superpowers 是一套给编码 agent 用的”软件开发方法论”，用可组合的 skill 加强制流程，逼 agent 按专业开发者的规矩做事——先问清需求、再拆计划、再写代码、最后评审收口。
是什么 一句话定位 ：superpowers 作者是 Obra（Jesse Vincent）。它不是更强的编码模型，而是套在 agent 之上的一层”工程纪律”——用一组可组合的 skill 与强制流程，约束 agent 按专业开发者的开发节奏走。
它解决的问题 ：默认情况下，agent 拿到需求的天性是”直接开写”——需求没问清就猜、不写测试、一把梭。superpowers 的核心主张是：别急着写代码，先退一步问清楚到底要做什么，把资深工程师会做、但 agent 默认跳过的动作（需求澄清、设计验证、计划、测试先行、系统评审）固化成强制流程。
三个关键词 理解 superpowers，抓住三个词。
Skill（技能）= 可组合的行为模块 ：每个 skill 是一段结构化指令，告诉 agent 在某种情境下该怎么做（如 test-driven-development、brainstorming）。skill 之间可组合，一个大任务会串起多个 skill。注意：superpowers 的 skill 不等于 Claude Code 原生的 subagent 或 slash command，它是叠加在上面的一层”行为规范”。
Mandatory，不是 suggestion ：README 原话——“The agent checks for relevant skills before any task. Mandatory workflows, not suggestions.” 即 agent 做任何任务前先检查有没有相关 skill，命中就必须 按流程走，而不是参考一下。这是它和”最佳实践清单”最大的区别：它是被执行的，不是被建议的。
README.MD
四条哲学底座 ：
Test-Driven Development ：测试先行。Systematic over ad-hoc ：系统化流程压倒随手即兴。Complexity reduction ：主动降复杂度、求简。Evidence over claims ：拿证据说话，不靠”我觉得应该没问题”——这条专门拦 agent”嘴上说改好了、实际没验证”的毛病。
七步工作流 superpowers 的执行骨架是固定七步。agent 命中一个开发任务就按顺序走。
七步工作流
步骤
做什么
拦截的坏习惯
① Brainstorming
反过来问、列替代方案，定稿设计再动手
需求没问清就猜着写
② Workspace Setup
git worktree 开隔离分支，先跑测试确认基线干净
改完才发现基线本就坏、分不清谁弄的
③ Planning
拆成离散任务，每个 2–5 分钟，写明精确文件路径与代码规格
想到哪写到哪、改动面失控
④ Implementation
每任务派 subagent，两段式评审（规格符合度 + 代码质量）
一次性大改难以审查
⑤ TDD
强制 RED-GREEN-REFACTOR
不写测试，或先写实现再补装饰性测试
⑥ Code Review
对照 plan 评审，按严重级别标记，critical blocker 会停
改完一走了之、不回头核验
⑦ Completion
确认测试通过，给 merge / PR 选项
开放态一直挂着没收口
三个值得注意的设计点：
步①就是”开工前先问清楚” ，这正是 grill-me 那个工具要做的事，superpowers 内置了简版，grill-me 把这件事做得更狠更专注。
步③切成 2–5 分钟一粒 ，这个粒度是和步④配套的——任务足够小，才能一个 subagent 干完、一轮评审过完。切成大块就没法用 subagent 串了。
步⑥ critical blocker 会停 ，是”Evidence over claims”在流程上的落地：评审不是走形式，发现致命问题真的会卡住，逼着先修。
三大关键机制 七步是骨架，真正”硬”的地方在三个互相咬合的机制。
subagent 驱动开发 步④里，每个小任务不是主 agent 自己写，而是派一个 subagent 去写 。主 agent 像项目经理——拆任务、派活、收结果、评审。
好处 ：主 agent 对话越长，前面堆积的 context 越多，判断力会下降。把每个小任务交给一个”只装这一块 context”的新 subagent，等于每次用清醒的脑子干活；互不依赖的小任务还能并行；subagent 产出的是 bounded 小结果，评审更容易。风险 ：subagent 之间不共享对话历史，有跨任务的隐式依赖时容易各做各的。所以步③必须把任务边界与依赖交代到极致清晰——粒度细和隔离是配套咬合的。
两段式评审 每个 subagent 交活后，分两轮评审，顺序固定：
规格符合度 （specification compliance）：有没有按计划、规格写？代码质量 （code quality）：就算按规格写了，这代码本身行不行？
为什么要分两段：这两类问题评判标准不同、修法不同。混在一起评，agent 容易把”没按规格”和”代码写得丑”搅成一锅。拆开后，规格不符先退回重做，质量问题再针对性重构。先对，再好 ——因为修复成本随阶段递增，先解决方向性错误（规格），再局部打磨（质量），避免在错的代码上做漂亮的重构。
git worktree 隔离 步②用 git worktree 而不是普通 branch。worktree 是 git 原生功能，能让同一仓库的不同分支各自占一个独立工作目录，物理隔离。
普通 branch 是”逻辑分支”——同一个目录切来切去；worktree 是”物理分支”——每个分支一个独立目录。superpowers 选后者，因为：
subagent 在隔离目录改，不会误碰主工作区正在改的文件，多个 worktree 能真正并行。
新 worktree 一开立刻跑测试确认”此刻是绿的”，与步②确认基线配套。
改砸了直接删 worktree，回退成本极低。
多个 worktree 并行时，连测试产物与缓存都不串台——这是 subagent 真并行的物理前提。
三个机制咬合关系：worktree 提供物理隔离 → subagent 并行、隔离干活安全 → subagent 产出的 bounded 小结果让两段式评审可行 。抽掉任何一个，”mandatory 流程”都会塌成空话。
skills库与安装 skills 大致分三类：
类别
代表 skill
职责
测试与调试
test-driven-development、systematic-debuggingTDD 节奏、系统化定位根因
协作流程
brainstorming、planning、executing-plans、subagent-driven-development、requesting-code-review对应七步中的各阶段
元 skill
writing-skills、using-superpowers教 agent 自己写新 skill、入门导引
其中 writing-skills 这个”元 skill”暴露了 superpowers 的设计野心：让 agent 能自我扩展方法论，从”用流程”走向”长出新流程”。
安装是跨 agent 的插件（截至 2026 年 7 月）。Claude Code 一条命令：
1 /plugin install superpowers@claude-plugins-official
另支持 Cursor（/add-plugin superpowers）、GitHub Copilot CLI、Antigravity、Factory Droid、Pi、Kimi Code、OpenCode 等。装好后使用方式几乎不变——还是正常下需求，变的是 agent 行为：它会先问问题、切 worktree、出 plan、派 subagent、评审，代码要到第 4–5 步才出现。
优缺点 优点 ：
流程强制、质量可控，输出从”看运气”变成”有质量保证”。
context 隔离防退化，多任务能真并行。
证据优先，每一步都有可观测的”状态”，而非 agent 嘴上说”好了”。
writing-skills 让方法论能自我生长。跨 agent 通用，方法论中立。
缺点 ：
慢、费 token：七步回合多，简单任务也走全套。
难”随手改”：流程强制，想做小改动或玩具式编程会被反复问、被流程拖住。
对用户要求高：逼你想清需求，对话量大。
subagent 依赖管理负担：边界与依赖要在 planning 阶段交代极致清晰。
存量大库里做小修小补时，全流程启动成本不划算。
适用边界
场景
适合 superpowers
认真做一个新功能/模块，要求质量
适合
多任务并行、需要质量保证的中大型改动
适合（subagent 并行优势显现）
随手改个小 bug、试个想法
过重，慢且烦
探索性/玩具式编程、快速原型
流程会拖累探索
改一行配置、改个文案
杀鸡用牛刀
需求自己都没想清、想边做边摸
它会逼你想清，可能帮也可能烦
一句话决策：正经开发用它，随手改别用它。
实际应用
下面是我在工作中真实的应用案例，使用superpowers来开发一套巡检脚本，下面是它生成的清单及步骤列表
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 Context ↑ PC大流程各业务节点受 chk_worker_live.sh 定时任务保护（cron */5，用户 cloud，lockf 防重入），通常自动重启无需干预。但运维仍需主动确认业务进程数量是否正常。目前 CloudSafeLine/CheckBusiness/ 目录已存在但为空，缺少可在统一主机上对 zzdt/shyc2/shcdt 三集群批量执行 salt 巡检、并按各集群阈值判定 PASS/FAIL 的工具。 ↑ 本计划在该目录下编写一批独立、可单独运行的 bash 巡检脚本，覆盖表格中 15 个有效检查项 + xen2 中转告警日志检查，并提供汇总脚本。只读巡检：仅打印结果与退出码，不主动发告警、不重启、不修改任何远端状态。 ↑ 关键事实（来自代码探索，已直接核对源文件） ↑ - salt nodegroup 不在本仓库：CloudSafeLine-1/2/3、VirusDBRelay 的主机成员定义在各集群 salt master 上（/etc/salt/master.d/*.conf），不在本仓库。因此 salt 命令必须在各集群 master 上执行。 - 集群→salt master 映射（CloudSafeLine/scan_unit_centos/base/scan_unit_prepare:41-44）： ↑ - shyc2 → saltmaster.grp01.qihoo.net - zzdt → saltmaster.grp08.qihoo.net ↑ - shcdt → saltmaster.grp09.qihoo.net - 进程模式串拼写（直接读 bin/start.sh 确认）： ↑ - KafkaAnalyseLog 模式：kafka_AnalyseLog_inc / kafka_AnalyseLog_merge / kafka_AnalyseLog_rescan（k 小写、A/L 大写）；ps grep 串为 KafkaAnalyseLog（目录名）。源：CloudSafeLine/KafkaAnalyseLog/KafkaAnalyseLog/bin/start.sh:6-9,27,39。 ↑ - DataDistribute 模式：DataDistribute_IncMergeMirror / _IncRescanMergeMirror / _RescanMergeMirror / _token / _feedback（Distribute 后无 r）；目录/业务名为 DataDistributer（有 r）。源：CloudSafeLine/DataDistributer/DataDistributer/bin/start.sh:6-12,29,41。 ↑ - 业务均以用户 cloud 跑 nohup /usr/local/bin/php <phpPath>/main.php -d <stage> ...；idc 取自 hostname 倒数第二段。 - 表格勘误：KafkaAnalyseLog_rescan 行的 master执行命令 实际 grep 的是 kafka_AnalyseLog_merge（复制粘贴错误）。脚本用正确的 kafka_AnalyseLog_rescan，README 注明该勘误。 ↑ - xen2 告警日志 /home/cuixiaogang/poodle/script/V1/logs/check.<date>.log 在本机不存在 —— 该检查需在 xen2.safe.lycc.qihoo.net 上本地执行（用户确认）。云舟告警用户确认不需要。 - 既有约定：仓库内 DiskSpaceMonitor/bin/run.sh 用 source $bindir/common.sh 复用 alarm()；monitor.sh 家族内联 alarm() POST 到 http://alarm.mis.corp.qihoo.net:8360/alarm。本批脚本走相同的 "source 同目录 common 库" 模式，但只读不发告警。无既有 PASS/FAIL/颜色约定 —— 由本批脚本建立。 ↑ 设计决策（已与用户确认） ↑ 1. 粒度：每个业务检查项一个独立可单独运行的脚本 + 一个 check_all.sh 汇总；外加 xen2 本地告警日志检查脚本。各业务脚本通过 source 同目录 csl_common.sh 复用 SSH/salt/解析/判定逻辑（沿用仓库 DiskSpaceMonitor 的 common 库模式）。 ↑ 2. 集群定位/执行点：从统一主机 ssh 到各集群 master（grp01/08/09），登录密码由标准输入读入；在 master 上 sudo -u root salt -N <nodegroup> cmd.run ...。假定 SSH 登录密码与 master 上 sudo 密码为同一账号密码；若 sudo 已 NOPASSWD 则密码仅用于 SSH。 ↑ 3. 告警行为：只打印 PASS/FAIL + 退出码，不 POST 告警。 4. 阈值语义：>=N → nodegroup 内所有 minion 计数求和后与 N 比较；=N → 每个 minion 的计数都必须恰好等于 N。minion 不可达（Minion did not return）记为该 minion 0 且整体 FAIL。 ↑ 文件清单（新建于 CloudSafeLine/CheckBusiness/） ↑ 通用与文档： ↑ - csl_common.sh — 共享库（被 source，不直接执行）。 - README.md — 用法、阈值表、勘误说明、runbook。 ↑ - check_all.sh — 汇总：./check_all.sh <zzdt|shyc2|shcdt>，stdin 读一次密码，遍历全部业务脚本。 ↑ 业务检查脚本（每个薄壳：定义 NAME/NODEGROUP/PS_CMD/OP/阈值表，调 csl_run "$@"）： ↑ ┌──────────────────────────────────────────────┬─────────────────┬────────────────────────────────────────────────────────────────────────────────┬─────┬──────┬───────┬───────┐ │ 脚本 │ nodegroup │ PS grep 串（ps aux | grep ...） │ op │ zzdt │ shyc2 │ shcdt │ ↑ ├──────────────────────────────────────────────┼─────────────────┼────────────────────────────────────────────────────────────────────────────────┼─────┼──────┼───────┼───────┤ │ check_newscanclient.sh │ CloudSafeLine-1 │ NewScanClient | grep -v grep | wc -l │ ge │ 85 │ 16 │ 110 │ ↑ ├──────────────────────────────────────────────┼─────────────────┼────────────────────────────────────────────────────────────────────────────────┼─────┼──────┼───────┼───────┤ │ check_downscanclient_normal.sh │ CloudSafeLine-1 │ DownScanClient | grep -v rescan_apk | grep -v rescan_hp | grep -v grep | wc -l │ ge │ — │ — │ 170 │ ↑ ├──────────────────────────────────────────────┼─────────────────┼────────────────────────────────────────────────────────────────────────────────┼─────┼──────┼───────┼───────┤ │ check_downscanclient_hp.sh │ CloudSafeLine-1 │ DownScanClient_rescan_hp | grep -v grep | wc -l │ ge │ — │ — │ 150 │ ↑ ├──────────────────────────────────────────────┼─────────────────┼────────────────────────────────────────────────────────────────────────────────┼─────┼──────┼───────┼───────┤ │ check_scan_frontend.sh │ CloudSafeLine-1 │ scan_frontend | grep -v grep | wc -l │ eq │ 1 │ 1 │ 1 │ ↑ ├──────────────────────────────────────────────┼─────────────────┼────────────────────────────────────────────────────────────────────────────────┼─────┼──────┼───────┼───────┤ │ check_kafkascanqueryuniq.sh │ CloudSafeLine-1 │ KafkaScanQueryUniq | grep -v grep | wc -l │ eq │ 8 │ 8 │ 8 │ ↑ ├──────────────────────────────────────────────┼─────────────────┼────────────────────────────────────────────────────────────────────────────────┼─────┼──────┼───────┼───────┤ │ check_kafkaanalyselog_inc.sh │ CloudSafeLine-2 │ KafkaAnalyseLog | grep kafka_AnalyseLog_inc | grep -v grep | wc -l │ ge │ 24 │ 15 │ 24 │ ↑ ├──────────────────────────────────────────────┼─────────────────┼────────────────────────────────────────────────────────────────────────────────┼─────┼──────┼───────┼───────┤ │ check_kafkaanalyselog_merge.sh │ CloudSafeLine-2 │ KafkaAnalyseLog | grep kafka_AnalyseLog_merge | grep -v grep | wc -l │ ge │ 17 │ 9 │ 20 │ ↑ ├──────────────────────────────────────────────┼─────────────────┼────────────────────────────────────────────────────────────────────────────────┼─────┼──────┼───────┼───────┤ │ check_kafkaanalyselog_rescan.sh │ CloudSafeLine-2 │ KafkaAnalyseLog | grep kafka_AnalyseLog_rescan | grep -v grep | wc -l │ ge │ — │ — │ 8 │ ↑ ├──────────────────────────────────────────────┼─────────────────┼────────────────────────────────────────────────────────────────────────────────┼─────┼──────┼───────┼───────┤ │ check_datadistribute_incmergemirror.sh │ CloudSafeLine-2 │ DataDistribute_IncMergeMirror | grep -v grep | wc -l │ ge │ 8 │ 5 │ 12 │ ↑ ├──────────────────────────────────────────────┼─────────────────┼────────────────────────────────────────────────────────────────────────────────┼─────┼──────┼───────┼───────┤ │ check_datadistribute_token.sh │ CloudSafeLine-2 │ DataDistribute_token | grep -v grep | wc -l │ ge │ — │ — │ 12 │ ↑ ├──────────────────────────────────────────────┼─────────────────┼────────────────────────────────────────────────────────────────────────────────┼─────┼──────┼───────┼───────┤ │ check_datadistribute_rescanmergemirror.sh │ CloudSafeLine-2 │ DataDistribute_RescanMergeMirror | grep -v grep | wc -l │ ge │ 6 │ 4 │ 12 │ ↑ ├──────────────────────────────────────────────┼─────────────────┼────────────────────────────────────────────────────────────────────────────────┼─────┼──────┼───────┼───────┤ │ check_datadistribute_increscanmergemirror.sh │ CloudSafeLine-2 │ DataDistribute_IncRescanMergeMirror | grep -v grep | wc -l │ ge │ — │ — │ 4 │ ↑ ├──────────────────────────────────────────────┼─────────────────┼────────────────────────────────────────────────────────────────────────────────┼─────┼──────┼───────┼───────┤ │ check_datadistribute_feedback.sh │ CloudSafeLine-2 │ DataDistribute_feedback | grep -v grep | wc -l │ ge │ — │ — │ 12 │ ↑ ├──────────────────────────────────────────────┼─────────────────┼────────────────────────────────────────────────────────────────────────────────┼─────┼──────┼───────┼───────┤ │ check_feedback_relay.sh │ CloudSafeLine-3 │ feedback | grep -v grep | wc -l │ eq │ — │ — │ 1 │ ↑ ├──────────────────────────────────────────────┼─────────────────┼────────────────────────────────────────────────────────────────────────────────┼─────┼──────┼───────┼───────┤ │ check_virusdbrelay_rundaemon.sh │ VirusDBRelay │ run_daemon | grep -v grep | wc -l │ eq │ 12 │ 12 │ 12 │ ↑ └──────────────────────────────────────────────┴─────────────────┴────────────────────────────────────────────────────────────────────────────────┴─────┴──────┴───────┴───────┘ ↑ DownScanClient APK 行表格为 无/无/无（未部署/不检查），不创建脚本，仅在 README 注明。 xen2 本地脚本： ↑ - check_scanner_relay_alarm.sh — 在 xen2.safe.lycc.qihoo.net 本地以 cuixiaogang 执行（无 ssh/salt）：检查当天 /home/cuixiaogang/poodle/script/V1/logs/check.<date>.log 存在、非空、mtime 在 30 分钟内（cron 节奏未知，30min 为保守阈值，README 注明可调）。 ↑ csl_common.sh 提供的接口（被各业务脚本 source） ↑ - csl_master_for <cluster> — 返回集群对应 master FQDN（zzdt/shyc2/shcdt → grp08/01/09）。 ↑ - csl_getpass — 幂等从 stdin 读一次密码到 CSL_PASS（tty 用 read -s，非 tty 用 read）；已设置则跳过。汇总脚本先调一次，子脚本复用。 - csl_salt_counts <cluster> <nodegroup> <ps_cmd> — ssh 到 master，sudo -S -u root salt -N <nodegroup> cmd.run '<ps_cmd>' --out=json -l（sudo 密码经 ssh stdin 注入 <<<"$CSL_PASS"），用 python3 解析 JSON，输出 <minion> <count> 行；不可达 minion 输出 <minion> UNREACHABLE。无 python3 时回退报错并提示。 - csl_run "$@" — 业务脚本入口：读全局 CSL_NAME/CSL_NODEGROUP/CSL_PS/CSL_OP/CSL_THR(关联数组)，解析位置参数 <cluster|all>；该集群无阈值 → 打印 [ N/A ] <name> cluster=<c> (未部署) 并 exit 0；否则调 csl_salt_counts，按 op 判定（ge 求和 vs 阈值；eq 逐台 vs 阈值），打印 [ PASS ]/[ FAIL ] <name> cluster=<c> nodegroup=<ng> actual=<...> expected<op><N>，exit 0/1。支持 --print 仅打印将执行的 salt 命令不执行（便于校验/排错）。 ↑ 传输实现细节与假设（README 重复说明）： ↑ - 依赖 sshpass（提供 SSH 密码）；若已配置免密 key，可设 CSL_SSH 环境变量覆盖传输命令。 - ssh -o StrictHostKeyChecking=no -o ConnectTimeout=10。 ↑ - salt 用 --out=json 便于稳定解析；cmd.run 输出形如 {"minion1":{"stdout":"8\n","retcode":0,...},...}；不可达 minion 值为字符串 "Minion did not return. [Not connected]"。 ↑ 业务脚本模板（以 NewScanClient 为例） ↑ #!/bin/bash ↑ # Check: NewScanClient (PC大流程) # nodegroup=CloudSafeLine-1 op=ge(sum) 阈值: zzdt>=85 shyc2>=16 shcdt>=110 set -u DIR=$(cd "$(dirname "$0")" && pwd); . "$DIR/csl_common.sh" L_NAME="NewScanClient" CSL_NODEGROUP="CloudSafeLine-1" CSL_PS='ps aux | grep NewScanClient | grep -v grep | wc -l' CSL_OP=ge declare -A CSL_THR=( [zzdt]=85 [shyc2]=16 [shcdt]=110 ) csl_run "$@" 其余脚本同构，仅替换 5 个常量；CSL_OP=eq 用于 scan_frontend/KafkaScanQueryUniq/feedback_relay/virusdbrelay_rundaemon。无阈值的集群在 CSL_THR 中省略键 → 自动 N/A。 汇总脚本 check_all.sh #!/bin/bash # Usage: check_all.sh <zzdt|shyc2|shcdt> (从 stdin 读一次 ssh/sudo 密码) set -u DIR=$(cd "$(dirname "$0")" && pwd); . "$DIR/csl_common.sh" cluster="${1:-}"; [ -z "$cluster" ] && { echo "Usage: $0 <zzdt|shyc2|shcdt>"; exit 2; } csl_getpass # 读一次，子脚本复用 fail=0 for s in "$DIR"/check_*.sh; do b=$(basename "$s") [ "$b" = "check_all.sh" ] && continue bash "$s" "$cluster" || fail=1 ne ho "-----"; [ $fail -eq 0 ] && echo "ALL PASS ($cluster)" || echo "SOME FAILED ($cluster)" it $fail 验证（实现后执行） 1. 语法：对所有脚本 bash -n（本机即可，无需 master 访问）。 2. dry-run 校验命令串：./check_kafkaanalyselog_rescan.sh --print 应输出 grep kafka_AnalyseLog_rescan（而非 merge，验证勘误已修）；./check_datadistribute_incmergemirror.sh --print 应输出 DataDistribute_IncMergeMirror（无 r）。 3. 单业务实跑（需可 ssh 到对应 master 且装 sshpass、python3）： - ./check_newscanclient.sh shcdt（stdin 喂密码）→ 验证 salt JSON 正确解析、计数与人工 salt -N CloudSafeLine-1 cmd.run 'ps aux | grep NewScanClient | grep -v grep | wc -l' 一致。 - ./check_kafkascanqueryuniq.sh shcdt → 验证 eq 逐台判定（每台应 =8）。 4. 汇总：./check_all.sh shcdt → 汇总表 + 退出码；人为 kill 一个非关键进程验证 FAIL 通路与退出码 1（验证后恢复，由 chk_worker_live.sh 自动拉起）。 5. xen2 告警：在 xen2 上 ./check_scanner_relay_alarm.sh → 当天日志存在且新鲜时 PASS；临时改文件 mtime 验证 FAIL（验证后恢复）。 6. N/A 通路：./check_downscanclient_normal.sh zzdt → 应输出 [ N/A ] ... (未部署) 且 exit 0（zzdt/shyc2 无该业务）。 ▎ 注意：步骤 3-5 需要真实 master/xen2 访问权限，本机无法执行；实现阶段仅做步骤 1-2 的本地静态校验，3-5 交由运维在具备权限的环境运行。
小结与延伸 superpowers 的本质，是把”先确认需求 → 制定计划 → 执行开发 → 审核”这条专业开发者本能的流程，强制套到 agent 身上。最大价值是稳定、确保准确；最大代价是慢、费 token、问答多。
