只有一个模糊想法，怎样写成 AI 能执行的需求？
用五个维度把想法变成有边界、能验收的 SPEC，并通过逐步提问补齐歧义。
本页目录
直接回答
先说清用户要完成什么，再描述产品怎样帮助他。一份便于执行的 SPEC 可以包含五个部分：问题陈述、方案描述、技术约束、明确不做的事、成功标准。它用来让人与 AI 对同一个结果形成共同理解，不是堆满专业术语。第一份可以很短，但每句关键要求都应能解释、实现和检查。AI 可以帮助拆解和追问，真实需求、预算与取舍仍由人判断。尚未确认的信息应单列为问题，不让看似合理的猜测悄悄变成既定要求。
适用场景
- 想法只有一句话，AI 每次生成的东西都不同
- 项目越做越大，双方对完成标准有分歧
- 需要把口头讨论交给另一个开发者或 Agent
一步一步做
写清一个人和一个场景
用“谁在什么时刻，想完成什么，现在怎样做，哪里最麻烦”描述问题。不要从“我要一个 AI 平台”开始。记录已有观察与自己的猜测，尚未接触用户就写“待验证”，避免把需求文档写成市场已被证明的结论。
画出最短操作过程
从进入页面到拿到结果，逐步写出输入、操作、系统处理和输出。例如粘贴一句话→点击翻译→看到具体行动与待追问信息→复制回复。遇到登录、上传或收费，说明为什么这个步骤必须出现在这里。
让 AI 每次追问一个关键维度
先让 AI 检查用户与问题，再检查方案、限制、范围和验收。要求给出容易比较的选项及影响，答完再继续。优先解决会改变产品方向的歧义，字体和间距等低风险细节可以采用默认值。
写出限制与明确不做的事
列出已有代码、运行平台、可用 API、数据保存方式与成本约束。非目标要具体，例如首版不做团队协作、不保存聊天记录。安全和必要错误处理不能因首版而省略；如果条件冲突，应先改要求。
把成功改写成可观察结果
“体验很好”无法验收；可以改成“首次使用者无需说明就能提交内容并复制结果，空输入有明确提示，失败不会显示成功”。技术验收与市场验证分开：功能正常并不能证明有人愿意长期使用或付费。
把互相冲突的承诺改成可验证选择
把每句“任意、立刻、一定、永远”圈出来，找到支撑它的测试。假设某个游戏同时规定最低分为 -50，又规定低于 -50 才失败，这两个条件就需要先统一；试衣功能若排除多人或遮挡照片，就不能承诺接受任意照片。先选择明确规则，再写输入校验、失败提示和验收；技术栈、GameContext 等从其他项目继承的字段也要逐项删除或确认。未知能力写成待验证假设，不能靠文案把它变成已实现功能。
案例拆解
假设练习：把解释工具与试衣原型写成需求
一个表达解释工具可以约定五类输出：具体的人话解释、可能的意图、需要追问的信息、不同语气的回复、词汇知识卡片。首版限定一种语言，避免用另一套黑话替换用户输入，也不评价用户的雇主。这样开发者能检查输出是否满足用途。无法由消息确定的意图应作为可能解释，不能假装读懂对方的真实想法。
另一个假设练习是试衣原型：首版只接受“单人清晰正面照＋一件服装的预览”，不合格照片先提示重传。10–20 秒先作为待测目标，实测后再决定对外承诺。这样成功标准可以逐张检查，不会把所有失败都归因于用户不会用。
行动检查
可复制模板
需求澄清提示词
工作模板
我想帮助［目标用户］在［具体场景］完成［任务］。目前的做法和困难是［描述］。
先不要写代码。请按问题陈述、方案描述、技术约束、明确不做的事、成功标准检查需求。
每次只问一个会实质影响方案的问题，提供选项并说明代价。已知信息不要重复问；不确定的事实标为待验证。
最后整理为一份 SPEC，列出已决定事项、仍需验证的假设，以及可以实际执行的验收步骤。
SPEC 矛盾与假设检查卡
原句：［完整写出待检查的承诺］
与它冲突的另一条：［输入、边界或实现限制］
目前证据：［书面要求／官方能力／本项目测试／尚无］
选择的规则：［只保留一套明确口径］
不满足条件时：［提示、替代、退出］
正常／边界／失败验收样例：
待验证假设、验证方法和通过条件：
从别的模板继承但未经确认的字段：
请保持五段 SPEC 结构，逐项指出冲突，不替我把未知能力写成既成事实。
易错点
- 把“需求清楚就一定能做好”理解成交付保证：还要验证技术能力、数据与真实使用效果。
- 让 AI 一次问几十个细节：先回答会影响方向的分歧，避免假装全面。
- 讨论里改了决定却没改文档：下一次实现会沿用旧要求。