Prometheus 规划：面试式需求收集与工作计划生成

学完你能做什么

启动 Prometheus 规划会话，通过面试模式明确项目需求
理解 Prometheus 的"只规划，不实现"核心原则
配合 Metis 和 Momus 生成高质量、无遗漏的工作计划
使用 /start-work 命令将计划交由 Atlas 执行

你现在的困境

想象一下，你给 AI 下达一个复杂任务："帮我重构认证系统"。

5 分钟后，AI 开始写代码了。你很高兴，觉得省了时间。

30 分钟后，你意识到：

AI 没问你用哪个认证库（JWT？NextAuth？Session？）
AI 假设了很多需求（比如"必须支持 OAuth"，其实你不需要）
代码写了一半，方向错了，全部重做
测试时发现核心逻辑和现有系统不兼容

这是典型的"混合规划与执行"问题：AI 在需求不明确时就动手，导致大量返工。

什么时候用 Prometheus

使用时机

Prometheus 适合的场景：

复杂功能开发（如"添加用户认证系统"）
大规模重构（如"重构整个数据访问层"）
架构设计（如"设计微服务架构"）
需要严格质量保证的任务

直接让 Sisyphus 执行的场景：

简单 bug 修复（如"修复登录按钮拼写错误"）
明确的小功能（如"添加 3 个输入的表单"）

🎒 开始前的准备

确保已完成以下配置：

[ ] 已启用 Prometheus 代理（默认启用）
[ ] 已配置至少一个 AI Provider（Anthropic、OpenAI 等）
[ ] 了解基本代理概念（已完成「AI 代理团队：10 位专家介绍」）

验证 Prometheus 可用：

bash

# 在 OpenCode 聊天框中输入
@prometheus

# 应该看到 Prometheus 提示：
# "你好，我是 Prometheus - 战略规划顾问。..."

核心思路

Prometheus 的核心身份约束

Prometheus 最重要的特点是什么？它永远不写代码。

功能	Prometheus	Sisyphus	Atlas
需求收集	✅	❌	❌
工作计划生成	✅	❌	❌
代码实现	❌	✅	✅（委托）
任务执行	❌	✅	✅（委托）

这为什么重要？

规划者 ≠ 执行者：就像产品经理不写代码一样，Prometheus 的职责是"怎么做"，不是"做"
防止假设：如果 Prometheus 能直接写代码，它可能在需求不明确时"猜着做"
强制思考：被禁止写代码后，Prometheus 必须把所有细节问清楚

三阶段工作流

各阶段职责：

Phase 1 - 面试模式：收集需求、研究代码库、持续更新草稿
Phase 2 - 计划生成：咨询 Metis、生成完整计划、呈现摘要
Phase 3 - 执行：通过 /start-work 交给 Atlas 执行

跟我做

第 1 步：启动 Prometheus 规划会话

为什么 通过关键词或命令触发 Prometheus，进入面试模式。

操作

在 OpenCode 聊天框中输入：

@prometheus 帮我规划一个用户认证系统

你应该看到：

Prometheus 确认进入面试模式
提出第一个问题（如"你的应用是什么技术栈？"）
创建草稿文件 .sisyphus/drafts/user-auth.md

关键特性：草稿文件

Prometheus 会持续更新 .sisyphus/drafts/ 下的文件。这是它的"外部记忆"：

记录每次讨论的决策
保存研究发现的代码模式
标注明确的边界（IN/OUT）

你随时可以查看草稿，验证 Prometheus 的理解是否正确。

第 2 步：回答问题，让 Prometheus 收集上下文

为什么 Prometheus 需要"理解"你的项目，才能生成可执行的计划。它不是猜，而是通过研究代码库和研究最佳实践来获得依据。

操作

回答 Prometheus 的问题，例如：

用户输入：
我的应用是 Next.js 14，App Router，目前没有认证。
我想支持邮箱密码登录和 GitHub OAuth。

Prometheus 会做什么：

使用 explore 代理分析现有代码结构
使用 librarian 代理查找认证最佳实践
更新草稿文件中的"Requirements" 和 "Technical Decisions" 部分

