昨天同事在用 Codex 写一个新模块。从上午到中午，提示词改了好几轮，代码生成了一版又一版，结果始终不是他想要的。
"算了，我还是自己写吧。"
我问他："要不先别急，你跟我说说这个模块要干嘛？"
问题出在哪
聊完发现问题其实挺简单：他没把需求想清楚，就开始让 AI 写代码了。
很多人用 AI 是这样一个循环：有个模糊想法 → 直接丢给 AI → 看生成结果 → 不满意改提示词 → 再来一轮。几轮之后人就开始烦躁，最后得出一个结论："AI 不行。"
但很多时候问题不是 AI，是需求本身模糊。
AI 和人的区别在这
人写代码的时候，能容忍很多模糊信息。因为你会自动补全上下文------结合项目背景、参考已有代码、凭经验推断逻辑。
AI 不一样。它是严格依赖你给的信息的。
如果输入是不完整的、没结构的、想到哪说到哪的，它只能自己补。
而 AI 补出来的东西，往往是行业通用方案、常见架构模式------它训练数据里最多的那些。
所以会出现一个现象：AI 写的代码"看起来很合理"，但就是不符合你的需求。
不是 AI 写错了，是你没告诉它真正的需求。
我让他先别写代码
聊清楚之后，我让他暂停和 AI 对话，先做一件事：驱动AI把需求结构化。
我们一起花了大概二十分钟，把整个模块拆开：
- 这个模块解决什么问题？
- 在系统里处于什么位置？
- 输入输出是什么？
- 需要遵守什么规则？
一点一点驱动AI生成完整的需求文档，很多人会觉得这一步"很慢"，但磨刀不误砍柴工。
不要急着让 AI 写代码
然后我建议他：先让 AI 帮你写"大纲"，而不是代码。
提示词大概是这样：根据现有代码结构和需求概览，生成模块设计大纲。
AI 很擅长做这件事，本质上是结构化信息生成。
很快我们就得到一个模块结构：模块职责、核心流程、子模块划分、数据结构、异常处理策略。相当于 AI 帮你写了份设计文档。
接下来就很舒服了：完善需求。
我们开始逐个确认：这个流程对不对？这个数据结构合理吗？这里需要权限控制吗？是否要兼容旧逻辑？
每一轮讨论，AI 都在帮忙补充细节。它的角色也变了------从代码生成器变成架构辅助工具。
等到逻辑、结构、边界条件都确认得差不多了，才进入最后一步。
再让 AI 写代码
这时候提示词完全不一样了。不再是"帮我写一个 XXX 模块"，而是"根据以下设计实现代码"，然后把完整上下文贴进去------需求概览、模块设计、数据结构、规则约束。
AI 的表现立刻就变了。代码结构清晰，基本一次成型。
下午下班前同事跑来说："新的模块一遍就跑通了。"
其实不是 AI 突然变强了。是我们换了一种方式使用它。
这件事印证了一个判断
AI 的输出质量，本质上取决于两件事：
一是需求是否准确。如果需求模糊，AI 一定会"自由发挥"，每一版结果都只是它在猜你的想法。
二是上下文是否完整。AI 不是全知的，只能基于你提供的信息推理。信息越完整，输出越稳定。
现在很多人对 AI 有一种不现实的期待：希望通过几句简单提示词，让 AI 直接生成自己脑子里的东西。
但你脑子里的东西，没有表达出来。AI 不会读心，你不说它就不知道，只能按通用规则、行业惯例、最常见架构去生成。
结果就是你觉得 AI 不懂你。
实际是你没告诉 AI 你要什么。
现在的OpenSpec、Speckit等本质上解决的也是这个问题，消除人与AI之间的"沟通歧义"，把输入做精确。
AI 时代的能力变化
很多人以为 AI 时代最重要的是会写提示词、会用工具、会调模型，只要模型够强，就能省去'把事情想清楚'这个最累的环节，试图用工具的算力来掩盖思维的懒惰。
但 AI 不会惯着你，它会用错误的结果，诚实地反馈出你逻辑上的缺陷。
AI执行能力很强，但需要你给它方向。
这就意味着，我们赖以生存的核心竞争力正在发生迁移------
从"如何实现（How）"的执行能力，转向"要做什么（What）"的定义能力。