Vibe Coding 的下半场：不是写得快，而是谁来收拾残局

Thu, 04 Jun 2026 08:55:32 +0800

最近 Reddit 的 r/ClaudeCode 上有个很火的帖子。发帖者说，他接手了一个 3 个月前由 “Vibe Engineer” 做出来的项目，最后提交了自己职业生涯里最爽的一次 PR。

帖子有 7000 多个赞，评论接近 700 条。这个数字不用太当真，Reddit 上的高赞贴经常有表演成分。但它戳中的那种感受很真：AI 让代码更容易被写出来，也让一批“看起来能跑”的项目更快进入维护阶段。

过去聊 Vibe Coding，大家更爱聊前半段。一个人怎么用 Claude Code、Cursor、Codex 在一个晚上搭出原型，怎么把一个想法变成页面，怎么绕过前端、后端、数据库、部署这些过去很劝退的门槛。

这当然很迷人。我自己也喜欢这种感觉。一个想法原来只是脑子里的几句话，现在半小时后就能在浏览器里点开，确实会让人上头。

麻烦在于，软件项目不会停在 demo 那一刻。

只要它继续被用，就一定会进入另一段时间：有人要读懂它，有人要改它，有人要修 bug，有人要解释为什么这个状态会从 A 跳到 B，有人要在需求变了以后，把原来随手生成的那套结构重新理一遍。

这也是我觉得 Vibe Coding 需要和 Harness Engineering 放在一起看的原因。

Vibe Coding 解决的是“怎么更快生成”。Harness 解决的是另一个问题：当 AI 开始替你行动，谁来约束它、验证它、纠偏它，以及在它留下一个烂摊子之前把它拦住。

Vibe Coding 的真正考验，可能不是“能不能写得更快”，而是写快之后，有没有一套东西能防止残局变大。

“能跑”离“能接手”还差很远

Vibe Coding 最容易制造的错觉，是功能跑起来了，事情就差不多完成了。

如果只是个人小工具，这个想法没什么问题。你让 AI 写一个网页、一个脚本、一个自动化流程，只要它能解决当下的问题，结构乱一点、命名怪一点、边界条件少一点，都可以接受。坏了就重写，跑偏了就丢掉。

可项目一旦开始给别人用，情况就变了。

一个“能跑”的项目，后面会不断长出新的问题。需求变了，原来的结构还能不能改？新人接手时，能不能看懂代码为什么这么写？线上出错时，能不能定位到真正原因？加一个小功能，会不会牵动一大片隐含状态？这些问题不适合做 AI 编程演示，也不容易剪成短视频，但它们才是日常工程里真正耗时间的部分。

很多 Vibe Coding 项目的麻烦，不是 AI 把代码写得完全不能用。恰恰相反，它经常写出“局部没问题、整体很难维护”的东西。页面能打开，接口能返回，测试样例能过，但模块边界含糊，状态散在各处，错误处理靠猜，业务规则藏在一堆临时判断里。

这种代码最烦人的地方是，它不会马上坏。

它会先给你一种进展很快的感觉。等项目到了第二个月、第三个月，需求开始叠加，问题才慢慢浮出来。到那时，维护者面对的往往不是一个明确的 bug，而是一片不知道从哪里开始整理的草丛。

Harness Engineering 的价值就在这里：它不是等草丛长出来以后再让人拿镰刀割，而是在 AI 写代码的过程中，就把边界、验收和反馈放进去。

AI 降低的是打字成本，不是理解成本

Vibe Coding 能成立，是因为 AI 确实把写代码的成本打下来了。

今天让 AI 生成一个 CRUD 模块、一个设置页、一个登录流程、一个数据导入脚本，比过去快太多。很多以前不值得动手的小工具，现在都可以试一试。这是实实在在的变化。

但软件的成本从来不只在“写”。

更麻烦的成本在后面：理解它为什么这么写，验证它有没有真的做对，和别人协作时能不能说清楚，半年后迁移时能不能搬得动，出问题时能不能快速排查。

AI 能帮你把代码写出来，却不能保证下一个人能轻松读懂。它能快速接上一个库，却不一定会说明为什么这个库适合当前项目。它能把需求拆成一堆文件，却不一定会给这些文件留下稳定的边界。它能生成测试，但测试是不是覆盖了真正重要的业务风险，还是要人判断。

这也是很多团队重新审视 AI 编程的原因。

如果 AI 只是让团队生成更多代码，但评审时间没有减少，返工次数没有下降，线上缺陷没有变少，新人理解系统也没有更轻松，那所谓提效就很可疑。成本没有消失，只是从“写代码的人”那里，挪到了“读代码、改代码、审代码、修代码的人”那里。

Reddit 那条帖子能引起共鸣，也是因为很多人都熟悉这种疲惫感。接手一个快速堆出来的项目，第一反应不是“这个人真高效”，而是“我得先弄明白这里到底发生了什么”。

