跳到正文

通用方法 / 从零上手

写一份能验收的任务说明

把目标、资料、输出和边界交代清楚,减少 Agent 做了一堆事却交不出结果的问题。

方法指南2 分钟阅读整理于 2026-10-12
这是一条可尝试的工作方法。

文中的示例任务用于练习;不承诺具体账号的运行结果、费用或耗时。

把“帮我研究一下”变成具体交付

先确定最后要拿到什么。例如“根据这五篇资料,写一页能给同事看的比较说明,列出三项选择条件,每项附来源”。这句话已经交代了输入范围、读者、产物和完成标准。

你不需要把所有操作步骤预先写死;需要明确的是结果、不能遗漏的要求,以及遇到资料缺口时应该怎么办。

复制这个模板

把方括号中的内容换成自己的要求,附上真正需要用的文件或链接。

可复制 · 请替换方括号中的内容
请完成以下任务:
目标:[我希望得到的具体结果]
资料:[文件、链接或我提供的背景]
交付:[文件格式、内容结构、保存位置]
完成标准:[我如何判断结果可用]
限制:[不可改动的内容;需要我确认的动作]
缺少资料时先指出缺口。
区分资料中的事实、你的推断和未知。
先完成一次任务并提供可检查的结果。

同一份模板也可以在资源页下载,作为自己的任务起点。

第一轮怎样反馈

遇到结果不符合要求,指出具体差异:“第二项结论没有来源”“我需要可编辑的 Markdown,不能只有截图”“这份表格少了日期列”。给出差异以后,让它补齐相应部分,而不是反复说“再好一点”。

要求它说明当前完成了什么、还缺什么,并给出文件或来源位置。“完成了”的文字回复要和实际产物对应。

留下可复用的部分

任务结束后,保存一份最终输入、结果和修正记录。重复使用时,更新资料范围和时间,而不是机械复制上一次的上下文。需要定时任务时,先让它在新资料上再运行一次,确认仍符合标准。

验收:别人只看任务说明和产物,也能判断这次工作是否完成。

FROM MY OWN BLOG

我的实际使用

从我已发表的 Blog 里整理:当时怎样用,结果怎样,哪里还没做成。具体过程以原文记录为准。

使用观察尹睦

我在意 Muse 怎样接下一个任务

先列计划,把做不了和需要授权的部分讲清楚,是我这几天用下来觉得省心的地方。

我让它做一件事,能做的,它会仔细把计划列好;做不了的、需要我提前授权的,它会先讲清楚。

原文摘录 · 有没有可能,Muse火是因为它真的好用 ↗

过程整理

  1. 交代要做的事

    我把事情交给 Muse,观察它是否理解目标,而不是只看一句答应。原文没有公布具体任务内容。

  2. 查看计划与限制

    我的体验是它会先列计划,并说明做不了或需要提前授权的部分。

  3. 保留自己的判断

    我觉得这让协作更省心,但原文也说不清有多少来自模型、多少来自产品流程。

给下一次使用的建议

交任务时,可以要求先列步骤、需要的材料和权限。确认能走通,再让它开始。

记录范围:这是几天使用后的主观观察,不是某一项任务的完整复现记录,也没有可用来量化比较的耗时数据。

对话后的思考尹睦

和 Muse、Dots 聊完,我更重视问题定义

一次对话引出了关于代码与判断力的思考:管成本、拆任务、定验收标准。

昨天晚上跟muse和dots聊天,突然想到一个问题。

原文摘录 · AI时代,就不需要程序员了吗? ↗

过程整理

  1. 先发生一次对话

    我在文章开头记录了前一晚和 Muse、Dots 聊天,但没有公开完整对话。

  2. 把想法写成文章

    文章接着讨论了代码与问题定义的价值,并提出管成本、拆任务、定验收标准这三件事。

给下一次使用的建议

与 Agent 协作之前,先说清要什么、能花多少资源,以及怎样判断已经做成。

记录范围:这是对话后的个人思考。没有证据证明后面的文章观点由某个 Agent 提出,也没有证据表明安装过文中提到的 Skill。

下一步

场景实战:整理一份带来源的信息周报

定义范围、时间和重要变化,先完成一份可检查的周报,再决定是否自动运行。