因此，未来 AI 编程的真正分水岭，或许并不仅仅在于“谁的模型更强”，而还在于谁能够持续、准确地把工程世界中那些原本隐性的约束、记忆和共识，转化为模型可理解、可执行、并可被反复验证的上下文结构。AI 编程从来不是单一模型能力的比拼，而是工程体系与模型能力共同作用的结果。当然，开发者和 AI 的协作方式，也会决定了能否使用好它产出好的结果。
InfoQ：这两年 AI 编程大致走出了两条路：一条是以 GitHub Copilot 为代表的“智能补全”，一条是以各类 Coding Agent 为代表的“任务驱动式开发”。从技术角度看，补全范式本身还存在哪些难以解决的痛点？纯补全范式是不是已经触碰到技术天花板了？如果说补全正在接近自己的“物理上限”，您觉得它未来会在整条 AI 编程技术栈中被放在一个什么样的位置？
天猪：我更倾向于把这两年的变化理解为一次编程范式的转移：从 AI 辅助编程 → AI 结对编程，甚至在部分场景下开始走向 AI 主导、人类决策的 AI 自主编程。
因此，与其说未来谁会胜出，不如说谁能更早构建出“以 AI 为主、工具为辅、人类做决策”的完整工程体系，谁就能更早跨过下一阶段的门槛。
InfoQ：你曾把 AI 形容为“每个人专属的高潜实习生”。在你看来，开发者要真正用好这个“实习生”，在任务拆解、上下文输入和角色分工上，最需要完成哪些认知与能力上的转变？
天猪：AI 本质上就是每个人专属的“高潜实习生”。
现在很多人一边觉得 AI 编程很震撼，一边又觉得它“很垃圾”，往往并不是模型本身的问题，而是没有找到与 AI 在不同阶段协作的正确方式，也没有管理好自己的预期——短期高估、长期低估。
把 AI 当作实习生来理解，会更贴近现实：你需要为它安排合适的任务，提供足够且结构清晰的指导与信息输入；在过程中随时帮它兜底，并在关键节点准备接手。这和带一个真人实习生并没有本质区别——要么没用好，要么没雇好。
很多使用上的挫败感，来自几个常见误区：有人试图用“甩手掌柜”的方式，在几乎不给上下文的情况下，只用一句话就要求 AI 完成正式项目；有人不断给 AI 指派超出其当前能力边界的事情，却仍期待它交付理想结果；也有人在模型选择上“抬手就上”，希望用 GPT 3.5 去完成本该交给 Claude 4 的任务。
过去两年，AI 编程工具的进化速度明显加快。从 Copilot 式的智能补全，到能够独立拆解任务、调用工具、提交 PR 的 Coding Agent，AI 正在从“辅助写代码”，逐步走向更深度地参与，甚至在部分环节开始主导研发流程。
对于这种范式改变，TRAE 核心开发者天猪用一句话概括了他的直观感受：“AI 就是每个人的专属实习生。” 对应到协作模式上，他将行业的变化总结为一条清晰路径：从 AI 辅助编程，到当下更常见的 AI 结对编程，并在部分场景中开始触及 AI 自主编程 的领域。
更有意思的是，他把这股浪潮指向了一个更“老”的问题：如果 AI 真的能持续理解并执行自然语言，那规范驱动开发（Spec）会不会成为一种比代码更高层、更稳定的工程产物？
与此同时，这一迁移也让一系列原本隐性的工程问题被集中放大：Token 成本结构为何变得更复杂？补全与 Agent 的分工边界在哪里？IDE / CLI / Cloud Agent 三种形态将如何演进？以及行业关注点又如何从 Prompt Engineering，进一步转向 Context Engineering 的技术体系。
围绕这些问题，InfoQ 与 TRAE 核心开发者 天猪 展开了以下对话。
AI编程的范式变革：从“人写代码”到“AI 执行、人类决策”
InfoQ：如果把 AI 编程工具拆成模型层、IDE 交互层和上下文层，你认为未来真正决定工程效率和可靠性的，会是哪一层？为什么？
天猪：在 AI 编程体系中，大模型负责“思考”，Tool 负责“行动”，IDE 承载人机交互，而上下文则负责“记忆与连续性”。这四者共同决定了系统的效率与可靠性，缺一不可。
模型层决定了上限，它负责理解、推理和生成；Tool 决定了模型是否真的“能做事”，而不只是“会说话”；IDE 交互层决定了人是否能高效地表达意图、修正方向；上下文层则把这一切粘合在一起，承载历史决策、工程约束与连续性，是长期可靠性的基础；
因此，未来 AI 编程的真正分水岭，或许并不仅仅在于“谁的模型更强”，而还在于谁能够持续、准确地把工程世界中那些原本隐性的约束、记忆和共识，转化为模型可理解、可执行、并可被反复验证的上下文结构。AI 编程从来不是单一模型能力的比拼，而是工程体系与模型能力共同作用的结果。当然，开发者和 AI 的协作方式，也会决定了能否使用好它产出好的结果。
InfoQ：这两年 AI 编程大致走出了两条路：一条是以 GitHub Copilot 为代表的“智能补全”，一条是以各类 Coding Agent 为代表的“任务驱动式开发”。从技术角度看，补全范式本身还存在哪些难以解决的痛点？纯补全范式是不是已经触碰到技术天花板了？如果说补全正在接近自己的“物理上限”，您觉得它未来会在整条 AI 编程技术栈中被放在一个什么样的位置？
天猪：我更倾向于把这两年的变化理解为一次编程范式的转移：从 AI 辅助编程 → AI 结对编程，甚至在部分场景下开始走向 AI 主导、人类决策的 AI 自主编程。
以 Copilot、Cursor 为代表的智能补全，本质上是一种以人为主导的编程方式。人仍然在持续写代码，AI 的角色是预测“下一个字符”或“下一个编辑位置”，在局部范围内提高速度和流畅度。它的天然痛点也在这里：补全对上下文窗口、代码局部性和人类输入节奏高度敏感，很难跨越文件、跨模块去理解更高层的意图，因此在复杂任务上始终是“加速器”，而不是“执行者”。
但我并不认为补全范式已经触碰到了技术天花板。原因有两点：一方面，确实有大量开发者仍然享受“亲自写代码”的过程，在这些场景下，补全的体验上限仍然有很大提升空间；另一方面，更重要的是，补全并不只是一个面向人的能力，它更像是一种基础原语。
从技术本质上看，补全解决的是“给定上下文，预测下一步最合理的编辑动作”。过去这个能力主要用来辅助人，但在 Agent 体系里，它同样可以被用来辅助 AI 自己执行。又比如 Agent 的对话面板、工具调用参数补全等都可以视为一种“补全场景”。
因此我更倾向把补全看成 AI 编程技术栈中的基础能力层，而不是终极形态。未来它不会消失，而是会被重新放置：在人主导的场景中，它是效率工具；在 Agent 主导的场景中，它可能退到幕后，成为支撑 Agent 精细执行的底层能力之一。
从这个角度看，真正的变化并不是“补全 vs Agent 谁赢了”，而是在不同场景下，人和 AI 在编码过程中的主导权正在发生动态调整。补全和 Agent 并不是对立关系，而是处在同一条技术演进路径上的不同层级。
InfoQ：当前 AI Coding 主要沿着 IDE、CLI 和 Cloud Agent 三条路线演进，很多人认为它们在理念和终局上存在分歧。你是否认同这种判断？在你看来，这三种形态之间究竟是竞争关系，还是正在走向某种共同的 Agent 主导范式？
天猪：从我的视角来看，其实并不太认同“这三条路线在本质上存在巨大分歧”的说法。无论是 IDE 、CLI，还是 Cloud Agent，本质上都在朝着同一个方向演进：以 AI 为主导的研发范式。差异更多体现在形态和使用场景上，而不是能力目标上。
这也是我们在 TRAE SOLO 一直践行的核心理念：AI 不再只是附着在工具上的能力，而是逐步成为研发流程中的主导角色。围绕这一点，很多传统工具形态都会被重新拆解和重组。
从技术演进来看，IDE 正在发生的是一次“能力原子化”和 AI Friendly 化的过程。过去 IDE 里大量以人为中心设计的能力，正在被拆解为一个个更细粒度的 Tool，由 AI Agent 按需调用。IDE 不再只是“人写代码的地方”，而更像是一个能力容器和执行环境，供 Agent 与人协作使用。相比之下，CLI 和 Cloud Agent 从一开始就是 Agent 主导的形态。它们对 UI 的依赖显著降低，要么是 Terminal，要么是简化的 Web 界面加上 GitHub Pull Request 作为协作媒介。这里的重点不在于交互是否精致，而在于是否能够让 Agent 高效地执行任务。
如果从真实工程团队的使用情况来看:
IDE 形态依然是主流入口，因为它最符合程序员长期形成的工作习惯。但我觉得 IDE 的形态本身未必还会是以 Editor 为中心的形态。我们在今年年初也分享过一个判断：专业生产力工具的颠覆式创新，往往伴随着对开发者认知和工作方式的全面重塑，IDE 的形态本身很可能在三年内发生根本变化。TRAE 的 SOLO 模式、Cursor 的 Agent 模式，正是业界围绕这一方向展开的探索与实践。CLI 更擅长的是融入既有工作流，尤其是在 CI/CD、自动化脚本和工程流水线中。当下 CLI 的流行，一方面确实得益于 Claude 等模型本身效果足够好，另一方面也因为它几乎不改变开发者原有习惯——无论使用什么 IDE，都可以在 Terminal 中直接调用。这种“低侵入性”是 CLI 的优势，但它并没有在交互层面解决特别新的问题。而 Cloud Agent 更像是协作模式的变化。它适合那些不需要人实时盯着的任务：比如下班前把一个需求交给远端 Agent，在手机上查看进度、做决策，回到家后在另一台设备上接管结果。这类形态的出现，也和云端资源、统一环境以及并行执行能力密切相关。
从这个角度看，这三条路线并不是在相互竞争，而是在不同层面分工协作，并且都在不同程度上向 Agentic Behavior 收敛。IDE 在“人 + Agent”的协作体验上持续进化，CLI 在工程自动化和流水线中强化 Agent 能力，而 Cloud Agent 则在时间和空间上扩展了研发协作的边界。至于它们对基模能力的依赖，我反而不觉得存在本质差异。模型的短板会同时限制这三条路线：对复杂工程上下文的理解能力、长期记忆与一致性、对隐性工程约束的遵循程度，都会直接决定 IDE、CLI 和 Cloud Agent 的上限。区别只是这些限制在不同形态下暴露得早或晚。
因此，与其说未来谁会胜出，不如说谁能更早构建出“以 AI 为主、工具为辅、人类做决策”的完整工程体系，谁就能更早跨过下一阶段的门槛。
InfoQ：你曾把 AI 形容为“每个人专属的高潜实习生”。在你看来，开发者要真正用好这个“实习生”，在任务拆解、上下文输入和角色分工上，最需要完成哪些认知与能力上的转变？
天猪：AI 本质上就是每个人专属的“高潜实习生”。
现在很多人一边觉得 AI 编程很震撼，一边又觉得它“很垃圾”，往往并不是模型本身的问题，而是没有找到与 AI 在不同阶段协作的正确方式，也没有管理好自己的预期——短期高估、长期低估。
把 AI 当作实习生来理解，会更贴近现实：你需要为它安排合适的任务，提供足够且结构清晰的指导与信息输入；在过程中随时帮它兜底，并在关键节点准备接手。这和带一个真人实习生并没有本质区别——要么没用好，要么没雇好。
很多使用上的挫败感，来自几个常见误区：有人试图用“甩手掌柜”的方式，在几乎不给上下文的情况下，只用一句话就要求 AI 完成正式项目；有人不断给 AI 指派超出其当前能力边界的事情，却仍期待它交付理想结果；也有人在模型选择上“抬手就上”，希望用 GPT 3.5 去完成本该交给 Claude 4 的任务。
归根结底，一分钱一分货。用 20 美元的月费，却期待跑出 2000 美元级别的 token 产出，本身就是不现实的预期管理。
更重要的是，开发者的角色认知也在发生转变：从执行者走向指挥官。
随着 AI 逐步成为专业生产力工具，它带来的颠覆式创新必然会重塑开发者的认知与工作方式。未来的 IDE 很可能不再是今天这种“以 Editor 为中心”的形态，这种变化甚至可能在三年内发生。也正因为如此，每个人都需要学会如何正确地与 AI 协作。
这意味着你不再只是亲自执行每一行代码，而要承担更多的指挥官角色：
需要有系统设计能力，能够把模糊需求转化为清晰的 PRD、RFC。需要有项目管理能力，能够复杂的工作拆解成清晰的步骤和 Task，理解不同 LLM 和 Agent 的脾性并善用。需要有高效的沟通能力，能够总结提炼问题，提供必要的有效的上下文信息，帮助它纠偏。你也需要一种 Leader 的心态：保持好脾气，随时准备好接手补位，虽然它是一个骂不跑的实习生，但还是要保持素养，专注解决问题。
从 Prompt 到 Context：上下文工程的演进
InfoQ：随着 AI Coding 从早期的 Chat 模式走向长期运行的 Coding Agent，你如何看待行业从 Prompt Engineering 转向 Context Engineering 的演进？在这一过程中，Fine-Tuning、RAG、大上下文窗口、agentic search 等各自扮演了怎样的角色，而真正决定上限的关键又是什么？
天猪：随着大模型智能水平的持续提升，行业对 AI Coding 的理解也在不断演进，其关注点正逐步从 Prompt Engineering 转向 Context Engineering。
在早期，Fine-Tuning 被视为一种直接方案：通过在大模型层面注入领域知识，补充其世界模型的盲区。但实践很快证明，这种方式在 AI Coding 场景下成本高昂、灵活性不足，且难以应对多模型频繁切换的现实需求。相比之下，以 RAG 为代表的 “外挂式知识补充” 在工程上更具性价比，也更符合 AI Coding 的实际使用模式。
在 AI Coding 的早期阶段，交互主要是一问一答的 Chat 模式，模型对“首轮输入 Context”的依赖极高，因此需要在提问时尽可能一次性注入相关背景，这直接推动了 RAG 召回机制的普及。
随着 Coding Agent 的出现，协作模式发生了根本变化：交互从单轮对话转向多轮、长期的 Agent Loop。此时，相关信息不再需要在第一轮全部给出，而是由 Agent 在执行过程中按需检索与召回。这一变化催生了 embedding search 与 grep 等能力的逐步登场。
需要强调的是，embedding search 并未过时。它更像是数据库中的 index，在特定条件下能够显著提升召回效率，而 grep 则在确定性和精确匹配上具备优势，两者服务于不同的检索阶段和需求类型。
进一步地，随着任务复杂度和检索路径的增加，Agentic Search 逐渐演化出来，并常与 Sub Agent 机制协同出现。在复杂场景中，许多 Tool Call 的中间历史并不具备长期价值，因此会出现专门的 Search Agent：它自身运行一个独立的 Agent Loop，负责多轮检索、筛选与验证，而 embedding search、grep、LSP 等仅仅是其可组合使用的工具能力。
最后，大上下文窗口“重要，但也不重要”。真正关键的并不是上下文的长度，而是有效 Context 的质量： 如何精准地组织上下文、在何时补充信息、在何时主动遗忘无关内容，标志着 AI Coding 正从粗放式堆叠走向精细化管理。
归根结底，大模型本身的智能水平与高质量、可控的上下文构建能力，缺一不可。
Token 复杂化的根源，是上下文
InfoQ：为什么在 2025 年，Token 计算会突然变得比以往复杂一个量级？这种变化背后的根本原因是什么，又给工程团队带来了哪些新的技术和成本挑战？
天猪：我认为 2025 年 Token 计算之所以会突然变得复杂一个量级，是因为大模型智能水平的提升，正在把 AI 编程和智能应用推向更复杂的真实工程场景。
在早期，模型更多解决的是局部、一次性的生成问题，输入和输出都相对短，Token 成本几乎等同于“你这次对话用了多少字”。但随着模型能力提升，它开始参与长流程、多轮协作、跨文件乃至跨系统的任务，这些场景天然依赖大量上下文。于是，Token 不再只是一次调用的成本，而变成了一个贯穿整个 Agent Loop 的持续性资源消耗。
当上下文开始跨越多轮对话、多个工具调用、多个子 Agent，Token 的构成也随之变得复杂：既包括显式输入输出，也包括系统提示、工具调用记录、检索结果、历史决策、缓存与回放等隐性消耗。这也是为什么不少工程团队会调侃自己的原因——因为如何组织、裁剪和复用 Context，已经直接决定了成本结构本身。
我们需要开始精细化地管理上下文：哪些信息必须长期保留，哪些是阶段性的，什么时候该补充，什么时候该遗忘。这不仅是模型效果问题，更直接影响系统的可扩展性、稳定性和单位成本。
从行业层面看，真正需要跨越的并不是某一个单点技术，而是有效 Context 的工程化管理能力。谁能把上下文组织得更精准、信息密度更高、复用效率更好，谁就能在效果和成本之间取得更有竞争力的平衡。
自然语言不再只是描述，而正在成为规范
InfoQ：在你看来，Spec 驱动开发在 AI Coding 中试图解决的核心问题是什么？它与 Vibe Coding 以及 Prompt / Plan 这类做法的本质区别在哪里？
天猪：Spec 试图解决的核心问题是：如何把“模糊的意图”转化为“可被 AI 与人类共同执行的明确约束”。
如果做一个比喻，Vibe Coding 更像是只给出一句方向性需求，然后在实现过程中不断通过即时反馈来修正路径；而 Spec Coding 则是在动手之前，先把需求的边界、约束充分对齐，再在共识基础上推进实现。
业界目前在 Spec Coding 的探索，让我回想起软件工程早期反复追求却始终未完全实现的目标：是否存在一份足够完备、可验证的描述，它本身就能够清晰定义系统如何运作，并且可以被可靠地复现？在这个愿景下，Spec 不再只是代码的前置说明或过程记录，而有可能逐步演化为一种比代码更高层、也更稳定的工程产物。
然而现实是骨感的，当前行业对 Spec 还处于探索阶段：Spec 是最终事实，还是阶段性产物？当系统演进时，旧 Spec 如何失效、合并或被覆盖？虽然大家在用同一个词 Spec，但往往在不同语境下指代不同层次的问题。Prompt 更多解决的是“这一轮模型该做什么”，PRD 面向的是人类之间的需求沟通，而 Plan 描述的是执行路径。Spec 更像是一组可被反复执行和验证的工程约束——它关心的是什么是允许的、什么是不允许的，什么算成功、什么算失败。
很多团队在实践中会有一个直观感受：AI 写代码时并不是缺 Spec，而是缺 Context。我对这件事的理解是，两者解决的并不是同一个问题。Spec 驱动开发关注的是我们是否已经想清楚要构建一个什么样的系统，而 Context Engineering 关注的是在当前这个时刻，模型是否拿到了足够的信息来做出正确决策。Spec 本身并不会自动转化为有效的上下文，但它往往是高质量 Context 的长期来源，两者在 AI 编程时代高度耦合，却无法相互替代。也正因为如此，Spec 才会显得格外难以标准化。难点并不在格式，而在于它承载的是人的系统性思考过程：认知在演进、约束在变化，执行结果会反过来修正理解。无论是 ephemeral specs、分层 specs，还是基于 TDD 的 specs，本质上都是在探索一个问题：Spec 应该在什么时间点冻结、冻结到什么粒度，以及如何在持续演进中被证伪和更新。
这些问题今天仍高度依赖工程实践本身。但我并不认为这是方向性问题，而更像是一个随着模型能力与工程范式共同演进、迟早会被“工程化解决”的问题。
InfoQ：你怎么看“AI 让自然语言第一次有机会成为工程产物”这件事？Spec Coding 在这条抽象演进链条里到底想实现什么——它是要用自然语言替代代码，还是在探索一种比代码更高层、但仍可约束、可验证的新表达形态？
天猪：早期计算机的最终产物是 0 和 1，后来我们发明了汇编，再到高级语言、DSL、配置文件、声明式规范，本质上都是在不断提高“可表达意图”的抽象层级。每一次抽象升级，都会伴随“不精确”“不安全”的争议，但最后往往通过工程约束和工具链把它收敛下来。
自然语言过去被认为不适合作为工程产物，是因为它既不精确，也无法被稳定执行。但 ChatGPT 之后，这个前提发生了变化：自然语言第一次具备了可被机器持续理解、解释、校验和修正的执行环境。
Spec Coding 的目标是“用自然语言完全替代代码”，而更像是在探索一种新的中间形态：一种比代码更高层、但又比纯自然语言更可约束、更可验证的表达。它可能仍然是不完美的、非确定性的，但在 AI 的参与下，这种不确定性是可以被工程化管理的。
让工程产物不断向“更贴近人类意图”的方向演进，只是这一次，机器终于跟得上了。
当然，这条路并不轻松。自然语言的模糊性决定了它很难被直接工程化，也注定这是一条充满挑战、尚无成熟范式的探索路径。但正因如此，它才成为当下业界正在反复试探和逐步推进的一个方向，而不是一个已经被证明或被否定的结论。我并不敢下论调这条路是否走得通，但至少当下它很值得我们去探索一下。