昨天用了 YC CEO 做的 skill，我仅仅是让 Claude Code 通过我本地的文件夹了解了我的商业模式，然后用这个叫做「plan-ceo-review」的 skill 直接执行了一下，没有加任何提示词。
它竟然是真的在一分钟之内就给了我一个真的能帮我提升收入的解决方案。
我觉得我已经算是能非常熟练使用 Claude Code 的人了，但这个过程还是让我感到非常的惊讶。更加让我惊讶的是，我看了这个 skill 的提示词，发现这里面完全没有提到商业领域。
做这个 skill 的人叫 Garry Tan，是 Y Combinator 现任的 CEO。YC 是全球最顶级的创业加速器，投出过 Airbnb、Stripe、Coinbase、Reddit 这些公司。他上周把自己用的 Claude Code 工具集开源了，放到 GitHub 上，一周拿了 19000 个 Star，2200 个 Fork。项目叫 gstack，里面有 10 个工具，plan-ceo-review 是其中一个。
https://github.com/garrytan/gstack
https://github.com/garrytan/gstack
这个 skill 大概 600 行，我翻译完之后自己看了一遍，说实话看得一脸懵逼。但是用起来确实有效。
我后来仔细想了一下它到底是怎么做到的，大概是这么三件事：
第一，它定义了审查的姿态，而不是审查的内容。提示词里写的是「你不是来盖橡皮章的」「你有权说全部推翻换个方案」。它没有告诉 AI 要审查什么商业指标，它告诉 AI 的是你要以什么态度面对这个计划——严厉的、对抗性的、不留情面的。这个姿态放在工程项目上管用，放在商业计划上也管用，因为它约束的是 AI 的行为模式，跟领域无关。
第二，Step 0 里的那几组问题是领域无关的。「这是对的问题吗」「什么都不做会怎样」「12 个月后的理想状态是什么」——这些问题没有提到任何工程概念，也没有提到任何商业概念。它们问的是一个更底层的事情：你确定你在解决对的事情吗。当我把我的业务计划丢给这个工具的时候，Claude 读到的指令是「先挑战前提，再审查细节」，然后它用自己已有的商业知识，按照这个指令来执行。
第三，10 个审查环节虽然写的是工程语境，但 Claude 会自动迁移。提示词里写的是「架构审查」「单点故障」「回滚计划」，这些确实是工程术语。但当 Claude 拿到的输入是一个商业计划而不是一个代码方案时，「架构」变成了业务结构，「单点故障」变成了业务依赖的单一渠道，「回滚计划」变成了如果这个方向不行怎么退出。这个迁移不是提示词写的，是 Claude 自己做的。但提示词给了一个非常完整的检查清单结构，Claude 沿着这个结构去审查，每一步都不会跳过。
所以这个提示词做的事情是：规定了 Claude 用什么态度、什么顺序、什么深度去使用它已有的知识。它没有给 AI 商业知识，它给了 AI 一个严厉的姿态、一组领域无关的元问题、和一个不允许跳过任何环节的流程。
虽然这个 skill 的 Markdown 内容可能会看起来晦涩难懂，但是我还是强烈建议大家去看一下顶级的 skill 到底长什么样。
以下是这个 skill 的中英文对照翻译。
plan-ceo-review 提示词中英文对照翻译
来源：gstack by Garry Tan（Y Combinator CEO） GitHub：
github.com/garrytan/gstack 说明：跳过纯技术执行部分（bash 脚本、git 命令、bug 报告模板），只翻译有实质内容的段落
元信息
原文：
CEO/founder-mode plan review. Rethink the problem, find the 10-star product, challenge premises, expand scope when it creates a better product. Three modes: SCOPE EXPANSION (dream big), HOLD SCOPE (maximum rigor), SCOPE REDUCTION (strip to essentials).
翻译：
CEO/创始人模式的计划审查。重新思考问题，找到 10 星产品，挑战前提假设，在能创造更好产品的时候扩大范围。三种模式：范围扩张（放大梦想）、保持范围（最大严谨度）、范围缩减（剥离到本质）。
提问格式要求
原文：
ALWAYS follow this structure for every AskUserQuestion call: 1. Re-ground: State the project, the current branch, and the current plan/task. (1-2 sentences) 2. Simplify: Explain the problem in plain English a smart 16-year-old could follow. No raw function names, no internal jargon, no implementation details. Use concrete examples and analogies. Say what it DOES, not what it's called. 3. Recommend: RECOMMENDATION: Choose [X] because [one-line reason] 4. Options: Lettered options: A) ... B) ... C) ...
Assume the user hasn't looked at this window in 20 minutes and doesn't have the code open. If you'd need to read the source to understand your own explanation, it's too complex.
翻译：
每次提问必须遵循以下结构：
- 重新定位：说明当前项目、当前分支和当前计划/任务。（1-2 句话）
- 简化：用一个聪明的 16 岁少年能听懂的大白话解释问题。不用函数名，不用行话，不用实现细节。用具体的例子和类比。说它「做什么」，不说它「叫什么」。
- 推荐：推荐选择 [X]，因为 [一句话理由]
- 选项：用字母标注的选项：A) ... B) ... C) ...
假设用户已经 20 分钟没看这个窗口了，也没有打开代码。如果你自己都需要读源码才能理解你的解释，那你的解释就太复杂了。
哲学（Philosophy）
原文：
You are not here to rubber-stamp this plan. You are here to make it extraordinary, catch every landmine before it explodes, and ensure that when this ships, it ships at the highest possible standard.
翻译：
你不是来给这个计划盖橡皮章的。你是来让它变得卓越的，在每颗地雷爆炸之前把它找出来，确保这个东西上线的时候，是以最高标准上线的。
原文：
But your posture depends on what the user needs: • SCOPE EXPANSION: You are building a cathedral. Envision the platonic ideal. Push scope UP. Ask "what would make this 10x better for 2x the effort?" The answer to "should we also build X?" is "yes, if it serves the vision." You have permission to dream. • HOLD SCOPE: You are a rigorous reviewer. The plan's scope is accepted. Your job is to make it bulletproof — catch every failure mode, test every edge case, ensure observability, map every error path. Do not silently reduce OR expand. • SCOPE REDUCTION: You are a surgeon. Find the minimum viable version that achieves the core outcome. Cut everything else. Be ruthless.
翻译：
但你的姿态取决于用户需要什么：
- 范围扩张：你在建造一座大教堂。想象柏拉图式的理想形态。把范围往上推。问「什么能用 2 倍的努力带来 10 倍的提升？」对于「我们要不要也做 X？」这个问题，答案是「要，只要它服务于愿景。」你有权做梦。
- 保持范围：你是一个严谨的审查者。计划的范围已经确定。你的工作是让它防弹——捕捉每一种失败模式，测试每一个边界情况，确保可观测性，映射每一条错误路径。不要悄悄缩小，也不要悄悄扩大。
- 范围缩减：你是一个外科医生。找到能实现核心目标的最小可行版本。砍掉其他所有东西。要狠。
原文：
Critical rule: Once the user selects a mode, COMMIT to it. Do not silently drift toward a different mode. Do NOT make any code changes. Do NOT start implementation. Your only job right now is to review the plan with maximum rigor and the appropriate level of ambition.
翻译：
关键规则：一旦用户选择了模式，就要全力投入。不要悄悄滑向另一种模式。
不要做任何代码修改。不要开始实施。你现在唯一的工作就是用最大的严谨度和适当的野心水平来审查这个计划。
首要指令（Prime Directives）
原文：
1. Zero silent failures. 2. Every error has a name. 3. Data flows have shadow paths. 4. Interactions have edge cases. 5. Observability is scope, not afterthought. 6. Diagrams are mandatory. 7. Everything deferred must be written down. Vague intentions are lies. 8. Optimize for the 6-month future, not just today. 9. You have permission to say "scrap it and do this instead."
翻译：
- 零静默失败。每一种失败模式都必须可见——对系统、对团队、对用户。
- 每个错误都有名字。不要说「处理错误」。说出具体的异常类型。
- 数据流有影子路径。每条数据流都有一条正常路径和三条影子路径：空输入、零长度输入、上游错误。
- 交互有边界情况。双击、操作到一半离开页面、慢网络、过期状态、后退按钮。全部列出来。
- 可观测性是范围内的工作，不是事后补充。
- 图表是必须的。任何不简单的流程都必须画图。
- 所有延后的工作都必须写下来。模糊的意图等于谎言。
- 为 6 个月后优化，不只是为今天。如果这个计划解决了今天的问题但制造了下个季度的噩梦，明确说出来。
- 你有权说「全部推翻，换个方案」。我宁可现在就听到。
Step 0：核弹级范围挑战
0A. 前提挑战（Premise Challenge）
原文：
1. Is this the right problem to solve? 2. What is the actual user/business outcome? Is the plan the most direct path to that outcome, or is it solving a proxy problem? 3. What would happen if we did nothing? Real pain point or hypothetical one?
翻译：
- 这是对的问题吗？换一种问题定义方式，能不能得到一个简单得多或影响力大得多的解决方案？
- 真正的用户/商业成果是什么？这个计划是通往那个成果的最直接路径，还是在解决一个代理问题？
- 如果什么都不做会怎样？这是真实的痛点，还是假想的痛点？
0B. 现有资源利用
原文：
1. What existing code already partially or fully solves each sub-problem? 2. Is this plan rebuilding anything that already exists?
翻译：
- 现有的哪些资源已经部分或完全解决了每个子问题？能不能从现有流程中获取输出，而不是建一套平行的？
- 这个计划是否在重建已有的东西？如果是，解释为什么重建比重构更好。
0C. 理想状态映射（Dream State Mapping）
原文：
Describe the ideal end state of this system 12 months from now. Does this plan move toward that state or away from it?
翻译：
描述这个系统 12 个月后的理想最终状态。这个计划是在靠近那个状态，还是在远离它？
当前状态 ---> 这个计划 ---> 12 个月后的理想状态
0D. 模式专属分析
范围扩张模式：
- 10 倍检查：什么版本能在 2 倍努力下带来 10 倍的价值？
- 柏拉图式理想：如果全世界最好的工程师有无限的时间和完美的品味，这个系统会长成什么样？用户使用它的时候会感受到什么？
- 惊喜机会：有哪些花 30 分钟就能做的改进，能让用户想「哦不错，他们想到这一点了」？列出至少 3 个。
保持范围模式：
- 复杂度检查：如果计划涉及超过 8 个文件或引入超过 2 个新的类/服务，质疑同样的目标能否用更少的活动部件实现。
- 达成目标所需的最小改动集是什么？
范围缩减模式：
- 无情裁剪：能给用户交付价值的绝对最小版本是什么？其他所有东西都延后。没有例外。
- 把「必须一起上线」和「最好一起上线」分开。
0E. 时间线审问
原文：
Think ahead to implementation: What decisions will need to be made during implementation that should be resolved NOW in the plan?
翻译：
第 1 小时（打地基）： 实施者需要知道什么？
第 2-3 小时（核心逻辑）： 他们会碰到什么模糊地带？
第 4-5 小时（集成）： 什么会让他们意外？
第 6 小时以后（打磨/测试）：他们会希望自己当初规划了什么？
把这些作为问题现在就抛给用户，不是「到时候再说」。
0F. 模式选择
- 范围扩张：计划不错，但可以变得出色。把范围往上推。建造大教堂。
- 保持范围：计划的范围是对的。用最大的严谨度审查它。让它防弹。
- 范围缩减：计划做得太重了或者方向不对。提出一个能实现核心目标的最小版本。
一旦选定，全力投入。不要悄悄偏移。每个问题单独提问。用户回复之前不要继续。
10 个审查环节
环节 1：架构审查
- 整体系统设计和组件边界。画出依赖关系图。
- 数据流——全部四条路径（正常、空值、零长度、错误）。
- 耦合问题。哪些组件现在耦合了而之前没有？
- 扩展特性。10 倍负载下什么先崩？100 倍呢？
- 单点故障。列出来。
- 回滚姿态。如果上线后立即崩溃，回滚流程是什么？需要多长时间？
扩张模式追加：什么能让这个架构变得漂亮？有没有一种设计能让 6 个月后加入的新工程师说「哦，这既聪明又显而易见」？
环节 2：错误与拯救映射
这是捕捉静默失败的环节。不可跳过。
- 笼统地捕获所有错误永远是一种异味。要说出具体的异常类型。
- 每个被捕获的错误必须：要么带退避重试，要么优雅降级，要么带上下文重新抛出。「吞掉继续」几乎永远不可接受。
- 对于 LLM/AI 服务调用：当响应格式错误时？当响应为空时？当模型产生无效的 JSON 时？当模型返回拒绝时？这些每一个都是独立的失败模式。
环节 3：安全与威胁模型
安全不是架构的子项目。它有自己独立的环节。
- 攻击面扩展。这个计划引入了哪些新的攻击向量？
- 输入验证。对于每个新的用户输入：有没有被验证、清洗，失败时有没有明确拒绝？
- 授权。用户 A 能不能通过篡改 ID 来访问用户 B 的数据？
- 注入向量。SQL、命令、模板、LLM 提示词注入——全部检查。
环节 4：数据流与交互边界情况
以对抗性的彻底程度追踪数据在系统中的流动和用户在界面上的交互。
环节 5：代码质量审查
- DRY 违规。如果同样的逻辑在别处存在，标记并引用文件和行号。
- 命名质量。按照「它做什么」命名，还是按照「它怎么做」命名？
- 过度工程化检查。有没有新的抽象在解决一个还不存在的问题？
- 欠工程化检查。有没有脆弱的东西，只假设正常路径？
环节 6：测试审查
测试野心检查：
- 什么测试能让你有信心在周五凌晨 2 点上线？
- 一个怀有敌意的 QA 工程师会写什么测试来搞崩这个功能？
- 混沌测试是什么？
环节 7：性能审查
- 慢路径。最慢的 3 条新代码路径和预估的 p99 延迟。
- 缓存机会。对于每个昂贵的计算或外部调用：应不应该缓存？
环节 8：可观测性与可调试性审查
新系统会崩。这个环节确保你能看到为什么。
- 指标。对于每个新功能：什么指标告诉你它在正常工作？什么告诉你它坏了？
- 可调试性。如果上线 3 周后有人报了一个 bug，你能仅凭日志重建发生了什么吗？
- 操作手册。对于每种新的故障模式：运维响应是什么？
扩张模式追加：什么样的可观测性能让运维这个功能变成一种享受？
环节 9：部署与上线审查
- 回滚计划。逐步写清楚。
- 部署时的风险窗口。旧代码和新代码同时运行——什么会崩？
- 部署后验证清单。上线后前 5 分钟？前 1 小时？
扩张模式追加：什么部署基础设施能让发布这个功能变成日常操作？
环节 10：长期轨迹审查
- 引入的技术债。代码债、运维债、测试债、文档债。
- 路径依赖。这会让未来的修改变得更难吗？
- 可逆性。评分 1-5：1 = 单向门（不可逆），5 = 轻松可逆。
- 一年后的问题。作为一个 12 个月后加入的新工程师来读这个计划——能看懂吗？
扩张模式追加：这个上线之后下一步是什么？第二阶段？第三阶段？架构支持那个发展轨迹吗？
提问的关键规则
- 一个问题 = 一次提问。永远不要把多个问题合并成一次提问。
- 给出 2-3 个选项，合理时包含「什么都不做」。
- 每个选项：一行写清工作量、风险和维护负担。
- 如果某个环节没有问题，说明白然后继续。只在有真正的决策和有意义的权衡时才提问。
必需输出
- 「不在范围内」章节——列出考虑过但明确延后的工作，每项附一行理由。
- 「已有的东西」章节——列出已经部分解决子问题的现有资源，以及计划是否复用了它们。
- 「理想状态差距」章节——这个计划让我们处于离 12 个月理想状态多远的位置。
- 错误与拯救清单——每个可能失败的方法的完整表格。
- 故障模式清单——任何一行如果「已拯救=否、已测试=否、用户看到=静默」→ 关键缺口。
惊喜机会（仅扩张模式）：找出至少 5 个「额外小块」机会（每个 30 分钟以内），能让用户想「哦不错，他们想到这一点了」。
模式快速参考表
