——第一次失败：目标贪多的代价
这是《嵌入式 AI 落地手记》的第二篇。上一篇讲了我为什么决定重构开发流程，结尾留了句话：第一次尝试失败了。这篇就讲这次失败——它怎么发生的，以及它留下了什么。
三个目标，一个都不想放
判断 AI 编程跨过可用门槛之后，我着手做的第一件事，是为新项目搭一套 AI 原生的开发体系。
体系的形式是我和 AI 来回讨论了很多次才逐渐定下来的：一个仓库模板，里面放文档模板和技能（skill），再配上文件服务器的目录模板，三者组合。文档模板负责告诉 AI"每个阶段要产出什么、写到什么程度"，技能负责告诉 AI"具体怎么干活、怎么检查"。
目标定了三个：合规、高质、高效。
合规排在最前面。当时我们预期要满足行业内的最高要求，所以体系的很大一部分是按这个标准设计的：需求要分类编号，文档之间要能双向追溯，每篇文档有自己的状态和修改记录。高质和高效字面上都好理解——质量不能降，效率要提上去。
现在回头看，这三个目标单独看都没错。放在一起，就是灾难的开始。
第一版模板有多重
六月底，第一版仓库模板建出来了。举几个例子，说明它有多"重"：
- 需求要分成七类，每类有独立的编号前缀，法规合规单设一章；
- 设计文档里有一张"接口索引与覆盖"表，用来做反向追溯，计划交给 AI 维护；
- 每篇文档开头挂着一组状态字段（草稿、已批准……），末尾强制带一张修改记录表，文档信息还要把项目元数据整段复制一遍；
- 配了七个检查类技能，覆盖各阶段的评审和质量检查。
注意最后一条：只有检查，没有生成。这套体系里 AI 的角色是守门员而不是前锋——它能挑毛病，但起步阶段的需求、设计文档，主要还得靠人带着它写。这个缺陷当时没有意识到，是后来才补上的。
在第一个真实项目上
七月，模板在第一个真实新项目上用起来了。具体该怎么用，我们心里都没底，各按各的理解摸索。
第一个问题出在输入上。客户的输入里有大量二进制原始文件，AI 读这些文件本身就吃掉大量上下文，真正开始干活之前，额度已经去了一半。我们赶紧补了一个步骤：先把二进制原始文件转成 Markdown，再进流程。
但这个转换规则只写了下限，没写上限——要求"不丢失信息"，没有要求"控制复杂度"。于是转换出来的文档把原始文件里的每个细节原样保留，需求文档顺着这个密度一路膨胀。
膨胀到什么程度？几个数字：需求阶段十二天改了八版，终版五百八十多行；设计文档两天突击出来，也是五百八十多行。内容上也是同一个走向：测试阶段才该做的验收项，提前写进了需求文档；接口协议的行为细节，整段整段出现在设计文档里；术语表把行业里最基础的缩写都挨个定义了一遍。这些写法单看都算不上错——问题不在写文档的人，在模板。它的倾向是"不要遗漏"，而不是控制复杂度，文档只是忠实地执行了这个倾向。
第二个问题是交互带宽。AI 生成一版内容要推理不短的时间；人拿到结果，阅读、理解、指出问题，很费劲；意见提给它，它理解和修改又要很久。需求阶段我们小会讨论过几次，实际用下来的反馈很一致：按这套文档和模板走，比自己写还费时间，一天的工作时间里和 AI 交互不了几轮。
第三个问题出在我原来的设想上。我计划的用法是：AI 出初版，后续由人手工编辑、修改、维护。实际执行发现这条路走不通——人手工改 AI 写的文档，效率低，改不完整，而且人不完全理解 AI 的写作模式和习惯，改动越多越容易和它原有的结构打架。
整个过程是在怀疑、讨论、调整中度过的。七月底，设计评审通过。从当天下午开始，后续的编码和测试就没再参考这套工作流——项目进度等不起了，我们按自己的方式把项目做完了。文档也再没有更新过，那批文档成了评审那一刻的快照，和代码从此各走各的。
第一套体系的试用，就此停在了需求和设计两步。
复盘：两个根因和一个机制
这次失败有两个根因。
一是目标过载。 合规、高质、高效，三个目标互相拉扯，最后全压在了文档模板上。模板要承载合规的追溯要求，要承载质量的检查点，又不能拖慢效率——结果是每一项目标都打了折扣，每一项的成本却都实实在在付了。
二是为假想需求过度设计。 合规那部分，是按当时预期要满足的最高要求设计的。后来业务定位调整，这类要求不再是硬约束——也就是说，体系里最重的那部分，服务的是一个最终没有出现的需求。软件开发里有条原则叫 YAGNI——"You Aren't Gonna Need It"，你不会需要它——意思是只实现当前真实需要的东西，不为假想的未来需求买单。这条原则一般用在代码上，这次我学到的是，体系设计也一样：流程和模板，同样不能为假想需求买单。
还要说清楚一点：把"合规"从目标里拿掉，不是因为 AI 原生的工作流做不了合规。计算机科学里有句老话：所有问题都可以通过增加一个间接层来解决——它还有后半句，"除了间接层太多的问题"。要求有多高，就需要复杂度和它相匹配的流程来承载，合规也一样，无非是把流程再加一层。只是业务上不再需要、技术上又还没有经验，"合规"才不再是当前的目标。哪天它重新成为硬约束，这套体系要做的也不是推翻重来，而是把那一层加回去。
两个根因之外，还有一个更具体的机制教训：给 AI 定的每条规则，都要同时想清楚下限和上限。"不丢失信息"是下限，没有上限，文档就会无限膨胀。这个教训后来直接改变了我们给 AI 写所有规则的方式。
公平地说，这次试用不是全输。反馈里有一条我很重视：虽然过程费劲，但需求阶段就把项目实现的细节想明白了——放在过去，这些漏洞往往要到设计甚至编码阶段才暴露。流程本身有问题，但"让 AI 深度参与需求"这件事，没有。
失败留下了什么
试用的反馈很快转化成了行动。需求文档发布的第二天，模板仓库开始了第一波精简：删掉那张反向追溯表——维护成本高、信息增量小；检查规则里"靠 AI 眼力排序""模糊词检查"这类不可重复的判断，改成工具化的检查。这批改动里能看到当时对 AI 能力边界的实战认知：哪些事 AI 做得比人稳，哪些事不能指望它。
更长远的是两样东西。
一样是"AI 起草、人拍板"的分工。手工编辑路线失败之后，我们意识到人和 AI 的协作界面不在"编辑"上，而在"决策"上。这个分工后来贯穿了整个体系——上一篇说"每一步保留人工审核"，它真正的来历就是这次失败。
另一样更意外：那个失败项目留下的代码，后来被整理提取，成了我们知识库的第一批素材。第一次失败留下的资产，成了后来重构的地基。
这次失败之后，再有同行问我怎么起步，我的回答就几句话：先把原始文件转成 AI 读着省力的形式，别把上下文浪费在读二进制上；给 AI 的每条规则，下限和上限都写清楚；目标一次只扛一个，扛不动的先砍掉；人和 AI 的分工放在"决策"上，别放在"编辑"上。
下一篇
新项目这条线停下来反思的时候，另一个更朴素的需求找上门来：老项目的日常维护。没有宏大目标，没有体系设计，就是手头几件具体的活。
意外的是，AI 真正落地，恰恰是从这里开始的。
