02 合规、高质、高效我全都要AI 开发体系一上线就败了——第一次失败目标贪多的代价这是《嵌入式 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 真正落地恰恰是从这里开始的。
