给AI一句帮我加个分页接口它给你100行代码。编译能过跑起来没报错。但你一看——ORM框架用了JPA你们项目是MyBatis分页参数用了page/size团队约定是offset/limit缓存逻辑完全没写而这个接口QPS至少2000。你觉得是需求没说清楚于是重新组织语言。第二版Prompt从一句话扩写成三段话把约束条件一条条加上用MyBatis、offset/limit分页、加Redis缓存、缓存key的格式是XXX。AI这次好了一些但缓存过期策略没写对分页边界值也没处理。第三轮你更详细了把过期策略和边界处理也加上。AI终于输出了一份能用的代码。你算了一下时间——来回三轮比自己直接写还慢。这种事发生得多了我就开始复盘每次的迭代。我发现一个规律每一轮优化都在补上一轮的窟窿但总会暴露一个新的、我没提前想到的坑。第一轮没说用什么框架第二轮没说过期策略第三轮没说并发情况下的缓存一致性。我不是在优化需求我是在打地鼠——冒出来一个打一个。有一天我突然想明白了一件事我不是需求没说清楚我是需求没想清楚。每轮Prompt补充的内容都是我在写Prompt的那一刻才想明白的——写第一轮的时候我脑子里根本没有缓存过期策略这个概念它是我看到AI的错误输出之后才想起来的。换句话说我在用语言去补思考的窟窿。Prompt写得越长不是需求越清晰是我思考的漏洞越多。打个比方你跟装修队说我要简约风跟签了字的图纸不是一回事你找装修队翻新卫生间跟工长说我要简约风格瓷砖要浅色的洗手台要大一点的。工长点点头回去开工了。做完你一看——瓷砖确实是浅色的但是两种不同的浅色拼在一起洗手台确实大了但大到挡住了门。你投诉工长说你当时没说要同色系的啊你也没说门要能完全打开啊。你说得对吗对。工长理解得对吗也对。问题是口头描述和图纸是两种完全不同的东西——口头描述天然有歧义图纸用尺寸和标注消除了歧义。你可能会反驳那我说得更仔细不就行了不行。因为口头描述的仔细和图纸的准确是两码事。你可以用100句话描述卫生间要长什么样但只要你没说到插座离淋浴区至少60厘米工长就可能把插座装在淋浴旁边。而图纸会标注每一个插座的位置和距离——它不依赖你有没有想到。Prompt就是口头描述Spec就是图纸。不管你把Prompt写得多长它始终是一种我想到什么说什么的表达方式而不是一种系统性地覆盖所有细节的结构化文档。这就是为什么Prompt越写越长但AI还是翻车——你不是在写图纸你只是在用更多的嘴说更多的话。为什么不继续优化Prompt因为瓶颈不在怎么说Prompt Engineering这个词暗示了一个前提存在一种更好的说法能让AI输出正确的结果。这个前提在简单场景下成立——帮我加个分页接口改成用MyBatis帮我加个分页接口offset/limit格式效果确实好了。但到了复杂场景这个前提就站不住了。原因是Prompt解决的是怎么说的问题但翻车的根本原因是你没想清楚要什么。你可以说得越来越精确但精确的前提是你得先想到。你想不到的东西不可能说出来。我有一次让AI优化一个接口的性能花了两轮Prompt把约束条件说得很细目标QPS、当前瓶颈、允许引入的新依赖、不允许动的模块。AI给了方案跑了一下性能确实提上去了。但上线前review发现新方案在并发场景下有数据不一致的风险——这个风险我在写Prompt的时候完全没想到。这不是AI的问题是我的问题。我在怎么说这件事上做到了极致但在想清楚要什么这件事上做得不够。并发一致性是我应该提前想到但没有想到的——它不是Prompt的问题是思考的问题。后来我做了一个尝试同一样的需求不优化Prompt而是先花10分钟写一份结构化的需求文档——这个接口要解决什么问题、涉及哪些模块、有哪些约束、怎么验证做对了。写完之后再让AI按这份文档来结果一次过。不是AI变聪明了是我在写文档的过程中把问题想清楚了——包括并发一致性的问题。写文档逼着我把每个维度都想一遍而写Prompt不会。因为文档是结构化的它天然有一套框架引导你思考Prompt是线性的它只引导你表达。不是所有需求都值得写文档但想清楚是必须的我不是在说所有需求都要写一份文档——那太重了。关键是想清楚的深度要和需求的复杂度匹配。我的做法是按复杂度分四档确定性高、影响面小的需求——不用写任何东西直接跟AI说就行。一个简单CRUD自己写也就10分钟的事没必要花时间写文档。有一定逻辑、需要联调的需求——写一个Mini-Spec。只记核心要点和验收标准5到10分钟能省下后面20到30分钟的返工。涉及多模块协作、有复杂业务规则的需求——走完整的规格流程。先分析关联代码每个结论附上文件路径再出方案。这一步遏制了AI幻觉式瞎编的毛病因为每个决策都有上下文依据。连需求方自己都说不清的探索性需求——先写一份问题清单把待澄清的疑问结构化地列出来。疑问不清零不开始编码。这条规矩看着死板但它防止了一个最常见的恶性循环边写代码边改需求改完需求又得改代码改完代码发现需求还得调。先想清楚再动手前期多花的10分钟省的是后面反复纠偏的半小时。还有一件事值得做在项目里维护两份东西——一份是怎么写的编码规范Rules一份是为什么这么写的决策记录Knowledge。Rules告诉AI必须用什么框架、不能碰哪些模块Knowledge告诉它为什么某个表不做物理分片、为什么某个服务要单独部署。前者是行为约束后者是决策依据。大部分团队花大量精力写Rules但效果依然不佳根本原因是只给了AI行为约束没给它决策依据。不过有一点要注意别过度。一个简单的配置改动不需要启动完整的规格流程。杀鸡用牛刀只会浪费时间。这套方法解决的是AI编码缺乏系统性的问题不是所有场景都需要系统化。回到最初的问题Prompt越写越长AI还是乱写因为问题根本不在Prompt。Prompt解决的是表达问题而AI翻车的根因是思考问题。你在Prompt里补的每一句话都是你写Prompt那一刻才想到的——说明你之前根本没想过这件事。这引出一个更通用的规律不管你用什么工具、什么模型、什么技巧来让AI写代码瓶颈永远在你想清楚了没有不在你说清楚了没有。把AI换成任何一个新人结论是一样的——你没想清楚的需求新人也没法做对区别只是新人会跑过来问你而AI不会。从下一个中等复杂度的需求开始试着在动手之前先把核心要点和验收标准写下来。不用很正式几行字就够。看看AI生成的代码是不是真的更贴近你的意图。坚持三五次你会感受到一种久违的掌控感——不是被AI牵着走而是你在驾驭它。