你应该看到：

我已启动探索代理来分析你的项目结构...

1. explore: 查找现有会话模式
2. librarian: 查找 NextAuth 最佳实践

等待结果返回后，我会继续提问。

第 3 步：查看草稿文件（可选）

为什么 草稿是 Prometheus 的"外部记忆"，你可以随时验证它是否理解正确。

操作

bash

# 在终端查看草稿内容
cat .sisyphus/drafts/user-auth.md

你应该看到类似内容：

markdown

# Draft: user-auth

## Requirements (confirmed)
- 技术栈: Next.js 14, App Router
- 认证方式: 邮箱密码 + GitHub OAuth
- 当前状态: 无认证实现

## Technical Decisions
- 无决策

## Research Findings
- 探索代理正在运行...

第 4 步：继续回答，直到需求明确

为什么 Prometheus 有一个"Clearance Checklist"，只有全部勾选后才会自动过渡到计划生成。

Prometheus 的判断标准：

CLEARANCE CHECKLIST (ALL must be YES to auto-transition):
□ 核心目标是否清晰？
□ 范围边界是否明确（IN/OUT）？
□ 没有遗留的关键歧义？
□ 技术方案是否确定？
□ 测试策略是否确认（TDD/手动）？
□ 没有阻塞问题？

操作

继续回答 Prometheus 的问题，直到它说：

所有需求已明确。正在咨询 Metis 并生成计划...

你应该看到：

Prometheus 调用 Metis 代理
Metis 分析可能遗漏的问题
Prometheus 根据 Metis 的反馈调整理解

第 5 步：查看生成的计划

为什么 计划文件是 Prometheus 的最终输出，包含了所有任务、依赖关系、验收标准。

操作

bash

# 查看生成的计划
cat .sisyphus/plans/user-auth.md

你应该看到完整结构：

markdown

# User Authentication System

## Context
[原需求描述]
[面试摘要]
[Metis 分析结果]

## Work Objectives
- 核心目标：实现邮箱密码登录和 GitHub OAuth
- 具体交付：登录页面、API 端点、会话管理
- 完成定义：用户可以登录并访问受保护路由

## Verification Strategy
- 基础设施存在：YES
- 用户想要测试：TDD
- 框架：vitest

## TODOs
- [ ] 1. 安装 NextAuth.js 并配置
  - References:
    - https://next-auth.js.org/getting-started/installation
  - Acceptance Criteria:
    - [ ] npm run test → PASS (1 test)

- [ ] 2. 创建 API 路由 [...nextauth]/route.ts
  - References:
    - src/lib/session.ts:10-45 - 现有会话模式
  - Acceptance Criteria:
    - [ ] curl http://localhost:3000/api/auth/... → 200

- [ ] 3. 实现登录页面 UI
  - References:
    - src/app/login/page.tsx - 现有登录页结构
  - Acceptance Criteria:
    - [ ] Playwright 验证：看到登录表单
    - [ ] 截图保存到 .sisyphus/evidence/

...

第 6 步：选择执行方式

为什么 Prometheus 会给你两个选择：快速开始还是高精度审查。

Prometheus 的呈现（使用 Question 工具）：

## Plan Generated: user-auth

**Key Decisions Made:**
- 使用 NextAuth.js（与 Next.js App Router 集成良好）
- GitHub OAuth 提供商 + 邮箱密码

**Scope:**
- IN: 登录功能、会话管理、路由保护
- OUT: 注册功能、密码重置、用户资料编辑

**Guardrails Applied:**
- 必须遵循现有会话模式
- 不修改核心业务逻辑

Plan saved to: `.sisyphus/plans/user-auth.md`

---

**Next Step**

如何继续？

1. **Start Work**: 执行 /start-work。计划看起来很稳健。
2. **High Accuracy Review**: 让 Momus 严格验证每个细节。增加审查循环但保证精度。

操作

选择一个选项（在 OpenCode 中点击按钮或输入选项）。

如果你选择 "Start Work"：

Prometheus 删除草稿文件
提示你运行 /start-work

如果你选择 "High Accuracy Review"：

