mosa@SilentMalachite

深度用了Claude Code 和 Codex，我发现一个比模型能力更残酷的事实：AI 编程最大的差距，可能已经不是模型，而是使用模型的人。前两条推文，我聊了两个问题：第一条：为什么用了一个月 Opus 5.5，我最后还是离不开 GPT-6 Sol 和 Astra。第二条：为什么 AI 越来越聪明，我反而越来越不敢完全放手让它干活。今天想继续聊第三个发现。同样是顶级模型，为什么有时候别人一句话就能搞定的任务，我却要折腾半天？以前我总觉得是模型不够聪明。后来发现，问题有时候出在我自己交代任务的方式上。主要有三个原因。 1. 我们经常高估 AI 对整个项目的理解。比如让 Opus 5.5 或 Sol 修改一个后端功能。以前我可能直接说： “把这个功能改一下，其他地方不要动。” 听起来很清楚吧？但问题是，AI 未必知道哪些地方属于“其他地方”。一个功能可能关联数据库、权限、接口、业务状态甚至前端展示。你只告诉它要改什么，却没告诉它哪些东西绝对不能破坏。模型只能根据自己看到的上下文去推断。很多时候，不是 AI 没有执行你的要求，而是你的要求根本没有定义清楚。 2. 任务越复杂，我反而越不愿意让 AI 一口气做完。 Claude Code 最大的优势之一，就是执行起来特别丝滑。但这也容易让我犯一个错误：把一整个复杂需求丢过去，然后等它告诉我完成了。结果最后检查，发现某个关键业务逻辑遗漏了。现在我更倾向于分阶段处理：第一步，让模型先理解现有项目和业务约束。第二步，让它给出修改方案，明确涉及哪些文件和模块。第三步，再开始写代码。第四步，运行测试，检查有没有破坏原来的功能。遇到特别复杂的任务，我还会让它先完成最关键的部分，而不是一次性修改几十个文件。我现在宁愿 AI 动手之前多花一点时间，也不想它动手之后让我花几个小时返工。 3. 真正拉开效率差距的，是有没有明确的验收标准。这是我改变最大的一点。以前让 AI 写代码，只要它说任务完成，我就开始检查哪里不对。现在我会提前告诉它：什么结果才算成功？哪些原有功能必须保持不变？需要运行哪些测试？如果测试失败，应该怎么处理？甚至要求它最后明确告诉我：哪些问题已经验证，哪些只是推测，哪些还没测试。因为我发现：没有验收标准的 AI 编程，本质上就是让一个能力很强、但可能犯错的程序员自己给自己打分。这也是我现在使用 Opus 5.5、Sol 和 Astra 的最大变化。不再一味追求哪个模型最快、哪个模型跑分最高。而是先把需求交代清楚，把修改范围控制住，把验收标准定下来。最后再根据任务难度选择合适的模型。当然，这不代表提示词写得好就能解决所有问题。模型自身能力、代码质量和测试覆盖率，依然很重要。但至少不会因为自己没交代清楚，就让 AI 在错误方向上反复折腾。用了一个多月，我现在越来越相信一个判断：未来 AI 编程真正有竞争力的人，未必是最会写代码的人，也未必是最会写提示词的人。而是那些能把复杂问题拆清楚、把业务约束讲明白、把最终结果验收好的人。 AI 负责提高执行速度。人负责定义什么才叫做对。最后问大家一个问题：你们现在用 Claude Code 和 Codex，是一句话让它直接开干，还是先让它分析需求、制定方案，再开始修改？