这段时间我越来越强烈地感受到一件事：

同样是 Coding Agent，有人已经把它用成了真实搭档；也有人用了几次之后，最后只剩下一句：不行，还是不靠谱。

更有意思的是，很多时候大家用的还是同一批工具、同一代模型。既然底层能力没有差到像换了一个物种，为什么最后体验会差这么大？

我现在越来越倾向于一个判断：
Coding Agent 的体验差异，越来越不是模型差异，而是上下文工程差异。

真正拉开差距的，不只是模型够不够强，而是你有没有把任务讲清楚、把项目信息喂完整、把中间检查点设计好，以及有没有用“协作”的方式，而不是“外包”的方式去使用它。

同一个 Agent，为什么会像两个产品？

如果你最近经常看 AI Coding 相关讨论，会发现一个很有意思的现象。

一边是极度兴奋的人：

• “已经可以做复杂重构了”
• “多文件修改完全能干”
• “现在真的像带了个能干活的搭档”

另一边则是完全失望的人：

• “除了写 demo 没啥用”
• “一复杂就乱”
• “看起来很聪明，做起来全是坑”

以前我会把这种分歧理解成“有人激进，有人保守”。但现在我越来越觉得，不是这么简单。

因为在很多场景里，大家用的并不是完全不同的工具，很多时候都在用 Claude Code、Codex、Cursor，或者同一代模型能力。既然底层并没有拉开一个数量级，那最后体验为什么会差得这么夸张？

我的答案是：

很多人以为自己在比较模型，实际上比较的是一整套上下文条件。

也就是说，一个 Coding Agent 好不好用，从来都不只取决于它“会不会写代码”，还取决于它是在什么前提下、以什么方式、拿着什么上下文去写代码。

同一个 Agent，放在两个人手里，之所以像两个产品，不一定是因为 Agent 变了，而是因为：

• 一个人给它的是清晰任务、完整上下文、明确约束
• 另一个人给它的是模糊目标、脏乱仓库、全自动幻想

你喂给它的工作环境不一样，它表现出来的能力上限，当然也不一样。

真正拉开差距的，是上下文工程

“上下文工程”这个词现在经常被提到，但很多人理解得还是太窄了。

一提上下文，很多人想到的是：“哦，就是 prompt 写得好一点。”

这当然算，但远远不够。对 Coding Agent 来说，上下文不是一句提示词，而是一整套让它能稳定干活的工作环境。

我更愿意把它拆成四层。

第一层：任务上下文

最基础的一层，是任务本身有没有被说清楚。

比如你让它：

• “帮我优化一下这个项目”
• “把这个模块重构一下”
• “修一修这个功能”

看起来像在提需求，实际上几乎没给边界。

什么叫优化？优化性能、结构还是命名？什么叫重构？是保留行为不变，还是允许改接口？什么叫修一修？是先修 bug，还是顺手补测试？

人类工程师遇到这种需求，都会先追问。但很多人对 Agent 的期待却是：你自己懂。

问题就在这里。Agent 不是不会写，而是它会在不够明确的目标下，擅自补完一个“它以为你想要的任务”。

一旦补完方向偏了，后面就会越来越像在认真推进，但离目标越来越远。

所以一个 Coding Agent 好不好用，第一步不是看模型，而是看你有没有把任务边界讲明白：

• 目标是什么
• 不要做什么
• 成功标准是什么
• 哪些文件可以改
• 哪些行为不能变

很多人抱怨 Agent 不稳定，根子不是它输出随机，而是输入本来就含糊。

第二层：项目上下文

再往上一层，是项目上下文。

这才是 Coding Agent 真正开始分层的地方。因为它不是在做一道算法题，而是在接手一个真实的代码仓库。

而真实代码仓库里，决定它能不能干活的，往往不是代码本身，而是代码之外的那些东西：

• README 有没有写清楚
• 目录结构有没有说明
• 架构分层是不是能看懂
• 哪些模块是历史包袱
• 哪些约定不能碰
• 哪些文件虽然能改，但最好别改

这些信息，对人类工程师来说，通常是靠长期协作和历史经验慢慢补上的。但 Agent 没有这个背景。

