用得最多的两个“神级“ AI Skill：一个管工程架构，一个管需求决策

c++开发工程师

158人浏览 · 2026-07-03 14:27:28

c++开发工程师 · 2026-07-03 14:27:28 发布

用得最多的两个"神级" AI Skill：一个管工程架构，一个管需求决策

过去半年，我用 AI Agent 陆续构建了不少项目——从内部工具到对外产品，从原型验证到正式上线。在这个过程中我逐渐意识到一件事：

真正决定 Agent 好不好用的，不是换更强的模型，而是给它装上对的 Skill（技能）。

模型决定"智商上限"，Skill 决定"做事下限"。一个没有 Skill 约束的 Agent，就像一个聪明但没有流程的实习生——能力不差，但容易跑偏、丢步骤、留隐患。

今天分享我过去半年用得最多、依赖最深的两个 Skill。一个负责把工程架构做对，一个负责把需求决策想透。它们刚好覆盖了项目开发中最关键的两端：想清楚和做对。

一、Superpowers：让编码 Agent 真正"懂"工程规范

项目地址：github.com/obra/superpowers
作者：Jesse Vincent（GitHub: @obra），Prime Radiant 团队
协议：MIT

这是什么

Superpowers 是一套面向编码 AI Agent 的完整软件开发方法论框架。它不是单个工具，而是一组可组合的 Skill，通过初始指令让 Agent 从项目启动那一刻起，就自动遵循一套系统化的开发流程。

一句话概括：它把资深工程师的工作习惯，固化成了 Agent 的默认行为。

为什么我离不开它

用 Agent 写代码最大的痛点是什么？是不可控。

你让它写个功能，它啪啪啪一顿输出，看起来都对，但细看可能漏了测试、跳过了审查、直接改了主干分支、甚至"自以为完成"实则没验证。问题的根源在于——Agent 缺乏一套强制的、分阶段的工作流约束。

Superpowers 解决的就是这个问题。它的核心理念只有四条，却字字戳中要害：

测试驱动开发——始终先写测试
系统化优于随意——流程优于猜测
降低复杂度——简洁是首要目标
证据优于声明——在宣布成功之前先验证

核心：7 阶段开发工作流

Superpowers 把一次完整的开发任务拆成 7 个阶段，每个阶段都有对应的 Skill 自动触发，这不是建议，而是强制流程：

阶段	触发的 Skill	做什么
① 头脑风暴	`brainstorming`	写代码前先探索方案、提问、分段验证设计
② 隔离工作区	`using-git-worktrees`	在新分支创建隔离环境，验证干净的测试基线
③ 编写计划	`writing-plans`	把工作拆成 2-5 分钟的小任务，含精确文件路径和验证步骤
④ 执行计划	`subagent-driven-development`	为每个任务派子代理，两阶段审查（规范合规 + 代码质量）
⑤ 测试驱动	`test-driven-development`	强制 RED-GREEN-REFACTOR 循环
⑥ 代码审查	`requesting-code-review`	按严重程度报告问题，关键问题阻断进展
⑦ 完成分支	`finishing-a-development-branch`	验证测试，呈现合并/PR/保留/丢弃选项

这里面有几个设计让我特别服气：

强制 TDD 循环。 先写会失败的测试，看着它失败，再写最小代码让它通过，最后提交。如果你先写了代码再补测试，它会直接删掉你的代码，逼你重来。这种"不妥协"恰恰是质量的保证。

两阶段代码审查。 第一阶段检查"是否按计划做了"（规范合规），第二阶段检查"做得好不好"（代码质量）。两层把关，既防跑题，又防烂代码。

子代理驱动开发。 每个小任务派一个独立子代理去做，主代理负责调度和审查。这样 Agent 可以自主工作数小时而不偏离计划——因为它每次只专注一件事，做完就被审查。

值得单独关注的几个 Skill

除了主线流程，还有几个 Skill 我经常单独拿来用：

