当 AI 让码农过剩，真正的瓶颈是「对齐」

当下 AI 开发工具最大的谎言，就是能创造所谓「10倍程序员」。真相是，它们更有可能制造出 10 倍的混乱。真正的未来不在于单兵成神，指挥一群 AI 智能体（Agent）蒙眼狂奔；那种模式只会通往组织协同的灾难。

软件工程的核心挑战，从来都是、且在 AI 时代愈发凸显的，依然是「对齐」（Alignment）。

去年以来，Vibe Coding 给了很多人虚妄的信心，他们幻想着一个人，加上一群 AI 智能体，就能干掉一整个开发团队。

但这种想法有个致命的缺陷：它假设软件是由一个人在真空中创造的。

所有这些鼓吹个人效率的工具，本质上都是单机游戏。它们致力于放大个体的产出，却忽视了一个基本事实：软件开发是团队运动。相信提升个人生产力就能自动产出伟大软件，和“九个孕妇一个月生出孩子”一样，是违背基本规律的逻辑。当个体的产出不成比例地放大，沟通和协调的问题不会被解决，反而会被指数级恶化。

GitHub Next 的研究工程师 Maggie Appleton 在一次分享中，提出了一个非常关键的判断：代码实现正在迅速成为一个已解决的问题。

写代码正变得越来越快、越来越便宜，质量也在稳步提升。过去我们纠结的「如何构建」，正在被「是否应该构建」所取代。当实现一个功能的成本趋近于零时，真正的瓶颈就变成了「就做什么达成共识」。

当生产变得廉价，机会成本就成了唯一的真实成本。你不可能构建所有东西，你选择构建的任何一个功能，都以放弃其他所有可能性为代价。这时候，团队中的每个人——产品、设计、开发、测试——都需要参与到对核心问题的回答中来：我们正在做正确的事吗？我们的精力花在了正确的地方吗？我们如何才能产生最大的影响？

被 AI Agent 冲垮的协作流程

任何在一个正规团队里交付过软件的人都知道，「对齐」从来不是新问题。它一直是瓶颈。但 AI 智能体的出现，让团队「不对齐」的成本变得前所未有的高昂。

更糟糕的是，我们现有的协作工具——GitHub、Slack、Jira、Linear 等等——都还停留在上一个时代。它们的设计理念，是为了服务一种已经过时的软件构建方式。我们正在将海量的、由 AI 智能体产生的输出，强行塞进这些旧时代的管道里。

Maggie 提到观点，即使她身在 GitHub，也必须承认：内部很少有人真的相信 Pull Request（PR）和 Issue 是软件开发的未来。恰恰相反，在 GitHub 这台大机器内部，有很多人正在努力探索下一步该怎么走。

我们来回顾一下经典的开发流程是什么样的。它通常分为三个阶段：计划、构建和评审。在整个流程中，我们有很多用于「对齐」的接触点。比如，在 Slack 或会议中讨论，在 Issue 里评论，起草一个 Draft PR 来探讨技术细节。这个过程足够慢，以至于团队里的每个人，包括资深工程师，都有时间给出自己的意见，发现潜在的错误，并在事情偏离轨道时进行修正。当一个 PR 最终被合并时，整个团队或多或少都对这项工作有所了解，大家基本在同一页上。

但现在，AI 智能体把「构建」这个阶段的时间窗口几乎压缩到了零。因为实现不再昂贵和耗时，我们下意识地认为不再需要那么多计划。于是，那些早期的、至关重要的对齐接触点，就这么消失了。

与此同时，我们发现，对 AI 生成代码的评审时间实际上增加了。从记录一个 Issue 到 AI 智能体提交一个 PR，可能只需要几分钟。代码变得如此廉价，以至于我们甚至来不及在发起一个 prompt（提示）之前停下来好好思考一下。更要命的是，大多数编码智能体都有一个「本地计划模式」（local plan mode），这个计划完全不与团队其他人共享。你甚至都懒得读一遍 AI 生成的计划，更别提和团队确认这个计划是否合理，就直接让它去执行了。

结果是什么？所有沟通、讨论、确认、妥协的压力，都被推迟到了流程的最后一步——Pull Request。

PR 成了所有早期对齐失败的垃圾场。它被迫承载了它从未被设计去承载的功能，自然表现得一塌糊涂。我们每个人都面临着堆积如山的 PR 需要评审，但对于这些 PR 的背景、目标、实现思路，我们一无所知。

这种「先斩后奏」的模式带来的直接后果就是巨大的浪费。比如，交付了没人要求的功能；功能完成后收到关键反馈，导致整个推倒重来；更可怕的是「协调债」，几个工程师（或他们的智能体）同时修改了相同的文件，造成了极其棘手的合并冲突；或者两个人不约而同地领了同一个任务，各自花了一天时间重复造轮子。

真正的上下文，在代码之外

要解决这个问题，我们需要能帮助团队在 AI 智能体开始工作之前，而不是之后，进行对齐的工具。并且，这种对齐需要在整个构建过程中持续发生。计划和构建不再是分离的阶段，而是一个紧密耦合的循环。

未来的工具，必须将计划、上下文收集、决策制定和开发本身，都整合到同一个屋檐下。

这一点至关重要，因为构建正确产品所需要的大部分上下文，根本就不在代码库里。它们存在于人们的头脑中。

业务上下文和财务资源：

决定了什么才是「正确」的构建目标。

组织内的政治动态：

谁是负责人，谁有决策权。

领导者的产品愿景。

设计师的用户研究洞察。

组织的历史：

过去构建过什么，踩过哪些坑。

