怎么写一份能被复核的任务指令How to Write a Task Brief Someone Can Review

四栏先写全：目标（交付什么）、输入（给哪些材料）、边界（不许做什么）、验收（怎么算通过）。缺任一栏，复核的人只能猜你的意图。

验收口径写成能判定的句子：不写「质量要好」，写「每条结论都能指回材料里的具体位置」。

边界要写禁止项和例外怎么处理：材料里查不到的事实，标注「未找到」，不靠常识补全。

让输出自带凭据：用到的材料编号、调用的工具、没做完的部分，复核时按这几样逐项对照。

举个例子（虚构情境）：输入是 12 页客服工单文本 → 处理是按模板产出「问题分类 + 依据段落编号」→ 结果判断是随机抽 5 条，人工核对分类与段落是否对得上 → 对不上时的下一步是补写分类定义里的边界说明再跑一轮，而不是先换模型。

指令本身要版本化：每次改动留一行「为什么改」，否则过半年没人知道哪条口径还生效。

Fill in four fields: goal (what must be delivered), inputs (which materials it gets), boundaries (what it must not do), acceptance (what counts as passing). Missing any one leaves the reviewer guessing at your intent.

Write acceptance as a decidable sentence: not "good quality", but "every conclusion points back to a specific location in the source material".

Boundaries need prohibitions and exception handling: facts not found in the material get marked "not found", not filled in from common sense.

Make the output carry its own evidence: material IDs used, tools called, parts left undone - the reviewer checks against exactly these.

Worked example (fictional scenario): input is 12 pages of support tickets -> processing produces "issue category + paragraph reference" from a template -> the check is to sample 5 items and confirm the category matches the cited paragraph -> if they do not match, the next step is to tighten the boundary wording in the category definitions and rerun, not to swap models.

Version the brief itself: log one line on "why this changed", or in six months nobody knows which acceptance rule still applies.