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

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

---

## 一、资产建好了，但它们不会自己动

前面五篇建了三样东西：理解层的五份资产（三张图、两份清单、AGENTS.md）、约束层的三层规则、验证层的基线加 CI 门禁。

这三样有个共同特点：**它们是静态配置**。AGENTS.md 放在仓库根目录，规则写在 rules/ 目录，测试基线嵌在 CI 里。它们就待在那里，不会自己跑起来。

你下次接个需求，跟 AI 说"帮我加个搜索接口"，如果只有这些资产，会发生什么？AI 会读到 AGENTS.md，知道项目结构；会读到规则，知道要加事务、要用统一响应体。然后它直接开始写代码。

结果比完全没有资产好很多，但仍然不稳定：需求里没写明的地方它照样猜，改动会影响哪些文件它未必扫全，方案合不合理没人审，做完了有没有改坏只有你自己去查。

**资产要好使，需要一条流水线把它们串起来：在正确的时点，加载正确的资产，产出正确的中间物。** 这就是六步工作流。

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

## 二、六步全景

| 步骤 | 命令 | 做什么 | 调用哪层资产 | 产出物 |
|------|------|--------|------------|--------|
| ① 拆需求 | `/decompose-prd` | 自然语言需求 → AI 可执行的结构化任务 | 理解层 | AI 理解态 PRD |
| ② 探代码 | `openspec explore` | 扫描代码库，做影响面分析 | 理解层 | 分析报告 |
| ③ 出方案 | `/opsx:propose` | 生成方案，约束层自动校验 | 约束层 | proposal + spec + design + tasks |
| ④ 写代码 | `/opsx:apply` | 按任务清单逐条编码 | 约束层 | 源代码变更 |
| ⑤ 验质量 | `openspec verify` | 基线比对 + CI 三道门禁 | 验证层 | 验证报告 |
| ⑥ 做归档 | `/opsx:archive` | 规范并入主线，经验沉淀 | 验证层→约束层 | 归档摘要 + 更新后的规范 |

命令速查：

```bash
# ① 分解 PRD 为 AI 理解态
/decompose-prd <prd文件路径>

# ② 探索分析现有代码影响面
openspec explore <理解态prd标识> --output <输出路径>

# ③ 创建变更提案
/opsx:propose <变更名称>

# ④ 实施代码变更
/opsx:apply <变更名称>

# ⑤ 验证规范与代码一致性
openspec verify <变更名称>

# ⑥ 归档并合并规范
/opsx:archive <变更名称>
```

六步不是六个并列的动作，是一条单向流水线：每一步的输入是上一步的产出。跳过任何一步，后面都会付出代价。下面逐个拆。

## 三、① decompose-prd：先解决需求本身的模糊

**为什么要有这一步？**

第 1 篇说过 AI 编码的第一个问题是信息缺失，但信息缺失不只是"AI 没看到代码"。更常见、也更麻烦的是：**需求本身就是模糊的**。

产品经理写「需求池列表加一个搜索接口」。这句话里藏着一堆没说的事：搜哪些字段？模糊匹配还是精确匹配？空关键词返回什么？排序规则？分页默认值？软删除的数据要不要排除？

PRD 不会写这些。你不去问，AI 就用默认值猜。猜错了就是 bug，而且这种 bug 往往要到验收时才被发现。

decompose-prd 的价值在于：**它逼你在写代码之前，把模糊的需求变成精确的任务定义。**

**它产出什么？**

一份"AI 理解态 PRD"，包含五块：

- 需求目标与范围
- 领域概念定义（这个需求涉及的实体、术语、字段）
- 接口契约（入参、出参、错误码）
- 业务规则与边界条件
- 验收标准（Given-When-Then 风格）

**你要 review 什么？**

三件事：

1. **领域概念准不准。** AI 提取的业务术语跟你们团队的理解一致吗？这一步错了，后面全错。
2. **边界条件全不全。** 空值、超长、并发、幂等，AI 经常漏。你按自己项目的经验补。
3. **验收标准能不能测。** 每条标准都得能写成测试用例，写不成用例的标准等于没写。

**常见坑**：复杂 PRD 生成的文档可能超过 500 行，后续步骤上下文装不下。PRD 太复杂就先拆成几个子需求，分别 decompose。

## 四、② explore：让 AI 自己找全影响面

**做什么？**

AI 启动一个只读的探索代理，拿着上一步的理解态 PRD，扫描整个代码库，回答一个问题：这个需求要动哪些地方？

它读 AGENTS.md 定位规矩，读三张图建立结构认知，读两份清单知道有哪些接口和数据模型可以复用。产出四样东西：匹配度分析、变更清单（要增删改的文件列表）、依赖关系、风险提示。

**为什么非要有这一步？**

没有 explore，你只能手动给 AI 贴几个文件。它基于这几个文件做判断，文件之外的世界一无所知。这就是管中窥豹。

