Agent 任务先写权限与证据卡

把任务交给 AI 或 Agent 前，不要只写“帮我完成 X”。先用一张很小的权限与证据卡，把目标、输入边界、允许动作、禁止动作、人工确认点、验证证据和失败回退写清楚。这样 agent 才知道什么可以自动做，什么必须停下来交给人判断。

适用场景

需要让 agent 读取仓库、改文件、联网搜索、调用外部工具或处理客户资料。
任务看起来很小，但可能触发发布、发送消息、付款、删除文件、生产接口或隐私数据处理。
你希望本轮输出可以被复核、接力和复用，而不是一次性聊天记录。
书稿、runbook 或工作流模板里已经出现“权限边界 / 人工确认点 / 验证证据 / 失败回退”等字段，但还没有一个简短入口。

不适用：纯头脑风暴、无工具调用、无外部数据、无副作用的草稿讨论。即便如此，仍建议至少写清目标结果和输出格式。

七字段卡片

任务名称：
目标结果：
输入材料：
允许读取：
允许修改 / 执行：
禁止操作：
人工确认点：
验证证据：
失败回退：
可复用沉淀：

最小通过标准：这张卡必须能回答四个问题：

Agent 能看什么、能改什么、能调用什么？
哪些动作不能自动执行，必须先给方案或等待人工确认？
交付物用什么证据验收，例如命令输出、diff、链接、截图、日志或用户反馈？
如果资料不足、工具失败或输出错误，下一步是停止、缩小范围、回滚还是补证据？

Go / Narrow / Stop 判断

结果	条件	下一步
`Go`	目标、输入、权限、人工确认点、验证证据和失败回退都写清楚	允许 agent 执行最小可验证切片
`Narrow`	目标清楚，但权限、证据或回退缺一项	先缩小任务，只做只读检查、草稿、局部 diff 或验证脚本
`Stop`	涉及发布、付款、生产接口、私密资料或不可逆操作，但没有明确授权	不执行副作用动作，只输出需要补充的授权和证据

判断时不要用“任务很简单”替代授权。越是看似简单的发布、删除、群发和生产操作，越应该写成 Stop 或 Narrow，直到授权字段完整。

与可复用沉淀的关系

“可复用沉淀”不是任务完成后的装饰项，而是任务前就要决定的验收方向：

如果是代码任务，沉淀可能是测试、脚本、fixture、复用 helper 或故障样例。
如果是写作任务，沉淀可能是模板、检查清单、案例卡、公开版本或内部 notebook。
如果是收入实验，沉淀可能是 offer 页面、回复模板、结果记录表或观察 runbook。
如果是审查任务，沉淀可能是红旗分诊、证据请求模板、下一条安全命令梯或匿名案例骨架。

没有沉淀方向时，任务仍然可以执行，但不要把它包装成“资产建设”；先记录为一次性探索。

示例

任务名称：检查某个 AI 生成 PR 是否可合并
目标结果：输出 1 页审查报告，包含 P0/P1/P2、证据和下一条安全命令
输入材料：PR 链接、失败命令、最近一次 CI log
允许读取：PR diff、公开 issue、仓库测试说明
允许修改 / 执行：本地只读测试命令；不得 push
禁止操作：合并 PR、修改生产配置、发布评论、访问未授权私有数据
人工确认点：是否公开报告、是否把建议改成正式 PR 评论
验证证据：git status、测试命令、exit code、关键 log 摘要
失败回退：证据不足时只交付 Next evidence needed，不写 P0 Stop
可复用沉淀：把重复问题写入审查 checklist 或匿名案例骨架

这张卡的目标不是限制 agent，而是让 agent 能安全地更自主：权限越清楚，越少来回确认；证据越明确，越容易接力和复用。

常见反模式

只写目标，不写权限。 “帮我发布这篇文章”没有说明渠道、账号、时间窗口和回退方式。
只写允许，不写禁止。 Agent 知道可以改文件，却不知道不能发消息、不能调用生产接口。
把验证交给感觉。 “看起来没问题”不能替代测试、diff、日志、链接或人工反馈。
没有失败回退。 工具失败后继续猜，容易把不确定输出包装成结论。
沉淀方向滞后。 任务完成后才想要模板或案例，往往已经丢失关键证据。

检查清单

目标结果是否具体到交付物？
输入材料是否列出来源和脱敏边界？
允许读取、允许修改和禁止操作是否分开写？
人工确认点是否覆盖价值判断、对外承诺和不可逆动作？
验证证据是否能被下一位接手者复跑或复核？
失败回退是否包含停止条件或缩小任务的下一步？
是否写清本轮会沉淀成什么资产，或者承认只是一次性探索？