我只是想问问，AI 怎么已经开始改代码了？
I only asked a question — why is AI editing my code?最近用 Claude Code、Codex 这类 coding agent 时，经常有一个很微妙的感受：
我只是想问问，它怎么已经准备动手了？
比如我问：
“这个功能是不是可以这样改？”
我的意思是：先帮我判断一下方向靠不靠谱，有没有坑。
但它可能已经开始读文件、找入口、准备修改。
我问：
“这个报错可能是什么原因？”
我的意思是：先解释一下，让我知道问题大概在哪。
但它可能已经开始改代码、跑命令、尝试修复。
这当然很厉害。
以前写代码，很多事情要自己查、自己试、自己改。现在一个 AI 可以进入项目，看上下文，读文件，甚至替你处理问题。
但厉害之外，也会有一点不安。
因为我还没决定要这么做。我还没确认方案。我还没判断风险。我甚至可能只是想先理解一下。
你以为自己还在想，它已经以为你在派任务。
01｜同一句话，在代码环境里会变味
这个问题不是简单的“AI 太急”。
更准确地说，是我和它对同一句话的理解不一样。
- 我以为自己在讨论。
- 它以为我在派任务。
普通聊天 AI 的默认动作是回答。
你问它一个问题，它解释、分析、给建议。
但 Claude Code、Codex 这类工具所在的环境，不是一张空白聊天框。
它面对的是代码库、文件系统、终端、测试、diff，以及一个可以被真实修改的项目。
所以，在这种环境里，很多句子会自动带上“任务委托”的味道。
你在聊天窗口里说：
“这里是不是可以优化？”
它可能会讲几个优化方向。
但你在代码环境里对 coding agent 说：
“这里是不是可以优化？”
它可能会开始找相关文件。
因为对它来说，“优化”不是一个抽象问题，而是一个可以被执行的任务。
同一句话，放在聊天框里是问题；放在代码环境里，可能就是任务。
02｜Coding agent 的默认目标，是推进任务
这不是批评它。
这是这类工具的产品定位。
Claude Code、Codex 最吸引人的地方，不是它能像聊天 AI 一样解释代码，而是它能真的处理开发任务：
- 读代码；
- 改文件；
- 跑测试；
- 修 bug；
- 生成 diff；
- 甚至帮你完成一个功能。
所以它的默认倾向会更偏行动。
普通聊天 AI 更像顾问。
你问它，它先说。
coding agent 更像已经站在工作台前的人。
你一开口，它会自然地判断：
这是不是一个可以开始处理的任务？
这也是为什么它有时显得很主动。
因为在它的产品语境里，“有帮助”不只是解释清楚，还包括把事情往前推。
但人的节奏不一定是这样。
很多时候，我们还停在判断阶段。
- 我想知道这个方案值不值得做。
- 我想知道这个问题是不是很严重。
- 我想知道有没有更简单的做法。
- 我想知道改了以后会不会牵连别的地方。
这些都还不是执行。
但 agent 可能已经把它理解成了执行前的指令。
于是错位就出现了。
人还在判断，AI 已经开始推进。
03｜真正让人不安的，是控制点被提前跳过
AI 有了工具权限以后，风险性质变了。
以前 AI 说错了，你最多不采纳。
它给你一个不靠谱的解释，你关掉就好。
它写了一段不好的文案，你删掉就好。
但 coding agent 不一样。
它可以读文件、改代码、运行命令、创建新文件，也可以根据报错继续尝试。
以前它说错了，我最多关掉窗口。
现在它可能已经改了三个文件。
这个差别比我一开始想的大。
问题不再只是：
它说得对不对？
还变成了：
它什么时候可以动手？它可以动哪些文件？它动手前要不要先说明计划？哪些决定必须由我确认？如果它走错方向，我怎么及时把它拉回来？
这也是为什么这种工具有时会让技术小白更紧张。
不是因为你不想让 AI 帮忙。
而是你不知道它一旦开始，会影响哪里。
- 你不知道它改了哪些文件。
- 不知道这个方案是不是过度设计。
- 不知道它是不是为了解一个小问题动了太大范围。
- 不知道它跑的命令有没有必要。
- 不知道它改完之后，你应该重点检查哪里。
真正让人不舒服的，不是 AI 行动能力太强，而是人的控制点被提前跳过了。
04｜工具自己也在提醒我们：先决定权限边界
很有意思的是，这件事其实已经被工具自己写进了界面里。
以 Claude Code 为例，它有几种不同的协作模式：
Ask permissions / default。Accept edits。Plan mode。Auto mode。Bypass permissions。
表面上看，这是功能设置。
但换个角度看，它其实在问你一个更本质的问题：
现在你到底允许 AI 做到哪一步？
- 如果你还不确定方向，只是想让它看懂问题，Ask permissions 或 default 会更稳。
- 如果你已经确认方向，只是让它做一些范围清楚的小改，Accept edits 更合适。
- 如果你只是想讨论、理解、比较方案，Plan mode 才是更接近“先别动手”的状态。
- 如果任务范围清楚、风险较低，可以考虑 Auto mode，让它连续处理。
- 至于 Bypass permissions，它不是“更高级”的日常模式，而是高风险放权。除非在隔离环境里，否则不应该随便用。
所以这些模式不只是操作选项。
它们其实在提醒我们：
和 coding agent 协作，第一步不是让它开始，而是先决定它有没有行动权限。
- 只是讨论，就不要给执行权限。
- 只是分析，就不要让它改文件。
- 只是计划，就先别让它动手。
- 等方向、范围、风险都确认了，再进入执行。
模式不是设置项，是授权边界。
05｜Codex 也类似，只是控制方式不同
Codex 和 Claude Code 的界面不完全一样，但底层定位类似。
它也不是普通聊天工具。
它可以读代码、改代码、运行命令，也可以在自己的工作环境里处理开发任务。
所以你同样需要区分：
- 我现在只是想理解；
- 还是想让它分析方案；
- 还是允许它开始修改；
- 还是让它在一个隔离环境里跑完任务。
在 Codex CLI 里，这更像是通过 sandbox 和 approval 来控制。
read-only 更接近“只读不写”。
workspace-write 适合已经确认范围的修改。
danger-full-access 就要非常谨慎。它不是普通模式，而是大范围放权。
在 Codex app 里，控制感更多来自 review。
- 你可以看 diff。
- 可以对具体行评论。
- 可以 stage、unstage 或 revert。
- 可以让它根据 review 再改。
不同工具的交互方式不一样，但它们都在处理同一个问题：
你不能只关心 AI 能不能做，还要关心它在什么权限下做、做到哪一步、由谁确认。
06｜和 agent 协作，第一句话不是“帮我做”
所以和 coding agent 协作时，我现在会先说清楚：
这一轮处在哪个阶段。
很多时候，问题不是 AI 不会做。
而是它不知道你现在是想让它理解、判断、计划，还是执行。
这几个阶段最好分开。
只是想理解：只解释，不修改
可以说：
“先不要改代码，只解释这个报错可能来自哪里。”
或者：
“只读代码，不要写入任何文件。先告诉我相关逻辑在哪几个文件里。”
还在比较方案：只分析，不执行
可以说：
“先给我 2–3 个方案和各自风险，不要开始实现。”
或者：
“先比较 A/B 两个方案，不要替我做决定。”
准备执行前：先列 plan，等确认
可以说：
“先列 plan，说明会改哪些文件、为什么改，等我确认后再执行。”
或者：
“改动前先告诉我影响范围和回滚方式。”
已经确认执行：限定范围，再动手
可以说：
“按这个 plan 执行。只改你刚才列出的文件。改完后告诉我具体 diff、测试结果，以及有没有你不确定的地方。”
这些话看起来有点啰嗦。
但它们不是废话。
它们是在告诉 agent：
现在只是理解。现在只是比较。现在只是计划。现在才是执行。
和 agent 协作，不只要说清任务，还要说清阶段。
最后｜以前要把问题问清楚，现在还要把授权边界说清楚
如果阶段不说清楚，agent 很容易把“讨论”理解成“任务委托”。
而一旦它进入执行，后面就会变成你追着它看：
- 它刚才做了什么？
- 为什么改这里？
- 有没有动到不该动的地方？
- 这个方案是不是我真的想要的？
这不是最好的协作状态。
好的状态应该是：
AI 可以很强，但节奏仍然由人控制。
以前我们说会用 AI，很多时候是在说会不会提问。
- 问题说清楚一点。
- 背景给完整一点。
- 限制条件写具体一点。
- 让它输出格式稳定一点。
这些当然还重要。
但当 AI 从聊天助手变成执行型 agent，问题就多了一层。
你不只是要告诉它“我要什么”。
你还要告诉它：
现在还不能做什么。
- 不要改代码。
- 不要写入文件。
- 不要直接选方案。
- 不要为了修一个 bug 重构整个项目。
- 不要在我确认前执行。
- 不要把讨论当成授权。
一个只会回答问题的工具，边界可以松一点。
一个会改项目、跑命令、生成真实结果的工具，边界必须更清楚。
因为很多 AI agent 的问题，不是它不够聪明。
而是它太快把你的模糊想法，当成了一个可以开始执行的任务。
以前用 AI，重点是把问题问清楚。
现在用 agent，还要把授权边界说清楚。
你要让它知道：
- 这句话只是讨论。
- 这句话只是判断。
- 这句话只是计划。
- 这句话才是可以动手。
否则，你以为自己还在想，它已经开始做了。