🎯 学什么：一键运行 CEO → 设计 → 工程三层评审管道。不是三个独立评审，而是一个有前后依赖的评审管道——前一步不过关，绝不浪费时间去下一步。核心洞察：(1) "局部优化"陷阱非常常见——单层看起来都不错，但跨层存在矛盾：CEO 说战略正确，工程说技术可行，但没人验证过用户需不需要；(2) autoplan 最值钱的地方不是"AI 帮你做决策"，而是"AI 确保你不跳过任何关键步骤"；(3) CEOBLOCK 后管道立即停止——因为"如果不值得做，就别浪费时间讨论怎么做"。 💡 难易度：⭐⭐⭐⭐ | ⏱️ 预计时间：40 分钟
[!quote]- 📖 原Skill精要 技能名称：autoplan 核心功能：自动评审管道——从磁盘读取完整的 CEO/设计/工程/DX 评审 Skill，使用六条决策原则依次运行并自动决策。在最终审批关口弹出品味决策。一个命令输出完整评审计划。 所属体系：gstack 虚拟工程团队 协作关系：串联 [[L6-02-CEO战略评审|plan-ceo-review]]、[[L6-05-设计计划评审|plan-design-review]]、[[L6-03-工程架构评审|plan-eng-review]] 形成完整管道
1. 课程概览
💡 白话小课堂：autoplan 的核心思想就一个——"如果不值得做，就别浪费时间讨论怎么做"。它把三个独立评审串联成一个有前后依赖的管道：CEO 评审不过 → 不浪费时间去设计评审；设计评审不过 → 不浪费时间去做工程评审。
2. 评审管道
Review Pipeline
autoplan 将三个评审串联成管道：
CEO 评审（战略） ↓ 通过 设计评审（视觉/交互） ↓ 通过 工程评审（架构/技术） ↓ 通过 准备开发
管道逻辑： → 前一步通过才进行下一步 → CEO 评审不过 → 不浪费时间去设计评审 → 设计评审不过 → 不浪费时间去做工程评审
每一次评审的输出是下一次评审的输入。 每一步发现的问题会影响后续评审的关注点。
3. 为什么需要全流程
Why Full Pipeline?
避免"局部优化"陷阱
单独做 CEO 评审：战略看起来很棒 但可能技术上完全不可行（工程评审会说 no）
单独做工程评审：架构设计很优雅 但可能没人需要这个产品（CEO 评审会说 no）
全流程评审确保： → 值得做（CEO） → 能做好（设计） → 能做出来（工程）
发现跨层矛盾
CEO 评审说"这是核心差异化" → 但工程评审发现"这需要 3 个月的基建" → 矛盾浮出水面 → 可能需要回到 CEO 评审重新权衡
⚠️ 避坑指南："局部优化"陷阱非常常见——CEO 很兴奋地说"我们做 XX 一定能成"，工程师们也兴奋地说"技术上很简单"，但没人想过"如果用最简单的方式实现，用户真的需要吗？"autoplan 强制三层都审视一遍，避免集体盲点。
4. 评审流程
Pipeline Flow
Step 1: 加载计划文档 → 从 office-hours 或其他来源 → 提取关键决策和假设
Step 2: CEO 评审 → 野心、范围、战略一致性 → 如果 CEOPASS → 进入设计评审 → 如果 CEOBLOCK → 停止，输出 CEO 问题
Step 3: 设计评审 → 设计系统、用户体验、视觉一致性 → 如果 DESIGNOK → 进入工程评审 → 如果 DESIGNREVISE → 修复后重新检查
Step 4: 工程评审 → 架构、技术选择、可扩展性 → 产出最终评审报告
Step 5: 汇总报告 → 三层评审的综合结果 → 决策建议和优先级排序 → 交叉模型验证意见（如有）
5. 自动化 vs 人工判断
Automation vs Human Judgment
autoplan 自动化的部分： ✅ 按正确顺序运行评审 ✅ 确保不跳过步骤 ✅ 跟踪决策的上下游影响 ✅ 汇总多来源的评审意见
autoplan 不替代的部分： ❌ 人类的最终决策权 ❌ 领域的专家判断 ❌ 不可量化因素的权衡
AI 的建议是"强烈推荐"，不是"默认执行"。 每个 STOP 点都需要人类确认。
🔑 核心秘诀：autoplan 最值钱的地方不是"AI 帮你做决策"，而是"AI 确保你不跳过任何关键步骤"。
6. 结构拆解：自动全流程 Skill 模板
自动全流程评审型 Skill 模板
核心特征
→ 管理对象 = 从 idea 到开发计划的完整评审管道 → 核心原则 = 前一步通过才进行下一步 + 避免局部优化 + 人类最终决策权 → 关键设计 = 三阶段管道 + CEOBLOCK 阻断 + 跨层矛盾检测
通用结构
Three-Stage Pipeline（三阶段管道）
- Stage 1: CEO 评审（战略层）—— 野心/范围/战略一致性
- Stage 2: 设计评审（体验层）—— 设计系统/UX/视觉一致性
- Stage 3: 工程评审（技术层）—— 架构/技术选择/可扩展性
- 管道逻辑：前一步不过 → 后续全部停止
Pipeline Flow（流程步骤）
- Step 1: 加载计划文档（提取决策和假设）
- Step 2-4: 依次执行三层评审
- Step 5: 汇总报告（综合结果 + 决策建议 + 优先级）
Key Principles（关键原则）
- 避免局部优化陷阱：单层正确 ≠ 全局正确
- 跨层矛盾检测：CEO/设计/工程三层意见冲突点
- 自动化 vs 人工：管道确保步骤完整性，人类保留最终决策
7. 电商案例：用 autoplan 评审拼团功能
🛒 实战案例：某社交电商App计划开发"直播带货小程序"（微信小程序内嵌直播间+商品橱窗+下单闭环）。团队预估10周开发、前后端6人投入。autoplan从CEO→设计→工程三层穿透评审。
- CEO评审层：核心假设——"用户会在直播间里直接下单"。验证数据：竞品抖音直播间的下单转化率约2-3%，但该App的用户行为数据显示90%的用户是从直播间"加购物车后退出到主页再下单"。这意味着用户把直播间当"商品发现"而非"交易闭环"。CEO评审结论——CONCERN：先做"直播间→商品详情页"的跳转链，验证加购率能否从当前3%提升到8%，再做闭环下单。开发周期从10周压缩到3周。
- 设计评审层：流程图拆解——当前设计8个步骤（进入直播→看商品弹窗→点商品→加购物车→退出直播→到购物车→选规格→下单）。冗余点在于"商品弹窗"和"商品详情页"展示了80%重复信息。精简方案：直播间底部固定"小黄车"图标→一键展开商品列表浮层→在当前页完成规格选择和加购（不跳页）。预期步数从8步降到3步，加购完成率从3%预估提升到12%。
- 工程评审层：直播间的核心工程挑战是低延迟（HLS vs WebRTC）、商品列表实时同步（主播上下架商品需推送到所有观众端）、消息并发（弹幕+下单消息）。方案选择：WebRTC做直播推流（延迟<1秒）、WebSocket做商品同步（广播模式，单房间最高支撑5万并发观众）、Redis ZSET做弹幕限流（每人每5秒一条）。评审发现：WebSocket方案未处理房间维度的心跳检测——修复方案：观众端每30秒发PING，5秒无PONG则自动重连。
汇总结论：不做"10周开发完整直播闭环小程序"，改为"3周做直播间→商品详情页跳转+小黄车浮层加购"。验证指标：加购转化率从3%提升到8%以上。达成后才投入第二阶段闭环下单。三层评审中CEO评审省了7周——如果先做工程评审（技术上直播闭环完全可以实现），会做出一个流畅但无人下单的直播间。
🔑 启示：autoplan的核心价值是"局部优化"检测——工程做得好、设计做得美、但战略前提有问题。三个视角穿一条线：先问值不值得做，再问怎么做最流畅，最后问技术上怎么实现最稳。
8. 掌握检验
Q1：autoplan 管道中，为什么 CEO 评审必须排在设计评审之前？
- A) 因为 CEO 评审的难度更高
- B) 因为如果战略上不值得做，讨论设计是浪费资源
- C) 因为 CEO 的工资比设计师高
- D) 因为设计评审需要 CEO 的评审结果作为输入文件
Q2：以下哪个场景属于 autoplan 试图避免的"局部优化"陷阱？
- A) 架构设计优雅，但产品没人需要
- B) 代码审查通过，但性能测试不达标
- C) 数据库选型合理，但 API 命名不一致
- D) 单元测试覆盖率高，但集成测试缺失
Q3：在拼团案例中，autoplan 汇总报告建议"先做 1 周拼团价 + 分享链接，而非 4 周完整拼团"。这个建议体现了管道的哪一项核心价值？请从三层评审各自的角度解释这个决策是怎么得出来的。
Q4：如果 autoplan 管道在 CEO 评审阶段输出了 CEOBLOCK，后续流程应该怎样？为什么这样做是最高效的？
Q5：autoplan 声明"不替代人类的最终决策权"。但在实际工作中，如何判断哪些决策应该采纳 AI 的强烈推荐，哪些应该坚持人的判断？以拼团案例中的"分享率"阈值（10%）为例进行讨论。
9. 答案
点击查看答案
Q1：B —— 管道逻辑的核心是"前一步通过才进行下一步"。
Q2：A —— "局部优化"陷阱即：单独看每个层级都不错，但跨层存在矛盾——CEO 说战略正确，工程说技术可行，但没人真正验证过用户需不需要。
Q3：CEO 层发现核心假设未验证（"用户愿意社交分享"），给出条件通过的建议；设计层发现"发起拼团"的心理门槛太高，建议简化为"以拼团价购买+分享链接"；工程层确认核心逻辑可复用秒杀库存。三层形成合力：CEO 说"先验证假设"、设计说"降低门槛来验证假设"、工程说"降低门槛后技术上更简单"——于是"1 周验证版本"成为自然结论。
Q4：如果 CEOBLOCK，管道停止，不再进入设计评审和工程评审。这是最高效的——因为管道的核心理念是"如果不值得做，就别浪费时间讨论怎么做"。CEO 问题被优先暴露在最便宜的阶段，修复后重新走管道。
Q5：AI 的推荐基于行业数据和模式识别（电商分享率的参考范围），但它不知道具体业务的特殊性（如产品特性、用户画像的特殊性）。人的判断把握业务上下文——如果 PM 知道自己的用户群体格外有社交属性，下调到 5% 是合理的。最佳实践：AI 推荐作为"基准线"，人类基于更丰富的上下文做"调整"，并记录调整理由——这样未来可以复盘谁判断更准。
（4/5 通过）
10. 延伸阅读
- [[L6-05-设计计划评审|下一课：设计计划评审 —— 确保产品设计在开工前就对了]]
评论区
共 0 条评论