它能读代码，不代表它能读出“这段代码为什么长成这样”。它能遍历仓库，不代表它知道“这个目录虽然丑，但背后是线上兼容约束”。

所以很多时候，决定 Agent 质量的，不是模型会不会写，而是：

你有没有把项目里那些隐性知识，提前显式化。

这也是为什么我越来越觉得，像 AGENTS.md、README、目录约定、模块说明这种文件，未来会变得越来越重要。

它们以前主要是写给人看的，以后会越来越像写给 Agent 的“项目操作手册”。

第三层：流程上下文

再往上一层，是流程上下文。

很多人现在用 Agent 的默认方式是：

• 把任务一次性丢过去
• 等它跑一大段
• 最后统一验收

这套方式在简单任务上也许还行，但任务一复杂，就很容易跑偏。

因为 Coding Agent 最危险的地方，往往不是一开始完全不会，而是它一开始看起来很对，中途也一直像在认真推进，但某个阶段开始 quietly drift——也就是悄悄漂掉。

它没有停，也没有报错，甚至还在持续输出。但等你真正回头检查时，才发现它已经偏离目标很远了。

这就是为什么，真正成熟的使用方式，不该是“一次性交付”，而应该是“阶段性推进”。

比如：

• 先让它复述任务边界
• 再让它提出改动计划
• 再进入具体实现
• 每一阶段都做一次人工 review
• 关键节点补测试、补 diff 检查

所以流程上下文的核心，不是让它更自由，而是让它更可校验、更可干预、更可回退。

第四层：组织上下文

最后一层，是组织上下文。

同样是用 Coding Agent，有的团队会把它纳入一个很明确的协作分工里：

• 人定义问题
• Agent 负责探索和实现
• 人做判断与验收
• 工具链负责测试、审批、可观测性

而有的团队会潜意识里把它当成“自动外包”：

• 直接扔任务
• 默认它自己会想明白
• 默认它自己会修正
• 默认它自己会负责质量

这两种思路，最后得到的当然不是同一种结果。

我觉得一个非常有用的心智模型是：

把 Coding Agent 当成一个速度很快、上下文很强、但仍然需要被管理的初级工程师。

它不是不能做复杂任务，它能做。但它并不天然拥有全量业务背景、历史设计原因和组织内部隐性知识，这些东西还是需要人来兜底。

为什么高手更容易觉得 Agent 好用？

现在最容易觉得 Coding Agent 好用的人，往往不是完全不会写代码的人，反而是那些原本就比较强的工程师。

这件事听上去有点反直觉。很多人原本以为，AI Coding 会最先让“不会写的人”也能轻松做软件。但现实更像是：

它先放大了那些本来就会组织问题、拆任务、给约束、做 review 的人。

一个成熟工程师在接任务时，通常会先做几件事：

• 先定义边界
• 再切分问题
• 明确输入输出
• 判断哪些部分风险高
• 设计检查点
• 最后再开始执行

这些能力，以前主要是拿来管理自己和管理团队，现在开始被拿来管理 Agent 了。

所以高手之所以更容易把 Agent 用顺，不是因为他们更迷信 AI，而是因为他们本来就具备一套更成熟的工程组织能力。

这就导致一个很现实的结果：

Agent 更像是能力放大器，而不是能力平均器。

它不会自动把所有人拉到同一水平，它会优先放大那些原本就更会工作的人。

为什么很多人会把 Coding Agent 用废？

如果反过来看，其实很多人不是“没有用上 Agent”，而是很快就把它用废了。

最常见的几种方式，大概是这样的：

1. 任务太大，边界太糊

一上来就让它重构整个项目、优化整个架构、顺手把历史问题都处理一下。这类任务对人都很难，对 Agent 只会更糟。

2. 项目上下文太脏

没 README、没目录说明、没模块边界、没技术约定、历史包袱全靠口口相传。这时候你不是在让 Agent 写代码，你是在让它猜谜。

3. 期待它一次生成直接交付

很多人潜意识里把 Agent 当成“高级外包”：任务扔过去，回来一个完整结果，然后自己只负责看结论。但真实情况是，Coding Agent 更像一个需要被引导、被校验、被约束的协作对象。

4. 只关注生成，不关注验证

很多人看 Agent，看的还是“它能不能写出来”。但到了真实工程里，更重要的是：

