AI编程最大的变化不是模型变强——从Superpowers的24万星说起
Superpowers以24万星登顶GitHub，核心理念是禁止AI直接写代码、先想清楚再动手。结合开发者中蔓延的AI疲劳症，聊聊AI编程正在经历的根本性范式转变：下一阶段拼的不是模型参数，而是工程化流程。
过去两周，AI 编程圈最火的东西不是某个新模型，不是某笔巨额收购，不是某条安全禁令。
是一个 GitHub 项目，叫 Superpowers。24 万颗星，7 天涨了 9 万颗。
它做的事情很简单：禁止 AI 直接写代码。
同一个时间窗口里，TypeScript 社区顶流 Matt Pocock 的项目 skills 冲到了 14.8 万星。Google 的 agent-skills 稳在 5.6 万星。agency-agents 拿下 11.2 万星。这帮项目有一个共同点：它们都不是让 AI 变得更聪明，而是让 AI 变得更守规矩。
与此同时，开发者社区里另一种声音也在放大。Midjourney 创始人 David Holz 在 X 上发帖说，身边朋友「用上最新编程模型后，工作效率高到离谱，却也身心俱疲」。一份开发者倦怠调查报告显示，受访者倦怠自评均值 7.4 分（满分 10），超过 70% 的人持续倦怠至少半年，而「AI 压力」已经和「永远在线文化」「优先级混乱」并列成为程序员倦怠的前四大来源。
这两件事放在一起看，指向了同一个趋势。
AI 编程是怎么让人更累的
过去两年 AI 编程的叙事主线很清晰：模型越来越强，程序员越来越不重要。
但 2026 年上半年的实际情况是：模型确实越来越强了，但程序员没有变得更轻松。Henry Yager 在《哈佛商业评论》里把这种现象叫做「工作量蔓延」——AI 把生产效率推高之后，组织预期跟着水涨船高，任务范围被动扩大，认知负荷不降反升。
OpenFGA 核心维护者 Siddhant Khare 今年初写了一篇在开发者社区疯传的文章，标题是《AI 疲劳是真实存在的，却无人提及》。他描述了一种工作模式的根本性转变：
过去写代码是一条清晰的路径：思考问题、编写代码、运行测试、通过后发布。那是创造者的愉悦。而现在的日常变成了一个循环——提出指令、等待 AI 输出、阅读输出、评估输出、判断是否正确、判断是否安全、判断是否符合架构设计、修正不符合的部分，然后重新下达指令，周而复始。
程序员从创造者变成了质检员。 干完活之后，没有往日的成就感，只有一片空白的疲惫感。
这还不是最要命的。更根本的问题是：AI 生成代码越快，你审查代码的压力就越大。以前你写完 200 行代码，自己心里有数。现在 AI 两分钟吐出 2000 行，你得在同样的时间里判断这 2000 行有没有问题。答案往往是有——但你未必能一眼看出来问题在哪。
Superpowers 做对了什么
Superpowers 的作者是 obra（也是 dayone 的创始人）。项目本身是一套结构化开发方法论，核心是一组可组合的 Skill 文件和初始指令，让 AI 在动手写代码之前先走完一整套思考流程。
具体来说，它强制 Agent 遵循一个七阶段工作流：
- 需求澄清——先问聪明的问题，确保理解你要什么
- 计划审批——生成可读的 spec，等你确认
- TDD 实现——先写测试，再写代码
- 子 Agent 并行——把任务拆成 2-5 分钟的小块分派执行
- 审查收尾——验证所有测试通过
TDD 这条铁律尤其狠：测试先行，未通过测试的代码会被 Agent 主动删除。不是「标记为需要修改」，不是「帮你重构」。直接删掉。
这四个字「直接删掉」才是 Superpowers 真正的设计哲学。它不信任 AI 的自我修正能力——或者说，它认为让 AI 自己改自己的代码，跟让醉汉自己醒酒一样不靠谱。与其在坏代码上修修补补，不如从正确的起点重新出发。
obra 在接受采访时说过一句话：「我不是在造一个更聪明的 AI。我是在造一套让 AI 没法犯傻的流程。」
这话说得有点绝对，但方向是对的。过去两年所有人都在追模型能力的天花板，Superpowers 做的是把地板抬高。
不是孤例：工程化方法论正在集体爆发
Superpowers 不是一个人在战斗。同一时期冒出来的几个项目，虽然定位不同，但底层逻辑高度一致：
| 项目 | 星标 | 定位 | 核心思路 |
|---|---|---|---|
| Superpowers | 240K+ | 开发方法论框架 | 设计→计划→TDD→实现 |
| agent-skills (Addy Osmani) | 56.7K | 生产级工程流程 | 21 个 SDLC 阶段技能 |
| agency-agents | 112.3K | AI 专家角色库 | 232 个专家角色定义 |
| Compound Engineering | 18.3K | 复合工程方法论 | 每次改动都降低下一次难度 |
Matt Pocock 的 skills 项目也很有意思。他的四个核心命令命名非常直白：
/grill-me—— 强制需求对齐，Agent 真正理解意图前一行代码都不写/tdd—— 红-绿-重构循环/diagnose—— 系统化根因分析，必须走诊断树/caveman—— 把 Token 消耗压缩 75%
Pocock 自己的总结很精准：「我不是让 AI 更聪明，我是让它更守规矩。」
这四个项目的集体爆发不是巧合。它们共同回答了一个问题：当 AI 能写出及格线以上的代码之后，差距不在模型能力上，在你怎么用它。
这对我们意味着什么
如果让我用一个判断来总结 2026 年上半年的 AI 编程趋势，我会说：天花板之战告一段落，地板之战刚刚开始。
GPT-5.6 发布、Grok 4.5 发布、Claude Fable 持续迭代——模型层面的军备竞赛还在继续，但程序员群体的注意力已经开始转移。大家逐渐意识到一个问题：模型再强，如果你不知道怎么驾驭它，结果可能更糟。
这跟软件工程的历史规律是一致的。九十年代没人讨论 CI/CD，不是因为不需要，是因为那时候写代码本身就是瓶颈。当写代码的速度被 AI 提到一个前所未有的高度之后，代码质量、架构一致性、团队协作——这些以前被「开发效率」掩盖的问题，全部浮出了水面。
Claude Code 业务负责人 Katherine Wu 说她现在「只用一个 AI 智能体，专心攻克一项高难度任务」。她解释：「平时我会同时调用十几个智能体，但静下心深耕单一任务、把细节打磨到位的沉浸感，实在难得。」
这话出自一个卖 AI 编程工具的人之口，值得琢磨。
最后
Superpowers 的 24 万星代表的不是某个工具的成功。它代表的是开发者群体的一次集体反思：AI 能写代码了，然后呢？
答案正在逐渐清晰：然后把流程建好，把规范定死，让 AI 在框里发挥。下一阶段 AI 编程的核心竞争力，不是谁的模型参数更多，而是谁的工程化方法论更成熟。
换句话说——过去两年我们一直在问 AI「你能做什么」。从现在开始，我们该问自己「我们想让 AI 怎么做」了。