你以为在用 AI 写代码，其实你在给它喂噪音

过去几周，我几乎把 Cursor 的 Agent 功能停掉了。

不是它不好用。
而是我慢慢意识到一件事：现在 AI 编程的差距，越来越不在于你选了哪个工具，而在于你怎么用。

同样是 Claude Code，有人还在把它当成一个更聪明的聊天窗口，反复问、反复补、反复解释；也有人已经把它当成执行系统来用：并行开多个 pane，拆分独立任务，让它做模块开发、做重构、顺手再跑一轮 Code Review。

差距不在模型，甚至也不完全在工具。
差距更像是一种新的使用认知。

很多人以为自己在“给 AI 更多信息”，但实际发生的，往往是另一件事：你在不断给它喂噪音。

---

1. 你以为上下文越多越好，其实很多时候只是更乱

现在很多人用 AI 写代码，还是一种很熟悉的 old pattern：

• 先把大量上下文贴进去
• 再写一个很长的 prompt
• 然后希望它一次性把问题解决

看起来很充分，实际上常常是在把“信息”变成“干扰”。

我现在开一个新任务，第一件事通常不是继续聊，而是先 clear。
原因很简单：上下文不是越多越好，越长越全也不等于越有效。

上下文一多，问题会连着出现：

• 模型响应更慢
• token 成本更高
• 注意力更分散
• 工具更容易把旧任务、旧约束、旧文件关系一起卷进来

有时候 Claude 还会自动触发 compaction，把上下文压缩一遍。很多人没太注意这件事，但它本身就意味着：你前面塞进去的东西，模型也未必真能高质量保留。

所以我现在更相信一个原则：

每个任务，只给最必要的上下文。

跟当前任务直接相关的，留下。
已经完成的、只在上个问题里成立的、会干扰判断的，删掉。

这已经不只是 prompt engineering 了，某种程度上更像 context engineering。
重点不是“怎么说更多”，而是“怎么只给对的东西”。

---

2. 真正拉开效率差距的，不是模型，而是任务拆法

很多人还在讨论：
到底该用 Opus，还是 Sonnet？
到底哪个模型更强？

我不是说模型差距不存在。它当然存在。
但我越来越强烈的感受是：

在大多数日常开发任务里，workflow gap 往往比 model gap 更大。

也就是说，真正决定你效率的，往往不是你点了哪个模型，而是你怎么拆任务、怎么分配上下文、怎么组织执行过程。

我现在比较常用的一种方式，是同时开多个 pane，让不同窗口各做各的事：

• 一个 pane 修当前 bug
• 一个 pane 写新功能
• 一个 pane 专门做重构或 review

它们各自有独立上下文，互不打扰。

这看起来像个小技巧，但背后的变化其实很大。
你不再是在一个对话里反复追问，而是在调度多个独立 worker。

比如一个很常见的场景：

我在处理一个线上异常时，可能会这样分：

• Pane 1：只负责定位 bug 和给出修复方案
• Pane 2：只负责阅读相关模块，列出潜在连锁影响
• Pane 3：不参与实现，只负责看 diff、找边界问题、补测试建议

这样做最大的好处，不只是“并行”，而是上下文更干净。
每个窗口只关心一类目标，模型不会被迫同时记住十件事。

很多人还把 AI 当问答工具。
但我越来越觉得，AI Coding 正在从“对话工具”变成“执行系统”。

你不是在问它问题。
你是在给它分工。

---

3. AI 一直等你点确认，节奏就断了

还有一个变化，我觉得很多人低估了：确认成本。

Claude Code 默认会频繁问你：

• 能不能改这个文件？
• 能不能执行这个命令？
• 能不能继续下一步？

刚开始我也觉得这很合理，甚至觉得更安全。
但用久了我发现，这种频繁确认，对节奏的破坏其实非常明显。

你中间看一眼 Slack，回头一看，它停在那里等你点 yes。
你去处理个别的事，再回来，整个执行流已经断掉了。

后来我开始用：

claude --dangerously-skip-permissions

很多人一看到 dangerously 这个词，第一反应就是“不安全”。
这当然不是一个适合所有场景的默认选项，我也不建议在高风险环境里无脑开。

