我让 AI 编程，它却给了我一个复杂方案——问题出在我的提问方式上

昨天用 Claude Code 时踩了个坑，事后复盘才发现，问题不在 AI，而在我给它加的“限制”上。

事情很简单：我让它实现一个功能，顺手加了几句限制条件。心里想着这样能更精准地控制输出，结果它给了我一套复杂的方案。我当时觉得奇怪——这明明是个简单需求，怎么搞得这么绕？

后来一问才发现，那个复杂的方案，恰恰是因为我的限制条件导致的。而它默认了我的指令是深思熟虑的，二话不说就照做了，完全没有提醒我“老板，你这个限制会让事情变复杂”。

这个经历让我重新审视了和 AI 编程工具的协作方式。

Agent 只会执行指令，不会质疑指令

这是 Claude Code、Cursor 这类 AI 编程工具的一个核心特点：它们是被设计来“完成任务”的，而不是“挑战需求”的。

你告诉它“必须用递归”，它就用递归。即使那个场景下递归会导致栈溢出、可读性极差，它也不会主动跳出来说：“这个需求用循环更合适。”

就像一个极其听话的初级程序员——你让他绕远路，他二话不说就绕。不是他笨，是他默认你的指令是深思熟虑过的。

这对使用者的要求其实更高了。 你需要清楚地表达意图，还要预判你的表达方式会不会把 Agent 引向歧途。

从“下命令”转变为“对齐目标”

想明白这点后，我总结了几条实用原则。

1. 主动要求它“说出你的理解”

下达复杂指令后，加一句：

“在执行前，先复述一遍你对我的要求和限制的理解，并评估这些限制是否会增加不必要的复杂度。”

这能让 Agent 在动手前先和你“对焦”。如果它理解了限制但预见到会导致复杂方案，就会提前告诉你。

2. 把限制变成“权衡”而非“死命令”

试试把表述方式从“必须如何”改成“我想要什么，但可以讨论”。

· ❌ 死命令：“必须用递归实现，不能写循环。”
· ✅ 解释目标：“我想学习递归思维，请用递归实现。但如果你发现递归会导致代码难以理解或有栈溢出风险，请指出并推荐更合适的方案。”

这样 Agent 会优先实现递归，但遇到问题时，会像同事一样提醒你：“老板，递归在这里会让内存暴增，换成循环更稳，你看行吗？”

3. 多用“为什么”来追问

当得到一个复杂方案时，养成追问的习惯：

“这个方案好像挺复杂，是不是因为我的某个要求导致的？有没有更简洁的替代方案？”

这个简单的提问可以直接点破那层窗户纸。Agent 会回溯你的限制条件，分析哪些是“复杂度元凶”。

4. 在项目里放一个 CLAUDE.md

Claude Code 支持在项目根目录放置 CLAUDE.md 文件，作为长期生效的协作指南。这是我的文件内容：

```markdown
# 项目协作原则
- 简洁优先：如果我的某个限制导致方案明显变复杂，请立即指出并建议替代方案。
- 解释决策：给出方案时，简要说明为什么这么做。
- 遇到歧义先提问，别猜。
```

每次启动时它都会读取这份“协作风格指南”，从根源上减少类似问题。

5. 分步验证，别一步到位

对于关键任务，让 Agent 先做计划而非直接执行：

“先别写代码，列出实现步骤，并标出哪一步是因为我的XX限制而额外增加的。”

这样你就能在代码产出前，直观地看到限制带来的成本，随时叫停或修改。

总结

这次经历让我意识到，AI 编程工具的本质是推理-行动循环系统——它忠实执行指令，不会主动质疑指令的合理性。这既是它的能力边界，也是我们需要适应的协作模式。

用好它的关键，不是写出更精确的指令，而是建立一种允许它“温和质疑”的对话机制。下次遇到类似情况，试试这句关键咒语：

“在执行前，先评估这些限制是否会带来不必要的复杂度。”

省下的时间，可能比你想象的多。