什么是 AI 编码助手？

LLM 本身能够接收代码、上下文和指令作为输入，并输出新代码或代码变更。但独立的 LLM 无法打开文件、使用外部工具和应用程序、访问终端或运行命令——这些任务对于创建和维护可用于生产的代码库至关重要。虽然 LLM 确实是能够辅助编码的 AI，但现代行业术语中的“AI 编码助手”并非指原始的 LLM。

相反，真正的 AI 编码助手是一个更强大、更全面的软件产品，它使用一个大语言模型（或多个模型）作为其引擎。可以将其理解为一个将 LLM 这一“大脑”与充当其“四肢”的工具包配对的应用程序，所有这些都通过单一用户界面 (UI) 访问，并通过精心设计的逻辑与工作流进行操作。

尽管编码助手的大部分功能可以通过手动编码逻辑和费力构建的提示词来实现，但 AI 编码助手的设计初衷正是为了自动化并简化这项工作。例如，内置的检索流水线可提供上下文感知能力，无需将整个代码库都塞进每个输入提示中，从而耗尽 LLM 的整个上下文窗口。通过最初由 Anthropic 推出的模型上下文协议 (MCP) 运行，MCP 服务器能够促进与外部服务和工具（如 API、数据库和文件）的通信。结构化工作流允许 AI 助手使用专门的工具进行精确、局部的代码编辑，而独立的 LLM 则必须重写整个文件或代码块才能做出单一变更。

开发团队间的协作以及与关键编码平台的集成，则是通过手动编排的工作流较难实现的，而 AI 编码助手可以提供这些能力。大多数现代编码助手可以直接融入常见的集成开发环境 (IDE) 中，如 Visual Studio Code (VS Code) 或 PyCharm。有些，如 GitHub Copilot，是主流 IDE 的原生插件或扩展。有些，如 IBM Bob，既可以作为 shell（一个命令行界面 (CLI)，例如 Bob Shell，既能独立运行，也能通过简单的包装器与 IDE 集成），也可以作为一个独立的 IDE，提供全面的内置调试、版本控制、重构和测试生成工具。

区分 AI 编码助手与  AI 智能体 在语义上可能令人困惑。在 AI 编码工具领域，术语既受营销驱动，也受那些明确、清晰定义且普遍认可的特性和能力的影响。

最重要的一点是，这些概念并非互斥。事实上，业界越来越多地将这两个术语混为一谈，以至于有时可以互换使用。或许最有用的理解方式是，将每个术语看作描述 AI 编码工具的不同维度，而非描述不同类型的产品。

• 助手描述的是产品与其人类用户之间的关系。这是一个非正式的、以用户体验为导向的术语，基本上定义了该工具的工作描述：使用 AI 来协助人类完成编码任务。理论上，这可以恰当地描述任何事物，从简单的代码补全工具和其他直接由自动补全驱动的功能，到用于人工智能驱动软件工程的复杂、全面的端到端套件。

• 智能体描述的是产品的技术架构。简而言之，任何为大语言模型配备工具、环境、指南、防护栏和推理框架，使其能够自主规划和执行编码任务的软件，都可以合理地称为“AI 编码智能体”，因为它本质上就是专为编码任务设计的 AI 智能体。

大多数现代编码助手都具有智能体式 AI 的特性：它们接收自然语言指令，然后独立制定执行这些指令所需的具体步骤，运行命令、评估结果，并在将最终输出呈现给用户之前进行迭代。因此，从技术层面讲，使用任一术语来描述它们通常是准确的。

但在实践中，更恰当的用法是用“AI 编码智能体”（或简称为“编码智能体”）来描述一个单独的智能体，它被编程来执行特定的任务或职责。例如，软件工程师可能会使用 AI 编码助手构建一个自主智能体，其目的是接收新的 Jira 工单并主动解决小问题。您可能会构建另一个智能体来监控代码库的变更并相应地更新文档。本质上，这些编码智能体将由您的编码助手创建并运行在其中。

尽管市场上的每种编码助手都提供其独特的工作流、逻辑、功能和重点领域，但一个编码助手通常包含以下基本组成部分。

编码助手必须有一个用户可与之交互的界面。该界面可以是简单的基于文本的命令行界面 (CLI)，或者对于基于 IDE 的助手而言，是图形用户界面 (GUI)。后者既可以是一个专门的编码助手 GUI，也可以是其主要 IDE 图形界面中的一个扩展或插件。

