如何让人在vibe coding的过程干预得更少

某天早上看到了朋友转发的这个# AI软件工程范式革命的思考原创 hadeswang 茹炳晟聊软件研发里面写的东西挺干的，对于ai对现阶段生产力的影响描述得很到位，具体说了什么，大家可以点开那篇文章细细品读一番。以前为什么机器能够代替人类，是因为那些工作完完全全就是流水线作业，体力活。每一次都是完完全全的重复劳动，可以被标准流水线替代的工作内容，也能够通过一把标尺来衡量工作的质量的好坏。具体的标准化流水线如下图所示

即便现在的软件工程经过几十年的积累，输出了很多标准化的软件实践例如CI/CD、TDD、devops等等，但是这些东西只是为了辅助人类把软件这个事情更快做好的一些工具，并不是把这些东西缝合在一起就能够代替人类，所以我也一直在想AI能不能完全代替人类，就算如今有如此好用的claude code fable5，我现在答案依然是”不能”。想用机器代替人脑，在我看来目前还不能完全实现，业务的确认、代码整体质量把控、方案在当前场景下是否合理等等，这些地方都需要人来确认。软件工程是一个很复杂的东西，如果拿瀑布模型来举例的话，可以分为需求确认、设计、编码、测试以及运维这几个阶段，在这个过程中，需求确认和设计部分是没办法用AI完全替代的，这些地方都需要反复推敲的。

所以从LLM爆发以来，人们其实一直在想着怎么提高生产力，但是人其实一直都没有从AI时代背景下的软件工程中完完全全地抽离出来。刚出来的时候LLM只是一个chatbot，让我们查阅问题的解决方案的速度变快了。再后来出现了agent，LLM可以自己通过loop的方式自己拿到每次编码后的反馈来调整自己的实现，但是在此过程中我们还是需要介入很多次，我们妄想着每次LLM的迭代更新，LLM输出越来越精确的答案就可以慢慢的取代人类在软件工程中的地位，就像工业时代中，动力越来越强劲，流水线的机械化程度越来越高，人类只需要通过一个固定按键模式来完成以前的体力工作。但是在vibe coding的过程中，我越来越发现AI没法取得完全的自动化，如果放任AI在代码中驰骋，你最后得到将会是一堆接着一堆的shit mountain。当然有的人也许会说，这有什么，代码烂了，大不了让ai重新帮我们写一遍就行了。当你说出这句话之后，LLM的出现并没有让coding完全变成自动化，你会使用越来越多的token，堆出越来越多的shit，最后产生的价值可能还比不上之前的手工代码。

那这个时候，你们也会说了，这也不行那也不行，AI有个屁用。这个结论是不是下得太快了，我们首先要识别出哪些地方是纯纯的体力劳动，哪些地方人脑是没法替代的。识别这些之后，我们才能够研究哪些地方人类可以直接越过，vibe coding的过程中，最耗时的地方其实还是在交互上，如果我们input不够清晰，AI没法很清晰的理解我们的意图，他们就需要反复的和我们确认，这个该怎么样，那个该怎么样。最后我发现vibe coding下的软件工程又回到了最原来的prompt engineering了。软件工程中的每一步其实都不能少，少了就会增大AI的理解成本，就需要人类的过多干预。第一步还是写清楚我们的需求，然后列清楚tech design，workflow design，让AI根据这些context生成对应的plan，那么这个时候这个过程，很多东西都会被反复使用，沉淀成一个 plan design，这个可以对应瀑布模型中的需求分析和设计阶段。等plan和我们确认的很清晰之后，就可以让AI来编码了，当然在coding的过程中可以让AI遵守很多的编码规则和最佳实践，当然也可以给他指出有哪些pitfall，让他不会重蹈覆辙，这个过程可以总结成一个 implement的skill。后面的测试，运维这些都可以整理成对应的skill，串联成整体的workflow，总之写清楚plan，然后结合当前软件工程中一些良好的实践就可以最大程度的减少人为干预。

回过头看，工业时代机器替代的是人的”手”，而AI时代我们想让它替代的是”手”再加上一部分”脑”。完全抽身现在还做不到，但人的角色确实已经在变了：从一个全程握着方向盘的司机，慢慢变成只在plan这一个关口把关的质检员。需要人确认的干预并不会消失，但它可以被收敛到一个点上——把需求和设计沉淀成 plan design，把规范和pitfall沉淀成 implement，把测试运维串进workflow，剩下那些纯纯的体力劳动，就放心交给AI在它的流水线上跑。这大概就是现阶段vibe coding能做到的”干预得更少”。

具体实现：我是怎么把工作流串起来的

上面讲的都是道，下面讲讲术。前面这套想法不是空想，我在自己手头的项目里已经用一组 skill 落地了，这一节就把它写清楚。

先说一个前提。我们团队以前的项目大部分是按敏捷（Scrum）在跑的，一个迭代里会有这么几个雷打不动的环节：

