为什么我最后选择了「先讨论，再让 Agent 动手」

我今天不讲什么

不讲安装教程。不讲模型横评。不讲工具大全。

只讲一件事：我在真实工作里，试过几种方式之后，最后留下了什么。

问题意识从哪来

我不是天然就反对重工作流的。我用过 superpowers、openspec 这类工具，它们确实能帮你把任务结构化，让 Agent 按步骤走。

但在真实工作里，我撞上了一个问题：工作流一旦跑偏，成本非常高。

不是”多改几次”这么简单。偏一点可能影响接口设计、数据结构、上下游对接。而且这类工作流本身就会消耗大量 token。spec、plan、分步执行，每一步都在吃 token，再加上跑偏后的修正，消耗会翻倍。

问题不是工作流不高级，而是它们在真实工作里还没有很好解决跑偏的问题。

为什么我没有把重工作流当主方法

demo 里跑偏了，改一下就好。真实项目里跑偏了，后面一串东西都要跟着调。尤其是跨文件、跨模块的任务，偏航的影响会被放大。越复杂的工作流，偏航的概率和代价都更高。

重工作流本身的 token 消耗也是现实成本。对个人开发者来说，这是不得不算的账。

我现在的方法：先讨论，再执行

以前我的做法是：写好 prompt → 丢给 Agent → 看结果 → 修。

现在变成了：先和 Agent 讨论清楚 → 确认方向 → 再执行。

具体来说，动手之前我会先做四件事：

1. 先讲目标 —— 这次任务到底要达成什么？终点在哪？
2. 先讲边界 —— 什么要做，什么不要做，什么留给后面？
3. 先讲假设 —— 我默认了什么前提？这些前提靠不靠谱？
4. 再让 Agent 动手 —— 前面三个都聊清楚了，再开始写代码。

我现在越来越觉得，Agent 最重要的能力不是会不会写，而是动手之前能不能先对齐。

为什么”先讨论”不是慢，而是稳

表面上看，先讨论多花了几分钟，好像拖慢了节奏。

但实际体感是：多花 3 分钟对齐，少花 30 分钟返工。大部分返工不是模型能力不够，而是前面没对齐。尤其在跨文件、跨模块的任务里，这个差距会被放大。

真正贵的不是多聊几句，而是没聊明白就直接开干。

我怎么理解 Agent 的价值

Agent 对我来说不只是代码生成器。

1. 帮我澄清 —— 有时候我自己都没想清楚，和 Agent 讨论的过程中反而理清了思路。
2. 帮我拆解 —— 把一个大任务拆成可执行的步骤，这个过程本身就有价值。
3. 帮我执行 —— 对齐之后，Agent 的执行效率和准确度都会更高。
4. 前提是先对齐 —— 如果没有前面的讨论，Agent 就只是一个更快的打字机。

Agent 不只是替我写代码，而是一个需要先对齐、再协作的工作搭子。

为什么 Codex 更容易进入我的工作流

Claude Code 我有订阅，也实际用过。模型能力没问题。

但我撞上的真实问题是：额度太少。 一个大任务还没做完，额度就见底了。在真实工作里，做到一半断掉，这种体验很伤。不是模型不行，是撑不住完整任务。

Codex 对我更合适的原因很实际：有独立的 App，不需要额外折腾环境；能撑住一个完整任务，不用做到一半停下来。它更自然地进入了我的日常工作流。

工具好不好，不只是看能力上限，还要看它能不能撑住真实工作的连续性。

Codex 已经开始接管我的电脑

我越来越离不开 Codex，不是因为它只会写代码。它已经开始帮我处理很多系统问题——进程、端口、性能、链路排查这类事。

遇到问题时，我不是自己先一通乱查，而是先把现象和上下文讲清楚，再让 Codex 去排。它不是盲查，而是带着目标去查。

从系统排障开始，我慢慢发现它已经不只是代码助手。它能进入我的整个工作环境，操作我不熟悉的工具、处理我不想花时间学的流程。查进程、查端口、查链路、甚至直接操作 GUI 应用。

我越来越觉得：Codex 已经开始接管我的电脑了。

它从帮我查进程、排链路开始，慢慢进入了我的整个工作环境。到现在我越来越觉得，它已经开始接管我的电脑了。这个体感和”让 AI 写段代码”完全不一样。

我的结论

我越来越不相信”流程越完整越好”，我更相信”先讨论清楚，再让 Agent 动手”。

三个要点：

1. 我试过重工作流，但真实工作里跑偏成本太高
2. “先讨论再执行”不是慢，而是更稳
3. Codex 能撑住完整任务，更容易进入真实工作流

AI 编程最怕的不是不会写，而是还没对齐就直接开干。