AI 可以帮助整理资料、发现结构缺口和生成初稿，但它不能替作者确认事实，也不能把没有发生过的测试变成经验。对技术网站而言，真正可持续的原创不是每天批量改写同一批新闻，而是持续解决具体问题，并保留来源、测试过程、审核结论和更新记录。
本文给出一套可落地的 AI 原创文章工作流。它把模型放在研究与编辑环节，把选题判断、事实确认、测试执行和最终发布责任留给人。文章产量可以并行扩大，但证据门槛不能随之降低。
一、先定义什么算本站原创
原创不等于文字第一次出现。把多个页面交给模型重新措辞，仍可能没有新增信息。技术文章至少应提供一种可识别的增量：
- 针对真实问题完成配置、排错或对比；
- 给出可复现的代码、输入条件和失败边界；
- 将分散的官方信息组织成清楚的决策路径；
- 记录本站实际实现中的取舍和复盘；
- 在已有方法上补充新的验证、限制或版本变化。
Google Search Central 关于实用内容和生成式 AI 内容的说明，都把重点放在内容是否对读者有帮助、是否准确以及是否提供上下文，而不是使用了哪一种生产工具。因此，后台的“AI 生成”只能表示稿件来源环节，不能代替原创判断。
二、用选题卡阻止无目的写作
每篇文章开始前先建立选题卡，不要直接让模型“写一篇 SEO 文章”。选题卡至少回答六个问题：
- 读者正在完成什么任务，卡在哪里？
- 主关键词背后是教程、排错、对比还是配置意图？
- 站内已有文章是否已经完整回答？
- 本文准备新增什么证据或经验？
- 哪些结论必须查官方资料，哪些必须亲自测试？
- 发布后应该链接到哪个专题和哪些下一步文章？
例如“AI 总结不好用”太宽泛，可以拆成“如何建立固定样例做回归测试”“模型切换后如何判断摘要是否退化”“结构化输出失败如何定位”。第一个问题已有AI 总结质量评估与回归测试承接；如果新文章不能提供不同的搜索意图或新证据，应更新旧文，而不是制造相互竞争的页面。
选题卡还应记录暂定标题、主关键词、目标读者、预期结论、必要测试、负责人和截止日期。AI 可以据此提出子问题，但作者要删除无法验证、与本站无关或只是追逐热词的方向。
三、建立来源台账，而不是堆参考链接
资料收集应围绕“哪条结论由什么证据支持”。建议把来源分成四级：
- 产品官方文档、标准、规范和源代码；
- 官方公告、版本日志与状态页；
- 原始研究、作者说明和可复现仓库；
- 第三方教程、社区讨论和搜索摘要。
前两级优先用于接口参数、限制、版本和行为结论。社区资料适合发现问题，不应在未经验证时成为唯一依据。搜索结果摘要只用于定位原页面，不能代替打开并阅读来源。
每条来源在台账中记录 URL、页面标题、访问日期、支持的结论、适用版本和是否需要复测。模型可以从资料中提取候选结论，但作者必须回到原页面核对。引用页面也可能过期，因此“有链接”不等于“事实已确认”。
一个轻量台账可以这样记录：
| 待核验结论 | 证据类型 | 当前状态 | 发布处理 |
|---|---|---|---|
| 请求格式与字段 | 官方接口文档 | 已核对 | 标注适用版本 |
| 某错误是否可重试 | 官方文档与受控测试 | 待测试 | 测试前不下结论 |
| 某方案性能更快 | 基准测试 | 未执行 | 删除比较结论 |
| 搜索排名一定提升 | 无可靠证据 | 不成立 | 不发布承诺 |
四、把“实测”写成可复现记录
只有真正执行过，才能写“实测”。一次合格的技术测试应记录：
- 日期、运行环境、依赖和模型版本；
- 使用的配置与关键输入，敏感信息需脱敏；
- 预期结果、实际结果和判断规则；
- 成功样例、失败样例与重复次数；
- 哪些变量未控制，结论能外推到哪里。
例如测试大模型 API 重试时，应在受控环境模拟 429、503、超时和不可重试的 4xx，而不是等待生产偶发故障。具体错误分类可参考大模型 API 429、超时和 5xx 排查。若只验证了一个模型、一个地区和少量请求，结论必须限定在该环境，不能写成“所有 OpenAI 兼容接口都支持”。
测试失败也有内容价值。记录失败条件、日志和修正过程，通常比只展示最终成功截图更能帮助读者。无法公开的数据可以描述采集方法和字段，但不能用模型生成一组看似合理的数字填空。
五、先写证据稿，再让 AI 帮助成稿
推荐把草稿分为两层。第一层是证据稿，只包含已经确认的事实、测试记录、代码、待核验项和来源映射。第二层才是面向读者的成稿。
AI 在成稿阶段适合执行以下任务：
- 根据选题卡整理章节顺序；
- 找出概念跳跃、重复段落和缺少前提的位置；
- 将日志与测试笔记转成易读说明；
- 检查术语是否前后一致；
- 生成标题和描述候选，供作者选择；
- 根据已确认内容提出需要补充的问题。
提示词应明确禁止新增事实、数字、引用和测试结果。模型遇到证据不足时应输出“待核验”，而不是补全。涉及代码时，代码仍需运行、语法检查或最小测试；涉及模型输出质量时，可使用固定样例和评分规则，避免只凭阅读感觉。
六、逐条事实核验，不只检查错别字
成稿后提取所有可验证陈述，按类型复核：
- 版本事实：模型名、API 路径、参数和发布时间；
- 行为事实：接口是否兼容、错误码如何返回、字段是否必填；
- 数量事实：价格、限制、耗时、成功率和页面数量；
- 因果陈述：某项修改是否真的导致收录、性能或质量变化；
- 引用陈述：来源是否确实支持正文，而非只与主题相关；
- 实测陈述：是否有原始记录，环境和边界是否写清楚。
数量和绝对化词语要重点搜索，例如“全部”“一定”“免费”“最快”“提升了 30%”。没有证据就删除或改成有限条件下的观察。SEO 描述、标题、图注和结构化数据也属于文章事实范围，不能正文谨慎而摘要夸大。
技术文章中的链接还要检查目标 slug、锚文本和上下文。可以结合技术博客文章内链设计检查孤儿页与失效链接，但相关链接只在确实帮助读者完成下一步时添加。
七、人工复审决定能否发布
最终复审人不应只点“通过”，而应明确检查：
- 文章是否回答选题卡中的真实任务；
- 主要结论能否追溯到来源或测试；
- AI 是否添加了证据稿中不存在的事实；
- 代码能否运行，示例是否泄露密钥或个人数据；
- 标题、摘要与正文是否一致；
- 限制、失败情况和适用版本是否清楚；
- 分类、专题、内链、canonical 和 Article 结构化数据是否正确；
- 是否需要专业人员进行更高等级审核。
后台可设置 draft → evidence_ready → ai_edited → fact_checked → reviewed → published 状态。每个状态保存操作者、时间和备注。模型可以建议状态，但不能自行跨过 fact_checked 与 reviewed。并行 Agent 写作也应遵守同一规则：一个 Agent 负责一个有边界的选题，统一由人工编辑合并、查重和发布。
八、发布不是终点，要按触发条件复审
技术内容会因模型、SDK、价格、接口和站点实现变化而过期。每篇文章应保存 contentVersion、reviewedAt 和 nextReviewAt，并配置事件触发复审：
- 官方文档或 API 版本更新；
- 依赖升级导致示例失效；
- 读者反馈与线上日志证明结论不完整；
- 站内 URL、分类或专题结构调整；
- 搜索意图发生变化，文章与标题不再匹配。
复审时不要仅修改日期。应重新打开关键来源、运行核心示例、检查全部内链，并记录修改了什么。若结论已经失效，显著标注旧版本适用范围；若新旧内容的搜索意图相同，应更新原 URL，而不是保留两个互相重复的版本。
九、可直接执行的发布清单
选题与证据
- 选题卡写明读者任务、搜索意图与新增价值；
- 主要结论已映射到官方来源或真实测试；
- 未执行的测试均标记为待验证；
- 与站内旧文不存在同意图重复。
成稿与核验
- AI 未新增无法追溯的数字、引用和产品行为；
- 代码已经运行或明确标注为示意；
- 实测记录包含环境、输入、结果和边界；
- 标题、描述、正文与结构化数据没有互相矛盾。
人审与维护
- 事实核验人与最终复审状态已记录；
- 敏感信息、许可证与引用方式已检查；
- 文章已加入正确专题并建立自然内链；
- 已设置版本、复审日期和事件触发条件。
可持续原创的关键不是让模型连续输出更多字，而是让每篇文章拥有明确问题、可信证据、真实验证、人工责任和维护周期。AI 能提高研究与编辑效率；决定一条结论是否值得发布的，始终应是可以追溯的证据和负责复审的人。
发布后的版本复审
内容发布不是结束。版本变化、链接失效和代码回归应进入复审队列，详见 技术文章过期检测与更新策略。