为什么你的AI提示词总是"差一点"|上下文|代码|差一点|显式标识

周三下午，一个开发者在GitHub上删掉了刚生成的300行代码。不是AI写得不好，而是这300行代码和他三天前写的模块功能重复了，只是变量名不同。他花了两小时调试，最后发现AI根本没"错"——它只是不知道这个项目里已经有个差不多的东西了。

这不是个例。越来越多人发现，AI工具越来越强，但拿到想要的结果反而更难了。不是提示词写得不够长，不是模型选得不够好，真正的问题在按下回车之前就已经存在了。

提示词陷阱：越改越偏的循环

大多数人的AI使用流程是这样的：写一句指令，看输出，发现缺东西，加细节重写，再生成，再修，再补。几个小时后，结果"差不多对了"，但和最初想的不完全一样。

这时候很容易怪AI不稳定，或者去网上搜"完美提示词模板"。但软件工程和人机交互领域的研究早就指出一个事实：模糊的需求是系统输出失败的最大原因之一。AI只是把这个老问题放大了——它完全依赖你给的指令，需求本身有漏洞，结果必然带洞。

在软件开发里这更明显。AI能秒写React组件、API、数据库表结构，但项目一大，麻烦就来了：架构风格不一致、逻辑重复、业务规则模糊、实现互相冲突、功能能跑但和整体系统不搭。AI没在"随机出错"，它在被迫猜测你没说的上下文。猜得越多，结果越飘。

转向：先结构化，再提示

意识到这点后，作者停止了"写更长提示词"的尝试，转而在提示之前就建立清晰的规格说明。不再把AI当聊天机器人，而是当作需要结构化上下文才能有效协作的搭档。

这个思路最终催生了MySpec。它的目标不是替代Cursor或Claude Code这类AI工具，而是帮它们获得真正需要的信息，从而持续产出更好结果。MySpec把项目信息整理进四个核心文件，取代零散混乱的提示词。

第一个叫Constitution（章程）文件，定义项目的长期规则和原则：代码规范、架构边界、设计哲学。第二个是Context（上下文）文件，记录当前状态和近期决策，让AI知道"我们现在在哪"。第三个是Requirements（需求）文件，明确具体要做什么、验收标准是什么。第四个是Tasks（任务）文件，拆解执行步骤，追踪进度。

这套结构的核心逻辑是：AI的表现取决于它接收到的上下文质量。上下文混乱，再精妙的提示词也救不了。

从"对话"到"协作"

MySpec的设计反映了一个更深层的转变。早期用AI像打电话——你说一句，它回一句，来回调整。现在更像项目管理：先把背景、规则、目标写清楚，再让AI进场执行。

这种转变在复杂项目里收益明显。当AI知道整个系统的架构约束，它就不会在角落偷偷发明新约定；当它能看到需求文件里的验收标准，输出就会主动对齐；当任务被拆解成可追踪的步骤，迭代方向也更清晰。

作者提到，用了这套方法后，"第一次提示就拿到可用结果"的比例大幅上升。不是AI变聪明了，是上下文变完整了，需要猜测的空间变小了。

工具之外的启示

MySpec的具体实现是一回事，但它指向的问题更普遍：我们和AI的交互界面还在早期。提示词工程（prompt engineering）这个词本身就有误导性——它暗示问题在"怎么问"，而实际上问题经常在"问之前准备了什么"。

软件开发领域有个老概念叫"需求工程"，强调在编码前把需求搞清、搞稳、搞一致。AI时代，这个老概念反而更关键了。因为AI写代码的速度太快，需求里的模糊点来不及在讨论中被发现，直接变成了技术债。

另一个值得注意的趋势是"上下文窗口"的军备竞赛。各大模型都在推更长的上下文长度，从4K token到128K、200K甚至更多。但长度不等于质量。把10万字的混乱文档塞给AI，不如给它5000字精心结构化的关键信息。MySpec的四文件结构，本质上是在做这种"关键信息提取"的工作。

谁需要关心这个

如果你用AI写点邮件、改改文案，提示词循环的代价不高，可能没必要上工具。但如果你在做：持续数周的软件开发项目、需要多人协作的AI辅助工作、对一致性要求高的技术文档或代码生成——那么"提示前的结构化"就值得投入。

MySpec目前是一个个人项目，作者开源了思路和部分实现。类似的方向其实不少：一些团队在Notion里维护项目知识库再喂给AI，有人用专门的AI项目管理工具，还有公司自建内部规范文档系统。核心都是同一件事：别让AI猜，先把上下文喂饱。