
> AI 编程工程化实践系列 · 卷五 · 落地 | 第 8 篇 / 共 8 篇
>
> 这个系列只讲一件事：怎么用工程化的方法，把 AI 编程从"碰运气"变成"可预期"。

![image.png](https://developer.qcloudimg.com/http-save/yehe-12408676/8db496f51dd88a982650b1f74eb2dbdd.png)

---

## 一、最后一篇，回到人的问题

前面七篇讲的全是技术：五份资产、三层约束、验证机制、六步工作流、两个复杂场景。

但真正决定这套东西能不能落地的，往往不是技术。是"团队里就你一个人在用"。

你建好了 AGENTS.md，写好了规则，用得很顺。同事还在凭感觉跟 AI 对话，改三遍改不对。你想推，又不知道怎么开口。说"你们应该用 SDD"，听起来像传教；不说，这套东西就永远是你一个人的玩具。

这一篇讲两件事：**怎么从一个人推到全团队**，以及**推进过程中那几个高频问题怎么排查**。

![image.png](https://developer.qcloudimg.com/http-save/yehe-12408676/62493e044f3512c094cce3a2571e27a5.png)

## 二、阶段二：三个人怎么对齐

第 2 篇讲了阶段一（一个人怎么起步），这里从阶段二开始。

**触发条件：你的效率差攒到肉眼可见，同事主动来问你。**

通常是两到三周。别提前推，没有可见的结果做支撑，说什么都是说教。

三步渐进法：

**第一步，在 Code Review 时自然引出。**

不要说"你应该用 SDD"。而是在 review 同事代码时，指着某一段说"这段是 AI 按 spec 生成的，一次过，没有返工"。

用结果引起好奇，不用说教引起反感。人只会模仿自己想要的东西，不会接受别人塞给他的东西。

**第二步，拉一个人一起写 rules/。**

找一个跟你协作最紧密的同事，跟他说"咱俩把踩过的坑总结成 rules 吧，下次 AI 就不会再犯了"。

这一步的关键是让他体会到那个爽感：**写一条管用的规则，这件事以后就再也不用说了。** 只要他体会过一次，后面不用你推。

**第三步，把规范文档放进项目仓库。**

等 rules/ 攒到 5-8 条经过验证的规则，提交到仓库。

对新人来说，这是实打实的好处：入职第一天读完 rules/ 就能让 AI 按团队标准干活，比"看一个月代码自己领悟"高效太多。

## 三、阶段三：跟现有流程嫁接

当核心小组（三五个人）都习惯了这套方法，可以推团队级的融合。

核心原则只有一条：**不推翻现有流程，在现有流程上嫁接。**

| 现有流程节点 | 嫁接方式 |
|------------|---------|
| 需求评审 | 增加一个"Spec 就绪"检查项：需求对应的理解态 PRD 是否已生成 |
| PR 审查 | CI 自动跑规范合规检查，把规范遵守情况列入 PR 模板的 Checklist |
| 回顾会 | 增加一个效率快报：本周 AI 按 spec 生成的任务数、一次通过率、返工轮次 |
| 新人入职 | 第一天就分配一个"贡献 rules"的小任务：读完 AGENTS.md 和 rules/，补一条他觉得缺的规则 |

四个嫁接点里，第二个最容易见效。CI 里加一条 Checkstyle 检查，PR 模板里加一个勾选项，半天的工作量，规范遵守情况从此可见可查。

第三个（回顾会效率快报）价值最大但阻力也最大，因为要用数据说话。这就引出下一个问题：该用什么指标衡量。

## 四、一个常见顾虑：团队已经有规范了

推这套东西，最常听到的一句话是“我们规范早就有了”。

规范确实有。第 4 篇讲过那个判断：规范的问题从来不在于有没有写，而在于写了之后有没有被执行。已有的规范大概率躺在 wiki 里，或者只在老工程师的脑子里。新人忘了，review 时才被发现。

所以嫁接的时候不要说“我们要新建一套规范”，要说“把已有的规范搬到 AI 能读到的地方”。具体做法很轻：

1. 找出现有规范里**最常被违反的那几条**（你心里有数，就是 review 时反复提的那几条）
2. 把它们改写成可判定的形式（第 4 篇的标准：AI 或 CI 能自动判断有没有被遵守）
3. 放进 `rules/prompt-rules.md`

这个过程不是新建规范，是把已有规范从“人读的文档”翻译成“AI 读的指令”。翻译三五条就能跑起来，剩下的以后再说。

阻力最小的地方在于：你没有否定团队过去的工作，只是让它第一次真正生效。

## 五、别用代码行数衡量

一个常见的错误度量是"AI 生成了多少行代码"。

这个数字毫无意义，甚至有害：代码行数越多，说明 AI 写得越啰嗦；你奖励这个指标，等于奖励冗余。

改用**规范有效条数**：能被 AI 遵守、能被 CI 验证、能在实际任务中减少返工的规则数量。

这个数字比代码行数更能反映真实成熟度。它涨得慢，但每涨一条，团队就少踩一个坑。

配套的一条纪律：**如果某条规则写了，但 AI 从来不违反它，这条规则就该删掉。** 规则的价值跟违反频率成正比，从没触发过的规则等于没有规则，留着只会稀释注意力。

## 六、9 个排查项

推进过程中反复出现的问题，集中在下面三类。逐条给了排查动作。

### 问题一：代码看着对，但跑不通

| # | 排查项 | 具体动作 |
|---|--------|---------|
| 1 | import 缺失或引错包 | 先跑编译。AI 经常漏 import，或者引入了错误版本的包路径 |
| 2 | 字段映射错误 | 检查 DTO 和 Entity 的字段名是否一致。AI 可能自己发明了不存在的字段 |
| 3 | 隐式依赖遗漏 | AI 只看到了你给的文件，可能依赖了某个你没给的类的某个方法 |
| 4 | 环境差异 | 检查 `code-style-spec.md` 里有没有写明 JDK 和 Spring Boot 版本。AI 不知道你用的是哪个版本 |

**判断原则**：如果 AI 反复犯同一类错误，说明约束层的规则不够精确。比如"编译不过"反复出现，检查是不是缺了一条"生成代码后先跑编译"的 Always 层规则。

### 问题二：规范写了，但 AI 不遵守

| # | 排查项 | 具体动作 |
|---|--------|---------|
| 5 | 约束描述太模糊 | "接口返回要规范"对 AI 等于没写。改成"接口必须返回 `ApiResponse<T>`" |
| 6 | 约束文件没被加载 | 检查 AGENTS.md 的加载指引表，当前任务类型对应的"必须加载"列里有没有这份文件 |
| 7 | 上下文溢出 | 一次给了太多文件，规则被挤出了有效上下文。减少单次给 AI 的文件数 |
| 8 | 模型限制 | 某些模型对"绝对禁止"类指令的遵循度天然偏低。升级模型，或者补一层静态检查 |

前三项第 4 篇展开过，这里只列要点。第四项是前三项都排查完之后的兜底方案：既然模型本身对否定指令不敏感，就把这类规则从"让 AI 记住"改成"让 CI 检查"。

**判断原则**：AI 不遵守规范，先假设是自己没说清楚，而不是 AI 太笨。这个顺序反过来的话，你会一直在换模型，问题一直在。

### 问题三：维护成本太高

这是推进到一定阶段后必然出现的抱怨。解法是分层，不是全都要维护：

| 该长期维护 | 该随用随扔 | 写进代码注释就够 |
|-----------|-----------|----------------|
| AGENTS.md（项目总入口，300 行以内） | 一次性的"本次任务 prompt" | 单个方法的特殊业务逻辑 |
| prompt-rules.md 的 Always 层和 Never 层 | 探索阶段的临时 spec | 字段级校验规则（注解本身就是 spec） |
| api-spec.md 的统一响应格式和错误码 | 尚未验证的规则草案 | 状态流转的前置条件（状态机图比文字直观） |

**判断原则**：规范维护的成本应该远小于它节省的返工成本。如果发现某条规则写了但 AI 从来不违反，说明它不值得写成规则。

## 七、三个明天就能开始的行动

如果你读完了这个系列，只想先做一点点，按这个顺序：

### 动作一：写一份 AGENTS.md（30 分钟）

技术栈、规约索引、加载指引，三块就够。不用一次写完，300 行以内把框架搭起来。让 AI 帮你生成初版（第 3 篇文末有分步指令，第 2 篇有一键指令），你 review 修正。放到项目根目录，下次用 AI 写代码时看看效果有没有变化。

### 动作二：建一个 rules/ 目录，先写两条规则（15 分钟）

选两条你在团队里反复强调、却总有人违反的规则。比如"数据库操作要加事务""接口返回要统一格式"。写进 `prompt-rules.md` 的 Always 层。

两条就够。关键是这两条写清楚之后，AI 不会再犯同样的错。

### 动作三：找一个卡壳场景，用六步工作流走一遍（45 分钟）

找一个你最近用 AI 写了一两轮、反复修改才搞定的任务。按六步重走一遍：拆需求、探代码、出方案、写代码、跑验证。

对比一下：有规范和凭感觉，效率差多少。

## 八、全系列收尾

回到第 1 篇那个问题：AI 写代码只要十几秒，你收尾要两个小时。

八篇下来，答案其实只有一句话：**你没写下来的规矩，AI 永远不知道。**

理解层解决"AI 不知道项目长什么样"，约束层解决"AI 不知道该守什么规矩"，验证层解决"你不知道 AI 有没有守规矩"，六步工作流解决"这些资产什么时候被用上"，归档闭环解决"这次踩的坑下次还踩不踩"。

我自己的观察是，这套体系的难点从来不在技术，在于你愿不愿意把脑子里那些"理所当然"的东西写下来。推广推不动，往往卡在这一步：都知道该怎么干活，就是没人愿意把它落成文字。

整套体系不是一次建成的。理解层、约束层、验证层都是活的：项目变了，约束跟着变；AI 犯了新错，规则加一条。它长出来的过程，就是团队把隐性经验显性化的过程。

最后一条，也是最容易被忽略的一条：**这套东西不需要团队批准才能开始。** 你在自己的开发环境里用，产出是代码本身。等效率差攒到肉眼可见，推广这件事会自己发生。

## 九、可带走的三件事

1. **三步渐进，不搞全员培训**：CR 时用结果引起好奇，拉一个人一起写 rules 让他体会爽感，攒到 5-8 条再提交仓库。
2. **用规范有效条数衡量，不用代码行数**：能被 AI 遵守、能被 CI 验证、能减少返工的规则才算数。从没触发过的规则删掉。
3. **AI 不守规矩时先怀疑自己**：描述模不模糊、文件加没加载、上下文装不装得下。排查顺序反过来，你会一直在换模型。

> 系列完。八篇的配套资产（一键指令、分步指令、规则骨架、SKILL 模板、排查表）都在各篇文末，可直接复制使用。


这个系列只讲一件事：怎么用工程化的方法，把 AI 编程从"碰运气"变成"可预期"。

从一个人到全团队：推广路径 + 9 个排查项

前七篇讲技术，决定成败的却是人的问题：团队里只有你在用。推广不用说服，CR 时用结果引好奇，拉一个人一起写规则，攒够 5-8 条再进仓库。衡量别用代码行数，用能拦住问题的规则条数。

职业发展

开发工具

后端

AI编程工程化落地指南：从个人效率到团队协作的系统方法。通过AGENTS.md与rules/资产体系、三层约束机制、六步工作流，将AI辅助开发从"碰运气"转为"可预期"。文中提供渐进式推广策略（CR自然引导、结对编写规则）、规范嫁接技巧及9个高频问题排查清单，强调用"规范有效条数"替代代码行数衡量成效。附赠30分钟启动方案：建立AGENTS.md、两条基础规则、六步流程试跑。

数据库

AI编程

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

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

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

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

社区新版编辑器体验调研

AI编程工程化落地指南：从个人效率到团队协作的系统方法。通过AGENTS.md与rules/资产体系、三层约束机制、六步工作流，将AI辅助开发从"碰运气"转为"可预期"。文中提供渐进式推广策略（CR自然引导、结对编写规则）、规范嫁接技巧及9个高频问题排查清单，强调用"规范有效条数"替代代码行数衡量成效。附赠30分钟启动...

从一个人到全团队：推广路径 + 9 个排查项-腾讯云开发者社区-腾讯云

从一个人到全团队：推广路径 + 9 个排查项

从一个人到全团队：推广路径 + 9 个排查项

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