管中窥豹最典型的后果就是第 1 篇那个场景：改了一个 Service 方法，编译通过，三个调用它的 Controller 当场挂掉。有了 explore，AI 是全量扫描，调用方一个都跑不掉。

**你要确认什么？**

1. **变更范围合不合理。** AI 说要改 20 个文件，你扫一眼，是不是真的都需要改。
2. **有没有遗漏的依赖。** AI 可能没发现隐式依赖，比如某个字段被反射调用，或者被下游服务通过 JSON 反序列化消费。
3. **风险提示准不准。** 它标的高风险点，是不是真的高风险。

**常见坑**：大项目扫一遍耗时很长。超过 10 万行的项目，先缩小探索范围，只让它扫相关模块的目录。

## 五、③ propose：约束层第一次介入，也是人最该介入的一步

**做什么？**

基于理解态 PRD 和影响面报告，AI 生成完整的变更方案，产出四个文件：

| 文件 | 内容 |
|------|------|
| `proposal.md` | 变更概述：为什么改、改什么、预期效果 |
| `specs/*.spec.md` | 增量规范：本次变更引入的新规范 |
| `design.md` | 技术设计：架构选择、接口定义、数据模型、关键逻辑 |
| `tasks.md` | 原子任务清单：按依赖顺序排列 |

**约束层怎么介入？**

生成方案时会自动加载 rules/ 下的规范做校验：`api-spec.md` 查接口格式、`db-spec.md` 查表设计、`code-style-spec.md` 查命名、`prompt-rules.md` 查有没有踩 Never 层红线。违反规范的地方，AI 会在 proposal.md 里标注冲突点，等你决策。

**这是六步里最需要人工介入的一步。** 方案行不行，你拍板。重点看三件事：

1. **接口契约对不对。** 入参、出参、错误码。这一步锁定的契约，后面两步都基于它，改一次成本翻倍。
2. **任务拆解合不合理。** tasks.md 的执行顺序要"依赖在先"：先建表，再写 DAO，再写 Service，最后写 Controller。顺序错了，apply 阶段会卡住。
3. **有没有过度设计。** AI 为了“完整”，容易引入不必要的抽象层，明明一个方法能解决，它给你整出个策略模式。看到不认识的抽象，问一句"这个能去掉吗"。

**常见坑**：design.md 可能写到 800 行以上，apply 阶段上下文不够用。设计复杂就把它拆成多个子文档，apply 时按需加载。

## 六、④ apply：分批、断点、逐批提交

**做什么？**

按 tasks.md 逐条实施代码变更。约束层在这一步实时生效，三层规则各有各的作用方式：

| 规则层级 | 生效方式 | 实际表现 |
|---------|---------|---------|
| Always | AI 自动执行，不询问 | 自动给 Service 方法加 `@Transactional` |
| Ask First | AI 停下来等你确认 | 需要改表结构时，暂停请求确认 |
| Never | AI 直接拒绝执行 | 不会在代码里硬编码密钥 |

**三个控制点**

第一，**分批执行**。一次只给 AI 1-3 个文件的任务，生成完立刻验证。一次改 10 个文件，出问题你根本不知道错在哪。第 7 篇的批量修改场景会展开讲分批策略。

第二，**断点续做**。apply 支持中断后从上次的位置继续。某批出错，修正后重跑该批即可，不用从头来。

第三，**逐批提交**。每批验证通过立刻 `git commit`，不要攒到最后一起提交。这一条最容易被忽略，也最能救命：分了批但不提交，等于没分批，回滚的时候还是一整坨。

**常见坑**：AI 会在 apply 阶段"顺手优化"不该碰的代码。在 prompt 里明确写出不可触碰区域：哪些文件不许动、哪些方法不许改。这条比告诉它"要做什么"更管用，第 4 篇讲过同样的道理。

## 七、⑤ verify：只讲这一步的位置

验证机制（行为基线、CI 三道门禁、测试通过不等于代码正确）在第 5 篇讲过了，这里只说它在流程里的位置。

**输入**：apply 产出的源代码变更。**输出**：验证报告。**调用**：验证层。

流程是五步：基线比对 → 编译检查 → 单元测试 → 规范检查 → 人工验收。

**你要做的三件事**（第 5 篇展开过，这里只列）：接口签名跟 propose 阶段锁定的契约一不一致、业务规则有没有实现完整、`git diff` 里有没有非预期改动。

这里补第 5 篇没说的一点：**verify 失败之后，回退到哪一步？**

多数人的反应是让 AI 改代码。但按流水线的逻辑，该先判断失败属于哪一类：

- 实现没写对 → 回 ④，让 AI 重做这一批
- 方案本身有问题（比如接口设计错了）→ 回 ③，改 proposal 重来
- 需求理解错了 → 回 ①，重新拆需求

在哪一步出的错，就回哪一步修。一律回 ④ 改代码，是最常见也最费时的错误做法。方案错了，代码改一百遍也是错的。

## 八、⑥ archive：整套体系"越用越强"的关键

**做什么？**

验证通过后，三件事：本次变更的增量规范并入主线规范目录、变更目录从 changes/ 移到 archive/、生成归档摘要。

