【免费下载链接】skills
Reusable AI agent skills for software factories: explore ideas, write specs, implement, review, and run autonomous research. Works with Claude Code, Codex, and other skill-compatible agents.
当你让 AI Agent 替你写代码，真正的风险不在几千行 diff 里，而在那些规格书没写、AI 自己拍板的决定中。dzhng/skills 中的 audit-choices 技能，就干这一件事：做一次纯决策审计——不读代码细节、不改一行代码，把 AI 在实现过程中替你做下的每一个决定追出来，记入choices.md决策账本，让你用半小时审完一次两天无人值守的自主运行。
为什么"审代码"这件事不再靠谱？
传统代码审查有个隐藏前提：改动的每一行都源于"人"的意图。但 AI Agent 不是这样工作的——
- 任务没写清楚的地方，它会自己补全。数据形状、存储位置、依赖选型、API 契约、内存换速度的权衡……diff 里不会有任何标记提醒你"这里是我替你做主的地方"；
- 能跑起来 ≠ 决定是对的。代码可以完美工作，却建立在用户从未选择的架构之上——而这些决定对后续所有工作都是承重墙；
- 审查几千行改动根本不可扩展，而且它审的是"执行"（通常没问题），不是"选择"（真正可能出错的）。
audit-choices 的思路是反转的：把审计对象从 diff 换成决策清单。把实现者自行做出的每个决定列出来、逐条给出结论、记录在案——这份清单就取代了"读代码"，成为你真正的审查面。
audit-choices 是什么？
一句话概括：一个永不阻塞运行的决策审计器。
它的核心约束写在 skills/engineering/audit-choices/SKILL.md 里：
| 特性 | 说明 |
|---|---|
| 🔍 只审计，不动手 | 不修改代码、测试、构建状态，审计完代码树原样保留 |
| ⏸ 永不卡住运行 | 每个条目是"交出去的判断"，不是"等待回答的问题" |
| 📋 交付物是账本 | 一份按结论分组、按置信度排序的决策清单（choices.md） |
| 🧍 两种进入方式 | 被工作流逐片调用，或由用户直接对整个分支/会话调用 |
它更关心架构而非bug：你不需要知道某个决定是错的才需要知道它存在，而是因为你从此要拥有它。
决策账本怎么生成：五步工作流
audit-choices 的执行流程是一个完整的"回溯—分诊—记账"循环：
第一步：回溯追问（Elicit and trace back）
先问实现者："这次工作中，哪些选择是你没把握的？全部列出。"但自报只是起点，不是边界——Agent 普遍少报。审计者会自己回溯整个会话的步骤、子代理报告、diff 和提交，把"在工作里、但不在原始规格里"的决定全部收集起来，覆盖数据形状、存储与命名方案、API 契约、新增依赖、并发与性能权衡、范围解释、未来代码会模仿的模式等架构类别。
第二步：按证据分诊（Triage on evidence）
对每个决定先问一句：是计划逼出来的，还是自己发明的？发明的才需要细看——它是通用解，还是只针对那一个失败案例的特殊补丁？
每个决定拿到三个结论之一：
- ✅sound（可靠）：架构上站得住
- ❌unsound（不可靠）：需要推倒重来
- ⚖️needs-user（需用户定夺）：品味、产品方向、外部成本这类只有人能拍板的
每个结论还配一个置信度（审计者有多确信"用户本人也会这么选"），用来给报告排序。
第三步：给出"修正后的决定"，而不是补丁草图
对 unsound 的条目，账本记录的是应该基于什么性质重做，而不是在坏决定上再糊一层补丁——补丁会保留坏决定本身，重做由读者看完账本后自行决定。
第四步：全部入账
每个审计过的决定都进choices.md账本；承重的可靠决定会被提升到计划交接区，后续轮次直接继承，不再重复决策。
第五步：按"结论分组 + 置信度升序"呈现
报告里最没把握的两三条放在最前面（"先审这几条"），needs-user 条目必须附带可撤销的临时决定——这样无人值守的调用方可以继续推进，不用干等。所有条目默认按 eli5 的"讲给外行听"标准撰写：完整走一遍场景、专业术语首次出现即定义，让没经历那次会话的人读完账本就能下判断。
一条决策账本长什么样？
账本固定存放在计划文件旁边（有规格书时是specs/<feature>/choices.md），每个条目六个字段：
| 字段 | 内容 |
|---|---|
| When | 落在哪一轮/哪次提交 |
| The choice | 一行标题 + 完整场景走查（触发事件、现状、未实现的另一方案） |
| The gap | 规格书留下了什么空白，逼出了这个决定 |
| The reach | 这个决定约束或解锁了哪些未来工作 |
| Verdict | sound / unsound / needs-user + 一行理由 |
| Confidence | low / medium / high，决定报告排序 |
账本有三条铁律：已入账即既定（后续轮次不再重列重议）、条目聚集是计划质量信号（某一片区域条目扎堆，说明该区域规格模糊，应回去重新切分而非反复分诊同类决定）、ELI5 场景在任何合并、重写时都必须存活——把完整场景压缩成一行标题的账本，等于废掉了读者的判断能力。
安装与上手
audit-choices 是 dzhng/skills 技能库中 20 多个工程技能之一，兼容 Claude Code、Codex、Cursor 等所有支持 skills 的 harness，安装只需一条命令：
npx skills add dzhng/skills从克隆的仓库本地安装则运行npm run install-skills（脚本在 scripts/install-skills.mjs），也支持--only audit-choices只装这一个。装好后，典型用法分两种：
- 随工作流自动触发：
/goal /implement-spec specs/<feature>跑完时，运行结束会汇总specs/<feature>/choices.md——所有规格书沉默之处 AI 做的决定，按置信度从低到高排好，这就是你的审查面。把修改意见发回去，下一轮自动再审计； - 临时单独调用：对一段没有规格书出处的改动（比如一次随手修的 bug），先跑
/review（refactor-clean → code-review → write-docs），再跑/audit-choices。当 diff 大到读不动时，决策账本就是你理解"代码库里现在多了什么"的唯一可行方式。
什么时候该跑一次 audit-choices？
技能描述里给了三个信号，都很具体：
- 合并或提交 AI 实现的工作之前——"看起来干净"恰恰是风险最高的时刻，实现者的信心峰值正好压着那些未经审视的决定；
- 整合一个委托子代理的成果时——你没法全程旁观，只能靠它的报告、转录和 diff 重建它的每一步决定；
- 一个修复"能跑了"但疑似点对点修补时——调大的缓冲区、调长的超时、加的特殊分支，如果"保证成立"的理由只是"这个用例过了"，那它就算测试全绿也是 unsound。
反过来也要记住：在非平凡工作里审计出空清单是红旗，不是通过——总有些东西填了规格的空白，去追问它是什么。
小结：你的时间花在两端，中间交给账本
在 dzhng/skills 的完整回路里，人的时间全部集中在头尾：前 30 分钟到几小时做探索和规格（explore-unknowns → write-spec），中间几小时到几天无人值守构建，最后再花 30 分钟到几小时审查决策。audit-choices 就是收尾那端的承重墙：
- 审查面从"diff"换成"决策清单"，审查成本从 O(代码行数) 降到 O(决策条数)；
- 审计永不阻塞运行，无人值守流程可以放心挂着；
- 每次 AI 写代码，你就审计它替你选择的部分——代码可以被重写，但账本里记下的架构，是你从此拥有的东西。
【免费下载链接】skills
Reusable AI agent skills for software factories: explore ideas, write specs, implement, review, and run autonomous research. Works with Claude Code, Codex, and other skill-compatible agents.
相关推荐
Jevgrep 的 AI 决策审计技能（audit-choices）：用 Choices Ledger 审查实现 Agent 替用户做出的每一个选择
Jevgrep 的 AI 决策审计技能（audit choices）：用 Choices Ledger 审查实现 Agent 替用户做出的每一个选择 导读 ：本
开发工具AI 应用代码智能体AI 技能/插件让技能保持锋利：dzhng/skills 的 eval-skills 与 audit-agents 质量审计实战
让技能保持锋利：dzhng/skills 的 eval skills 与 audit agents 质量审计实战 dzhng/skills 是一套面向 Clau
Decepticon 审计账本（Audit Ledger）实战：RoE 决策的 HMAC 链式防篡改记录与验证
Decepticon 审计账本（Audit Ledger）实战：RoE 决策的 HMAC 链式防篡改记录与验证 本文围绕 Decepticon 的审计账本机制展
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
