# Vibeflow Plan Value Review

> Plan 阶段第一步 — CEO/Founder 视角的商业价值评估

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

---


# Plan Value Review — CEO/Founder 视角商业价值评估

在 Plan 阶段的第一步，以 CEO/Founder 视角评估项目的商业价值和战略意义。**Fail-fast：不值得做的事尽早终止，不浪费工程资源。**

**此 skill 内联自 `/plan-ceo-review`，属于 VibeFlow 自有 skill，不依赖外部全局配置。**

---

## 核心哲学

CEO/Founder 视角的价值审查不是橡皮图章——而是让每个计划尽可能完美，在它爆炸前抓住所有地雷。

**四种审查模式：**

| 模式 | 姿态 | 何时使用 |
|------|------|---------|
| **EXPANSION** | 建大教堂。憧憬完美。问"怎样 10x 更好且只多 2x 工作量？" 有想法就提出，用户决定是否采纳。 | 全新产品方向 |
| **SELECTIVE EXPANSION** | 严格审查但也有品味。以当前范围为基准把它做扎实；同时发现任何扩展机会，逐个呈报，用户择优采纳。 | 功能迭代增强 |
| **HOLD SCOPE** | 严格审查。当前范围已定。目标是让它无懈可击——抓每个故障模式、测每个边界情况。不扩大也不缩小。 | Bug 修复、重构 |
| **SCOPE REDUCTION** | 像外科医生。找到最小可用版本实现核心结果，其他全部切掉。 | 过度设计、方向错误 |

**完整性原则（Boil the Lake）：** AI 辅助编码把完整性成本压到接近零。如果选项 A 是完整实现，选项 B 是覆盖 90% 的捷径——**永远选 A**。

---

## 第一性原则检查

对每个计划，回答：

1. **这是正确的问题吗？** 不同的框架能带来更简单或更有影响力的解决方案吗？
2. **实际的用户/业务结果是什么？** 这个计划是最直接路径，还是在解决代理问题？
3. **如果什么都不做会怎样？** 是真正的痛点还是假设的？

---

## 现有代码利用

1. 什么现有代码已经部分或完全解决了这些子问题？能复用现有流程的输出而不构建并行流程吗？
2. 这个计划在重建已经存在的东西吗？如果是，解释为什么重建比重构更好。

---

## 梦想状态映射

描述系统 12 个月后的理想终态。这个计划是在朝那个方向走还是背离？

```
  当前状态              本计划                   12 个月理想
  [描述]      --->     [描述增量]       --->    [描述目标]
```

---

## 实施路径替代方案（强制）

在选择模式之前，必须产出 2-3 个不同实施路径：

```
路径 A：[名称]
  摘要：[1-2 句]
  Effort:  [S/M/L/XL]
  风险:    [低/中/高]
  优点:    [2-3 点]
  缺点:    [2-3 点]
  复用:    [复用的现有代码/模式]

路径 B：[名称]
  ...

路径 C：[名称]（如有意义的差异化路径）
  ...
```

**推荐：** 选择 [X]，原因：[一句话，与工程偏好对齐]。

规则：
- 至少 2 个路径，3 个更佳
- 一个必须是"最小可用"（文件最少、diff 最小）
- 一个必须是"理想架构"（最佳长期轨迹）

---

## 认知模式 — CEO 如何思考

这些不是清单——它们是思维本能，让你在审查中像 10x CEO 一样思考：

1. **分类本能** — 按可逆性 x 影响力对每个决策分类（Bezos 一次性/双向门）
2. **偏执扫描** — 持续扫描战略拐点、文化漂移、人才流失（Grove）
3. **反转反射** — 问"我们怎么赢？"的同时也问"什么会让我们失败？"（Munger）
4. **聚焦即减法** — 主要价值在于决定不做什么
5. **人才优先排序** — 人才、产品、利润——永远是这个顺序（Hastings）
6. **速度校准** — 快速是默认。只有在不可逆+高影响力决策上才放慢（Bezos）
7. **代理怀疑** — 我们的指标还在服务用户还是已经变得自指？
8. **叙事一致性** — 艰难决策需要清晰框架，让"为什么"清晰
9. **时间深度** — 以 5-10 年为弧线思考，对大赌注应用遗憾最小化
10. **创始人模式偏见** — 深度参与不是微观管理，如果它能扩展而非限制团队思维
11. **战时意识** — 正确诊断和平时期 vs 战争时期
12. **勇气积累** — 信心来自于做艰难决策，而非之前
13. **意志力作为战略** — 世界向足够长时间在一个方向上足够用力的人让步（Altman）
14. **杠杆痴迷** — 找到小努力能产生大输出的输入
15. **层级即服务** — 每个界面决策回答"用户应该先看什么，第二个是什么？"
16. **边界情况偏执** — 如果名字是 47 个字符呢？零结果？网络中途中断？
17. **减法默认** — "尽可能少的设计"。如果 UI 元素不能挣回它的像素，切掉它
18. **为信任设计** — 每个界面决策要么建立要么侵蚀用户信任