归档摘要长这样：

```markdown
# 归档摘要 — feature-xxx

## 基本信息
- 归档时间：2026-xx-xx
- 变更类型：新功能
- 关联提交：7f3d2a1

## 变更范围
- 新增能力：（列出本次新增的能力点）
- 新增文件：N 个 | 修改文件：M 个

## 验证结果
- 单元测试：x/x 通过
- 代码审查：无阻断性问题

## 已知遗留项
- （本次没做完、下次要补的事）
```

**真正的价值在闭环**

archive 的核心不是存档，是把这一轮踩到的坑变成下一轮的护栏：

```
本次开发中发现的问题
    ↓
archive 时记录到归档摘要
    ↓
提炼为新规则 → 追加到 rules/ 对应文件
    ↓
下次 AI 开发时自动加载新规则
    ↓
同样的问题不再发生
```

举几个典型的沉淀场景：

- AI 在 apply 阶段犯了个错 → 想想"rules/ 里多写一条什么能避免它" → 补上
- verify 发现个边界条件没覆盖 → 在 `domain-spec.md` 补这条业务规则
- propose 阶段方案过度设计 → 在 Never 层追加"禁止引入不必要的抽象层"

**这一步是六步里唯一让体系变强的步骤。** 前五步是"把事做对"，这一步是"让下一次更容易做对"。跳过它，等于每次都从零开始，AI 上次犯的错，这次还会犯。

**你要做什么？**

只有一件事，但必须人来做：**回顾本次开发中发现的规则缺口，决定哪些值得沉淀成新规则。**

我的做法是在归档摘要里单独开一段“规则缺口”，跟“已知遗留项”并列。遗留项记的是代码里没做完的事，规则缺口记的是这次暴露出来、下次必须拦住的事。分开记，下次归档时一眼能看出这次沉淀了几条。

判断标准跟第 4 篇写规则时一样：这个坑下次还会踩吗？会，就写成规则；一次性笔误，不写。规则库里塞满从没触发过的规则，跟没有规则是同一个效果。

## 九、六步与 SDD 四步法

如果你读过早期的 SDD 资料，可能知道"四步法"：Specify → Plan → Implement → Validate。六步是四步的精细化展开：

| SDD 四步法 | 六步工作流 | 说明 |
|---|---|---|
| Specify | ① decompose-prd + ② explore | 拆需求加探查代码，合起来才是完整的"写规范" |
| Plan | ③ propose | 生成方案和任务清单 |
| Implement | ④ apply | 按清单执行编码 |
| Validate | ⑤ verify | 基线测试加 CI |
| — | ⑥ archive | 四步法没有的沉淀闭环 |

多出来的两步正是实践里最需要的补充：**explore 解决"AI 不懂项目"，archive 解决"经验不沉淀"**。四步法假设规范已经写好、经验会自动积累，这两个假设在真实项目里都不成立。

## 十、可带走的三件事

1. **六步是单向流水线，跳过任何一步后面都要还**：不拆需求就得靠猜，不探代码就会漏影响面，不审方案就得改代码。改代码的成本是改方案的十倍。
2. **在哪一步出的错，就回哪一步修**：verify 失败先判断是实现问题、方案问题还是需求问题。一律回 apply 改代码是最费时的做法。
3. **archive 是唯一让体系变强的一步**：前五步把事做对，这一步让下一次更容易做对。每次归档时问一句"这个坑下次还会踩吗"，会就写成规则。

## 下一篇预告

**第 7 篇：《批量修改与跨服务改动：两个真实场景走一遍》**

六步工作流在简单场景下好理解，在复杂场景下才见真章。下一篇用两个场景把前六篇的内容全部串起来跑一遍：一个是"给几十个文件统一加注解"的批量修改，核心挑战是漏改；一个是"一次需求横跨三个服务"的跨服务改动，核心挑战是接口契约。

前面讲的所有原则，在那两个场景里会一一出场。


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

从一句话需求到归档：六步工作流的完整链路

前五篇建好的资产，躺在仓库里不会自己动。这篇把它们串成六步流水线：拆需求、探代码、出方案、写代码、验质量、做归档。两处最容易做丢：出方案那步得人拍板，归档那步决定这套体系是越用越强还是从头再来。

人工智能

开发工具

后端

AI编程工程化实践六步流水线：拆需求、探代码、出方案、写代码、验质量、做归档。核心在于每步产物驱动下一步，强调需求分解精确化、代码影响面全量扫描、分层规则自动校验，以及"在哪步出错回哪步修"的精准修复策略。通过归档沉淀规则缺口实现体系持续进化，将AI编程从碰运气变为可预期。

单元测试

代码解释

AI编程

JSON

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

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

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

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

社区新版编辑器体验调研

从一句话需求到归档：六步工作流的完整链路-腾讯云开发者社区-腾讯云

从一句话需求到归档：六步工作流的完整链路

从一句话需求到归档：六步工作流的完整链路

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