4-report-assembler 报告组装器完全指南：zeroize-audit 审计结果汇聚、置信门控与双模式报告生成-北京尧图网络

AI 技能AI 插件应用安全网络安全AI 评测【免费下载链接】skillsTrail of Bits Claude Code skills for security research, vulnerability detection, and audit workflows项目地址https://gitcode.com/gh_mirrors/skills8/skills点击查看免费下载4-report-assembler是零化审计技能zeroize-audit流水线中的汇聚与收口环节它读取上游所有 Agent源码分析、编译器分析、MCP 语义解析、Preflight 元数据产生的发现文件依次执行超驰替换supersession置信门控confidence gatingID 规范化三层处理最终输出供下游 Agent 消费的findings.json与面向审计人员阅读的final-report.md。本文以 4-report-assembler 规范文档为骨架结合 SKILL.md 中的置信门控权威规则、机械执行器源码、输出 JSON Schema 与报告模板进行纵深讲解。读完本文你将掌握该 Agent 的双模式interim/final调用契约、七个输入源的收集规则、supersession 与置信门控的精确判定标准、ZA-NNNNID 的排序与映射规则、PoC 结果合并的六种分支处理以及final-report.md九个必备章节的完整渲染要求。一、角色定位为什么需要一个装配工Agentzeroize-audit 流水线采用多 Agent 并行架构详见 SKILL.md 的 Agent Architecture 章节上游发现分布在不同的命名空间与目录中2-source-analyzer产出source-analysis/C/C 敏感对象SO-NNNN与源码发现F-SRC-NNNN2b-rust-source-analyzer产出 Rust 命名空间的F-RUST-SRC-NNNN与SO-5NNN3-tu-compiler-analyzer每个翻译单元TU一个实例各自产出compiler-analysis/{tu_hash}/下的 IR/ASM/CFG/SIR 发现3b-rust-compiler-analyzer以 crate 为单位产出rust-compiler-analysis/下的 MIR/IR/ASM 发现。由于并行执行这些发现使用各自独立的 ID 前缀彼此之间还存在着相互取代例如 CFG 主导性分析可以取代源码启发式的路径分析的关系。因此需要一个装配工Agent 在两条流水线检查点Phase 3 中间态与 Phase 6 终态统一收口——这正是 4-report-assembler 的职责。该 Agent 在 SKILL.md 的 Agent Architecture 表中被明确描述为Collect findings from all agents, apply confidence gates; merge PoC results and produce final reportPhase 3 interim Phase 6 final。其进程由 orchestrator 通过Tasksubagent_type: zeroize-audit:4-report-assembler在 phase-3-interim-report.md 与 phase-6-final-report.md 两个工作流中分别派发允许的工具集为Read, Grep, Glob, Write, Bash。二、输入参数来自 orchestrator 的 8 个值Agent 从 orchestrator 接收如下参数对应规范文档 Input 表参数说明workdir运行工作目录如/tmp/zeroize-audit-{run_id}/所有中间产物存放于此config_path合并后配置文件的路径{workdir}/merged-config.yaml由0-preflight在 Phase 0 写入mcp_available布尔值——MCPSerena 语义解析是否成功使用来自 orchestrator 状态路由mcp_required_for_advanced布尔值——控制高级发现是否依赖 MCP 可用性baseDir插件基础目录用于定位工具脚本与 Schema如apply_confidence_gates.py、output.jsonmodeinterim或final——决定执行哪些步骤、产出哪些输出poc_resultspoc_final_results.json的路径仅final模式传入对比两个工作流文件的派发参数可确认双模式的差异phase-3-interim-report.md 仅传 6 个参数modeinterim无poc_results而 phase-6-final-report.md 额外传入poc_results: {workdir}/poc/poc_final_results.jsonmodefinal。模式分支Mode Branchinginterim模式执行 Step 1–5仅写出findings.json不产出final-report.md。这是 PoC 生成前的中间快照供5-poc-generator与6-test-generator读取final模式先读取已存在的findings.json执行 Step 5b合并 PoC 结果再产出更新后的findings.json与final-report.mdStep 6。phase-3-interim-report.md 的收尾检查还给出一个重要分支若 interimfindings.json的 findings 数组为空则直接跳过 Phase 4/5 跳到 Phase 6 产出空报告——这与 task.md 的 Early Termination 规则一致空结果也必须走完报告流程。三、Step 0 — 加载合并配置Agent 首先读取config_path指向的{workdir}/merged-config.yaml从中获得三个关键参数族置信门控阈值决定 2 独立信号 →confirmed、1 信号 →likely、0 强信号 →needs_review的判定严重度规则与preflight.json传入的enable_asm、enable_semantic_ir、enable_cfg等开关联动决定哪些高级发现类别可能产出报告设置优化级别、MCP 模式、PoC 验证状态等最终会渲染进报告的 Header 与 Executive Summary。该合并配置由0-preflight在 Step 3 中以 default.yaml 为基础做键级覆盖合并用户配置覆盖同名键未设置的键回退到默认值。四、Step 1 — 收集全部发现七类输入源Agent 从工作目录读取以下七类文件并合并为一个统一列表规范文档 Step 1源码发现{workdir}/source-analysis/source-findings.json编译器发现C/C遍历{workdir}/compiler-analysis/*/每个子目录读取ir-findings.json、asm-findings.json、cfg-findings.json、semantic-ir.json编译器发现Rust从{workdir}/rust-compiler-analysis/读取mir-findings.json、ir-findings.json、asm-findings.json、cfg-findings.json、semantic-ir.json覆盖缺口coverage gaps{workdir}/rust-compiler-analysis/coverage-gaps.json若存在——记录 crate 实际使用但没有脚本审计的 Section D 模式。这些不算发现、不进置信门控只用于填充报告中的 Analysis Coverage 章节防止干净报告被误读为无事发生敏感对象清单{workdir}/source-analysis/sensitive-objects.jsonMCP 状态{workdir}/mcp-evidence/status.json若存在Preflight 元数据{workdir}/preflight.json提供run_id、repo、compile_db、opt_levels等报告头部信息见 0-preflight 的输出格式。容错要求缺失目录必须优雅处理——某个 TU 的compiler-analysis/tu_hash/或整个rust-compiler-analysis/可能因对应 Agent 失败而不存在此时应继续基于可用发现产出报告并在 Analysis Coverage 章节标注缺失的 TU。task.md 的错误处理表明确规定单个 TU compiler-analyzer 失败→继续其余 TU、Rust compiler analyzer 失败→记录并继续报告装配器自行处理缺失目录。五、Step 2 — 应用 Supersessions发现取代读取两份 supersession 文件每个 C/C compiler-analysis 子目录{workdir}/compiler-analysis/*/superseded-findings.jsonRust 编译器分析{workdir}/rust-compiler-analysis/superseded-findings.json。对每条超驰记录执行规范文档 Step 2移除被取代的发现例如源码启发式的F-SRC-0005NOT_ON_ALL_PATHS被取代保留取代者例如 CFG 主导性分析产出的F-CFG-a1b2-0003NOT_DOMINATING_EXITS或MISSING_ON_ERROR_PATH在notes.md中记录超驰关系。这一机制源于 2-source-analyzer 的 Step 4 注释源码分析对路径覆盖的检查是启发式的heuristic而 CFG 分析3-tu-compiler-analyzer的 Step 5计算支配节点产出的是确定性结论因此 CFG 发现可取代源码启发式发现。报告模板 Superseded Findings 章节中的示例表格F-SRC-0005 (NOT_ON_ALL_PATHS)→F-CFG-a1b2-0003 (NOT_DOMINATING_EXITS)理由是CFG dominance analysis provides definitive result正是该机制的报告侧体现。六、Step 3 — 应用置信门控判定标准与机械执行器这是整个装配流程中最关键的一步。规范文档给出了四组规则并明确指出权威版本在 SKILL.md6.1 证据阈值Signal 数量一条发现需要2 个以上独立信号才能标记为confirmed只有 1 个信号标记为likely0 个强信号仅名称模式命中标记为needs_review。SKILL.md 列出的信号来源包括名称模式命中、类型提示命中、显式注解、IR 证据、ASM 证据、MCP 交叉引用、CFG 证据、PoC 验证。6.2 硬性证据要求不可协商发现必需证据OPTIMIZED_AWAY_ZEROIZEIR diff——证明 wipe 在 O0 存在、在 O1 或 O2 消失。绝不允许仅凭源码产出STACK_RETENTION汇编摘录——证明ret时栈上仍残留机密字节REGISTER_SPILL汇编摘录——证明存在 spill 指令对应 3-tu-compiler-analyzer 的流程IR 发现必须基于diff_ir.sh对 O0/O1/O2.ll的 diff汇编发现必须基于emit_asm.shanalyze_asm.sh的输出。6.3 MCP 不可用降级当mcp_availablefalse且mcp_required_for_advancedtrue时以下三类高级发现降级为needs_review除非存在 2 个非 MCP 信号SECRET_COPYMISSING_ON_ERROR_PATHNOT_DOMINATING_EXITS6.4 Rationalization 覆盖尝试若出现以编译器不会优化掉这是热路径memset 就够等理由SKILL.md 的 Rationalizations to Reject 清单试图覆盖发现的尝试必须保留该发现并在证据中记录覆盖尝试。6.5 机械执行器apply_confidence_gates.py规范文档建议可选调用机械执行器以强制执行门控逻辑uv run --no-project {baseDir}/tools/mcp/apply_confidence_gates.py \ --findings raw_findings_json \ --mcp-available mcp_available \ --mcp-required-for-advanced mcp_required_for_advanced阅读执行器源码可看到其实现与上述规则的精确对应关系L16-L20 定义ADVANCED_MCP_CATEGORIES {SECRET_COPY, MISSING_ON_ERROR_PATH, NOT_DOMINATING_EXITS}L22-L25 定义ASM_REQUIRED_CATEGORIES {STACK_RETENTION, REGISTER_SPILL}_has_compiler_evidenceL28-L32检查compiler_evidence对象中的o0/o2/diff_summary字段是否非空用于判定OPTIMIZED_AWAY_ZEROIZE是否缺少 IR 证据_has_markerL35-L36在证据文本中检索asm标记用于判定汇编类发现是否缺少汇编证据三类降级在apply_gatesL39-L74中统一施加每项降级都会在evidence字段追加形如[gated: missing assembly evidence]的标记。注意 CLI 参数名与规范文档中--mcp-required-for-advanced略有差异脚本实际使用--require-mcp-for-advanced且脚本读写的是符合output.json的完整报告对象--input/--out而非独立 findings 列表在以 Agent 方式执行时以 Agent 判定为主脚本作为一致性校验手段。七、Step 4 — 规范化 IDZA-NNNN 命名空间所有存活发现被赋予最终 IDZA-NNNN顺序编号、零填充 4 位并将命名空间 ID → 最终 ID的映射写入id-mapping.json如{F-SRC-0001: ZA-0001, F-IR-a1b2-0001: ZA-0002, ...}。排序规则决定 ZA 编号的顺序依规范文档 Step 4 为C/C 源码发现按F-SRC-NNNN顺序Rust 源码发现按F-RUST-SRC-NNNN顺序C/C 编译器发现按 TU 分组先按 TU hash 排序组内再按发现类型 IR → ASM → CFG → SIRRust 编译器发现最后按 MIR → IR → ASM 类型排序。该ZA-NNNN命名空间是全流水线的最终 ID下游5-poc-generator据此生成poc_za_0001_*.c之类的 PoC 文件名6-test-generator据此生成测试 harness。八、Step 5 — 产出结构化 findings.jsonfindings.json是供下游 Agent5-poc-generator、6-test-generator消费的机器可读产物其结构与 schemas/output.json 严格匹配。顶层结构{ run_id: from preflight.json, timestamp: ISO-8601, repo: path, findings: [], summary: { total: 0, by_severity: {}, by_category: {}, by_confidence: {} } }每个 finding 对象包含的字段规范文档 Step 5 字段表字段内容idZA-NNNNcategory发现类别枚举11 种见 output.json 的 enumseverityhigh或mediumconfidenceconfirmed、likely或needs_reviewlocation{file, line}object{name, type, size_bytes}evidence证据对象数组{source, detail}evidence_source标签source、mcp、ir、asm、cfgcompiler_evidenceIR/ASM 证据细节如适用含opt_levels、o0–o3、diff_summaryfix推荐的修复方案pocPoC 对象interim 模式下为validated: false, validation_result: pending对照 output.json 的 Finding 定义可确认category有 11 个枚举值、severity枚举为low/medium/high/critical、confidence枚举为confirmed/likely/needs_review、poc对象要求file、makefile_target、compile_opt、requires_manual_adjustment、validated、validation_result六个必填字段其中validation_result枚举为exploitable/not_exploitable/compile_failure/no_poc/pending。写出前的交叉引用校验规范文档 Step 5 末尾每个related_objects条目必须存在于sensitive-objects.json若引用缺失保留该发现但在notes.md中追加警告并在 evidence 中附加说明如[assembler] related object SO-5xxx missing in sensitive-objects.json。interim 模式到此为止——不得产出final-report.md。九、Step 5b — 合并 PoC 验证与校验结果仅 final 模式Agent 读取poc_results即poc_final_results.json。该文件由 orchestrator 在 Phase 5 的 Step 5d 合并产出同时包含两类信息运行时验证结果能否编译/运行、退出码与语义校验结果PoC 是否真正证明了其声称的发现。每条记录按finding_id匹配发现并更新其poc对象六种分支如下规范文档 Step 5b 映射表PoC 结果发现的更新exit_code0、verifiedtrue可利用且已校验poc.validatedtrue、poc.verifiedtrue、poc.validation_resultexploitable追加证据PoC confirmed: secret persists after operation (exit code 0). Verification passed.计入置信信号可将likely升级为confirmedexit_code1、verifiedtrue不可利用且已校验poc.validatedtrue、poc.verifiedtrue、poc.validation_resultnot_exploitableseverity 降级为low仅信息性追加证据PoC disproved: secret was wiped (exit code 1). Verification passed.verifiedfalse用户接受poc.validatedtrue、poc.verifiedfalse沿用 PoC 原始validation_result追加证据PoC verification failed but user accepted result. Checks: {failed checks}作为弱于已验证 PoC 的置信信号verifiedfalse用户拒绝rejectedpoc.validatedfalse、poc.verifiedfalse、poc.validation_resultrejected追加证据PoC verification failed and user rejected result. Checks: {failed checks}置信度不变编译失败poc.validatedfalse、poc.validation_resultcompile_failure追加证据PoC compilation failed置信度不变未生成 PoCpoc.validatedfalse、poc.validation_resultno_poc追加证据No PoC generated for this finding置信度不变合并完成后计算顶层 summary 中的poc_validation_summary{ total_findings: 0, pocs_generated: 0, pocs_validated: 0, pocs_verified: 0, exploitable_confirmed: 0, not_exploitable: 0, rejected: 0, compile_failures: 0, no_poc_generated: 0, verification_failures: 0 }对照 output.json 的poc_validation_summary定义机器消费侧至少要求total_findings、pocs_generated、pocs_validated、exploitable_confirmed、not_exploitable、compile_failures、no_poc_generated七个必填键additionalProperties: falseAgent 侧产出的 10 键版本更加完整。这里需要理解PoC 验证作为证据信号在 SKILL.md 置信门控中的定位退出码 0可利用且已验证是强信号可将likely升级为confirmed退出码 1不可利用且已验证则降级严重度为low但保留在报告中——这正是区分误报的发现与信息性提示的关键机制。十、Step 6 — 产出 final-report.md九个必备章节final-report.md是面向人类读者的主输出使用{baseDir}/prompts/report_template.md作为结构指导模板文件 report_template.md 给出了完整的骨架与示例。报告必须自包含且全面包含以下章节10.1 Header头部报告标题# Zeroize Audit Report运行元数据run_id、时间戳、仓库路径、compile_db 路径配置摘要opt_levels、mcp_mode、启用的分析asm、semantic_ir、cfg、runtime_tests、PoC 验证状态。模板中以设置表格呈现Optimization levels / MCP mode / MCP available / Assembly analysis / Semantic IR analysis / CFG analysis / Runtime tests / PoC validation。10.2 Executive Summary执行摘要总发现数按严重度high/medium/low的表格按置信度confirmed/likely/needs_review的表格按类别每种发现类型计数的表格MCP 可用性状态及其对发现的影响PoC 验证汇总计数。10.3 Sensitive Objects Inventory敏感对象清单所有敏感对象的表格ID、名称、类型、file:line、置信度、命中的启发式标注哪些对象有已批准的 wipe、哪些没有模板示例列Has Wipe: yes/no。10.4 Findings发现按严重度分组组内按置信度每条发现的渲染模板规范文档 Step 6 示例### ZA-NNNN: CATEGORY — severity (confidence) **Location:** file.c:123 **Object:** key (uint8_t[32], 32 bytes) **Evidence:** - [source] Description of source-level evidence - [ir] Description of IR-level evidence - [asm] Description of assembly-level evidence **Compiler Evidence** (if applicable): - Opt levels analyzed: O0, O1, O2 - O0: wipe present — llvm.memset(key, 0, 32) at line 88 - O2: wipe absent — dead-store elimination after SROA - Summary: Wipe first disappears at O2. Non-volatile memset eliminated by DSE. **PoC Validation:** exploitable / not_exploitable / rejected / compile_failure / no_poc / pending - Exit code: N - PoC file: poc_za_0001_category.c - Verified: yes / no (if no: {list failed checks}) **Recommended Fix:** Use explicit_bzero(key, sizeof(key)) on all exit paths.report_template.md 中给出了更丰富的实际渲染范例STACK_RETENTION的汇编证据sub $0xc0, %rsp且ret前无清零、REGISTER_SPILL的 spill 指令movq %r12, -48(%rsp)、OPTIMIZED_AWAY_ZEROIZE的 IR diff 证据llvm.memset在 O0 存在、O1 消失dead-store elimination、INSECURE_HEAP_ALLOC的malloc且无mlock/madvise等。10.5 PoC Validation ResultsPoC 验证结果表位于 Findings 与 Superseded Findings 之间模板格式| Finding | Category | PoC File | Exit Code | Result | Verified | Impact | |---|---|---|---|---|---|---| | ZA-0001 | MISSING_SOURCE_ZEROIZE | poc_za_0001.c | 0 | exploitable | Yes | Confirmed | | ZA-0002 | STACK_RETENTION | poc_za_0002.c | 1 | not_exploitable | Yes | Downgraded to low | | ZA-0003 | OPTIMIZED_AWAY_ZEROIZE | poc_za_0003.c | 1 | rejected | No | Rejected — wrong opt level |10.6 Superseded Findings被取代的发现列出被 CFG 分析取代的源码级发现及原因说明。10.7 Confidence Gate Summary置信门控摘要列出被降级的发现及其原因MCP 不可用、缺少硬性证据、PoC 证伪等列出被拒绝的覆盖rationalization override尝试。10.8 Analysis Coverage分析覆盖率已分析的 TU 数 vs compile DB 中的总 TU 数成功运行与失败的 Agent 列表启用/禁用的特性及其影响Agent 5PoC 生成器状态success/failed未审计模式读取{workdir}/rust-compiler-analysis/coverage-gaps.json并列出每个pattern、where、why。这里有一个关键设计细节Step 1 在final模式下不会执行因此本节必须自行读取该文件若文件缺失或为空必须明确写出未报告覆盖缺口。这一行绝不能省略——其缺失会被解读为完整覆盖暗示无事发生。report_template.md 的示例展示了static LazyLockMasterKey这类永不 drop、无从检查 zeroize 路径的 Section D 模式。10.9 Appendix: Evidence Files证据文件附录按发现 ID 映射到证据文件路径相对 workdir的表格供审计人员回溯如compiler-analysis/a1b2/asm-findings.json、compiler-analysis/c3d4/ir-findings.json。十一、输出文件清单所有输出写入{workdir}/report/规范文档 Output 表文件内容raw-findings.json门控前的全部发现保留原始命名空间 IDid-mapping.json{F-SRC-0001: ZA-0001, F-IR-a1b2-0001: ZA-0002, ...}findings.json门控后的结构化发现匹配{baseDir}/schemas/output.json供下游 Agent 消费final-report.md综合 Markdown 报告——仅 final 模式产出notes.md装配过程记录收集到的发现、应用的超驰、施加的门控、ID 映射、PoC 合并结果以及所有文件的相对路径十二、错误处理契约规范文档 Error Handling 定义了七条边界情形情形行为缺少source-findings.json致命——源码分析必须已运行写出错误报告缺少 compiler-analysis 目录非致命——基于可用发现产出报告在 Analysis Coverage 中标注缺失的 TU缺少 MCP 证据非致命——应用 MCP 不可用降级在报告中注明畸形 finding JSON跳过该条目记入notes.md继续final 模式缺少poc_results非致命——所有发现置为poc.validatedfalse、poc.verifiedfalse、poc.validation_resultno_poc报告中注明必须始终产出findings.json即使包含零发现空报告也应保留所有章节并以零计数呈现final-report.md仅 final 模式产出interim 模式禁止产出这一契约与 task.md 的错误处理总表保持一致报告装配器失败即向用户抛出错误interim 与 final 均如此。十三、跨引用约定ID 命名空间总表该 Agent 消费所有上游 Agent 的 ID 并产出最终ZA-NNNN命名空间规范文档 Cross-Reference Convention输入 ID 模式来源 AgentSO-NNNN2-source-analyzerSO-5NNN2b-rust-source-analyzerF-SRC-NNNN2-source-analyzerF-RUST-SRC-NNNN2b-rust-source-analyzerF-IR-{tu_hash}-NNNN3-tu-compiler-analyzerF-ASM-{tu_hash}-NNNN3-tu-compiler-analyzerF-CFG-{tu_hash}-NNNN3-tu-compiler-analyzerF-SIR-{tu_hash}-NNNN3-tu-compiler-analyzerF-RUST-MIR-NNNN3b-rust-compiler-analyzerF-RUST-IR-NNNN3b-rust-compiler-analyzerF-RUST-ASM-NNNN3b-rust-compiler-analyzerZA-NNNN本 Agent最终输出与 SKILL.md 的 Cross-Reference Convention 一致敏感对象C/CSO-0001–SO-4999、RustSO-5000–SO-9999翻译单元为TU-{hash}。所有 finding JSON 对象均包含related_objects、related_findings、evidence_files字段以支持跨 Agent 回溯——这也是 Step 5 交叉引用校验related_objects 必须存在于 sensitive-objects.json得以实施的基础。十四、工作流集成全景从 interim 到 final 的两条调用路径结合 SKILL.md 的 Execution flow 与 README 的 Agent Architecture4-report-assembler 两次被调用的上下文是Phase 3interim: 读取全部上游 Agent 输出 → 应用超驰与门控 → 规范化 ZA-NNNN → 写出 findings.json Phase 4: 5-poc-generator 读取 findings.json为每个发现定制 PoCC/C 全部 11 类Rust 仅 MISSING_SOURCE_ZEROIZE、SECRET_COPY、PARTIAL_WIPE其余 poc_supportedfalse Phase 5: 5b-poc-validator 编译运行 → 5c-poc-verifier 语义校验 → orchestrator 将校验失败项经 AskUserQuestion 提交用户 → 合并为 poc_final_results.json Phase 6final: 读取既有 findings.json → 合并 PoC 结果Step 5b→ 重写 findings.json → 产出 final-report.mdStep 6 Phase 8: orchestrator 读取 {workdir}/report/final-report.md 并作为技能输出返回phase-5-poc-validation.md 的验证检查清单目标变量匹配、目标函数匹配、技术手段适配类别、优化级别正确、退出码解读未颠倒、结果与发现证据一致决定了poc_final_results.json中verified字段的值进而驱动 Step 5b 的六种分支——因此报告装配器最终的置信度升降、严重度降级与rejected标注本质上是 Phase 4–5 整条 PoC 证据链的收口。十五、关键设计要点回顾双模式是为了在 PoC 环节前冻结发现集合interim 只产findings.json让 PoC 生成器与下游测试生成器有稳定输入final 模式才把 PoC 证据回填避免中间态出现未经实证的报告。置信门控是可追溯的每一次降级都会在evidence字段与notes.md留下带[gated: ...]或[assembler] ...前缀的标记配合Confidence Gate Summary章节审计人员可以逐条追溯为什么这条发现被降级。空报告也必须完整零发现时仍产出含全部章节、零计数的findings.json与final-report.md且 Analysis Coverage 的未报告覆盖缺口行必须显式写出——这是防止无发现被误读为已全面覆盖的重要防线。ID 排序规则兼顾可读性与确定性源码发现优先、编译器发现按 TU hash 与证据类型排序保证ZA-NNNN在多次运行间的可复现映射。如需深入阅读源码实现可继续查看4-report-assembler 规范文档、SKILL.md 置信门控权威规则、机械执行器 apply_confidence_gates.py、输出 Schema output.json、报告模板 report_template.md、Phase 3 工作流与 Phase 6 工作流。赞分享AI 技能AI 插件应用安全网络安全AI 评测【免费下载链接】skillsTrail of Bits Claude Code skills for security research, vulnerability detection, and audit workflows项目地址https://gitcode.com/gh_mirrors/skills8/skills点击查看免费下载相关推荐Unity层级面板美化神器HierarchyDecorator常见问题解决Unity层级面板美化神器HierarchyDecorator常见问题解决 HierarchyDecorator是一款轻量级Unity插件能够将层级面板转换AWS CLI acm-pca create-certificate-authority-audit-report 命令实战为私有 CA 生成合规审计报告AWS CLI acm pca create certificate authority audit report 命令实战为私有 CA 生成合规审计报告本开发工具云原生运维Sparkit-learn实战教程用分布式K-Means聚类处理百万级数据集Sparkit learn实战教程用分布式K Means聚类处理百万级数据集 Sparkit learn是一个结合PySpark与Scikit learn优势机器学习大数据创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

