GStack 实战：用 AI 工具链从零搭建个人技术博客
什么是 GStack
GStack 是 Garry Tan（Y Combinator CEO）打造的一套 Claude Code 技能系统。它提供了十几个 / 命令，覆盖软件开发的完整生命周期：
| 阶段 | 命令 | 做什么 |
|---|---|---|
| 产品设计 | /office-hours | YC 风格的创业诊断或创意头脑风暴 |
| 需求文档 | /spec | 将模糊需求转化为可执行的 Issue |
| 架构审查 | /plan-eng-review | 检查架构、边界情况、测试覆盖 |
| 全流程审查 | /autoplan | CEO → Design → Eng → DX 四阶段自动审查 |
| 代码审查 | /review | 检查当前 diff 的正确性和简洁性 |
| QA 测试 | /qa | 端到端验证功能是否正常工作 |
| 发布 | /ship | 创建 PR 并自动关联 Issue |
这些命令不是简单的 prompt 模板——每个 skill 文件有数百行指令，定义了严格的决策框架、输出格式和检查清单。
GStack 的核心理念
GStack 的设计哲学贯穿在所有 skill 中：
"Boil the Ocean" —— 一次做完整件事。 AI 让完整性的边际成本趋近于零。与其分 5 次迭代，不如一次性覆盖所有边界情况、错误路径和测试。这不是浪费——这是最高效的方式。
双模型审查。 /autoplan 和 /review 会同时调用 Claude 和 Codex（OpenAI 的 CLI 工具）做独立审查，然后对比两份输出。两个模型都同意的结论是高置信度信号；分歧则标记为需要人工判断的 taste decision。
决策审计。 每个自动决策都记录在案的 audit trail——用了哪条原则、拒绝了哪个方案、为什么。不是魔法黑箱，是可追溯的工程决策。
Founder mindset。 GStack 的语调是 Garry Tan 本人的——直接、不废话、对模糊零容忍。它不是你的 AI 助手，它是你的 YC partner。
我如何用 GStack 搭建这个博客
1. /office-hours —— 先想清楚再动手
我带着一个简单的需求出发："我需要一个个人技术博客来吸引副业客户。"
GStack 没有直接开始写代码。它先问了六个 YC 式的诊断问题：
- 需求验证： 有没有人真的需要你的博客？我承认是"提前布局"——目前还没有客户问我要过 portfolio。
- 现状： 目前完全没有线上品牌。博客脚手架是唯一资产。
- 目标客户： 我一开始说"来者不拒"。GStack 追问了两次，直到我说出"AI + 自动化工具链"这个内容方向。
这个过程把我模糊的"建个博客"变成了一个清晰的命题：用 AI 自动化方向的技术内容，通过搜索引擎吸引潜在客户。
然后 GStack 挑战了三个前提：
- 博客是获客的正确渠道 ✓
- 需要完整功能才能建立信任 ✓
- 中英双语从一开始就是必要的 ✓
最后输出了三个方案（先写内容 / 先上中文版 / 完整版），我选了完整版。GStack 推荐渐进方案但尊重我的选择——这是 founder 的信号。
2. 设计文档经历 3 轮审查
GStack 产出了一份设计文档，然后启动了一个独立的 Claude 子 agent 做审查。第一轮给了 5/10——数据模型缺失、Pagefind 集成方案模糊、Giscus Discussion 创建流程有事实错误。
修复后再审：6/10——Pagefind 和 SSR 存在根本冲突（Pagefind 需要静态 HTML），Giscus 的 Discussion 创建流程还是有问题。
第三轮：7/10。Pagefind 切换为静态导出方案（output: 'export'），Giscus 修正为 pathname 映射 + 首次评论触发 Discussion 创建。通过了。
这种"写 → 审 → 修 → 再审"的循环，如果没有 AI 的审查能力，需要至少两个高级工程师花半天时间。现在 10 分钟完成。
3. 代码实现：5 个 Phase，15 个测试
Plan 通过后实现了 5 个阶段：
- Phase 1： 把硬编码占位数据替换为真实 MDX 渲染 + 代码高亮
- Phase 2： 静态导出、SEO（OG/hreflang）、RSS、Sitemap
- Phase 3： Giscus 评论、Pagefind 搜索（含搜索 UI 组件）
- Phase 4： 暗色模式修复（next-themes）、404 页面、移动端汉堡菜单
- Phase 5： 15 个组件测试（vitest + testing-library）
bun run build 一次通过。16 个静态页面，Pagefind 索引 14 页。
我学到的
AI 审查的价值被低估了。 大部分人用 AI 写代码，但很少人用它审查设计文档。/office-hours 的设计文档 3 轮审查找到了 2 个事实错误和 1 个架构冲突（Pagefind + SSR），这些问题是手工审查几乎不可能发现的。
GStack 的完整循环才有复利。 单独用 /office-hours 或单独用 /spec 都有价值，但 plan → design → review → ship 的完整流程才是 GStack 的核心。每个阶段产生的内容（设计文档、审计记录、审查报告）都会被后续阶段自动发现和使用。
"Boil the Ocean" 是真实的效率提升。 一次性写完全部测试、处理完所有边界情况、建好完整的 CI/CD——表面上看"做多了"，实际上因为 AI 的边际成本为零，完整性比渐进式开发的总体成本更低。
写在最后
这个博客本身就是 GStack 能力的最好证明。你正在读的这篇文章所在的网站，从产品设计到代码实现，全部由 GStack 驱动的 AI 工作流完成。
如果你也在用 Claude Code 做开发，GStack 值得一试。
下一篇预告：如何用 n8n + Claude API 搭建自动化内容发布工作流。