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

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

---

## 一、看见了，不等于听话

上一篇我们把五份资产建起来了：三张图、两份清单、一份 AGENTS.md。AI 现在知道你的项目长什么样，知道有哪些接口能调，知道规矩写在 rules/ 的哪个文件里。

但"知道规矩在哪"和"守规矩"是两件事。它读完了接口规范，写新方法时照样可能自创一种返回格式；它看到了分层结构，改代码时照样可能把业务逻辑塞进 Controller。

原因不复杂：**上下文里有一条信息，不等于这条信息会被优先采纳**。AI 生成代码时，影响它下一token的因素有一堆：你的规则、训练数据里的常见写法、当前文件的既有风格、它自己"觉得更优雅"的方案。规则只是其中之一，没有优先级。

约束层要解决的就是这个：让规矩从"可读的一份文档"变成"必须遵守的指令"。

## 二、规范不是没写，是没被执行

在讲怎么做之前，先说一个我反复观察到的现象。

每个团队都有规范。命名规范、异常处理规范、事务使用规范、日志规范，写得很全，有的还配了示例代码。然后呢？躺在 wiki 里，藏在共享盘某个 2021 年的目录里，或者只存在于几个老工程师的脑子里。

新人入职，老人跟他说"我们这边日志要带 traceId"，他记下了，写两天就忘了。你 review 的时候看见了，提一句，他改了。下周又忘。

这不是人的问题。人会忘，这是常识。真正的症结在于：**规范的执行成本全压在"记得住"和"自觉"上，没有任何机制兜底**。规范有没有被遵守，只有 review 那一刻才知道，而 review 覆盖不到每一行代码。

AI 编码时代把这件事往前推了一步。规范第一次可以不是“人读的文档”，而是“直接喂给模型的约束指令”。你把规范写成文件，放在项目里，AI 每次写代码都先读它。人读规范会漏，AI 读规范不会漏；人记规范会忘，AI 记规范不会忘，因为它每轮对话都重新加载一遍。

这是组织级规范第一次真正变得可控。代价是：你得把规范写成它能执行的形式。

## 三、三层约束：分级依据是你的把握程度

`rules/prompt-rules.md` 是这个文件的核心，所有项目级的行为规则写在这里，分成三层：

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

**分级依据不是规则有多重要，是你对这条规则有多少把握。**

这一点很关键，容易理解错：分级看的不是规则的重要性。把最重要的规则全塞进 Never 层，AI 动不动就拒绝执行，你只能一条条放行，最后那层形同虚设。

正确的分法是问自己一个问题：**这条规则，你有多确定？**

- **Always 层**：你有 100% 把握，不需要 AI 每次来问。比如"所有数据库写操作必须加事务"。这条规则没有例外场景，让 AI 每次停下来问你"要不要加事务"，纯属浪费时间。
- **Ask First 层**：你大概率知道不该做，但确实存在需要做的场合。比如"修改数据库表结构"。多数任务不该改表，但加需求时就是得加字段。这种事让 AI 先问，你点个头就行。
- **Never 层**：你宁愿 AI 报错，也不愿它越界。比如“硬编码密钥”：没有任何场景需要它把 token 写死在代码里，一次都不该发生。

一份能用的骨架长这样：

```markdown
# rules/prompt-rules.md —— AI 行为约束

## Always（必须执行，不允许跳过）
- 日志必须携带 traceId，格式：log.info("[{}] 操作描述", traceId)
- 数据库写操作必须使用事务注解，指定 rollbackFor = Exception.class
- 使用强类型参数，禁止使用 Map 作为接口入参
- 生成代码后先跑一次编译，不通过不许交付

## Ask First（先问再动手）
- 修改数据库表结构（新增字段、修改字段类型）必须先确认
- 引入新的第三方依赖库必须先确认
- 修改已有接口的出参结构（字段重命名、删除字段）必须先确认

## Never（绝对禁止）
- 禁止将用户输入直接拼接到 SQL 语句中
- 禁止在循环内执行数据库查询
- 禁止在代码中硬编码密钥、密码、Token
- 禁止自行发明新的响应格式
```

Always 层这几条，每一条背后都是一个踩过的坑。这个文件是长出来的，不是设计出来的：AI 犯一次错，你补一条，补完它就不犯了。

### rules/ 目录怎么拆

`prompt-rules.md` 是总纲，管 AI 的行为。具体领域的规范拆成独立文件，每个控制在 200-500 行：

