*——减法：两次尝试后的彻底重构*

> 这是《嵌入式 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 重新设计。


这是《嵌入式 AI 落地手记》的第四篇。前面讲了第一次失败，也讲了老项目维护线怎样从真实需求里长出来。这篇回到新项目线：两次尝试之后，我为什么不再继续局部修补，而是把最初的体系彻底重构了一遍。

04 · 给 AI 的流程做减法：三个目标砍成两个的取舍

人工智能

重构源于两次实战失败：需求膨胀已控但设计文档秩序混乱、多处维护易漏。砍掉重复状态字段和评审报告，保留功能四件套与阶段评审，AI从检查转向生成与一致性维护。目标收敛为高质+高效，新增知识库与工程骨架，确保AI可溯源、决策有人工审核。

服务器

让每一个 Agent，都跑在云上

lexiang

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

04 · 给 AI 的流程做减法：三个目标砍成两个的取舍-腾讯云开发者社区-腾讯云

04 · 给 AI 的流程做减法：三个目标砍成两个的取舍

04 · 给 AI 的流程做减法：三个目标砍成两个的取舍

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