每次向 ChatGPT 或 Claude 发出请求，其实同时做了三个决定：在哪里问、让哪个模型回答、让它花多少推理。开发者习惯争论第二个，几乎不看第一个。但多数让人失望的回答，来自问错了地方；多数被浪费的钱，来自另外两个选择。

打开网易新闻 查看精彩图片

先选地方，再选模型。这个顺序反了，后面怎么调都补不回来。

六个任务，六个地方

边界是软的。一次对话可以写完整个模块，一个编码智能体也能回答一个问题。真正决定去哪儿的，是这件事在哪里最容易被检查。

一个改动涉及九个文件的重构，在能跑测试的地方检查成本很低，在聊天窗口里靠肉眼核对则很贵。反过来，一个随口就能判断对错的问题，没必要搬进仓库。

一次只改一个变量

地方选对了，就从中间档模型、默认推理强度起步。之后每改一项，都要能说出理由：

  • 回答漏掉了你给过的东西，比如埋在长文件里的某条约束，或者两个互相影响的事实。这时提高推理强度，或者升一档模型。
  • 回答错了，是因为缺信息，比如出 bug 的那个文件根本没给它。换任何模型都救不了，把信息补上。
  • 任务是例行公事：重命名、改格式、做摘要。降低推理强度或降一档模型，等得更短，额度也省。

更强的模型，猜得更像真的

这里有个陷阱，正是上面第二条规则要防的。助手对一个搜索功能如何构造查询给出了错误回答。第一反应是换成最大的模型。但如果没人把构造查询的那个文件附上，助手就是在猜——更强的模型只会猜得更令人信服，而不是更正确。

把证据补上，重新问一次，到这一步再考虑加推理。

一个常见的混淆

以为 ChatGPT 或 Claude 的订阅能覆盖自己程序发起的 API 调用。应用由订阅覆盖，API 单独按 token 计费，走的是 API 账户。两者挂着同一个品牌名，团队因此经常搞混。

对团队来说，什么会变

在团队争论哪个模型更好之前，值得先问一句：AI 的工作发生在哪里。每周一粘贴进新对话的重复提示词、从聊天窗口复制出来却从没运行过的仓库改动、一个调用聊天产品而不是 API 的脚本——每一个都是位置问题，没有哪次模型升级能解决。

顺序是：先修地方，再调模型，最后调推理强度。