夜雨聆风
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% 的人死在两个地方：
- 选错工作流
—— 简单问题复杂化，复杂问题简单化 - 不做收尾
—— 改完就交，不验证，不记录
避开这两个坑，你已经超过了 90% 的人。
下一步可以学什么：
深入某个技能的源码，看它是怎么实现的 看官方文档，每个工具链的官方文档都是宝藏 实践中积累，形成自己的 Skill 库
立刻能做的事：
1. 今天用一个新项目，用一次「复现→定位→分析→验证」的调试流程2. 跑一遍 npm test，确认退出码 = 0 再交付3. 写一条开发记录，记录这版的坑和解决方案方法对了，事自然成。收尾稳了，项目才真正结束。
