有几个设计决策值得特别提一下：

1. 默认使用 Claude。Hayden 在公开场合说过，在“长上下文推理 + 代码质量”这个维度上，Claude 的综合表现最稳定。这不是玄学，大量独立评测（如 EvalPlus、BigCodeBench）都支持这个结论。
2. 全本地索引。Superpowers 在本地构建项目的代码索引，不会把完整代码上传到云端（只在需要 LLM 推理时按需发送片段）。这对于企业级项目的合规性来说，是个非常关键的设计。
3. MCP 成为唯一工具协议。这意味着任何人都可以通过标准 MCP Server 为 Superpowers 扩展新能力。理论上，它的工具生态是无限的，这一点想象力很大。

2.5 实战案例：一次完整的功能开发

下面是一个真实的交互示例（来自 Superpowers GitHub 仓库中的 demo 场景）：

User：我发现 src/utils/auth.ts 里的 verifyToken 函数没有处理 JWT 过期的情况，而且错误信息不友好。请修复这个问题，并确保所有调用它的地方都能正确处理新的错误类型。

在传统流程中，你需要：定位 verifyToken、阅读实现、设计新的错误类型、全局搜索所有调用点、逐个修改调用方的 catch 逻辑、写测试、跑测试……一套下来，时间就这么流走了。

而 Superpowers 的实际输出是：

开发者只需要打开 diff 视图，审查每一处修改的合理性，**决定是接受还是微调**，而不是自己去敲每一行代码。

这个流程中，开发者的“价值密度”发生了根本性改变——从“消耗 80% 精力在语法、模板、重复劳动上”，变成了“消耗 100% 精力在业务判断上”。这才是 AI 编程真正的价值所在。

2.6 局限性与坑

Superpowers 并非完美，有几个客观存在的问题值得注意：

1. “幻觉文件”问题。Agent 偶尔会建议创建一个“它认为应该存在但实际上不需要”的文件。所以在审查阶段，必须保持警惕。
2. 超大仓库的索引延迟。在超过 50 万行代码的 monorepo 项目中，初次索引可能耗时 10-30 分钟，这个等待时间有点长。
3. LLM 成本不可忽视。一次端到端开发任务可能消耗不少 Token（取决于上下文长度），个人开发者需要关注账单。
4. 调试复杂 bug 仍需人类介入。当涉及到竞态条件、分布式系统一致性、性能瓶颈这类“推理链很长”的问题时，AI 的推理质量会明显下降。

三、Grill.me：Vibe Coding 的集大成者

3.1 Vibe Coding 到底是什么

在讨论 Grill.me 之前，必须先搞清楚 **Vibe Coding** 这个概念——因为它被误解得最多。

Vibe Coding 不是“随便写代码”，也不是“用 AI 瞎蒙”。它的准确含义是：

以最小的 upfront design（前置设计）为前提，通过与 AI 的连续对话迭代，快速把一个模糊的想法（vibe）变成可运行的软件原型。

它的对立面是传统的“瀑布式设计 + 详细规格说明书”。在 Vibe Coding 中，规格说明书是不存在的，它被“对话历史”替代了。

Grill.me（由独立团队 Grill Labs 开发的基于 Web 的 AI IDE）是目前对 Vibe Coding 实现得最彻底的工具。

3.2 Grill.me 的核心理念

Grill.me 的创始人在公开访谈中反复强调一个观点：

“大多数应用开发者 99% 的时间花在两件事上：1）把脑子里的想法翻译成代码；2）调试翻译过程中产生的错误。这两件事 AI 都能做得更好。”

基于此，Grill.me 做了一系列“反传统”的设计：

• 没有文件树的默认视图。你看到的不是 src/components/Foo.tsx 这种层级结构，而是“功能卡片”。
• 以“功能”为单位组织代码。一个功能卡片 = 一个 UI 组件 + 对应的逻辑 + 测试 + 样式，Grill.me 会自动把它映射到文件系统。
• “即时预览”优先于“先写后看”。每一轮对话修改后，预览器会在 2 秒内更新。
• AI 是“实现者”，你是“产品经理 + 设计师”。你的主要工作是描述需求、审阅输出、做出判断。

3.3 Grill.me 的典型工作流

