先让 AI 向你提问，再把用户任务、现有事实、范围、约束和可观察的验收标准写成一份任务说明书。
- 学习结果
- 把一个模糊的想法整理成一份可以直接交给 AI 或开发者执行的任务说明书，事实和假设分开，验收标准可以逐条检查。
- 时长
- 2-3 小时
- 难度
- 经验分享
- 核验
- 未核验
正文
“做一个项目详情弹窗”“加一个收藏功能”，这类一句话需求交给 AI，它也能很快写出代码。问题是，写出来的东西往往和你脑子里想的不一样，然后就是一轮又一轮的“不是这样，改一下”。
花时间在开发之前把需求写清楚，比在开发之后反复返工划算得多。好消息是，写需求这件事本身，AI 可以帮上很大的忙。
从一句话到任务说明书
一份能直接开工的任务说明书，大致包含这几部分：
- 用户任务：谁、想完成什么、现在被什么挡住了。
- 现有事实：相关的页面、组件、数据字段和接口，以及哪些可以复用。
- 范围：这次做什么，明确不做什么。
- 约束：哪些东西不能改。
- 验收标准：一条条可以观察到的行为。
- 未决问题：还不确定、需要查证或者需要你拍板的事。
第一步：让 AI 先向你提问
与其自己一次写完，不如把想法告诉 AI，让它先提问，不要急着给方案。比如：“我想给项目列表加一个详情查看功能。在写需求之前，请先问我 5 到 8 个问题，帮我把需求弄清楚。”
好的问题会逼你想清楚很多原本模糊的地方：详情是弹窗还是独立页面？手机上怎么显示？没有图片的项目怎么办？需要分享链接吗？回答完这些问题，需求就清楚了一大半。
第二步：从用户任务出发，而不是界面
需求要从用户要完成的事开始。“做一个漂亮的弹窗”描述的是界面，“读者不离开列表，就能看到项目的来源，并打开官网”描述的是用户任务。
界面形态只是实现方式之一。写清了用户任务，AI 和开发者才能判断弹窗、抽屉还是独立页面更合适，而不是被一个界面形态限制住。
第三步：事实和假设分开
AI 在补充需求时，经常会“合理推测”一些并不存在的东西：数据里有某个字段、用了某个版本的库、浏览器会有某种行为。这些推测如果直接写进需求，开发时就会出问题。
做法是让 AI 先列出它需要阅读的文件和不确定的地方，然后根据真实的代码补齐事实。需求里每一条关于现状的描述，都要能在代码或数据里找到依据。
特别要注意两类情况：
- 数据里没有的东西，不能编造。数据里没有评分，就不能为了让界面好看而让 AI 编一个评分出来。
- 未知的要明确标出来。来源还没核验，就显示“待核验”，而不是自动填上当天的日期。
第四步：写清范围和约束
范围要同时写“做什么”和“不做什么”。比如详情查看功能：展示详情、关闭、打开官网链接属于这次的任务；新增账号系统、修改审核流程、抓取新数据都不属于。
约束必须准确，并且彼此不矛盾。如果一边要求“保留现有接口”，一边又要求“改成新的数据结构”，AI 只能二选一，结果多半不是你想要的。发现矛盾，先解决再开始。
第五步：验收标准写成可观察的行为
“交互流畅”“体验好”这类描述没法检查。验收标准要写成任何人都能逐条验证的行为：
- 点击某个项目卡片，打开的是这个项目的详情；
- 按 Esc 键可以关闭，关闭后键盘焦点回到刚才点击的卡片；
- 手机上详情内容不会超出屏幕；
- 没有图片、没有来源的项目，显示明确的提示。
除了正常情况，还要写上异常情况和边界情况。这些往往是实现时最容易漏掉的。
需求变了，验收也要跟着变
需求确定之后，整理成一份简洁的说明书，作为开发的依据。中途改了目标，就同步修改说明书和验收标准，不要让执行的人靠翻聊天记录去猜最终版本。
比如详情从弹窗改成独立页面，就要重新确认：网址怎么设计、返回时回到列表的哪个位置、键盘操作有什么变化。不能沿用弹窗的验收条件。
学习步骤
- 用一句话写下你的想法，交给 AI，要求它先提出 5 到 8 个澄清问题。
- 回答这些问题，把需求改写成用户任务。
- 让 AI 列出需要阅读的文件，根据真实代码写出现有事实。
- 把 AI 的推测和已确认的事实分开，未知的地方明确标出。
- 写出范围（做和不做）和约束，检查有没有互相矛盾。
- 写出包含正常、异常和边界情况的验收标准，整理成一份说明书。
场景拆解
把“加个详情弹窗”写成任务说明书
小许想给工具目录加一个功能：不离开列表就能看到工具详情。
- AI 提问：他让 AI 先提问。AI 问了 7 个问题，其中“详情需要能分享链接吗？”让他意识到，读者经常想把某个工具发给朋友。
- 用户任务：读者在列表中点击一个工具，不离开列表就能看到用途、价格类型、来源和官网链接，并能把这个工具的链接分享给别人。
- 现有事实：AI 读了数据文件后报告，数据里有用途、价格类型、来源和官网字段，但没有评分和用户数。小许确认详情里不显示这两项。
- 范围和约束：做详情展示、关闭、分享链接；不做收藏、评论和账号。不改现有的数据结构和详情页网址。
- 验收：点击卡片打开对应详情；Esc 关闭并且焦点回到卡片；带分享参数的链接打开后直接显示该工具的详情；手机上不溢出；没有来源的工具显示“来源待补充”。
因为加了“可以分享”这个要求，AI 建议用独立的详情页，而不是弹窗：独立页面天然有自己的网址。这个决定是在写需求阶段做出的，而不是开发到一半才发现。
补充材料
思维导图、练习、清单和参考资料可按需展开。
01 思维导图和离线文件
适合读完后下载到自己的知识库里继续整理。
说明书的六个部分
- 用户任务
- 现有事实
- 范围
- 约束
- 验收标准
- 未决问题
写的过程
- 先让 AI 提问
- 从用户任务出发
- 事实和假设分开
- 不编造不存在的数据
验收标准
- 写成可观察的行为
- 覆盖正常、异常、边界
- 需求变了同步修改
02 实践练习
根据文章内容记录自己的判断与依据。
写一份任务说明书
选一个你想做的功能，借助 AI 写出一份可以直接开工的任务说明书。
准备材料
- 一个你想做的功能想法。
- 项目代码（让 AI 能读取相关文件）。
练习步骤
01 / 让 AI 提问
时间： 20 分钟
操作：
- 把一句话想法交给 AI，要求它先提问，不给方案。
- 逐个回答问题。
产出： 一份问答记录。
检查： 至少有一个问题让你改变或补充了原来的想法。
02 / 核对事实
时间： 30 分钟
操作：
- 让 AI 列出需要读的文件，根据代码写出现有事实。
- 把推测和事实分开，标出未知项。
产出： 一份“事实与假设”清单。
检查： 每条事实都能指出依据在哪个文件里。
03 / 写成说明书
时间： 40 分钟
操作：
- 按模板写出用户任务、范围、约束和验收标准。
- 请 AI 检查约束之间有没有矛盾、验收标准有没有遗漏的异常情况。
产出： 一份任务说明书。
检查： 每条验收标准都可以由另一个人独立验证。
完成检查
- 需求从用户任务出发。
- 事实有依据，假设和未知都标出来了。
- 验收标准包含正常、异常和边界情况。
03 清单、模板和关键词
用于项目记录和自查。
任务说明书模板
## 用户任务
谁：
想完成什么：
现在被什么挡住：
## 现有事实（附依据文件）
-
## 范围
做：
不做：
## 约束
-
## 验收标准
正常情况：
异常情况：
边界情况：
## 未决问题
-
让 AI 先提问的提示词
我想做：【一句话想法】。
在写需求或给方案之前，请先问我 5-8 个问题，
重点问：用户是谁、要完成什么、边界情况、哪些东西不能改。
一次只问问题，不要给方案。
关键概念
- 用户任务：谁要完成什么，而不是界面长什么样
- 现有事实：有代码或数据依据的现状
- 假设：AI 或你自己的推测，需要查证
- 范围：做什么和不做什么
- 约束：不能改动的部分
- 可观察的验收标准：任何人都能逐条验证的行为
容易误判
- 用界面形态代替用户任务
- 让 AI 编造数据里不存在的字段
- 把未核验的信息填上默认值
- 只写“做什么”，不写“不做什么”
- 约束之间互相矛盾
- 需求改了，验收标准没跟着改
04 工具和参考资料
本篇涉及的工具和参考链接。
可参考工具
- Claude
- ChatGPT
- Notion
- Linear