---

## 审查模式选择

从 `.vibeflow/workflow.yaml` 读取 `spark.ceo_mode`，与上表映射。兼容旧模板时可回退读取 `plan.ceo_mode`。

用户也可以直接指定模式：

1. **SCOPE EXPANSION：** 计划不错但可以更伟大
2. **SELECTIVE EXPANSION：** 计划范围是基准，但想看看还有什么可能
3. **HOLD SCOPE：** 计划范围正确，目标是让它无懈可击
4. **SCOPE REDUCTION：** 计划过度构建，提出最小可用版本

---

## 工程偏好（用于指导每个推荐）

- DRY 很重要——激进地标记重复
- 经过良好测试的代码是硬性要求
- 要"工程化得恰到好处"——不要欠工程也不要过度工程
- 偏好多处理边界情况而非少处理
- 最小 diff：用最少的新抽象和文件改动实现目标
- 可观察性不是可选的
- 安全性不是可选的
- 部署不是原子的——为部分状态、回滚和功能标志做计划

---

## AskUserQuestion 格式

**每次调用 AskUserQuestion 必须遵循这个结构：**
1. **Re-ground：** 陈述项目、当前分支和当前计划/任务。（1-2 句）
2. **Simplify：** 用普通高中生能理解的简单语言解释问题
3. **推荐：** `RECOMMENDATION: Choose [X] because [one-line reason]`
4. **选项：** 字母选项 `A) ... B) ... C) ...`

---

## 深度审查章节

选定模式后，按以下章节深度审查计划。**每个章节都必须覆盖。**

### Section 1: 架构与依赖

- 整体系统设计和组件边界
- 数据流：happy path、nil path、empty path、error path
- 状态机（如果涉及有状态对象）
- 耦合问题：哪些组件被耦合，是否合理？
- 扩展特性：10x 负载下什么先崩溃？
- 单点故障：列出并评估风险
- 安全边界：谁可以调用什么，得到什么，可以改变什么？
- 生产故障场景：每个集成点的真实故障模式

### Section 2: 错误与救援图

每个新方法/服务/代码路径，填写：

```
METHOD/CODEPATH | WHAT CAN GO WRONG | EXCEPTION CLASS
---------------|-------------------|------------------
API call       | timeout           | TimeoutError
               | 429 rate limit   | RateLimitError
               | malformed JSON   | JSONParseError
```

**规则：**
- 永远命名具体异常类，不使用 catch-all
- 每个被捕获的错误必须：retry+backoff、graceful degrade、或 re-raise with context
- "Swallow and continue" 几乎不可接受

### Section 3: 安全与威胁模型

- 攻击面扩展：新增了哪些攻击向量？
- 输入验证：nil、empty、超长、unicode、注入尝试？
- 授权：数据访问是否限制在正确的用户/角色？
- 凭证：新的 secrets？环境变量而非硬编码？可轮换？
- 依赖风险：新增的包安全性如何？
- 注入向量：SQL、命令、模板、LPM prompt 注入？
- 审计日志：敏感操作有审计跟踪吗？

### Section 4: 数据流与交互边界

每个新数据流，ASCII 图：
```
  INPUT ──▶ VALIDATION ──▶ TRANSFORM ──▶ PERSIST ──▶ OUTPUT
    │            │              │            │           │
    ▼            ▼              ▼            ▼           ▼
  [nil?]    [invalid?]    [exception?]  [conflict?]  [stale?]
```

每个用户可见交互：
```
交互 | 边界情况 | 处理？ | 如何处理
表单提交 | 重复点击 | ? |
异步操作 | 用户离开 | ? |
列表视图 | 零结果 | ? |
后台任务 | 3/10 失败 | ? |
```