一个没有 Harness 的 Vibe Coding 流程，很容易把理解成本往后推。生成时很顺，接手时很痛。真正成熟的 AI 编程，应该尽量把这种成本前置：让 AI 在写的时候就说明假设，跑验证，留下轨迹，交代为什么这么改。

技术债以前慢慢长，现在可以一夜长大

技术债不是 AI 发明的。

没有 AI 的时候，人也会赶工，也会复制粘贴，也会为了上线先把边界条件放一边。区别在于，过去技术债的增长速度受人类编码速度限制。

AI 改变的是速度。

一个开发者过去一天只能写出一个混乱模块，现在可能让 AI 在一天里生成五个。过去一个不成熟的架构要几周才显出问题，现在两三天就能堆到足够复杂。过去项目变乱，通常还有一个逐渐失控的过程；现在项目可能从第一版开始，就带着大量自动生成的结构惯性。

我见过不少类似情况：一个很小的功能，最后被拆成 service、manager、adapter、helper、config、schema、types。每个文件单独看都不算离谱，合在一起却很难说清楚主线在哪里。等真正要改需求时，才发现自己不是在改功能，而是在穿越一套由 AI 想象出来的工程仪式。

这类技术债不一定来自低水平。

有时恰恰是模型太擅长模仿“成熟项目”的样子。它知道现代软件工程里有分层、有抽象、有配置、有测试、有错误处理，于是把这些形状都生成出来。问题是，一个项目需不需要这些层次，取决于业务复杂度、团队规模、生命周期和变更频率，不取决于代码看起来像不像大厂项目。

AI 很容易把一个小问题写成一个“大项目的开端”。

而很多时候，我们需要的只是一个清楚、短小、能被下一个人读懂的实现。

这时候 Harness 不一定是复杂系统。它可以很简单：不允许无理由新增抽象层；新增依赖前必须解释替代方案；改动超过一定范围先停下来让人确认；每次完成都要给出验证命令和失败风险。听起来像规矩，但规矩正是用来对抗“顺手多写一点”的。

Vibe Coding 缺的不是更多 Prompt，而是小 Harness

很多人遇到 AI 写乱代码，第一反应还是改 prompt。

比如写“你是资深工程师”“请遵循最佳实践”“不要过度设计”“请写可维护代码”。这些话不是完全没用，但它们太软了。模型当时可能会听，任务一长、上下文一乱，它又会回到自己的习惯里。

Harness 的思路不一样。

它不只是在语言上提醒 AI，而是把任务拆成几个可检查的阶段：先读代码，再给计划；先确认改动范围，再实现；实现以后必须运行测试；如果测试失败，先解释失败原因再修；如果引入新文件，要说明它存在的必要性；如果没有验证，就不能说完成。

这套东西听起来笨，但很管用。

因为它把“请认真一点”变成了流程，把“不要乱改”变成了边界，把“完成了吗”变成了外部可检查的结果。

Anthropic 在长任务 Agent 实验里把规划、实现、评估拆开，用 Planner、Generator、Evaluator 形成反馈循环。普通开发者未必要搞三个 Agent，但这个思路可以借过来：写代码的人和验收代码的人，最好不是同一个“自我感觉良好”的模型状态。

哪怕只是让 Claude Code 写完后再切一个检查视角，让它专门挑错、跑测试、检查 diff 有没有越界，也比一路生成到底要稳得多。

一个普通项目的小 Harness 可以长什么样

如果把 Harness 说得太大，它会显得像企业 Agent 平台的事，离 Vibe Coding 很远。

其实个人项目也可以有很小的 Harness。

比如你要让 AI 加一个功能，不要一上来就说“帮我实现用户设置页”。可以先让它做三件事：读现有目录，列出准备修改的文件，说明不会碰哪些模块。你确认以后，再让它动手。

实现完成后，也不要只看它的总结。让它给出验证路径：运行什么命令，打开哪个页面，点哪个按钮，看哪个状态。如果是前端功能，最好让它用 Playwright 或浏览器检查一次；如果是后端接口，就让它跑测试或给出可复现的 curl；如果没有自动化测试，至少让它明确哪些地方没验证。

再往前一步，可以把这些规则写进项目说明里：

不要为了一个小功能新增多层抽象；
不要在没确认的情况下改数据库结构；
不要引入新依赖，除非说明为什么现有工具不够；
每次提交前必须说明改动范围、验证方式和遗留风险；
如果任务超过原计划范围，先停下来问人。

这不是为了限制 AI，而是为了让 AI 的速度不会把项目带偏。

好的 Harness 不会让 Vibe Coding 变慢太多。它只是把那些迟早要付的维护成本，提前一点暴露出来。

好代码的标准，要重新往“可接手”上挪

