为什么我们仍然需要 IDE
内容提要
文章认为，AI编码代理普及后IDE仍不可替代：代理虽能执行多文件修改，但开发者仍需在IDE中掌握完整项目上下文、验证结果并承担责任。编码瓶颈已从写代码转向审查与判断，IDE的类型检查、导航和测试等工具既帮助人理解代理产出，也应供代理使用。作者还强调应通过ACP和BYOK避免被单一模型供应商锁定，保持工具选择自由。
延伸解读
从“写代码”到“审代码”的转变
文章指出，AI代理能快速生成代码，但瓶颈已转移到验证环节。开发者需要判断代码是否正确、是否处理了用户实际遇到的边界情况、是否符合系统整体行为。阅读和理解代理产出的代码比以往更耗时，但这本就是工程中应有的慢工。IDE的类型检查、导航和测试工具，正是帮助开发者完成这种深度审查的关键。
责任无法转移给代理
即使大部分代码由代理编写，提交记录上仍是开发者的名字。文章强调，你不能拥有自己不理解的东西。当代理写的代码出问题，凌晨被叫醒、参加事后复盘、面对绩效评估的都是开发者本人。因此，在IDE中结合上下文审查变更、理解其影响并能够解释和辩护结果，是承担责任的具体方式。
让代理使用开发者的工具
文章提出，IDE的确定性工具不仅服务于人，也应供代理使用。LLM本质是概率性猜测，而类型系统、linter和测试给出的是确定结果。如果代理能在任务中实时检查类型、看到lint错误、运行刚破坏的测试，就能基于更可靠的信息做决策，减少事后修补。这比单纯让代理“更聪明”更能缩小猜测与系统实际行为之间的差距。
避免被单一模型供应商锁定
文章警告，将整个工作流绑定到一家模型供应商存在真实风险：供应商可能调价、被收购、弃用模型或出现服务中断。如果切换供应商需要重建工具和配置，切换成本就会变成留下的理由。ACP提供IDE与代理通信的通用方式，BYOK让开发者自带凭证选择模型，两者分别解决互操作性和控制权问题，使IDE成为稳定层而非锁定层。
Q&A
AI编码代理已经能自动改代码了，为什么开发者还需要IDE？
因为代理虽然能执行多文件修改，但开发者仍需在IDE中掌握完整项目上下文、验证结果并承担责任。IDE提供类型检查、导航、测试等工具，帮助人理解代理产出，并让代理使用同样的工具做出更明智的决策。
使用编码代理后，开发者的工作瓶颈发生了什么变化？
瓶颈从写代码转向审查与判断。开发者更多时间用于阅读代理的计划、发现遗漏的边界情况、判断变更是否正确，而不是逐行输入代码。验证和确保代码正确成为新的慢环节。
为什么说“代理写的代码”仍然需要开发者负责？
因为提交记录上是开发者的名字，出问题时需要开发者调试、解释和辩护。代理不会在凌晨被叫醒处理故障，也不会参加事后复盘。只有真正理解变更，才能拥有代码并承担责任。
IDE如何帮助代理更好地工作，而不仅仅是辅助人类？
IDE可以将类型解析、linting、实时错误检查等确定性工具提供给代理，让代理在任务中检查类型、看到lint错误、运行测试，从而基于确定事实而非概率猜测做决策。
什么是ACP和BYOK，它们如何避免被单一模型供应商锁定？
ACP（Agent Client Protocol）为IDE和编码代理提供通用通信方式，减少定制集成；BYOK（Bring Your Own Keys）让开发者自带模型凭证。两者结合实现互操作性和控制权，切换模型无需重建工作流。
文章用“驾驶舱”比喻IDE，这个比喻说明了什么？
比喻说明代理像飞行计算机能处理复杂执行，但飞行员仍需驾驶舱查看仪表、理解状态并在需要时干预。IDE就是开发者的驾驶舱，让开发者引导、验证并对最终结果负责。
