ttttstc 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。
第一性原则检查
对每个计划，回答：
- 这是正确的问题吗？ 不同的框架能带来更简单或更有影响力的解决方案吗？
- 实际的用户/业务结果是什么？ 这个计划是最直接路径，还是在解决代理问题？
- 如果什么都不做会怎样？ 是真正的痛点还是假设的？
现有代码利用
- 什么现有代码已经部分或完全解决了这些子问题？能复用现有流程的输出而不构建并行流程吗？
- 这个计划在重建已经存在的东西吗？如果是，解释为什么重建比重构更好。
梦想状态映射
描述系统 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 一样思考：
- 分类本能 — 按可逆性 x 影响力对每个决策分类（Bezos 一次性/双向门）
- 偏执扫描 — 持续扫描战略拐点、文化漂移、人才流失（Grove）
- 反转反射 — 问"我们怎么赢？"的同时也问"什么会让我们失败？"（Munger）
- 聚焦即减法 — 主要价值在于决定不做什么
- 人才优先排序 — 人才、产品、利润——永远是这个顺序（Hastings）
- 速度校准 — 快速是默认。只有在不可逆+高影响力决策上才放慢（Bezos）
- 代理怀疑 — 我们的指标还在服务用户还是已经变得自指？
- 叙事一致性 — 艰难决策需要清晰框架，让"为什么"清晰
- 时间深度 — 以 5-10 年为弧线思考，对大赌注应用遗憾最小化
- 创始人模式偏见 — 深度参与不是微观管理，如果它能扩展而非限制团队思维
- 战时意识 — 正确诊断和平时期 vs 战争时期
- 勇气积累 — 信心来自于做艰难决策，而非之前
- 意志力作为战略 — 世界向足够长时间在一个方向上足够用力的人让步（Altman）
- 杠杆痴迷 — 找到小努力能产生大输出的输入
- 层级即服务 — 每个界面决策回答"用户应该先看什么，第二个是什么？"
- 边界情况偏执 — 如果名字是 47 个字符呢？零结果？网络中途中断？
- 减法默认 — "尽可能少的设计"。如果 UI 元素不能挣回它的像素，切掉它
- 为信任设计 — 每个界面决策要么建立要么侵蚀用户信任
审查模式选择
从 .vibeflow/workflow.yaml 读取 spark.ceo_mode，与上表映射。兼容旧模板时可回退读取 plan.ceo_mode。
用户也可以直接指定模式：
- SCOPE EXPANSION： 计划不错但可以更伟大
- SELECTIVE EXPANSION： 计划范围是基准，但想看看还有什么可能
- HOLD SCOPE： 计划范围正确，目标是让它无懈可击
- SCOPE REDUCTION： 计划过度构建，提出最小可用版本
工程偏好（用于指导每个推荐）
- DRY 很重要——激进地标记重复
- 经过良好测试的代码是硬性要求
- 要"工程化得恰到好处"——不要欠工程也不要过度工程
- 偏好多处理边界情况而非少处理
- 最小 diff：用最少的新抽象和文件改动实现目标
- 可观察性不是可选的
- 安全性不是可选的
- 部署不是原子的——为部分状态、回滚和功能标志做计划
AskUserQuestion 格式
每次调用 AskUserQuestion 必须遵循这个结构：
- Re-ground： 陈述项目、当前分支和当前计划/任务。（1-2 句）
- Simplify： 用普通高中生能理解的简单语言解释问题
- 推荐：
RECOMMENDATION: Choose [X] because [one-line reason] - 选项： 字母选项
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：
# Plan Value Review — 商业价值评估
**日期**：YYYY-MM-DD
**审查分支**：[branch-name]
**审查模式**：[EXPANSION / SELECTIVE / HOLD / REDUCTION]
## 价值评估结论
[核心结论]
## 第一性原则检查
- 问题正确性：[评估]
- 实际业务结果：[评估]
- 不做的后果：[评估]
## 梦想状态映射
[描述 12 个月理想]
## 深度审查结论
[按 Section 1-10 的关键发现]
## 决策
**是否进入 scope 审查**：是 / 否
**理由**：
- [支持的理由]
- [风险/担忧]
## 后续行动
- [如果通过：继续 design 阶段（eng/design review 在 design 阶段末尾执行）]
- [如果拒绝：项目终止，记录原因]