判断一段 AI 代码好不好，我现在越来越少看它生成了多少行，而是看接手的人会不会被吓到。

一个好的 AI 辅助变更，应该让后来的维护者大致知道几件事：为什么改，改了哪里，哪些假设成立，怎么验证，失败时从哪里排查。

这就要求开发者把注意力从“产出速度”挪到“可接手性”。

你当然可以让 AI 帮你写代码，但最好也让它顺手做一些不那么显眼的事。比如把复杂函数拆小，把隐含状态写清楚，把关键路径补上测试，把临时方案标出来，把不确定的业务假设列出来，把提交说明写得像给同事看的，而不是像给自己看的。

很多时候，AI 最有价值的输出未必是第一版代码，而是它帮你把一团混乱整理成别人能继续工作的形态。

Vibe Coding 的下半场，说白了就是从“我能不能做出来”，转向“别人能不能继续维护”。前者解决创造速度，后者决定生命周期。

Harness 在这里扮演的不是高级概念，而是很朴素的交接机制。它让每次 AI 参与的变更都留下解释、验证和边界，而不是只留下一个看起来已经完成的 diff。

团队真正要防的，是无人负责的 AI 代码

企业和团队要警惕的，不是“代码由 AI 生成”这件事。

以后大量代码都会有 AI 参与，这几乎不可避免。真正危险的是：代码由 AI 生成，但没有人对它负责。

如果一个开发者只是把需求丢给 AI，接受结果，提交上线，然后在问题出现时说“这是 AI 写的”，那团队得到的不是提效工具，而是一种责任真空。

AI 不能成为责任主体。能负责的仍然是人。

谁提交，谁理解；谁合并，谁承担；谁让 AI 改了生产代码，谁就要能解释改动背后的判断。AI 可以参与实现，但不能替代工程师对系统的所有权。

我更愿意把成熟的 AI 编程流程理解成一种“带 Harness 的工程责任制”。AI 负责加速探索、生成草稿、补齐重复劳动；Harness 负责提供边界、检查点和反馈；人负责收敛方向、判断取舍、确认风险、维护长期一致性。

这套关系如果倒过来，就会变成另一种日常：AI 在前面狂奔，人类在后面追着补锅。短期很刺激，长期很累。

会收拾的人，会变得更重要

Vibe Coding 的前半场，奖励的是想象力和行动力。

你有一个点子，能快速试；你不懂某个技术栈，也能让 AI 带你过门；你没有完整团队，也能把原型搭起来。这当然是进步。

但下半场奖励的是另一种能力：收拾能力。

能不能把 AI 生成的代码收敛成清晰结构？能不能删掉多余抽象？能不能发现那些看起来能跑、实际埋雷的地方？能不能在需求变化时保持系统不散？能不能让下一个接手的人少骂两句？

这些能力过去就重要，只是没有那么显眼。AI 把写代码这件事降价之后，它们会变得更贵。

如果再结合 Harness Engineering 看，这种能力还会再往前走一步。优秀开发者不只是会收拾 AI 留下的代码，还会把反复出现的失败变成规则，把规则写进工作流，把工作流变成下一次 AI 不能轻易绕过的检查点。

这才是真正的复利。

一次手工救火，只是救一个项目；一次 Harness 改进，可以让以后十次类似任务少踩同一个坑。

未来优秀开发者的差异，可能不再是“谁能从零写出更多代码”。这件事 AI 已经大幅削平了。差异会转向更具体的地方：谁能定义好问题，谁能约束好 Agent，谁能验证结果，谁能把一堆快速生成的东西整理成可靠系统。

Vibe Coding 不会消灭软件工程。

它只是把过去被“写代码”遮住的那些部分，重新推到台前。

别只庆祝速度

我仍然喜欢 Vibe Coding。

它让更多人能动手，让想法更快落地，也让很多小团队拥有了过去不可能拥有的试错速度。没有必要因为一些失败案例，就把它说成泡沫或骗局。

但速度不是免费的。

当代码更容易生成，维护就更容易成为瓶颈；当原型更容易出现，判断什么值得长期维护就更重要；当每个人都能快速做出第一版，真正拉开差距的就是第二版、第三版，以及半年后还能不能稳稳改下去。

Vibe Coding 的前半场，是让人惊叹“怎么这么快就做出来了”。

下半场的问题更朴素，也更难回避：谁来读懂它，谁来修它，谁来删掉不该存在的部分，谁来在它出问题时承担责任。

Harness Engineering 给这个问题补了一层答案：别等残局出现以后才讨论责任。把边界、验证、日志、评估和人工确认放进流程里，让 AI 的速度跑在一条有护栏的路上。

如果这些问题没有答案，AI 写得越快，残局也会来得越快。

如果这些问题能被系统化，Vibe Coding 才不只是一次爽快的生成，而会变成一种更可靠的工程加速方式。

技术债 on 奇诺分享 | 重在分享