合适的选择通常取决于用户的技能水平、用例、操作环境和 token 预算等因素的组合。

基于 CLI 的助手，如 Bob Shell、Aider 或 Pi，使开发者能够在自己机器的原生终端（或他们选择使用的第三方终端）内指挥其编码助手。对于主要通过终端工作的软件工程师来说，这提供了最无缝、最快速、最高效利用 token 且可定制的体验。对于必须在无 GUI（以及显示器）的“无头”环境中运行的编码助手——例如持续集成/持续交付 (CI/CD) 服务——基于 CLI 的工具通常是唯一的选择。

CLI 编码助手提供对工具和流程更精确的控制，使开发者能够显式地编写工作流脚本，而不必受限于 IDE 的抽象层和内置工作流逻辑。系统命令、测试或工作流的输出可以直接通过管道传入 AI 助手的下一个输入提示，使开发者能够无缝地将命令串联在一起。

基于 CLI 的助手确实需要更高的技能和开发知识才能操作，因此对初学者和氛围编程者来说不是一个好的选择。用户必须能够熟练浏览终端环境、文件路径以及其他在常规计算中通常隐藏在 UI 抽象之下的架构元素。它们极简的 UI 也排除了基于 IDE 的助手所提供的一些功能，例如内嵌按钮、聊天侧边栏、实时代码审查或点击即接受的代码补全建议。

基于 IDE 的 AI 编码助手通过经典的图形用户界面提供更强大、更用户友好的体验。对于主要通过 IDE 工作的开发者，或不熟悉终端命令的初学者来说，基于 IDE 的工具将提供更流畅、低摩擦的体验。

基于 IDE 的工具可提供功能更丰富的环境，因为在带有可移动、可点击光标的图形用户界面中，有更多的方式和位置可以向用户呈现选项和信息，并供用户接收。例如，基于 IDE 的编码助手的图形界面可以提供并排文件对比和彩色编码的行内差异，以清晰传达所提议的更改。侧边栏和上下文菜单则提供了展示重构建议的机会。该助手可以实时响应文本光标的位置，并且上下文感知的编辑建议只需单击即可接受或拒绝。

这种功能是以牺牲控制权为代价的，在某些情况下还会牺牲成本效益。基于 IDE 的助手本质上比基于 CLI 的助手更消耗 token，因为 IDE 必须持续将大量上下文信息打包到它底层发送给大语言模型的每个原始提示中。对大多数用户而言，通过 IDE 的抽象集工作而非使用显式命令，更容易上手、更直观，但这会牺牲定制能力。

LLM 是每个 AI 编码助手的核心：或许最好将“助手”理解为一个软件结构，它允许用户从 LLM 中获取最大性能和效用。因此，选择使用哪个具体的 LLM，对于任何 AI 编码工具来说都是一项至关重要的架构决策。

一些编码助手是模型无关的，但许多助手将用户限制在特定的 LLM 上。例如，Claude Code 完全通过 Anthropic 的 Claude 模型运行。Cursor 则使用其专有的“Composer”模型进行代码生成。

在大多数情况下，基于单模型方法构建的编码助手从成本和延迟角度来看效率都不高：某些任务需要大型前沿模型的精确度和推理能力，但许多其他任务更适合由更小、更快、消耗更少 token 的 LLM 来处理。例如，IBM Bob 采用多模型编排，结合了前沿专有模型（包括 Claude）、开源 Mistral 模型、IBM Granite 模型，以及专门用于安全和下一步编辑预测的微调模型。Bob 将每项任务路由到最合适的模型：简单的任务交给轻量模型，而中央规划和复杂任务则交给更大的模型。

智能体式推理逻辑是编码助手的 LLM “大脑”消化宏观目标（例如“找出为什么登录在移动端一直崩溃”）并将其分解为实际执行步骤的方式。不同的推理策略适用于不同类型的任务：编码助手通常被编程为部署多种策略以满足用户请求的需求。 

工具是编码助手的“手臂和腿”，使其能够与环境交互，并且不仅能凭空编辑或生成孤立的代码片段。现代编码助手通常提供的内置工具支持以下任务：

• 从外部服务（如任务管理软件、内部文档、数据库、日历或其他应用程序）中提取相关信息并执行操作 

• 对文件的特定部分进行精确、局部的代码更改，而不是完全重写

• 运行终端和 shell 命令

• 进行安全检查

• 在预定义场景中执行基于规则的操作

• 根据系统指南和防护栏验证输出（并强制执行）

