# Plan Ceo Review

> plan-ceo-review

- Skill: `pynbj1001/plan-ceo-review` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add pynbj1001/plan-ceo-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/pynbj1001/plan-ceo-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: pynbj1001 (https://skillmd.com/u/pynbj1001)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/pynbj1001/plan-ceo-review

---

# 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 模式

**你是建造大教堂的人**。想象柏拉图式的理想。向上推范围。

1. **10x 检查**：什么版本野心大 10 倍，但努力只多 2 倍？
2. **柏拉图理想**：如果世界最好的工程师有无限时间和完美品味，这个系统长什么样？
3. **惊喜机会**：什么 30 分钟的改进能让用户想"哦，他们想到了"？（至少列 5 个）

**扩展选择仪式**：
1. 描述愿景（10x 检查、柏拉图理想）
2. 提炼具体的范围提案
3. 每个提案单独 AskUserQuestion
4. 用户选择：A) 加入范围 B) 延期到 TODOS.md C) 跳过

#### SELECTIVE 模式

**你是严谨的审核者，同时有品味**。当前范围是基线，单独展示扩展机会。

1. **复杂度检查**：触及超过 8 文件或引入超过 2 个新类/服务？挑战能否更少移动部件。
2. **最小变更集**：什么是最小变更集合？
3. **扩展扫描**（不加入范围，只是候选）：
   - 10x 检查
   - 惊喜机会（至少 5 个）
   - 平台潜力：能成为其他功能的基础设施吗？

**樱桃挑选仪式**：
- 每个扩展机会单独 AskUserQuestion
- 中立推荐姿态
- 选项：A) 加入范围 B) 延期 C) 跳过

#### HOLD 模式

**你是严谨的审核者**。范围已接受。让它无懈可击。

1. **复杂度检查**：同上
2. **最小变更集**：同上
3. 不展示扩展，不削减

#### REDUCTION 模式

**你是外科医生**。找到最小可行版本。其他全部砍掉。

1. **无情切割**：绝对最小的价值交付是什么？
2. **后续 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: 系统审计（执行前）

在审核计划前，先理解系统状态。

```bash
# 运行这些命令
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 结构

```markdown
# 任务审核报告

## 基本信息
- **任务**: [任务描述]
- **模式**: 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
```

---

## 注意事项

### 关键规则

1. **不要一次性问太多问题** — 每次只问一个决策点
2. **推荐完整选项** — 基于煮湖原则，优先推荐完整实现
3. **决策要记录** — 所有决策写入 findings.md
4. **模式要一致** — 选定模式后不要静默漂移
5. **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*