跬步 On Coding

AI工程落地实践

Feb 11 2026

前几天在整理项目代码的时候，看着 commit log 里那些由 AI 生成的代码，突然有点感慨。以前写代码是体力和脑力的双重劳动，现在好像变成了单纯的脑力博弈——跟 AI 的博弈。

这篇想絮絮叨叨聊一下从传统的开发模式转变为 Vibe Coding 的过程中，我踩过的坑以及现在摸索出来的一套还算顺手的 SOP。

1. 回顾：前AI时代的手工作坊

在那时候，我接一个大需求，流程基本是雷打不动的：

  1. 拆解：把大需求掰碎了，变成一个个小任务。
  2. 设计：看老代码，定方案。哪里要改，哪里要加，脑子里或者纸上得有个谱。
  3. 搬砖：按计划写代码，写单测。
  4. 验证：跑通端对端流程。
  5. Code Review：提 PR，等同事挑刺，改代码，合并。

这个过程里，最重要的一步其实往往被忽视，就是复盘。这波开发里学到了什么新模式？引入了什么新坑？怎么避免下次再犯？这种“复利”思维才是工程师成长的关键。

2. Vibe Coding 时代的冲击与适应

进入 AI 时代（或者说 Cursor 时代）后，我一开始也是懵的，试错了很多次，现在的 SOP 变成了这样：

  1. 聊需求：先不急着写代码。拉着 ChatGPT 或者 Gemini 开聊。讨论业界怎么做，现在的项目痛点在哪。这一步是为了定方向，最后产出一份靠谱的需求文档。
  2. 定计划（feat.md大法）：
    • 我会在 Cursor 里建个 feat.md，把需求文档丢进去。
    • 在 Cursor 里 @feat.md，让 AI 出 Plan。
    • 重点：如果 Plan 太大，我会让它拆。如果 Plan 漏了东西，只要不致命，我先不打断，记在小本本上，等它写完代码再补。
    • 有时候 Plan 实在离谱，改动量太大，我会回头改 feat.md，限制它的发挥范围，只做第一阶段。
  3. 生成：Plan 只要逻辑通顺，我就让 Cursor 开工。
  4. 人工 Review：这一步绝对不能省。我对 AI 的信任度还没到无脑 Merge 的地步，尤其是 E2E 测试覆盖率不够高的时候。我得盯着它生成的代码，脑子里过一遍逻辑。
  5. 收尾：测试，合并。

这个流程看着挺顺，但有个大问题：我怎么把“复利”这一环加回来？

之前我看 Spec Driven Development（文档驱动开发），也就是 Speckit 或者 OpenSpec 那一套，试了一下就放弃了。感觉太重了，光是喂给 AI 的上下文就把窗口撑爆了，而且那种从头到尾写文档的感觉，很反直觉，完全没有了快速验证的快感。

直到读到那篇《认知重建：Speckit 用了三个月，我放弃了》，里面提到了复利工程的概念，简直说到我心坎里去了：

Plan ──────→ Work ──────→ Review ──────→ Compound
详细规划     执行工作     质量检查       知识沉淀
   ↑                                       │
   └───────────────────────────────────────┘
            知识复合：下次规划更精准

这不就是我以前手工作坊时代的升级版吗？

3. 在 Cursor 中落地复利工程

理论有了，怎么在 Cursor 里实现？上个月 Cursor 2.4 更新了 SubAgents、Skills 和 Commands，我感觉机会来了。

我先是扒了 everything-claude-code 这个项目，想复刻一套工具链：

  • Subagent: planner, code-reviewer, doc-updater
  • Skill: security-review, tdd-workflow
  • Commands: learn（这个最关键，用于知识沉淀）

理想很丰满，流程应该是 planner -> tdd-guide -> code-reviewer -> learn。

现实很骨感。Cursor 的 SubAgent 经常“自作主张”。你给它编排好了流程，它跑着跑着就切回自己的默认 Plan 模式，或者无视我的 SubAgent 逻辑。那一阵子搞得我很抓狂，感觉在跟一个不听话的实习生较劲。

不过，learn 这个命令我是真留下来了。每次做完需求，把改动总结成知识点存下来，下次 AI 再写代码时，就能读到这些“家规”，确实有用。

4. 最终的折衷方案

不死心的我又去研究了 superpowers 和 code-review-expert 这两个项目，重新调整了策略。

既然 Cursor 对 SubAgent 的调度有自己的想法，那我就顺着它，把流程简化，侧重于前置规划和后置学习。

现在的工具组合变成了：

  • Skill: brainstorming, writing-plans, executing-plans, test-driven-development, subagent-driven-development, code-review-expert, using-superpowers
  • Commands: learn (雷打不动)

流程图大概是这样：

brainstorming ──→ writing-plans ──→ executing-plans ──┬──→ test-driven-development
                                                      └──→ code-review-expert ──→ learn

为了适配 Cursor，我把 Claude Code 定义的工具名都改了一遍，还在 Prompt 里强制要求它必须明确调用哪个 Skill。

虽然现在 Cursor 还是偶尔会丢失上下文，或者写着写着断片了，需要我手动把断掉的节点接起来，但整体上，这套流程已经能复刻我以前的工作流了。

总结：

不管 AI 工具有多强，它终究是个工具。不要被工具牵着鼻子走，也不要为了用 AI 而用 AI。

我觉得核心还是要把人的经验沉淀下来。以前我们沉淀在脑子里、Wiki 里，现在我们通过 learn 命令沉淀在本地文档里。

AI 可以帮我们把 Plan -> Work 这一段做得飞快，但 Review -> Compound 这一段，目前还得靠我们自己把关。只有把这个闭环跑通了，才算真正把 AI 用成了自己的副驾驶，而不是请了个随时会跑路的外包。