03 · 写清背景、任务与交付要求

返回课程总览 · 返回模块

03 · 写清背景、任务与交付要求

本课为可阅读、可跟做的文字教程。界面与账户能力可能随版本变化；视频和独立下载模板不属于当前已交付内容。案例均为自编教学样例，除明确标记的个人实测外，不代表真实业务成绩。

本课要解决的问题

一条好任务说明要让双方对“做完”有同一理解。把背景、输入、动作、输出和边界写出来，比堆叠“专业、深入、高质量”等形容词更有用。验收条件应是能逐项判断的事情，例如输出有三列，而非“看起来更好”。

准备材料

建立 input/会议便签.txt： 产品同事：下周想测试新的摘录入口。 设计同事：周三前交两版草图。 开发同事：需要先拿到草图才能评估工时。 主持人：周五再决定是否进入开发。 注意：“下周测试”是意向，不是已经排定的发布时间。

可复制任务说明

背景：我要为一次产品讨论整理会后行动。
输入：仅 input/会议便签.txt。
任务：区分已经确定的行动、讨论意向和依赖条件。
输出：output/行动清单.md，表格列为事项、负责人、时间、依据、状态；没有明确的人或日期填“待确认”。另列不超过3个需要追问的问题。
验收：每个行动都能对应原文；不得推算具体日期，不得把“是否进入开发”改为“已进入开发”。不要发送给任何人。

跟着做

1. 先用“帮我整理会议”生成一个版本，保存为行动清单-初稿.md。
2. 用上面的完整说明开一个新任务生成第二版。使用同样输入，避免新增材料影响比较。
3. 比较两版是否保留“先有草图再估工时”的依赖，是否把意向与决定分开。
4. 将任务说明中的五部分抽出，写成自己的空白任务说明表，之后换任务只替换内容。

结果检查

• 第二版表格列数、输出位置和追问数量符合要求。
• 设计交草图有负责人和相对时间；开发工时仍未知。
• “周五决定是否开发”被保留为待决事项，不能出现确定的上线日期。

出错时怎样处理

如果 AI 要求你补充无关背景，先判断缺口是否影响交付。本例缺少绝对日期，只需保留相对时间即可；不能为了填满表格随意猜一个日期。

独立练习与交付

为一个自己的低风险任务写出同样结构的说明，要求至少两项可检验的标准。保留两次输出，写明具体改善了哪一项，以及仍有哪项需要人工判断。