```text
rules/
├── code-style-spec.md     ← 命名规范 + 注解规范 + 禁止项
├── api-spec.md            ← 统一响应体 + 分页格式 + 错误码
├── db-spec.md             ← 表设计规范 + 索引策略 + SQL 禁令
├── domain-spec.md         ← 领域术语表 + 状态机定义 + 业务规则
└── prompt-rules.md        ← 以上三层约束的总纲文件
```

这么拆有两个好处。

一是按需加载。改接口的任务读 `api-spec.md` 就够了，不必把建表规范也塞进上下文。二是新人上手快。新人入职第一天读完 `rules/` 就能让 AI 按团队标准干活，比看一个月代码自己领悟高效得多。

拆的时候注意一条：`domain-spec.md` 容易被忽略，但它是 AI 犯错率最高的地方。你的项目里“需求”到底是 `Issue` 还是 `Requirement`、“状态”有哪几个值、状态之间怎么流转，这些不写清楚，AI 生成的业务代码一定跟你的领域模型对不上。

## 四、一条规则的及格线

第 2 篇提过一个判断标准，这里值得展开：**每条规则写完，问一句"AI 或 CI 能自动判断它有没有被遵守吗？"**

能判断，才算规则；判断不了，那只是愿望。

对比几组：

| 愿望 | 规则 |
|------|------|
| 接口返回要规范 | 所有接口必须返回 `ApiResponse<T>` |
| 日志要打全 | 日志必须携带 traceId，格式 `log.info("[{}] 操作描述", traceId)` |
| 注意性能 | 禁止在循环内执行数据库查询 |
| 代码要简洁 | 单个方法不超过 80 行 |

左边那列写进文件等于没写。AI 读完"接口返回要规范"，它不知道你指的规范是什么，只能按训练数据里最常见的写法来。然后你发现它自创了一种返回体。

右边那列是可判定的：有没有用 `ApiResponse<T>`，扫一眼就知道；循环里有没有查库，静态检查一扫就知道。写成这样，规则才有牙齿。

还有一条容易被忽略：**规则里必须给反例**。只写"日志必须携带 traceId"，AI 可能写成 `log.info("[{}]", traceId)`，格式对了但没内容。把完整格式写进规则，它照抄就行了。

## 五、规则不是越多越好

新手最容易犯的第二个错：一口气写五十条规则。

结果有两个。一是 AI 寸步难行，五十条规则占满了上下文，它把注意力分给了规则，反而写不好代码。二是你自己维护不动，五十条规则里，三个月后你根本想不起来哪条还在生效。

判断一条规则要不要进约束层，标准是：**这个问题会在多个场景下反复出现吗？**

会，才写进 rules/。只是这一次任务的特殊要求，写在本次对话的 prompt 里就够了，不要污染长期规则。

还有一条更狠的：**如果某条规则写了，但 AI 从来不违反它，说明这条规则不值得写**。规则的价值跟 AI 的违反频率成正比。你可以隔段时间扫一遍 rules/ 目录，把那些从来没触发过的删掉。

## 六、静态规则之外，还有动态约束

rules/ 是项目级的默认规则，每次对话都加载。但具体到某一次任务，还有特殊要求："这次只改 Controller，不要动 Service"、"这个接口只新增，不许删已有的"。

这类约束有两种载体。

**第一种，SKILL.md。** 把一类高频任务的标准流程写成文件，AI 下次遇到同类任务直接加载它当行为模板。比如"生成 REST 接口"这个动作，从查领域术语到设计签名到生成三层代码，每一步的输入输出都定死：

```markdown
# Skill：生成 REST 接口

## 触发条件
用户提出"新增一个查询接口""加一个增删改查"等需求

## 前置约束（必须加载以下 rules）
- prompt-rules.md：行为约束
- api-spec.md：接口规范
- domain-spec.md：领域术语

## 执行步骤
1. 确认领域术语：从 domain-spec.md 查找涉及的实体和字段
2. 设计接口签名：按 api-spec.md 的统一响应格式设计入参/出参
3. 生成 Controller：遵循 api-spec.md 的路径和参数规范
4. 生成 Service：遵循 code-style-spec.md 的编写规范、日志、事务约束
5. 生成 DTO：遵循 code-style-spec.md 的命名规范
6. 输出检查清单：列出生成的文件路径

## 禁止操作
- 禁止自行发明新的响应格式
- 禁止跳过事务注解
- 禁止在 Controller 中直接返回 Entity
```

