2026-04-22 从Vibe-Coding到AI全流程工程化

同一个需求，三种做法，完全不同的结果。这篇文章分享我们终端团队从”让 AI 写代码”到”让 AI 参与工程全流程”的实践路径。

写在前面

我们是一个终端团队，工作区下面挂了多个组件仓——基础层、业务层、调试工具，宿主仓负责装配。

过去一年，我们逐步把 AI 编程助手接入了开发流程。不是简单让 AI 写代码，而是从需求抓取到代码归档，每个环节都有 AI 参与。

这篇文章会讲四件事：

三种模式有什么不同——纯人肉 / Vibe Coding / AI 全流程工程化
为什么 Vibe Coding 不够用——我们踩过的核心问题
全流程工程化具体怎么做——每个环节的工具、规则和产物
怎么一步步走到这里——学习路线和经验教训

一、三种模式：同一个需求，三种命运

产品在钉钉丢过来一个 PRD：「换肤配置」——用户可以为游戏选择不同的皮肤主题。需求涉及：UI 换肤逻辑、主题资源包下载、配置后台对接、异常降级。跨了宿主仓和业务组件仓。

同样的需求，三种模式下会发生什么？

模式定义

模式	一句话	AI 的角色
纯人肉	从头到尾自己干	没有 AI
Vibe Coding	让 AI 写代码，我指挥	打字员，你说它写
AI 全流程工程化	AI 参与每个环节，受规则约束	全流程协作者，有边界有规矩

逐环节对比

1. 需求获取

	纯人肉	Vibe Coding	全流程工程化
PRD 获取	手动阅读，脑子记	复制文字粘贴给 AI	自动截图抓取，AI 可读
API 获取	手动抄字段	复制粘贴	自动抓取，结构化 JSON
原型图	截图存本地	AI 看不到	合并截图，AI 可读
信息完整度	依赖人的记忆力	只有文字，丢图	完整保留

2. 需求评审

	纯人肉	Vibe Coding	全流程工程化
谁在审	开发自己审	没人审	AI 先审，结构化评审
什么时候发现问题	做到一半	测试阶段	编码之前
返工成本	中等	最高（写完重来）	最低（提前拦截）

3. 方案设计

	纯人肉	Vibe Coding	全流程工程化
有没有方案文档	在脑子里	没有	有，结构化产物
AI 什么时候介入	不介入	直接写代码	先设计，再实现
方向偏了什么时候发现	写到一半	写完	动手之前

4. 编码实现

	纯人肉	Vibe Coding	全流程工程化
代码产出速度	慢	快	快
是否符合项目规范	靠人记	经常不符合	规则约束，首次即对
修规范问题的成本	无（自己写的）	高（可能和写代码一样久）	低（规则前置约束）
净效率	基线	看起来快，实际未必	最高

5. 代码审查

	纯人肉	Vibe Coding	全流程工程化
审查覆盖面	看什么算什么	表面风格	领域专项 + 项目约束
能否发现性能问题	靠经验	几乎不能	内置检查项
结果可执行性	模糊	模糊	带严重级别，明确动作

6. 工程规范

	纯人肉	Vibe Coding	全流程工程化
分支名/Commit 规范	靠自觉	AI 不知道规范	规则约束，自动合规
组件联调	手动重复操作	AI 不会	一个命令自动化

7. 变更归档

	纯人肉	Vibe Coding	全流程工程化
方案文档	无	无	有，结构化归档
设计取舍记录	在脑子里/会议纪要	无	design.md
新人接手成本	高	高	低

同一个需求，从收到 PRD 到上线

纯人肉：5 天

Day 1 看 PRD，脑子想方案 → Day 2-3 写代码 → Day 4 做到一半发现 PRD 没写异常降级，停下来等产品 → Day 5 补完逻辑，提交 MR。没有方案文档，半年后新人问「为什么这么设计」，没人答得上来。

Vibe Coding：看起来 2 天，实际 4 天

Day 1 把 PRD 文字贴给 AI，产出很快 → Day 2 发现 AI 把代码写错了仓，用了错误的技术栈，手动改 → Day 3 测试发现异常降级没做，补代码 → Day 4 AI review 说「代码不错」，但测试提了 5 个 bug，逐个修。没有方案文档，没有需求评审记录。

AI 全流程工程化：3 天（含前期准备）

Day 1 上午抓 PRD 和 API，AI 评审发现 3 个 P0 阻塞项 → Day 1 下午拿评审报告找产品补需求，同时走变更流程：proposal → design → tasks → Day 2 按任务清单编码，AI 在规则约束下首次即对仓、对技术栈 → Day 3 AI 审查发现 1 个严重项，修完提交 MR，归档变更。3 天完成，产出不仅是一段代码，还有需求评审报告、方案文档、任务清单、代码审查记录、能力基线。

