让 Claude Code 担任项目经理——PM Layer 设计模式

这篇文章探索了一个新颖的想法：不把 Claude Code 当作"写代码的工具"，而是让它充当"项目经理（PM）"，自主管理开发任务的分解、优先级排序、依赖关系跟踪和进度汇报。

作者设计了一个"PM Layer"抽象层：通过结构化的 Prompt 模板，让 Claude Code 读取 TASKS.md 文件，自动判断当前应执行的任务，执行后更新任务状态，并生成进度报告。

这种设计让 AI coding tool 从"被动响应工具"转变为"主动任务管理者"。作者分享了自己在实际项目中使用 PM Layer 的经验：任务分解的准确率、AI 判断错误的场景、以及需要人工干预的节点。对希望探索 AI Agent 自主工作流的开发者具有参考意义。

大多数开发者把 Claude Code 当作"写代码的助手"——你给它一条指令，它执行，你再给下一条。整个流程是线性的、被动的，人类始终是那个决定"下一步做什么"的人。但 Zenn 作者 yamapiiii 提出了一个更有野心的设计模式：**PM Layer**——让 Claude Code 本身承担项目经理角色，自主决定做什么、按什么顺序做、完成后汇报什么。

PM Layer 的核心思想

PM Layer 的名字来源于"Project Management Layer"，它是一个 Prompt 抽象层，架设在你的开发目标和 Claude 的执行能力之间。你不再直接告诉 Claude"写这个函数"或"修那个 bug"，而是告诉它一个高层目标，然后让它自行规划和推进。

这个层赋予 Claude Code 三个传统 PM 职责：

1. 任务分解（WBS，工作分解结构）

Claude 读取你的目标描述，将其拆解为可执行的子任务，自动生成 TASKS.md 文件。每个任务包含唯一 ID、描述、优先级、依赖关系和当前状态。这类似于敏捷开发中的 Sprint Backlog，但由 AI 来生成和维护。

2. 优先级与依赖管理

拆解任务之后，Claude 不是随机选一个开始做，而是分析任务间的依赖关系——比如"写测试"必须在"写代码"之后，"部署"必须在"通过测试"之后——并据此决定执行顺序。遇到依赖未满足的任务，它会自动跳过，选择当前可执行的最高优先级任务。

3. 进度追踪与汇报

每完成一个任务，Claude 更新 TASKS.md 中的状态字段，并生成一段简短的进度摘要：完成了什么、下一步是什么、有没有遇到障碍。这让你随时可以中断、查看进度，再继续。

技术实现：轻量但关键

实现 PM Layer 的技术并不复杂，作者的核心是两个组件：

结构化 System Prompt：这是 PM Layer 的"灵魂"。它告诉 Claude：「在每次执行任务之前，先读取 TASKS.md；选择满足以下条件的任务执行：（1）状态为待处理，（2）所有依赖任务已完成，（3）优先级最高；执行完毕后，更新该任务的状态，并附上简短的执行摘要。」

TASKS.md 文件约定：统一的文件格式让 Claude 能可靠地读写任务状态，也让人类能一眼看懂进度。格式示例如下：

## [TASK-001] 用户认证模块
- 状态: ✅ 完成
- 依赖: 无
- 优先级: P0
- 摘要: 实现了 JWT 登录逻辑，通过全部单元测试

## [TASK-002] 数据库迁移脚本
- 状态: 🔄 进行中
- 依赖: TASK-001
- 优先级: P1

## [TASK-003] 邮件通知服务
- 状态: ⏳ 待处理
- 依赖: TASK-001, TASK-002
- 优先级: P2

两周实验：诚实的结果

作者在一个中等规模项目（约 15 个功能模块、前后端各有独立任务）中使用 PM Layer 实验了两周。结果是真实的，有成功也有局限：

成功之处：整体任务推进顺畅，80% 的任务被正确分解和排序。在没有干预的情况下，Claude 可以连续完成 3-5 个相互关联的任务，减少了大量"下一步做什么"的沟通来回。对于有清晰依赖链的功能（比如"先建表，再写 API，再写前端"），PM Layer 表现尤为稳定。

局限之处：首先是隐式依赖的判断弱。有些依赖不在代码层面，而在认知层面——比如"在写代码之前，你需要先决定整体架构风格"。这类依赖 Claude 无法自动识别，需要人工在 TASKS.md 中显式标注。其次，AI 有偏向简单任务的倾向：当两个任务优先级相同时，Claude 更容易选择描述更具体、看起来更"可做"的任务，而非真正最重要的那个。第三，任务描述越模糊，偏差越大——"优化性能"这类描述会被 Claude 随意解释，有时做的事情完全偏离原意。

人工干预的节点设计

PM Layer 不是"设置后忘记"，作者建议在以下三类节点保留强制人工确认：

**重大架构决策**：涉及技术栈选择、模块边界设计等高层决策
**外部 API 或第三方集成**：这类任务风险高、调试成本高，AI 容易写出能跑但有隐患的代码
**任何涉及生产环境或生产数据的操作**：这是红线，无论 AI 多自信，都必须人工审查

这个设计哲学是：让 AI 管理节奏和顺序，让人类把守关键决策点。

从 PM Layer 看 Agentic AI 的演进方向

PM Layer 本质上是一种"AI 管理 AI"的模式——用一个 AI 的项目管理能力，驱动同一个（或另一个）AI 的代码执行能力。这并不是什么遥远的未来概念，而是今天就可以用 System Prompt 实现的工程实践。

这与 Anthropic 正在推进的方向高度契合。Claude Code 的最新版本已经内置了更强的任务记忆和上下文保持能力，未来的 Agent 基础设施很可能会原生支持类似 PM Layer 的任务图管理。

更长远地看，**AI PM + AI Developer** 的协作栈，可能成为独立开发者和小型团队的标配工具链。一个人，通过定义高层目标和关键约束，让 AI 自主完成绝大多数执行性工作——这不是取代开发者，而是把开发者从"逐条执行指令"解放出来，让人专注于真正需要人类判断力的决策。

PM Layer 今天还是一个需要手工搭建的实验性模式。但它证明了一件事：AI 的边界，常常不在于模型的能力，而在于我们为它设计了什么样的工作流。