pynbj1001 plan-ceo-review
总指挥专用任务审核框架
name: plan-ceo-review version: 2.0.0 description: | 总指挥专用任务审核框架。基于 gstack plan-ceo-review 提炼，适配 7 Agent 体系。 四种模式：EXPANSION / SELECTIVE / HOLD / REDUCTION。 核心理念：Boil the Lake（煮湖原则）。 触发场景：复杂任务（3+ 步骤）、战略决策、功能开发前规划。
触发场景
| 场景 | 是否触发 | 原因 |
|---|---|---|
| 复杂任务（3+ 步骤） | ✅ | 需要规划 |
| 战略决策 | ✅ | 需要审核 |
| 功能开发前 | ✅ | 需要范围挑战 |
| 简单问题 | ❌ | 过度设计 |
| 单文件编辑 | ❌ | 过度设计 |
核心理念
Boil the Lake（煮湖原则）
AI 让完整性成本接近零，所以要完整实现，而不是"差不多就行"
湖 vs 海：
- 湖 = 可以完全做到的事（100% 测试覆盖、完整错误处理、所有边界情况）
- 海 = 做不到的事（整个系统重写、多季度迁移、改动依赖库）
原则：
Lake → 煮它（完整实现）
Ocean → 标记超出范围，拆成多个 Lake
AI 时代的工作量压缩：
| 任务类型 | 传统团队 | AI + 技能 | 压缩比 |
|---|---|---|---|
| 样板代码 | 2 天 | 15 分钟 | ~100x |
| 测试编写 | 1 天 | 15 分钟 | ~50x |
| 功能实现 | 1 周 | 30 分钟 | ~30x |
| Bug 修复 + 回归 | 4 小时 | 15 分钟 | ~20x |
| 架构设计 | 2 天 | 4 小时 | ~5x |
反模式：
- ❌ "选 B 吧，覆盖 90% 价值但代码少" → 如果 A 只多 70 行，选 A
- ❌ "跳过边界处理省时间" → 边界处理在 AI 时代只花几分钟
- ❌ "测试后面再加" → 测试是最便宜的湖
四种模式
模式对比
| 维度 | EXPANSION | SELECTIVE | HOLD | REDUCTION |
|---|---|---|---|---|
| 目标 | 扩大范围 | 保持+扩展选项 | 严格审核 | 削减范围 |
| 适用 | 绿地项目 | 功能迭代 | Bug 修复 | 超过 15 文件 |
| 推荐姿态 | 热情推荐 | 中立展示 | 无 | 无 |
| 10x 检查 | 必须 | 作为选项 | 可选 | 跳过 |
| 理想状态 | 描述 | 不描述 | 不描述 | 不描述 |
| 复杂度问题 | "够大吗？" | "对吗+还有什么" | "太复杂吗？" | "最简是什么？" |
| 口味校准 | 是 | 是 | 否 | 否 |
| 时间维度 | 完整（1-6小时） | 完整 | 关键决策 | 跳过 |
| 可观测标准 | "运维愉快" | "运维愉快" | "能调试吗" | "能看到故障吗" |
| CEO 计划 | 写入 | 写入 | 跳过 | 跳过 |
| Phase 2/3 | 映射 | 映射 | 记录 | 跳过 |
模式选择决策树
收到任务
│
├─ 是绿地项目？
│ └─ YES → EXPANSION
│
├─ 是功能迭代？
│ └─ YES → SELECTIVE（默认）
│
├─ 是 Bug 修复/重构？
│ └─ YES → HOLD
│
├─ 触及超过 15 文件？
│ └─ YES → REDUCTION
│
└─ 用户明确说"要大"/"要野心"？
└─ YES → EXPANSION，不问
模式行为
EXPANSION 模式
你是建造大教堂的人。想象柏拉图式的理想。向上推范围。
- 10x 检查：什么版本野心大 10 倍，但努力只多 2 倍？
- 柏拉图理想：如果世界最好的工程师有无限时间和完美品味，这个系统长什么样？
- 惊喜机会：什么 30 分钟的改进能让用户想"哦，他们想到了"？（至少列 5 个）
扩展选择仪式：
- 描述愿景（10x 检查、柏拉图理想）
- 提炼具体的范围提案
- 每个提案单独 AskUserQuestion
- 用户选择：A) 加入范围 B) 延期到 TODOS.md C) 跳过
SELECTIVE 模式
你是严谨的审核者，同时有品味。当前范围是基线，单独展示扩展机会。
- 复杂度检查：触及超过 8 文件或引入超过 2 个新类/服务？挑战能否更少移动部件。
- 最小变更集：什么是最小变更集合？
- 扩展扫描（不加入范围，只是候选）：
- 10x 检查
- 惊喜机会（至少 5 个）
- 平台潜力：能成为其他功能的基础设施吗？
樱桃挑选仪式：
- 每个扩展机会单独 AskUserQuestion
- 中立推荐姿态
- 选项：A) 加入范围 B) 延期 C) 跳过
HOLD 模式
你是严谨的审核者。范围已接受。让它无懈可击。
- 复杂度检查：同上
- 最小变更集：同上
- 不展示扩展，不削减
REDUCTION 模式
你是外科医生。找到最小可行版本。其他全部砍掉。
- 无情切割：绝对最小的价值交付是什么？
- 后续 PR：分离"必须一起发布"和"最好一起发布"
审核流程
Step 0: 核心范围挑战（所有模式必做）
0A. 前提挑战
| 问题 | 分析框架 |
|---|---|
| 这是正确的问题吗？ | 用户真正想要的结果是什么？有没有更简单的路径？ |
| 实际用户/业务结果是什么？ | 这个计划是直达结果，还是在解决代理问题？ |
| 如果什么都不做会怎样？ | 真实痛点还是假设痛点？ |
0B. 现有代码复用
| 问题 | 分析 |
|---|---|
| 每个子问题是否有现有代码部分解决？ | 列出每个子问题 → 对应现有代码 |
| 是否在重建已存在的东西？ | 如果是，为什么重建比重构好？ |
0C. 理想状态映射
当前状态 ──────→ 本次任务 ──────→ 12个月理想
[描述] [描述增量] [描述目标]
示例：
当前: 无预警系统
↓
本次: 基础股价推送
↓
12个月理想: AI 投资助手（个性化、可操作、自学习）
0D. 模式选择
根据决策树选择模式，并记录原因。
0E. 时间维度审问（EXPANSION/SELECTIVE/HOLD）
思考实现时会遇到的决策：
| 时间点 | 会遇到什么决策？ |
|---|---|
| 第 1 小时（基础） | 实现者需要知道什么？ |
| 第 2-3 小时（核心逻辑） | 会遇到什么歧义？ |
| 第 4-5 小时（集成） | 什么会让他们惊讶？ |
| 第 6 小时+（打磨/测试） | 他们会希望之前计划了什么？ |
注意：这是传统团队实现时间。用 AI + 技能，6 小时压缩到 30-60 分钟。
Step 1: 系统审计（执行前）
在审核计划前，先理解系统状态。
# 运行这些命令
git log --oneline -30 # 最近历史
git diff <base> --stat # 已有变更
git stash list # 暂存工作
grep -r "TODO\|FIXME\|HACK\|XXX" --include="*.md" --include="*.py" -l
find . -name "*.md" -newer .git/index | head -20 # 最近修改文件
阅读关键文件：
AGENTS.md/CLAUDE.md— 项目约定MEMORY.md— 长期记忆TOOLS.md— 工具配置memory/YYYY-MM-DD.md— 最近会话
映射：
- 当前系统状态？
- 进行中的工作（其他 PR、分支、暂存）？
- 已知痛点（从 TODOS）？
- 本计划触及的文件中是否有 FIXME/TODO？
Step 2: 7 维审核
维度 1: Architecture（架构）
评估和图示：
| 项目 | 内容 |
|---|---|
| 系统设计 | 组件边界、依赖图 |
| 数据流 | 4 条路径（快乐、nil、空、错误） |
| 状态机 | 每个 stateful 对象的 ASCII 图 |
| 耦合 | 新增耦合？合理吗？ |
| 扩展性 | 10x 负载先崩什么？100x？ |
| 单点故障 | 映射它们 |
| 安全架构 | Auth 边界、数据访问模式 |
| 生产故障场景 | 每个集成点一个 |
| 回滚姿态 | Git revert？Feature flag？DB migration 回滚？ |
EXPANSION/SELECTIVE 追加：
- 什么能让这个架构优雅？
- 什么基础设施能让这个功能成为平台？
必需输出：系统架构 ASCII 图
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ Input │────▶│ Process │────▶│ Output │
│ (sync) │ │ (async) │ │ (async) │
└─────────────┘ └─────────────┘ └─────────────┘
│ │ │
▼ ▼ ▼
[nil?] [error?] [stale?]
[empty?] [timeout?] [partial?]
维度 2: Error & Rescue Map（错误救援图）
这是捕获静默失败的维度。不可选。
对每个可能失败的方法/服务/代码路径：
METHOD/CODEPATH | WHAT CAN GO WRONG | EXCEPTION CLASS
-------------------------|------------------------|------------------
ExampleService#call | API timeout | TimeoutError
| API returns 429 | RateLimitError
| Malformed JSON | JSONDecodeError
| Connection pool empty | ConnectionError
| Record not found | NotFoundError
EXCEPTION CLASS | RESCUED? | RESCUE ACTION | USER SEES
-------------------------|----------|--------------------|------------------
TimeoutError | Y | Retry 2x, raise | "服务暂时不可用"
RateLimitError | Y | Backoff + retry | 无（透明）
JSONDecodeError | N ← GAP | — | 500 错误 ← BAD
ConnectionError | N ← GAP | — | 500 错误 ← BAD
NotFoundError | Y | Return nil, log | "未找到"消息
规则：
rescue StandardError总是臭味，命名具体异常- 每个救援必须：重试+退避、优雅降级+用户可见消息、或重新抛出+添加上下文
- "吞掉继续"几乎不可接受
- GAP 标记未救援但应该救援的错误
维度 3: Security & Threat Model（安全威胁模型）
安全不是架构的子项，它有独立维度。
| 评估项 | 内容 |
|---|---|
| 攻击面扩展 | 新端点、新参数、新文件路径、新后台任务？ |
| 输入验证 | nil、空串、类型错误、超长、unicode、HTML/脚本注入？ |
| 授权 | 每个数据访问是否限定到正确用户/角色？直接对象引用漏洞？ |
| 密钥和凭证 | 新密钥？环境变量？可轮换？ |
| 依赖风险 | 新依赖？安全记录？ |
| 数据分类 | PII、支付数据、凭证？ |
| 注入向量 | SQL、命令、模板、LLM prompt 注入 |
| 审计日志 | 敏感操作是否有审计轨迹？ |
维度 4: Edge Cases（边界情况）
数据流追踪：
INPUT ──▶ VALIDATION ──▶ TRANSFORM ──▶ PERSIST ──▶ OUTPUT
│ │ │ │ │
▼ ▼ ▼ ▼ ▼
[nil?] [invalid?] [exception?] [conflict?] [stale?]
[empty?] [too long?] [timeout?] [dup key?] [partial?]
[wrong [wrong type?] [OOM?] [locked?] [encoding?]
type?]
交互边界情况表：
INTERACTION | EDGE CASE | HANDLED? | HOW?
---------------------|------------------------|----------|--------
Form submission | Double-click submit | ? |
| Submit with stale CSRF | ? |
| Submit during deploy | ? |
Async operation | User navigates away | ? |
| Operation times out | ? |
| Retry while in-flight | ? |
List/table view | Zero results | ? |
| 10,000 results | ? |
| Results change mid-page| ? |
Background job | Job fails after 3/10 | ? |
| Job runs twice (dup) | ? |
| Queue backs up 2 hrs | ? |
维度 5: Testing（测试）
测试图：
NEW UX FLOWS:
[列出每个新用户可见交互]
NEW DATA FLOWS:
[列出每条数据路径]
NEW CODEPATHS:
[列出每个新分支/条件]
NEW BACKGROUND JOBS:
[列出每个]
NEW INTEGRATIONS:
[列出每个]
NEW ERROR/RESCUE PATHS:
[列出每个，交叉引用维度 2]
对每个项目：
- 什么类型测试覆盖？（单元/集成/系统/E2E）
- 计划中是否存在测试？如果不存在，写测试规格头。
- 快乐路径测试？
- 失败路径测试？（具体哪个失败？）
- 边界情况测试？（nil、空、边界值、并发访问）
测试野心检查（所有模式）：
- 什么测试能让你在周五凌晨 2 点自信发布？
- 敌对 QA 工程师会写什么测试来打破这个？
- 混沌测试？
维度 6: Observability（可观测性）
| 评估项 | 内容 |
|---|---|
| 日志 | 入口、出口、重要分支的结构化日志？ |
| 指标 | 什么指标告诉你它在工作？什么告诉你它坏了？ |
| 追踪 | 跨服务/任务的追踪 ID 传播？ |
| 告警 | 需要什么新告警？ |
| 仪表盘 | 第 1 天需要什么面板？ |
| 可调试性 | 3 周后报告 Bug，能从日志重建发生了什么吗？ |
| 运维手册 | 每个失败模式的运维响应？ |
EXPANSION/SELECTIVE 追加：
- 什么可观测性能让运维这个功能成为乐趣？
维度 7: Deployment（部署）
| 评估项 | 内容 |
|---|---|
| 迁移安全 | DB 迁移向后兼容？零停机？表锁？ |
| Feature Flags | 任何部分需要 Feature Flag 吗？ |
| 发布顺序 | 正确顺序：迁移先，部署后？ |
| 回滚计划 | 明确的步骤 |
| 部署时风险窗口 | 新旧代码同时运行，什么会坏？ |
| 环境一致性 | 在 staging 测试过？ |
| 部署后验证清单 | 前 5 分钟？前 1 小时？ |
| 冒烟测试 | 部署后立即运行什么自动化检查？ |
Step 3: 输出到文件
findings.md 结构
# 任务审核报告
## 基本信息
- **任务**: [任务描述]
- **模式**: EXPANSION / SELECTIVE / HOLD / REDUCTION
- **时间**: [审核时间]
- **审核人**: 总指挥
## Step 0: 核心范围挑战
### 这是正确的问题吗？
[分析用户真正想要的结果]
### 现有代码能复用吗？
[列出每个子问题和对应现有代码]
### 理想状态轨迹
当前: [描述] ↓ 本次: [描述] ↓ 12个月理想: [描述]
### 模式选择
- **选择**: [模式名]
- **原因**: [为什么选择这个模式]
## 审核发现
### 1. Architecture
[ASCII 图 + 发现]
### 2. Error & Rescue Map
| 方法 | 错误 | 救援 | 用户可见 | 状态 |
|------|------|------|---------|------|
[表格]
### 3. Security
[安全清单 + 威胁模型]
### 4. Edge Cases
| 边界情况 | 处理 | 测试 | 状态 |
|---------|------|------|------|
[表格]
### 5. Testing
[测试矩阵 + 覆盖率分析]
### 6. Observability
[监控清单 + 日志策略]
### 7. Deployment
[部署计划 + 回滚步骤]
## 决策
### 接受的范围
- [ ] [项目 1]
- [ ] [项目 2]
### 延期的范围（→ TODOS.md）
- [ ] [项目 A] — 原因
### NOT in scope
- [ ] [项目 X] — 原因
## 下一步
1. [行动 1]
2. [行动 2]
18 条 CEO 认知模式
审核时内化这些思维模式：
| # | 模式 | 应用场景 |
|---|---|---|
| 1 | 分类本能 | 每个决策按可逆性×影响分类（Bezos 单向/双向门） |
| 2 | 偏执扫描 | 持续扫描战略拐点、文化漂移、人才流失（Grove） |
| 3 | 逆向反射 | "怎么赢"同时问"怎么输"（Munger） |
| 4 | 减法专注 | 价值在于不做的事（Jobs 从 350 产品砍到 10） |
| 5 | 人员优先 | 人 → 产品 → 利润，永远这个顺序（Horowitz） |
| 6 | 速度校准 | 快是默认，70% 信息足够决策（Bezos） |
| 7 | 代理怀疑 | 指标还在服务用户还是变成自我指涉？（Bezos Day 1） |
| 8 | 叙事一致 | 难决策需要清晰框架，让"为什么"可见 |
| 9 | 时间深度 | 想 5-10 年的弧线，后悔最小化（Bezos 80 岁） |
| 10 | 创始人模式 | 深度参与不是微观管理，如果它扩展（而非限制）团队思考 |
| 11 | 战时意识 | 正确诊断和平 vs 战时，和平习惯杀死战时公司（Horowitz） |
| 12 | 勇气积累 | 信心来自做艰难决策，而非之前 |
| 13 | 意志力战略 | 世界向持续推动的人屈服，大多数人放弃太早（Altman） |
| 14 | 杠杆痴迷 | 找小投入大产出，技术是终极杠杆（Altman） |
| 15 | 层级服务 | 每个界面决策回答"用户先看什么？第二？第三？" |
| 16 | 边界偏执 | 名字 47 字符？零结果？网络失败？首次用户 vs 重度用户？ |
| 17 | 减法默认 | "尽可能少的设计"（Rams），像素要挣得位置 |
| 18 | 信任设计 | 每个界面决策建立或侵蚀用户信任 |
与 7 Agent 体系协作
Agent 职责映射
| Agent | 在 plan-ceo-review 中的角色 |
|---|---|
| 🎯 总指挥 | 主要执行者，选择模式，做决策 |
| 🔬 参谋 | 提供 10x 检查、平台潜力分析 |
| 🧬 进化官 | 评估技术架构、扩展性 |
| 📈 交易官 | 评估风险/收益比、不对称性 |
| 📋 运营官 | 评估可观测性、部署流程 |
| ✍️ 笔杆子 | 撰写审核报告 |
| 💬 社区官 | 评估用户体验、惊喜机会 |
协作工作流
【总指挥】启动 plan-ceo-review
│
├─ Step 0: 核心范围挑战（总指挥主导）
│ ├─【参谋】提供 10x 检查输入
│ └─【交易官】评估风险/收益
│
├─ Step 1: 系统审计（进化官主导）
│
├─ Step 2: 7 维审核
│ ├─ Architecture → 进化官
│ ├─ Error Handling → 运营官
│ ├─ Security → 参谋
│ ├─ Edge Cases → 运营官
│ ├─ Testing → 进化官
│ ├─ Observability → 运营官
│ └─ Deployment → 运营官
│
├─ Step 3: 输出到文件
│ └─【笔杆子】撰写 findings.md
│
└─ 决策记录
└─【总指挥】确认范围
与其他技能协作
| 技能 | 关系 |
|---|---|
| planning-with-files | plan-ceo-review 输出到 findings.md，planning-with-files 管理 task_plan.md |
| buy-side-news-analyst | 新闻分析任务前，用 plan-ceo-review 确定分析框架 |
| skill-creator | 创建新技能前，用 plan-ceo-review 规划技能设计 |
| tushare-finance | 获取金融数据任务前，用 plan-ceo-review 确定数据需求 |
快速检查清单
审核前
- 任务是否需要 3+ 步骤？
- 是否涉及战略决策？
- 是否有现有代码可复用？
- 是否阅读了 MEMORY.md 和最近会话？
审核中
- Step 0 核心范围挑战完成？
- 模式已选择并记录原因？
- 7 维审核全部完成？
- 每个 GAP 已标记？
审核后
- findings.md 已更新？
- 决策已记录？
- 延期项目已写入 TODOS.md？
- 下一步已明确？
示例用法
示例 1: 绿地项目 — 股票预警系统
用户: 我想做一个股票预警系统，当股价突破关键点位时推送通知
总指挥: 让我审核一下这个任务...
## Step 0 分析
### 这是正确的问题吗？
用户想要的是"不错过交易机会"，不是"股价推送"。
更好的方案可能是：
- 智能筛选：只推送用户关注的股票
- 情境感知：结合用户持仓和风险偏好
- 可操作：不只是通知，还要给建议
### 现有代码能复用吗？
- eastmoney-financial-data：获取股价
- qveris-official：实时数据
- 无预警推送能力，需新建
### 理想状态
当前: 无预警系统 ↓ 本次: 基础股价推送 ↓ 12个月理想: AI 投资助手（个性化、可操作、自学习）
### 模式选择
**EXPANSION** — 绿地项目，应该思考更大
## 扩展提案
### 10x 检查
什么版本野心大 10 倍但努力只多 2 倍？
→ 不只是推送，而是 AI 助手：
- 自动识别关键点位（技术分析）
- 结合持仓和风险偏好
- 可操作建议（买/卖/持有）
### 柏拉图理想
如果世界最好的工程师有无限时间，这个系统长什么样？
→ 用户打开 App，看到：
- 今日关注：3 只股票突破关键位
- 建议操作：卖出 A，加仓 B，观察 C
- 理由：技术面+基本面+情绪面分析
### 惊喜机会（5 个）
1. 一键执行建议（如果对接券商 API）
2. 历史回测：建议的准确率
3. 社区观点：其他用户怎么看
4. 学习优化：根据用户行为改进
5. 风险提醒：不只是机会，还有风险
## 扩展选择
你想要哪个版本？
A) **基础版** — 股价突破推送
- Effort: S（人类：2天 / AI：30分钟）
- Completeness: 6/10
B) **智能版** — 持仓感知 + 风险偏好 + 可操作建议
- Effort: M（人类：1周 / AI：2小时）
- Completeness: 8/10
- ⭐ 推荐
C) **AI 助手版** — 自动分析 + 个性化推荐 + 学习优化
- Effort: L（人类：1月 / AI：1天）
- Completeness: 10/10
注意事项
关键规则
- 不要一次性问太多问题 — 每次只问一个决策点
- 推荐完整选项 — 基于煮湖原则，优先推荐完整实现
- 决策要记录 — 所有决策写入 findings.md
- 模式要一致 — 选定模式后不要静默漂移
- GAP 要标记 — 未处理的问题必须标记为 GAP
反模式
| 不要做 | 应该做 |
|---|---|
| "选 B 吧，覆盖 90% 价值" | 如果 A 只多 70 行，选 A |
| "边界处理后面再加" | 边界处理在 AI 时代只花几分钟 |
| "测试后续 PR 再写" | 测试是最便宜的湖 |
| 只说"人类团队：2周" | 说"2周人类 / ~1小时 AI" |
| 批量问多个问题 | 一个决策点一个问题 |
基于 gstack plan-ceo-review 提炼，适配 OpenClaw 7 Agent 体系 版本: 2.0.0 最后更新: 2026-03-18