二、为什么 Vibe Coding 不够用

看到上面的对比，你可能会问：Vibe Coding 不是挺快的吗？为什么还要搞全流程工程化？

我们不是一开始就做全流程工程化的。路径是这样的：

1	纯人肉 → 觉得效率低 → 引入 AI → Vibe Coding → 发现问题 → 全流程工程化

从纯人肉到 Vibe Coding 的动力很简单：AI 写代码快，这谁都知道。但从 Vibe Coding 到全流程工程化，原因更值得说：

1. AI 写得快但改得慢

它不知道团队的规范——用哪个网络库、解析库、埋点 SDK。产出越多，修正成本越高。你花了和 AI 写代码一样长的时间，在修这些”风格不对”的问题。

2. AI 不会质疑需求

你让它做，它就做。PRD 没写异常降级？它不管。交互细节缺失？它按自己理解补。做到一半发现方向偏了，浪费更大。

3. AI 没有上下文

PRD 在钉钉，API 在 ShowDoc，设计稿在 Figma——这些都在外部系统里，AI 看不到。写出来的代码凭想象，复制粘贴又丢图丢结构。

4. AI 审查自己写的代码是无效的

让 AI review 自己写的代码，它当然觉得不错。通用 review 说”这个函数有点长”——帮助不大。真正的问题没人发现：启动链路阻塞、UI 线程卡顿、网络层不合规。

5. 没有文档的代码就是技术债

AI 写的代码尤其如此——因为没人完整理解它。半年后新人问「为什么这么设计」，git log 里只有一堆看不出意图的 commit。

全流程工程化的本质，不是给 AI 加更多限制，而是把 AI 从”打字员”升级为”带规矩的协作者”：

它知道该改哪个仓（归属路由）
它知道该用什么技术栈（规则约束）
它知道需求有没有漏洞（PRD 评审）
它知道代码有没有隐患（领域化审查）
它知道做完之后要留下什么（变更归档）

三、全流程工程化：具体怎么做

1. 工具选型：三把刀，但只磨一块磨刀石

团队里 Cursor、Claude Code、Kiro 都在用，不强求统一工具，但有一个原则必须统一：AI 规则只维护一份，所有工具共享。

