03｜把任务计划变成程序能检查的数据

如果想获取全套课程资料，请关注微信公众号 「AI面包君」，回复 「课程资料」 即可领取。

“先找资料，再写文章”人能看懂，程序却还不知道资料有几组、谁等谁、每步怎样算完成。这一节把这句话变成一组有编号的任务，并亲手制造一次循环依赖。你会学会读一个任务对象，也能解释为什么坏计划必须在执行前被拦住。

1. 先读一个任务，不急着读整张图

项目用下面的 Step 表示一项子任务：

class Step(BaseModel):
    id: str = Field(pattern=r'^[a-z][a-z0-9_-]{0,31}$')
    title: str = Field(min_length=1, max_length=120)
    role: Literal['researcher', 'writer', 'reviewer']
    depends_on: list[str] = Field(default_factory=list)
    brief: str = Field(min_length=1, max_length=3000)
    acceptance: str = Field(min_length=1, max_length=1000)
    transport: Literal['local', 'a2a'] = 'local'

比如写作任务的 id 是 write，role 是 writer，depends_on 则是 ['research-product', 'research-audience']。这句话翻译过来就是：写作助手必须等两项资料任务都结束。

Literal 约束可选值，例如 role 不能随便填成 boss。Field(min_length=1) 不允许空要求。default_factory=list 每次产生一份新的空列表，避免多个任务共用同一个可变列表。

brief 描述怎么做，acceptance 描述交付时检查什么。当前项目会展示验收要求，但没有逐条自动判定它们是否满足；最终还需要查看产物。

用一场小型活动理解“依赖”

准备一场社团讲座时，海报需要讲座主题和时间，所以要等主题、时间确认；但搬椅子不一定要等海报设计完成。这时如果把所有事情写成一张顺序清单，就容易误以为排在后面的都必须等前面的。

依赖描述的是“缺少哪份结果就没法继续”。它比列表顺序更有用，因为两件互不需要对方结果的事可以同时做。对应我们的文章任务，产品资料和受众资料可独立整理，写作却需要把两份资料结合起来。

depends_on 保存的是所等待步骤的编号，不是角色名。写作可能依赖两个 researcher 步骤，只写 researcher 无法区分到底等哪一个。

把一个 Step 当成填好的任务卡

字段	写作步骤的例子	如果写错，谁受影响
id	write	依赖引用、产物索引会找不到它
title	撰写文章初稿	页面展示给人看的标题
role	writer	程序选择哪种执行方式
depends_on	两项资料的 id	决定什么时候具备执行条件
brief	依据资料撰写带来源的文章	告诉执行者本步要做什么
acceptance	包含步骤、限制和来源	给人检查交付物的依据
transport	local	决定在本地执行还是远程委派

id 像内部编号，title 像显示名称。你把标题从“文章初稿”改成“入门指南初稿”，依赖仍可以继续引用 write；如果把 id 改了，引用它的地方也要一起改。设计时把编号和标题分开，就是为了避免改一句展示文案就破坏任务关系。