Y Combinator 总裁 Garry Tan 开源其私人 AI 编程工具集 gstack，其中核心 skill /plan-ceo-review 引发广泛关注。
该 skill 共 577 行代码，本质并非普通提示词，而是一套可复用的「认知操作系统」——将 Garry Tan 高效交付（日均 10K 行代码、10 个 PR）背后的创始人级思维，系统化编码为算法。
为什么这个 skill 如此特殊？
多数 AI 提示词聚焦于“如何做事”；/plan-ceo-review 的突破在于教 AI “如何思考”，更准确地说，是用「创始人的大脑」进行结构化思考。其设计包含三大核心机制：
一、三重认知模式：非单一视角，而是三种互斥思维范式
/plan-ceo-review 并非单一对话模式，而是强制用户在审查前明确选择其一，并全程锁定——杜绝思维漂移。三种模式逻辑对立、不可混用：
范围扩展模式：大教堂建造者
你在建造大教堂。
想象柏拉图式的理想版本。
推动范围向上。
问："什么能让这个功能好 10 倍，但只需要 2 倍的努力?"
"要不要也做 X?" 的答案是 "要，如果它服务于愿景。"
你有权利去梦想。
核心追问：「理想状态是什么样的？」
必须回答三个问题：
- 10 倍检查：什么版本能好 10 倍，但只需 2 倍努力？
- 理想状态：若由世界顶尖工程师以无限时间与完美品味构建，该系统应为何样？
- 惊喜机会：哪些 30 分钟内可完成的小改进，能让用户脱口而出“哦，他们连这个都想到了”？
保持范围模式：偏执的审查者
你是一个严格的审查者。
计划的范围已经确定。
你的工作是让它防弹级——捕捉每个失败模式，测试每个边界情况，确保可观测性，映射每个错误路径。
不要悄悄减少或扩展。
核心追问：「哪里会炸？」
必须执行：
- 映射每一个错误路径
- 命名每一个异常类
- 追踪每一个影子路径（nil、空、错误）
- 检查每一个边界情况
范围缩减模式：外科医生
你是一个外科医生。
找到实现核心目标的最小可行版本。
砍掉其他一切。
无情。
核心追问：「什么可以推迟到下一个 PR？」
一旦选定模式，即完全承诺。若选扩展，则不得在后续讨论中质疑范围；若选缩减，则不得暗中加回功能。该设计直击当前 AI 助手的核心缺陷：缺乏对用户当前所需认知模式的显式识别与锁定。
二、9 条不可妥协的原则：从建议升级为铁律
不同于泛泛而谈的“注意错误处理”，/plan-ceo-review 定义了 9 条 Prime Directives（首要指令），每一条均为不可协商的工程底线：
1. Zero silent failures（零静默失败）
每个失败模式必须可见——对系统、对团队、对用户。
如果一个失败可以静默发生，那就是计划中的关键缺陷。
要求：不是“处理错误”，而是“让每个错误都尖叫”。
2. 每个错误都有名字
不要说"处理错误"。
命名具体的异常类，什么触发它，什么拯救它，用户看到什么，是否测试过。
rescue StandardError 是代码异味——必须指出。
禁止通用捕获 rescue => e，强制要求：
- 命名具体异常类（如
Faraday::TimeoutError，而非StandardError） - 说明触发条件
- 说明恢复方案
- 说明用户感知
- 说明是否已覆盖测试
3. 数据流有影子路径
每个数据流有一个快乐路径和三个影子路径：
nil 输入、空/零长度输入、上游错误。
为每个新流程追踪所有四条路径。
强制追踪四条路径：
- 快乐路径：数据正常流动
- Nil 路径：输入为 nil/缺失
- 空路径：输入存在但为空/零长度
- 错误路径：上游调用失败
4. Interactions have edge cases（交互有边界情况）
每个用户可见的交互都有边界情况：
双击、中途离开、慢连接、过期状态、返回按钮。
映射它们。
5. 可观测性是范围，不是事后补救
新的仪表板、告警和 Runbook 是一等公民的交付物，
不是发布后的清理项目。
新功能上线时，必须同步交付：
- 日志
- 指标
- 告警
- 仪表板
- Runbook
6. 图表是强制性的
没有非平凡的流程不画图。
每个新的数据流、状态机、处理管道、依赖图、决策树都要有 ASCII 艺术图。
非“建议画图”，而是“必须画图”。
7. 延期的事项必须写下来
模糊的意图是谎言。
TODOS.md 或者它不存在。
杜绝“以后再做”。要么立即实施，要么写入 TODOS.md，要么公开承认放弃。
8. 优化 6 个月后的未来
如果这个计划解决了今天的问题，但创造了下个季度的噩梦，
明确说出来。
9. 你有权说“推倒重来”
如果有根本更好的方法，提出来。
我宁愿现在听到。
这 9 条原则是贯穿全部 10 个审查环节的底层约束，非建议，而是执行刚性标准。
三、10 个审查维度：CEO 级计划审查的标准化流程
Garry Tan 将“CEO 审查技术计划”的隐性经验，拆解为 10 个强制执行的审查步骤，每个环节均含明确输出要求与 GAP 标记机制（标为 GAP 即视为关键缺陷）：
步骤 0：核心范围挑战
审查始于对前提的质疑：
0A. 前提挑战
- 这是正确的问题吗？
- 真正的用户/业务结果是什么？
- 如果什么都不做会怎样？
0B. 现有代码利用
- 什么现有代码已部分或完全解决各子问题？
- 该计划是否在重复造轮子？
0C. 梦想状态映射
当前状态 → 此计划 → 12 个月理想状态
0D. 模式特定分析
依所选认知模式，执行差异化检查：
扩展模式执行三项：
- 10 倍检查：什么版本能好 10 倍，但只需 2 倍努力？
- 理想状态：理想体验应为何样？（从用户出发，非架构）
- 惊喜机会：至少列出 3 个 30 分钟可交付的惊喜点。
保持范围模式执行：
- 复杂度检查：涉及文件 >8 个或新增类/服务 >2 个，即为代码异味。
- 什么是实现目标的最小变更集？
缩减模式执行：
- 无情砍掉：向用户交付价值的绝对最小值是什么？
- 什么必须留至后续 PR？
0E. 时间审问
提前模拟实施过程，定位卡点：
第 1 小时（基础）：实现者需掌握什么？
第 2–3 小时（核心逻辑）：会遇到哪些歧义？
第 4–5 小时（集成）：什么会令人意外？
第 6+ 小时（完善/测试）：需提前规划什么？
问题须在当下提出，而非延后。
10 个审查维度
- 架构审查：系统设计、依赖图、数据流（含影子路径）
- 错误与拯救映射：每个异常具名且附处理方案
- 安全与威胁模型：攻击面、输入验证、授权边界
- 数据流与交互边界情况：双击、导航离开、超时等
- 代码质量审查：DRY 原则、命名质量、复杂度
- 测试审查：覆盖新流程、所有代码路径及错误路径
- 性能审查：重复查询、内存占用、DB 索引
- 可观测性与可调试性审查：日志、指标、告警、Runbook
- 部署与发布审查：迁移安全、功能开关、回滚计划
- 长期轨迹审查：技术债务、路径依赖、可逆性
最精巧的设计：结构化提问机制
每个审查章节结束时，均嵌入统一指令：
停下。一次只问一个问题。不要批量提问。
给出推荐 + 原因。如果没有问题或修复方案很明显，
说明你要做什么然后继续——不浪费提问机会。
在用户回应之前不要继续。
该机制强制 AI 单点突破，避免信息过载。所有问题须遵循四段式结构：
提问的强制格式
1. 重新定位:
说明项目、当前分支、当前计划/任务。（1–2 句话）
2. 简化说明:
用一个聪明的 16 岁孩子能理解的简单语言解释问题。
禁用函数名、内部术语、实现细节；用具体例子和类比说明功能，而非名称。
3. 给出推荐:
推荐：选择 [X]，因为 [一行原因]
4. 提供选项:
字母选项：A) ... B) ... C) ...
关键规则：假设用户 20 分钟未查看窗口且未打开代码。若需读源码才能理解解释，即判定为不合格。
skill：一套可编码、可传播、可执行的认知框架
/plan-ceo-review 的本质，是将创始人级系统思维工程化落地，体现为三大能力：
1. 把“创始人思维”编码成算法
将原属直觉与经验的审查过程，结构化为：
- 3 种认知模式（EXPANSION / HOLD / REDUCTION）
- 9 条不可妥协原则
- 10 个强制审查维度
- 每个维度含强制输出项
使任意工程师均可通过该框架，接近 Garry Tan 级别的审查深度与质量。
2. 强制“系统化的偏执”
不依赖记忆与自觉，而是通过机制确保：
- 映射每一个错误路径
- 追踪每一个影子路径
- 检查每一个边界情况
- 画出每一个非平凡流程的图表
这不是 checklist，而是嵌入工作流的强制执行层。
3. 把“高标准”变成默认行为
Garry Tan 的高产高质量，源于工具本身对标准的内化：
- 无需提醒“检查错误处理”——工具强制执行
- 无需提醒“画架构图”——工具强制生成
- 无需提醒“考虑长期影响”——工具强制评估
局限性：适用场景与前置条件
1. 工具体量较重
577 行代码、10 个审查维度、全环节强制输出，适用于关键模块或重大功能评审，而非轻量快速迭代。
2. 依赖完整上下文
需接入 Git 历史、CLAUDE.md、TODOS.md、架构文档及近期修改文件。若项目文档缺失或陈旧，效果将显著衰减。
3. 要求高度用户参与
每个章节均 STOP 等待人工响应。用户需全程决策、反馈、确认，无法全自动运行——保障质量，但增加时间成本。