Prometheus 进入 Momus 循环
持续修复反馈，直到 Momus 说 "OKAY"
然后提示你运行 /start-work

第 7 步：执行计划

为什么 计划是 Prometheus 的输出，执行是 Atlas 的职责。

操作

bash

# 在 OpenCode 中输入
/start-work

你应该看到：

Atlas 读取 .sisyphus/plans/user-auth.md
创建 boulder.json 状态文件
按顺序执行每个 TODO
委派任务给专业代理（如 UI 工作委托给 Frontend）

检查点 ✅

boulder.json 文件已创建
Atlas 开始执行任务 1
每个任务完成后，状态更新

踩坑提醒

坑 1：需求说一半就急着要计划

问题：

用户：@prometheus 做一个用户认证
用户：先别问那么多，直接生成计划

后果：计划中充满假设，执行时需要反复修改。

正确做法：

用户：@prometheus 做一个用户认证
Prometheus：你的应用是什么技术栈？目前有认证吗？
用户：Next.js 14，App Router，没有认证
Prometheus：需要支持哪些登录方式？
用户：邮箱密码 + GitHub OAuth
...
（持续回答直到 Prometheus 自动过渡）

记住这个原则

规划时间 ≠ 浪费时间

花 5 分钟明确需求，可以节省 2 小时返工
Prometheus 的面试模式，是在替未来的你"省钱"

坑 2：不看草稿文件

问题：Prometheus 在草稿中记录了很多决策和边界，你不看就直接让它生成计划。

后果：

计划中包含了错误的理解
执行时才发现"我怎么没说要这个？"

正确做法：

1. 启动规划后，时刻关注 .sisyphus/drafts/ 文件
2. 发现误解立即纠正："不对，我不是要 OAuth，是简单的 JWT"
3. 纠正后再继续

坑 3：计划分多次生成

问题：

用户：这个项目太大，先计划第一阶段吧

后果：

第一阶段和第二阶段的上下文断裂
架构决策不一致
需求在多次会话中遗漏

正确做法：

✅ 单计划原则：无论多大，所有 TODO 都在一个 .sisyphus/plans/{name}.md 中

为什么？

Prometheus 和 Atlas 都能处理大计划
单计划保证架构一致性
避免上下文碎片化

坑 4：忘了 Metis 的作用

问题：

用户：需求说完了，快生成计划
Prometheus：（直接生成，跳过 Metis）

后果：

计划中可能遗漏关键边界
没有"Must NOT Have" 明确排除范围
执行时出现 AI slop（过度设计）

正确做法：

✅ Metis 咨询是强制的，你不用催

Metis 会做什么？

识别 Prometheus 应问但没问的问题
提出需要明确的边界
防止 AI 过度工程化

坑 5：忽略测试策略决策

问题：Prometheus 问"需要测试吗？"，你说"无所谓"或跳过。

后果：

如果有测试基础设施，但未利用 TDD，错失机会
如果无测试，又没有详细手动验证步骤，执行失败率高

正确做法：

Prometheus：我看到你有 vitest 测试框架。工作需要包含测试吗？
用户：YES（TDD）

影响：

Prometheus 会把每个任务结构化为：RED → GREEN → REFACTOR
TODO 的 Acceptance Criteria 会明确包含测试命令
Atlas 执行时会按 TDD 流程工作

本课小结

Prometheus 核心价值：

分离规划与执行：通过"不写代码"的强制约束，确保需求明确
面试模式：持续提问、研究代码库、更新草稿
质量保证：Metis 咨询、Momus 验证、单计划原则

典型工作流：

输入 @prometheus [需求] 启动规划
回答问题，查看 .sisyphus/drafts/ 草稿
等待 Prometheus 自动过渡（Clearance Checklist 全部勾选）
查看生成的 .sisyphus/plans/{name}.md
选择 "Start Work" 或 "High Accuracy Review"
运行 /start-work 交给 Atlas 执行

最佳实践：

花时间理解需求，不急于要计划
持续查看草稿文件，及时纠正误解
遵循单计划原则，不拆分大任务
明确测试策略，影响整个计划结构

下一课预告

