每项任务都有具体交付的周计划

先说清这一周最需要改变什么

一周计划需要一个现实约束：即将发布的产品、反复影响成交的问题，或你实际能维护的渠道。生成或重新定制计划时，先告诉 Afield 这个约束。七项各自合理的任务，也可能争抢同一份时间。

例如，潜在客户反复询问迁移过程，本周可以围绕迁移教程和介绍该教程的外联邮件展开。立刻安排所有社交渠道，不一定能解决这个问题。

在任务页展开当天任务的详情，查看步骤、来源范围和最终交付。“研究买家顾虑”应该说明研究谁、去哪里查，以及报告需要帮助你做什么判断。

过于笼统的任务	可以审阅的具体任务
优化 SEO	检查迁移页没有回答的设置问题，并写出替换段落
发社交内容	根据已批准的教程解释一个迁移错误，交付目标账号可用的完整草稿
找客户	研究符合迁移场景的公司，保留各家的依据和筛选原因

这些只是任务写法示例，实际计划应使用你的真实产品与材料。

单个任务可以编辑或移除；整周重点改变时，用「重新定制」说明可投入时间和优先事项。例如，要求完成一篇可以发布的文章，而不是同时准备五份浅草稿。

把前后依赖写进详情。写作任务应说明使用哪份研究，发布任务应指向哪份审阅后的稿件。排在连续两天，并不代表需要的材料已经传过去了。

看一个小团队准备供应商准入指南的例子。周一研究工程买家提交图纸前会问什么；周二把发现写成完整询价示例；周三准备一封向合适客户提供指南的邮件。真正的依赖是经过审核的示例，不是日历上把三个任务排成先后。

周一发现了初始计划遗漏的区别：一部分买家希望供应商负责零件设计，而这家工厂只按客户图纸加工。因此，运行周二任务前就应修改要求，让指南解释加工询价需要什么，并与设计需求书明确区分。

结合工艺说明和周一的发现，完成整篇指南。给出包含材料、图纸版本、公差问题与预计数量的询价示例，解释哪些缺失信息会阻碍报价、哪些可以在第一轮回复里澄清。不承诺产品设计。最后提供一份买家发送询价前能直接使用的检查清单。

返回的文章里需要真的有这份询价及解释。提纲上写着“这里加入示例”，还没有完成任务。继续在同一任务中指出缺失部分，要求返回完整改稿，再检查结果。

如果客户图纸不能公开，可以先完成有依据的说明，配一个明确标为示意的例子。技术数值影响产品承诺时，请负责同事确认后再使用。邮件也可以围绕已审核的范围先写出来，把发布依赖的具体资料列清楚，而不是所有任务一起停住。

文章完成但还没有发布时，计划里也要保留这个区别。把整条链全部勾完，会掩盖仍需执行的步骤。优先级改变时重新定制整周；只需要换示例或交付内容时，修改那一项任务。计划才能随着实际发现前进，而不是无论做出了什么都按七天打卡。

选择「执行」，在助手中继续该任务。复杂任务可能包含多次研究和写作，完成后应能查看报告或草稿，并在同一对话中修改。

把任务说明再讲一遍，不能算完成。研究任务要看发现和来源，文章任务要看完整正文；成稿与发布也要分开。约定的内容还没交付，就不应因为出现了一条回复而把任务记为完成。