与 AI 协作开发，越来越容易快速生成代码、搭建页面、跑通流程。
但当项目持续数天甚至数周，真正困难的事情才逐渐显现：
- 如何让下一次对话接得上当前工作；
- 如何及时发现需求理解偏差；
- 如何判断一个功能到底完成到什么程度；
- 以及什么时候应该停止继续投入。
这些问题需要一套贯穿构建过程的工作方法。
从实际开发经验中，可以提炼出五种值得复用的做法。它们的新意，主要体现在对 AI 协作特点的适应：
上下文会丢失，执行速度很快，局部成功容易被过度概括，持续推进也可能让错误方向越走越远。
一、让计划成为可恢复的工作状态
长周期项目很难只靠聊天记录维持连续性。
讨论越多，当前决定越容易被旧方案、临时结论和过程日志淹没。即使完整保留对话，下次接手也未必能迅速判断应该从哪里继续。
更有效的做法，是让项目文件明确回答几个问题：
- 目标是什么
- 当前范围是什么
- 已经完成什么
- 下一步做什么
- 什么条件下才能结束
主计划保持简短，只承载当前执行所需的信息。
具体设计按需引用，已完成的过程归档，仍然有效的限制和阻塞留在当前入口。
这样，计划就具备了恢复工作的能力。
换一次对话、换一个执行者，都可以从同一个入口重建必要上下文。文档的价值也可以据此衡量：
它能否帮助接手者准确继续工作。
二、用真实交付物校准需求
“实用”“有价值”“覆盖充分”这样的要求，在讨论阶段很容易达成表面共识。
等到结果出现，双方才发现对这些词的理解并不一致。
例如，用户想看到某个社区里的真实经验，系统却提供了经过整理的中文教程。语言、格式和信息量都可能符合预期，但来源和内容价值已经偏离目标。
因此，应尽早提交一个足以暴露理解偏差的真实结果。
它需要包含用户实际会判断的内容，让用户能够具体指出：
- 哪里符合预期；
- 哪里不对；
- 缺失的究竟是什么。
更关键的一步，是把反馈转成下一轮能够检查的条件。
例如，“不像社区内容”可以进一步拆成：
- 出处是否明确；
- 是否包含亲历经验；
- 是否提供独立的信息增量。
如此，用户反馈就能持续修正验收标准。
每一轮交付既推进产品，也提高双方对目标的理解精度。
三、让每个结论绑定具体对象和证据
AI 协作中，一个常见的问题是结论扩张：
- 测试通过了，就写成功能可靠；
- 一次真实调用成功了，就写成流程稳定；
- 用户认可一个案例，就写成整体效果得到验证。
这些判断之间存在明显的证据距离。
不同证据能够支持的结论范围并不相同：
| 证据 | 可以支持的结论 |
|---|---|
| 回归测试通过 | 对应工程行为符合预期 |
| 一次真实调用记录 | 某次执行确实成功发生 |
| 用户认可某个结果 | 该具体对象通过了本次审查 |
| 系统性评估结果 | 才可能支持更广泛的质量判断 |
因此，每次汇报“通过”或“完成”时，都应能回答：
- 哪个对象
- 哪个版本
- 满足了什么条件
- 依据是什么
这种做法允许一个项目同时拥有多种真实状态：
- 工程修复已经完成；
- 某个案例已获认可；
- 历史运行仍有部分失败；
- 整体质量尚未评估。
这些状态可以并存，也不必全部成为当前交付的阻塞。
准确表达完成程度，能让后续决策建立在可靠的事实之上。
四、按用户判断所需的证据决定补全程度
Agent 很容易沿着“把所有缺口补齐”的方向不断扩展工作：
- 网页抓取失败，就增加采集能力；
- 材料不足，就继续搜索；
- 存在不确定性，就追加研究。
每一步单独看都合理，累积起来却可能远远超过用户的实际需要。
更有效的决策顺序是：
- 用户需要作出什么判断？
- 当前缺少什么关键依据？
- 补到什么程度就足以支持判断？
- 达到后在哪里停止？
例如，一条公开摘要可能足以帮助用户判断：
是否值得继续阅读？
但它不足以支持：
该工具效果优于其他产品。
两种用途要求的证据不同，处理深度也应不同。
因此，完成条件应围绕实际用途制定。
必要且可修的问题得到处理，其余限制有明确处置，就可能满足当前任务要求。
与此同时：
- 无法获取的内容仍然保持未知；
- 历史失败继续保留；
- 没有足够证据的结论不被提前扩大。
这种方式既控制无止境的投入，也保护事实标准。
五、把关闭错误方向纳入正常工作流程
代码越来越多、测试数量不断增长、计划完成率持续上升，都可能发生在一个已经偏离用户目标的项目里。
因此，阶段检查除了确认实现是否正确，还应重新核对：
- 当前成果是否仍然服务于用户想完成的事情；
- 新增工作是否仍在有效范围内；
- 原先的完成条件是否仍然适用。
当方向发生变化，关闭旧计划是一项明确的项目决定。
这意味着：
- 旧任务停止推进；
- 旧授权不再被用于恢复执行；
- 已有代码、证据和失败记录保留；
- 后续工作从新的目标出发。
这让团队有能力在持续投入之前重新选择。
已经付出的成本可以作为经验留下，无须继续变成未来工作的理由。
一份最小可用的 AI 协作工作记录
这些方法最终可以浓缩进一份很小的工作记录：
# 当前工作状态
## 用户目的
用户真正想完成什么？
## 当前范围
这一阶段明确要做什么、不做什么？
## 下一步
下一项最值得执行的动作是什么？
## 完成证据
什么证据能够证明这一阶段已经达到要求？
## 停止条件
达到什么状态后停止继续扩展？
## 历史入口
旧方案、设计文档、失败记录和历史过程在哪里？
它不需要复杂的管理系统，但需要在关键变化发生时保持准确。
规则也应按实际问题逐步增加：
- 一次交接丢失了上下文，就改善恢复入口；
- 一次验收出现理解偏差，就补充具体检查条件；
- 一次执行无限扩张，就明确停止边界。
结语
好的 AI 协作机制，不只是让 AI 更快地产生代码。
它应该同时做到四件事：
- 让执行更连贯
- 让反馈更具体
- 让结论更可信
- 让人始终能够决定工作何时继续、何时结束
真正成熟的 AI 协作，不是让 Agent 一直向前跑，而是让整个构建过程始终保持：
可恢复、可校准、可验证、可停止。