GStack 实战指南 | 第2期 - 产品与架构：用 CEO 与技术总监视角锁定项目边界
💡 俗话说，写代码只占开发的 20%，剩下 80% 的时间在弄清楚"到底该写什么"以及"写错了怎么重构"。GStack 提供的第一道防线，就是在写代码前把这两个痛点锁死。
为什么要让 AI 扮演 CEO？
在全栈独自开发的场景下，极易陷入 严重的范围蔓延（Scope Creep）。比如，你最初只想做个任务大屏，结果写着写着，就开始加黑夜模式切换、加高级动画库、甚至折腾一个极其复杂的自定义日历组件……一周过去了，核心业务都还没跑通。
Garry Tan 加入 /plan-ceo-review（还有它的姊妹指令 /office-hours）的作用，就在于 给你一棒子，让你回到正确的轨道上。
/plan-ceo-review 深度解析
它在幕后做了什么？
当你输入 /plan-ceo-review 时，GStack 会给 Claude 注入一段特殊的系统提示词，将它转变为一个"严肃的 CEO"。这个角色有明确的行为准则：
▪️ 不能讨好你：不会说"这个想法很棒"，只会评估可行性 ▪️ MVP 优先：所有建议都围绕最小可行产品展开 ▪️ 资源意识：时刻考虑你的开发时间和技术栈复杂度 ▪️ 商业价值导向：每个功能都必须回答"为什么用户需要这个"
实战演示：一步步走通 CEO 评审
假设你正在开发一个个人博客系统，想加一些"酷炫"的功能：
/plan-ceo-review
我想在文章页面加上这些功能：
1. Web3 钱包打赏（MetaMask 集成）
2. 实时评论系统（WebSocket）
3. 文章阅读进度条
4. AI 自动生成文章摘要Claude（CEO 模式）的典型回复：
## CEO 评审意见
### ❌ 拒绝：Web3 钱包打赏
**理由**：你的站点月活用户不足 200。引入 `ethers.js`（gzip 后 120KB）
会使打包体积增大 40%，且 Web3 钱包用户在国内渗透率极低。
**替代方案**：放一张赞赏码图片，零成本，转化率更高。
### ❌ 搁置：实时评论系统
**理由**：WebSocket 长连接需要额外的服务器成本和运维复杂度。
当前阶段应验证"是否有人看你的文章"，而不是"评论体验好不好"。
**替代方案**：接入 Giscus（基于 GitHub Discussions），零运维成本。
### ✅ 通过：阅读进度条
**理由**：实现成本极低（纯 CSS + 少量 JS），能有效提升用户
阅读体验和页面停留时间。
### ⚠️ 通过（有条件）：AI 文章摘要
**理由**：对 SEO 有实际价值，但不应在客户端实时调用 API。
**条件**：摘要必须在文章发布时生成并缓存，不允许每次访问都调 API。关键洞察：CEO 模式不是简单地说"不"，它会给出 具体的替代方案 和 量化的理由（比如包体积增大 40%）。这比你自己拍脑袋决策要靠谱得多。
/office-hours 的补充用法
如果你对 CEO 的评审结果不服气，或者想进一步讨论，可以用 /office-hours：
/office-hours
关于 Web3 打赏被拒绝的问题——如果我的目标用户群就是区块链开发者呢？
我的博客主要写 Solidity 教程。→ 此时 CEO 会重新评估，可能因为目标用户群的变化而调整结论。这不是"翻案"，而是在新信息下的理性决策。
/plan-eng-review 深度解析
为什么必须在写代码前做架构审查？
无数"屎山"诞生的根源是给 AI 下达模糊的指令，比如"给这页加上权限管理"。一旦涉及状态提升、数据穿透，它就开始胡乱引入文件和全局变量。
/plan-eng-review 让 Claude 变为经验丰富的 Tech Lead（技术总监）。它的核心原则是：只做设计，不写实现。
实战演示：产出架构方案
紧接前面的 CEO 评审结果——假设阅读进度条和 AI 摘要都通过了：
/plan-eng-review
根据 CEO 评审通过的需求，请规划以下两个功能的技术方案：
1. 文章阅读进度条
2. AI 文章摘要（发布时生成并缓存）
当前技术栈：Next.js 14 + Tailwind CSS + SupabaseClaude（Tech Lead 模式）的典型输出：
## 技术架构方案
### 功能一：阅读进度条
**组件层级**：
ArticlePage
├── ReadingProgressBar ← 新增（fixed 定位在顶部）
├── ArticleHeader
├── ArticleContent ← 需要 ref 获取滚动高度
└── ArticleFooter
**状态设计**：
- 使用 `useEffect` + `scroll` 事件监听
- 计算公式：progress = scrollTop / (scrollHeight - clientHeight) × 100
- ⚠️ 必须使用 `throttle`（建议 16ms 节流）防止高频触发重渲染
**CSS 要点**：
- 使用 `transform: scaleX()` 而非 `width` 动画（GPU 加速，不触发 reflow）
- `position: fixed; top: 0; z-index: 50;`
- ⚠️ 检查与现有 NavBar 的 z-index 层级关系，避免遮挡
### 功能二：AI 文章摘要
**数据流**：
文章发布 → API Route → OpenAI API → 写入 Supabase
**数据库变更**：
ALTER TABLE articles ADD COLUMN summary TEXT;
ALTER TABLE articles ADD COLUMN summary_generated_at TIMESTAMPTZ;
**接口定义**：
POST /api/articles/[id]/generate-summary
Request: { articleId: string }
Response: { summary: string, generatedAt: string }
**防护措施**：
- ⚠️ 该接口必须鉴权（仅管理员可调用），防止被滥用消耗 API 额度
- ⚠️ 加入幂等校验：如果 summary_generated_at 在 24h 内，拒绝重复生成
- ⚠️ OpenAI 调用需设置 timeout（建议 30s），失败时返回 null 而非报错关键洞察：Tech Lead 不只是画组件树。它会标注 ⚠️ 警告来提醒你容易踩的坑——z-index 冲突、接口鉴权遗漏、性能陷阱。这些都是真实开发中最容易忽略的细节。
两个角色的协作流程
完整的 GStack 前期评审流程是一个漏斗模型：
┌─────────────────────┐
│ 你的原始需求列表 │ ← 10 个想法
└──────────┬──────────┘
↓
┌─────────────────────┐
│ /plan-ceo-review │ ← 砍到 3 个
│ CEO 产品评审 │
└──────────┬──────────┘
↓
┌─────────────────────┐
│ /plan-eng-review │ ← 细化为可执行方案
│ Tech Lead 架构评审 │
└──────────┬──────────┘
↓
┌─────────────────────┐
│ 开始写代码！ │ ← 每一行代码都有依据
└─────────────────────┘这个漏斗的价值在于：你的每一行代码都有出处。 CEO 说了要做什么，Tech Lead 说了怎么做，你只需要填充具体实现。当 AI 后续帮你编码时，它也能参照这份架构文档，大幅降低"跑偏"的概率。
实战技巧
技巧一：评审文档要存档
CEO 和 Tech Lead 的评审结果不要只看一眼就关掉。建议在项目中创建一个 docs/ 目录：
docs/
├── ceo-review-v1.md # CEO 评审记录
├── eng-review-v1.md # 架构方案
└── ceo-review-v2.md # 需求变更后的二次评审技巧二：迭代式评审
不要一次性把所有功能都丢给 CEO 评审。正确的做法是：
- 第一轮：核心业务功能（登录、主页、核心交互）
- 第二轮：增强功能（搜索、筛选、个性化）
- 第三轮：锦上添花（动画、主题切换、分享）
每一轮都走 CEO → Tech Lead → 编码 → /review 的完整闭环。
技巧三：引用上下文
在调用 /plan-eng-review 时，务必提到 CEO 评审的结论：
/plan-eng-review
根据刚才 CEO 评审的结论（阅读进度条通过，Web3 打赏被拒绝），
请为通过的功能做技术架构规划。这样 Tech Lead 不会去规划已经被砍掉的功能，避免浪费 Token。
小结
▪️ /plan-ceo-review 解决的是 "做什么" 的问题——用商业思维砍需求 ▪️ /plan-eng-review 解决的是 "怎么做" 的问题——用工程纪律定架构 ▪️ 两者配合使用，就像给你的 AI 开发流程上了一道双保险 ▪️ 评审文档要存档、要迭代、要引用，它是后续编码和审查的基石
在下一篇文章中，我们将进入 GStack 开发流中最残酷的审计阶段：/review 对抗性代码审查。
好了，本期的内容到这里就结束了，如果你觉得对你有帮助的话，欢迎点赞、在看、转发，我们下期见！Bye~
📝 作者：NIHoa ｜ 系列：GStack实战指南系列 ｜ 更新日期：2025-04-14