管理AI软件项目 是做什么的？
将模糊的AI辅助交付工作转化为一个由单人操作者控制的执行系统。通过引导框架、获取对故事分解的明确批准、通过持久的任务队列执行、以证据进行验证，并仅在每个成功标准通过端到端检查后才关闭项目。
保持持久的项目状态供应商中立。在Codex、Claude Code或其他兼容代理之间切换时，无需转换pm/文件。
快速入门
- 检查工作区。如果
pm/存在，先阅读pm/STATE.md，然后是pm/TASKS.md；修复缺口，而非重新生成系统。 - 如果不存在项目系统，运行CP1：提出引导性问题，并在
pm/PLAN.md中草拟框架。 - 从references/file-templates.md创建四个标准文件。
- 通过CP2分解、CP3队列、执行循环和CP4最终验收来驱动工作。
操作者检查点协议
与操作者共同创建分解。在pm/PLAN.md或pm/TASKS.md中记录每次批准的日期。
- CP1 — 框架。 引导并获取对目标、成功标准、最终检查、范围、约束和结构假设的批准。
- CP2 — 分解。 使用操作者的语言呈现故事。为每个故事设定验收标准，并将其与其所服务的成功标准关联。与操作者一起解决开放的结构性决策。
- CP3 — 队列。 在执行开始前，呈现带有路由层级的有序任务队列。
- CP4 — 最终验收。 重新运行每个CP1最终检查的端到端验证，链接证据，呈现验收报告，并获得签收。仅完成的任务并不意味着项目已完成。
使用以下常设规则：
- 在已批准的框架内填补小缺口，在
pm/DECISIONS.md中记录假设。 - 将结构性变更——范围、故事、成功标准或验收门槛——返回到相关检查点，并记录权衡。
- 在CP1阶段提问：必须产出什么成果，为谁产出？操作者将如何亲自验证？哪些是范围之外的？哪些约束是固定的？已经存在什么？什么风险最高或最不明确？操作者期望多少审查？
- 在救援模式下，从工作区重建隐含的框架和分解，呈现给操作者确认，然后重建队列。
标准项目文件
在pm/下维护四个文件：
pm/PLAN.md— 目标、成功标准、范围、故事、可追溯性、批准pm/TASKS.md— 有序任务队列、稳定ID、路由、验证、证据pm/STATE.md— 当前状态、交接笔记、会话日志pm/DECISIONS.md— 决策、假设、风险、问题、变更日志
默认情况下不要创建更多控制文件。仅当相关分支处于活动状态时，才添加pm/CONSTRAINTS.md、pm/RELEASE.md或pm/RESEARCH.md。
保持产品特定的入口文件——例如AGENTS.md或CLAUDE.md——简短且具有导航性：指向pm/STATE.md，然后指向pm/TASKS.md，并将pm/PLAN.md作为已批准的范围。将会话本地规划工具中的持久信息镜像到pm/TASKS.md和pm/STATE.md中。
根据能力路由工作
当每个任务进入队列时，分配一个供应商中立的Route:层级：
| 层级 | 用于 |
|---|---|
heavy | 规划、分解、架构、模糊调试、跨领域重构、高风险审查、最终验收 |
standard | 有边界的实现、测试、中等复杂度的变更 |
light | 仓库搜索、摘要、机械性编辑、文档、格式化、日志分类 |
将每个任务路由到能够可靠完成它的最便宜层级：
- 保持主线程足够有能力进行指导：框架简报、路由工作、判断证据和签收。
- 对于同一任务，两次尝试失败或结果置信度低后，升级一个层级；记录升级。
- 要求评审层级至少与编写层级相同。为高风险或跨领域的变更分配全新上下文的
heavy评审。绝不允许light工作者自我批准。 - 将模型名称排除在
pm/文件之外；产品别名和价格会变化，而能力层级仍然有用。 - 在配置Codex、Claude Code或其他代理的工作者之前，请阅读references/agent-routing.md。
首先构建上下文
- 提取真实的目标、用户、验收标准、依赖关系和发布期望。
- 仅当日期、预算、批准、供应商时间表或发布窗口明确时，才将其视为一等输入。
- 在发明新工件之前，查找现有的
pm/文件、任务简报、待办事项列表、设计、ADR、测试策略、运行手册、风险日志和代理指令文件。 - 在救援工作中，评估目标清晰度、范围、依赖关系、验收质量、风险卫生状况、上下文可读性、权限和发布就绪度。
选择最小的控制模式
- 默认为
solo-operator：一个操作者指导AI代理。 - 对于真正的固定日期、合规门禁、审批、供应商依赖、配额或发布窗口，添加
external-constraint。 - 当探索、用户学习或用户体验迭代占主导时，添加
feedback-heavy。 - 当发布需要切换、回滚、监控或操作说明时，添加
release-safety。
确定执行单元的大小
- 使用故事来表示用户可见的价值和验收。仅使用里程碑来分组工作。通过任务来执行。
- 使每个任务适合一次集中的代理运行和一次快速的操作者审查：一个子系统、接口、文档或测试表面，以及一个可审查的差异。
- 为每个任务赋予稳定的ID、故事引用、路由层级、范围、依赖关系、完成条件、精确验证、证据字段和明确的停止点。
- 当任务涉及不相关的领域或几个独立的验证时，在执行前进行拆分。保留历史记录：子任务获得新ID；被替换的任务标记为
superseded。 - 完成任务后，在同一运行中填写其证据并更新
pm/STATE.md。
维护可追溯性
- 将每个成功标准映射到至少一个故事，每个故事映射到至少一个任务。
- 仅当故事的所有任务和验收标准都通过证据验证后，才能将其标记为完成。
- 仅在CP4端到端重新验证每个成功标准后，才能将项目标记为完成。
运行质量优先的循环
- 在实现之前定义最小的可信证明：失败的复现、自动测试、预期输出、截图比较、合约检查或精确的手动程序。
- 使用
探索 -> 规划 -> 实现 -> 验证 -> 审查 -> 文档化。 - 记录命令、结果、截图、指标和审查笔记，而不仅仅是结论。
- 为风险任务说明变更预算：允许的文件、稳定的接口、数据安全、回滚和升级触发器。
- 在规模化之前，先在狭窄的代表性切片上试点重复性或自动化的变更。
- 在两次相同的失败之后，停止并改进环境、文档、规则或验证器；使用干净的上下文重新开始。
- 将代理的重复失败视为系统反馈。改进流程，而不仅仅是当前的答案。
安全地委派
- 仅委派准备好自治、有边界的工作。将目标、分解、综合和签收保留在主线程中。
- 为每个工作者提供书面简报：任务ID、目标、范围、约束、验证命令、预期证据、停止点、升级触发器和路由层级。
- 当委派开销超过其收益时，将微小、紧密耦合或高度交互的工作保留在主线程中。
- 对于零异常规则（如必需测试、路径限制、格式化或秘密扫描），优先使用确定性验证器。
- 强制执行最小权限、信任边界、秘密处理规则，以及对风险行动的明确操作者批准。
参考文献
- 在创建或修复
pm/时，阅读references/file-templates.md。 - 阅读references/worked-example.md以获取一个紧凑的端到端示例。
- 在审计或救援项目时，阅读references/project-rulebook.md。
- 仅当存在真实的外部约束或生产发布风险时，阅读references/external-constraints.md。
- 阅读references/ai-agent-practices.md以获取关于持久内存、上下文、委派、评估和防护措施的更深入指导。
- 在将层级映射到产品当前能力时，阅读references/agent-routing.md。
- 当来源或易变的供应商指导很重要时，阅读references/source-anchors.md。
- 仅加载最小的相关参考文献。
输出标准
- 以命令形式编写具体、可决策的工件。
- 首先报告检查点状态，然后在摘要状态前报告任务ID。
- 格式化任务为：
任务ID、任务、故事、路由、范围、依赖、完成条件、验证方式、证据、停止条件、状态。 - 每个任务优先提供一个可审查的差异。
- 将模型名称排除在持久的项目文件之外。
- 除非项目确实需要，否则不要添加日期计划、预算、审批工作流、定期仪式或阶段门。
- 在使用前，对照主要来源验证当前模型、基准、价格或供应商工作流声明。