AI编码工具应超越编辑器

AI辅助编码工具正在改变软件开发的方式，但它们大多被限制在代码编辑器内。本文将探讨为什么这些工具应该超越编辑器，覆盖整个开发循环。

AI辅助编码的本质

在传统开发中，开发者手动将意图转化为代码：你在大脑中保持目标，然后键入实现。AI辅助编码在这一路径中插入了一个新层——你用自然语言描述需求，工具将其转化为代码，然后你审查并优化结果。这种形式的最松散版本被称为“氛围编码”，但底层的机制是相同的：自然语言成为与代码库交互的主要界面，由工具作为中介。

传统开发直接将开发者与代码连接。AI辅助开发则插入了一个AI助手，由自然语言驱动，开发者审查其产出。这是一个看似微小的变化，却带来了实践上的巨大不同。而且，几乎毫无例外，这个变化被限定在编辑器内。

开发不仅仅是编码

这幅图景默认了有趣的工作就是写代码。退一步看，构建软件实际上涉及什么，编码只是更大循环中的一个环节。

大多数开发工作围绕三个支柱循环：

• 项目管理：计划、讨论和记录工作的地方，包括路线图、功能和bug。这是意图在代码存在之前被捕获的地方。
• 编码：在开发环境中实现意图。
• 基础设施：将代码部署到生产环境、运行和观察的地方。

这些不是一条直线；它们是一个循环。你在项目管理工具上计划和记录变更，转到开发环境实现它，然后推向生产——而在那里学到的东西（bug、指标或投诉）会回流到计划中，作为下一项工作。

开发者位于这三个支柱的中心，在它们之间移动，形成一个连续的循环——计划工作、构建它、交付并观察，然后回到计划。在这个循环中每绕一圈，就是一次真正的进步。写代码只是中间的三分之一。

在循环中放置助手

现在，将AI助手放在这张地图上。今天，它几乎完全存在于编码支柱内——在编辑器中，帮助编写下一个函数。它在这方面很擅长，这里不是要把它赶走。关键是，将它限制在一个支柱中会使它对其他两个支柱视而不见，从而无法判断自己的工作是否重要。

AI辅助编码已经使自然语言成为代码库的界面。将同样的举措扩大到整个循环，助手就成为开发本身的界面：你表达一次意图，它就会将该意图贯穿所有三个支柱——打开工单、编写代码、交付并读取生产环境的反馈。开发者仍然做出决策；助手成为他们通过其作用于整个循环的层，而不是局限于一个站点的代码生成器。

编码

这是助手已经占据的支柱——直接在开发环境中，无论是通过终端的命令行工具，还是内置于VS Code等编辑器中。必须坦白地说，这非常有效。生成函数、重构、解释不熟悉的代码、编写测试——编辑器内的助手已经赢得了它的位置。论点不是要离开编码支柱，而是不要将其误认为是整个工作。

项目管理

代码很少是为了自身而存在；它存在于满足人类在项目管理工具（如Jira、Asana或Trello）中描述的内容——一个工单、一个问题、一个路线图项。能够读写项目管理层的助手可以将变更与其意图连接起来：从工单中提取验收标准，在接触代码前起草计划，随着工作进展更新状态，并立即提交它发现的bug，而不是留待某人注意。计划和代码不再渐行渐远，因为同一个参与者确保两者诚实。这种连接通过团队已经使用的工具运行：大多数工具暴露命令行界面，并且越来越多的工具提供了模型上下文协议（MCP）服务器——这是一个开放标准，允许助手读写外部系统——因此将助手接入越来越像配置而非定制粘合。

基础设施

助手能做的最有价值的事情通常不是写代码——而是关闭已编写代码的循环。这意味着能够部署、读取日志、检查运行中的资源，以及在实际重要的地方观察变更的效果。从diff猜测与从生产环境读取之间的区别，就是希望修复起作用与知道它起作用之间的区别。接入方式已经存在：主要的云提供商——Google Cloud、AWS——提供全面的CLI，因此部署、跟踪日志和检查资源都是助手可以执行的普通命令，而不是定制的集成。

闭合循环带来的好处

三个独立的工具——一个用于规划，一个用于编码，一个用于运维——强迫人类成为它们之间的集成层，手动跨每个边界携带状态和交接。跨越所有三个支柱的助手自己承担这个负担——而且这种跨度也让它能够检查自己的工作。局限于编辑器的工具提出一个变更就停止了；它无法判断部署是否成功，它目标的指标是否移动，或者它是否重新引入了上周的bug。能够看到生产环境的工具可以做到这一点。使循环成为循环的反馈——现实报告——正是编辑器边界切断的东西。

在这之下有一个更基本的事实：大语言模型（LLM）的好坏取决于其上下文窗口——它推理所依据的决策、历史和当前状态的工作集。让LLM产生有用工作的关键是，将正确的信息放入那个窗口中。其他两个支柱不仅是行动的地方；它们也是助手所能拥有的最丰富的上下文。项目管理包含变更背后的意图；基础设施包含系统实际运行时的行为。代码说明构建了什么——那些支柱说明为什么以及是否有效。局限于编辑器，助手在大部分证据不可见的情况下进行推理。

这种扩展伴随着一个纪律。更多的上下文并不自动是更好的上下文——关键的是窗口内的信噪比，这个问题现在被称为上下文工程。扩大范围会提高两者的供应：连接工单上决定性评论的能力可能同样容易地拉入十个过时的评论，而确认修复的日志行旁边有更多不相关的日志行。目标不是将所有三个支柱都倒入上下文——而是在正确的时间从每个支柱中提取正确的切片。范围使得正确的上下文可达；它并不免除你选择它的责任。

风险与防护

当然，触及生产环境和项目管理工具正是爆炸半径所在。能够部署的助手也可能破坏部署；能够关闭工单的也可能关闭错误的工单。危险并不均匀分布。错误的工单编辑尴尬但可逆；错误的生产操作可能两者都不是。基础设施是不可逆的所在——丢失的数据库、未修复的不良部署——这使得它成为需要最严格防护措施的支柱。答案不是退回到编辑器，那里工具安全是因为它无能为力。答案是我们应用于人类访问的相同方法：范围权限、明确的读写分离、在不可逆或面向外部的操作前明确的确认，以及所做操作的审计追踪。设计得当，这些防护措施使广泛访问变得安全；设计不当，狭窄的访问只会使其无用。

边界是一个选择

编辑器边界是一个历史偶然——这些工具恰好从这里开始，而不是它们必须停止的地方。开发工作是一个跨越三个支柱的循环，只参与一个支柱的助手将始终在帮助完成三分之一的工作，同时猜测其余部分。值得构建的未来方向是跨越整个周期的助手。这一未来的真正约束是信任和控制——而不是范围。