这些「软信息」对于决定团队应该做什么，其重要性远超代码本身。而 AI 智能体永远无法靠自己发现这些上下文。你需要一种方法，让团队里的「人」能够早期、自然地分享这些信息，而不是通过增加繁琐的流程和会议。

GitHub Next 的探索：Ace 环境

带着对这些问题的思考，GitHub Next 团队（可以理解为 GitHub 内部那个「折腾与探索」的实验室）构建了一个名为 Ace 的研究原型。Ace 全称是 Agent Collaboration Environment，即「智能体协作环境」。

Ace 的核心理念，是创造一个多人在线的、人与 AI 智能体共同协作的环境。它看起来像是 Slack、GitHub Copilot 和一堆云端计算机的结合体。

下面是对 Ace 核心价值的解读，而不是简单的功能罗列：

会话（Session）即环境，而不只是聊天。在 Ace 中，每一个工作单元是一个「会话」。这个会话表面上像一个 Slack 频道，你可以和队友聊天。但它的内核，是一个独立的、沙盒化的微型虚拟机（Micro-VM），并且自带一个独立的 Git 分支。这意味着，每个会话都是一个完整的、隔离的开发环境。这解决了什么问题？解决了软件开发中最恼人的摩擦之一：环境切换。你想看看同事正在做什么？不需要 git stash，拉取他的分支，安装一堆依赖，最后发现「在我机器上跑不起来」。你只需要点击进入他的会话，就能立刻看到他所看到的一切，包括他的终端、实时预览、以及他与 AI 智能体的完整交互历史。这种零摩擦的上下文切换，是实现持续对齐的基础。

AI 智能体成为共享资源，而非私人助理。在 Ace 的会话里，AI 智能体不是某个人的专属。我发起了会话，但我的队友 Nate 可以在同一个会话里，继续向 Ace 智能体发出指令。这改变了 Agent 的归属。它不再是「我的 Agent」，而是「我们的 Agent」。Agent 的所有输入（prompt）和输出，都沉淀为团队的共享知识，而不是某个工程师本地终端里无法追溯的历史记录。这意味着，与 AI 的交互本身，也成为了团队协作的一部分。

包容性的界面，让非开发者也能参与。Ace 选择了类似 Slack 的聊天界面，这是一个深思熟虑的设计。它极大地降低了参与门槛。产品经理、设计师、甚至客服人员，都可以进入这个环境，实时看到一个功能是如何被构建出来的，他们可以截图、提问、甚至直接在对话中给出反馈，然后让工程师（或直接让 Agent）去实现。为什么不用 Slack？因为 Slack 永远不会成为一个功能完备的软件开发工具，它没有代码差异对比（diff）、终端命令这些原生能力。Ace 的目标是，在保持开发工具专业性的同时，让它对其他角色足够友好，从而把构建软件所需的所有「人」都拉到同一个空间里。

主动的社会化信息摘要。当团队每个人每天都能交付 5 个功能，而不是半个时，信息过载会成为新的巨大挑战。你根本不知道你的同事们都在干什么。Ace 的仪表盘设计了一个「团队脉搏」功能。它利用大模型，主动为你总结过去一两天里同事们的工作动态，比如「Nate 刚刚合并了一个大厅频道的功能，David 修复了访问令牌的问题」。它甚至会提醒你上周五未完成的工作。这本质上是让 AI 具备了初步的「组织感知能力」，它不再是被动执行命令的工具，而是能帮你理解团队动态、保持同步的主动助手。

核心观点：从「增强编码」到「增强协作」

Maggie 的分享和 Ace 的原型，揭示了一个比「AI 辅助编程」更宏大的图景。这场变革的核心，并不仅仅是关于工具的演进，而是关于工程师角色和软件工程定义的根本性转变。

过去，工程师的核心工作是「写代码」。未来，工程师的核心工作将是「指导意图和确保对齐」。工程师的角色会越来越像一个导演或总编辑，他的主要职责是定义问题、构思方案、协调资源（包括 AI 和人），并对最终产出的质量和方向负责，而不是一个打字员。

AI 的真正价值，不在于让差的开发者变好，或者让好的开发者写代码的速度快十倍。它的真正价值在于，将工程师从繁琐、重复的实现工作中解放出来，把节省下来的时间，投入到那些真正决定软件质量和价值的活动中去：更深入的批判性思考、更广泛的用户研究、更激烈的架构辩论、以及更周全的规划。

这是一种「手艺」的回归。当代码生成变得廉价，当每个人都能用 AI 快速拼凑出一个产品时，真正的差异化优势是品味、是判断力、是质量。是那种对细节的偏执、对用户体验的同理心、对系统长期健康度的远见。

而所有这些「手艺」，都需要时间和精力去打磨。AI 给了我们这份奢侈的礼物。

像 Ace 这样的协同工具，其终极目标不是管理 AI 智能体，而是创建一个新时代的「数字化作战室」。在这个空间里，团队能够以前所未有的清晰度和目标感，一起思考、计划和创造。这不再是简单的「增强编码」，而是迈向了「增强协作」。

未来的赢家，不会是那些拥有最强 AI 智能体的孤胆英雄，而是那些能够将人的智慧与 AI 的能力最紧密地结合，形成了高效「对齐」的超级团队。他们不会用 AI 去生产 1000 个平庸的功能，而是用它来精心打磨少数几个卓越的产品。

这才是 AI 时代，软件工程真正激动人心的未来。

参考来源：Collaborative AI Engineering: One Dev, Two Dozen Agents, Zero Alignment — Maggie Appleton, GitHub