systematic-debugging——4 阶段根因分析流程。遇到 bug 不瞎猜，而是系统化追踪根因、纵深防御。配合 verification-before-completion 确保"真正修好了"而不是"看起来修好了"。
dispatching-parallel-agents——并发子代理工作流。多个独立任务同时跑，效率翻倍。
writing-skills——按最佳实践创建新技能的"元技能"。用它可以给团队沉淀自定义 Skill。

怎么装

它支持 10 种主流编码 Agent / 平台，安装方式因平台而异。以 Claude Code 为例：

# 方式一：官方市场（推荐）
/plugin install superpowers@claude-plugins-official

# 方式二：添加市场后安装
/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace

Cursor、Codex、GitHub Copilot CLI、Kimi Code、OpenCode 等平台也都有对应安装方式。装完即用，技能自动触发，无需特殊操作。

我的真实体验

说实话，第一次用我是有点"被约束得难受"的——它不让你跳步、不让你偷懒、不让你"先写代码再说"。但用下来几个项目后，我成了坚定的拥趸。

最大的改变是：交付质量稳定了。 以前用 Agent 写代码像开盲盒，现在每一步都有审查、有测试、有验证，“看起来对但其实没跑通"的情况基本消失。它让 Agent 从"会写代码"升级到"会做工程”。

二、Council of High Intelligence：18 位"大佬"帮你多维度审视决策

项目地址：github.com/0xNyk/council-of-high-intelligence
作者：0xNyk
协议：CC0 1.0（完全放弃版权，公共领域）
当前 Star：3000+

这是什么

Council of High Intelligence（高智能议事会）是一个多维度讨论需求与决策的 Skill。它召集 18 个以历史/当代智者为原型的 AI 人格角色，对你的难题进行结构化的多轮审议，最终给出一份突出分歧而非掩盖分歧的裁决。

一句话概括：遇到难决策，别问一个 AI，开一场议事会。

它解决的真正问题

你可能觉得：我直接问 AI 不就行了？问题恰恰出在这里。

单个 LLM 只给你一条推理路径，却伪装成自信的结论。 你问"该不该开源我们的框架"，它给你列一堆利弊，然后给个"建议"——但这只是单一视角的"事后合理化"。你缺的不是答案，而是多个独立视角的碰撞。

Council 的核心理念一针见血：

议事会给你的是结构化的分歧——3 到 18 个来自不同思想流派的独立分析，强制它们相互挑战，最终合成一个突出分歧而非隐藏分歧的裁决。

而且它不是让一个模型"演"18 个角色（那本质上还是一个视角），而是通过多提供商路由，让不同 LLM 家族真正独立推理——这是它和"角色扮演 prompt"的本质区别。

18 位议事会成员

这 18 个角色覆盖了从哲学到工程、从战略到认知科学的极广光谱。每一个都有明确的"领域"和"极性角色"（即它天然倾向的立场）：

角色	领域	极性角色（天然立场）
亚里士多德	分类与结构	一切皆可分类
苏格拉底	假设摧毁	质疑一切
孙子	对抗策略	读取地形与竞争
阿达·洛芙莱斯	形式系统与抽象	什么能/不能被机械化
马可·奥勒留	韧性与道德清明	控制与接受
马基雅维利	权力动态与现实政治	行为者实际如何行为
老子	无为与涌现	何时少即是多
费曼	第一性原理调试	拒绝未解释的复杂性
林纳斯·托瓦兹	务实工程	发布它或闭嘴
宫本武藏	战略时机	决定性打击
艾伦·瓦兹	视角与重构	消解虚假问题
安德烈·卡帕西	神经网络直觉	模型实际如何学习与失败
伊利亚·苏茨克维	扩展前沿与 AI 安全	何时能力成为风险
丹尼尔·卡尼曼	认知偏差与决策科学	你自己的思维是第一个错误
多内拉·梅多斯	系统思考与反馈回路	重新设计系统，而非症状
查理·芒格	多模型推理与经济学	反转——什么保证失败？
纳西姆·塔勒布	反脆弱与尾部风险	为尾部设计，而非平均值
迪特·拉姆斯	以用户为中心的设计	更少，但更好——用户决定

更妙的是，其中 13 对角色构成极性对——天然对立的视角。比如：

