AI 技能AI 插件应用安全网络安全AI 评测【免费下载链接】skillsTrail of Bits Claude Code skills for security research, vulnerability detection, and audit workflows项目地址https://gitcode.com/gh_mirrors/skills8/skills点击查看免费下载导读在评估一个 AI Agent 是否真正完成代码评审任务时最致命的假阳性不是评得不好而是根本没产出产物却把产物描述得头头是道。本文聚焦 Trail of Bits 的 review-walkthrough 插件中rate-limit-walkthrough评估案例的 artifact-written 判定规则剖析这条file_exists闸门如何以双倍权重守住整个评估体系的底线并展示它与渲染器校验、其余 7 个 grader、fixture 脚手架和自动化测试之间的完整协作关系。读完本文你将掌握产物真实性闸门在 Agent 评估管线中的设计思路以及如何用文件存在性检查、正则断言、工具调用追踪和 LLM 语义评分四层手段组合防御口述式成功。一、artifact-written判定规则一句话的闸门全体系的底线artifact-written.md是整个rate-limit-walkthrough评估案例中最短、却权重最高的判定规则之一。它的完整内容如下--- type: file_exists weight: 2 path: walkthrough.html exists: true --- The artifact has to be on disk. This is the guard against the failure this repo has already shipped once: a run that describes the deliverable convincingly enough to satisfy a transcript-reading judge without ever producing it. Every other artifact grader is meaningless if this one fails, so it carries double weight.逐字段拆解这条规则type: file_exists声明该 grader 的类型是文件存在性检查即判定器会去目标路径上确认产物是否真实存在而非依赖任何语义理解。weight: 2权重为 2。结合 evals/README.md 中--threshold 1.0要求每个参与评分的 grader 都必须通过的说明权重意味着在通过/未通过的门槛计算中占双倍比例。path: walkthrough.html检查的目标文件即本次评估要求 Agent 产出的交互式 HTML 评审走查页面。exists: true期望的判定结果是文件存在。若文件缺失该 grader 直接判负。该规则的关键论断有两条直接构成了本文要展开的核心理念产物必须真实落盘一个只描述交付物而不实际生成它的运行无论描述得多有说服力都不能算作完成任务。仓库明确记录了这一失败模式曾经真实发生the failure this repo has already shipped once——在评估历史上曾出现过一次运行通过详尽的口头描述骗过了阅读转录文本的评审却从未产出真实文件的情况。双倍权重的理由该闸门是所有产物类 grader 的前提。如果walkthrough.html不存在那么针对它的正则检查、LLM 语义评审、锚点校验统统没有意义因此它carries double weight。从这一定义出发我们可以在仓库中找到完整的工程化支撑为什么产物必须是 HTML、如何保证它是被真实渲染出来的、以及其余判定如何分工。二、为什么产物是walkthrough.html技能契约与渲染链artifact-written检查的文件并非随意指定而是由技能契约与渲染链共同定义。在 review-walkthrough 技能文档 中技能被设计为生成自包含的 HTML 走查页面将分支的最终 diff 拆分为逻辑步骤并附带解释与关键评审结论。对于无头headless运行场景评估 prompt 明确要求将完成的走查写入工作目录下的walkthrough.html不要运行open无浏览器环境仓库没有 GitHub remote 与打开的 PR因此不调用ghpr_meta视为缺失继续执行本运行是通过读取walkthrough.html来检查的而不是阅读你的总结因此对走查内容的描述得零分。最后一条正是artifact-written的设计意图在 prompt 层面的回响评分依据是磁盘上的产物而不是 Agent 的自我汇报。产物的数据契约由技能文档中的字段表定义title评审标题、steps步骤数组含sha、message、files、diff、explanations每步一段 HTML 解释、reviews每步的发现数组含severity/title/body锚定发现还带file/line/side与可选的end_line、pr_metaGitHub PR 元数据或null。三个数组长度必须相等且一一对应。真正把 JSON 数据变成walkthrough.html的是插件自带的渲染器 render_walkthrough.py。调用方式在技能文档中给出uv run --no-project {baseDir}/scripts/render_walkthrough.py \ --input /tmp/data.json \ --diff /tmp/captured.patch \ --output /tmp/walkthrough.html渲染器不是简单的模板替换——它在渲染前执行多层校验详见第三节并且会拒绝用自写的页面绕过它见renderer-usedgrader。template.html中则预留了五个占位符TITLE_PLACEHOLDER出现两次位于title与h1、STEPS_PLACEHOLDER、EXPLANATIONS_PLACEHOLDER、REVIEWS_PLACEHOLDER、PR_META_PLACEHOLDER各一次位于 template.html 的脚本区。渲染器会校验每个占位符的出现次数恰好符合预期TITLE_PLACEHOLDER两次其余各一次再一次性完成替换防止占位符文本被递归替换。三、渲染器产物真实性在落盘之前的最后防线artifact-written保证文件存在但一个存在却内容空洞、甚至仍是模板占位符的 HTML 同样没有价值。因此render_walkthrough.py 在写出文件前执行了五类校验1. 结构完整性校验normalize_data要求输入必须是 JSON 对象title为非空字符串steps为非空数组且explanations、reviews与步骤数严格一一对应。2. 补丁真实性校验split_diff要求步骤的diff值以diff --git开头patch_paths通过git apply --numstat -z用 Git 自身的引号规则解析路径确保捕获的补丁能被 Git 解析最关键的是每个步骤中的每个 diff 块必须原样来自捕获的完整补丁any(block not in originals ...)即拒绝并且Counter(seen) ! Counter(blocks)时拒绝——即每个被捕获的文件 diff 必须恰好出现在一个步骤中不得缺失、不得重复。3. 锚点校验review_anchor每个锚定发现必须指向本步骤内的文件line/end_line必须构成正整数有序区间且该区间必须落在同一 hunk 的同一侧LEFT 或 RIGHT上若区间在两侧都存在歧义则要求显式指定side。这解释了技能文档中对新增或新文件上下文用RIGHT对删除或旧文件上下文用LEFT的约定。4. PR 元数据校验normalize_prowner/repo必须匹配 GitHub 仓库名校验pr_number必须为正整数head_sha必须是完整的 40 位十六进制 SHA。5. 模板占位符替换render用json.dumps(...).replace(, r\u003c)安全嵌入数据并校验每个占位符的期望出现次数最后单趟替换re.sub一次完成防止占位符文本被递归替换。一个值得注意的细节渲染器用read_text读取补丁时特意保留 CRLF、不做通用换行转换因为换行转换会改变证据注释原话universal-newline conversion changes the evidence。这种对证据保真的执着正是整个产物真实性工程的底色。四、双倍权重的结构含义它保护了其余 7 个 graderrate-limit-walkthrough案例共有 8 个 graderartifact-written是唯一一个type: file_exists的闸门。其余 7 个全部以walkthrough.html为目标因此文件存在是它们共同的前置条件。下表展示了完整的分工与权重grader类型权重检查内容artifact-writtenfile_exists2walkthrough.html必须存在于磁盘definitions-before-wiringregex3定义必须先于消费者app/middleware.py的步骤不得出现在ratelimit/bucket.py之前criteriallm3评审确实发现真实缺陷且每条解释引用步骤 diff 中的真实标识符no-placeholder-survivesregex2产物中不得残留STEPS_PLACEHOLDER等模板占位符renderer-usedtool_used2必须调用内置渲染器render_walkthrough.py不得用手写模板替换替代review-anchored-to-bucketregex2至少一条评审发现锚定到ratelimit/bucket.py种入缺陷的文件steps-carry-real-diffsregex1第一个步骤必须携带真实的 Git 补丁文本而非散文式摘要subject-before-its-testregex2测试不得先于其被测模块tests/test_bucket.py不得出现在ratelimit/bucket.py之前这 8 个 grader 覆盖了四种判定机制构成对口述式成功的完整防线文件存在性file_exists杜绝产物只存在于叙述中的假阳性正则断言regex以确定性代码检查产物内容的结构性事实步骤顺序、真实补丁、无占位符、锚定文件工具调用追踪tool_used从执行轨迹确认内置渲染器真的被调用而不是 Agent 手工拼了一个相似页面LLM 语义评分llm由评审模型判断是否发现了真实缺陷、解释是否引用真实标识符这类无法用正则表达的质量问题。evals/README.md中的What Is Checked表也印证了这一分工渲染器调用看工具调用轨迹、输出存在且含数据看生成的 HTML、步骤顺序看序列化的步骤数组、锚定看序列化的评审对象、语义质量则由 LLM 评审器直接读取产物。五、确定性检查的工程细节顺序如何用正则表达artifact-written是 8 个 grader 中唯一一个纯文件存在性检查而其余 5 个正则 grader 的设计充分体现了如何用正则精确表达结构性事实是理解整个评估管线不可回避的背景。以权重最高的 definitions-before-wiring 为例它体现了三个关键设计决策决策一写成不应找到的违规而不是应找到的顺序。模式为b/app/middleware\.py[\s\S]*message:\s*[\s\S]*b/ratelimit/bucket\.py匹配结果为not_contains。即只要发现middleware 的路径后面隔着至少一个message:又出现 bucket 的路径就判定违规。这样写的原因在于步骤step而非文件才是基本单位——app/middleware.py导入TokenBucket若评审者先遇到 middleware 就得在脑中悬着一个未定义符号这正是技能要求定义先于消费者的动机。决策二用message:作为步骤边界。每个步骤对象都携带一个message且它出现在files与diff之前因此两个路径之间隔着message:意味着它们属于不同步骤。这样区分很重要技能允许把小文件合并进一个步骤而 git 在同一步骤内按路径顺序输出文件b/app/middleware.py排在b/ratelimit/bucket.py之前。一个朴素的bucket 在 middleware 之前包含式模式会误杀这种合法合并而本模式只在middleware 的步骤真正先于 bucket 的步骤时触发。边界标记选message:而非sha是因为 sha 只是运行方给步骤取的名字而message是页面渲染标题所必需的。决策三匹配b/前缀的 diff 头路径而非裸文件名。bucket.py自己的 diff 里包含from ratelimit.config import ...middleware 的 diff 里包含from ratelimit.bucket import ...——这些导入用的是点号路径无法满足反斜杠路径模式不会意外触发。其余正则 grader 同样各有关键约束steps-carry-real-diffs 的模式锚定在diff: …内部防止评审正文里的补丁文本满足检查且(?:(?!diff)[\s\S])*把匹配钉死在数组的第一个diff键上——因为惰性匹配[\s\S]*?会回溯到后面的步骤恰恰会放过第一步是编造、只有第二步才有真 diff的欺骗。no-placeholder-survives 匹配模板自身的占位符位点(?:title|h1)[A-Z_]*PLACEHOLDER与const [A-Z_] [A-Z_]_PLACEHOLDER;而非裸词PLACEHOLDER——因为裸词可能合法地出现在被评审的 diff 内容里。它锚定的是真实换行json.dumps会把内嵌值中的换行转义为\n两个字符因此产物中任何字面换行都来自模板自身结构而非 diff 内容。review-anchored-to-bucket 要求至少一条评审锚到ratelimit/bucket.py——种入缺陷的文件未钳制的令牌补给也是最有话可说的文件。锚点是否指向 diff 中的有效行由渲染器负责校验。subject-before-its-test 允许小测试紧挨其被测模块技能允许因此测试必须全部排在最后的严格版 grader 反而会误伤正确输出。六、fixture 如何支撑产物真实性可复现的仓库与被种入的缺陷artifact-written能成立还依赖一个可复现、无网络的 fixture 仓库。scaffold.sh的注释点明两个保持确定性的关键细节手写refs/remotes/origin/main与origin/HEADgit update-ref与git symbolic-ref使技能无需 remote 或网络即可发现默认分支种入缺陷固定在ratelimit/bucket.py的特定行注释明确警告编辑该文件会移动 case.yaml 中记录的行号。缺陷本体是_refill中的self._tokens elapsed * self._config.refill_per_second一行——补给从未被钳制到config.capacity因此空闲客户端会累积无界令牌之后可直接冲破限流。graders 锚定到这一行。fixture 构建的七文件功能分支形成清晰的依赖链ratelimit/config.pyRateLimitConfig数据类__post_init__校验容量与补给率为正→ratelimit/bucket.pyTokenBucket的consume/_refill→app/middleware.pyRateLimitMiddleware包装 dispatcherDEFAULT_CONFIG RateLimitConfig(capacity20, refill_per_second5.0)超出时返回 429→tests/test_bucket.py突发容量与非法配置两个测试。app/server.py在分支提交前被脚本改写注入RateLimitMiddleware包装。这个依赖顺序恰好是 case.yaml 中描述的无歧义依赖顺序config → bucket → middleware → tests使步骤顺序与评审锚点都能被确定性检查而无需人工评审。case.yaml中同时定义了预期结果expected_outcomewalkthrough.html存在、不含未替换占位符、定义先于消费者且测试最后、至少一条评审锚到未钳制补给。这正是artifact-written及其兄弟 grader 的组合目标。此外prompt.md还设计了一道防作弊门槛若.git缺失或git merge-base HEAD origin/main失败说明 fixture 未构建Agent 必须报告运行者需要--scaffold并停止——禁止自建仓库因为对编造变更的走查比没有走查更糟它拿到部分分数并掩盖真实问题。七、自动化测试与运行方式闸门如何被验证artifact-written及其体系不是纸面设计而是被多层自动化测试守护的。评估运行入口evals/README.mdCLAUDE_CODE_WALNUT_SPIRE1 claude plugin eval plugins/review-walkthrough \ --ablation none \ --scaffold \ --allow-tools Bash Write Edit \ --judge-model sonnet \ --threshold 1.0 \ --no-publish \ --report /tmp/review-walkthrough-report.html--scaffold是必须的运行器默认不执行作者提供的 fixture 脚本--threshold 1.0要求每个参与评分的 grader 都通过--no-publish保持报告本地化。allowed_tools授予文件读写、Bash、搜索与技能调用。grader 自测test_eval_graders.py该测试会真实构建 fixture调用scaffold.sh、渲染其完整补丁然后用JavaScript 的 regex 引擎逐一演练全部 5 个正则 grader。它既检查合法步骤编排能通过也构造每个 grader 对应的缺陷变体以及空产物/缺失产物验证其确实失败。测试开头还有两道守卫断言每个 regex grader 的 target 是walkthrough.html且 pattern 非空并断言发现的 grader 集合恰为预定义的 5 个名字——防止自测在没测到已上线的模式时依然通过。criteriaLLM 语义与renderer-used工具调用不在此列分别由评审模型与轨迹分析覆盖。渲染器单测与浏览器测试渲染器的 Python 测试与页面的node:test套件在make check下运行覆盖数据嵌入、diff 保真、行锚点与生成的评审命令不真正发布到 GitHub。tests/browser-check.mjs还会在真实 Chrome 中测试 HTML 净化、评论转换、导航与评论控件可用一个 Chromium 可执行文件作为参数在本地运行。排障指引若产物缺失可能意味着 scaffold 被省略或运行耗尽了 turn/时间预算。evals/README.md建议用--keep-temp检查sandbox/out/trace.jsonl的最后记录来区分两种失败。同时LLM 评审器拿到的是产物的有界视图fixture 增大时需在嵌入数据超过运行器 focus 限制前拆分。文档还诚实记录了一条环境性失败2026-09-14 的某次运行中 macOS 沙箱拒绝了对 fixture checkout 与临时目录的 shell 写入导致无法触达渲染器——这类环境故障不影响本地 Python/Node/Chrome 测试。八、实践要点把产物真实性闸门迁移到自己的评估管线结合artifact-written及其姊妹 grader 的整套设计可以提炼出可复用的评估工程原则真实落盘是第一条闸门。任何基于产物的评估都应先做file_exists检查且把它放在权重最高或至少双倍的位置——因为后续所有检查都以产物存在为前提一个口述式成功会同时污染所有下游判定。提示词要与闸门同向。prompt.md明确写读取walkthrough.html而非你的总结描述产物得零分把产物真实性从评分规则渗透到 Agent 的行为约束中。存在 ≠ 真实。文件存在之外还需要渲染器被调用工具轨迹、无占位符残留正则、携带真实补丁与捕获的原始补丁逐一比对来封堵存在但空洞与存在但编造的中间地带。正则表达结构事实要钉死边界。用步骤边界标记message:区分步骤用b/前缀 diff 头路径避免导入语句误匹配用锚定在字符串内部的模式防止评审正文满足检查用钉在第一个 diff 键防止回溯到后续步骤——这些细节共同决定了确定性检查的精确度。把机械检查从 LLM 评分中剥离。criteria的规则明确列出HTML 转义、数组对齐、锚点位置、步骤顺序、样式脚本一律不判——它们由代码和确定性检查处理放进 LLM 规则只会制造假阴性。LLM 只负责正则无法表达的语义是否发现真实缺陷、解释是否引用真实标识符。fixture 必须可复现且诚实。手写 remote refs 以离线运行把缺陷固定在已知行并防止脚手架脚本改动它并禁止 Agent 自建仓库——对编造变更的走查掩盖真实问题这正是artifact-written及其体系共同对抗的核心风险。结语artifact-written只有短短数行却浓缩了 Agent 评估中最重要的一条经验评分必须锚定在磁盘上的真实产物上而不是运行者对产物的叙述上。围绕这条闸门review-walkthrough 用文件存在性、正则断言、工具调用追踪与 LLM 语义评分四层机制构建了一个互相咬合的防御体系——占位符检查堵住空页面渲染器比对堵住编造 diff锚点校验堵住无依据的评论语义评分堵住没看懂缺陷。理解这套设计不仅有助于读透rate-limit-walkthrough案例也能为任何需要验证 Agent 真实交付能力的评估管线提供一份可以直接借鉴的工程蓝本。赞分享AI 技能AI 插件应用安全网络安全AI 评测【免费下载链接】skillsTrail of Bits Claude Code skills for security research, vulnerability detection, and audit workflows项目地址https://gitcode.com/gh_mirrors/skills8/skills点击查看免费下载相关推荐code-improver 评估体系中的 ledger.json 持久化门禁从 file_exists 打分器解析依赖保障机制的设计code improver 评估体系中的 ledger.json 持久化门禁从 file_exists 打分器解析依赖保障机制的设计 导读 本文以 codeAI 技能AI 插件应用安全网络安全AI 评测精读 Node.js v0.7.9 发布说明0.7 不稳定系列中的核心模块演进与 nodejs.org 发布公告的呈现机制精读 Node.js v0.7.9 发布说明0.7 不稳定系列中的核心模块演进与 nodejs.org 发布公告的呈现机制 本文以 nodejs.org 官方AI 技能AI 插件应用安全网络安全AI 评测GitNexus CI 评审蜂群守门人ci-critic-lens 评审稿质检闸门的设计与落地GitNexus CI 评审蜂群守门人ci critic lens 评审稿质检闸门的设计与落地 导读 ci critic lens 是 GitNexus gi开发者工具知识图谱静态分析MCP 服务人工智能上一篇N_m3u8DL-CLI-SimpleG免费图形化M3U8视频下载工具终极指南下一篇魔兽争霸兼容性终极解决方案WarcraftHelper让经典游戏在现代电脑完美运行创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 产物必须真实落盘：review-walkthrough 评估体系中 file_exists 判定闸门的设计与实践
AI 技能AI 插件应用安全网络安全AI 评测【免费下载链接】skillsTrail of Bits Claude Code skills for security research, vulnerability detection, and audit workflows项目地址https://gitcode.com/gh_mirrors/skills8/skills点击查看免费下载导读在评估一个 AI Agent 是否真正完成代码评审任务时最致命的假阳性不是评得不好而是根本没产出产物却把产物描述得头头是道。本文聚焦 Trail of Bits 的 review-walkthrough 插件中rate-limit-walkthrough评估案例的 artifact-written 判定规则剖析这条file_exists闸门如何以双倍权重守住整个评估体系的底线并展示它与渲染器校验、其余 7 个 grader、fixture 脚手架和自动化测试之间的完整协作关系。读完本文你将掌握产物真实性闸门在 Agent 评估管线中的设计思路以及如何用文件存在性检查、正则断言、工具调用追踪和 LLM 语义评分四层手段组合防御口述式成功。一、artifact-written判定规则一句话的闸门全体系的底线artifact-written.md是整个rate-limit-walkthrough评估案例中最短、却权重最高的判定规则之一。它的完整内容如下--- type: file_exists weight: 2 path: walkthrough.html exists: true --- The artifact has to be on disk. This is the guard against the failure this repo has already shipped once: a run that describes the deliverable convincingly enough to satisfy a transcript-reading judge without ever producing it. Every other artifact grader is meaningless if this one fails, so it carries double weight.逐字段拆解这条规则type: file_exists声明该 grader 的类型是文件存在性检查即判定器会去目标路径上确认产物是否真实存在而非依赖任何语义理解。weight: 2权重为 2。结合 evals/README.md 中--threshold 1.0要求每个参与评分的 grader 都必须通过的说明权重意味着在通过/未通过的门槛计算中占双倍比例。path: walkthrough.html检查的目标文件即本次评估要求 Agent 产出的交互式 HTML 评审走查页面。exists: true期望的判定结果是文件存在。若文件缺失该 grader 直接判负。该规则的关键论断有两条直接构成了本文要展开的核心理念产物必须真实落盘一个只描述交付物而不实际生成它的运行无论描述得多有说服力都不能算作完成任务。仓库明确记录了这一失败模式曾经真实发生the failure this repo has already shipped once——在评估历史上曾出现过一次运行通过详尽的口头描述骗过了阅读转录文本的评审却从未产出真实文件的情况。双倍权重的理由该闸门是所有产物类 grader 的前提。如果walkthrough.html不存在那么针对它的正则检查、LLM 语义评审、锚点校验统统没有意义因此它carries double weight。从这一定义出发我们可以在仓库中找到完整的工程化支撑为什么产物必须是 HTML、如何保证它是被真实渲染出来的、以及其余判定如何分工。二、为什么产物是walkthrough.html技能契约与渲染链artifact-written检查的文件并非随意指定而是由技能契约与渲染链共同定义。在 review-walkthrough 技能文档 中技能被设计为生成自包含的 HTML 走查页面将分支的最终 diff 拆分为逻辑步骤并附带解释与关键评审结论。对于无头headless运行场景评估 prompt 明确要求将完成的走查写入工作目录下的walkthrough.html不要运行open无浏览器环境仓库没有 GitHub remote 与打开的 PR因此不调用ghpr_meta视为缺失继续执行本运行是通过读取walkthrough.html来检查的而不是阅读你的总结因此对走查内容的描述得零分。最后一条正是artifact-written的设计意图在 prompt 层面的回响评分依据是磁盘上的产物而不是 Agent 的自我汇报。产物的数据契约由技能文档中的字段表定义title评审标题、steps步骤数组含sha、message、files、diff、explanations每步一段 HTML 解释、reviews每步的发现数组含severity/title/body锚定发现还带file/line/side与可选的end_line、pr_metaGitHub PR 元数据或null。三个数组长度必须相等且一一对应。真正把 JSON 数据变成walkthrough.html的是插件自带的渲染器 render_walkthrough.py。调用方式在技能文档中给出uv run --no-project {baseDir}/scripts/render_walkthrough.py \ --input /tmp/data.json \ --diff /tmp/captured.patch \ --output /tmp/walkthrough.html渲染器不是简单的模板替换——它在渲染前执行多层校验详见第三节并且会拒绝用自写的页面绕过它见renderer-usedgrader。template.html中则预留了五个占位符TITLE_PLACEHOLDER出现两次位于title与h1、STEPS_PLACEHOLDER、EXPLANATIONS_PLACEHOLDER、REVIEWS_PLACEHOLDER、PR_META_PLACEHOLDER各一次位于 template.html 的脚本区。渲染器会校验每个占位符的出现次数恰好符合预期TITLE_PLACEHOLDER两次其余各一次再一次性完成替换防止占位符文本被递归替换。三、渲染器产物真实性在落盘之前的最后防线artifact-written保证文件存在但一个存在却内容空洞、甚至仍是模板占位符的 HTML 同样没有价值。因此render_walkthrough.py 在写出文件前执行了五类校验1. 结构完整性校验normalize_data要求输入必须是 JSON 对象title为非空字符串steps为非空数组且explanations、reviews与步骤数严格一一对应。2. 补丁真实性校验split_diff要求步骤的diff值以diff --git开头patch_paths通过git apply --numstat -z用 Git 自身的引号规则解析路径确保捕获的补丁能被 Git 解析最关键的是每个步骤中的每个 diff 块必须原样来自捕获的完整补丁any(block not in originals ...)即拒绝并且Counter(seen) ! Counter(blocks)时拒绝——即每个被捕获的文件 diff 必须恰好出现在一个步骤中不得缺失、不得重复。3. 锚点校验review_anchor每个锚定发现必须指向本步骤内的文件line/end_line必须构成正整数有序区间且该区间必须落在同一 hunk 的同一侧LEFT 或 RIGHT上若区间在两侧都存在歧义则要求显式指定side。这解释了技能文档中对新增或新文件上下文用RIGHT对删除或旧文件上下文用LEFT的约定。4. PR 元数据校验normalize_prowner/repo必须匹配 GitHub 仓库名校验pr_number必须为正整数head_sha必须是完整的 40 位十六进制 SHA。5. 模板占位符替换render用json.dumps(...).replace(, r\u003c)安全嵌入数据并校验每个占位符的期望出现次数最后单趟替换re.sub一次完成防止占位符文本被递归替换。一个值得注意的细节渲染器用read_text读取补丁时特意保留 CRLF、不做通用换行转换因为换行转换会改变证据注释原话universal-newline conversion changes the evidence。这种对证据保真的执着正是整个产物真实性工程的底色。四、双倍权重的结构含义它保护了其余 7 个 graderrate-limit-walkthrough案例共有 8 个 graderartifact-written是唯一一个type: file_exists的闸门。其余 7 个全部以walkthrough.html为目标因此文件存在是它们共同的前置条件。下表展示了完整的分工与权重grader类型权重检查内容artifact-writtenfile_exists2walkthrough.html必须存在于磁盘definitions-before-wiringregex3定义必须先于消费者app/middleware.py的步骤不得出现在ratelimit/bucket.py之前criteriallm3评审确实发现真实缺陷且每条解释引用步骤 diff 中的真实标识符no-placeholder-survivesregex2产物中不得残留STEPS_PLACEHOLDER等模板占位符renderer-usedtool_used2必须调用内置渲染器render_walkthrough.py不得用手写模板替换替代review-anchored-to-bucketregex2至少一条评审发现锚定到ratelimit/bucket.py种入缺陷的文件steps-carry-real-diffsregex1第一个步骤必须携带真实的 Git 补丁文本而非散文式摘要subject-before-its-testregex2测试不得先于其被测模块tests/test_bucket.py不得出现在ratelimit/bucket.py之前这 8 个 grader 覆盖了四种判定机制构成对口述式成功的完整防线文件存在性file_exists杜绝产物只存在于叙述中的假阳性正则断言regex以确定性代码检查产物内容的结构性事实步骤顺序、真实补丁、无占位符、锚定文件工具调用追踪tool_used从执行轨迹确认内置渲染器真的被调用而不是 Agent 手工拼了一个相似页面LLM 语义评分llm由评审模型判断是否发现了真实缺陷、解释是否引用真实标识符这类无法用正则表达的质量问题。evals/README.md中的What Is Checked表也印证了这一分工渲染器调用看工具调用轨迹、输出存在且含数据看生成的 HTML、步骤顺序看序列化的步骤数组、锚定看序列化的评审对象、语义质量则由 LLM 评审器直接读取产物。五、确定性检查的工程细节顺序如何用正则表达artifact-written是 8 个 grader 中唯一一个纯文件存在性检查而其余 5 个正则 grader 的设计充分体现了如何用正则精确表达结构性事实是理解整个评估管线不可回避的背景。以权重最高的 definitions-before-wiring 为例它体现了三个关键设计决策决策一写成不应找到的违规而不是应找到的顺序。模式为b/app/middleware\.py[\s\S]*message:\s*[\s\S]*b/ratelimit/bucket\.py匹配结果为not_contains。即只要发现middleware 的路径后面隔着至少一个message:又出现 bucket 的路径就判定违规。这样写的原因在于步骤step而非文件才是基本单位——app/middleware.py导入TokenBucket若评审者先遇到 middleware 就得在脑中悬着一个未定义符号这正是技能要求定义先于消费者的动机。决策二用message:作为步骤边界。每个步骤对象都携带一个message且它出现在files与diff之前因此两个路径之间隔着message:意味着它们属于不同步骤。这样区分很重要技能允许把小文件合并进一个步骤而 git 在同一步骤内按路径顺序输出文件b/app/middleware.py排在b/ratelimit/bucket.py之前。一个朴素的bucket 在 middleware 之前包含式模式会误杀这种合法合并而本模式只在middleware 的步骤真正先于 bucket 的步骤时触发。边界标记选message:而非sha是因为 sha 只是运行方给步骤取的名字而message是页面渲染标题所必需的。决策三匹配b/前缀的 diff 头路径而非裸文件名。bucket.py自己的 diff 里包含from ratelimit.config import ...middleware 的 diff 里包含from ratelimit.bucket import ...——这些导入用的是点号路径无法满足反斜杠路径模式不会意外触发。其余正则 grader 同样各有关键约束steps-carry-real-diffs 的模式锚定在diff: …内部防止评审正文里的补丁文本满足检查且(?:(?!diff)[\s\S])*把匹配钉死在数组的第一个diff键上——因为惰性匹配[\s\S]*?会回溯到后面的步骤恰恰会放过第一步是编造、只有第二步才有真 diff的欺骗。no-placeholder-survives 匹配模板自身的占位符位点(?:title|h1)[A-Z_]*PLACEHOLDER与const [A-Z_] [A-Z_]_PLACEHOLDER;而非裸词PLACEHOLDER——因为裸词可能合法地出现在被评审的 diff 内容里。它锚定的是真实换行json.dumps会把内嵌值中的换行转义为\n两个字符因此产物中任何字面换行都来自模板自身结构而非 diff 内容。review-anchored-to-bucket 要求至少一条评审锚到ratelimit/bucket.py——种入缺陷的文件未钳制的令牌补给也是最有话可说的文件。锚点是否指向 diff 中的有效行由渲染器负责校验。subject-before-its-test 允许小测试紧挨其被测模块技能允许因此测试必须全部排在最后的严格版 grader 反而会误伤正确输出。六、fixture 如何支撑产物真实性可复现的仓库与被种入的缺陷artifact-written能成立还依赖一个可复现、无网络的 fixture 仓库。scaffold.sh的注释点明两个保持确定性的关键细节手写refs/remotes/origin/main与origin/HEADgit update-ref与git symbolic-ref使技能无需 remote 或网络即可发现默认分支种入缺陷固定在ratelimit/bucket.py的特定行注释明确警告编辑该文件会移动 case.yaml 中记录的行号。缺陷本体是_refill中的self._tokens elapsed * self._config.refill_per_second一行——补给从未被钳制到config.capacity因此空闲客户端会累积无界令牌之后可直接冲破限流。graders 锚定到这一行。fixture 构建的七文件功能分支形成清晰的依赖链ratelimit/config.pyRateLimitConfig数据类__post_init__校验容量与补给率为正→ratelimit/bucket.pyTokenBucket的consume/_refill→app/middleware.pyRateLimitMiddleware包装 dispatcherDEFAULT_CONFIG RateLimitConfig(capacity20, refill_per_second5.0)超出时返回 429→tests/test_bucket.py突发容量与非法配置两个测试。app/server.py在分支提交前被脚本改写注入RateLimitMiddleware包装。这个依赖顺序恰好是 case.yaml 中描述的无歧义依赖顺序config → bucket → middleware → tests使步骤顺序与评审锚点都能被确定性检查而无需人工评审。case.yaml中同时定义了预期结果expected_outcomewalkthrough.html存在、不含未替换占位符、定义先于消费者且测试最后、至少一条评审锚到未钳制补给。这正是artifact-written及其兄弟 grader 的组合目标。此外prompt.md还设计了一道防作弊门槛若.git缺失或git merge-base HEAD origin/main失败说明 fixture 未构建Agent 必须报告运行者需要--scaffold并停止——禁止自建仓库因为对编造变更的走查比没有走查更糟它拿到部分分数并掩盖真实问题。七、自动化测试与运行方式闸门如何被验证artifact-written及其体系不是纸面设计而是被多层自动化测试守护的。评估运行入口evals/README.mdCLAUDE_CODE_WALNUT_SPIRE1 claude plugin eval plugins/review-walkthrough \ --ablation none \ --scaffold \ --allow-tools Bash Write Edit \ --judge-model sonnet \ --threshold 1.0 \ --no-publish \ --report /tmp/review-walkthrough-report.html--scaffold是必须的运行器默认不执行作者提供的 fixture 脚本--threshold 1.0要求每个参与评分的 grader 都通过--no-publish保持报告本地化。allowed_tools授予文件读写、Bash、搜索与技能调用。grader 自测test_eval_graders.py该测试会真实构建 fixture调用scaffold.sh、渲染其完整补丁然后用JavaScript 的 regex 引擎逐一演练全部 5 个正则 grader。它既检查合法步骤编排能通过也构造每个 grader 对应的缺陷变体以及空产物/缺失产物验证其确实失败。测试开头还有两道守卫断言每个 regex grader 的 target 是walkthrough.html且 pattern 非空并断言发现的 grader 集合恰为预定义的 5 个名字——防止自测在没测到已上线的模式时依然通过。criteriaLLM 语义与renderer-used工具调用不在此列分别由评审模型与轨迹分析覆盖。渲染器单测与浏览器测试渲染器的 Python 测试与页面的node:test套件在make check下运行覆盖数据嵌入、diff 保真、行锚点与生成的评审命令不真正发布到 GitHub。tests/browser-check.mjs还会在真实 Chrome 中测试 HTML 净化、评论转换、导航与评论控件可用一个 Chromium 可执行文件作为参数在本地运行。排障指引若产物缺失可能意味着 scaffold 被省略或运行耗尽了 turn/时间预算。evals/README.md建议用--keep-temp检查sandbox/out/trace.jsonl的最后记录来区分两种失败。同时LLM 评审器拿到的是产物的有界视图fixture 增大时需在嵌入数据超过运行器 focus 限制前拆分。文档还诚实记录了一条环境性失败2026-09-14 的某次运行中 macOS 沙箱拒绝了对 fixture checkout 与临时目录的 shell 写入导致无法触达渲染器——这类环境故障不影响本地 Python/Node/Chrome 测试。八、实践要点把产物真实性闸门迁移到自己的评估管线结合artifact-written及其姊妹 grader 的整套设计可以提炼出可复用的评估工程原则真实落盘是第一条闸门。任何基于产物的评估都应先做file_exists检查且把它放在权重最高或至少双倍的位置——因为后续所有检查都以产物存在为前提一个口述式成功会同时污染所有下游判定。提示词要与闸门同向。prompt.md明确写读取walkthrough.html而非你的总结描述产物得零分把产物真实性从评分规则渗透到 Agent 的行为约束中。存在 ≠ 真实。文件存在之外还需要渲染器被调用工具轨迹、无占位符残留正则、携带真实补丁与捕获的原始补丁逐一比对来封堵存在但空洞与存在但编造的中间地带。正则表达结构事实要钉死边界。用步骤边界标记message:区分步骤用b/前缀 diff 头路径避免导入语句误匹配用锚定在字符串内部的模式防止评审正文满足检查用钉在第一个 diff 键防止回溯到后续步骤——这些细节共同决定了确定性检查的精确度。把机械检查从 LLM 评分中剥离。criteria的规则明确列出HTML 转义、数组对齐、锚点位置、步骤顺序、样式脚本一律不判——它们由代码和确定性检查处理放进 LLM 规则只会制造假阴性。LLM 只负责正则无法表达的语义是否发现真实缺陷、解释是否引用真实标识符。fixture 必须可复现且诚实。手写 remote refs 以离线运行把缺陷固定在已知行并防止脚手架脚本改动它并禁止 Agent 自建仓库——对编造变更的走查掩盖真实问题这正是artifact-written及其体系共同对抗的核心风险。结语artifact-written只有短短数行却浓缩了 Agent 评估中最重要的一条经验评分必须锚定在磁盘上的真实产物上而不是运行者对产物的叙述上。围绕这条闸门review-walkthrough 用文件存在性、正则断言、工具调用追踪与 LLM 语义评分四层机制构建了一个互相咬合的防御体系——占位符检查堵住空页面渲染器比对堵住编造 diff锚点校验堵住无依据的评论语义评分堵住没看懂缺陷。理解这套设计不仅有助于读透rate-limit-walkthrough案例也能为任何需要验证 Agent 真实交付能力的评估管线提供一份可以直接借鉴的工程蓝本。赞分享AI 技能AI 插件应用安全网络安全AI 评测【免费下载链接】skillsTrail of Bits Claude Code skills for security research, vulnerability detection, and audit workflows项目地址https://gitcode.com/gh_mirrors/skills8/skills点击查看免费下载相关推荐code-improver 评估体系中的 ledger.json 持久化门禁从 file_exists 打分器解析依赖保障机制的设计code improver 评估体系中的 ledger.json 持久化门禁从 file_exists 打分器解析依赖保障机制的设计 导读 本文以 codeAI 技能AI 插件应用安全网络安全AI 评测精读 Node.js v0.7.9 发布说明0.7 不稳定系列中的核心模块演进与 nodejs.org 发布公告的呈现机制精读 Node.js v0.7.9 发布说明0.7 不稳定系列中的核心模块演进与 nodejs.org 发布公告的呈现机制 本文以 nodejs.org 官方AI 技能AI 插件应用安全网络安全AI 评测GitNexus CI 评审蜂群守门人ci-critic-lens 评审稿质检闸门的设计与落地GitNexus CI 评审蜂群守门人ci critic lens 评审稿质检闸门的设计与落地 导读 ci critic lens 是 GitNexus gi开发者工具知识图谱静态分析MCP 服务人工智能上一篇N_m3u8DL-CLI-SimpleG免费图形化M3U8视频下载工具终极指南下一篇魔兽争霸兼容性终极解决方案WarcraftHelper让经典游戏在现代电脑完美运行创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考