——减法：两次尝试后的彻底重构
这是《嵌入式 AI 落地手记》的第四篇。前面讲了第一次失败，也讲了老项目维护线怎样从真实需求里长出来。这篇回到新项目线：两次尝试之后，我为什么不再继续局部修补，而是把最初的体系彻底重构了一遍。
需求很顺，设计却卡住了
第二次把新项目流程放进真实项目时，我以为最难的地方已经过去了。
第一次试用失败后，模板已经做过一轮精简。这个项目的需求阶段也确实顺了不少：增量范围先圈定，已有功能不重复定义，AI 自检后再由人逐条裁定。照第一次的经验看，最容易膨胀、最耗交互的阶段，这次总算走过去了。
到了设计，节奏又慢了下来。
同一个功能，触发条件在一处，状态变化在另一处，接口又被收进一张大表。单看哪一节都没有明显错误，想完整理解一个功能，却得在不同章节之间来回拼。维护更麻烦：一处规则写在四个地方，评审后改了三处，漏了一处。
第一次那种需求膨胀没有重演，设计文档却又变成了另一种难用：内容都在，秩序不对。
不是再删几个字段就能解决
两次尝试之间，我们一直在改模板。
第一次试用后，删过维护成本高、信息增量小的追溯表，把一些依赖 AI"眼力"的检查改成可重复执行的规则。第二次设计卡住时，也现场补过章节，让眼下装不下的内容先有地方放。其中有一节还明确标着只服务当前项目。内容暂时有了归属，模板却开始依靠项目例外维持。
这些改动都有用，但基本假设没有变：目标仍是合规、高质、高效三个；流程主要围绕文档交付展开；AI 大多负责检查，生成和不少编辑工作仍然压在人身上，流程状态则要靠一套复杂机制维护。
第一次失败暴露的是目标和复杂度问题，第二次暴露的是组织方式问题。再往前看，还有第一次留下的人机分工问题。几处根子连在一起，继续打补丁，只会不断给旧结构增加例外。
我决定不再沿着原模板往下修，做一次彻底重构。
九月初，目标改成两个
9 月初，模板仓库里有一个提交，把项目目标从"合规 + 高质 + 高效"收敛为"高质 + 高效"。
合规部分不再作为当前目标，原因在第一次失败复盘时已经说过：它来自当时预期要满足的最高要求，后来业务定位调整，这类要求不再是硬约束。这不代表降低质量，也不代表这套流程以后无法承载合规，只是眼下不再为一个并不存在的硬要求提前付成本。
那次提交还在模板里写过一句话：
模板与技能中每项机制的去留，以项目实证（是否防住过真实缺陷或返工）为准。
这句话能克制"以后也许用得上"的设计冲动，但现在看，它不能作为唯一尺度。机制的价值不一定只体现为抓住缺陷：有些能减少重复纠正，有些能让必要动作稳定发生。
我实际改流程的方法更朴素：执行中遇到困难，先找困难来自哪里；找到来源，再决定改进还是去除。每次人纠正 AI 的地方也收集起来，变成下一次不必重复纠正的经验。
所以，判断一个机制，除了问它防住过什么，还要问：有没有解决真实困难、减少重复纠正、让必要动作稳定发生？维护成本又由谁承担？
首轮重构就有数百行删改。数字本身不证明方向正确，只说明这次改的是机制，不是措辞。真正难的是按这些尺度处理具体机制。
砍、留、改
砍掉的，主要是重复承载和重形式。
每篇文档开头的状态字段、末尾的修改记录表被删掉了。批准以 PR 记录为准，历史以 Git 提交为准，同一件事不再在文档里另外维护一份。
这不只是为了减少重复。文档里的状态靠口头要求大家记得维护，实际效果并不好，就发生过评审通过后没人再回去改状态的事。把批准改由 PR 承载后，分支保护要求合并必须经过评审，必要动作由工具卡住，执行反而稳定下来。
成套的追溯矩阵也退出了模板，只保留轻量的断链检查。让一个技能扫描整个仓库、判断项目下一步该做什么的设计同样被放弃——流程推进由人负责，AI 不做阶段裁决。
有些表格原本就打算交给 AI 维护，似乎这样就不会增加人的负担。实际用过才发现，AI 维护也不是零成本：生成要上下文，检查要上下文，人最后仍要理解它。一份没人消费的文档，不会因为交给 AI 写就变得值得保留。
同期，模板里还删掉了四份评审报告文件。评审没有取消，只是不再为每项评审额外制造一种文档形态。
留下的，恰好是那些直接支撑质量的东西。
需求、设计、编码、测试、发布的阶段骨架保留，各阶段评审保留。描述一个功能时，触发、执行、输出、异常这四个部分保留，因为它们直接影响需求能否被下游使用。
有些机制不是彻底删除，而是换一种成本更低的形式。完整追溯矩阵不维护了，接口之间是否断开、设计中的全局事实与组件说明是否闭合，仍然要检查。减的是维护形式，不是质量要求。
改动最大的，是设计文档的结构和 AI 在流程里的位置。
设计不再按章节把所有功能横向拆开，而是按功能和组件组织。全局事实集中说明，每个组件相关的行为、接口和参数尽量归到同一处，避免一个功能散落在多处，也避免同一事实由几个章节分别维护。
第一版只有检查技能，改版把生成技能逐步补齐：需求整理、设计起草、代码起草、测试用例整理，都有对应的生成与检查环节。AI 不再只负责指出问题，也承担初稿和一致性维护。
人的工作随之移动。与其在 AI 生成的长文档里逐句编辑，不如让 AI 先交出假设、方案和风险，人在这些决策点上确认。这个分工来自第一次失败，在老项目维护中验证过，这次被正式写进新项目流程。
回头看，这一轮砍、留、改的大部分手术对象是文档模板：删的是文档形态，留的是功能四件套，改的是设计文档结构。技能在这一轮主要是补齐生成侧；重构流程的相当一部分精力，就花在这些模板上。
新体系不只是一套模板
重构后的体系，最后不再只有"仓库模板 + 技能"这两样东西。
- Git 使用规范：用阶段分支、PR 评审和基线 Tag 管理需求、设计、代码和测试产物。
- 文件服务器目录模板：保存权威原始文件、硬件资料和客户交付物，分别按各自的版本轴管理。
- 项目仓库模板：以各阶段的文档模板为主体，规定每个阶段产出什么、写到什么程度、放在哪里，以及 AI 可以读取和维护哪些派生文件。
- 技能：把原始文件转换、需求整理、设计、编码、测试和检查拆成可执行的步骤。
- 知识库：沉淀成熟项目里已经验证过的系统架构和各模块程序模式。
项目仓库模板在这里同时承载约束和知识。它约束每个阶段最终交付什么、边界到哪里；其中文档模板的栏目、判据和功能四件套，也把过去对“合格交付物”的理解固定下来。技能负责过程，知识库负责设计判断，模板负责最终产物应该长成什么样。
知识库在这里不是可选的参考资料。它是新项目流程的默认组成部分，之后的设计和开发都会参考其中已经定义好的架构与模式。技能告诉 AI 怎样推进工作，知识库让 AI 知道我们过去怎样做才合理。
这些内容之上，还有一条没有变：每一步保留人工审核。AI 起草，人拍板；AI 检查，人定论。
踩坑与教训
如果你也想给团队的流程做减法，我建议先别急着删文档。先把执行中的困难、返工和人纠正 AI 的记录摆出来，找到来源再决定改还是删。对新增机制，则多问一句：它解决的是哪个真实问题，维护成本由谁承担？
纠正记录也不能见一条就固化一条通用规则。先分清项目特例和共性问题，否则模板还会在反馈中重新膨胀。
精简也不能以拿掉质量门为代价。评审、基线、必要的检查，是开发必须支付的成本。该砍的是重复记录和无人消费的形式，该留的是能让错误更早暴露的环节。
流程约束写在哪里，也决定它能不能落地。口头约定可以解释原则，关键动作却要尽量进入实际工作路径：模板、技能、分支保护，各有各的位置。也不值得把所有建议都强制化，强制本身有成本，应该用在少数不能跳过的质量动作上。
AI 原生同样不等于 AI 全自动。流程越往后改，我越倾向于把 AI 放在记忆、生成和一致性检查上，把人放在取舍、批准和物理验证上。审核如果只能落在几百行产物的全文阅读上，人和 AI 都很容易被拖住。
最后，给 AI 设计流程，不能只设计文档。权威输入在哪里、不同产物怎样保持同一版本、过去的经验怎样进入当前项目，这些问题不解决，模板写得再完整，也只能保证产物看起来像样。
下一篇
彻底重构之后，新体系有了一个完整轮廓。接下来要先回答几个朴素的问题：原始文件放在哪里，AI 读的是哪一版，人凭什么批准，半年后怎样找回同一批需求、设计和代码？
下一篇讲工程骨架：为什么连目录、分支和原始文件的存放方式，都要为 AI 重新设计。