• 它写的有没有副作用
• 它改的边界对不对
• 它有没有破坏已有逻辑
• 它是不是只是表面可运行
• 它有没有留下新的技术债

5. 把它当替代者，而不是协作者

如果你希望 Agent 完全替代你的思考，那最后很大概率会失望。但如果你把它看成一个协作放大器，它就会变得非常有价值。

真正的大问题，不是“它会不会写”，而是“它会不会中途漂”

我现在越来越觉得，AI Coding 里最值得重视的问题，不是首轮生成质量，而是漂移。

因为现在很多 Agent 的真实状态已经不是“完全不能用”了。恰恰相反，它们很多时候在开始阶段表现得相当不错。

问题在于，一旦任务变长、上下文变多、决策链变复杂，它就会出现一种很麻烦的现象：

不是突然死掉，而是悄悄偏掉。

而这种漂移最麻烦的地方在于，它有很强的迷惑性。

比如：

• 它不是报错
• 不是卡住
• 不是停止
• 而是还在继续输出，还在做出一副“我正在高效工作”的样子

你如果没有阶段性检查点，很可能会在最后才发现：方向偏了、改动范围错了、理解前提错了。

所以未来真正成熟的 Coding Agent 体系，拼的不会只是生成质量，而是这些能力：

• 漂移监控
• 中间状态可见
• 关键节点 review
• 测试与验证自动接入
• 人工接管机制
• 回滚与重试机制

这也是为什么我越来越不把 AI Coding 理解成一个“模型问题”，而是把它理解成一个“工程系统问题”。

AI Coding 的下半场，拼的不是模型战争，而是上下文战争

模型当然还会继续变强。但只要模型整体进入“都能用”的阶段，真正拉开差距的，就不再只是底层模型参数，而是你围绕它搭出来的那整套工作系统。

换句话说，AI Coding 的下半场，拼的不是单点模型战争，而是上下文战争。

谁更会赢？

不是那个喊“全自动编程”最响的人，而是那个更早把下面这些东西做出来的人：

• 可消费的项目知识
• 清晰的任务拆解方式
• 稳定的 AGENTS.md / README / 工作约定
• 明确的人机协作边界
• 能发现漂移的流程设计
• 可验证、可回退、可接管的执行系统

所以未来一项越来越重要的能力，可能已经不是“写代码”本身，而是：

把问题组织成 AI 能稳定完成的样子。

最后

AI 不会自动让每个人都变成高产工程师。

它会先放大那些更会组织任务、表达约束、管理上下文的人。它不是天然的能力平均器，更像是新一代的能力杠杆。

所以如果你问我，今天真正值得练的能力是什么？

我会说，不只是写代码，而是：

• 定义问题
• 设计边界
• 组织上下文
• 管理协作
• 判断结果

因为在 AI Coding 时代，真正稀缺的，不只是“把代码写出来”的能力，而是把工作组织成一个 Agent 能稳定完成的系统。

同样的 Coding Agent，有人觉得神，有人觉得废。真正的分水岭，往往不在模型，而在你是怎么工作的。

发布物料备份

摘要

同样是 Coding Agent，为什么有人觉得像神，有人却觉得像废？问题越来越不只是模型强不强，而是任务边界、项目上下文、流程设计和人机协作方式差太多。AI Coding 的下半场，拼的不是模型战争，而是上下文战争。

导语

很多人以为自己在比较模型，实际上比较的是一整套上下文条件。
同样的 Coding Agent，在不同人手里之所以像两个产品，不一定是因为 Agent 变了，而是因为工作方式变了。

结尾金句备选

1. 同样的 Coding Agent，有人觉得神，有人觉得废。真正的分水岭，往往不在模型，而在你怎么工作。
2. AI 不会自动让每个人都变成高产工程师，它会先放大那些更会组织任务、表达约束和管理上下文的人。
3. 在 AI Coding 时代，真正稀缺的能力，不只是写代码，而是把工作组织成一个 Agent 能稳定完成的系统。

封面文案备选

• 为什么同样的 Coding Agent，有人觉得神，有人觉得废？
• 很多人不是没用上 Coding Agent，而是很快把它用废了
• Coding Agent 的差距，越来越不是模型差距，而是上下文差距