大扁平化时代
神译局是36氪旗下编译团队，关注科技、商业、职场、生活等领域，重点介绍国外的新技术、新观点、新风向。
编者按：告别堆叠人力的传统开发模式，当智能成本每四个月折半，未来属于用Token淹没瓶颈的“大扁平化”时代.。文章来自编译。
大模型觉醒
过去一年里发生了一件大多数人尚未完全消化吸收的事。大模型在编程领域达到了超越人类的水平——不是展现出某种趋势，不是大致接近，而是此时此刻真正超越了人类。我曾高居 Google Code Jam、Topcoder 和 ACM ICPC 等大赛的印度榜首，但前沿模型已将我远远甩在身后。我每天都对此心生敬畏。
如此强大的模型早已不再适合局限在你的个人电脑里。每一次新版本的发布，模型都能更加持久地自主运行、规划自身工作、并派生出专属的辅助程序。一台必须摆在你手边并保持开启的机器，绝不是承载这一切的正确归宿。软件开发的未来在于云端。本文接下来的内容，将阐明其背后的逻辑与所需的条件。
你还是Loop的一环（Humans in the loop）
每一次迭代，模型运行的独立性和效率都会越来越高。可是，走进任何一家工程组织，你依然会看到人类被束缚在流程之中：提示输入、审查代码、纠正偏差，死死被绑在机器前。我亲历过这一切。我曾深度使用 Claude Code，并像保姆一样全程盯防每一个会话，可过度干涉反而抹杀了速度优势；而听之任之、无人监管，又容易偏离既定方向。最新的模型终结了其中的绝大部分困境。它们可以无人值守地运行数小时，自行规划工作、精简上下文，并在汇报成果前自主校验输出。那么，保姆式的监管就此终结了吗？并没有。就像所有的瓶颈一样，它只是提升到了更高的维度。过去你监管的是单个会话，现在你监管的是整个系统：你是否敢于信任一份未经你逐行审核的合并请求？二十个自主会话能否在不发生冲突踩踏的前提下同时作用于同一个代码库？在成果呈递给你之前，它是否在真实的软件栈中验证过？
你渴望极致的并行能力。你希望合上笔记本电脑，回来时工作已然搞定。当你越是被移出这个循环，工作就越是必须在云端运行。
既然如此，为何大家尚未全面拥抱云端？因为目前提供给他们的云端是盲的。Agent 固然能在某处的虚拟机上编写代码，却无法运行你的应用，也无法拉起你所有的服务来进行端到端测试。于是，每一个分支最终还是得拉回本地笔记本进行校验，你便再次被拉回那个循环。云端必须切实解决端到端的运行与测试难题，才有可能真正为你节省时间。
整个公司正在被扁平化
编写代码不再是难题所在。过去，工程师接收管理者的指令，听取产品经理的需求，然后贯彻执行；信息在层层传递中不断衰减，迭代周期被无休止地拉长。那样的时代已经一去不复返了。当你能在数分钟内将构想转化为上线代码，稀缺的资源便转移到了新颖的创意、直接从客户处萃取需求的能力，以及启动下一次实验的魄力。我曾是 Rippling的联合创始人兼 CTO。近来，我每周交付的代码行数甚至超越了我手下的工程师——这并非因为我技术更精湛，而是因为客户在通话中抛出构思，这些构思便直达开发会话，甚至在通话挂断前就已完成代码合并。需求积压（Backlogs）本就不应继续存在，一个构想理应在数小时内转化为生产力成果。
沿着这种转变一路延伸，跨过你的办公桌，它将彻底重塑整家公司的格局。每家公司都存在一个固定的“人类细胞边界”：即直面外部世界的接口。销售、客户关系，以及那些必须由人类代表公司去面对另一个人类的契机。这些领域暂且保持人类的主导……至少眼下如此。而在边界内部，规划、设计、架构、审查、执行，一切都在向 Harness（控制框架，即驱动工作运行的系统）收拢坍缩。组织架构图与其说是缩减，不如说是发生了形态重塑。内部或许只需要一个人，或者都不需要人了。这就是大扁平化。
因此，工作本身迈向了“元（Meta）”层面。你不再拘泥于解决眼前具体的任务，转而开始探寻为何这个有机体无法自主解决该任务。每个人的核心工作变成了自我分析与剖析：你的脑海中存在哪些未曾写入代码库的决策框架？你如何判定优先级？你需要调取哪些数据？以及你会做出怎样的独到抉择？这种“判断力”成为了唯一稀缺的资产。那么，它究竟该归于何处？
Harness（控制框架）
若如今的工作已蜕变为将判断力代码化，而非机械地执行操作，那么这种判断力便需要一个载体。它落脚于 Harness 中。Harness 是唯一的场域，让你的工程准则不再仅仅停留在脑海，而是如实运转于每一个会话之中：你如何分流问题、你独有的架构决策、以及绝不妥协的交付门槛。若仅仅将它们写进文档，次日便会沦为无人问津的陈迹；若将其写入 Harness，即便你不在场，它也能在你未曾瞩目的工作中将你的判断力贯彻千万次。这是“元工作”的具象化。你的原则在传达给新员工时难免会有损耗，半数内容甚至从未口头表达；但传达给 Harness 时却是完好无损的，并且能产生复利效应——因为你所编码的每一次决策，都意味着你无需再做第二次。这是竞争对手绝无法抄袭的核心壁垒，因为它是写下来的、关于你公司的具象形态。
Harness 必须专属于你的第二个原因在于：模型的每一次发布，都在吞噬其下方的技术层。手写的上下文管理、自定义的 Sub-agent 配置、人们绞尽脑汁折腾出的巧妙规避方案……AI 实验室密切关注着哪些方案有效，并直接将其集成内置。因此，你本季度所倚仗的奇技淫巧，下季度就会变成系统默认功能。押注于机制，实质上是在与 AI 实验室博弈，而每次新模型发布你都注定会输。然而，有两样东西是他们在结构上绝无法提供的：其一是你的判断力，即只有你才会做出的决策（这正是上文的核心所在）；其二则是中立性。现在的实验室 Harness 固然能调度自家的 Sub-agent 并运行自家的审查程序——这是货真价实的工程设计，也确实优秀——但它们始终局限于单一家族，专为中位数水平的代码库调校，因为没有任何一家实验室会把你的工作路由给竞争对手的模型。由于我们不训练任何模型，这一层得以保持绝对中立：你的判断力，可以在各大实验室顶尖模型之间灵活穿梭，哪款模型本周在特定任务中拔得头筹，工作便流向何处。我们不训练模型，实验室交付的是他们的偏好，而唯有你能交付属于你自己的偏好。
剖析瓶颈，用 Token 将其淹没
那么，该如何构建这样的 Harness？绝非靠更聪明的模型，亦非靠更迅捷的自动补全。早已迈入这种模式的人们趋同于同一种方法：针对自身代码库精细调校配置，并在开发生命周期中最容易让你摔跟头的环节上，疯狂地倾泻 Token。业内对此有个流行词：Tokenmaxxing（Token最大化）。
悟透此道的人已然跨入全新范式。团队人数保持精简，信息对称度与构想效率居高不下。那些因队列爆满而被你的团队推托数月的特性，如今一觉醒来便已完工。以下是我目前部分客户的真实写照：
一位产品经理独自充当了整支研发团队。他每天要充值 1000 美元的 Token，合并代码的速度超越了他曾管理过的任何团队。
一位拿到风投的独角戏创始人，决定彻底放弃招人。
“座席”是错误的算力度量单位，“Token”才是正确的单位。其准则极其明确：每一次模型迭代，都去剖析人类时间究竟消耗在了何处、瓶颈位于何方，然后用 Token 猛砸，直到瓶颈消除。终点线在于：以一段提示词起始，中间尽可能减少人类干预，最终以一次性成功合并（One-shot merge）告终。人类的时间才是瓶颈，Token 绝非瓶颈。
将这个准则贯彻到底本身就是一项全职工作。搭建基础设施、配置 Sub-agent、为各项任务分配合适的模型、接入对抗性审查机制，而后在每隔几周新模型发布、最佳模型宝座易主时重调一切——绝大多数团队的薪酬名单里并没有这样的岗位，而他们手工搭建的东西往往在一个季度内就会过时。Opus 4.8 在 5 月底重塑了行业格局；两周后 Fable 5 再次改写规则，却又在问世数日内悄然隐退。无论你上周针对什么做好了调校，本周都可能横空出世更好的替代方案。
从一段提示词到最终合并 Pull Request，中间隔着六大瓶颈：机器、规划、将诸多微观计划编排为单一变更、测试、审查、以及合并本身。每一个瓶颈的终结方式如出一辙：分析它，而后用 Token 将其淹没。
在你睡觉的时候
在拆解局部之前，先勾勒出终极蓝图，因为终极蓝图才是关键所在。如今任务堆积成队列，原因只有一个：每项任务都需要你守在电脑前逐一处理。然而工作本身并没有这种要求。队列之所以存在，是因为调度靠人工、执行靠串行。剥离这两点，队列便不再是队列：明确的任务在定义完成的瞬间即刻散列展开，上百个会话在数百台隔离的机器上并行运转，在提出需求的人尚在甜梦中时，于一夜之间尽数收官。所谓需求积压，从来不是因为工作量大到无法完成，而是因为海量的任务排在一个人身后等待轮候。以下六大瓶颈，便是阻隔在当下与那个美妙夜晚之间的一切障碍，以及它们各自瓦解的方式。
瓶颈一：机器
首先从工作的运行载体谈起，因为其余一切皆依附于它，这也是大家至今仍困守本地 localhost 的真实根源。生产级应用是由一整套服务与微服务串联而成的复合体，需要同时并发运行：你的前端、后端、移动端应用以及数据库。云端沙盒或许能运行一段脚本，却无法拉起整套系统。CI/CD 未曾打通，环境变量无所指代，而那些能让这一切指向真实环境的密钥（Secrets）也从未被请求过。任何试图在生产环境中使用云端 Agent 的团队，最终都会败退回自己的本地机器上，因为 Agent 不断交付给他们的，是在真实系统中从未运行验证过的代码。
因此，我们像开发者配置个人电脑那样，在一台原生
未曾在真实系统中运行过的代码算不上完成，那不过是一种“猜想”。在机器未曾完成构建并亲眼见证其正常运转前，任何东西都不应作为成型的 PR 呈递到你面前。这正是破除 localhost 怪圈的关键所在：一旦 Agent 拥有了一个能运行你所运行的一切的真实家园，远离操作闭环便不再以牺牲信任为代价，而高并发运行也不再以蚕食你的笔记本电脑性能为代价。
瓶颈二：规划
工程师每天的大部分时间都耗费于此，而在问题被完满解决的世界里，人们在此投入的时间甚至更多，因为这里是修正错误成本最低的环节。当下的工具却背道而驰：耗费数分钟撰写一段单薄的提示词，便直奔编写代码而去，而该问题本应值得一个小时的深度思考。这种捷径在下游会产生恶性复利，计划中的每一处漏洞都会在构建阶段付出十倍的代价来偿还。因此，绝大部分的 Token 应当倾注于此，而非削减。
理想的状态表述起来十分简单：你交付意图（两条链接加一句话），返回的并非代码，而是一份值得推敲论证的方案。它首先摸排了你的整个技术栈、代码库、数据库以及互联网的相关角落，并提出了优秀工程师在提交代码前会质询的问题。你只需简洁回复一行：自动批准工具调用，将变更隐藏在 Feature Flag（特性开关）之后。随后它开始起草，来自不同实验室的审查 Agent 将草案批驳得体无完肤，经历“修复-批评-再修复”的轮回，直至一份由无数微观计划交织而成的终极方案站稳脚跟：拆解出的子任务各附带测试用例，每一个都小巧到足以被干净利落地构建。而你则站在高于代码的层面上进行审阅，那是真正决策生效的地方：依赖关系图、何者并行与何者等待、架构设计、数据模型。你在关键之处发表意见，方案随之重新生成。
只要规划妥当，构建过程便不再与你作对。我的法则是五分钟：如果指导一项特性耗费我的时间超过五分钟，那么它根本就不值得去做。
瓶颈三：编排
一份由计划汇聚成的方案，归根结底仍是一堆零散的部件。每一块都需要运行、与其他部件排定顺序、调和输出成果、抹平衔接痕迹。如今这项工作落在你身上，而这是资深工程师整天所做的事中杠杆率最低的：纯粹的协调，毫无判断力可言。以下特征足以证明这绝不该是人类的工作：你所学会的招式——在粗糙处理后运行 `/simplify`、重新研读模型重写了两遍的文件、在脑海中死记依赖顺序以免两处变更发生碰撞——全都是规矩。而规矩，恰恰是系统比人类执行得更好的东西：它永不遗忘，也永不知疲倦。因此，协调不再由人类承担。控制器将工作顺着依赖图谱分发下去，把每一个碎片死死锁定在“构建-评判-修复”的循环中直至落地，最终呈递成果。
有两点要素让该控制器超越了单纯的循环。首先，它为每个环节配备在该领域表现最佳的模型，而这些模型都不是换谁都行的：
这张表在我们撰写它的当下（2026 年 6 月）是准确的。到了秋季，其中部分结论或将不再成立，而这背后的重要性远超表面所示：必须有人持续摸索出究竟哪个家族的哪个模型在动态变化中最擅长何种任务，且没有任何一家供应商会为你代劳。
其次，控制器将每个 Sub-agent 维持在各自独立的上下文窗口中，因为上下文窗口是会“衰老”的。当窗口不断被填满，模型便会趋于迟钝，犹如漫长的一天耗尽了人的精力：它会遗忘二十分钟前做出的决定，在代码库里留下同一个东西的两个半成品。一个庞大的单一会话，就等于一个走向衰老的头脑。而一支由新鲜血液组成的团队——各自拥有独立的上下文、专属的模型以及明确的本职工作——能够始终保持敏锐；主 Agent 则通过将繁杂工作下沉给它们，来维持自身的精干清爽。协调向来是额外开销，而额外开销正是 Token 最应当优先吞噬的对象。
瓶颈四：测试
正是这一瓶颈，让其他所有人口中的云端变得毫无意义。若分支仍需拉回你的笔记本电脑去检验，云端的价值何在？“能运行代码”并非门槛，“亲眼见证其运行”才是。盲目上云执行完一个分支便宣称大功告成，可没有任何人进行过监视，也就没人确信它是否真的有效。标准是绝对的：在特性经过端到端实操验证并被证实坚固无误前，任何成果都不应作为“已完成”呈递给你。
在一台真实的机器上，这一切皆有可能。整个应用拉起，测试随之展开——不仅是单元测试，更是真刀真枪的演练：驱动浏览器跑完真实流程，在屏幕上证实特性的正确性，并留存录屏，以便你通过审阅视频来核准测试，而非凭空盲信。同一台机器还可以在云端启动一部手机，并在上面运行原生测试。几乎无人做到这一点，而这正是“看起来正确的代码”与“你亲眼见证过正常运转的代码”之间的天壤之别。
若你更倾向于亲自查验，运行中的应用就在那台机器上：打开它、点击进入、指向某个元素并提出修改需求。每一个分支都能获得一个可访问的实时 URL，因此同事在代码尚处于分支阶段时便能点击体验。预发布（Staging）不再意味着漫长的等待。
瓶颈五：审查
一旦编写代码变得极其廉价，阅读代码便成了高昂的成本所在。单个会话就能交还一份长达 8000 行的代码差异（Diff），没人会去逐行阅读，这意味着审查环节成为了整个愿景能否兑现、亦或悄然崩溃的决胜点。天真的解决方式是让模型自查其成果，各大实验室如今皆是如此，但那根本不奏效。作者对自己打分总是宽宏大量；若去问编写代码的模型这代码好不好，它定会夸赞其卓尔不群。即便实验室推出了自身的审查 Agent，它们本质上也是同胞手足——与写代码的模型出自同一家族，由同一批人训练，带有相同的盲区。
真正有价值的审查来自于家族之外：由另一家实验室的审查者出马，因不带有作者的任何惯性而对作品更为严苛，能够抓取那些作者因固有缺陷而无法察觉的纰漏。这种跨实验室的对抗性审查，是你敢于信任未经阅读的合并请求的关键保障；而这恰恰是任何一家实验室都绝不会交付的检查机制——毕竟，雇竞争对手来为自己的作业打分，没人会研发这样的产品。一旦评分机制值得信赖，审查的形式便焕然一新。审查者用非工程师也能理解的通俗语言标出要害，带你顺理成章地解读 Diff 的脉络：最重要的变更居首，测试文件与自动生成文件被折叠收起，而非像 GitHub 那样按字母顺序罗列出令人窒息的文件墙。近来我住在海边，习惯在晨间散步时用手机进行代码审查。若脉络逻辑通顺，点击批准，继续前行。
瓶颈六：合并
整整一夜，其他会话都在陆续交付成果，主分支（Master）从未停止演进。而在旧世界里，这恰恰是人类重新被拖回泥潭的时刻：变基（Rebase）这个、解决那个冲突、细心照看队列以防碰撞。这其中毫无判断力可言，不过是恰好难度较高的琐碎账务，也因此成为了最应当彻底交付出去的事物。队列自行跟进动态变化的目标，化解冲突，将一项项变更接连落地。无需任何人手动 Rebase。甚至连最后一步——各团队习惯性留给人工的步骤——也不再需要人类：凭借对你的 Postgres 数据库与 Kubernetes 的访问权限，系统会自行开启 Feature Flag，变更就此直接上线。而提出需求的人，在这一切发生时依然在熟睡。
演进的终局
整个领域都在攀登同一座梯子。如今，各家实验室已掌握前两层，并正在向第三层发起冲击。提示词衍生为方案，编排器借助 Sub-agent 将其落地，而常驻型 Agent（Recurring agents）也开始作为新特性陆续发布。然而，它们每攀登一个阶梯，都是在其高墙之内进行：局限于自家的模型、自家的默认配置、中位数水平的代码库，以及依然把你的笔记本电脑绑在环路之中。我们在高墙无法企及的领域展开攀登。由此延伸的前进方向对所有人而言皆是一致的：你设定常态化意图（“审查每一个生产环境崩溃并予以修复”、“找出昨日最慢的十个查询并进行性能优化”），系统便会自主派生出相关工作。放眼更远的未来，你只需陈述优先级，系统便能自行决定如何针对这些优先级倾泻 Token——即“Token 分配器”。实验室的分配器永远只会消耗在自家产品家族内，而我们的分配器则能横跨整个市场。虽然尚未臻至彼岸，但我们在一步一个脚印地向上攀登。
需求积压（Backlog）的时代终结了
当智能成本每四个月便衰减一半，且你只需付出一位资深工程师一周的薪酬成本便能运行上百个会话时，需求积压不再是产能不足的问题，而变成了一种选择。老话常说初创公司必须保持专注、排定优先级、学会频繁拒绝——在每一次说“好”都要付出漫长招聘周期的时代，这无疑是正确的。然而，如今软件已沦为大宗商品，一句“好”的代价不过是一夜的会话运转。以单一构想的价格去贯彻执行上百个创意，整个战略逻辑便发生了翻天覆地的逆转：你尽数将其构建出来，再去验证哪些真正具备价值。瓶颈已彻底转移——从“我们能否将其构建出来”，变为“我们能否甄别出该构建什么，以及我们能否将其销售出去”。销售与对客户的洞察，继承了工程团队刚刚让渡出的瓶颈宝座。最先洞悉这一点的公司，在设计之初就已经实现了扁平化：更少的工程师、更庞大的 Token 支出、更迅捷的交付速度，以及一条从客户的一句话直达已合并代码的敏捷通道。若你在尚未榨干 Token 的极限潜能前仍在盲目招揽工程师，那么你依然在玩 2022 年的游戏。
最快洞察此道的人，亦是交付成果最丰硕的人。这就是当下游戏的新规则，而我渴望看到每一个人都能入局共舞。
堆叠 Token（Tokenmaxx），而非堆叠人力（Peoplemaxx）。跟我一同疯狂堆叠 Token ，让我们一起栖居于这片未知的最前沿吧。
译者：boxi。
