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 必須把所有細節問清楚

三階段工作流

mermaid

flowchart LR
    A[使用者輸入需求] --> B[Phase 1: 面試模式]
    B -->|需求明確?| C[Phase 2: 計畫生成]
    C --> D[Metis 諮詢]
    D -->|需要高精度?| E[Momus 循環驗證]
    E -->|計畫完善| F[生成 .sisyphus/plans/*.md]
    C -->|不需要高精度| F
    F --> G[/start-work 執行]

各階段職責：

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，計畫完成後刪除

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：忽略測試策略決策

本課小結

下一課預告

附錄：原始碼參考