SKILL.md 的价值不在"省事"，在**一致性**。同一个任务让 AI 做十次，十次的路径是一样的，产出结构也是一样的。没有它，AI 每次都要临场决定"这次要不要先查术语表"，决定得对不对全看运气。

**第二种，本次对话的 prompt。** 最灵活，也最常用。一个好的任务 prompt 要包含三样东西：

```
请在 ItemController 中新增 GET /api/items/search 接口。

约束：
1. 入参 keyword（必填，String，需 @NotBlank 和 @Size(max=100) 校验）
2. 入参 pageNum（选填，int，默认 1）；pageSize（选填，int，默认 20）
3. 出参必须使用统一响应体 PageResult<ItemDTO>
4. 禁止修改 ItemService 已有的 getItemList() 方法（只能新增 searchItems 方法）
5. 搜索结果必须排除 is_deleted=1 的记录
6. 结果必须按 update_time 倒序排列
7. 必须遵守 rules/api-spec.md 的接口格式规范
```

1-3 是接口签名，4-5 是硬约束，6-7 是业务规则和已有规范引用。

注意第 4 条。这种"只能新增、不许改已有"的约束，看起来啰嗦，实际上是最管用的一类：AI 的想象力比你丰富，你不明确禁止，它可能顺手就把 `getItemList()` 重构了。写清楚"不许碰什么"，比写清楚"要做什么"更能控制住产出的范围。

## 七、AI 不守规矩时，先怀疑自己

最后说一条排查原则，比前面所有内容都常用。

AI 违反了你写的规则，多数人的第一反应是"这模型不行"或者"AI 就是不听话"。我的经验是反过来查：**先假设是我没说清楚。**

最常见的三种情况：

1. **规则描述太模糊**。"接口返回要规范"对 AI 等于没写。改写成具体的类型名。
2. **规则文件没被加载**。你写了 `rules/db-spec.md`，但 AGENTS.md 的加载指引表里，"涉及数据库变更"这一行没有指向它。AI 根本没读。这也是第 3 篇那张加载指引表存在的意义。
3. **上下文装不下**。你一次给了二十个文件，规则被挤出了有效上下文。减少单次给 AI 的文件数，或者让它在任务开始时只读规则、读完了再读代码。

三种都是你的问题，不是模型的问题。而且三种都好修。

更详细的排查清单（9 项）我放在最后一篇，这篇先记住这条原则就够。

## 八、可带走的三件事

1. **三层按把握程度分，不按重要程度分**：100% 确定 → Always；八成不该做 → Ask First；碰都不许碰 → Never。把重要规则全塞 Never，那层很快就废。
2. **规则必须可判定，且给反例**："接口返回要规范"是愿望，"必须返回 `ApiResponse<T>`"才是规则。规则的价值跟 AI 的违反频率成正比，从没触发过的规则删掉。
3. **"不许碰什么"比"要做什么"更管用**：AI 的想象力比你想的丰富，明确列出不可触碰的区域，比描述期望产出更能控制住改动范围。

## 下一篇预告

**第 5 篇：《让 AI 可信：行为基线测试 + CI 三道门禁》**

规则立好了，AI 会照着做。但你怎么知道它真的照做了？规则写在文件里，AI 说"我加了事务"，你信不信？

下一篇讲验证层：怎么用改动前的基线快照，把"AI 有没有改坏东西"从主观判断变成客观对比；以及 CI 上那三道门禁怎么配，才能让 AI 生成的代码和人写的代码过同一道标准。


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

让 AI 听话：Always / Ask / Never 三层约束

规则写进文件不等于 AI 会照做。三层约束按把握程度分级，每条必须可判定、给反例，从没触发过的就删掉。

人工智能

编程语言

开发工具

AI编程工程化实践：建立三层约束体系（Always/AskFirst/Never），按把握程度分级规则而非重要程度。规则必须可判定且含反例，高频问题才写入rules/目录。明确"不许碰什么"比"要做什么"更有效。AI违规先自查规则描述、文件加载、上下文容量三个环节。

代码解释

数据库

AI编程

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

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

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

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

社区新版编辑器体验调研

让 AI 听话：Always / Ask / Never 三层约束-腾讯云开发者社区-腾讯云

让 AI 听话：Always / Ask / Never 三层约束

让 AI 听话：Always / Ask / Never 三层约束

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