AI编程工作流·Superpowers(6/6)|真实项目经验总结:AI编程工作流,怎么选,怎么收

Superpowers 系列课程完结篇 · 这一课讲怎么选工作流、怎么避坑、怎么收尾

01 怎么选工作流？

很多人问：我现在这个情况，该用哪个技能？

这个问题本身就有问题。技能不是菜单，不能你点一个上一个。工作流是按场景选的，不是按喜好选的。

我总结了 4 个场景决策树：

场景 1：需求不清晰    ↓    → 用 brainstorming，先把需求问清楚再动手场景 2：需求清晰，实现复杂（2+ 个独立模块）    ↓    → 用 writing-plans + subagent-driven，先规划再执行场景 3：需求清晰，实现简单（1 个文件改几行）    ↓    → 直接执行，不用绕弯子场景 4：遇到 bug 了    ↓    → 用 systematic-debugging，先诊断再修复

记住一个原则：用最简单的工作流把事做对。

别搞复杂了。我见过最典型的过度工程是这样的——

用户：帮我改个 typo AI：好的，我先创建一个详细的 spec，包括 5 个部分、3 个验证步骤、2 个审查节点……

这就是用牛刀杀鸡。工作流是为场景服务的，不是为了证明你专业。

02 常见坑与解决方案

这一节是我这一年踩过的坑，总结成 4 个最典型的：

坑 1：设计阶段过度讨论，迟迟不开始

表现：需求讨论了 3 天，代码一行没写。

原因：把"想清楚"当成了"做完"。但需求是永远讨论不完的。

解决方案：设置启动阈值。

需求讨论上限：30 分钟超过 30 分钟，启动，先写代码再说不完美就改进，别等完美

一个简单标准：当你能够回答「这个功能的核心数据流是什么」时，就可以开始写了。

坑 2：任务拆分太粗，执行时漏掉细节

表现：计划写了 10 个任务，执行完了发现漏了 3 个。

原因：任务粒度太大，每个任务做了 5 件事。

解决方案：2-5 分钟粒度原则。

一个任务应该：- 单一动作（增删改查一个东西）- 可验证（跑一下能确认做没做对）- 2-5 分钟能完成

怎么验证任务拆得够细？看这个任务能不能用一句话描述清楚。 如果需要"而且""或者""还有"，说明任务该拆了。

坑 3：测试写了但不执行

表现：测试文件在项目里，但从来没人跑过。

原因：没把测试当成验收的一部分。

解决方案：测试不通过 = 任务没完成。

验收公式：npm test 退出码 = 0如果没有测试退出码 = 0，任务不算完成

这一条写进肌肉记忆里。AI 说"测试写了"不算数，必须"测试跑过了"才算数。

坑 4：代码改了不验证，直接下一题

表现：AI 改了代码，用户说"好的"，然后继续下一题。

原因：省略了验证环节，觉得改完就是对。

解决方案：建立验证闭环。

验证动作：1. 运行 lsp_diagnostics（类型检查）2. 跑测试（功能检查）3. 构建（构建检查）4. 跑一遍（手动检查）

没有验证的修改=没改。这是铁律，违者必翻车。

03 收尾流程：finishing-a-development-branch

代码写完了，测试通过了，然后呢？

很多人就甩给用户了。这是不负责任的结尾。

一个完整的收尾流程分为 4 步：

第一步：验证测试

# 必须执行的动作npm test# 运行所有测试npm run build     # 构建验证

如果这两个命令有一个失败，收尾不算完成。

第二步：分支选择

根据场景选收尾方式：

原则：不要留尾巴。该合并合并，该删删。

第三步：清理工作

# 删除 worktree（如果用了的话）git worktree remove ../todo-app# 检查是否有未提交的更改git status

收尾不清理，次年回来做新功能的时候，全是遗留问题。

第四步：文档记录

很多人忽略这一步。

记录什么：

• 这版实现了哪些功能
• 踩了哪些坑，怎么解决的
• 哪些地方下次要注意

## v1.0 开发记录### 实现功能- 添加待办事项- 标记完成/未完成- 删除待办### 踩坑记录- 1. 箭头函数 this 绑定问题 → onClick={addTodo} 而非 onClick={() => addTodo()}- 2. localStorage 解析失败 → 加了 try-catch### 下次注意- 先跑测试再交付- 测试用例要覆盖空输入

不记录的教训 = 将来还会再踩一次。

04 进阶技巧

技巧 1：自定义技能

如果你有一些固定的工作流，比如「每次接需求必须先问 3 个问题」，可以写成自定义 Skill。

# 自定义 Skill: strict-context## 触发条件用户提到实现意图时自动激活## 检查清单1. 需求文档存在吗？2. 验收标准明确吗？3. 边界情况定义了吗？## 输出如果检查不通过，输出问题清单而不是开始写代码

写 Skill 是把自己的经验变成自动化。不是什么高大上的东西，就是约束。

技巧 2：扩展能力，而不是换工具

进阶的意思不是"这个工具更强换成那个"，而是"我想做到 X，但当前工具链做不到 → 引入 Y"。

正确思路：工作流需要什么能力，就引入什么工具。

常见的扩展方向：

核心原则：不是追新工具，是补能力缺口。

我缺了什么能力？→ 有 MCP 或 skill 能补吗？→ 有 → 接入→ 没有 → 自己写一个 skill

工作流是固定的，能力是扩展的。这才是进阶的正确姿势。

技巧 3：技能组合技

有些技能组合起来用，效果翻倍：

brainstorming + writing-plans↓ 需求问清楚 → 计划写清楚 → 执行subagent-driven + verification-before-completion↓任务分配执行 → 完成后验证 → 不通过打回重做systematic-debugging + receiving-code-review↓bug 修好了 → 别人再审一遍 → 确保没引入新问题

组合技的前提是：单个技能都用对了。 根基不牢，组合没用。

05 总结与下一步

6 篇写完了，说几句收尾的话。

这一系列文章讲了一个核心观点：

AI 编程的上限是方法，下限是收尾。

代码生成只是开始，不是结束。

90% 的人死在两个地方：

1. 选错工作流
    —— 简单问题复杂化，复杂问题简单化
2. 不做收尾
    —— 改完就交，不验证，不记录

避开这两个坑，你已经超过了 90% 的人。

下一步可以学什么：

• 深入某个技能的源码，看它是怎么实现的
• 看官方文档，每个工具链的官方文档都是宝藏
• 实践中积累，形成自己的 Skill 库

立刻能做的事：

1. 今天用一个新项目，用一次「复现→定位→分析→验证」的调试流程2. 跑一遍 npm test，确认退出码 = 0 再交付3. 写一条开发记录，记录这版的坑和解决方案

方法对了，事自然成。收尾稳了，项目才真正结束。