用一个真实场景来演示：**从 0 开始做一个“番茄钟 Web App”**。

Step 1（30 秒）：用自然语言描述产品意图

“我想做一个极简番茄钟：25 分钟工作 / 5 分钟休息，循环 4 次后有一个 15 分钟长休息。需要有声音提示、键盘快捷键、数据持久化（localStorage）。用 React + TypeScript + Tailwind CSS。”

Grill.me 会在约 15 秒内生成一个**可运行的项目骨架**，包括必要的文件结构、配置和代码。

同时，右侧预览窗口已经出现了一个可点击的番茄钟界面。

Step 2（迭代）：通过连续对话微调

“把主色调从红色改成深绿 #059669，按钮要有 hover 动画效果。” “圆形进度条的粗细增加到 6px，数字字体改用 monospace。” “新增一个统计面板，显示本周已完成的番茄数。”

每一条指令，Grill.me 在 3-10 秒内完成修改并刷新预览。这就是 Vibe Coding 的“体感”——你感觉自己是在**和一个会写代码的设计师实时协作**，而不是在“编程”。

Step 3（深度修改）：当你需要理解和调整底层逻辑

“我想看看 useTimer 的实现，并且把 tick 间隔从 1 秒改成 100 毫秒，让 UI 动画更顺滑。”

Grill.me 会把 useTimer.ts 的完整代码展示给你，并根据你的要求重写。关键是：**你随时可以“降维”到代码层面操作**，Vibe Coding 不排斥传统编程，只是把它变成了“可选操作”。

Step 4（交付）：一键导出

最终这个番茄钟可以一键导出为标准的 Vite 项目，脱离 Grill.me 也能正常开发和部署。这一点很重要——**你不是被锁定在一个专有平台上**。

3.4 Grill.me 的技术栈

Grill.me 在技术上最大的亮点是对 **WebContainer**（由 StackBlitz 开源的浏览器内 Node.js 运行时）的深度集成。这意味着：

• 你不需要本地安装 Node.js
• npm install 在浏览器里运行
• HMR（热模块替换）在 iframe 内实时生效
• 整个开发环境可以在 2 秒内从一个 URL 加载完成

这在 2020 年之前是科幻级别的能力。

3.5 Grill.me 与传统 IDE 的范式对比

Grill.me 最被低估的价值在于“降低了把想法变成东西的门槛”。之前你需要至少 200 小时的学习积累才能做出第一个可用的 Web App；现在，一个有产品直觉但不会写代码的人，可能在 1 小时内做出一个像样的原型。这对创新的影响是结构性的。

3.6 Grill.me 的边界

Grill.me 不是“万能 IDE”，它的适用范围有清晰的边界：

适合用 Grill.me：

• 个人工具、小工具、SaaS 原型
• 前端为主的 Web App（React/Vue/Svelte）
• Hackathon / 快速验证想法
• 学习新技术（边看 AI 写代码边理解）

不适合用 Grill.me：

• 需要严格性能预算的底层库/基础设施
• 对安全性有极高要求的金融/医疗系统核心代码
• 超过 10 万行代码的大型单体项目（上下文窗口会成为瓶颈）
• 需要精细控制编译选项、构建流程的项目

四、Superpowers vs Grill.me：选择的本质

经常有人问：“Superpowers 和 Grill.me 哪个更好？”

这是一个错误的问题。正确的问法是：**“你在哪个阶段，以及你的项目性质是什么？”**

4.1 维度对比

4.2 选择建议

如果你是专业开发者，有日常工作的代码仓库：选 Superpowers。

理由很简单——它不破坏你现有的工作流。你依然用 Git、依然用 VS Code 的所有快捷键、依然可以随时脱离 AI 自己写代码。Superpowers 是“增强”，不是“替代”。

如果你是独立开发者/创业者/设计师/产品经理，想快速验证一个 idea：选 Grill.me。

Grill.me 的“即时反馈 + 以功能为单位”的模式，对于快速原型迭代来说是碾压级的体验。你会惊讶于自己“居然这么快就做出了一个能用的东西”。

两者不是替代关系，是互补关系。 很多资深开发者的实际用法是：先用 Grill.me 做原型探索，方案确定后导出代码，再切换到 Superpowers + VS Code 进行后续的深度开发和维护。

