先规格后代码

直接要代码，你要读四百行才能发现它理解错了。先要一页规格，同样的错误在二十行里三十秒就能看出来。

在让 AI 写代码之前，先让它用自然语言写出打算做什么：数据结构、页面上有哪些状态、边界情况怎么处理、哪些地方它自己拿不准。你看这一页，改几条，再让它动手。

这个动作看起来是多了一步，实际上省的是最贵的那一步。AI 写代码几乎不花你的时间，但读代码、发现它理解错了、然后描述该怎么改——这三件事全部消耗你的注意力，而且随代码量线性增长。规格只有二十行，你三十秒能扫完，错误在这里被抓住的成本几乎为零。

更重要的是，规格会逼出那些你自己也没想清楚的问题。做一个评论区这句话里藏着七八个决定：要不要楼中楼、能不能编辑、删除是软删除还是硬删、未登录用户看得见吗。你不说，AI 就替你决定了，而且它多半会选最常见的那个做法，未必是你要的那个。

「与 AI 协作」里的其他模式——三段式提示、参考锚定、约束沉淀——都要先有这个习惯才用得上。

规格里的四块

四块缺一不可，其中最值钱的是最后一块。

设计考量

• 明确说先不要写代码，否则它会顺手写完。 模型的默认倾向是给出完整可运行的东西。不加这句限制，你会拿到一份规格加四百行代码，等于没省。这句话要放在提示的开头和结尾各一次。
• 要求它单独列出拿不准的地方。 这是整个模式里最值钱的一栏。它会暴露你需求里的空洞，而这些空洞如果不在这里补，就会变成它自己猜的一个答案藏进代码里，通常要到测试时才发现。
• 规格控制在一屏以内。 超过一屏你就不会认真读了，那这一步就白做。规格太长通常说明任务太大，该拆（见「一次一件」）。二十到三十行是舒服的长度。
• 确认过的规格要留在上下文里，别只留在脑子里。 把定稿的规格写进项目里的一个 markdown 文件，后续每次让它改这个模块时都带上。否则改到第三轮它就会忘掉第一轮的约定，你得重新解释一遍。
• 改规格，别改代码。 发现输出不对时，第一反应应该是回去补规格里缺的那条，而不是直接说把这里改成什么样。前者能顺带修掉你还没发现的同类问题，后者只修掉这一处。
• 规格只写做什么和为什么，别写怎么实现。 指定用哪个库、怎么拆函数属于过度约束，会让 AI 放弃它更熟悉的写法。你负责判断，它负责实现，边界清楚了双方都省事。

给 AI 的话

这段可以固定成你每次开新模块的第一句话。

我要做：[一句话描述功能]

先不要写任何代码。先给我一份不超过 30 行的规格，包含四部分：

1. 数据：涉及哪些实体、关键字段、彼此的关系。
2. 状态：这个界面会出现哪几种样子，各自什么条件下出现。
   至少覆盖正常、空、加载中、出错。
3. 边界：你能想到的异常情况和你打算怎么处理
   （超长内容、零条数据、权限不足、并发修改、网络失败）。
4. 未定项：我没说清楚、你只能靠猜的地方，逐条列出来问我。
   不要自己替我决定。

用中文，列表形式，不要展开解释。我确认之后再动手写代码。

确认完之后，第二句：

规格按以下修改后定稿：
- [你的修改 1]
- [你的修改 2]
- 未定项的答复：[逐条回答]

请把定稿的规格写入 docs/specs/[模块名].md，然后按它实现。
之后我对这个模块提的任何修改，都要先同步更新那份规格文件。

相关模式

真实案例