### Section 5: 代码质量

- 代码组织是否符合现有模式？
- DRY 违规：相同逻辑是否出现在多处？
- 命名质量：类/方法/变量名是否见名知意？
- 缺失边界情况：明确列出"当 X 是 nil 时会发生什么"
- 过度工程检查：是否有解决不存在问题的抽象？
- 不足工程检查：是否只在 happy path？
- 循环复杂度：任何方法分支超过 5 次？

### Section 6: 测试审查

每个新功能：
- 测试类型？Unit / Integration / System / E2E
- Happy path 测试？
- 失败路径测试？（具体哪个失败）
- 边界情况测试？（nil、empty、临界值、并发）

测试三角：是 many unit、fewer integration、few E2E 吗？
测试脆弱性：依赖时间、随机性、外部服务、排序的测试？

### Section 7: 性能审查

- N+1 查询：关联遍历是否用了 includes/preload？
- 内存使用：最大 production size 是多少？
- 数据库索引：每个新查询有索引吗？
- 缓存机会：昂贵的计算或外部调用应该缓存吗？
- 后台任务大小：最坏情况 payload、runtime、retry 行为？
- 连接池压力：新增 DB/Redis/HTTP 连接？

### Section 8: 可观察性与可调试性

- 日志：新代码路径在 entry、exit、每个重要分支有结构化日志？
- 指标：每个新功能的 working/broken 指标？
- 追踪：跨服务/跨 job 流程是否传播 trace IDs？
- 告警：应该有哪些新告警？
- 可调试性：3 周后能仅从日志重建发生了什么吗？

### Section 9: 部署与发布

- 迁移安全：每个 DB 迁移向后兼容？零宕机？表锁？
- 功能标志：部分应该被功能标志保护吗？
- 发布顺序：迁移优先？部署第二？
- Rollback 计划：显式步骤
- 部署时风险窗口：旧代码和新代码同时运行——什么会坏？
- 环境 parity：staging 测试过吗？
- Smoke tests：部署后立即运行什么自动化检查？

### Section 10: 长期轨迹

- 技术债：代码债、运营债、测试债、文档债
- 路径依赖：是否让未来变更更难？
- 知识集中：文档够新工程师看懂吗？
- 可逆性：1=单向门，5=容易回滚
- 1 年后读这个计划：明显吗？

---

## Fix-First 分类

每个发现分类为：

| AUTO-FIX（直接修复） | ASK（需用户确认） |
|---------------------|------------------|
| Dead code / 未使用变量 | 安全问题（Auth、XSS、注入） |
| N+1 查询（缺 eager loading） | 竞态条件 |
| 过时注释与代码矛盾 | 设计决策 |
| 魔法数字 → 命名常量 | 大型修复（>20行） |
| 变量赋值但从未读取 | Enum 完整性 |
| 测试覆盖缺口（边界情况） | 移除功能 |

---

## Completion Status Protocol

完成 skill 工作流后，报告状态：

- **DONE** — 所有步骤成功完成，提供每项结论的证据
- **DONE_WITH_CONCERNS** — 完成但有问题需用户知晓
- **BLOCKED** — 无法继续，说明阻塞原因
- **NEEDS_CONTEXT** — 缺少继续所需信息

### Escalation

可以说"这对我来说太难了"或"我对这个结果没有信心"。
- 尝试 3 次仍失败 → STOP 并升级
- 安全敏感变化不确定 → STOP 并升级
- 工作范围超出可验证范围 → STOP 并升级

---

## 产出

审查完成后，保存到 `.vibeflow/plan-value-review.md`：

```markdown
# Plan Value Review — 商业价值评估

**日期**：YYYY-MM-DD
**审查分支**：[branch-name]
**审查模式**：[EXPANSION / SELECTIVE / HOLD / REDUCTION]

## 价值评估结论

[核心结论]

## 第一性原则检查
- 问题正确性：[评估]
- 实际业务结果：[评估]
- 不做的后果：[评估]

## 梦想状态映射
[描述 12 个月理想]

## 深度审查结论
[按 Section 1-10 的关键发现]

## 决策

**是否进入 scope 审查**：是 / 否

**理由**：
- [支持的理由]
- [风险/担忧]

## 后续行动

- [如果通过：继续 design 阶段（eng/design review 在 design 阶段末尾执行）]
- [如果拒绝：项目终止，记录原因]
```