IPM（Iteration Planning Meeting） —— 迭代开工前，整个迭代要做哪些卡，先有个全局的认识；
Backlog refine（过卡） —— 一张一张卡细抠，把实施方案和验收标准（AC）聊清楚；
Implement（TDD） —— 红→绿→重构，每条 AC 都有测试兜底；
Test（e2e） —— 端到端跑一遍，站在用户的角度验；
Desk check —— 基于卡里写好的 AC，逐条对着验收。

到了 vibe coding 时代，很多人的第一反应是：”有 AI 了，这些流程是不是可以省掉了？一个任务丢给 AI，它自己做就好了。”我试过，结论是不行。你把需求原封不动丢给 AI，它一样要回过头来反复跟你 clarify——这个字段要不要、那个边界怎么处理、AC 到底是什么。只是把『人来回确认』换成了『跟 AI 来回确认』，并没有发生质变。

真正让 AI 在软件工程里发生质变的，不是更强的模型，而是 把敏捷的每个环节蒸馏成一个 skill，让流程本身替我把 context 喂到位 。每个环节该确认的东西，在进入下一环节之前就固化下来、写进文档，AI 拿到的不再是一句模糊的需求，而是一份已经被人把过关的、结构化的输入。环节不能省，省了就是把理解成本转嫁给后面，最后还是要人来兜。

下面是我目前这套 skill 跟敏捷环节的对应关系：

敏捷环节	对应 skill	干的事
IPM / 全局了解	`analyze-requirement`	吃进 Jira / Confluence 链接，产出一份结构化的需求分析（现状 / 要做什么 / 影响范围 / AC / To be confirmed），落到 Obsidian
Backlog refine（过卡）	`refine-ticket-plan`	一次只抠一张 ticket，跟 AI 多轮讨论敲定实施方案和 AC，最后把”已定稿”的 Implement Details 写回那张卡
Implement（TDD）	`implement`	以 AC 为契约，test-first 实现单张 ticket，跑完 lint + 单测；多张无耦合的卡可以开多个 agent 并行
Test（e2e）/ Desk check	`ui-test`	把 QA 的活蒸馏出来——从 ticket 生成 UI 测试用例，驱动浏览器在测试环境上真跑一遍，按 AC 出测试报告

辅助的还有两个小工具：postman-request（把刚写好的接口同步进 Postman 集合，联调时不用手敲）、refresh-aws-credentials（本地 AWS SSO token 过期了一键刷新，不用离开 Claude Code）。它们不在主线上，但属于”省掉一段纯体力交互”的同类。

一个完整 epic 迭代是怎么走下来的

analyze-requirement —— 迭代一开始，把这次要做的需求（Jira epic / Confluence PRD）丢进去，先拿到一份 general 的分析。这一步对应 IPM，目的是建立全局认识，把模糊的、待确认的点（To be confirmed）先暴露出来，而不是急着动手。
refine-ticket-plan —— 然后一张一张卡过。这是整个流程里人介入最重、也最该重的一步，对应敏捷里的过卡。我会和 AI 就每张 ticket 的具体实施方案、数据模型、边界、AC 反复聊，聊到方案落地、AC 能钉死 scope 为止，再把”已定稿”的 Implement Details 写回那张卡的文档里。这一份定稿，就是前面说的 plan design——它是后面所有自动化的地基。
implement —— 卡的方案定稿后，就可以让 AI 编码了。它会先去 Obsidian 里找那张卡的 Implement Details 当作权威实现说明，然后 test-first 地实现，跑 lint 和单测。关键点： 只要 ticket 之间没有耦合，就可以同时开多个 agent 并行 implement ，几张卡一起推。这一步因为 plan 已经定稿，人几乎不用再介入——这正是”干预收敛到 plan 那一个关口”的体现。
联调 + postman-request —— 后端写完，和前端联调。接口顺手用 postman-request 同步进集合。
ui-test —— 既然要”去 QA 化”，那就把 QA 这个角色也蒸馏成一个 skill。它从 ticket 生成 UI 测试用例（plan 模式只出用例给人 review，给了账号就直接驱动浏览器在测试环境上真跑），跑完出一份图文并茂的测试报告。这一步对应 e2e + desk check——而且因为用例本身就是从 ticket 的 AC 推出来的，desk check 的”对着 AC 逐条验”是天然内建的。

走完这五步，一个 epic 的迭代开发就闭环了。

这套东西真正的价值在哪

不在于某一个 skill 多聪明，而在于 它把敏捷的流程编排固化了下来 ：每个环节的产出（分析文档、定稿的 plan、AC checklist、测试报告）都是下一个环节的结构化输入，人只需要在”过卡定 plan”这个关口认真把关，前后两端的体力活——查需求、读代码定位现状、写测试、点页面验收——就都交给 AI 在流水线上跑。需要人的地方一个都没省，但需要人的地方被收敛到了一个点上。

这套 workflow 我还在持续调整，skill 也在迭代——上面写的是当前的形态，后面大概率还会变。先记到这里。