认知模式切换
输入“/”快速插入内容
认知模式切换
认知模式切换
用户1208用户12085月29日修改
阅读时间：约 10 分钟前置条件：Claude Code Skills（技能模块）基础、计划模式相关：「计划流水线」、「计划驱动开发」
TL;DR
一个通用助手会将所有阶段混在一起。这个模式为每个阶段提供独特的认知模式：你为手头的工作召唤合适的大脑，当工作性质改变时切换。
代码块
/plan-ceo-review → 「我们在构建正确的东西吗？」
/plan-eng-review → 「我们如何让这个可实现？」
/review → 「什么会在生产中炸掉？」
/ship → 执行发布，不再争论
/browse → 它在浏览器中实际能用吗？
/retro → 这周我们交付得怎么样？
洞察在于：规划、审查和交付需要根本不同的认知姿态——一个处于通用模式的单一助手会把它们混淆得很糟糕。
六个档位
命令 | 角色 | 核心问题 | 何时切换 |
/plan-ceo-review | 创始人 / CEO | 「我们在构建正确的东西吗？」 | 写任何代码之前 |
/plan-eng-review | 工程经理 / 技术负责人 | 「我们如何让这个可实现？」 | 方向锁定后 |
/review | 偏执的资深工程师 | 「还有什么可能在生产中崩溃？」 | 合并之前 |
/ship | 发布工程师 | 「让飞机着陆」 | 分支就绪，不再争论 |
/browse | QA 工程师 | 「它实际上能用吗？」 | 部署后，针对 staging 或 prod |
/retro | 工程经理 | 「我们交付得怎么样？」 | 每周或发布后 |
填补的空缺：实现前的战略门控
AI 编程助手最难做对的事不是实现。而是在此之前的问题：我们在构建正确的东西吗？
Claude Code 被优化为构建你要求的东西。如果你说「添加照片上传」，它就会添加照片上传。它不会问照片上传是否真的是产品需要的。这就是 /plan-ceo-review 要解决的问题。
示例：你在构建一个类 Craigslist 的挂牌应用。
•
请求：「让卖家为商品上传照片」
•
字面实现：文件选择器 + 图片保存
•
真实产品是什么：帮助卖家创建真正能卖出去的挂牌
如果你先运行 /plan-ceo-review，助手会被明确要求挑战字面请求，找出其中隐藏的产品。输出变成了完全不同的简报：从照片自动识别产品、拉取规格和定价对比、起草标题和描述、建议主图、在上线前检测低质量照片。
这是一个不同的功能。更好的功能。而你只有通过在实现开始前插入一个明确的门控才能得到它。
/plan-ceo-review 内部的三种模式：
•
扩展范围 — 寻找 10 星产品，问「付出 2 倍的努力，什么能让这个好 10 倍？」
•
保持范围 — 接受方向，让计划无懈可击
•
缩减范围 — 无情地精简到最小可行版本
用户选择模式。助手承诺并不偏离。
/plan-eng-review：让想法变得可构建
一旦方向锁定，认知模式从产品直觉转向工程严谨。/plan-eng-review 是理想化停止、架构开始的地方。
应产生的内容：
•
架构图（组件、边界、数据流）
•
核心流程的状态机
•
同步 vs 异步边界决策
•
失败模式和重试逻辑
•
信任边界（你在哪里接受外部输入？）
•
测试矩阵
关键突破是强制生成图表。图表能发现散文掩盖的隐藏假设。时序图让你明确谁调用什么。状态机让你枚举每一个失败模式。没有它们，「系统会处理它」会无限期地保持模糊。