给 AI 的任务说明怎么写：一份可以直接填写的模板

让 AI 做项目时，最容易漏掉的往往是完成条件。说“做一个报名页面”，它可能交出界面，也可能接上数据库；双方对“完成”的理解不同，后面的修改就会不断扩大范围。

任务说明的作用，是在开工前把这些分歧变成可以讨论的选择。下面是一份用于小项目的模板，示例数据均为虚构。

先填六个空

使用者：谁会用这份结果？
场景：他在什么情况下，需要完成什么动作？
输入：给出一组实际格式的样例，敏感内容先替换。
交付物：具体文件、页面或功能，以及打开或运行方式。
完成条件：我能通过哪些操作确认任务做成了？
范围与权限：允许修改哪里，哪些操作需要先展示结果？

如果填写时发现有三种不同使用者，第一版可以先选一种。如果“完成条件”只有“好看”“专业”，继续写出具体表现：比如打印时标题不被截断，报名失败时保留已填内容。

一份填好的例子

使用者：小型读书会的组织者。
场景：把每周书目和讨论时间整理成可打印的议程。
输入：三条虚构议程，包含一条标题很长的记录。
交付物：一个可在本地打开的议程页，附修改文字的方法。
完成条件：按开始时间排序；空标题有提示；打印时不显示编辑按钮。
范围与权限：这一版只编辑议程，不接收报名；先在本地展示，公开发布另行决定。

这个例子故意把数据保存、报名和打印拆开。它们看起来属于同一页面，但每一项都有不同的验收方式。先把其中一个做通，后续需求才有稳定的基础。

用反例补全模糊要求

“简洁”可以补成“第一页只显示时间、书目和地点”；“容易修改”可以补成“组织者不改代码也能更新标题”；“不能出错”则需要换成可检查的失败场景。

反例同样有用：遇到时间缺失，显示待定，不自行猜测；两场时间冲突，提示冲突，不擅自调整活动安排。这样可以区分工具应执行的动作与人需要作出的判断。

开工前让 AI 复述一次

请它列出交付物、验收方法和尚不明确的问题。逐项确认它是否扩大了范围。若它增加账号、支付或自动通知，就要求说明这些功能对应哪条需求，再决定是否保留。

后续需求变化也写进同一份说明，标出替代了哪条旧要求。不要只把新意见留在很长的聊天记录末尾，否则下一轮修改可能继续沿用旧标准。

这份模板适用于小型软件和内容任务。涉及专业判断的结果，仍需相应专业人员复核。初次做项目可以配合文科生的 AI 项目入门指南使用。