Superpowers 实战：AI 编程如何让我半天完成两周的工作
什么是 Superpowers
Superpowers 不是某个具体的工具——它是一种新的工作方式。当你把 AI 编程工具（Claude Code、Cursor、Copilot）和一个结构化的开发流程结合起来，产生的效果不是"快一点"，而是质变。
传统开发流程：想需求 → 画原型 → 写设计文档 → 评审 → 开发 → 测试 → 部署 → 写文档。每一步依赖不同的人、不同的时间窗口，整个流程拉长到数周。
AI 模式：向 AI 描述目标 → AI 追问澄清 → 产出设计文档 → AI 自我审查 → 生成代码 → AI 写测试 → 部署。全程一个人，半天完成。
这不是理论。这篇文章记录的就是我今天的真实经历。
从零到上线：一个个人博客的完整构建
起点：一个模糊的想法
我的原始需求只有一句话："我需要一个个人技术博客来展示能力、吸引副业客户。"
正常流程下，这句话之后会发生：找设计师出图（2-3 天）、前端开发（3-5 天）、后端开发或 CMS 配置（2-3 天）、部署和域名配置（1 天）、测试（1-2 天）。乐观估计两周。
实际发生的是：我在 Claude Code 里打了 /office-hours。
第一阶段：设计诊断（10 分钟）
AI（以 YC partner 的角色）没有直接开始写代码。它先追问了三个关键问题：
-
需求验证： "有人真的需要你的博客吗？有没有客户问过你要 portfolio？"我承认目前是提前布局，没有实际需求信号。这个坦诚很重要——它意味着我应该控制投入，不追求完美。
-
现状分析： "你现在怎么解决展示能力的问题？"没有。完全没有线上品牌。
-
目标客户： "你想吸引什么样的客户？"我一开始说"什么样的都行"。AI 追问了两次，直到我明确说出"AI + 自动化工具链"这个内容方向。
三个前提被明确提出并挑战：
- 博客是获客的正确渠道吗？取决于内容和 SEO。
- 完整功能是否必要？搜索引擎对功能完整的网站排名更好。
- 中英双语是否必要？中文 AI 内容供给不足，差异化机会大。
第二阶段：设计审查（15 分钟，3 轮）
AI 产出了一份设计文档，然后启动了一个独立的审查 agent。第一轮给了 5/10——数据模型缺失、Pagefind 和 SSR 的兼容性没考虑到、Giscus 的 Discussion 创建流程写错了。
修改后再审：6/10——发现了一个根本问题：Pagefind 索引需要静态 HTML，但 Next.js App Router 默认是 SSR。两者不兼容。
第三轮：7/10。切换到静态导出方案（output: 'export'），修正了 Giscus 的配置。通过。
这种"写 → 独立审查 → 修正 → 再审查"的循环，正常需要至少两个资深工程师坐下来讨论半天。AI 在 15 分钟内完成了，而且第二轮的检查比第一轮更严格——它记住了之前提出的问题，逐条验证是否真的被修复。
第三阶段：代码实现（2 小时）
Plan 确定后，5 个 phase 逐一实现：
Phase 1 — MDX 渲染接入。把首页、博客列表、文章详情页的硬编码占位数据全部替换为真实数据源。首页从 getAllPosts() 拉取文章，文章页用 getPost(slug, lang) 渲染 MDX 内容，代码块接入 rehype-pretty-code 双主题高亮。
Phase 2 — SEO + 分发。next.config.ts 设置 output: 'export'（整个博客是完全静态的）。generateMetadata 为每页输出 OG 标签和 hreflang 交替链接。构建时自动生成 RSS feed 和 sitemap.xml。
Phase 3 — 评论和搜索。接入 Giscus 评论（后来因为域名问题去掉了，后续自己开发评论系统）。Pagefind 搜索——构建后用 pagefind --site out 索引所有静态 HTML，搜索页面嵌入客户端搜索 UI，300ms 防抖。
Phase 4 — 视觉打磨。Inter 字体、indigo 渐变色系、hover 动效、暗色模式、404 页面、移动端汉堡菜单。
Phase 5 — 测试。15 个组件测试（vitest + testing-library）。bun run build 一次性通过。
第四阶段：部署上线（30 分钟）
注册域名 alex908.com，配置 Vercel 自动部署，DNS 配好 SSL 证书自动签发。git push 触发了自动构建，18 个静态页面生成，Pagefind 索引完成。
整个流程的核心不是 AI 写了多少代码——而是 AI 帮你做了那些"知道应该做但经常没时间做"的事：设计审查、边界情况分析、测试、SEO 配置、RSS 生成。
Superpowers 的三个关键原则
1. Boil the Ocean —— 一次性做完
传统开发的直觉是渐进迭代：先做核心功能，根据反馈再慢慢加。但 AI 让完整性的边际成本趋近于零。
一次性写完所有测试、覆盖所有边界情况、配好完整的 SEO 和分发——表面上做了"太多"，但因为 AI 的速度，完整版的总成本反而低于渐进版的多次往返。
2. Adversarial Review —— 让 AI 审查 AI
单个 AI 模型的输出总是有盲区的。但当你用一个模型生成内容、另一个模型（或同一个模型的独立实例）来审查时，就形成了一个 mini 的同行评审系统。
这次构建中最有价值的发现——Pagefind 和 SSR 的根本冲突——不是我在写设计文档时发现的，是审查 agent 在第二轮审查中发现的。这个 bug 如果留到部署后才发现，修复成本至少翻倍。
3. Decision Audit Trail —— 可追溯的决策
每一次 AI 自动做出的决定都记录了用了哪条原则、拒绝哪个方案、为什么。这很重要——三个月后回头看代码，你知道"为什么当时选了这个方案"，而不是面对一个既成事实猜测。
这不是取代，是放大
使用 AI 工具之后，我依然在写代码、做决策、把控质量。变化的是 AI 承担了大量的"认知 overhead"——我不用记住每个文件的 API 签名、不用手写 boilerplate、不用逐条检查 SEO 最佳实践。
Superpowers 不是 AI 替你思考和编码。是 AI 在你思考和编码的时候，把那些重复的、机械的、容易遗漏的环节全部覆盖了。你只需要做好唯一一件 AI 做不好的事：判断什么值得做。
你可以在 GitHub 看到这个博客的完整源码。