引言：复杂代码的挑战
对超过十万名开发者的调查显示，人工智能在软件工程中的应用面临显著挑战，尤其是在处理复杂的、存在技术债务的现有代码库（Brownfield）时。研究发现，AI在这些场景下往往导致大量返工和代码库的混乱。相比之下，在全新的、简单的项目中，AI工具的表现则非常出色。这种现象与许多资深工程师的个人经验相吻合，即过于陈旧的代码和技术债务会阻碍AI的有效集成。
上下文工程的定义与目标
上下文工程正是为了解决当前模型限制而诞生的，其核心目标是最大化利用现有模型的上下文窗口。尽管初期使用某些工具时体验可能不佳，但通过团队的持续实践和流程的彻底重构，可以实现开发吞吐量高达两到三倍的提升。这种提升会迫使团队改变软件构建和协作的全部方式，过程虽然艰辛，但成果是不可逆的，其最终目标是实现无返工的高效开发。
为了在复杂项目中用好AI，理解大型语言模型（LLMs）的工作原理是第一步。
- 在复杂Brownfield代码库中表现良好
- 解决复杂的技术难题
- 维护团队心智对齐
- 尽可能多地利用模型处理的Token
高级上下文管理
最原始地使用编码代理的方式是不断提问、修正、再提问，直到耗尽上下文窗口或放弃。更智能的做法是识别当前对话已偏离目标时，果断启动一个新的上下文窗口，并明确告知代理避免重蹈覆辙。然而，更进一步的策略是“有意向的压缩”。
上下文工程的核心，就是关于如何从当今的模型中榨取最大价值，以及如何精细化管理我们的上下文窗口。
有意向的上下文压缩
有意向的压缩是指，无论当前进展如何，都主动要求代理将现有上下文（包括对话历史、代码片段、错误信息等）压缩成一个结构化的Markdown摘要。当开启新的工作会话时，可以直接从这个压缩包开始，省去了大量的重复搜索和理解时间，有效避免了后续迭代中的信息冗余和资源浪费。这本质上是一种高级的工程化流程思维。
- 文件查找和理解
- 代码流分析
- 文件编辑操作
- 测试和构建输出
上下文痴迷的原因
对上下文的痴迷源于大型语言模型的本质：它们是无状态的。获得更好输出的唯一途径是提供更优质的输入。在每一次迭代中，模型选择下一步行动都只受迄今为止对话历史的影响。因此，必须持续优化上下文窗口的正确性、完整性、大小和演进轨迹。
如果模型接收的上下文充满了错误和指责，其学习到的“模式”可能就是重复犯错。它看到的是：‘我做错了，人类纠正我，然后我又做错了，人类又纠正我’。那么，下一个最可能出现的输出就倾向于再次犯错。
上下文的负面影响因素
要扭转负面轨迹，必须关注影响模型输出的关键因素。最有害的是错误信息，其次是关键信息的缺失，最后是过多的无关噪音。研究表明，上下文窗口被填充得越满，输出结果往往越差，这引出了“愚蠢区”的概念。
优先级与影响因素
- 最差：不正确的信息
- 次差：缺失的信息
- 噪音：过多的无关信息
愚蠢区概念
“愚蠢区”是一个描述性能拐点的概念：当上下文窗口使用率达到一定阈值后，模型的性能开始显著下降。以某些模型为例，大约在40%的使用率时，就会出现回报递减的现象。如果编码代理的上下文中塞满了过多的中间过程数据和日志，那么工作将完全在“愚蠢区”进行，难以获得理想结果。虽然40%是一个指导性数值，具体取决于任务复杂度，但它为我们的上下文管理提供了关键参考。
巧妙规避愚蠢区的方法
为了巧妙地避开“愚蠢区”，可以采用子代理机制。子代理的目的不是拟人化角色，而是严格控制上下文边界。例如，当需要理解大型代码库的某个复杂模块时，可以引导主代理分叉出一个新的、纯净的上下文窗口，专门负责深度阅读和搜索，最后只将提炼后的、极其简洁的结论返回给父代理。这确保了父代理的上下文始终保持精简和聚焦。
上下文管理与RPI工作流
比子代理更普适的策略是构建“频繁的有意向压缩”工作流，即持续保持上下文窗口小巧，并将整个开发流程围绕上下文管理来设计。这个流程分为三个阶段：研究（Research）、计划（Plan）和实施（Implement）。其核心目标是全程工作在高效的“智能区”内，通过压缩来精确管理意图的表达。
| 阶段 |
主要目标 |
上下文策略 |
| 研究 |
理解系统、定位关键文件、保持客观 |
寻找正确文件，避免过早下结论 |
| 计划 |
概述确切步骤、包含涉及的文件和代码片段 |
明确测试和实现方法，压缩意图 |
| 实施 |
执行既定计划，保持上下文低位 |
确保模型能清晰、正确地执行操作 |
复杂问题的解决实践
在实践中，使用此方法成功修复了某公司一个拥有3亿行代码的Rust项目中的编程语言兼容性问题，并在7小时内交付了35，000行适配代码。这表明，即便面对极其复杂的问题，在受控的流程下也能被有效解决。然而，像“移除Hadoop依赖”这类涉及底层架构重构的终极复杂任务，在初期尝试中失败了，这证明了AI无法替代人类所需的深层架构思考，必须回到白板阶段重新设计。
当前确实有效的方法
当前真正被验证有效的方法是专注于战术性和实践性步骤。其核心是：先进行研究以透彻理解系统，然后通过压缩和上下文管理来构建详细计划，确保整个工作流程始终运行在高效的智能区内。这构成了规范的工程实践的一部分。
心智对齐的关键
代码审查的首要目标是实现心智对齐，即确保团队成员对代码变更及其原因达成共识。对于技术领导者而言，阅读一份详细的计划文件，远比阅读海量的代码差异更能帮助他们跟上系统演进的步伐。一个包含了清晰执行步骤、测试方案和结果的拉取请求，能引导审阅者经历一个完整的逻辑“旅程”，极大提升审查效率和效果。
代码片段计划的价值
随着AI辅助交付的代码量增加，目标是实现杠杆效应，即高置信度地相信模型会执行正确操作。因此，计划本身也需要迭代，最终应纳入实际的代码片段骨架或关键修改点。这确保了意图被高度压缩且执行可靠。计划的长度往往与可靠性成正比，但与可读性成反比，团队需要在两者间找到最佳平衡点。
不要外包思考
核心原则是“不要外包思考”。不存在一劳永逸的“完美提示词”。如果开发者不亲自阅读和推敲计划，整个工具链将无法正常工作。整个流程是围绕开发者与代理之间持续、高质量的反馈循环而构建的。计划在实施前可以发送给同行审查，以确保方法正确、顺序合理。一个糟糕的计划或错误的研究结论，可能导致整个工作方向南辕北辙。
上下文工程的需求弹性
上下文工程的投入深度需要根据任务复杂性弹性调整。例如，更改按钮颜色这类简单任务，无需完整的RPI流程，直接与代理沟通即可。而涉及多个服务或代码库的中等复杂功能，则需要执行完整的研究和计划步骤。团队愿意在上下文工程上投入的深度，直接决定了他们能用AI解决多复杂问题的上限。
总结：RPI工作流与保持在智能区
RPI（研究、计划、实施）工作流的重点在于实践上下文工程和坚决保持在智能区内，而非依赖某种魔法术语或提示词。其本质是通过持续的有意向压缩，管理好与AI协作的“对话上下文”，从而在复杂的棕地代码库中实现可靠、高效的生产力提升。
发表于 昨天 04:26
|
查看: 0|
回复: 0