但它提醒了我一件更本质的事：

你到底愿不愿意把 AI 当执行者，而不只是建议者？

如果不愿意给执行权，AI 很多时候就只能停留在“高级 autocomplete”。
只有当它能持续执行、持续推进、持续把任务走完，它才开始更像一个真正能干活的 agent。

当然，这里一定有边界。
比如我更愿意在这些场景里这么用：

• 本地开发环境
• 自己可控的代码仓库
• 风险明确、回滚容易的任务
• 已经有版本控制和基础测试保护的项目

它不是“绝对安全”，但在合适边界里，带来的节奏提升是真实的。

---

4. Terminal 看起来旧，实际上更像 agent 的原生界面

我一开始用 Claude Code 的时候，其实很不适应 terminal。

总觉得 GUI 更直观，terminal 更像上一代工具。
但用了一段时间后，我反而越来越觉得：这个判断可能反了。

GUI 更适合人。
而 terminal，很多时候其实更适合 agent。

原因很简单：

• 它更轻
• 它更快
• 没有额外的 UI 操作成本
• 命令就是动作，动作就是执行
• 天然可脚本化，可组合，可批量处理

你在 GUI 里做的很多事，本质上是在“操作界面”。
而在 terminal 里，你更像是在“调用系统能力”。

这也是为什么我现在越来越觉得，AI 工具的未来形态，未必是一个花里胡哨的 app。
它更可能越来越像一个系统层：可以调度、可以编排、可以拼接、可以持续执行。

换句话说，AI 工具不一定会更像“应用”。
它可能会更像“基础设施”。

---

5. 真正的门槛，不是会不会写 prompt，而是会不会管理上下文

过去一段时间，很多人都在聊 prompt engineering。
但我现在越来越觉得，在 AI Coding 这件事上，真正拉开差距的，已经不是谁更会写一句漂亮的 prompt。

真正的门槛开始变成：

• 你会不会定义任务边界
• 你会不会拆解问题
• 你会不会管理上下文
• 你会不会把不同任务放进不同执行槽里
• 你会不会审结果，而不是只看它会不会写

这也是为什么，同样一个工具，有人用起来像是“偶尔帮点忙”，有人用起来却已经像是“多了几个可调度的工程执行单元”。

差别不在 AI 本身。
差别在你有没有从“使用工具”，切换到“设计 workflow”。

---

6. 程序员的工作，正在从亲自实现，转向任务建模与结果校验

把这些变化串起来看，我觉得会得到一个更大的结论：

程序员的工作，正在从“亲自完成实现”，转向“定义任务、调度 AI、审核结果”。

当然，这不代表代码不重要了。
也不代表工程能力突然不值钱了。
恰恰相反，工程能力会变得更重要，只是它体现的位置变了。

以前你最核心的价值，可能体现在：

• 自己写出实现
• 自己排查问题
• 自己逐行完成逻辑

现在越来越多时候，你的价值会体现在：

• 能不能把任务拆对
• 能不能把边界说清
• 能不能控制上下文污染
• 能不能设计一条高效执行路径
• 能不能快速判断结果是否可用

也就是说，程序员的核心能力没有消失。
它只是从“直接产出代码”，逐渐迁移到“任务建模与结果校验”。

这也是我最近越来越强烈的一个感受：

很多人还在讨论“AI 会不会替代程序员”。
但更现实的问题可能是：

你会不会被更会用 AI 的程序员替代？

这个时间点什么时候真正到来，我不知道。
但我越来越觉得，它可能比大多数人预期的更近。

---

7. 最后一句

你以为自己在用 AI 写代码。
但很多时候，你只是在把混乱的上下文、更长的 prompt、更多的确认弹窗，一层层堆给它。

真正的差距，不在你有没有用 AI。
而在你有没有开始把它当成一个需要被正确调度的执行系统。

从这个角度看，未来更重要的能力，可能不再只是“我会不会写代码”。

而是：

我会不会让 AI 在干净的上下文里，沿着清晰的边界，把事情真正做完。

---

更多深度内容与完整文章，欢迎关注我的微信公众号：SamLai 效率研习社

主要分享：

AI 编程与开发效率

技术趋势与工程思考

实用工具与工作流