工作原理
从一个目标到一份能跟进的计划
六个阶段，循环往复。你说出想要什么，PO 负责规划、给任务排序、回忆项目已知的内容、执行工作、检查成果，并保存学到的东西。每个阶段下面都可以展开技术细节。
规划 → 排序 → 回忆 → 执行 → 验证 → 学习，然后回到回忆。第 6 阶段保存的内容，就是下一个计划在第 3 阶段回忆起的内容。
循环
循环，逐个阶段
向下滚动：每幅图都按产品界面的样子绘制。示例是一次团队周末活动。
第 1 阶段，共 6 个
你说出想要什么，就得到一份计划
你用一句话描述想要的结果，助手把它变成带任务的计划。每个任务有若干步骤，每个步骤都写明如何检查它已完成。
幕后细节
结果会被保存为一个带优先级和约束的计划，再拆成任务。每个任务写明它依赖什么，并列出自己的步骤。每个步骤都带着证明它已完成的检查。
计划、任务和步骤保存为数据，而不是聊天里的自由文本。界面和执行器读取的是同样的状态。
plan(action: "create", title, description, priority: 8, constraints: [{ constraint_type: "performance", … }])task(action: "create", plan_id, title, depends_on: [task_id], steps: [{ description, verification }])- 计划状态：draft, approved, in_progress, completed, cancelled。
- 约束类型：performance, security, style, compatibility, other。
- code(action: "plan_implementation", auto_create_plan: true) 会根据代码图谱起草一份计划。
第 2 阶段，共 6 个
互不依赖的任务放在一起
PO 给任务排序。一个任务只等待它所需的任务，其余的都可以现在一起开始。
幕后细节
只有当一个任务依赖的所有任务都完成后，它才会开始。PO 把这些联系变成批次：第 1 批包含所有没有未满足前提的任务，第 2 批包含第 1 批解锁的任务，以此类推。
同一批次里的任务互相独立，所以同时运行。最长的依赖链，即关键路径，决定了批次数量的下限。
plan(action: "get_waves", plan_id)plan(action: "get_critical_path", plan_id)- plan(action: "get_dependency_graph") 返回任务的有向无环图（DAG）。
- task(action: "get_next") 返回下一个未被阻塞的任务，优先级最高的在前。
- 恢复一次运行时，会重新计算批次，已完成的批次会被跳过。
第 3 阶段，共 6 个
助手先查找项目已经知道的内容
每个任务开始之前，助手会先读取适用的笔记和决策，所以不会把同样的问题再问一遍。
幕后细节
任务开始前，助手读取项目记忆：笔记（警告、准则、模式）、带理由的决策，以及对于代码项目，它将改动的文件周围的代码。按含义搜索会先找到最接近的匹配。
接着 PO 顺着笔记之间的连线查找。一条与问题不直接匹配的笔记也可能出现，因为与它紧密相连的另一条笔记匹配了。连线每经过一步就减弱一次，已经淡去的笔记不会被选中。
note(action: "search_semantic", query, project_slug)decision(action: "search_semantic", query)admin(action: "search_neurons", query, max_hops: 2)note(action: "get_context", entity_type: "file", entity_id)- 扩散激活的默认值：20 条起始笔记、2 跳、信号每跳减半、10 条结果。
- 结果名额中有 40% 留给通过突触（synapse）到达的笔记。
- 传播得分 = 父级得分 x 突触权重 x 笔记能量 x 衰减。
第 4 阶段，共 6 个
助手一组一组地完成任务
每个任务交给各自的助手。一组里的任务同时运行，下一组等待。
幕后细节
plan(action: "run") 在独立的 git 分支上启动执行器。对每个批次，它为每个符合条件的任务启动一个代理会话，并在上限（默认 4 个）之内并行运行。
每个任务都会得到一条根据项目记忆构建的提示：它的描述、步骤和约束、与它相关的笔记、匹配的角色和技能，以及之前批次所做工作的摘要。一个守卫会监视会话的空闲时间、重复调用和超时，并在代理跑偏时发出提示。
plan(action: "run", plan_id, cwd, project_slug)plan(action: "run_status", plan_id)- 任务会根据标签、步骤和文件被归为简单、复杂或创意型。这个类型决定它的时间上限和成本预算。
- 简单：600 秒和 $0.50。复杂：3600 秒和 $2.00。创意：1800 秒和 $1.00。
- 运行记录会被保存，所以重启后可以恢复一次运行。plan(action: "cancel_run") 会停止一次运行。
第 5 阶段，共 6 个
检查通过，一组才算完成
下一组开始之前，PO 会检查工作成果：步骤必须全部关闭，改动里不能留有敏感文件。对于代码项目，PO 还会检查它是否仍能构建。
幕后细节
一个批次结束时，执行器会在下一批开始之前验证它：检查代理是否产生了提交、每个步骤是否已完成或跳过、项目能否构建，以及差异中是否有敏感文件。
运行本身是一个状态机。一个生命周期流程从 approved 进入 executing，再进入 post_run，每次转换都需要明确的触发。代理失败或超时的任务默认会重试一次，并把错误作为上下文。
protocol(action: "transition", run_id, trigger: "child_completed")step(action: "get_progress", task_id)- 构建检查：cargo check、npm run build 或 go build ./...，按检测到的语言选择。
- 被拒绝的敏感文件：.env、credentials.json、*.pem、*.key 及类似文件。
- 测试是可选项，默认关闭。plan-runner-reviewed 增加了一个供人审阅的 awaiting_review 状态。
第 6 阶段，共 6 个
学到的东西留给下一次
工作完成后，决定了什么、学到了什么，都会写回项目记忆。下一个计划就从这里开始。
幕后细节
任务完成时，执行器无需调用模型就会写回：把提交与任务和计划关联起来，根据 git 日志创建一条上下文笔记，并把决策关联到它们影响的文件。
助手补充只有它才知道的内容：带备选方案的决策、警告、模式。一起使用的笔记会越走越近，从不使用的笔记会失去能量并变得过时。一条事件记录（episode）会记下请求、经过的状态路径和结果。下一个计划从第 3 阶段开始，带着这一切。
decision(action: "add", task_id, rationale, alternatives)note(action: "create", note_type: "gotcha", content, anchors)episode(action: "collect", run_id, project_id)admin(action: "reinforce_neurons", note_ids)- 过时程度随距上次活动的时间增长，速度取决于笔记类型。note(action: "confirm") 会将它重置。
- 技能从紧密相连的笔记聚类中浮现（admin(action: "detect_skills")）。
分工
谁做什么
PO 处理琐碎的运转，助手可以专心做工作。
PO 自动完成，无需你开口
- 把任务分成若干组，并启动助手。
- 检查每一组：步骤已关闭、没有敏感文件，对于代码项目还要检查构建。
- 把改动关联到任务，并写一条记录所发生情况的笔记。
- 把每次运行的改动保存在各自的 git 分支上。
- 记录哪些角色和技能提供了帮助。
助手通过它的工具完成
- 开始之前先搜索笔记和决策。
- 创建计划、任务和步骤，并更新它们的状态。
- 保存决策，连同备选方案和影响范围。
- 写下警告、准则和模式，并关联到它们所涉及的内容。
- 一步一步推进一个流程。
入口
启动循环的三种方式
从你的 AI 工具
Claude Code、Cursor 或其他连接到 PO 的 AI 工具。你描述想要的结果，它负责规划、排序和回忆，最后保存它学到的东西。
从聊天
PO 内置的聊天与同一个助手对话。每条消息都会带上匹配的技能、适用的笔记和决策，以及正在进行的工作。
自行运行
计划可以在没人在场时运行。它按计划时间或在某个事件发生时启动，两次启动之间会有间隔。启动类型有 schedule、webhook、event 和 chat。
记忆
PO 记得你的决定和心得
笔记、决策以及它们之间的联系，都和你的项目放在一起。需要时，PO 会把它们找出来。向下滚动，看一份记忆如何生长。
虚构示例：一个小型活动项目。图中的名称只是示意，不是你的数据。颜色和形状与产品中的图谱一致。
第 1 步，共 5 步
你的文件变成圆点
PO 从项目里已有的内容开始：文档、表格、文件。每个文件是一个蓝色圆点。
第 2 步，共 5 步
计划和任务加入进来
计划和任务被加到同一张图里。每个任务都与它涉及的文件相连。
第 3 步，共 5 步
笔记和决策保持相连
学到的东西成为笔记，做出的选择成为决策。两者都与文件相连，彼此之间也相连。
第 4 步，共 5 步
相关的内容聚在一起
主题相同的内容会彼此靠近。项目的主要主题一目了然。
第 5 步，共 5 步
PO 顺着连线找到答案
你提出一个问题，PO 找出匹配的笔记（青色），再顺着连线找到相关内容（紫色），即使用词不同也能找到。
幕后：连线的名称
这些是产品图谱中各种连线的名称。使用 PO 并不需要了解它们。
- CONTAINS计划包含它的任务。
- IMPORTS一个文件使用另一个文件。
- AFFECTS任务涉及某个文件。
- CO_CHANGED经常一起修改的两个文件，从代码历史中看出。
- SYNAPSE笔记、决策和文件之间的连线。没人用的连线会逐渐淡去。
试一试
看助手如何借助 PO 工作
选一个请求。你会看到用平实语言写的回答，以及助手在幕后对 PO 发出的调用。点开一个调用，可以查看细节。
Two notes apply: the place must be close to a train station, and last year the menu had nothing vegetarian. I will write the plan around both.
The plan has 3 tasks in 2 waves. The shortlist and the date poll do not depend on each other, so they happen at the same time. Booking waits for both.
模拟演示：回答是预先写好的，不会连接任何服务器。调用及其参数是真实的。