五、AI 编程时代，开发者的真正价值

这是本文最重要的部分。

很多人焦虑：“AI 会不会取代程序员？”

答案是：**不会取代程序员，但会彻底重新定义“什么是一个好程序员”**。

我们来拆解一下。

5.1 正在贬值的能力

以下能力在 AI 时代的经济价值正在快速下降：

1. 记住 API 的能力。记不住 Array.prototype.reduce 的参数列表？没关系，AI 会帮你查。
2. 手写 boilerplate 的能力。组件的 props 类型、简单的 CRUD、DTO 的定义——这些正在被 AI 接管。
3. 语法熟练度。你不需要“闭着眼睛也能写出正确的 Promise 链式调用”，你只需要“知道自己需要一个 Promise”。
4. 对某种语言细节的精通。如果你写了 10 年 Ja va 但不知道“为什么要用抽象工厂模式”，AI 会比你写得更快更好。

5.2 正在升值的能力

以下能力在 AI 时代的价值不降反升，甚至**变得更稀缺**：

1. 把模糊需求翻译成精确描述的能力。这是目前 AI 完全无法替代的。你必须能说清楚“我到底想要什么”，以及“这个设计决策背后的 trade-off 是什么”。
2. 系统设计能力。模块如何切分？边界在哪里？什么应该同步、什么应该异步？什么是业务核心、什么是辅助功能？这些是决定一个项目“是否能活到 1 年以后”的关键。
3. 代码审查能力。当 AI 给你一份代码时，你能不能在 30 秒内判断它是不是“看起来对但其实有隐藏 bug”？这需要真正的工程经验。
4. 性能直觉与故障排查能力。“这个 SQL 会不会慢？”“这个缓存策略在什么情况下会崩？”——这类问题需要“见过足够多坑”的直觉。
5. 架构决策的 taste。什么时候该用微服务，什么时候不该用？什么时候该引入消息队列，什么时候是过度设计？这需要判断力，不是背诵。

一个可供参考的经验是：过去一年里，在团队面试候选人时，**已经不再考“手写算法题”了**。会给一个真实的业务场景，问他“你会怎么设计？为什么？”，然后让 AI 写一份实现，再让他“review 这份 AI 代码，找出问题并改进”。这比任何 LeetCode 题目都更能测出真实水平。

5.3 新的能力地图

注意：这是一个**环**。你不能只学其中一项，它们彼此强化。

六、Vibe Coding 的三个陷阱与三个原则

Vibe Coding 的效率是迷人的，但也是危险的。见过太多人“用 AI 快速做了一个原型，然后发现根本没法维护”。

这里是自己总结的“Vibe Coding 生存指南”。

6.1 三个必须避开的陷阱

陷阱一：“能跑就行”的技术债务累积

Vibe Coding 的即时反馈会让你产生“这个东西已经做好了”的错觉。但 AI 生成的代码往往缺少：适当的抽象层次（以后很难扩展）、边界条件的处理（异常情况直接崩）、类型安全（any 满天飞）、测试（出了问题不知道从哪里排查）。

建议：**每完成 3-5 轮 Vibe Coding 迭代后，强制自己做一次“代码体检”**。把 AI 写的核心模块读一遍，看看是不是“看起来能跑但实际上烂透了”。

陷阱二：失去对代码的“掌控感”

当一个项目完全由 AI 生成时，你会遇到一个诡异的问题：你是这个项目的“主人”，但你**并不真正理解它每一行代码在做什么**。有一天出了 bug，你会陷入“让 AI 修 bug → AI 又引入新 bug → 再让 AI 修”的死循环。

建议：**在项目从“原型”进入“生产”阶段的那一刻，你必须亲手重新实现一遍核心模块**。不是重构 AI 的代码，而是你自己写一遍——即使写得更慢。这个过程能把“AI 的代码”变成“你的代码”。

陷阱三：过度依赖 LLM 的“随机正确性”

LLM 是概率模型，不是定理证明器。它这次给你的代码是对的，不代表下次同样的问题它还能给出对的答案。你不能说“我上次问过了没问题”，你必须每次都检查。

建议：**建立一个“AI 输出审查 checklist”**，每次接受 AI 修改前过一遍：

