★ FEATURED ARTICLE 干安全分析这行的人大概都有过这种体验同一个模型上午让它看一段固件加载流程它能把文件头、节表、字符串分布讲得头头是道下午你让它顺手改个构建脚本它反而开始一本正经地胡说。问题不在模型本身而在于你喂给它的上下文里到底有没有一套针对当前任务的作业规范。reverse-skill这类项目想解决的正是这件事把逆向分析、安全审计相关的作业知识拆成一个个独立技能包再通过一套技能路由机制让 Claude Code、Cursor、Cline、Codex 这些 AI 编码客户端在合适的时机自动加载合适的技能而不是把所有知识一股脑塞进系统提示词里。这篇文章不讲虚的我按自己搭这套东西的顺序来写先讲清楚为什么要做路由而不是全量注入再拆技能包的目录结构和触发元数据然后逐个客户端给出可复制的配置写法接着跑一遍从零到能用的完整流程最后把踩过的坑整理成一张速查表。读者对象是已经在用 AI 编码助手做代码分析、二进制结构梳理、依赖清点这类工作的同行也包括想把团队内部作业规范沉淀成技能包的朋友。全文涉及的技能内容都限定在自有程序、已获授权的样本、公开练习题目这几类范围内边界问题我会在正文里反复提醒。1. reverse-skill 到底在解决什么问题1.1 一个模型四种客户端知识是碎的先说个很现实的情况。团队里几个人用不同的客户端有人习惯在终端里跑 Claude Code有人离不开 Cursor 的编辑器内联补全有人用 Cline 做多步任务编排还有人偏爱 Codex 的命令行交互。这四套东西的项目规则加载机制完全不同——有的认根目录的 Markdown 记忆文件有的认带 frontmatter 的规则文件有的认目录形式的规则集合有的认分层级的说明文件。结果就是同一套分析一个未知二进制时应该先做什么的作业规范你得在四个地方各维护一份改一处忘三处。更糟的是规范会漂移终端那份更新到了第三版编辑器里那份还停在第一版两个人跑同一个样本得出不同结论回头排查半天发现是提示词不一致。技能路由的第一个价值就在这里——单一事实来源。技能包只写一份放在仓库里四个客户端通过各自的适配层去引用同一份内容。适配层可以很薄薄到只是一行路径引用或者一段生成脚本。1.2 为什么不做全量注入而是路由有人会问既然技能包就那些内容干脆全部塞进系统提示词不就完了我试过结论是行不通主要原因有三条。第一是上下文预算。逆向分析这类任务的技能描述天然偏长光是文件格式识别一个技能要覆盖常见容器格式的魔数、节区布局、对齐规则、常见加壳特征写紧凑了也要一两千字。技能一多光技能描述就吃掉大半窗口留给实际代码和输出分析的余量就没了。第二是注意力稀释。模型不是把上下文读进去就一定能用上。无关技能堆在那里会干扰它对当前任务的判断出现你让它看字符串它跑去讲节表对齐这种跑偏。技能越全跑偏概率反而越高。第三是工具调用的选择困难。很多技能包会附带建议的工具链比如静态结构梳理用十六进制查看器加反汇编器动态观察用调试器加行为监控。如果所有工具建议同时在场模型经常选一个最顺手的而不是最适合当前文件的。路由的本质是按需装配先用一个轻量的意图识别环节判断当前任务属于哪一类再把对应的技能正文拼进上下文。判断环节本身要足够便宜——关键词加文件类型加显式指令三路打分就够了不需要再调用一次大模型。1.3 技能路由的三层结构我把整套东西拆成三层后面所有配置都围绕这三层展开。第一层意图识别。输入是用户的一句话加上当前操作的文件路径、扩展名、编辑器选区内容。输出是一个候选技能列表加分数。这一层要快要稳宁可漏判也不要误判因为漏判的后果是模型用通用能力硬扛误判的后果是它拿着一份完全不相关的规范在那儿自我约束。第二层技能选择。对候选列表做冲突消解。比如二进制结构梳理和伪代码逻辑复核可能同时命中但前者适合原始样本后者适合反编译输出得按文件类型决定谁优先。还要考虑互斥技能比如仅静态观察和允许动态执行这两个模式不能同时生效。第三层上下文装配。把选中的技能正文、附带的检查清单、建议的工具调用顺序拼成一段结构化文本注入到对应的客户端。这一层要控制长度通常只装配一个主技能加最多一个辅助技能超过两个就说明意图识别出问题了。注意路由层不要试图做成智能体自主决策。让模型自己选技能听起来很美实测下来延迟高、结果不稳定而且每次选择都要消耗上下文去描述所有候选技能等于把省下来的预算又花回去了。规则打分加人工兜底是目前性价比最高的做法。2. 技能包的目录结构与元数据设计2.1 一份能跨客户端复用的目录约定目录结构这块我的原则是内容与适配分离。技能正文放在一个中立目录里四个客户端的配置只负责指向它。下面是我现在用的布局你可以直接照着建repo-root/ ├── skills/ # 中立技能库单一事实来源 │ ├── _index.yaml # 全局索引与路由参数 │ ├── binary-triage/ │ │ ├── SKILL.md # 技能正文 │ │ └── checklist.md # 附带的检查清单 │ ├── string-symbol-scan/ │ │ └── SKILL.md │ ├── dependency-audit/ │ │ └── SKILL.md │ ├── pseudocode-review/ │ │ └── SKILL.md │ └── report-writer/ │ └── SKILL.md ├── adapters/ # 各客户端适配层 │ ├── claude/CLAUDE.md │ ├── cursor/rules/*.mdc │ ├── cline/.clinerules/ │ └── codex/AGENTS.md ├── router/ │ ├── route.py # 打分与装配脚本 │ └── cases.yaml # 回归测试用例 └── out/ # 生成产物不入库几个设计取舍值得说一下。技能用目录而不是单文件是因为一个技能往往会带检查清单、示例片段、常见误判案例塞进一个文件会很长模型读的时候容易只读前半段。索引单独抽出来是为了让路由脚本不用扫描全部目录去解析每个技能的元数据读一个 YAML 就够冷启动快。适配层单独放是为了让换客户端变成加一个文件而不是改技能内容。_index.yaml里我一般这么写version: 3 default_skill: null max_inject: 2 skills: - id: binary-triage path: skills/binary-triage/SKILL.md priority: 90 file_globs: [*.bin, *.elf, *.so, *.dll, *.exe, *.img] keywords: [固件, 二进制, 样本, 文件头, 节表, 加载, firmware, elf, pe] exclusive_group: static - id: string-symbol-scan path: skills/string-symbol-scan/SKILL.md priority: 70 file_globs: [*.bin, *.elf, *.so] keywords: [字符串, 符号, 导入表, 导出表, strings] exclusive_group: static - id: pseudocode-review path: skills/pseudocode-review/SKILL.md priority: 80 file_globs: [*.c, *.cpp, *.pseudo, *.txt] keywords: [伪代码, 反编译, 逻辑, 控制流, decompile] exclusive_group: review - id: dependency-audit path: skills/dependency-audit/SKILL.md priority: 60 file_globs: [package.json, requirements.txt, go.mod, Cargo.toml] keywords: [依赖, 组件, 版本, 第三方库] exclusive_group: audit - id: report-writer path: skills/report-writer/SKILL.md priority: 50 file_globs: [*.md] keywords: [报告, 结论, 汇总, 输出格式] exclusive_group: output2.2 触发元数据怎么写才不容易误触发keywords这一项最容易写坏。我踩过的坑是关键词写得太泛比如给依赖审计技能写了[分析, 检查, 看看]结果任何一句话都能命中路由等于没做。后来我定了几条规则。关键词必须是名词或专有动作不能是泛动词。分析检查看一下这类一律删掉换成依赖组件版本传递引用这样的具体对象。判断标准很简单把这个词单独拿出来你能立刻想到它对应哪类任务吗想不到就删。中文关键词要考虑同义表达。用户不会说请执行二进制结构梳理他会说这坨东西是啥。所以除了正式术语还得补一批口语说法。我一般在每个技能下面额外挂一个keywords_loose字段权重减半专门收这些。文件扩展名的权重应该高于关键词。因为关键词是用户说的可能随口但文件是他真的打开的。我给的权重是文件命中 40精确关键词 30宽松关键词 15显式指令用户直接说用 XX 技能100。这样即使用户一句话没说清楚只要他打开的是.elf文件结构梳理技能也能被拉起来。给技能加互斥组。同一个exclusive_group里最多只装配一个取分最高的。这解决了一个很烦的问题用户打开一个.bin说看看里面有没有可疑字符串结构和字符串两个技能都会命中但真正该装配的是字符串扫描结构梳理作为背景知识提一句就够。2.3 优先级与冲突消解的具体算法打分打到平手怎么办我的处理顺序是这样的。先比精确度显式指令 文件命中 精确关键词 宽松关键词。再比priority字段。还平就比技能正文长度短的优先——理由是短技能装配进去占的预算少如果它不够用后面还能追加。这里有个反直觉的点不要把报告输出类技能的优先级设高。我一开始把报告技能的优先级设成 95想着最后总要出报告嘛结果每次分析刚开始它就被拉起来了模型还没看完文件就开始套报告模板输出的结论全是待补充。后来降到 50只在用户明确说整理成报告或者对话轮次超过某个阈值时才装配效果好很多。提示技能路由的配置一定要进版本库并且和技能正文同一次提交。我见过把索引放在本地不提交的做法换台机器就完全失效排查起来极其浪费时间。3. 四个客户端的接入方式逐个配先说清楚一件事下面四套配置的具体文件名和字段不同版本可能有细微差异写的时候以你本地实际版本的文档为准。我给的是长期稳定的那部分结构思路是通用的。3.1 Claude Code记忆文件 子代理分工终端里跑的这一套核心是两个东西项目根目录的记忆文件和子代理定义。记忆文件的作用是常驻上下文所以只放路由规则本身不放技能正文。我的写法是这样的# 项目作业约定 ## 技能路由 本项目在 skills/ 下维护了一套分析技能。开始任何文件分析前 先读取 skills/_index.yaml按 router/route.py 的打分规则选择技能 只装配得分最高的一到两个技能正文不要一次性读取所有 SKILL.md。 ## 边界 - 仅分析本仓库内的自有程序、已获授权的样本、公开练习题目。 - 遇到来源不明的样本先停下来说明情况不要擅自执行。 - 分析结论必须标注依据文件偏移、字符串位置、调用点不允许只给结论。 ## 输出 - 中间过程用短段落不要长表格。 - 最终结论单独成段前面加结论前缀。这段东西不长但它是整套路由能不能生效的关键。不要一次性读取所有 SKILL.md 这句话必须写进去否则模型很容易图省事把整个技能目录读一遍上下文瞬间爆掉。子代理这块适合拆的是那种独立性强、输出格式固定的环节。比如我会定义一个专门做结构清点的子代理它的任务只有一件给定一个文件输出格式、架构、节区、入口点、依赖库这几项事实不做任何推断。这样做的好处是主对话上下文干净推断和事实分离。--- name: binary-facts description: 仅提取二进制文件的结构性事实不做行为推断 tools: Read, Grep, Glob, Bash --- 你只做事实提取。给定一个文件路径输出 1. 文件类型与架构 2. 节区/段列表及大小 3. 入口点偏移 4. 导入的库与函数名清单 5. 可打印字符串中最长的 20 条及其偏移 不允许输出这个程序可能在做 X这类推断。没有把握的项写未确定。这种只做事实、禁止推断的约束在逆向分析里特别值钱。因为推断一旦和事实混在一起后面很难拆开复核。3.2 Cursor规则文件的分层与 glob 匹配编辑器内联这套的规则机制是文件级的好处是能按路径自动生效坏处是容易写多写重。我的分层是三层。第一层是常驻规则alwaysApply打开内容就是那段路由说明和记忆文件基本一致。第二层是路径规则靠 glob 匹配比如**/*.bin、**/*.elf命中时自动带上结构梳理技能的摘要和工具建议。第三层是手动规则不自动生效需要的时候用引用。路径规则的写法--- description: 二进制文件分析时的作业规范 globs: [**/*.bin, **/*.elf, **/*.so, **/*.dll] alwaysApply: false --- 打开此类文件时 - 先确认文件来源与授权范围来源不明则停止。 - 按 skills/binary-triage/SKILL.md 的步骤执行不要跳步。 - 字符串提取优先于反汇编先建立整体印象。 - 每一条结论后面标注依据位置。这里有个细节值得强调路径规则里不要写完整技能正文。我试过把技能全文贴进.mdc文件结果是只要打开一个.so编辑器上下文就被占掉一大块补全质量肉眼可见地下降。正确做法是只写去读哪个文件让模型按需读取。3.3 Cline规则目录与工作流组合这一套支持目录形式的规则集合正好对上我们的技能库结构。我的做法是在.clinerules/下面放两类文件一类是编号的规则文件按加载顺序排一类是工作流描述对应多步任务。.clinerules/ ├── 00-routing.md # 路由总则 ├── 10-boundary.md # 授权边界与安全约定 ├── 20-tools.md # 工具调用偏好与顺序 └── workflows/ ├── triage.md # 从零到结构清点的完整流程 └── report.md # 分析结论整理流程编号前缀这件事看着土但很管用。规则文件的加载顺序会影响模型的理解先给总则再给细则比反过来效果稳定。10-boundary.md我固定排在第二位原因是边界约束必须在工具偏好之前生效否则模型可能先学会了该用哪个工具再看到哪些不能碰执行时容易越界。工作流文件的写法要具体到步骤不能只写目标# 工作流未知文件初筛 步骤 1确认来源 - 询问或记录文件来源属于自有程序、已授权样本、公开练习题之一才继续。 步骤 2文件类型确认 - 读取前 64 字节按魔数判断容器格式。 - 记录判断依据不要凭扩展名下结论。 步骤 3整体结构 - 列出节区/段、大小、权限标志。 - 标出异常项大小为零、权限可写可执行、名称不合常规。 步骤 4静态字符串 - 提取长度大于 6 的可打印字符串。 - 按语义分组路径、域名、错误提示、格式串、疑似密钥。 步骤 5输出 - 按事实 / 观察 / 待验证三段输出不要混在一起。这套流程写下来大概一千字作为工作流文件存放需要时手动触发不占常驻上下文。3.4 Codex CLI说明文件的收敛写法命令行这套认的是项目说明文件支持分层——根目录一份总说明子目录可以有自己的补充说明。这个分层特性很好用因为逆向分析相关的技能往往集中在特定目录不需要全仓库生效。根目录的说明文件我只留路由和边界控制在三十行以内# 仓库说明 ## 分析类任务 分析类任务的技能库在 skills/索引在 skills/_index.yaml。 开始分析前先读索引只加载命中的技能不要遍历全部技能文件。 ## 授权边界 - 仅处理自有程序、已授权样本、公开练习题目。 - 来源不明的文件不执行只做静态读取。 - 结论必须可追溯到具体位置或命令输出。 ## 命令约定 - 所有分析命令的输出重定向到 out/不要直接打印大段十六进制。 - 单次命令输出超过 200 行时先用过滤条件收窄。然后在我放样本的目录下再放一份局部说明写明这个目录下都是公开练习题可以放心分析避免每次都要重复确认授权。3.5 四套配置的对照关系配置多了容易乱我整理了一张表放在仓库 README 里新同事进来直接照着看。能力Claude CodeCursorClineCodex CLI常驻规则载体根目录记忆文件alwaysApply规则编号规则文件根目录说明文件路径自动匹配需在规则中说明原生 glob 支持需在规则中说明需在说明中写明目录按需加载技能显式指令 读取引用工作流文件显式指令 读取分层覆盖目录级记忆文件目录级规则目录规则目录内文件子目录说明文件适合放的内容路由总则、边界单文件类型的作业规范多步流程命令约定、输出规范这张表的价值在于当你需要新增一个技能时能立刻知道该在哪几个地方补配置不会漏。4. 从零跑通一次完整的技能路由4.1 造一个最小可用的技能包先别贪多两个技能就够验证链路。第一个是结构清点第二个是字符串扫描。skills/binary-triage/SKILL.md的内容我写得比较克制控制在八百字以内# 技能二进制结构初筛 ## 适用 已知来源的二进制文件需要快速建立整体印象。 ## 步骤 1. 读文件头按魔数确认格式不依赖扩展名。 2. 列出节区或段记录名称、偏移、大小、权限。 3. 标记异常零大小节区、可写可执行段、名称非常规。 4. 记录入口点与架构位数、字节序、指令集。 5. 列出导入的库与关键函数。 ## 输出要求 - 事实与观察分开写。 - 每条事实标注来源偏移或命令。 - 不下行为结论。 ## 常见误判 - 压缩过的正常程序会出现高熵段不等于加壳。 - 某些语言的运行时会产生大量看起来可疑的符号名。 - 大小异常的节区可能只是对齐填充。第二个技能短一些核心是提取策略而不是命令本身# 技能静态字符串扫描 ## 适用 需要从文件中快速获取语义线索时。 ## 步骤 1. 按最小长度 6 提取可打印 ASCII 与 UTF-16 字符串。 2. 按语义分组文件路径、域名与地址、错误提示、格式串、疑似凭据。 3. 对每组按出现频次排序取前若干条。 4. 标注偏移便于回查。 ## 注意 - 疑似凭据一律脱敏后再写入报告只保留前后各 4 个字符。 - 字符串不等于逻辑不要直接从字符串推断行为。4.2 写一个够用的路由器路由脚本我写得比较土标准库加一个 YAML 解析就够了。核心逻辑是打分、去重、按互斥组取最高、最后生成注入文本。import fnmatch import sys from pathlib import Path import yaml W_FILE 40 W_KW 30 W_KW_LOOSE 15 W_EXPLICIT 100 def score(skill, text, file_path, explicit_idNone): s 0 if explicit_id and skill[id] explicit_id: s W_EXPLICIT if file_path: name Path(file_path).name for g in skill.get(file_globs, []): if fnmatch.fnmatch(name, g) or fnmatch.fnmatch(file_path, g): s W_FILE break low text.lower() for k in skill.get(keywords, []): if k.lower() in low: s W_KW for k in skill.get(keywords_loose, []): if k.lower() in low: s W_KW_LOOSE return s def route(index_path, text, file_pathNone, explicit_idNone, top_k2): idx yaml.safe_load(Path(index_path).read_text(encodingutf-8)) scored [] for sk in idx[skills]: sc score(sk, text, file_path, explicit_id) if sc 0: scored.append((sc, sk)) scored.sort(keylambda x: (-x[0], -x[1].get(priority, 0))) picked, groups [], set() for sc, sk in scored: g sk.get(exclusive_group) if g and g in groups: continue picked.append((sc, sk)) if g: groups.add(g) if len(picked) min(top_k, idx.get(max_inject, 2)): break if not picked: return 未命中任何技能按通用流程处理。 parts [以下技能按当前任务路由命中请严格按其中步骤执行\n] for sc, sk in picked: body Path(sk[path]).read_text(encodingutf-8) parts.append(f!-- skill: {sk[id]} score{sc} --\n{body}\n) return \n.join(parts) if __name__ __main__: text sys.argv[1] fp sys.argv[2] if len(sys.argv) 2 else None print(route(skills/_index.yaml, text, fp))这个脚本不到一百行但它把前面讲的三层结构全落地了。exclusive_group那段是重点没有它两个静态分析技能会同时被装配上下文直接翻倍。4.3 端到端验证三种问法看加载结果光写完不算数得验证。我准备了三个典型输入分别是明确命中、模糊命中、不该命中。用例一明确命中结构清点。python router/route.py 帮我看看这个 firmware.bin 里有什么结构 samples/firmware.bin预期结果是binary-triage得分 70文件 40 关键词 30string-symbol-scan也可能命中字符串以外的词但分数低于它最终只装配主技能。实测下来这个组合很稳模型会老老实实按步骤走先读文件头再列节区。用例二模糊命中字符串扫描。python router/route.py 这文件里有没有什么可疑的地址 samples/firmware.bin可疑这个词很泛我特意没收进任何技能的关键词表靠的是firmware.bin的文件命中把结构清点拉起来40 分。但因为没有精确关键词得分不够高实际装配时我会在客户端里追加一句如果用户问的是具体内容线索优先用字符串扫描。这就是人工兜底的位置——路由给候选人做最终判断。用例三不该命中。python router/route.py 给 scripts/build.py 加个单元测试 scripts/build.py得分全为零输出未命中任何技能。这一步很重要它证明路由没有过度触发。我一开始的配置里给分析这个词设了关键词结果这个用例被误判成结构清点模型跑去给单元测试写二进制格式说明非常离谱。验证通过之后把这几个用例固化到router/cases.yaml里每次改索引就跑一遍cases: - input: 帮我看看这个 firmware.bin 里有什么结构 file: samples/firmware.bin expect_first: binary-triage - input: 这文件里有没有什么可疑的地址 file: samples/firmware.bin expect_contains: [binary-triage] - input: 给 scripts/build.py 加个单元测试 file: scripts/build.py expect_empty: true - input: 用 pseudocode-review 看一下这段反编译结果 file: out/decompiled.txt expect_first: pseudocode-review最后这条是显式指令测试验证W_EXPLICIT那条路径没坏。这套用例我改索引必跑五分钟的事能省掉后面大量为什么突然不好使了的排查。5. 高频踩坑与排查手册5.1 技能叫不动的五个常见原因这是被问得最多的问题。按我遇到的频次排大概是这么五种。第一索引没被读到。表现是模型完全不提技能直接按通用能力干活。原因通常是常驻规则里没写清楚先读索引或者写了但位置太靠后被其他规则淹没了。解决办法是把这句话提到规则文件的第一段。第二技能路径写错。相对路径的基准在不同客户端里不一样有的按仓库根有的按当前文件所在目录。我现在的做法是一律用仓库根相对路径并且在路由脚本里做一次存在性检查找不到就直接报错不要让模型去猜。第三技能正文太长被截断。单个技能超过两千字时模型经常只读到前半段就开始执行。解决办法是拆分把步骤和常见误判分成两个文件后者按需加载。第四互斥组配置互相压制。两个技能被放进同一个互斥组但实际场景里需要同时用结果永远只能装配一个。这种情况要重新审视分组互斥的判断标准应该是这两个技能的作业规范是否冲突而不是它们是不是同一类任务。第五用户表述太口语。用户说这玩意儿有点怪任何关键词都命中不了。这时候路由不该硬猜应该输出未命中请确认任务类型把判断权交回给人。我一开始觉得这样体验不好后来发现让用户多说一句比让模型猜错方向再返工要省时间得多。5.2 上下文吃紧时的取舍顺序技能装配多了上下文一定紧张。我的削减顺序是这样的从先砍到后砍。先砍示例片段。技能正文里那些举个例子假设有个函数长这样的内容对模型理解帮助有限但在预算紧张时是最先该牺牲的。再砍常见误判章节。这部分价值高但可以延后只在用户对结论提出质疑时加载。然后砍辅助技能。主技能保留辅助技能降级为参考技能名xxx需要时再读。最后才砍工具建议。工具建议是技能包里性价比最高的部分因为模型选错工具带来的返工成本远大于省下的那几百字。注意不要在预算紧张时砍掉授权边界那段。这段文字很短但它决定了整个分析过程是否在合规范围内。我把它单独抽成一个固定注入的片段不参与削减。5.3 排查速查表把这几年遇到的症状整理成一张表出问题时按图索骥。症状最可能原因快速验证处理完全不提技能索引未加载直接问模型索引里有什么把读索引的指令提到规则首段技能加载了但步骤乱序正文过长被截断统计 SKILL.md 字数拆分步骤与附录同时装配两个同类技能互斥组缺失看路由脚本输出补exclusive_group明显不相关也触发关键词太泛跑cases.yaml反例删泛动词改名词换了客户端就失效路径基准不一致打印实际解析路径统一改成根相对路径结论和事实混在一起输出约束缺失看技能的输出要求段加事实/观察/待验证三段式分析中途跑去执行文件边界约束位置太靠后看规则文件顺序边界规则排到工具偏好之前这张表我贴在仓库 wiki 首页新同事入职第一周基本都会用到其中三四行。6. 把它当成一个长期维护的产品6.1 回归用例是这套东西的生命线技能路由这类配置有个特点坏掉的时候不会报错只会悄悄变差。你今天删了一个关键词明天可能就发现某类任务不再触发技能但没有任何提示。所以我坚持两件事。一是所有改动必须过cases.yaml包括新增技能、调整权重、修改关键词。用例不追求覆盖全但必须包含至少一个正例、一个模糊例、一个反例。二是给路由输出打日志每次装配了哪些技能、得分多少、为什么被互斥组挡掉全部记录下来。出了问题翻日志比瞎猜快十倍。日志格式我用的很简单一行一条2025-xx-xx route input看看这个固件 filefirmware.bin candidate binary-triage score70 picked candidate string-symbol-scan score40 dropped(groupstatic) candidate dependency-audit score0 result: [binary-triage]这种日志看一百行就能看出模式比在客户端里反复试要高效得多。6.2 版本与灰度技能包改动的风险主要来自改了但没验证。我的做法是给索引加version字段技能正文里也标注适用版本改动走小步快跑每次只改一个技能的一个方面。灰度这块如果团队有几个人用不同客户端最省事的办法是让一个人先升跑一周看他日志里有没有异常装配。因为四个客户端的适配层引用的是同一份技能正文一个人的问题大概率是所有人的问题反过来也成立。还有一点技能正文里的工具建议要写得宽泛一些。我最初写死了具体的工具名和参数结果换台机器没装那个工具模型就卡在那儿反复尝试。后来改成优先用十六进制查看器读取前 N 字节如果没有则用系统自带的文件识别命令鲁棒性好了很多。我个人在这套东西上最大的体会是技能路由的价值不在于让模型更聪明而在于让它更守规矩。模型本身的通用能力其实够用真正让人头疼的是它每次的作业方式都不一样——这次先看字符串下次先反汇编再下次直接下结论。把作业规范固化下来用路由保证在正确的时机加载正确的规范输出的稳定性会有肉眼可见的提升。这套配置搭起来大概两三天后面每次分析省下的返工时间一周就赚回来了。
阅读完成 · 觉得有帮助？
