一次发布准备交给三个助手：一个查资料，一个做图，一个核对数据。三个窗口都写着“完成”，负责人却还不知道图片是否过审、数据是否等人确认，以及哪份文件可以真正交付。
已有项目看板或工作流能管理依赖和验收时，继续把它作为任务主线。任务少时，一份写清负责人、产物和截止时间的清单就够了。把更多运行状态搬到一屏，并不会自动让进度更准确。
以发布配图为例，助手提交任务编号、获准素材和约定尺寸，通过 EasyNet 调用生成函数，返回图片位置和实际尺寸。业务任务关联这次调用，设计负责人查看图片后再写入审批结果；函数返回了一张图，不等于这张图已获准发布。
每个任务需要自己的完成条件：资料附哪些出处，数据由谁复核，图片交哪种尺寸。读取进度的身份也要对应项目范围，不能为了汇总状态顺带公开其他客户的资料与产物。
跨系统汇总还需要接上人工审批和外部任务状态。等待确认应明确写成等待确认，未接入的工具应显示无法核对，不必编一个总完成百分比。负责人看到的应是下一处需要推动的工作。
安排一次有人等待审批、有人处理失败的演练，检查依赖任务是否正确停住，重试是否只作用于失败步骤。若负责人能直接找到该找的人和该看的产物，这张进度页才比三个聊天窗口多解决了一件事。
- 01
提交配图任务
任务号、素材与尺寸
- 02
收到图片文件
记录真实产物位置
- 03
等设计确认
生成结束不等于可发布
不要把产物生成当成审批完成
合成任务展示逻辑，不提供任务调度或审批服务。
本地示例 · python
task = {"artifact": "launch-image.png", "run": "completed", "approval": "pending"}
if task["artifact"] and task["run"] == "completed":
status = "ready-to-publish" if task["approval"] == "approved" else "awaiting-design-review"
else:
status = "no-deliverable"
assert status == "awaiting-design-review"
print(status)预期结果：输出awaiting-design-review，不能显示可发布。
接入时的检查项
- 面板中的完成状态都有对应产物或验收记录，不靠助手自述。
- 一个子任务失败时依赖者显示等待原因，不持续重复启动。
- 人工决定后的状态变化可追踪，失联助手显示未知而非仍在正常推进。