4-report-assembler 报告组装器完全指南：zeroize-audit 审计结果汇聚、置信门控与双模式报告生成

相关推荐

MacBook Neo传闻解析：苹果如何冲击低价笔记本市场？

U盘文件不显示却占空间？从原理到实操的完整数据恢复指南

openJiuwen agent-core 的 create_deep_agent 工厂：一站式构建可运行 DeepAgent 的完整指南

更多资讯

遥感电力塔检测：10000张图三格式标签实战指南

YOLOv8深基坑变形监测：毫米级位移校准与边缘部署实战

Spark信用卡评分卡分析：从特征工程到WOE与分数映射

从自建数据集到部署排查：打电话/抽烟检测的VOC与YOLO全流程实践

哈工大通信复试不考专业题？真正在考什么

PHP开源工单系统FeelDesk全解析：部署、模板定制与二次开发

今日更新

交通拥堵预测毕设：基于Python+LSTM的车辆流量预测系统全流程解析

MATLAB/Simulink搭建10机39节点电力系统暂态稳定仿真实战

无人机航拍三维重建全流程：从SfM到网格生成的避坑指南

本周精选

交通拥堵预测毕设：基于Python+LSTM的车辆流量预测系统全流程解析

MATLAB/Simulink搭建10机39节点电力系统暂态稳定仿真实战

无人机航拍三维重建全流程：从SfM到网格生成的避坑指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？