很多低质量输出并不是模型能力不足，而是任务本身没有被说清楚。直接输入“帮我写一下”“分析这个”或“优化代码”，模型只能自行猜测目标、读者和判断标准。
任务简报的作用，是在正式提问前先补齐这些空白。它不需要很长，五分钟足够写出第一版。
可复制模板
任务目标：我要完成什么结果？
使用对象：结果给谁看、在什么场景使用？
必要背景：模型必须知道哪些上下文？
输入材料：我会提供哪些文字、数据、代码或链接？
输出格式：需要清单、表格、文章、代码还是操作步骤？
限制条件：长度、语气、技术栈、时间范围或不能做什么？
验收标准：满足哪些条件才算完成？一个具体例子
不要只说：
帮我写一篇 Cursor 教程。可以改成：
任务目标：写一篇帮助零基础读者完成第一次 Cursor 项目修改的教程。
使用对象：会基本电脑操作，但不熟悉 Git 和终端的读者。
必要背景：教程基于一个已有的 Astro 项目，不从安装 Node.js 开始。
输入材料：项目目录、目标页面和需要修改的文案。
输出格式：按“准备、定位、修改、验证、常见错误”分节。
限制条件：避免宣传式语言，不假设读者知道命令含义。
验收标准：读者可以照着步骤完成修改，并知道如何运行构建验证。第二种写法并没有使用复杂提示词，但它给出了足够明确的决策边界。
使用顺序
- 先独立写完任务简报，不急着选择模型。
- 删除与结果无关的背景，避免上下文过载。
- 把已有材料一起交给模型，不让它凭空补全事实。
- 要求模型先复述任务和缺失信息，再开始生成。
- 用验收标准逐项检查输出，而不是只判断“看起来不错”。
什么时候需要继续拆分
如果一个任务同时包含研究、写作、设计和发布，最好拆成多个阶段。每个阶段只有一个主要输出，例如先产出资料卡，再产出文章结构，最后才写正文。
任务简报不是为了让提示词变长，而是为了减少猜测。能用一句话说清楚的任务，不必套完整模板；一旦结果重要、过程复杂或需要多人协作，就值得先写简报。