Limin Ge

05

上一章下一章

第 5 章：AI-Native 工作流——Plan–Act、Test–Code、Doc–Code–Doc

Plan–Act、Test–Code、Doc–Code–Doc 是新工程时代的工程循环。

Cover Image for 第 5 章：AI-Native 工作流——Plan–Act、Test–Code、Doc–Code–Doc

“Plan–Act、Test–Code、Doc–Code–Doc 是新工程时代的工程循环。”

延伸阅读：本章是对AI 的无状态性与 Context Window和Test–Code 循环：为什么测试代码比功能代码更重要在流程层面的综合应用。

本章把分散在对话中的工作流实践整理在一起，聚焦在三个循环：
Plan–Act、Test–Code、Doc–Code–Doc，以及它们在一个两人小团队里的真实落地方式。

1. Plan–Act：不要先看代码，而是先讲清楚问题

现实中的一个经验总结是这样的：

“我拿到东西之后，千万不要先去看代码，而是把需求跟 AI 描述清楚。”

一个典型的 Plan–Act 流程是：

  1. 先描述问题/需求，而不是直接打开 3000 行的大文件
  2. 让 AI 先尝试解决，观察它的执行过程
  3. 每一轮结束后，立刻验证结果，看是否真的解决了问题
  4. 同时关注 context 使用百分比，感知这个 AI 的思考逻辑跑到了哪里

如果两轮之后还没有解决：

  • 让 AI 把自己的思考过程总结成一个文档
  • 用这个总结文档作为“接力棒”，交给一个更强模型或一个新的 session
  • 再在这个基础上继续搜索和尝试

当进入所谓“深水区”之后：

2. Test–Code：用测试驱动 AI 的混沌产能

在 AI-native 的场景下，Test–Code 循环的本质是：

“用海量的 test case 去 cover 人脑 cover 不了的部分。”

这一点在Test–Code 循环：为什么测试代码比功能代码更重要章节已经详细展开，这里只强调和工作流相关的部分：

  1. 新需求开发时，尽可能让 AI 同时生成功能代码和测试代码
  2. 人类在 code review 中要把大部分精力放在测试代码上：
    • 框架是否规范
    • case 是否覆盖关键分支
    • AI 有没有随意修改旧的测试
  3. 功能代码可以“大胆交给 AI 写”，但只能在测试网里大胆，在测试体系外要非常保守

在这种模式下，你可以接受：

  • AI 的功能代码是“在混沌中写出来的”
  • 但不能接受测试代码同样“在混沌中被随意改来改去”

3. Doc–Code–Doc：文档只记录“结果”，不记录“过程”

传统软件工程里，很多团队会如下操作：

  1. 写 PRD
  2. 再写 Tech Doc
  3. 再写执行记录
  4. 最后写代码，并且不断回填这些文档

在 AI 帮助下，这个模式有两个致命问题：

  1. 文档太多，人脑根本读不过来，很快就会失去对代码库的掌控力
  2. 文档和代码极难保持始终一致，一旦不同步，就会给 AI 输入大量矛盾信息

实践经验是：

  • 把这一整套东西精简到：只有一类文档，文档和代码必须始终一致
  • 不再区分 PRD 和 TDD，而是用一份“最简单的文档”承载高层设计和关键 Flow
  • 文档的 scope 要刻意保持在高层：
    • 全局架构
    • 核心模块的职责
    • 关键 flow（可以配图）
  • 如果你想写一个比这个 scope 还低的文档，那它大概率就不应该存在

对于过程性的 plan、执行记录：

  • 可以写，用来帮助当下这一轮 AI 工作
  • 但在任务完成之后，要么删掉，要么只抽取其中的“结论性信息”合并到主文档
  • 永远不要在代码库里保留“我们把 A 改成 B”这样的历史描述

这一点与AI 的无状态性与 Context Window中"删除所有 A，只保留 B"的原则是一致的。

Plan/Act, Test/Code and Doc/Code/Doc loops

4. 中高复杂度需求的标准工作流

把上面的经验综合起来，一个中等复杂度以上需求的标准工作流大致是：

  1. Session 1：理解与计划

    • 让 AI 多读全局性文档和相关代码
    • 让它写出一个执行计划（Plan–Act 的 Plan）
    • 人类认真审阅这个计划，讨论不合理之处
    • 把确认后的计划固化成文档（快照）

  2. Session 2：执行与测试

    • 开一个新的 AI，会话只读这个计划文档
    • 按步骤执行，每完成一步就生成/完善对应测试（Test–Code）
    • 人类在每一步后做最小必要的 review，尤其关注测试和边界

  3. Session 3+：接力与重启

    • 当发现 AI 变蠢（比如 context 剩余不到 40%，或者反复犯同样的错）
    • 用当前计划和执行结果，重新开一个新的 session，在断点处继续
    • 必要时更换模型或工具（比如从 IDE 内部 Agent 换到 Codex/Cloud Code）

  4. 收尾：清理与固化

    • 全部通过测试、lint、质量检查之后
    • 删除过程性计划文档
    • 把真正有价值的结论固化到长期文档里（Doc–Code–Doc）

5. UI/UX 工作流：设计先行，AI 辅助还原

延伸阅读：这个工作流如何与降低垂直复杂度相关，参见从垂直复杂度到水平复杂度。

在前端/UI 这条线上，对于一个有设计师的团队，一个相对成熟的 AI-native 工作流是：

  1. 设计师使用 Figma 做 hi-fi 设计稿
  2. 通过 Figma → 代码插件导出一版初始组件代码
  3. 前端工程师用 Cursor 等 IDE 型工具来：
    • 调整细节
    • 按照现有组件库/设计系统做拆分和重组
  4. Storybook 作为设计和前端之间的“对齐平台”：
    • 设计师需要为组件做变量化、组件化设计
    • 前端通过 Storybook 确保设计还原不漂移

这里一个重要经验是：

  • 设计端的进度通常要比前端快
  • 可以把“生成大致 UI 结构”的工作交给设计师和 Figma 插件
  • 前端工程师更多扮演“把设计转化为可维护代码”的角色，而不是“从零想 UI”

6. Programmer = 文档与上下文的管理者

一个非常有代表性的感受是：

“我没想到，今后程序员可能基本上就属于跟 AI 打交道的一个文档整理人员。”

因为：

  • 文档太多、密度太大
  • 前后跳转很多，需要一直遵守各种约定
  • 同时要保证 prompt、代码注释、文档、测试之间没有自相矛盾的信息

这听上去有点“降维”，但从 AI-native 的视角看，这是必然结果：

  • 代码产能已经从“人写”切换到“AI 写”
  • 人类的工作重心，从“写对每一行代码”，变成了“管理上下文、管理测试、管理文档一致性”

The engineer conducts the workflow assembly line

7. 小结：从“写代码”到“设计工作流”

Plan–Act、Test–Code、Doc–Code–Doc 这三个循环，其实是同一件事的三个侧面：

  • Plan–Act：把“做什么”讲清楚，避免无效 code churn
  • Test–Code：用测试兜底 AI 写出来的混沌代码
  • Doc–Code–Doc：用最少量的结论性文档，维持长期可理解性

在 AI-native 的时代，工程师的核心能力不再是：

  • 手写多少行代码
  • 掌握多少语言的细节

而是：

  • 设计一个 AI 能够高效执行、又不会在三个月后把自己“写死”的工作流
  • 知道在什么地方要让 AI 接力，在什么地方要亲自下场
  • 知道哪些东西该记录成“快照”，哪些东西该及时删掉