Superpowers 与 Grill.me：新一代 AI 编程范式

❝

写在前面：本文不是工具评测，而是一次对"AI 原生编程"底层逻辑的深度拆解。

一、从"写代码"到"描述意图"：编程范式的第三次跃迁

让我们先建立一个坐标系。

第一次跃迁（1950s-1970s） ：从机器码到高级语言。人类摆脱 0/1，用 if/for/while 描述逻辑。

第二次跃迁（1990s-2010s） ：从手写代码到框架/库复用。npm install + 组合调用成为主流。

第三次跃迁（2023-至今） ：从"写代码"到"描述意图"。自然语言成为新的"编程语言"，LLM 充当编译器。

这不是"效率提升"，而是生产关系的改变。之前的范式是"人适应机器"，现在的范式是"机器适应人"。

Superpowers 和 Grill.me 正是这第三次跃迁中两个极具代表性的产物------它们选择了完全不同的切入角度，却指向同一个终点：让开发者从"代码实现者"变回"系统设计者" 。

二、Superpowers：把 IDE 变成"有记忆的工程合伙人"

2.1 Superpowers 到底是什么

Superpowers 是一款 VS Code 扩展，由独立开发者 Hayden Bleasel（GitHub @haydenbleasel）主导开发。它不是 GitHub Copilot 的"另一个版本"，它的核心设计哲学完全不同。

理解这个区别非常关键。Copilot 像一个坐在你旁边"看你打字"的实习生；Superpowers 像一个已经完整读过你项目代码、了解业务背景、能主动提出重构建议的资深同事。

2.2 Superpowers 的核心能力矩阵

能力	说明	底层依赖
全项目代码索引	自动扫描项目结构，理解依赖关系	Tree-sitter + 向量化存储
MCP 协议支持	通过 Model Context Protocol 调用外部工具	Anthropic MCP Spec
长期记忆	跨会话保留项目上下文、决策记录	本地向量库 / SQLite
多智能体协作	Agent A 写代码，Agent B 做 Code Review，Agent C 写测试	Multi-Agent Orchestration
终端接管	Agent 可直接执行命令、运行测试、查看错误反馈	Shell 集成 + 安全沙箱
浏览器工具	Agent 可实时搜索文档、查 npm 包信息、看 Stack Overflow	内置浏览器 Agent
代码图谱	可视化展示函数调用链、模块依赖图	AST 分析 + 图形渲染

❝

个人观点：Superpowers 最被低估的能力是"多智能体协作"。当一个 Agent 写完代码后，另一个 Agent 会以"找茬者"身份进行 Review------这在心理层面极大降低了"AI 写出烂代码"的概率，也让输出质量发生了质变。

2.3 Superpowers 的工作流

这是一个完整的"端到端"流程。开发者只说了一句话，Superpowers 完成了5 个文件的联动修改 + 测试 + 文档 。传统模式下，这需要 30-60 分钟；AI 原生模式下，核心等待时间约 2-3 分钟，其余时间开发者在做"决策"而非"打字"。

2.4 技术架构与底层原理

Superpowers 的技术栈设计得相当克制：

几个值得注意的设计决策：

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

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

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

❝

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

在传统流程中，你需要：

定位 verifyToken，阅读其实现
设计新的错误类型（如 TokenExpiredError）
全局搜索所有调用点
逐个修改调用方的 catch 逻辑
写测试
跑测试

Superpowers 的实际输出（简化后）：

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

❝

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

2.6 局限性与坑

Superpowers 有几个客观存在的问题：

"幻觉文件"问题。Agent 偶尔会建议创建一个"它认为应该存在但实际上不需要"的文件。审查阶段必须保持警惕。
超大仓库的索引延迟。超过 50 万行代码的 monorepo 项目中，初次索引可能耗时 10-30 分钟。
LLM 成本不可忽视。一次端到端开发任务可能消耗 3 的 Token 费用（取决于上下文长度）。个人开发者需要关注账单。
调试复杂 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 的范式对比

维度	传统 IDE（VS Code）	Grill.me
基本单位	文件/代码行	功能/意图
开发者角色	实现者	决策者/产品经理
反馈循环	写代码 → 保存 → 切到浏览器 → 刷新	描述意图 → 看预览 → 继续微调
初始门槛	需要了解框架/构建工具/配置文件	只需会描述你想要什么
最小迭代周期	分钟级	秒级
适合场景	大型系统/底层基础设施/性能优化	原型验证/小型应用/个人项目/学习

❝

个人观点：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 维度对比

对比维度	Superpowers	Grill.me
产品形态	VS Code 扩展	Web IDE（独立平台）
代码归属	完全本地，属于你	云端存储，可导出本地
与现有工作流集成	无缝（就在你的 VS Code 里）	需要切换到新环境
对"已有大项目"友好度	非常友好（全项目索引）	一般（更适合从 0 新建）
团队协作支持	需要配合 Git，无内置协作	支持多人实时协作（类似 Figma）
预览体验	需要手动启动 dev server	内置实时预览
学习曲线	低（VS Code 用户零成本）	低（但需要适应"无文件树"）
定价	订阅制（约 $20/月）	免费 + Pro 订阅（约 $15/月）
离线使用	大部分功能需要联网	完全在线

4.2 我的选择建议

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

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

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

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

两者不是替代关系，是互补关系。 很多资深开发者的实际用法是：

用 Grill.me 做原型探索
方案确定后，导出代码
用 Superpowers + VS Code 进行后续的深度开发和维护

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

这是本文最重要的部分。

很多人在焦虑："AI 会不会取代程序员？"

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

让我们拆解一下。

5.1 正在贬值的能力

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

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

5.2 正在升值的能力

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

把模糊需求翻译成精确描述的能力。这是目前 AI 完全无法替代的。你必须能说清楚"我到底想要什么"，以及"这个设计决策背后的 trade-off 是什么"。
系统设计能力。模块如何切分？边界在哪里？什么应该同步、什么应该异步？什么是业务核心、什么是辅助功能？这些是决定一个项目"是否能活到 1 年以后"的关键。
代码审查能力。当 AI 给你一份代码时，你能不能在 30 秒内判断它是不是"看起来对但其实有隐藏 bug"？这需要真正的工程经验。
性能直觉与故障排查能力。"这个 SQL 会不会慢？""这个缓存策略在什么情况下会崩？"------这类问题需要"见过足够多坑"的直觉，AI 目前还没有。
架构决策的 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 是目前市面上这个方向上最好的两个代表。它们选择了不同的路径，但指向同一个未来。

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

这是我能给你的最好建议。

❝

参考来源：

Superpowers 官方文档与 GitHub 公开 Issue 讨论

Grill.me 官方博客与创始人公开访谈

StackBlitz WebContainer 技术白皮书