过去几周，我对于 Vibe Engineering 的实践有了更深的体会，今天再做一次总结。我刻意避免使用“Vibe Coding”这个词，因为当下的重点已经超越了代码本身，触及了一些更高维度的东西。本文的 AI 生成内容我会尽量控制在 5% 以内，大家可以放心阅读。
之前提到的 TiDB PostgreSQL 重写项目，现在已不再是个玩具。前几天出差的路上，长途飞行没有网络，我仔细 review 了这个项目的代码。虽然个别地方略有瑕疵，但总体质量已经很高，我认为那是接近生产水平的 Rust 代码，和我早期理解的“原型”定义截然不同。
顺带一提，我认为这个项目从一开始就选择 Rust 是无比正确的决定。Rust 的严谨性让 AI 能写出更接近 bug-free 的基础设施代码。相比之下，我另一个使用 Python 的项目（agfs及其脚本语言 ascript），在项目规模变大后，可维护性就大大降低，此时重写已经非常困难，只能硬着头皮慢慢重构。所以，现在是 2026 年，如果你要启动一个新的后端基础设施项目，Rust 应该是你的首选。
验证得差不多后，我也邀请了几位团队内的顶尖 vibe coder 加入项目。我想看看，100% 的 AI Native 研发模式，究竟能以多快的速度将这个项目推进到何种程度。无论如何，这都值得期待，应该会很有意思。
下面说说我自己最近的一些核心感受。
1. 当前关于 Vibe Engineering 的所有认知都会在 1 个月内严重过时
这并非危言耸听。哪怕我正在写的这篇文章，如果你是 2026 年 2 月之后看到，那么很遗憾，文中讨论的内容很可能已经过时。这个领域发展太快，很多今天的“最佳实践”（SOTA），下个月可能就落后了。
很有意思的是，过去很多对 Vibe Coding 嗤之以鼻的技术领袖，例如 DHH、Linus、Antirez 等，从 2025 年 12 月开始纷纷改口。我认为这很正常。从去年 12 月起，AI 编程工具和头部模型突然有了跳跃式的进步，它们对于复杂任务和大型项目的理解能力，以及生成代码的正确率，都有了极大提升。
这个进步主要源于两个方面。
一方面，头部模型在长上下文（>256K）的支持上，尤其是关键信息的召回率提升惊人。上图展示了 GPT-5.2 在长上下文中的召回表现，与 GPT-5.1 对比鲜明。
要知道，对于 Agent Coding 场景，通常需要多轮次推理加上长上下文（因为要放入更多代码和中间推理结果），才能更好地把握“大局观”。大局观的正确性，是处理复杂项目的决定性因素。在这种场景下，你可以简单计算：如果一个模型（类似 GPT-5.1）每轮的召回率是 50%，大约 3 轮后，正确的整体召回率就会降至 12.5%。而 GPT-5.2 仍然能保持在 70% 以上。
另一个进步是，主流的 Vibe Coding 工具的“上下文工程”（Context Engineering）实践日益成熟，例如 Claude Code、Codex、OpenCode。从用户体验到最佳实践，肉眼可见地越来越好，比如对 Bash 的使用、Subagent 的调度等。越来越多的资深工程师重度使用并分享经验，为这些工具的进化提供了数据飞轮。尤其是 AI 本身也在深度参与开发这些工具，迭代速度只会更快。
其实这个进步并非去年 12 月某个时间点突然爆发的“黑科技”，前几个月一直在稳步提升，只是还无法长时间离开人工干预。更像是到了那个时间点，主流 Coding Agent 的质量越过了某个临界点：在 100% 无人工干预下，完成长时间的 Agentic Loop 成为可能。
2. Hire the best (model)，否则就是在浪费生命
上面提到的所有进步，我个人感觉只体现在最顶尖的闭源头部模型中。我听到很多朋友反馈：“我感觉 AI 编程还是很傻啊？并没有你提到的那么聪明。” 我首先会反问：“你是不是只用着每月 20 美元那种入门模型？” 如果是，请先去用一阵每月 200 美元以上的 Pro Max 档次模型，或许会有惊喜。
我个人认为，目前主流模型，即使不是头部那档，作为聊天机器人处理大多数普通人的短上下文日常工作是完全足够的。哪怕是 GPT-4，在和你探讨人生道理时，也足以说得你一愣一愣。
作为人类，我们的直觉或一些简单的 CRUD 演示，已经无法评估这些模型之间的“智商”差距。但在复杂项目开发中，这种差距是极其明显的。
根据我的个人实践，当下能用来进行大型基础设施项目（如数据库、操作系统、编译器）开发的模型大概只有两个：GPT-5.2 (xhigh) 和 Opus 4.5，Gemini 3 Pro 勉强算半个。
上个月我主要使用 opencode + oh-my-opencode + Opus 4.5，但最近两周转向了 codex + gpt-5.2 的组合。下面分析一下这几个模型的一些“脾气”和调性，这仅是我的个人感受，且仅限于后端基础设施软件开发领域，仅供参考。
Opus 4.5 的风格是速度快，是个“话唠”。由于 Sonnet 4 存在严重的“奖励黑客”（reward hacking）问题，例如在解决不了 bug 时会偷偷构造作弊的测试蒙混过关，导致我很长一段时间不敢用 Sonnet 系列模型处理复杂任务。但这一点在 Opus 4.5 中解决得很好，即使模型“冥思苦想”各种尝试都搞不定，它也没有选择作弊，这让我放心不少。不过，Opus 的问题是推理（reasoning）和调查（investigation）的时间太少，动手太快，以至于发现不对时，又返回头去确认假设和研究。这种特性催生了像 ralph-loop 这样的技巧，即同样的提示词在 Claude Code 结束后，又通过停止钩子（stop hook）重新调用，再完整走一遍流程，不断逼近最终结果。
相比之下，GPT-5.2 更像一个更加小心谨慎、话不多的角色。我最开始用 Codex 的体验其实不算太好，因为我一直觉得它有点太慢了。主要是因为我习惯用它的 xhigh 深度思考模式。在真正开始写代码之前，它会花很长时间去浏览项目里的各种文件和文档，做大量准备工作。可能也因为 Codex 的客户端不会明确告知它的计划和预计耗时，所以显得过程特别漫长。有时一些复杂任务，它前期的调查可能就要花上一到两个小时。但经过长时间思考后，它完成的效果通常更好，尤其是在项目大体框架已经稳定时。Codex 考虑得更周全，最终体现为更少的 bug 和更好的稳定性。
至于第三个顶级模型 Gemini 3 Pro，虽然我知道它的多模态能力非常吸引人，但就复杂任务的编码场景而言，至少从我个人的体验来看，它的表现并没有 Opus 4.5 和 GPT-5.2 那么强。不过它确实针对快速的前端项目 Demo 和原型制作做了一些优化，再加上它的 Playground 模式，让你在需要一些炫酷的小 Demo 或前端项目时能更快实现。
一个比较反直觉的事情是：过去我们常说 Vibe Coding 只能搞一些比较简单的事情，比如上面提到的小 Demo 或 CRUD 项目。你会看到网上各种 KOL 都在做这种小原型，于是大家觉得对于后端核心基础设施代码，当前 AI 还是搞不定。我以前也这么想，但从去年 12 月份开始，这个结论可能需要修正了。
原因是，这类基础设施代码通常由顶级工程师长期精雕细琢而成，它们有清晰的抽象、良好的测试，代码本身经过多轮重构后也相当精炼。所以，当 AI 具备足够的上下文空间、更好的推理能力、更成熟的 Agentic Loop 以及高效的工具调用时，这类 数据库/中间件/技术栈 代码的开发和维护，反而能最有效地利用这些顶尖大模型的“智商”。
在实际工作中，我经常会让多个 Agent 互相协作，或者使用复杂的工作流把它们编排在一起，并不会让一个模型完成所有事情。后面我会再分享一些具体例子。
3. 人在什么时候进入？扮演什么角色？
上面提到，这些顶级模型配合主流 Vibe Coding 工具，基本上已经能超越大多数资深工程师的水平。这不仅体现在能写出 bug 更少的代码，也体现在代码评审中能发现更多人类工程师可能忽略的问题，毕竟 AI 真的会一行一行仔细看。
那么，人在这个过程中扮演什么角色？哪些阶段必须由人来做？
根据我的实践，第一当然是提出需求。毕竟只有你才知道你想要什么。这听起来很显然，但有时也挺难，因为人很难从一开始就准确描述自己想要的东西。这时我会用一个偷懒的办法：让 AI 来角色扮演。比如，在开发 PostgreSQL 版本的 TiDB 时，我就让 AI 假设自己是一个资深的 Postgres 用户，从开发者视角告诉我，有哪些特性是至关重要、必须实现且投资回报率（ROI）比较高的，让它列出 N 个这样的功能点。然后，我再和 AI 对这些需求逐个打磨。这其实是一个高效的冷启动方法。
第二，在需求提出后，现在的 Coding Agent 大多会有一个规划阶段（Planning），反复确认你的需求。这个过程中有一些技巧：不要给 AI 太具体的方案，而是让 AI 来生成方案，你只关注最终结果；提前告诉 AI 有哪些基础设施和环境上的约束，让它少走弯路。
另外，我通常会在提出需求的第一阶段，就要求 Agent 执行一些关键动作。比如，无论接下来做什么，都要把计划和待办列表放在一个 work.md 或 todo.md 这类文件里。每完成一个阶段的工作，就把上一阶段的经验教训更新到 agents.md 里。第三点是，当一个计划完成且代码合并后，把这个工作的设计文档添加到项目的知识库中（例如 .codex/knowledge）。这些内容我都会在一开始提需求时就放进去。
第二阶段是漫长的调查、研究和分析。这个阶段基本不需要人做什么，Agent 的效率比人高得多，你只需要等待。唯一需要注意的是，在研究过程中，我通常会告诉模型它拥有“无限的预算和时间”，尽可能充分地进行调研。另外，如果你的模型有推理深度参数，我建议在这个阶段全部调到 xhigh 级别。虽然这会让过程变慢，但在此阶段多“烧”一些 token，做好更好的规划，了解更多的上下文，对后续的实现阶段大有裨益。
实现阶段没什么特别好说的。我现在基本不会一行行去看 AI 写的代码。我觉得在实现阶段唯一要注意的是：要么就让 AI 完全去做，要么就完全自己做，千万别混着来。目前我倾向于完全零人工干预的模式，效果更好。
第四阶段人就变得非常重要了，那就是测试和验收结果。在我个人与 AI 开发项目的过程中，我 90% 的时间和精力都花在了这个阶段：即如何评估 AI 的工作成果。我认为在 Vibe Engineering 中：There's a test, there's a feature。只要你清楚如何评估和测试你想要的东西，AI 就一定能把它做出来。
另外值得注意的是，AI 在实现过程中会自动帮你添加很多单元测试。说实话，这些单元测试在微观层面基本都能通过，毕竟 AI 写这种局部代码时已经很难出 bug。但 AI 不擅长的是集成测试、端到端测试。比如在开发一个 SQL 数据库时，哪怕每个细节的单元测试都没问题，但整合到一起时，集成测试可能会出错。
所以，在开始实现大目标前，我一定会先和 AI 一起搭建一个方便的集成测试框架，并提前准备好测试基础设施，收集和生成一些现成的集成测试用例，尽量做到一键运行。这样在开发阶段就能事半功倍。关于如何使用这些测试基础设施的信息，我都会在正式开始前就固化在 agents.md 里，这样就不用每次沟通时都重复告知。关于测试用例的来源，我的经验是你可以让 AI 帮你生成，但一定要告诉它生成的逻辑、标准和目的。另外，千万不要把生成测试的上下文，和实际进行开发工作的 Agent 的上下文混在一起。
第五个阶段是重构和拆分。我发现当前的 Coding Agent，在面对单一模块复杂度超过大约 5 万行代码之后，就很难在一个提示（1-shot）里一次性解决问题（但反过来，只要任务复杂度控制在这个阈值之下，在一个足够好的初始提示驱动下，很多事情确实可以做到 1-shot 通过）。Agent 通常不会主动去做项目结构和模块边界的治理。你让它实现功能，它恨不得把所有东西都塞进几个几万行的大文件里。短期看很快，长期就是技术债务爆炸。我自己在这个阶段的做法通常是先停下来，凭借自己的经验进行模块拆分，然后在新的 后端 & 架构 下进行一到两轮重构。之后，又可以高并发地进行开发了。
4. 多 Agent 协同编程的一些实践
前面提到，我现在使用 Coding Agent 时，通常不会只用单一一个。我的工作流会尽量让多个 Coding Agent 同时工作。这也是为什么有时在一些项目上会花掉好几千美金——你必须把并发跑起来。
当然，提升并发和吞吐是一方面。但另一方面，我认为让不同的 Agent 在不共享上下文的前提下互相评审工作，能显著提高质量。这就像管理研发团队时，你不会让同一个人既当运动员又当裁判。Agent A 写的代码交给 Agent B 来评审，往往能发现一些 A 看不到的问题。通过这样的循环往复，你会更有信心。
例如，我现在实际工作中一个用得比较好的工作流是这样的：
- 设计规划：首先让 GPT-5.2 在 Codex 环境下生成多个功能的设计文档，做出详细的设计和规划，并将这些规划文档保存下来。
- 实现：然后，依然用 Codex，根据这些需求文档一个一个去实现功能。在实现过程中，如前所述，记录待办项、经验教训，并在接近完成时（代码通过测试、准备提交之前）停下。
- 交叉评审：将当前的工作区交给另一个 ClaudeCode 或 OpenCode（不提供原始设计上下文），让 ClaudeCode 来评审当前未提交的代码，并根据代码本身提出修改建议。
- 反馈与修正：再将这些建议发回给 Codex，让 Codex 评论这些建议，如果合理就修改代码。
- 二次确认：改完之后，再让 ClaudeCode (Opus 4.5) 进行二次评审，直到双方都认为代码质量达标，再提交到 Git，标记任务完成，更新知识库，然后进入下一个功能的开发。
另外，在一个大型项目中，我会同时开启多个 Agent（在不同的 Tmux 会话中）并行开发多个功能，但我尽量让它们负责完全不同的模块。比如一个 Agent 修改内核代码，另一个 Agent 做前端界面，这样就能分开进行。如果你需要在一份代码上做一些彼此不太相关的工作，可以利用 git 的 worktree 功能，让多个 Agent 在不同的 git 分支上各自工作，这也能快速提升吞吐量。
5. 未来的软件公司与组织形态
未来的软件公司会是什么形态？从我自己的实践和与一些朋友的交流来看，至少在当下，团队中 Coding Agent 的 Token 消耗呈现出非常符合二八定律的分布。最头部的、AI 用得最好的工程师，他们消耗的 Token 可能比剩下 80% 的工程师加起来还要多。
而且，Coding Agent 对不同工程师产出（质量、吞吐）的增益是不同的，这个方差非常大。对于用得最好的一群人，他们的增幅可能是 10 倍，但对于普通人，可能只有 10%。目前唯一的瓶颈是人工的代码评审和一些无法被自动化的线上运维工作（不过我觉得这也快了）。这样的特点使得头部工程师在 AI 协助下可以无边界地工作，也就是说，未来会出现越来越多的“一人军队”。目前我认为这与 Token 消耗是正相关的：你能花掉多少 Token，大致代表你能做得多好。
我还发现一个有趣的现象：同样是 10 倍效率的工程师，他们各自的 Vibe Coding 工作流和最佳实践其实并不相同。这意味着，两个顶尖的 Vibe Coder 很难在一个项目的同一个模块中协作。这种工作方式更像是“头狼”带着一群“狼群”（Agents），在自己的“领地”里耕耘。但同一片领地里很难容纳两匹头狼，会造成 1+1 < 2 的效果。
在这样的组织形态下，我觉得传统意义上的“团队协作方式”会被重新定义。过去我们强调的是多人在同一个代码库、同一个模块里高频协作，通过评审、讨论、同步来达成共识。但在 Vibe Engineering 这种模式下，更有效的方式反而是强解耦的并行。管理者要做的是把问题切分成足够清晰、边界明确的“领地”，让每一个头部工程师带着自己的 Agent 群，在各自的领域里做到极致。
从管理的角度看，这是一个挺大的挑战。因为你不能再使用统一的流程、统一的节奏去约束所有人。对顶尖的 Vibe Coder 来说，过多的流程和同步反而会显著拉低效率，甚至抵消 人工智能 带来的增益。管理者更像是在做“资源调度”和“冲突隔离”：确保不同“头狼”之间尽量少互相干扰，同时在必要的时候，能够通过清晰的接口、契约和测试来完成协作。
正因为上述种种，AI-Native 的研发组织其实很难自底向上从一个非 AI-Native 的组织中生长出来。因为大多数开发者面对变革时的第一反应并非拥抱，而是回避和抵触。但时代的进步不会因个人意志而转移，只有主动拥抱和被动拥抱的区别。
大概就写到这里吧。总的来说，在这样的大环境下，对个人而言意味着一场深刻的转变。就像我之前在朋友圈提到的，我身边一些最优秀的工程师已经陷入了或多或少的存在主义危机。
但是，作为具体的建造者（Builder），我是兴奋的。因为“造物”在当下的门槛变低了许多。如果你能从“造物”中获得成就感和人生的意义，那么恭喜你，你活在一个最好的时代。但反过来，作为一个抽象的“人”来说，我又是悲观的。人类是否准备好面对这样的工具？以及这种工具将对社会和整个人类文明带来的冲击？
我不知道。
技术演进永不停歇，但真正的价值创造和深度思考，依然是开发者的核心壁垒。欢迎在 云栈社区 交流你关于 Vibe Engineering 的实践与思考。
发表于 3 天前
|
查看: 13|
回复: 0