例如，编码助手可能会调用一个内置工具，仔细查阅您所在组织的 Slack 频道，以获取与当前任务相关的上下文。基于这些上下文，它可能会调用另一个工具对特定代码区域进行精确的局部修改，再调用第三个工具来生成并运行一个单元测试。

涉及文件系统、数据库和外部服务的操作通常由 MCP 服务器来协调。模型上下文协议 (MCP) 为 LLM 与外部 API 之间的通信提供了通用标准，它的出现和广泛采用，显著提升了 Code Assistant、为其提供动力的 LLM 以及它们必须交互的众多服务之间的互操作性。

这些工具的功能通常是识别、检索对编码助手所要执行的任务至关重要、但 LLM 的训练数据中不会包含的上下文，并据此采取行动。

• 向量数据库：编码助手必须反复判断，在数千份文档或数百万行代码中，哪些少数文件包含为任务每一步提供信息所需的上下文。将各个文件存储在向量嵌入数据库（每个文档以数字数组表示的一种数学表示形式）中，便可通过语义搜索识别相关文档。然后，检索到的文件中的上下文可以通过检索增强生成 (RAG) 注入到大语言模型的工作流中。

• 规则文件：无需用户持续、反复地为每项任务提供详尽的指令，Code Assistant 通常依赖于规则文件，例如 Claude Code 中的 Claude.md 文件或 IBM Bob 中的自定义规则和自定义模式。这些是标准化的 markdown 文件，明确规定了编码标准、期望行为以及架构方面的考量，供 LLM 遵循。

• 跨会话记忆：LLM 默认是无状态的。除了当前会话的上下文窗口，LLM 无法访问之前会话的信息。因此，编码助手会存储会话日志和持久化的元数据缓存，让助手能够“记住”重要的要点、模式、障碍（例如代码缺陷及用于修复缺陷的调试策略）以及项目特定的构建配置。正是这一点让编码助手能够随着时间推移不断“学习”。

编码助手（以及它们为执行任务而创建的编码智能体）强大的自主性可能是一把双刃剑。如果不加以监控和约束，编码助手可能会执行影响广泛的更新，导致功能损坏、凭据及其他机密信息泄露，或使恶意代码进入您所在组织的系统。

因此，高质量的编码助手会提供防护栏和自动检查点机制，以确保任何重大操作在执行之前都经过人工审核和批准。例如，IBM Bob 默认情况下对大多数操作都需要人工许可——任何例外情况都必须由用户明确设置为“自动批准”。

许多编码助手的配置设置允许用户将特定的智能体或项目置于沙箱中，出于安全或相关性的考虑，将其限制在特别批准的环境内。在 IBM Bob 中，只需将特定文件和目录添加到 .bobignore 文件中，即可阻止 Bob 与之交互。在尚未添加到“受信任文件夹”的目录中使用基于 CLI 的 Bob Shell 时，Bob 会在受限的安全模式下运行，以最大限度地减少漏洞。

许多现代编码助手提供自动检查点功能，以便于对代码更改进行实验，并在产生不良后果时轻松回滚更新。

当针对某项任务部署了多个子智能体时（无论它们是在编码助手内部创建的还是在其他地方构建的），大多数编码助手都会使用 Agent2Agent (A2A) 协议来协调它们之间的通信。

对于像 Bob 这样利用多个大语言模型的编码助手，任务感知路由系统会根据复杂性、计算需求和 token 预算，动态地将每个子任务委派给合适的模型。

AI 编码助手支持广泛的用法模式，从氛围编程——完全由自然语言提示和模型输出驱动，极少与代码本身交互——到更加深思熟虑和具有策略性的智能体式编码（或智能体式工程）。

氛围编程通常是没有经过软件开发培训或缺乏经验的用户的领域，他们中的许多人甚至缺乏 Python 或 JavaScript 等常见编程语言的基础知识，或者（在更有经验的开发者手中）用于实验和原型设计。用户基本上将整个过程委托给编码助手，除了通过自然语言指令传达的指示和修正外，避免大部分手动输入、审查和测试。如果氛围编码的项目要用于真实场景，必须格外小心，以避免代码质量问题或安全风险。

相反，智能体式工程更类似于结对编程，其中编码助手是真正与开发者并肩工作的助手——开发者积极主导项目和代码——充当额外的帮手和眼睛。这种更复杂的智能体式编码实践释放了 AI 编码助手的全部能力和潜力，使得在生产环境中更可持续、更高效地使用 AI 编码工具成为可能。