【免费下载链接】jevgrepFind code by asking what it does. A CLI for coding agents that uses Jev to discover relevant files and source context.项目地址https://gitcode.com/gh_mirrors/je/jevgrep点击查看免费下载导读本文深入剖析 Jevgrep 仓库中audit-choices技能——一种只审计决策、不审计代码 diff的纯决策审查方法。它解决的核心问题是AI 实现者在任务未写明的地方自行做了大量决定而代码 review 无法发现这些决定本文讲解其回追溯源 → 分类判定 → 落账 Choices Ledger → 按置信度呈现的完整工作流并结合仓库中 jevgrep 实现记录的选择账本 与 provider-support 选择账本 展示真实落地形态。读完你既能直接调用该技能审查委托给 Agent 的工作也能理解如何在任何 AI 辅助开发流程中建立自己的决策审计机制。为什么要审计选择而不是审计diff给定一个好决策Agent 会忠实实现它但凡是任务说明不充分的地方Agent 就会自己默默做决定——而 diff 不会把这一点标记出来。审查几千行变更既不现实而且它检查的是执行过程那通常是没问题的。真正可扩展的审计对象是选择把实现者自行做出的每一个决定都摆到台面上逐一评判并记录结论。这本质上是架构问题而非 bug 问题。一个实现可以完全正常运转却建立在用户从未做出的决定之上——比如一个数据结构形状、一个存储位置、一个新增依赖、一个 API 契约、一个用内存换速度的取舍——而其中每一个都对未来的工作承重。用户需要知道它们不是因为它们错了而是因为它们从此归用户所有。该技能定位明确这是纯粹的决策审计——不改任何代码可随时调用。它产出的选择账本choices ledger替代通读代码成为用户的审查面这正是它的全部意义。对判定结果采取行动重做不合理的选择、采纳临时方案属于调用方运行中的实现工作流或读完报告的用户。两种调用入口同一套审计被工作流调用每 pass 或每 slice 一次审计该 pass把条目追加进账本后返回工作流在交回控制权时展示累积的账本。被用户直接调用审计面前的全部工作会话、分支或命名变更立即呈现报告。只做建议不改任何东西。五步工作流从回追溯源到按置信度呈现1. 引出与回追溯源Elicit and trace back当实现者报告完成了时先问一句做这项工作时你哪些选择自己没把握全部列出来。但要把自我报告当作起点而非边界——Agent 普遍少报。必须自己追溯历史会话的每一步、子 Agent 的报告、diff、提交——收集所有在工作里但不在原始 spec 或 prompt 里的决定。要扫遍架构类别而不只是可疑的修复数据结构与格式、存储与命名方案、API 契约及其错误行为、新增依赖、并发/性能取舍、范围解读、未来代码会模仿的模式。审计自己的会话时用同样方式追溯自己的步骤。计划中明确委托给实现者的选择属于裁量discretion不是审计项。2. 基于证据对每个选择分类Triage each choice on evidence先问这是被计划强制的还是发明的被发明的才需要细查这是通用解还是只针对那一个失败用例塑形的点修复每个选择的判定有三种sound合理用户会做出同样选择。unsound不合理选择本身有问题需要重做。needs-user需用户裁决真正只有用户能定的品味、产品方向、外部成本。与判定并列的是置信度confidence——审计方对用户会做出同样选择的把握程度它是报告排序的依据。needs-user只保留给真正用户专属的调用每条needs-user条目都必须附带一个可逆的、推荐的临时方案这样无人值守的调用方不必等待就能继续。审计从不卡住运行每条条目都是一个交给行动或审查的判断而不是一个让流程停摆的问题。3. 陈述修正后的决策而不是勾画补丁对每个 unsound 选择条目要指明工作应从中重做的那种决策——即一般意义上必须成立的性质——而不是一个叠加在上的编辑。叠加在坏决策之上的补丁等于保留了坏决策重做本身是调用方的事且须在账本审阅之后进行。4. 把每个选择存进账本并提升承重条目把承重的 sound 选择提升进计划的交接说明让后续 pass 把它们当作既定前提继承而不是重新决定一遍。5. 呈现账本按判定分组按置信度排名审计的交付物是账本交给下一个行动者——运行中的调用工作流或运行结束时的用户。每个判定组对应一种行动needs-user→ 决定借助临时方案unsound→ 重做依据修正后的决策sound→ 确认接受这就是用户现在拥有的架构。组内按置信度从低到高排序。账本很长时用整体置信度最低的两三个选择开篇无论它们属于哪一组——这就是先审这些一行。sound 组不可跳过。只有琐碎裁量内部命名、纯装饰性调用才压缩成一行计数。每条条目必须 ELI5 写作——默认如此而非应要求读者没有亲历会话。每条条目都要用 eli5 技能 的语域写作端到端走一个具体场景触发事件、工作今天做了什么、未构建的替代方案会做什么每个术语在首次出现时给出定义当选择涉及控制流、顺序或时序时给出决策层面的伪代码条件和它们的顺序而不是真实函数签名。有门控的询问被丢弃而不是延迟是一句标题不是一条条目。一条压缩到让用户问这条什么意思的条目就是失败的账本必须能脱离 diff、spec 和 transcript 独立成立。判断何时需要伪代码的线索是你的行文里有仅当之前除非一……就……而读者仍说不清第二次调用会发生什么。eli5 技能本身给出了更完整的语域要求读者是懂技术的但没读过任何代码和任何会话消息——没有 diff、没有 transcript、没有工作过程中发明的标签要用小而有形的例子而不是用类比替代精确表述输出顺序固定为Problem→Solution→Schema changes。Choices Ledger字段与规则账本是一个比任何一次 pass 都长寿的专用文件choices.md放在计划旁边当 spec 拥有这项工作时为specs/feature/choices.md。每个被审计的选择一条条目When何时——它落地的 pass 或提交。The choice选择本身——一行标题然后是 ELI5 场景触发事件、工作今天做什么、未构建的替代方案会做什么术语就地定义。The gap缺口——计划留下了什么未指明、从而迫使了这个选择。The reach波及面——这个决定约束或使能的未来工作为什么用户需要知道它存在。Verdict判定——sound / unsound / needs-user附一行理由。unsound 给出要重做的修正决策needs-user 给出推荐的临时方案及如何逆转。Confidence置信度——审计方对用户会做出同样调用的把握low / medium / high。升序为报告排序。账本规则落账即定案已进账或被提升进计划的选择对后续 pass 是既定前提——绝不重列、绝不重判。账本是计划质量信号条目聚集在某一个 slice 或区域说明计划在那里模糊——应重新切片或让那部分回到 spec 流程而不是永远处理同一类选择。ELI5 在每次改写中幸存上述条目格式标题加就地定义术语的走场景是存储格式不是展示打磨。条目合并、重审、收尾再审计或复制进最终账本时每条幸存条目都保留或重新获得完整场景。已知的失败模式正是这种压缩收尾改写把已存条目压缩成标题会产生一份需要读者追问的账本——检查点按邮箱顺序加载行当后引用有更早的 createdAt 时拒绝列表读起来像已定案但只有走场景版本两个会话、彼此不可比较的逐会话序号、共享插入时间戳时钟才能让读者真正判断这个选择。丢了场景的合并就是失败——即使每个事实都幸存反过来保留了场景却依赖构建过程中发明的标签重试信封证据缝而不在使用处定义它们同样是失败。规则审计的边界与能跑陷阱能跑不是对选择的判定。反复出现的味道是巧合式修复一个恰好加大到覆盖失败输入的缓冲区、超时或特例而根因仍潜伏。要问什么性质能一般地保证修复如果答案是这个用例通过了那即使代码全绿这个选择也是 unsound。宣布成功是风险最大点——实现者自信最高时恰是它未经审视的选择即将被合并之时。结果看起来干净绝不是跳过审计的理由。非平凡工作上出现空列表是红旗不是通过。要追问任务哪里没写明白总有什么东西填补了那些缺口。审计不改任何代码、测试或构建状态。发现 unsound 选择是交付物不是修复许可——记下修正决策让树保持审计后的原样这样账本和树对调用方正在决定什么保持一致。收集证据是允许的读任何东西、运行现有测试、写临时探针——但交还前必须移除每个探针。仓库中的真实账本从技能到落地的完整闭环audit-choices 不是纸上谈兵——Jevgrep 仓库内就有两份真实账本正好示范了技能要求的一切。实例一jevgrep 实现记录的选择账本specs/done/jevgrep/choices.md 是技能所称specs/ /choices.md的标准落点。它的开头明确说明这份账本描述实现中体现的决策而不是其验证状态并给出先审这些行——三个 medium-confidence 选择基准工作时钟、跨文件证据的内部顺序、共享 Python 解释器。账本按## Sound — medium confidence与## Sound — high confidence分组组内按置信度升序排列每条都完整携带六个字段。举几个典型条目Measure benchmark work separately from waiting for retrievalMedium走了一个完整场景——编码 Agent 花 12 分钟等独立jg搜索、再花 5 分钟编辑测试监控器把 5 分钟记入 15 分钟工作额度两条搜索并行时不赚取双倍等待额度。配了规则伪代码if a recognized search is active and no other command is active: count elapsed time once as retrieval waiting else: charge elapsed time as work条目明确 Gap目标把耗时当诊断信息但仍需失控上限、Reach单独的 24 小时墙钟守卫保留主机崩溃仍可能留下所属容器、Verdict对成本/质量目标 sound、Confidencemedium因为观测事件是近似且变更指令本身就是比较的一部分并给出 Owner 文件 installed.py。Revalidate buffered source through the same filesystem policyHigh解释了一个请求排队期间用户编辑了源文件 A 的情形——请求携带 A 的原始内容哈希评估前及每次 provider 尝试前由同一 reader 校验资格并比对当前字节改了就不能再知情地提交。配伪代码bind buffered content to its snapshot queue validation in arrival order if a required source changed or became excluded: remove its stale evidence; report incomplete retain independently valid work where possible else: evaluate with the unchanged semantic request before returning, recheck candidate snapshots其声明克制且可证检查是观测不是锁检查之后的变化与已传输的字节无法撤销——这是对已检测变化 sound不声称原子文件系统一致性。Enforce the cache bound by scanning stored entriesMedium直白披露成本——发布完整答案原子写入后按文件系统枚举序扫描、删除超预算条目不是最旧优先淘汰不维护持久索引无后台清理服务存储是尽力而为大缓存写吞吐受重复扫描限制此机制不做吞吐承诺。账本中还有一条值得注意的元信息source selection保留 spike 的 1,000,000 字节检查上限——更大的已接纳文件保留位置与角色分类但不做声明求值packet 报告source_inspection_limit见 parity-restoration.md 中的讨论。这展示了ELI5 场景 精确边界在真实条目中的样子。实例二provider-support 的选择账本specs/done/provider-support/choices.md 展示了技能的另一面把已在 spec 内的选择明确划出审计范围。它只有一条Sound — high confidence条目New benchmark plans use schema 4然后专门列了一节Within the specificationprovider 预设、单记录认证、环境移除、遗留密钥处理、缓存隔离、重试策略和外部测试传输都已由 spec 决定内部命名与探针布局是已委托的裁量。它还保留了共享 Node 路由 fixture 的决策场景——测试显示把 SDK 原始 body 转成流会掩盖 401 错误因此保留原始 body这是实现既定传输契约而非增加产品行为。这与技能步骤 1 的计划显式委托的选择是裁量不是审计项完全对应审计的价值在于把边界画得诚实而不是把所有事都塞进账本。实例三ELI5 的并发佐证技能要求术语首次出现即定义、用伪代码表达时序而仓库里正好有一处真实教训可以印证为何这是硬性要求在 jevgrep 实现记录 的Historical review corrections一节详见 parity-restoration.md一次全产品审查复现了两个普通保真缺陷参考实现按源选择完成顺序构建第二遍selectedEvidence而移植版用了接纳顺序——推迟一个文件就翻转了有意义的数组顺序即使模型分数完全相同另一个是 TS/JS 语法回退在收集注释前就返回导致块注释内的选中片段被截断而不是展开成参考版的完整注释。这两个都是工作正常但选择未被审视的典型也正是 audit-choices 说要提前摆上台面的东西——commita7a28bb与bcf3253修复后用失败于修复前的 whole-CLI 回归测试钉死了行为。记账惯例账本如何被引用仓库的惯例是实现记录 README 指向账本并说明其职责分工——jevgrep 实现记录 写明契约定义公共语义选择账本记录实现决策与权衡并给出机制代码的落点core、CLI、installed tests、retrieval 行为测试provider-support README 同样把账本作为额外基准格式决策的说明处其 final-verification.md 则把结论直接锚定到已记录在选择账本中。这套README 引路 账本定案的结构正是 audit-choices 第 5 步账本交付给下一个行动者的仓库级实践。何时使用、何时算完成何时调用合并或提交 AI 实现的工作之前审查委托子 Agent 的一次 pass 时当一个修复能用但可能只是点修复时——用户想审查 AI 替自己做的决定。完成定义Done审计完成的标志是——该 pass 中每个被发明的选择都有带判定的账本条目每条 unsound 条目都指明要重做的修正决策每条 needs-user 条目都携带可逆的临时方案账本已按判定分组、组内最低置信度优先、每条都能 ELI5 独立读懂地呈现给下一个行动者且树保持原样。交还时展示 diff 而不是选择或审计期间顺手修了东西都不算完成。一句话总结这套方法的精髓把审查执行换成审查决策把通读代码换成阅读账本——因为能跑的代码仍然嵌着用户从未选择过的架构而未来的工作会继承它。把它摆到台面上来因为用户从此拥有它。赞分享【免费下载链接】jevgrepFind code by asking what it does. A CLI for coding agents that uses Jev to discover relevant files and source context.项目地址https://gitcode.com/gh_mirrors/je/jevgrep点击查看免费下载相关推荐awesome-python 列表审计实战audit-the-list 技能如何用实时数据重审 README 中的每个条目awesome python 列表审计实战audit the list 技能如何用实时数据重审 README 中的每个条目 awesome python 是一文档知识库LobeHub UX 审计实战从 ux-audit 技能的 Agent 用量与成本仪表盘审计实例stats.md入手LobeHub UX 审计实战从 ux audit 技能的 Agent 用量与成本仪表盘审计实例stats.md入手 本篇以 LobeHub 仓库中 UX人工智能AI 应用大模型AI Agent多智能体工具调用前端后端用 spotDL 下载 Spotify 音乐时如何挑选音频格式完整格式选择指南用 spotDL 下载 Spotify 音乐时如何挑选音频格式完整格式选择指南 spotDL 是一款能把 Spotify 歌单和歌曲连同封面与元数据下载到CLI音频音视频网页爬虫创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
 】建造者模式)
