黄广民：开发者关心的是效果、效率、成本。而决定 Token 消耗与成功率的，是Coding Agent在背后如何组织上下文、如何调用工具、如何重试与纠错。压力因此更多落在了 CodeBuddy 这类 AI 编程工具上，它们需要为用户提供开箱可用的 Agent 体验。
同时，不同开发者、不同企业的效率提升差异很大，关键变量往往是有没有准备好面向 AI 的内容资产：个人层面的习惯与偏好沉淀，团队层面的工作流、代码规范、知识库与决策记录。在这方面，CodeBuddy提供了充足的能力抓手，例如 rules、hooks、subagent、skills 等；未来还会提供更通用的行业模版、场景模版，让客户以更低成本建设、沉淀资产，进一步减缓这部分压力。
过去一年，AI 编程工具真正走进了工程核心，但随之而来的并不是“代码写得更快”这么简单。
当编程从补全几行代码，演进为让 Agent 把一件事“做完”，很多工程问题被整体抬升到了一个新层级：Token 不再只是计费单位，而成了系统设计的一部分；上下文不再只是输入，而是一种需要被精细管理的工程资源；Spec、规则、工具调用和反馈回路，开始直接决定一个 Coding Agent 能否稳定交付，而不是陷入无休止的重试与返工。
2025 年，越来越多团队意识到：真正限制 AI 编程落地效果的，已经不只是模型能力，而是一整套围绕 Agent 构建的工程体系——上下文如何组织、工具如何协同、成本如何控制、失败如何被治理。
在这次采访中，我们邀请腾讯 CodeBuddy 产品负责人黄广民，从一线产品与工程实践出发，系统拆解 AI 编程工具正在经历的几次关键转折：
为什么 Token 计算突然复杂了一个量级？补全范式是否正在逼近物理极限？IDE、CLI 与 Cloud Agent 各自承担什么角色？上下文工程与 Spec 驱动开发究竟解决了哪些真实问题，又在哪里容易被“形式化”？
这不是一场关于“未来畅想”的讨论，而是一次围绕真实工程约束、成本压力与工具设计取舍的技术复盘。对所有正在尝试、或即将引入 Coding Agent 的团队来说，这些问题，已经无法回避。
一、Token 工程的崛起
InfoQ：过去大家理解 Token 成本很简单：输入多少、输出多少就是多少。但今年整个行业突然发现，Token 计算变得异常复杂，许多工程团队调侃自己在做“prompt 套利”或“上下文金融工程”。在您看来，为何在 2025 年，Token 计算会变得比以往复杂一个量级？
黄广民：本质原因是，大模型应用正在从问答范式升级到以 AI 编程为代表的 Agent 范式，这直接改变了 Token 的经济学模型。Coding Agent 的典型任务不再是“回答一个问题”，而是“把一件事做完”。一旦目标变成任务闭环，Token 成本就从单次输入输出，变成推理-执行-反馈链路的全生命周期成本控制。
Coding Agent 天然是长程任务。为了完成一个任务，往往需要多轮对话；而每一轮对话背后又会经历几次到几百次不等的工具调用。这意味着上下文里存在大量可复用的稳定信息，也就留下了上下文缓存与重用的空间。模型平台的计价规则也有差异，不同模型、不同厂商对输入/输出定价、缓存命中收益、工具调用的隐性开销并不一致，进一步放大了 Token 经济学的复杂度。
第二个变化是，工具调用带来的隐性 Token 开始占大头。大模型刚出现时，成本主要来自对话本身；而现在， 检索返回、文件 diff、终端日志等等，大量工具输出其实是给下一轮模型阅读的，它们会反复回灌进上下文，成为新的主要成本来源。这也是为什么今年大家会特别关注 log 过滤、diff slicing、输出摘要等能力，本质上都是在控制“给模型看的 Token”，把无效信息从上下文里剔掉。
第三个变化是，随着 Spec Coding 的兴起，Coding Agent 的产出不再只是代码文件。Spec、Plan、ToDo、变更说明、验收清单等中间产物会被会被反复生成、引用与迭代。它们提升了任务可控性，但也会形成新的上下文常驻内容，进一步改变 Token 的成本结构。
第四个变化来自多 Agent 协作。多 Agent 把 Token 变成了一个通信效率问题：Agent 之间传什么信息、传到什么粒度、怎么压缩、怎么保持关键信息不丢失，这一过程本质上是在成本与信息有效传递之间做权衡。多 Agent 系统里，信息压缩策略和通信协议本身就成了影响 Token 效率的关键变量。
因此，上下文工程在 2025 年的核心工作可以概括为三件事：
1）把上下文拆成稳定部分与变化部分；
2）让变化部分更精准、长度可控、可验证；
3）用缓存、裁剪、摘要、检索等机制，把 Token 的边际成本压到可控区间，同时避免因信息失真导致的返工成本。
InfoQ：这种复杂度具体压在了谁身上，又带来了哪些工程层面的负担？要克服这些负担，行业需要跨越哪些技术难关？
黄广民：开发者关心的是效果、效率、成本。而决定 Token 消耗与成功率的，是Coding Agent在背后如何组织上下文、如何调用工具、如何重试与纠错。压力因此更多落在了 CodeBuddy 这类 AI 编程工具上，它们需要为用户提供开箱可用的 Agent 体验。
同时，不同开发者、不同企业的效率提升差异很大，关键变量往往是有没有准备好面向 AI 的内容资产：个人层面的习惯与偏好沉淀，团队层面的工作流、代码规范、知识库与决策记录。在这方面，CodeBuddy提供了充足的能力抓手，例如 rules、hooks、subagent、skills 等；未来还会提供更通用的行业模版、场景模版，让客户以更低成本建设、沉淀资产，进一步减缓这部分压力。
工程层面的压力，主要集中在三块：
上下文策略：首先得做好上下文分层，哪些属于稳定指令，哪些属于持久化事实，哪些属于会话、工具临时信息。此基础上再做召回与渐进式披露：先小范围读取、先拿关键信息，按需扩大检索半径；必要时触发压缩与回收，把长对话变成结构化摘要，保留约束。在确保必要的全局理解前提下，降低上下文压力，避免稀释注意力
工具链优化：高性价比的路径是尽可能多用工具。对于AI编程中出现的高频任务，不断扩充工具链的数量和质量，将信息获取、过滤、整理尽可能通过工具完成，工具返回也尽量标准化、结构化
可观测性与失败治理：无限循环和低质量重试是消耗巨大的隐性成本。良好的 Agent 设计，需要能及时发现同一类工具调用是否存在无效循环、上下文是否反复膨胀、失败是否由同一个缺失信息导致；并能在触发阈值后立刻跳出并使用替代方案。而有了可观测性，才能把成本波动变成可优化的工程问题。
二、补全范式的极限
InfoQ：这两年 AI 编程大致走出了两条路：一条是以 GitHub Copilot 为代表的“智能补全”，一条是以各类 Coding Agent 为代表的“任务驱动式开发”。从技术角度看，补全范式本身还存在哪些难以解决的痛点？纯补全范式是不是已经触碰到技术天花板了？
黄广民：一方面，为了不打断开发者心流，补全必须足够丝滑。行业里普遍以几百毫秒量级的端到端时延为目标，这直接约束了可用模型规模、可携带的上下文长度：模型参数不能太大，上下文长度也远不可能用全。
另一方面，补全的能力边界正在从“行内预测”扩展到“跨行、跨函数、跨文件”的续写、改写甚至局部重构。要把这种泛补全做准，系统必须在极短时间内抓住真正相关的全局信息：当前编辑意图、项目约束、依赖关系、代码风格、既有实现等，并在大量相似候选里给出最符合意图、最少副作用的建议。这对泛补全系统的后训练、上下文选择、推理策略与工程链路提出了接近极限的要求。
这是否意味着补全范式已触达技术天花板？我们认为，其效果提升虽已进入深水区，但通过数据、训练和工程链路的精耕细作，有一定优化空间。
然而，由于补全范式自身存在修改范围小、占用开发者注意力多等局限，与能高效生成代码的 Agent 对话模式相比，其持续优化的边际效用正在递减，更适合作为快速修正与收口的补位能力。
InfoQ：如果说补全正在接近自己的“物理上限”，您觉得它未来会在整条 AI 编程技术栈中被放在一个什么样的位置？
黄广民：从趋势上看，随着模型能力和编程工具链的完善，Agent 会覆盖从需求到交付的更多环节，逐渐成为主流程。
但在一些 Agent 还可靠性不够，或者做得到但代价偏高的场景里，补全会成为一个更稳定、更经济的补位能力，帮助开发者完成最后的微调和收口。比如变量重命名、小范围重构、性能敏感代码、线上故障修复这类需要小步推进、随时确认的工作，用补全往往更快：开发者在光标附近逐段接受、即时校正就能完成改动，不必额外引入对话、长链路执行、代码 review 的人机协作流程。
三、AI 编程工具的三条演化主线
InfoQ：如果按形态来拆，过去四年 AI 编程大致沿着三条主线演化：一是以 Copilot、Cursor 为代表的IDE 内嵌式智能补全，二是以 Claude Code 等为代表的 CLI 式对话/推理开发，三是今年开始快速冒头的 Cloud / Background Agent 式并行开发。从您一线观察来看，这三条主线目前在真实工程团队里的分工和占比大致是什么样？
黄广民：从 AI 编程工具的演进路线看，整体是在从高人机交互，逐步走向更强的 Agent 自主执行。
补全是最贴合开发者原有习惯的一层，几乎没有迁移成本。但它天然依赖开发者持续注意力和逐段确认，更多是小步增益；同时受限于实时性和上下文，补全能覆盖的范围、单次生成的代码量也相对有限。
往前一步是 Native IDE 里的 Agent 模式，比如 CodeBuddy Craft。它开始具备自主规划、调用工具链、跨文件修改、生成完整项目等能力，把 AI 从给建议推进到自行完成需求级任务。IDE的产品形态在使用门槛上适中，除了服务专业开发者外，在泛开发者人群中也有了一定的用户基数。
CLI 在专业开发者中接受度更高，尤其擅长处理复杂和长程任务，它能将需求拆解为步骤，驱动工具链反复迭代，甚至通过多 Agent 并发来提高吞吐量。加上开放的可定制性，CLI 往往更容易嵌入团队已有的工程流程和脚本体系，成为重任务的高效入口。
Cloud Agent 则代表更进一步的自动化，连运行环境配置也由平台托管在云端，适合标准化、可并行、长耗时的工作，例如自动修复、代码质量巡检、安全扫描等等。它更靠近流水线，可以成为团队级自动化的主要承载形态。
InfoQ：它们分别最擅长、最不擅长解决哪类问题？是否都在收敛向“Agentic behavior（代理式行为）”？
黄广民：这几种范式的演进，本质上体现了从高人机交互模式，逐步走向更高比例 Agent 自主执行模式的趋势。它们的擅长点，很大程度取决于开发者的注意力放在哪里、交互链路有多长、以及反馈闭环有多自动化。
补全的注意力基本还在 editor。它最擅长的是高频、小步、低风险的改动，但代码贡献的能力有限。
对话式 Agent 的注意力区域主要在 chat panel，同时会在 editor 和 terminal 里查看过程和结果，并把反馈再带回对话。这一类最擅长的是中等复杂度任务，并且需要用户在关键节点确认方向。
CLI 的交互几乎都围绕输入框完成，对专业性要求更高，但也更适合长程任务执行和工程化集成。然而，它在面向泛开发者大规模普及时会遇到瓶颈，也不太适合需要强可视化确认的场景。CLI 的优势是效率，但门槛也更高。
Cloud Agent 则是更进一步的自动化，面向的是从触发到执行的全自主执行。在需要代码 review，及细粒度人机协作的场景则不太适合。
这几种形态并不是割裂的，在底层能力上有很大复用空间，同时也各服务一部分用户和场景。
InfoQ：从 IDE、CLI 到 Cloud / 背景 Agent，这三条 AI 编程路线对基模能力的依赖是否存在明显差异？在您看来，现有基模能力的这些“短板”，具体是怎样限制了这三条路线各自的上限？
黄广民：IDE/CLI/Cloud Agent对于模型能力的要求没有显著差异，Agent 形态模型的核心诉求都趋同：能正确使用工具，能保持长程任务稳定性，能在反馈信号下持续修正。Coding Agent能力本质上是长程任务稳定性和工具调用能力。基模每一次能力跃迁，都会直接带来工具范式升级，编程能力的提升也会外溢到更广义的推理能力上，让模型在逻辑链条、约束遵循和问题拆解上更“靠谱”，这也是腾讯坚决投入Coding赛道的原因之一。
四、上下文工程的演进
InfoQ：过去一两年里，行业在提升 AI 编码可靠性上，先后尝试了 fine-tuning、RAG、大上下文窗口、Agentic search 等多种路径。站在今天回看，你觉得这些方法各自解决了什么问题，又分别在哪些关键点上暴露了局限？
黄广民：在大模型的早期阶段，模型能力和上下文窗口都比较受限，编程工具需要用两类手段把体验先垫起来。一方面通过微调/对齐训练强化代码场景的输出稳定性与贴合度；另一方面通过 codebase RAG 这类更工程化的方法，在有限窗口内更精准地召回相关代码片段，在成本和效果之间取得可用的平衡。
随着模型能力增强、窗口拉大、调用成本下降，Coding Agent 可以把更大的自主性交还给模型。通过把文件阅读、代码搜索和定位等工具做扎实，让模型根据任务自主决策下一步动作，这类接近 Agentic search 的路径更能发挥大模型的潜能，并在各种场景里留出更大的泛化性。
InfoQ：过去，很多团队一开始是把整套代码库都塞进上下文里，后来才发现会掉进“上下文低效区”，于是逐渐转向上下文压缩、按需切片、多 Agent 检索、Research-Plan-Implement这类更精细的做法。在你看来，这一轮上下文工程的演进，最关键的技术进展是什么？
黄广民：从CodeBuddy的视角看，我们认为上下文工程并不是某个单一的技术进步，而是一系列技术组合的持续优化。具体来讲，可以拆成以下几个方面：
上下文资产的生命周期管理和分层策略：System Prompt/规范/工具说明这类稳定信息，应该尽量前置并复用；环境与仓库概况这类半稳定信息，适合增量更新；偏好与项目约定这类长期信息，适合做成按需检索注入；对话与执行状态这类强动态信息，则要控制历史包袱，用摘要/裁剪保持短而准。按需供给的渐进式披露策略：通过Agentic的范式，在每一步触发对应的检索工具，需要什么给什么，而不是用固化的结构一次性塞满。降噪能力补齐：通过裁剪、过滤、摘要让 Token 更有效。工程侧会系统性地做输出净化与结构化，把可用信号密度做上去。缓存与复用：稳定前缀配合 KV cache，让重复内容尽量命中缓存，把长程任务的边际成本压下来。
InfoQ：如果你要用一个真实的案例或转折点，来说明今年上下文技术是怎么从“粗放”走向“精细”，你会讲哪个故事？那一刻让你意识到：真正决定 AI 编码效果的不是模型，而是上下文工程本身？这个转折对你们内部的技术路线带来了怎样的变化？
黄广民：分享两个优化项：针对模型的优化和工具执行层面的优化。
不同模型的能力都很强，但它们各自擅长的领域不同，也都有一些“习惯”或小问题。如果不做针对性优化，模型能力反而很难被真正发挥出来。
例如，早期的 GPT 系列模型在编码任务中，常常会反复向用户确认需求，而不是主动去修改代码。为了解决这个问题，我们在系统提示词中做了针对性的优化。调整之后，GPT 模型在实际任务中能够更果断地行动，而不是停留在反复确认上。
Gemini 3.0 Pro 模型在前端审美和 UI 设计方面明显领先于其他模型。基于这一特点，我们在提示词中有意识地放大了它在界面布局、视觉细节上的优势，让它在合适的场景下发挥出更好的效果。
模型与外部世界的交互，最终都需要通过工具来完成。早期，我们在工程上只是“执行完工具就结束”，并没有把执行结果再反馈给模型。
后来我们做了一个重要调整：不仅把工具执行的结果告诉模型，也把用户对结果的反馈同步给模型。
这样一来，模型就能够逐步形成清晰的认知，例如：
这次修改是正确的，用户已经接受哪些改动不符合预期，需要调整
在这种反馈机制下，模型不再只是“一次性输出”，而是能够更好地对齐用户预期，持续提高后续任务中的表现，极大地提升了模型的效果。
五、Spec驱动开发
InfoQ：现在行业经常把“Spec”一词泛化，有人把它当 Prompt，有人当需求文档PRD，有人当 Research、Planning、Implement 的计划文件。在你们看来，“Spec”与 AI 编程中常说的 Prompt、需求文档和计划文件三者之间，本质区别是什么？
黄广民：Spec是面向实现的契约，包括方案、规划、接口、边界、验收等，偏约束与可验证。Spec 不应该限制在某几种文档形态，而是用来指导代码生成的一切契约的总和。
因此产品文档、设计稿、接口定义、边界条件、验收标准、执行计划都可以被纳入 Spec，它们只是 Spec 在不同阶段、不同粒度下的子集。面向未来，Spec 会出现更多形态，同时也会形成更完善的组织方式，让模型更稳定地按契约生成、按标准验收、按变更持续演进。
InfoQ：很多团队发现：AI 写代码时不是缺 Spec，而是缺上下文（Context）。你们如何看待 Spec 驱动开发与 Context Engineering 的关系？它们解决的是同一个问题吗？还是完全不同的两类问题？
黄广民：它们不是一件事，但有关系。
Context engineering 是底座能力，目标是让 Agent 在长程任务里稳定运转：该看什么信息、什么时候加载、怎么压缩、怎么复用、怎么把工具输出变成有效上下文。它解决的是信息供给与调度的问题。
Spec 则是上下文里最关键的一类内容，属于指导性的 context。它把目标、约束和验收口径讲清楚，相当于给 Agent 一份可执行的契约，告诉它做什么、怎么算做对。
InfoQ：有团队尝试过多种版本的实现，比如“ephemeral Specs（短暂 Spec）”，有“分层 Specs”、“基于 TDD 的Specs”......最后才收敛出一个可用的形态（比如Kiro迭代了七八次才找到形态"）。从技术视角看，为什么 Spec 这么难标准化？
黄广民：Spec 的标准，本质上是软件工程理论在 AI 编程工具中的具象化。然而，软件工程理论经过多年发展，在生产实践中并未形成放之四海而皆准的统一标准。不同的 Spec 变体实际上是在权衡不同的矛盾（如灵活性与严谨性），因此其最佳粒度也因任务而异。
Spec 标准是否有效，确实取决于应用场景，因为 Spec 本质上是在用一种文档/结构去交换三样东西：正确性、效率、维护成本。不同场景对这三者的权重不同，所以不会收敛在单一标准，而是出现多种接受度较高的形态。
InfoQ：很多团队在深度使用 Coding Agents 后，repo 里会同时出现 Agent.md / claude.md / gemini.md / cursor rules / skills / Copilot 配置或第三方如Tessl、BMad Method等一堆文件，内容往往高度重复、只是格式不同。在你看来，一个“更合理的上下文管理方式”应该长什么样——它应该如何做到既能被不同工具/代理复用，又不会让团队陷入配置膨胀与维护噩梦？
黄广民：目前 AI Coding 工具百花齐放，迭代速度都很快。在各自生态里自然会涌现出不同的配置形态和标准，这是必然过程。
CodeBuddy也一直在积极拥抱生态，举个例子，CodeBuddy观察到了skills理念的有效性，也是最早兼容这一标准的 AI 编程工具之一。对开发者来说，同一类资产在不同工具间迁移和复用的成本并不高，不会因为工具切换被绑架。
随着行业发展趋稳，会进一步收敛到更统一的标准和规范，减少重复表达与维护负担。比如 Agent.md 这类约定，本质上就正在形成跨工具可复用的行业标准。
InfoQ：如果让你给出一条落地路线：团队从今天这种“多份规则到处复制”的状态，第一步最该收敛什么、统一在哪一层？（repo 内规范、组织级知识库/registry、还是工具层的 rules/skills）
黄广民：CodeBuddy的做法，是提供多种定义工具，例如rules、skills、hooks等，同时开放企业/项目/个人等多级作用域，帮助用户针对性组合出运行良好的机制。
从分层的角度来讲：
企业级，放强制性、跨项目的红线和合规，比如安全扫描、敏感信息处理、审计要求。项目级，放和代码库强绑定的 Spec、模块约束、依赖使用方式、验收标准。个人/团队偏好：放效率类的偏好配置，比如快捷命令、代码生成习惯、常用脚手架、个人提示词偏好等，允许差异化，不强求统一。
InfoQ：有一种说法是：“Spec 驱动开发它试图把所有思考都结构化，而 AI 工具恰恰不擅长执行结构化思考。”你们赞同这个观点吗？你们认为真正应该结构化的是什么？
黄广民：我部分赞同这个观点，但我认为其对核心矛盾的归因有误。Spec Coding 真正想结构化的，不是思考，而是那些最容易在长程任务里出错、也最值得被验证和沉淀的部分。软件工程本来就是复杂工程，大模型在复杂任务里确实会出现幻觉，也会在长上下文中发生灾难性遗忘或目标漂移。如果没有机制补足，Agent 很容易越做越偏，返工成本会迅速放大。
在这个意义上，Spec 不是一份静态文档，而是一种结构化表达加上配套流程：它需要在执行过程中被更新、被版本化，并且和代码、测试、变更记录保持持续映射。好的 Spec 驱动实践不是先写一份完美 Spec 再开始写代码，而是用 Spec 把正确性口径说清楚，然后在推理-执行-反馈的过程中不断校准 Spec 和代码制品的一致性。这反而比传统开发更接近工程真实状态，需求会变、约束会变、实现会变，关键是让这些变化可追踪、可验证、可回滚。
InfoQ：还有不少声音认为：Spec 过于静态、难以约束执行，并且相当于是“规范驱动开发：瀑布模型回潮”。你赞同这种判断吗？Spec 的失效点（或优缺点）在哪里？
黄广民：如上所述，Spec 的正确用法是活的契约。
在 CodeBuddy 的流程里，Spec 不是一次性文档，而是 Plan-Execute 闭环中的关键中间态，在Spec、执行、反馈中持续修正实现。
InfoQ：如果让你给技术团队一句建议：在 AI 编程时代，是“写更好的 Spec”更重要，还是“减少对 Spec 的迷信”更重要？
黄广民：Spec是工程师和 Agent之间的沟通工具，能帮资深程序员在AI时代释放更大的生产力，也是企业从传统编程平稳切换到 AI 编程的安全护栏。
InfoQ：一个被大量开发者反复吐槽的问题是：Coding Agent 非常喜欢“自己实现功能”，而不是复用成熟库，甚至在你明确指定库之后，依然会用错、或干脆绕开。在你看来，这背后的根本原因是什么？究竟是模型太聪明，还是工程约束太少？那你认为解决这个问题的关键路径是什么？
黄广民：这个问题是模型训练、和工程应用共同作用的结果。
一方面，模型在预训练里看到的语料分布是不均衡的。举个例子，像 matplotlib 这种基础库出现得更多、示例更丰富，模型自然更熟。而plotly这类封装更高、出现更晚的库，语料更少、写法更分散，模型对它们的把握就更弱。另外，模型训练和对齐阶段的奖励往往更偏向运行正确，而不是优先复用。当模型在不确定时，它会倾向于选择最保险的路径。
另一方面是库知识的时效性问题。迭代快，版本差异、API 变更、文档不完整甚至互相冲突都很常见。用户即便明确指定了库，如果没有把正确版本、用法、约束放进上下文，模型还是可能用错。
建议的解决路径是，可以借助 Context7 等 MCP 工具补齐版本、用法与示例等关键信息，用渐进式披露把正确用法注入到任务上下文中。如果是企业内部的组件库，更需要将使用文档、版本说明、示例和最佳实践、使用边界与规范等等进行充分的文档沉淀，通过渐进式披露的方式让Coding Agent了解库的正确使用方式。
InfoQ：如果把 AI 编程工具拆成模型层、IDE 交互层和上下文层，你认为未来真正决定工程效率和可靠性的，会是哪一层？为什么？
黄广民：在 CodeBuddy 的方法论里，我们常用一句工程化表达： Agent = 模型 × 上下文 × 循环，他们的叠加效果是乘数效应。
模型决定上限，而“上下文/工具/循环”决定了Coding Agent能不能稳定逼近上限。