AI工程转向智能体，但面临生产力悖论和“氛围编程”导致的技债。解决方案是上下文工程，特别是企业级上下文，确保AI生成可靠软件，而非仅加速。
译自：Why Agentic AI Needs a Context-Based Approach
作者：Chris du Toit
工程领域关于 AI 的讨论正在迅速转变，已经超越了单纯的自动补全，走向了工程工作中全面的推理和自动化。未来的开发将越来越多地由 AI 智能体定义。这种转变已经产生了具体的工具，例如专注于代码审查的 AI 智能体和全面的集成。
然而，这种激动人心的智能体化转变却被生产力悖论所困扰。我们看到 AI 模型在基准测试中取得了令人印象深刻的成绩，同时也有不少传闻称 AI 在各种任务中提供了 substantial 帮助。然而，当这些系统在真实场景中接受严格审查时，结果却喜忧参半，甚至出现负面情况。
关于 AI 能力的证据部分存在矛盾。尽管许多人表示 AI 对重要的软件任务非常有帮助，但随机对照试验表明，在特定的高风险开发环境中，AI 导致了显著的放缓。
这种矛盾促使我们认识到一项关键事实：为了克服当前的局限性并防止累积昂贵的技术债务，构建更有效、更可靠的 AI 智能体的关键在于超越模糊提示——我们称之为“氛围编程”——转而拥抱上下文工程。我们必须强制实行普遍、严谨的上下文感知，以引导智能体的创造力。
智能体 AI 采用的当前挑战
现实世界生产力放缓
挑战普遍乐观情绪的最显著证据来自实证研究。一项旨在衡量 2025 年初 AI 工具对经验丰富的开源开发人员生产力影响的随机对照试验 (RCT) 发现了一个令人惊讶的核心结果：当开发人员被允许使用前沿 AI 工具（例如 Cursor Pro 配合 Claude 3.5/3.7 Sonnet 等高级模型）时，他们完成任务的时间比没有 AI 辅助时长了 19%。这代表了显著的放缓。
这项试验的条件专门设计用于捕捉真实世界的有用性，涉及经验丰富的开发人员处理真实问题（bug 修复、功能开发、重构），这些问题发生在他们多年来一直贡献的大型、熟悉的仓库中。关键是，成功的定义要求人类用户满意代码能够通过审查，包括与文档、风格和测试覆盖率相关的要求。
这一发现与开发人员的看法形成了鲜明对比。开发人员预期 AI 会使他们提速 24%，即使在经历了放缓之后，他们仍然认为 AI 使他们提速了 20%。这种感知与现实之间的差距是惊人的，表明自我报告的速度提升可能不准确且过于乐观。此外，在质量标准极高或存在许多隐含要求（如文档或 linting）的环境中，这种放缓仍然存在，而这些要求需要人类花费大量时间学习和实施。
氛围编程与技术债务的陷阱
这种现实世界放缓的根本原因通常是大型语言模型 (LLMs) 的灵活性与生产系统所需的严谨性之间存在根本性脱节。这种脱节表现为氛围编程。
氛围编程的定义是基于宽松、非正式的提示通过 AI 生成代码，例如输入“制作一个看起来很酷的登录表单”，而不是提供精确、结构化的规范。AI 根据训练模式迅速填充空白，从而实现快速的初始开发。
这种做法代表了动态类型原则在 AI 时代的逻辑延伸。动态类型（想想经典的 JavaScript 或 Python）和氛围编程都优先考虑即时开发速度和灵活性，而非前期严谨性，并且这两种范式都会积累技术债务，这些债务最终必须付出利息来偿还。
氛围编程的隐藏成本是巨大的且至关重要的：
- 安全风险：AI 可能会复制其训练数据中不安全的模式，遗漏关键的验证机制，如跨站请求伪造保护、错误处理或跨站脚本攻击保护。
- 上下文丢失：AI 无法解释其推理，这意味着实现背后的关键“原因”丢失了。开发人员可能会跳过人工文档，导致新团队成员难以理解。
- 维护噩梦：生成的代码通常包含不必要的复杂性或冗余逻辑，并且重构变得困难，因为更改可能会破坏隐藏的依赖项。
- 延迟验证：错误被推迟到运行时才出现，可能在生产环境中浮现，而不是立即被编译器或验证器捕获。
如果组织在不解决此问题的情况下扩展 AI，他们将面临通过氛围编程陷入技术债务海啸的风险。
不明确智能体的局限性
全自主智能体在 SWE-Bench Verified 或 RE-Bench 等基准测试中取得的令人印象深刻的成功，它们可能使用复杂的脚手架或采样数百万个 token，但这往往掩盖了它们在实际使用中的局限性。这些基准测试通常为了规模而牺牲真实性，依赖于自包含任务和算法评分，而这些并不能捕捉真实世界需求的复杂性、先前的上下文或人类满意度（包括风格和架构）。
重要的是要理解，尽管这些模型在最大化启发（数百万个采样 token）下展示出高能力，但这种能力并不能轻易转化为实际应用中的影响或复杂的真实世界有用性。此外，研究人员认为，如果 AI 系统能够在这些现实的 RCT 环境中显著加速开发人员的工作，这可能预示着 AI 研发进展的快速加速，这反过来可能导致重大的不稳定风险，包括扩散风险以及保障措施和监督的崩溃。
上下文工程：更智能智能体的解决方案
在不陷入技术债务的情况下释放 AI 全部潜力的关键是将智能体深度集成到开发生态系统中，我们将其定义为上下文工程。
通过上下文感知实现个性化
AI 平台必须不仅仅是通用聊天提示。上下文感知 AI 平台（例如 Tabnine）通过理解开发人员的特定应用程序、要求和工作流程来提供高度相关的代码和建议。
这种个性化使得 AI 能够像开发团队中真正入职的成员一样运作。个性化可以在多个层面进行，确保 AI 能够访问对于做出架构上合理决策至关重要的专有非代码知识。
通过数据连接最大化智能体效率
为确保智能体生成有效且安全的代码，它们需要即时和增强的上下文：
- 即时上下文 (IDE)：智能体必须直接使用来自开发人员 IDE 的所有可用数据。这包括关键信息，如变量类型、注释、打开的文件、导入的包和库，使 AI 能够“开箱即用”地提供相关的代码和建议。
- 增强上下文 (组织)：通过将系统连接到项目所需的额外信息源，如组织的代码库、需求、文档以及工单系统（Atlassian Jira）和文档库（如 Confluence）等工具，可以显著增强智能体的性能。
从氛围编程转向上下文工程
上下文的战略性使用允许开发人员用严格的规范取代模糊的请求，从根本上改变了与智能体的交互模式：
- 结构化规范：开发人员必须超越简单的请求，例如“添加用户管理”，而是使用经过上下文工程的提示作为结构化规范。这些规范明确定义了关键要求，例如使用 TypeScript 接口、定义 PostgreSQL schema、指定输入验证、强制实行限速、要求审计日志以及设定单元测试覆盖率目标（例如，覆盖率 >80%）。
- 实施防护措施：组织必须将其独特的最佳实践、策略和工程标准正式化，并将其转换为控制 AI 智能体行为的明确规则。这些规则必须在开发人员工作时在 IDE 内强制执行，并在拉取请求或代码审查阶段再次强制执行。
- 混合工作流：最可持续的工作流需要一种严谨的混合方法。人类的角色涉及前期严格性：定义类型和接口，以及至关重要的是，在生成之前编写测试用例。这之后是上下文工程化的提示，它指导 AI 生成。然后，AI 生成的代码需要经过必要的验证步骤，包括静态类型检查、运行测试、安全扫描，最后是系统性的人工代码审查和重构。
企业级上下文的重要性
智能体 AI 的真正前沿不仅仅是上下文——它是企业级上下文。虽然大多数 AI 助手在单个文件或仓库的狭窄范围内运行，但企业级工程需要理解整个工作系统的智能体。这不仅包括代码库，还包括隐含架构、合规策略、部署管道以及每次变更请求背后的组织意图。
上下文即架构，而非记忆
在企业中，上下文不是一个临时状态或聊天历史记录——它是组织知识产权的活生生的架构。每个服务、接口和 schema 都代表着系统和团队之间的契约。当智能体在无法访问此架构的情况下运行时，它们会在真空中做出决策。结果是语法正确但语义错误的代码：逻辑上“可行”但违反全局一致性的代码。因此，上下文工程是将这种架构感知编码到智能体的推理层，确保每一次生成都与组织的设计意图保持一致。
连接组织图谱
企业系统是关系网络——服务、工单、文档和人员之间的关系。高效的智能体必须能够驾驭这个图谱。通过连接到 Jira、Confluence 和内部 Git 仓库等工具，智能体获得了与高级工程师相同的态势感知能力：功能背后的“原因”、已经讨论过的权衡以及限制实现的依赖项。这种深度集成使智能体能够在与组织本身相同的语义空间中进行推理，而不仅仅是在代码的语法空间中。
设计层面的治理和可追溯性
企业级上下文也为大规模治理奠定了基础。当每个 AI 操作都与明确的标准、设计文档和问题引用关联时，合规性就成为工作流的内置属性，而不是事后考虑。这确保了代码生成不仅快速，而且可追溯。当智能体在结构化、上下文丰富的环境中运行时，可审计性、溯源和可解释性自然而然地出现。每个生成的函数都可以追溯到原始业务需求、相关的 Jira 工单以及指导其设计的策略。
上下文作为新的杠杆来源
正如编译器曾经成为工程师的放大器一样，企业级上下文现在是智能体的放大器。上下文将通用智能转化为组织智能。它让同一个模型在执行 PCI-DSS 合规性的金融科技公司、执行 3GPP 标准的电信公司或在 HIPAA 约束下工作的医疗保健公司表现不同——不是通过重新训练模型，而是通过用组织的上下文结构来包围它。这是可持续加速的核心：AI 不仅能快速编写代码，还能正确、安全地编写代码，并符合公司的基因。
结论：从氛围编程到企业级上下文
快速迭代的便利性与架构严谨性的必要性之间的张力在软件开发中并不新鲜。从动态类型到渐进类型（如 TypeScript）的演变提供了关键的经验：虽然氛围编程等便捷的捷径能提供即时速度，但它们在复杂性和后期维护方面付出了沉重代价。可持续的软件实践需要纪律、复杂的工具和经验积累。
对于今天的软件团队来说，前进的道路是清晰的：最成功的团队将利用智能体进行快速迭代，同时严格维护质量标准。通过用数十年的软件经验积累的智慧来指导 AI——确保清晰的类型、强大的测试和结构化规范——我们可以从寄希望于提速转向架构可靠的软件。
氛围编程提供了一个诱人的捷径——快速、富有表现力且看似富有创意。但它牺牲了使企业软件可靠的关键结构。正如无类型语言曾迫使行业正视调试和维护中隐藏的成本一样，无上下文的 AI 生成现在也暴露了自己的债务：能编译但不合适的代码。
下一个前沿不仅仅是上下文工程，而是企业级上下文工程，这是一门将 AI 创造力与组织真相绑定在一起的学科。在这种模式中，上下文不是一个短暂的内存窗口或一个巧妙的提示技巧；它是一种企业级结构。它包括类型定义、代码库、测试框架、设计模式、合规策略、业务逻辑以及编码在 Jira 工单、Confluence 页面和内部 API 中的制度历史。
目标不是更快的代码，而是更真实的软件——体现企业意图，在其防护措施内运行，并随着时间的推移可靠地交付价值的软件。上下文工程是我们从氛围驱动的生成转向受控创造的方式。企业级上下文是我们确保今天构建的智能体不仅成为工作的加速器，而且成为定义未来系统的管理者的方式。
