推倒就完事了
80.69M · 2026-03-22
过去几周，我几乎把 Cursor 的 Agent 功能停掉了。
不是它不好用。 而是我慢慢意识到一件事：现在 AI 编程的差距，越来越不在于你选了哪个工具，而在于你怎么用。
同样是 Claude Code，有人还在把它当成一个更聪明的聊天窗口，反复问、反复补、反复解释；也有人已经把它当成执行系统来用：并行开多个 pane，拆分独立任务，让它做模块开发、做重构、顺手再跑一轮 Code Review。
差距不在模型，甚至也不完全在工具。 差距更像是一种新的使用认知。
很多人以为自己在“给 AI 更多信息”，但实际发生的，往往是另一件事：你在不断给它喂噪音。
现在很多人用 AI 写代码，还是一种很熟悉的 old pattern：
看起来很充分，实际上常常是在把“信息”变成“干扰”。
我现在开一个新任务，第一件事通常不是继续聊，而是先 clear。
原因很简单：上下文不是越多越好，越长越全也不等于越有效。
上下文一多，问题会连着出现：
有时候 Claude 还会自动触发 compaction，把上下文压缩一遍。很多人没太注意这件事，但它本身就意味着：你前面塞进去的东西，模型也未必真能高质量保留。
所以我现在更相信一个原则：
跟当前任务直接相关的，留下。 已经完成的、只在上个问题里成立的、会干扰判断的，删掉。
这已经不只是 prompt engineering 了，某种程度上更像 context engineering。 重点不是“怎么说更多”，而是“怎么只给对的东西”。
很多人还在讨论： 到底该用 Opus，还是 Sonnet？ 到底哪个模型更强？
我不是说模型差距不存在。它当然存在。 但我越来越强烈的感受是：
也就是说，真正决定你效率的，往往不是你点了哪个模型，而是你怎么拆任务、怎么分配上下文、怎么组织执行过程。
我现在比较常用的一种方式，是同时开多个 pane，让不同窗口各做各的事：
它们各自有独立上下文，互不打扰。
这看起来像个小技巧，但背后的变化其实很大。 你不再是在一个对话里反复追问，而是在调度多个独立 worker。
比如一个很常见的场景：
我在处理一个线上异常时，可能会这样分：
这样做最大的好处，不只是“并行”，而是上下文更干净。 每个窗口只关心一类目标，模型不会被迫同时记住十件事。
很多人还把 AI 当问答工具。 但我越来越觉得，AI Coding 正在从“对话工具”变成“执行系统”。
你不是在问它问题。 你是在给它分工。
还有一个变化，我觉得很多人低估了：确认成本。
Claude Code 默认会频繁问你：
刚开始我也觉得这很合理，甚至觉得更安全。 但用久了我发现，这种频繁确认，对节奏的破坏其实非常明显。
你中间看一眼 Slack，回头一看，它停在那里等你点 yes。 你去处理个别的事，再回来，整个执行流已经断掉了。
后来我开始用：
claude --dangerously-skip-permissions
很多人一看到 dangerously 这个词，第一反应就是“不安全”。
这当然不是一个适合所有场景的默认选项，我也不建议在高风险环境里无脑开。
但它提醒了我一件更本质的事：
如果不愿意给执行权，AI 很多时候就只能停留在“高级 autocomplete”。 只有当它能持续执行、持续推进、持续把任务走完，它才开始更像一个真正能干活的 agent。
当然，这里一定有边界。 比如我更愿意在这些场景里这么用：
它不是“绝对安全”，但在合适边界里，带来的节奏提升是真实的。
我一开始用 Claude Code 的时候，其实很不适应 terminal。
总觉得 GUI 更直观，terminal 更像上一代工具。 但用了一段时间后，我反而越来越觉得：这个判断可能反了。
GUI 更适合人。 而 terminal，很多时候其实更适合 agent。
原因很简单：
你在 GUI 里做的很多事，本质上是在“操作界面”。 而在 terminal 里，你更像是在“调用系统能力”。
这也是为什么我现在越来越觉得，AI 工具的未来形态，未必是一个花里胡哨的 app。 它更可能越来越像一个系统层：可以调度、可以编排、可以拼接、可以持续执行。
换句话说，AI 工具不一定会更像“应用”。 它可能会更像“基础设施”。
过去一段时间，很多人都在聊 prompt engineering。 但我现在越来越觉得，在 AI Coding 这件事上，真正拉开差距的，已经不是谁更会写一句漂亮的 prompt。
真正的门槛开始变成：
这也是为什么，同样一个工具，有人用起来像是“偶尔帮点忙”，有人用起来却已经像是“多了几个可调度的工程执行单元”。
差别不在 AI 本身。 差别在你有没有从“使用工具”，切换到“设计 workflow”。
把这些变化串起来看，我觉得会得到一个更大的结论：
当然，这不代表代码不重要了。 也不代表工程能力突然不值钱了。 恰恰相反，工程能力会变得更重要，只是它体现的位置变了。
以前你最核心的价值，可能体现在：
现在越来越多时候，你的价值会体现在：
也就是说，程序员的核心能力没有消失。 它只是从“直接产出代码”，逐渐迁移到“任务建模与结果校验”。
这也是我最近越来越强烈的一个感受：
很多人还在讨论“AI 会不会替代程序员”。 但更现实的问题可能是：
这个时间点什么时候真正到来，我不知道。 但我越来越觉得，它可能比大多数人预期的更近。
你以为自己在用 AI 写代码。 但很多时候，你只是在把混乱的上下文、更长的 prompt、更多的确认弹窗，一层层堆给它。
真正的差距，不在你有没有用 AI。 而在你有没有开始把它当成一个需要被正确调度的执行系统。
从这个角度看，未来更重要的能力，可能不再只是“我会不会写代码”。
而是：
我会不会让 AI 在干净的上下文里，沿着清晰的边界，把事情真正做完。
更多深度内容与完整文章，欢迎关注我的微信公众号：SamLai 效率研习社
主要分享：
AI 编程与开发效率
技术趋势与工程思考
实用工具与工作流
