#思考预算

15小时前

你仍然需要思考随着编码智能体（coding agents）的能力越来越强、运行时间越来越长，这并不意味着人类“思考”的工作就被取代了。总得有人来负责指挥这些工作——设定目标、选择约束条件，并对输出结果作出判断。大家在抽象层面上似乎都认可这一点，但几乎没有人真正讨论过一个事实：产品形态的不同，实际上会从根本上改变“写代码”时所需的思考方式。 💭 不同产品形态对“思考预算”的影响我认为，不同编码智能体之间看似细微的 UX（用户体验）差异，实际上对用户“思考预算”的分配方式有着巨大的影响。远程型产品（如 Codex Cloud，而非 CLI）：这种产品鼓励你不要在智能体工作时花太多精力思考，而是更多地在最后拿到结果后再思考。我们甚至刻意不让用户看到智能体调用终端命令的过程，因为模型的工作方式和人类有本质区别。交互式产品（如 Claude Code 或 Codex CLI）：在这种产品里，你会花更多时间去思考规范和智能体采取的高层方案，因为你可以在终端中“跟随”它的思路。不过，你需要在其他地方（如编辑器或 GitHub）查看代码差异，因此工作流程更多是在跟进智能体的计划并验证执行过程。 IDE 集成型产品（如 Cursor）：你会快速地接受或拒绝智能体给出的代码改动。因为上下文已经在编辑器中，所以你无需花太多心思去提供上下文信息，但这意味着你可能需要提前花时间把问题拆解好，在最开始就想清楚计划和方案。 🧠 “思考预算”的四个主要环节所有这些产品都需要在以下四个环节之间重新分配“主动思考”的时间：提供正确的上下文制定计划实现代码验证和审查就目前 LLM 的能力而言，我的判断是： 👉 实现（3） > 验证（4） > 规划（2） > 提供上下文（1）也就是说，“提供上下文”仍然是人类价值最大的地方。在我们拥有更好的组织内搜索工具、用户信息提取工具、全局上下文理解能力之前，这一点都不会改变。另一方面，LLM 在接收清晰的计划并实现它时表现非常出色。它们能很好地处理竞态条件、错误处理以及复杂的技术细节。 🔍 不同问题 & 不同思考方式如果你接受“思考预算”这个概念，就不难理解为什么工程师在使用不同工具时的体验差异会如此巨大：有些问题只需要一个清晰的规范——你已经完全知道实现的样子。有些问题需要通过写代码来“思考”问题本身，然后再进行重构。有些工程师更喜欢先看一版初稿再进行审查，而不是从零开始写。不论你偏好哪种方式，不同的产品体验都要求你用不同的方式来思考。我认为不太可能出现一种“单一工作流程”就能满足所有用户的需求。你依然需要思考……但最好的产品，会让用户自己选择他们想要“如何思考”。

#编码智能体 #思考预算 #产品形态 #用户体验 #代码实现