• [ ] 类型定义完整吗？有没有 any？
• [ ] 错误处理到位了吗？空值/异常/边界情况呢？
• [ ] 命名是否符合项目现有约定？
• [ ] 是否引入了不必要的新依赖？
• [ ] 性能敏感路径上的实现合理吗？
• [ ] 这处修改会不会影响其他模块？

6.2 三个必须坚持的原则

原则一：始终自己写测试

强烈建议**不要让 AI 写测试**。原因不是 AI 不会写测试，而是因为：**写测试是你理解自己系统的最后一道防线**。当你亲自为一个模块写测试时，你会被迫思考“这个模块应该有什么行为”“什么情况下它应该失败”——这个思考过程是无价的。

让 AI 写实现，你自己写测试。这是一个很好的分工。

原则二：重要的架构决策由人做出，AI 只负责实现

“微服务还是单体？”“用 Redis 还是 PostgreSQL 做缓存？”“这个状态应该放 Redux 还是放 localStorage？”——这类决策不能扔给 AI。AI 不知道你的业务长期规划、不知道你的团队构成、不知道你的预算约束。

原则三：保持“随时可以脱离 AI 自己写代码”的能力

这是一种心理上的自律。每周至少抽 2-3 小时，关掉所有 AI 工具，手写一段代码。不是因为手写更好，而是因为：**你必须证明给自己看——你还会**。

如果哪天没有 AI 你就写不出代码了，你已经不是一个工程师，你只是一个“prompt 操作员”。

七、给初学者的一条路

如果你刚入门编程，或者在考虑“现在学编程还有没有意义”，这里有一条**反直觉但值得认真考虑的路径**：

7.1 学习顺序建议

阶段 1 的目的：你必须亲自体会过“为什么需要数组”“为什么需要循环”“为什么需要函数”——这些东西 AI 可以帮你写，但你得先明白它“为什么要那样写”。

阶段 2 的目的：你需要亲手做过一个至少 5000 行代码的项目。这个项目的目的不是“做好一个产品”，而是“让你亲手踩一遍所有的坑”。

阶段 3 的目的：读别人的代码比写自己的代码更重要。选一个你每天都在用的开源项目（比如 Vite、Prisma、Tailwind CSS），读它的核心源码。你会发现：**真正优秀的代码，其价值不在“写对了”，而在“设计选择背后的深思熟虑”**。

阶段 4 的目的：把 AI 融入你的工作流，但永远保持“审查者”的姿态。

7.2 为什么“先手写再 AI”比“一开始就用 AI”更好

有两类初学者：

A 类：从第一天开始用 AI。两个月后，他能“做出”看起来很炫的东西。但如果你问他“这里为什么用 useEffect 而不是 useMemo”，他答不上来。遇到一个需要自定义 Hook 的场景，他卡住了，因为 AI 这次给出的答案不对，而他自己没有判断能力。

B 类：前 3 个月完全不用 AI，手写一切。这段时间他进展很慢、很痛苦。但 3 个月后，他开始用 AI——这时他能一眼看出“AI 这个地方写得有问题”“AI 过度设计了”“AI 这里应该换一种做法”。他用 AI 的效率是 A 类的 3-5 倍。

短期看 A 类赢了，长期看 B 类的上限是 A 类无法企及的。

八、写在最后

Superpowers 和 Grill.me 不是“更好的 IDE”。它们是**新的生产力工具，会改变编程这个职业的定义**。

AI 不会让程序员失业。历史上每次生产力工具的升级，最终结果都是“让这个行业能做的事情变多了”而不是“需要的人变少了”。Excel 没有让会计失业，它让会计从“算帐的人”变成了“分析帐的人”。AI 对程序员的影响也是同理。

但确实，**接下来 3-5 年里，“会用 AI 写代码”和“不会用 AI 写代码”之间的差距，会拉大到无法忽视的程度**。这种差距不是“效率高一点”，而是“一个人能做之前一个团队才能做的事”。

Superpowers 和 Grill.me 是目前市面上这个方向上最好的两个代表。它们选择了不同的路径，但指向同一个未来。

去用它们。然后——**保持怀疑，保持判断，保持你作为工程师的品味**。