用 AI 把模糊任务写清楚：做一份能验收的需求说明

模糊要求为什么容易返工

任务速览：入门，不用编程。输入原始任务和已确认规则；输出一页说明、待确认问题及三个验收案例。适合交办任务前减少理解偏差。

“把活动报名做得好用一点，周五给我。”这句话没有说明谁使用、怎样算完成，也没说是否允许改流程。让 AI 直接生成方案，往往会多出未经同意的功能。本练习把它整理为一页需求说明，交付对象是负责实现的人；未确认的决定保留给负责人。

准备好输入与边界

准备原始任务、已有规则和可公开的样例，使用公司允许的文字 AI 即可。本练习不需要联网或付费 API；免费账户可能有额度限制，也不需要安装测试软件。以下报名场景和数字均为虚构练习，不是你的组织已经批准的规则。

任务：改善内部分享会报名。
已确认：名额20人；收集姓名和工作邮箱；满员后停止新增；
同一邮箱重复报名不能占两个名额；工作人员需要查看报名名单。
未确认：截止时间、是否候补、怎样取消、谁验收。
范围限制：本次不收款，不发营销消息，不新增个人信息字段。

第一步 让 AI 先找空白

依据上面的虚构材料，整理一页需求说明。
分为目标、使用者、已确认规则、交付物、范围外、待确认问题。
每条规则标记来自哪一句材料。不能自己设定时间、
负责人、候补机制或新的数据字段。建议另列，不能写成已批准。
先给最多四个会改变实施结果的问题；未知处明确留空。

优先追问会影响行为的问题，例如“取消后是否立即释放名额”。避免让模型一口气列出二十个装饰性问题。负责人没回答前，可以整理已知部分，但不能把默认猜测交给实施者当约定。

第二步 改写成可观察的验收

Cucumber 官方文档用 Given、When、Then 分别表示前提、事件和预期结果，并强调结果应可观察。普通工作也能借这个结构，不必编写或运行自动化测试。

只针对已确认规则，写三个验收案例：正常、重复、满员。
每个使用“已知／当／应看到”，描述用户可观察的结果。
不能用“体验良好”“性能优秀”等无法判断的词。
没有约定提示文案时，只写提示含义，不虚构固定文案。
最后列出这些案例尚未覆盖的边界，保持待确认状态。

第三步 用反例检查说明

正常案例：已知已有十九个有效报名，当新邮箱成功报名，应看到报名成功，名单增加一人并达到二十人。重复案例：已知某邮箱已报名，当该邮箱再次提交，应看到已报名提示，名单人数不增加。满员案例：已知已有二十人，当另一邮箱提交，应看到满员提示，名单人数仍为二十。

再问 AI：“如果两人在剩最后一个名额时同时提交，现有说明是否足以判定结果？”目前只能确认不得超额，还要补充并发处理的验收方式。邮箱大小写是否视为同一个、取消是否释放名额，也应列为待确认，而不是悄悄补成产品规则。

交给同事前检查什么

把说明逐条对照原任务：交付物具体吗，范围外写清了吗，每条验收都能实际观察吗，未确认事项有负责人吗？若原材料只说“快一点”，先询问使用条件和可接受时间，不要替团队承诺“两秒完成”。

AI 产出的说明仍需任务负责人确认；写出测试场景不代表功能已经通过测试。共享时只放虚构报名者，真实姓名与邮箱不应进入示例。没有得到授权，不要让工具自动建工单、通知同事或开始收集报名信息。

需求说明经负责人确认后，若要通过邮件交接，可接着做工作邮件的背景、请求与截止时间练习，写清希望对方确认什么、材料版本和已约定的时间；尚未确定的事项仍列为问题。

参考资料

• Cucumber：Gherkin 结构与可观察结果
• OpenAI：提示词应清晰具体并逐步修订

资料核查：2026年10月10日。示例为原创虚构练习，未声称已在产品中实测。