AI 辅助工作很擅长继续往下做。模型可以再生成一版、再加一个检查、回应最新批评，然后又发现一个可以改进的地方。只要工作流程还知道自己为什么继续，这种能力很有价值。
我在搭建 AI 辅助的内容和产品流程时，也遇到过相反的情况：局部成果不断变好，整个过程却开始漂移。每一个新发现都像是在要求当前阶段重新打开；一处文字调整让句子更顺，却可能削弱事实边界；网站布局出了问题，流程又想回头重做研究。工作一直在进行，状态却越来越模糊。
我的解决方法，是分别定义每一个阶段的“完成”。一个阶段达成自己的目标，通过必要检查，解决或升级重大阻塞，并进入明确的停止状态，就可以结束。它不需要达到“以后再也无法改进”的程度。
这篇文章不是一份通用 Scrum 教程。它讨论的是 AI 辅助工作中的控制方法：当生成、审查和修改都可以不断继续时，怎样为流程建立自然终点。
先定义当前阶段，不要直接追逐最终愿景
“做出一篇优秀的双语文章”可以是目标，却不是一份清楚的阶段约定。它把研究、证据、写作、编辑、中文改写、网站实施、发布和效果判断全部放进同一句开放指令。
这些工作需要各自承担更小、更明确的责任。
- 研究阶段负责建立可用的证据与使用边界。
- 内容简报（Content Brief）负责确定文章承诺、结构、内容主张和排除范围。
- 英文阶段负责产出通过内容简报、主张核查（claim audit）与自然度检查（humanization audit）的候选稿。
- 中文阶段负责用自然中文重写，并保留英文事实和证据边界。
- 网站实施负责保留候选内容，并通过构建、渲染、SEO、无障碍与草稿安全检查。
- 发布只能在明确授权之后发生。
- 效果观察要等内容真正上线后才有对象。
这些阶段互相连接，却不能互相替代。构建成功不代表编辑质量已经通过；英文流畅不代表中文事实完全对齐；网页上线也不代表 SEO 或 GEO 已经产生效果。
按阶段定义完成，能让流程保留这些差别。
一份有效的完成约定包含五个部分
实用的约定不只是一张 checklist。我会把它分成五个互相连接的部分。
1. 一个单一阶段目标
先说明这个阶段到底负责哪一个结果。目标要具体到可以排除不属于当前阶段的工作。
例如，证据阶段可以负责“建立一组足以支持核心主张的来源与第一方记录，并说明使用边界”。它不负责“写出市场上最全面的文章”。
2. 必须通过的验收标准（Acceptance Criteria）
列出成果继续流转之前必须成立的条件。条件应当可以观察：来源计划（source plan）已存在；每一个重大主张都有支持类型；中文候选稿保留了所有数字限制；网站路由仍处于未发布状态。
不要用模糊分数代替判断。自动评分可以提示潜在问题，验收条件则说明这个问题为什么重要，以及怎样才算通过。
3. 与阶段匹配的检查
不同检查从不同角度验证条件。内容简报审计（Brief audit）判断文章计划是否兑现承诺；主张核查检查说法有没有超出证据；双语事实回归则确认另一种语言或网站实施有没有改变原意。
检查必须与当前阶段匹配。如果每个环节都运行所有可能的审计，只会制造噪音，也更容易让两个工具围绕无关偏好争论。
4. 有限的修复规则
重大检查失败时，流程既需要修复权限，也需要明确上限。
在我为 HuiyangXie.ca 建立的 Low-Touch Blog workflow 中，同一个重大阻塞最多可以进行两次有针对性的自动修复；一篇正常文章全程最多使用四次重大自动修复。如果问题仍然存在，流程必须停止并请求 Owner 决定。
具体数字属于这套 workflow 的设计，不是普遍定律。它们的作用是让升级路径可以预测，避免系统用无限改稿掩盖不确定性。
5. 一个明确停止状态
最后要说明，什么状态能证明当前阶段已经结束：带哈希值（hash）的锁定文件、通过的审计结果集（audit set）、可以预览的网站候选，或一份异常处理包（exception package）。同时说明下一步允许做什么，哪些动作仍然禁止。
如果没有这条线，“完成”的范围会悄悄扩大。通过编辑检查的稿件可能直接进入发布；一个预览问题可能重新打开锁定源稿；一次生产流程跑通，也可能被错误描述成效果已经得到验证。
“完成”和“还能更好”不是同一件事
AI 辅助工作经常暴露阶段完成与局部优化之间的区别。
假设一篇英文文章符合内容简报，所有主张都有依据，读起来也自然。审查建议把三个普通动词换成更有变化的写法。修改之后，文字也许会稍好一点，但这不等于原来的阶段没有完成。
如果同一轮审查发现，一句话把没有衡量过的结果写成事实，情况就不同了。它违反证据边界，属于重大问题。修正或升级之前，当前阶段不能关闭。
判断重大程度，可以让流程继续服务于阶段承诺。真正的阻塞会威胁事实、证据、隐私、安全、可用性、路由、发布控制或其他已经定义的条件；可选润色可以记录下来，不必消耗修复次数。
模型经常会提出很长的反馈清单。反馈很多，并不代表问题很严重。
防止审计与修复（audit and repair）来回拉扯
自动流程很容易陷入反复拉扯（ping-pong）：一次修改为了减少 AI 味而缩短解释，内容简报检查又认为内容不完整；系统把细节补回去，风格检查接着指出重复。两个方向轮流拉动，流程却没有收敛。
我用四条规则打断这种循环：
- 为每个阻塞保留稳定的失败特征（failure signature），让同一个问题在不同轮次仍能被识别。
- 修复预算只计算真实内容修改，不计算审计执行次数。
- 改动之前，先判断它可能影响哪些原本已经通过的检查。
- 同一阻塞经过两次针对性修复仍未解决、修改撤销了之前的修复，或循环没有产生实质进展时，立即升级。
目的不是让所有审计对风格达成一致，而是在保留事实和已接受策略的前提下，解决真正影响阶段完成的问题。
下游失败不应该抹掉上游完成状态
状态边界能够保护已经结束的工作。
假设研究结果已经验证、保存并锁定。之后网站因为 table component 无法渲染而构建失败，这是实施问题。重新进行关键词研究或再次调用付费 provider 都不会修好它。
同样，中文措辞问题不应该重新打开英文研究；预览路由损坏不应该改写已经锁定的文章；部署失败也不应该重新生成内容。一次变化只应让真正依赖它的下游状态失效。
这也是 durable artifact 很重要的原因。流程需要知道，究竟是哪一个输入通过了检查、到达什么状态，以及哪些下游成果依赖它。完成状态不能只存在 terminal buffer 或聊天记忆里。
记录新发现，但不要让它们无限延长当前阶段
明确停止并不等于忽略有价值的反馈。关键是把反馈放到正确位置。
如果阶段通过后出现一个非重大改进，就把它写进质量、编辑、实施或观察改进清单，并保留足够背景，让之后能够判断它是否值得形成新版本。不要悄悄丢掉，也不要自动让当前周期继续保持打开。
这样，产品和工作流程可以持续学习，同时不把每一个新发现都当作紧急事故。当前版本依据现有证据结束；下一个版本则从更完整的信息开始。
一份够用的阶段模板
下面这组字段通常已经足够：
| 字段 | 需要回答的问题 |
|---|---|
| 阶段目标 | 当前阶段负责哪个具体结果？ |
| 输入 | 可以使用哪些规范文件（canonical artifacts）和权限？ |
| 验收条件 | 哪些可以观察的条件必须通过？ |
| 审计（Audits） | 哪些检查用来验证这些条件？ |
| 修复预算 | 允许多少次针对性修改，什么问题才算重大？ |
| 停止状态 | 哪个文件或状态证明阶段完成或进入 exception？ |
| 下一步权限 | 接下来允许发生什么，由谁授权？ |
这份模板刻意保持简短。它的价值来自边界，而不是更多文书。
在流程开始移动之前定义完成
设定停止条件的最好时机，是审计发现问题之前。否则，工作流程很容易根据自己已经生成的结果，临时改写成功标准。
每个阶段开始时，先决定它负责什么、哪些检查必须通过、允许多少修复、什么情况需要升级，以及新的非阻塞问题应该进入哪里。完成时，再保存能够证明结果的文件与状态。
AI 可以让工作快速前进。“完成”的定义，则让这些动作真正累积成可靠进展。