转载自：https://mp.weixin.qq.com/s/8kY6grrMrunTzmz1Oq5MSg（标题：Vibe Engineering in 2026.1）
将来的软件公司和组织形态
作者：PingCAP 结合开创人兼 CTO 黄东旭
其其实上一篇介绍 OpenCode 之后（重度应用 opencode 后激发的一些关于 agent 的感触）, 获得了很多同伙的存眷和反馈, 并且这几周以前我对于 Vibe Engineering 的实践有了更多的领会, 今天再次总结一下。其实也能看出来我避免应用 Vibe Coding 这个词，是因为当下的重点已经不再是代码，而是一些更高维度的器械。别的，本文的 AI 含量我会尽量控制在 5% 内，可以宁神浏览😄。
趁便报告请示下，上一篇提到我开端的 TiDB Postgres 重写项目已经不再在是个玩具。在前几天出差的路上, 因为长途飞翔没有收集, 我细心 review 了一下这个项目标代码, 固然一些处所略有瑕疵, 然则总体质量已经很高, 我认为已经是接近临盆程度的 rust 代码，和以前我懂得中的早期原型的定义很不一样。趁便提一句, 我认为这个项目从一开端就选择 rust 是一个无比精确的决定, rust 的严谨性让 AI 能写出更接近 bug free 的 infra code (比较我另一个项目 agfs 的 shell 和它自带的脚本说话 ascript，因为这项目应用 python，项目变大年夜后，可保护性就大年夜大年夜降低，但此时重写已经很艰苦，只能捏着鼻子慢慢重构)，所以如今已经是 2026 年了， 假如你要再启动一个新的 backend infra 项目, rust 应当是你的第一选择。
TiDB PostgreSQL Cloud
验证差不多后，我也邀请了几位我团队内的几个顶尖的 vibe coder 参加项目, 看看 100% 的 AI Native 研发模式能在多快把这个项目推动到何种程度，无论若何都很想看看，应当会很有意思。
下面说说本身比来的一些感触感染。
当前关于 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% 以上。
因为上面的各种，AI-Native 的研发组织其实很难自底向上从一个非 AI-Native 的组织中发展出来，因为大年夜多半开辟者面对变革的时刻的第一反响其实并不是拥抱，而是躲避和抵触，然则时代的进步不会因为小我的意志转移，只有主动拥抱和被动拥抱的差别。
别的一个进步是主流的 Vibe Coding 对象的 Context Engineer 实践日益成熟，例如 Claude Code / Codex / OpenCode。从用户体验到最佳实践，肉眼可见的越来越好，例如对于 Bash 的应用，Subagent 等，这方面越来越多的资深 Engineer 的重度应用和经验分享会对这些对象的进化供给数据飞轮，尤其是 AI 也在深度的开辟这些对象，迭代速度只会更快。
其实这个进步也并不是客岁 12 月那个时光点的忽然什么黑科技爆发，其实前几个月一向在进步，不过还不克不及长时光分开人工干涉，更像是那个时光点，主流 Coding Agent 的质量跨越了一个临界点：100% 的无人工干涉下完成长时光的 Agentic Loop 成为可能。
Hire the best (model), 不然就是在浪费生命
上面所有提到的进步，我小我感到只反应在了最顶尖的闭泉源部模型中。我听到很多同伙和我反馈到：“我感到 AI 编程照样很傻啊？并没有你提到那么聪慧”，我起首会反问，你是不是只是用着 $20 一个月那种入门模型？假如是的话，那先去用一阵 $200 以上的 Pro Max 档次的，也许有惊喜。
我小我认为，今朝主流的模型，即使并非头部那档，作为 chatbot 处理大年夜多半通俗人的短高低文的日常工作是完全足够的，哪怕是 GPT-4 在和你讲人闹事理的时刻也已经足够把你说得一愣一愣了。
作为人来说，我们的直觉或者是一些简单的 CRUD Demo 已经无法评估这些模型之间的智商差距了。然则在复杂的项目标开辟中，这个差距是极端明显的。
根据我小我的实践来说，当下能用来进行大年夜型 Infra 项目（数据库，操作体系，编译器等）开辟的模型大年夜概就两个：GPT-5.2 (xhigh) + Opus 4.5，还有半个算是 Gemini 3 Pro。
大年夜概上个月我重要用着 opencode + oh-my-opencode + Opus 4.5 然则比来两周转向到了 codex + gpt-5.2 的组合，下面分析一下这几个模型的一些性格和调性，仅仅是小我感触感染，并且是在后端 Infra 软件开辟这个范畴，仅供参考。
Opus 4.5 的风格是速度很快，是个话唠，因为 Sonnet 4 有严重 reward hacking 问题，例如是在解决不了 bug 的时刻会悄悄的构做作弊的测试然后糊弄以前，所以导致很长一段时光我都不太敢用 Sonnet 系列模型干复杂的工作，然则这点在 Opus 4.5 中解决得很好，即使在模型冥思苦各类测验测验想都搞不定的情况下也没有选择作弊，让我宁神不少，然则 Opus 的问题是 reasoning 和做 investigation 的时光太少，着手太快，以至于发明纰谬的时刻，又返回头确认假设和研究，如许的特点催生了像 ralph-loop 如许的奇技淫巧。比方说，同样的一个 prompt 在 Claude Code 停止后又经由过程 stop hook 从新调用，再完全走一遍流程，赓续地切近亲近最终的成果。
比拟之下，GPT-5.2 更像是一个加倍当心谨慎、话不多的角色。我最开端用 Codex 的体验其实不算太好，因为我一向认为它有点太慢了。主如果因为我习惯用它的 xhigh 深度思虑模式，在真正开端写代码之前，它会花很长时光去浏览项目里的各类文件和文档，做很多预备工作。可能也是因为 Codex 的客户端不会告诉你它的筹划和大年夜概须要多久，所以就显得过程特别长。有时刻一些复杂的义务，它前期的查询拜访可能就要花上一到两个小时。然则经由长时光思虑后它完成的后果平日是更好的，尤其是在一个项目标大年夜体框架已经稳定，Codex 推敲得更周全，最终也表现出更少的 bug 和更好的稳定性。
其实一个比较反直觉的工作是，以前我们经常说 Vibe Coding 只能搞一些比较简单的工作，比如上面那些小 Demo 或 CRUD 项目，你会看到网上各类各样的 KOL 其实都在做这种小原型，反而大年夜家认为对于一些像后端这种核心的基本举措措施代码，当前 AI 照样搞不定的。我以前也这么想，但从客岁12月份开端，这个结论可能须要修改了。这里面的原因是，其实这类基本举措措施的代码平日是由顶级工程师经久精雕细琢而成，它们有清楚的抽象、优胜的测试，甚至代码本身经由多轮重构后也相当精华精辟。所以当 AI 具备足够的高低文空间 + 更好的推理才能 + 更成熟的 Agentic Loop + 高效的对象调用时，这类 Infra 代码的开辟和保护反而是能最有效地应用这些顶尖大年夜模型的智商的场景。
在实际的工作中，我经常会让多个 Agent 互相协作，或者应用一些复杂的工作流来把它们编排在一路，并不会让一个模型来完成所有的工作。后面我会再分享一些我本身实践中的具编制子。
人在什么时刻进入? 扮演什么角色?
上面提到了，这些顶级模型再合营主流的 Vibe Coding 对象，根本上已经能超出大年夜多半资深工程师的程度了。这不仅表如今能写出更少 bug 的代码，也表如今在 review 中能发明更多人类工程师可能看不到的问题，毕竟 AI 真的会一行一行细心看。
对了，这周 PingCAP 将举办新品分享会，开创人全部出席：2026 平凯数据库新品分享会，TiDB 开创人齐聚。
所以人在这个过程中扮演什么样的角色，哪些阶段只有人才能做？根据我本身的实践来说，第一当然是提出需求，毕竟只有你才知道你想要啥，这很显然，然则有时确切也挺难的，毕竟人很难从一开端就精确描述本身想要什么，这时刻我会用一个偷懒的办法：让 AI 来角色扮演，比方说，我在开辟 PostgreSQL 版本的 TiDB 时，我就让 AI 假设本身是一个资深的 Postgres 用户，从开辟者的视角告诉我有哪些特点是异常重要、必定要实现并且 ROI 比较高的，让它列出 N 个如许的功能点，然后 AI 就会根据它的懂得生成一个需求列表，接下来你再和 AI 对这些需求逐个打磨，这其实是一个高效冷启动的办法。
对于第三个顶级模型，也就是 Gemini 3 Pro。固然我也知道它的多模态才能异常吸惹人，但就复杂义务的 Coding 场景而言，至少从我小我的体验来看，它的表示并没有 Opus 4.5 和 GPT-5.2 那么强。不过它确切针对一些快速的前端项目 Demo 和原型制造做了一些优化，再加上它的 Playground 模式，让你在须要一些炫酷的小 Demo 或前端项目时能更快实现。
第二是在需求提出后，如今的 Coding Agent 大年夜多都邑和你有一个筹划阶段（Planning），会反复确认你的需求。在这个过程中其实有一些技能，比如不要给 AI 太具体的筹划，而是让 AI 来生成筹划，你只须要存眷最终你想要的成果；提前告诉 AI 有哪些基本举措措施和情况的问题，让它少走弯路。
别的，我平日会在提出需求的第一阶段就请求 Agent 做的一些关键动作。比如无论接下来做什么，都要把筹划和 todo 列表放在一个 work.md 或 todo.md 这类文件里。还有，每完成一个阶段的工作，就把上一阶段的经验教训更新到 agents.md 里。第三点是当一个筹划完成并且代码归并后，把这个工作的设计文档添加到项目标常识库中（.codex/knowledge）。这些都是我会在一开端提需求时就放进去的内容。
第二个阶段就是漫长的查询拜访、研究和分析的阶段。这个阶段其实根本上不须要人做什么工作，并且 Agent 的效力比人高得多，你只须要等着就好。独一须要留意的就是在 Research 的过程中，我平日会告诉模型它拥有无穷的预算和时光，尽可能充分地进行调研。别的，假如你的模型有推理深度的参数的话，我建议在这个阶段把它们全部调到 xhigh 的级别。固然这会让过程变慢，但在这个阶段多烧一些 token、做好更好的筹划、懂得更多高低文，对后续的实现阶段会更有赞助。
实现阶段没什么特别好说的，反正我如今根本不会一行行去看 AI 的代码。我认为在实现阶段独一要留意的就是，要么你就让 AI 完全去做，要么你就完全本身做，切切别混着来，我今朝是偏向于完全零人工干涉的模式后果更好。
第四个阶段人就变得异常重要了，那就是测试和验收成果的阶段。其其实我小我和 AI 开辟项目标过程中，我 90% 的时光和精力都花在了这个阶段：也就是若何评估 AI 的工作成果，我认为在 Vibe Coding 时：There's a test, there's a feature，你只要知道若何评估和测试你要的器械，AI 就必定能把器械给你做出来。别的值得留意的是，AI 在实现过程中会主动帮你添加很多单位测试，但说实话，这些单位测试在微不雅层面根本都能经由过程，毕竟 AI 写这种局部代码时已经很难出 bug。但 AI 不善于的是集成测试、端到端测试。比如在开辟一个 SQL 数据库时，哪怕每个细节的单位测试都没问题，但整合到一路时集成测试可能会掉足。所以我在完成大年夜目标前，我必定会先和 AI 一路做一个便利的集成测试框架，并提前预备好测试的基本举措措施，收集和生成一些现成集成测试的用例，尽量一键能运行那种，如许在开辟阶段就能事半功倍，并且关于若何应用这些测试的基本举措措施的信息，我都邑在正式开端前就固化在 agents.md 里，如许就不消每次沟通的时刻都再告诉它该怎么测试了。关于测试从哪来的问题，我本身的经验是你可以让 AI 帮你生成，但必定要告诉它一些生成的逻辑，标准和目标，别的就是切切不要把生成测试的 Context 和实际进行开辟工作的 Agent 的 Context 混在一路。
第五个阶段是重构和拆分。我发明当前的 Coding Agent 在面对单一模块复杂度跨越大年夜约 5 万行代码之后，就开端很难在 1-shot 里把问题一次性解决掉落（但反过来这也意味着，只要义务复杂度控制在这个阈值之下，在一个足够好的 first prompt 驱动下，很多工作确切可以做到 1-shot AC），Agent 平日不会主动去做项目构造和模块界线的治理，你要它把功能做出来，它恨不得把所有器械都写进几个几万行的大年夜文件里，短期看似很快，经久就是债务爆炸。我本身在这个阶段的做法平日是先停下来，用本身的经验进行模块拆分，然后在新的架构下进行 1～2 轮的重构，之后又可以高并发度的进行开辟了。
多 Agent 协同编程的一些实践
前面提到我如今应用 Coding Agent 的时刻，平日不会只用一个，我本身的工作流会尽量让多个 Coding Agent 同时工作。这也是为什么有时刻在一些项目上会花掉落好几千美金，因为你必须把并发跑起来。当然，并发和吞吐是一方面，但另一方面我认为让不合的 Agent 在不共享高低文的前提下互相 Review 工作，其实能明显进步质量。这就像在治理研发团队时，你不会让同一小我既当活动员又当裁判。相当于 Agent A 写的代码交给 Agent B 来 Review，往往能发明一些 A 看不到的问题。经由过程如许的轮回来去，你就会更有信念。
例如，我在实际工作中如今用得比较好的一个工作流是如许的：起首让 GPT-5.2 在 Codex 下生成多个功能的设计文档，做出具体的设计和筹划，第一阶段把这些筹划文档都保存下来。然后在第二阶段，依然用 Codex 根据这些需求文档一个一个去实现功能。在实现的过程中，就像我前面提到的那样，记录 To-Do、经验教训，并在接近完成的时刻，在代码经由过程测试并预备提交之前停下，把当前的工作区交给另一个 ClaudeCode 或 OpenCode，在不供给高低文的情况下，让 ClaudeCode 来 Review 当前还未提交的代码，根据设计提出修改建议。然后再把这些建议发还给 Codex，让 Codex 来评论这些建议，假如有事理就修改代码。改完之后，再让 ClaudeCode (Opus 4.5) 那边再次 Review，直到两边都认为代码已经写得很不错了，再提交到 Git 上，标记这个义务完成，更新常识库，然落后入下一个功能的开辟。
别的在一个大年夜型项目中我会同时开多个 Agent (in different Tmux) 并行开辟多个功能，但我尽量让它们负责完全不合的模块。比如一个 Agent 修改内核代码，另一个 Agent 做前端界面，如许就能分开进行，假如你须要在一份代码上做一些彼此不太相干的工作时，可以应用 git 的 worktree 让多个 Agent 在不合的 git 分支上各自工作，如许也能快速晋升吞吐量。
将来的软件公司会是什么形态呢？反正从我本身的实践和与一些同伙的交换来看，至少在当下，团队顶用 Coding Agent 的 token 的消费出现出一个异常相符二八定律的分布，也就是说，最头部的用 AI 用得最好的工程师，他们消费的 token 可能比剩下 80% 的工程师加起来还要多，并且 Coding Agent 对于不合工程师产出（质量，吞吐）的增益是不一样的，这个方差异常大年夜，也就是对于用的最好的一群人，他们的增幅可能是 10x，然则通俗人可能也就是 10%，并且独一的瓶颈是人工的 code review 和一些无法被主动化的线上运维工作（我认为也很快了）并且如许的特点可以或许让这些头部的工程师在 AI 的协助下可以无界线的工作，也就是会有越来越多的 one-man army 出现，只是今朝我认为和 token 消费是正相干的，你能花掉落若干 token，大年夜致代表你能做的多好。
别的我发明一个很有趣的现象，同样是 10x 的工程师，他们各自的 Vibe Coding 工作流和最佳实践其实并不雷同。也就意味着，两个顶尖的 Vibe Coder 是很难在一个项目中（的同一个模块）协作。这种工作方法更像是头狼带着一群狼群（Agents），在一片本身的领地里面垦植，然则同一片领地里很难容纳两匹头狼，会造成 1+1 < 2>
在如许的组织形态下，我认为传统意义上的“团队协作方法”会被从新定义。以前我们强调的是多人在同一个代码库、同一个模块里高频协作，经由过程评审、评论辩论、同步来杀青共鸣；但在 Vibe Engineering 这种模式下，更有效的方法反而可能是强解耦的并行。治理者要做的是把问题切分成足够清楚、界线明白的“领地”，让每一个头部工程师带着本身的 Agent 群，在各自的范畴里做到极致。
从治理的角度看，这其实是一个挺大年夜的挑衅。因为你不克不及再用同一流程、同一节拍去束缚所有人。对顶尖的 Vibe Coder 来说，过多的流程和同步反而会明显拉低效力，甚至抵消 AI 带来的增益。治理者更像是在做“资本调剂”和“冲突隔离”：确保不合头狼之间尽量少互相干扰，同时在须要的时刻，可以或许经由过程清楚的接口、契约和测试来完成协作。
大年夜概就写到这里吧，总的来说，在如许一个大年夜情况下，对小我而言意味着一场深刻的改变，就像我上周在同伙圈里提到的，我身边最好的工程师们有一些已经陷入了或多或少的存在主义危机。然则作为具体的 Builder 的我来说是高兴的，因为造物，在当下，门槛变低了很多，假如你能从造物中能获得成就感和找到人生的意义，那恭喜你，你活在一个最好的时代。但反过来，作为一个抽象的 “人” 来说，我又是消极的，人类是否预备好面对如许的对象？以及如许对象带来的对于社会和整小我类文明的冲击？我不知道。
发表评论 取消回复