托瓦兹 vs 瓦兹：立即发布具体方案 vs 质疑问题是否真的存在
卡尼曼 vs 费曼：你的认知是第一错误 vs 信任第一性原理
塔勒布 vs 卡帕西：隐藏的灾难性尾部 vs 平滑的经验扩展曲线

这些极性对确保了议事会永远不会有虚假共识。

三种审议模式，适配不同场景

不是每次都要开 18 人大场。Council 提供三种模式灵活切换：

模式	命令	轮次	适用场景
全模式（默认）	`/council 你的问题`	7 步完整流程	重大决策，需要充分审议
快速模式	`/council --quick 你的问题`	2 轮	日常决策，要快但要多元
双人模式	`/council --duo 你的问题`	极性对辩证	探索某个核心张力/取舍

全模式的 7 步流程设计得很讲究：提供商路由 → 问题重述门 → 独立分析 → 交叉质询 → 执行扫描 → 最终立场 → 裁决合成。

其中"问题重述门"这个设计让我眼前一亮——每个成员在分析前必须先重新表述问题。如果 3 个成员的表述各不相同，说明问题本身就有问题。这一步能在源头就拦住"问错了问题"的浪费。

反群体思维：最关键的设计

多 Agent 讨论最容易翻车的地方是什么？群体思维——大家互相附和，最后变成回音壁。Council 用几条硬规则死死摁住了这个问题：

异议配额：如果超过 70% 的成员过早同意，强制两名成员为反对观点辩护。
反事实提示：强制考虑"如果反过来呢"。
创新性门控：防止过早收敛。
苏格拉底之盾规则：任何超过 2 条消息的对话对被截断，防止递归死循环。

最终的裁决不是"大家一致认为"，而是结构化计票——共识需要领域加权 2/3 多数。如果真有分歧，它会把"未解决的问题"和"建议的下一步"摆出来给你，而不是强行编造一个虚假共识。

这份诚实，比一个看似笃定但经不起推敲的答案有价值得多。

怎么装

git clone https://github.com/0xNyk/council-of-high-intelligence.git
cd council-of-high-intelligence

# Claude Code 安装
./install.sh

# 同时安装 Codex 版本
./install.sh --codex

# 预览不写入
./install.sh --dry-run

装好后，一条命令启动议事会：

# 全模式：重大决策
/council 我们的 Agent 框架该不该开源？

# 三人组：聚焦某个领域
/council --triad strategy 我们的竞争壁垒是什么？

# 双人模式：探索取舍
/council --duo 该用微服务还是单体？

# 手动指定成员
/council --duo --members torvalds,ada 这个抽象值得吗？

它还内置了 20 个领域三人组（architecture、strategy、risk、ai-safety、decision 等）和 3 种议事会配置（18 人经典版 / 12 人探索版 / 5 人精简版），按需取用。

我的真实体验

我最常用的是 --duo 和 --triad 模式。遇到"要不要做某功能""选 A 还是 B"这类取舍题，开一个极性对辩证，5 分钟就能看清两边的核心论点和盲区。比我自己拍脑袋、或只问一个 AI 强太多。

最大的收获是：我开始看见"自己没想到的角度"。 比如有次纠结一个技术选型，托瓦兹视角说"先发布能用的"，塔勒布视角却说"这个选型在极端情况下会崩"——两个视角单独看都对，放一起才看清这是个"效率 vs 韧性"的根本取舍，不是对错问题。这种洞察，单问一个 AI 永远得不到。

三、两个 Skill 怎么配合：一个想清楚，一个做对

这两个 Skill 之所以是我"用得最多"的，是因为它们恰好覆盖了项目开发的两个最关键环节，而且互补到几乎没有重叠：

维度	Council of High Intelligence	Superpowers
解决什么	决策端：该做什么、怎么选	执行端：怎么把事做对
核心能力	多视角碰撞，暴露盲区	强制工程流程，保证质量
介入时机	需求/方向/取舍的决策点	进入编码后的全流程
输出	突出分歧的裁决 + 下一步建议	经过测试和审查的可用代码