第一次尝试：框架齐全，项目归零
2025 年 1 月，我做一个「入职信息填报」Web 应用。流程看起来很规范：
- 原型阶段：用 Trae 做交互原型，表现出色——当时我判断它可以替代 Axure
- 开发阶段：让同一个工具实现后端 + 数据库 + 前后端联调，出现了严重的上下文遗忘——前面确认过的细节，在后续实现时已经模糊
- 文档纪律介入：引入项目管理式四套书（需求规格 / 概要设计 / 详细设计 / 数据库设计），并写了约束文档结构的 skill
- 多 Agent 实施：按前端 / 后端 / 测试 / 产品经理四角色分工
结果：登录无法使用。多轮修复联调一整天，失败。项目放弃。
复盘时我意识到问题在哪：文档纪律”做到位”的标准，当时被定义为”有框架、有流程、有产出”——但不包含质量审查。文档量太大审不完，技术细节我也看不懂，只能看懂流程。五套书的产出齐全，质量参差。
第二次尝试：原样交接，一次修复 90%
2025 年 5 月，我把同一个项目的文档和跑不通的代码原样交给更强的新一代模型。
没有重写文档，没有整理上下文——就是原样丢过去。模型主动识别问题并迭代修复，一次完成了约 90% 的功能。
这个对照实验说明什么
两次的差异有两层，缺一不可：
第一层：模型能力代差。 强模型能消化劣质输入，从跑不通的代码里自己找路。这个能力是真实的。
第二层：但强模型的成功仍需输入。 我原样交接时，文档里至少有目标、有需求描述——AI 才有执行的原点。不给目标、不给需求，再强的模型也不可能替你做事。
所以结论不是”换强模型就行”，而是一个更锋利的判断：
模型代差和输入质量，任何一块短板都能让项目归零；但只有短板被补齐，长板才发挥作用。
对我的三个改变
这次实验之后，我的 AI Coding 习惯发生了三个具体变化：
- 文档纪律升级为”文档质量”：不再满足于”有产出”，验收时问”这份文档能让一个不看代码的人判断对错吗”
- 工具选型先看代差：2025 年那次我验证过一个判断——“模型代差 + Harness 差距 > 文档流程规范”。在弱模型上磨流程，不如直接换强模型
- 人守在目标层：模型可以消化烂输入、可以自己找路，但”做什么、为什么做、做到什么标准”这三件事，永远是人给出的。AI 不可能替你定方向。
失败的项目不丢人，丢人的是没有从失败里提炼出对照实验的数据。这个项目花了时间，但它让我在后来的每个 AI 项目里都能快速判断：问题出在模型、出在输入，还是出在我自己没把目标说清楚。