跳到正文
一AllOne
关注

工作流

给 AI 写需求：把想法变成它做得对的规格说明

AI 写代码出错，很多时候不是能力问题，而是需求没说清。这篇给出一套和具体工具无关的写法：先让 AI 反问你，再写一页规格说明，用验收标准和边界约束把「做对」定义清楚，然后拆成小任务交给它。

发布于 2026-10-22 · 最后核实：2026-10-22 · 文中价格与额度以各官网为准

你可能有过这种体验：对 AI 说「帮我做一个记账网站」，几分钟后它真的交出了一个能跑的东西——但用的技术栈不是你想要的，功能多了一堆你不需要的，偏偏你最在意的那个功能做得不对。

问题往往不在 AI，而在需求。AI 编程工具很擅长「把清楚的要求做出来」，却没法读出你脑子里没说出口的东西。无论你用的是 Claude Code、Codex、Cursor、TRAE、GitHub Copilot、OpenCode 还是别的工具，这一点都一样。

结论先说：动手写代码前，先花 20 分钟写一份一页纸的规格说明（spec）。它要回答四个问题：做给谁、做什么、怎么算做对、什么不能碰。 下面是一套可以反复使用的流程。

为什么规格说明比提示词技巧更重要

几个原因，和你用哪个工具无关：

  • AI 会默认填补空白。 你没说用什么框架，它就挑一个；你没说要不要登录，它可能顺手做一个。每一个「它替你做的决定」，都可能是返工的来源。
  • 上下文会被冲掉。 对话越长，早期的要求越容易被「遗忘」。Anthropic 的 Claude Code 最佳实践文档把这一点列为最重要的约束：上下文窗口填满后，模型表现会下降。写在文件里的规格说明可以随时重新读取，聊天记录不行。
  • 你需要一个判断标准。 没有写下来的验收标准，你只能靠「看起来差不多」来判断它做没做完。

第一步：先让 AI 反问你

很多人写不出好需求，是因为自己也没想清楚。最省力的办法是反过来让 AI 采访你。Claude Code 官方最佳实践里就推荐了这种做法：先给一个简短描述，让它深入追问技术实现、界面、边界情况和取舍，问完之后写成一份规格说明文件，再开一个新会话去执行。

这个方法在任何聊天式或 Agent 式工具里都能用。可以直接用这段提示词：

我想做：[一句话描述]。
在写任何代码之前，请先采访我。重点问那些我可能没想到的问题：
目标用户、核心场景、边界情况、技术约束、哪些功能可以不做。
一次问 3–5 个问题，等我回答后再继续。
问完后，把结论整理成 SPEC.md，不要开始写代码。

关键是最后一句：明确告诉它这一步不写代码。 很多工具都有只读的「计划模式」，用上它效果更好；没有的话，用这句话约束也行。

第二步：一页纸规格说明的结构

规格说明不是越长越好。Addy Osmani 在关于给 AI Agent 写规格的文章里提到，指令堆得越多，模型对每一条的遵守程度反而越低。一页纸、结构清楚，比十页散文有用得多。推荐这个结构：

# 项目名

## 一句话目标
给 [谁] 解决 [什么问题]，让他们能 [做成什么]。

## 用户与场景
- 主要用户：……
- 典型场景：用户打开网站后，先……然后……最后……

## 第一版要做的功能（按优先级）
1. ……
2. ……

## 明确不做的功能
- 不做用户注册（第一版用链接分享即可）
- 不做移动端 App

## 技术约束
- 框架：……（写具体，带版本更好）
- 部署：静态站点，部署在……
- 不引入新的付费服务

## 验收标准
- [ ] 在手机浏览器上能完成核心流程
- [ ] 输入为空时显示提示，而不是报错
- [ ] 构建命令通过，无类型错误

## 待定问题
- ……

其中最常被省略、又最有价值的是两节：「明确不做的功能」和「验收标准」。

第三步：把「做对」写成可以检查的标准

验收标准要写成能判断真假的句子，而不是形容词。