.cursor/rules/*.mdc          ←  核心规则定义（唯一真实来源）
       │
       ├──镜像──→  .kiro/steering/*.md      （Kiro 消费）
       │
       └──分流──→  CLAUDE.md                （Claude Code 消费）

规则写在 .cursor/rules/，这是唯一的”磨刀石”。.kiro/steering/ 是镜像给 Kiro 用的，CLAUDE.md 是分流入口告诉 Claude Code 遇到什么问题去看哪个规则。

早期各子仓自己带了 .cursorrules、.kiro/、.trae/，结果不同工具看到的规则不一致，AI 行为不可预测。后来我们专门做了一个变更把子仓的 AI 配置全部清理掉，统一收敛到工作区根目录。教训：子仓零配置，根目录统一定义。

2. 多仓架构：让 AI 知道”这事不归你管”

AI 助手最常犯的错：你让它修一个属于组件仓的 bug，它直接在宿主仓里加了个 workaround。这在多仓架构里是灾难。

我们给 AI 写了一个归属判断路由器，而不是把所有规则扁平堆在一起：

任务进来
  ├── 宿主仓的事？        → 看宿主仓规则
  ├── 基础层的事？        → 看基础层规则
  ├── 业务层的事？        → 看业务层规则
  ├── 调试工具的事？      → 看调试工具规则
  └── 共享基线            → 始终生效

AI 在动手之前会先走这个路由，判断该改哪里。越界改仓的情况大幅减少。

3. 需求阶段：把外部文档搬进 AI 的视野

我们的 PRD 写在钉钉文档，API 文档写在 ShowDoc。这些都在外部系统里，AI 看不到。

两个 Playwright 自动化技能解决了这个问题：

dd-prd-claw：钉钉文档 → 慢滑截图 → 去重合并 → AI 可读的完整 PRD（包括原型图和标注）
dd-api-claw：ShowDoc → 提取文本 → 结构化 JSON（同时产出纯文本和 JSON，方便不同场景消费）

抓取后的文档就在工作区里，AI 助手可以直接读取。不需要人工搬运。

4. PRD 评审：让 AI 先审需求，再写代码

开发做到一半才发现 PRD 没写清楚某个交互细节——这是最常见的返工原因。

dd-prd-judge 对抓取的 PRD 做实现前评审：

评审维度	审什么
用户流程	核心路径完整吗？分支流程覆盖了吗？
交互规格	状态切换、动画、手势写清楚了吗？
业务规则	计算逻辑、边界条件定义了吗？
数据契约	字段定义、必填/选填、枚举值给了吗？
异常处理	断网、超时、降级描述了吗？
验收标准	有没有可执行的测试用例？

风险分级：P0（阻塞开发，必须补）→ P1（必然返工，当前迭代补）→ P2（不阻塞，开发中补）→ P3（建议优化，后续处理）。

实际案例：「换肤配置」PRD 评审得分 58/100，标注了多个 P0 阻塞项——用户流程不完整、交互规格缺失、异常处理未覆盖。这些问题在编码前就被拦截了。

5. 变更管理：让每一步都有据可查

以前做功能，经常是”PRD 丢过来 → 直接写代码 → 写完发现方向偏了”。我们引入了 spec-driven 模式，给变更流程加上结构化中间产物：

proposal.md ──→ delta spec ──→ design.md ──→ tasks.md
     │                                          │
     │  为什么要改？               具体怎么实现？  │
     │  改什么能力？               任务拆分        │
     │                              │           │
     │                              ▼           ▼
     │                        实现 & verify
     │                              │
     │                              ▼
     │                        archive（归档）
     │                              │
     │                              ▼
     └── ── ── ── ── ── ──→ sync delta → main spec

产物	回答的问题
`proposal.md`	为什么要做？改什么？影响范围？
`delta spec`	新增/变更了什么能力？
`design.md`	技术方案是什么？影响哪些模块？
`tasks.md`	具体要做哪些事？优先级怎么排？

归档后，delta spec 合入 main spec。下次再改同一块能力时，AI 能看到历史基线。半年后新人接手，看归档就知道当初的设计取舍。

最大的变化是：**AI 不再直接写代码，而是先过一遍”为什么要做、怎么做、分几步”**。

6. 工程自动化：把团队规范写进 AI 的肌肉记忆

Git 工作流规范

规范	规则	AI 行为
分支名	`feature/[任务号]-中文描述`	AI 创建分支时自动遵循
Commit	`-#任务号提交信息`	AI 写 commit 时自动带任务号
推送保护	禁止推 master/develop	AI 推送前检查分支名

多仓组件联调

联调时切本地源码，以前要手动读 Podfile 版本 → 去组件仓 checkout 对应 tag → 写本地配置文件，多个组件仓重复操作。现在一个命令搞定，支持 --dry-run 预览。

AI 生成的 commit 和分支不再需要人工修正格式。

7. 代码审查：不是通用 review，是领域专家 review

通用 AI 代码审查会说”这个函数太长了”——帮助不大。我们关心的是：会不会影响启动速度？会不会卡 UI 线程？有没有走规定的网络层？

以下是我们在移动端的实践，思路可迁移到其他终端领域：

dd-code-review 内置了质量六维模型：

维度	典型问题（以移动端为例）	严重级别
启动性能	应用启动时同步读磁盘/发请求	`[严重]`
流畅度	列表滚动时重复创建视图	`[主要]`
稳定性	强制解包服务端可选字段	`[严重]`
耗电	后台未停止的定时器	`[主要]`
网络	相同请求未复用缓存	`[次要]`
发布风险	Release 包含调试入口	`[严重]`

还内置了项目级约束检查：网络请求是否走了规定的网络层？解析是否用了规定的解析库？埋点是否接了规定的监控 SDK？

审查结果带严重级别：[严重] 必须修、[主要] 应当修、[次要] 建议修、[挑刺] 可忽略。不再是泛泛的代码风格建议，而是带业务上下文的可执行行动项。

8. 全流程串起来

钉钉 PRD ──┐                              ┌── 代码审查 ──→ 合入
            │                              │
ShowDoc ───┤                              │
            ▼                              │
      ┌──────────┐                   ┌─────┴─────┐
      │ PRD 抓取  │                   │  编码实现   │
      │ + API抓取 │                   │ (规则约束)  │
      └────┬─────┘                   └─────┬─────┘
           │                               │
           ▼                               │
      ┌──────────┐                   ┌─────┴─────┐
      │ PRD 评审  │                   │  工程自动化  │
      │ (门禁)    │                   │ (Git/组件)  │
      └────┬─────┘                   └─────┬─────┘
           │                               │
           ▼                               ▼
      ┌──────────┐                   ┌───────────┐
      │ 方案提议  │──────────────────→│  变更归档   │
      │ + 设计    │                   │ + Spec同步  │
      │ + 任务拆分 │                   └───────────┘
      └──────────┘

◄─────── spec-driven 变更流程 ──────────────────►

一句话：需求进来 → 先抓取 → 再评审 → 然后设计拆任务 → 编码（受规则约束+工程自动化）→ 审查 → 归档。AI 参与了每一个环节。

四、学习路线：从用到工程化

前面是我们的实践结果，但团队不是一步到位的。这条路怎么走？我们总结了三个阶段：

阶段一：上手（1-2 周）—— 先用起来

目标：让 AI 参与每天的开发工作，建立基本手感

两个工具都要会：Cursor 擅长编辑器内实时辅助，Claude Code 擅长终端级多文件任务，从真实小任务开始
核心习惯：小步给指令，每步 review——不要一次性甩一个大需求
给项目写 Rules（Cursor 的 .cursor/rules / Claude Code 的 CLAUDE.md），让 AI 懂你的项目约定
关键体感：Rules 越具体，AI 输出越稳定

自测验证：

验证项	达标线
两个工具都能用	Cursor 能独立完成行内编辑 + 上下文引用；Claude Code 能产出可直接 review 的 PR
工具选择合理	回顾最近 5 次任务，至少 3 次选择合理（编辑器内小改用 Cursor，跨文件/终端任务用 Claude Code）
Rules 生效	有 Rules 时 AI 输出明显更贴合项目约定

阶段二：提效（2-4 周）—— 改变工作方式

目标：从”AI 写代码”升级为”你写 Spec，AI 实现”

最核心的方法论是 Spec 编程：

1	需求 → 写 Spec → AI 出方案 → 你确认 → AI 写代码 → 你审查

Spec 越清楚，AI 输出越靠谱；模糊输入 = 随机输出。

Prompt 质量是 Spec 编程的基础：

好的 Prompt = 清晰目标 + 充分上下文 + 明确约束
太模糊或太详细都不行，给方向和边界，让 AI 决定实现
常见反例：
- “优化一下这个函数” → AI 不知道优化性能？可读性？兼容性？
- “帮我写个登录页” → 缺少技术栈、设计规范、接口约定，输出不可控
- “按照第一行到第三行的方式，写第四行” → 逐行指挥，不如描述整体模式让 AI 批量处理

自测验证：

验证项	达标线
Spec 驱动开发	产出 Spec 文档 + AI 生成的代码，代码一次通过 review 或仅需微调
Prompt 质量	结构化 Prompt 输出的可用性明显高于随意版
Spec 精度	精确版 Spec 的返工次数明显少于粗略版

阶段三：整合（持续）—— 让 AI 融入工具链

目标：AI 不只是聊天窗口，而是连接设计、数据、服务的入口

MCP：让 AI 直连 Figma、数据库、内部 API，从”盲猜”变”有据可依”
Skills / Hooks：把重复动作自动化——代码审查、安全检查、循环任务
Rules 迭代：阶段一写了初版 Rules，现在根据 AI 犯过的错持续迭代，让 Rules 越来越精准

自测验证：

验证项	达标线
Skills 使用	每个 Skill 产出可观察的结果（如 `/simplify` 后代码行数减少、`/review` 发现实际问题）
Rules 迭代	至少完成 2 次”犯错→补 Rule→验证生效”的闭环
MCP 接入	AI 借助 MCP 产出的结果准确性高于无 MCP 时

贯穿始终的关键认知

认知	说明
你决策，AI 执行	你负责思考和决策，AI 负责执行和扩展
Spec > 逐行指挥	写清楚”要什么”，比指挥”怎么写”效率高得多
Rules 是杠杆	一次写好，每次对话都生效，投入产出比最高
小步迭代	一次一个明确指令，逐步推进，每步确认
审查不可省略	AI 生成的代码必须 review，你是最终责任人

五、踩过的坑和当前局限

踩过的坑

坑	教训
规则扁平堆砌	AI 不知该看哪条，经常忽略重要约束 → 改为分层路由（归属判断）
让 AI 直接写代码	写完发现方向偏了，返工更大 → 先走 proposal → design → tasks
通用代码审查	帮助不大，开发同学不当回事 → 改为领域化审查

当前局限

局限	说明
PRD 抓取依赖 Playwright	钉钉文档结构变化时脚本需同步更新
规则镜像需人工维护	`.cursor/rules/` 和 `.kiro/steering/` 目前是手动镜像，存在不一致风险
AI 归属判断偶尔误判	复杂跨仓改动时，路由判断可能不够精准
PRD 评审深度有限	AI 能发现缺什么，但不能替代产品补全需求细节

六、三种模式的适用场景

没有银弹，三种模式各有适合的场景：

模式	适合什么	不适合什么
纯人肉	探索性原型、个人项目、极简改动	团队协作、多仓架构、长期维护
Vibe Coding	一次性脚本、学习练手、简单独立功能	多仓项目、有规范的团队、需要长期维护的代码
全流程工程化	团队项目、多仓架构、长期迭代、多人协作	一个人临时写个脚本（前期投入不值得）

判断标准很简单：这段代码的生命周期有多长？ 只需要跑一次，Vibe Coding 够了；需要活半年以上，全流程工程化才划算。

Vibe Coding 让 AI 替你打字，全流程工程化让 AI 替你思考——而且是有规矩地思考。