把“帮我研究一下”变成具体交付
先确定最后要拿到什么。例如“根据这五篇资料,写一页能给同事看的比较说明,列出三项选择条件,每项附来源”。这句话已经交代了输入范围、读者、产物和完成标准。
你不需要把所有操作步骤预先写死;需要明确的是结果、不能遗漏的要求,以及遇到资料缺口时应该怎么办。
复制这个模板
把方括号中的内容换成自己的要求,附上真正需要用的文件或链接。
可复制 · 请替换方括号中的内容
请完成以下任务:
目标:[我希望得到的具体结果]
资料:[文件、链接或我提供的背景]
交付:[文件格式、内容结构、保存位置]
完成标准:[我如何判断结果可用]
限制:[不可改动的内容;需要我确认的动作]
缺少资料时先指出缺口。
区分资料中的事实、你的推断和未知。
先完成一次任务并提供可检查的结果。
同一份模板也可以在资源页下载,作为自己的任务起点。
第一轮怎样反馈
遇到结果不符合要求,指出具体差异:“第二项结论没有来源”“我需要可编辑的 Markdown,不能只有截图”“这份表格少了日期列”。给出差异以后,让它补齐相应部分,而不是反复说“再好一点”。
要求它说明当前完成了什么、还缺什么,并给出文件或来源位置。“完成了”的文字回复要和实际产物对应。
留下可复用的部分
任务结束后,保存一份最终输入、结果和修正记录。重复使用时,更新资料范围和时间,而不是机械复制上一次的上下文。需要定时任务时,先让它在新资料上再运行一次,确认仍符合标准。
验收:别人只看任务说明和产物,也能判断这次工作是否完成。
从我已发表的 Blog 里整理:当时怎样用,结果怎样,哪里还没做成。具体过程以原文记录为准。
使用观察尹睦
我在意 Muse 怎样接下一个任务
先列计划,把做不了和需要授权的部分讲清楚,是我这几天用下来觉得省心的地方。
我让它做一件事,能做的,它会仔细把计划列好;做不了的、需要我提前授权的,它会先讲清楚。
原文摘录 · 有没有可能,Muse火是因为它真的好用 ↗
过程整理
- 01
交代要做的事
我把事情交给 Muse,观察它是否理解目标,而不是只看一句答应。原文没有公布具体任务内容。
- 02
查看计划与限制
我的体验是它会先列计划,并说明做不了或需要提前授权的部分。
- 03
保留自己的判断
我觉得这让协作更省心,但原文也说不清有多少来自模型、多少来自产品流程。
给下一次使用的建议交任务时,可以要求先列步骤、需要的材料和权限。确认能走通,再让它开始。
记录范围:这是几天使用后的主观观察,不是某一项任务的完整复现记录,也没有可用来量化比较的耗时数据。
对话后的思考尹睦
和 Muse、Dots 聊完,我更重视问题定义
一次对话引出了关于代码与判断力的思考:管成本、拆任务、定验收标准。
昨天晚上跟muse和dots聊天,突然想到一个问题。
原文摘录 · AI时代,就不需要程序员了吗? ↗
过程整理
- 01
先发生一次对话
我在文章开头记录了前一晚和 Muse、Dots 聊天,但没有公开完整对话。
- 02
把想法写成文章
文章接着讨论了代码与问题定义的价值,并提出管成本、拆任务、定验收标准这三件事。
给下一次使用的建议与 Agent 协作之前,先说清要什么、能花多少资源,以及怎样判断已经做成。
记录范围:这是对话后的个人思考。没有证据证明后面的文章观点由某个 Agent 提出,也没有证据表明安装过文中提到的 Skill。