模糊的写法 可检查的写法
页面要好看 参考这张截图的布局；在 375px 宽的屏幕上不出现横向滚动条
处理好错误 网络请求失败时，按钮恢复可点，并显示「加载失败，请重试」
校验邮箱 a@b.com 通过；abc、a@、@b.com 不通过
性能要好 首页图片都经过压缩，单张不超过某个你定下的大小

能写成测试用例的，尽量写成具体的输入和输出。Claude Code 文档里有一个很好的对比：与其说「实现一个验证邮箱的函数」，不如直接给出几个应该通过和不应该通过的例子，并要求实现后运行测试。给 AI 一个它自己能跑的检查，它就能自己发现并修正错误，而不是每个错误都等你来发现。

界面类的需求，一张草图胜过一大段文字。用 Excalidraw 画个线框图，截图贴给 AI，再写上「完成后截图对比，列出差异并修正」。

第四步：写清楚边界

边界告诉 AI 什么时候可以放手做、什么时候要停下来问你。GitHub 分析了 2500 多个仓库里的 Agent 指令文件后总结出一种好用的写法：三级边界。

  • ✅ 直接做：运行测试、按现有代码风格写新文件、修复类型错误。
  • ⚠️ 先问我：新增依赖包、修改数据库结构、改动部署配置。
  • 🚫 绝不做：提交密钥或 .env 文件、删除已有的测试来让测试通过、修改某个指定目录。

GitHub 的分析还发现，「不要提交密钥」是出现最多、也最有用的一条约束。这条建议直接抄进你的每个项目。

第五步：拆成小任务，一次只交一个

规格说明写好后，不要说「按 SPEC.md 把整个项目做完」。更稳的做法是：

  1. 让 AI 根据规格说明列出一个任务清单，每个任务小到可以单独完成、单独验证。
  2. 你审一遍清单，调整顺序，删掉不需要的。
  3. 一次只让它做一个任务，做完验证、提交，再做下一个。

GitHub 开源的 Spec Kit 把这个过程总结为四个阶段：明确需求（Specify）→ 制定技术方案（Plan）→ 拆分任务（Tasks）→ 逐个实现（Implement）。你不一定要用这个工具，但这四步的顺序值得照搬。每一步都有你的检查点，错误在最便宜的阶段就被拦下来。

第六步：让规格说明活下去

规格说明不是写完就扔的。开发中做了新决定（比如砍掉一个功能、换了数据结构），立刻更新文件。它应该始终是「这个项目现在要做成什么样」的唯一真相。

把它放进项目仓库，和代码一起做版本管理。下次开新会话、换一个 AI 工具，甚至过半年你自己回来接手，第一件事都是读它。用 Notion 或 Obsidian 打草稿也可以，但定稿最好进仓库，AI 才读得到。

常见的坑

  1. 只写要做什么，不写不做什么。 AI 天然倾向于「多做一点」，不划边界，它就会自由发挥。
  2. 把实现细节当需求。 第一版规格说明重点写「做什么、为什么」，技术细节可以让 AI 先提方案，你来挑。
  3. 规格说明太长。 超过一两页，就考虑拆成几个文件，按任务只给相关部分。
  4. 验收标准全是形容词。 「快」「好看」「友好」没法检查，换成具体数字、截图或例子。
  5. 需求变了不更新文件。 文件和实际不一致，比没有文件更糟，因为 AI 会照着过时的内容做。
  6. 跳过审清单这一步。 AI 拆出来的任务顺序不一定合理，花两分钟看一眼能省掉很多返工。

一套可以直接用的流程

  1. 一句话写下想法 → 让 AI 采访你（不写代码）。
  2. 整理成一页 SPEC.md：目标、用户、功能、不做什么、技术约束、验收标准、待定问题。
  3. 加上三级边界：直接做 / 先问我 / 绝不做。
  4. 让 AI 拆任务清单，你审核。
  5. 一次一个任务，做完验证、提交。
  6. 决定有变，先改 SPEC.md。

这套流程不依赖任何具体工具。工具会换代，但「先把要什么说清楚」这件事，永远是让 AI 做对的前提。

参考资料

← 返回教程列表