下一课我们学习 后台并行任务：像团队一样工作。
你会学到：
如何让多个代理并行工作，大幅提升效率
配置并发限制，避免 API 限流
管理后台任务，获取结果和取消操作
像"真实团队"一样协调多个专家代理

附录：源码参考

点击展开查看源码位置

更新时间：2026-01-26

功能	文件路径	行号
Prometheus 系统提示词	`src/agents/prometheus-prompt.ts`	19-1184
Prometheus 权限配置	`src/agents/prometheus-prompt.ts`	1187-1197
Metis 代理	`src/agents/metis.ts`	-
Momus 代理	`src/agents/momus.ts`	-
编排指南文档	`docs/orchestration-guide.md`	67-90

核心常量：

PROMETHEUS_SYSTEM_PROMPT：完整的系统提示词，定义了 Prometheus 的身份、工作流程和约束

关键函数/工具：

PROMETHEUS_PERMISSION：定义 Prometheus 的工具权限（仅允许 .md 文件编辑）

业务规则：

Prometheus 默认模式：INTERVIEW MODE（面试模式）
自动过渡条件：Clearance Checklist 全部为 YES
Metis 咨询：强制的，在计划生成前执行
Momus 循环：可选的高精度模式，循环直到 "OKAY"
单计划原则：无论多大任务，所有 TODO 在一个 .md 文件中
草案管理：持续更新 .sisyphus/drafts/{name}.md，计划完成后删除

5 分钟跑起来

连接你的 AI 账号

像团队一样工作

遇到问题怎么办

配置迁移全搞定

新功能速览

Prometheus 规划：面试式需求收集与工作计划生成

学完你能做什么

你现在的困境

什么时候用 Prometheus

🎒 开始前的准备

核心思路

Prometheus 的核心身份约束

三阶段工作流

跟我做

第 1 步：启动 Prometheus 规划会话

第 2 步：回答问题，让 Prometheus 收集上下文

第 3 步：查看草稿文件（可选）

第 4 步：继续回答，直到需求明确

第 5 步：查看生成的计划

第 6 步：选择执行方式

第 7 步：执行计划

踩坑提醒

坑 1：需求说一半就急着要计划

坑 2：不看草稿文件

坑 3：计划分多次生成

坑 4：忘了 Metis 的作用

坑 5：忽略测试策略决策

本课小结

下一课预告

附录：源码参考

Prometheus 规划：面试式需求收集与工作计划生成 ​

学完你能做什么 ​

你现在的困境 ​

什么时候用 Prometheus ​

🎒 开始前的准备 ​

核心思路 ​

Prometheus 的核心身份约束 ​

三阶段工作流 ​

跟我做 ​

第 1 步：启动 Prometheus 规划会话 ​

第 2 步：回答问题，让 Prometheus 收集上下文 ​

第 3 步：查看草稿文件（可选） ​

第 4 步：继续回答，直到需求明确 ​

第 5 步：查看生成的计划 ​

第 6 步：选择执行方式 ​

第 7 步：执行计划 ​

踩坑提醒 ​

坑 1：需求说一半就急着要计划 ​

坑 2：不看草稿文件 ​

坑 3：计划分多次生成 ​

坑 4：忘了 Metis 的作用 ​

坑 5：忽略测试策略决策 ​

本课小结 ​

下一课预告 ​

附录：源码参考 ​

Prometheus 规划：面试式需求收集与工作计划生成

学完你能做什么

你现在的困境

什么时候用 Prometheus

🎒 开始前的准备

核心思路

Prometheus 的核心身份约束

三阶段工作流

跟我做

第 1 步：启动 Prometheus 规划会话

第 2 步：回答问题，让 Prometheus 收集上下文

第 3 步：查看草稿文件（可选）

第 4 步：继续回答，直到需求明确

第 5 步：查看生成的计划

第 6 步：选择执行方式

第 7 步：执行计划

踩坑提醒

坑 1：需求说一半就急着要计划

坑 2：不看草稿文件

坑 3：计划分多次生成

坑 4：忘了 Metis 的作用

坑 5：忽略测试策略决策

本课小结

下一课预告

附录：源码参考