如果你最近正在用 AI 编码客户端干二进制分析、协议还原或者老项目维护的活大概率会遇到这么个情况让模型写一个快速排序又快又对可丢给它一份没有文档的 PCAP 流量包或者一个来路不明的二进制格式它就开始一本正经地胡说八道。这不是模型水平不够而是任务形态不匹配。绝大多数 AI 编码客户端的默认工作流是“从需求到代码”的单向生成逆向工程恰好是反过来的——你面对的是已经存在的产物要逆推出它的结构、含义和边界。我做的这个 reverse-skill就是针对这类场景的一套技能路由包。它的定位不是替代反汇编器或抓包工具而是把逆向工程的方法论固化成 AI 编码客户端能识别、能执行、能自我约束的技能模块再按任务类型做智能路由。简单说它管的是“当 AI 拿到一个逆向任务时第一步做什么、第二步做什么、什么情况下必须停下来验证假设”而不是让 AI 靠泛化的语言能力临场发挥。本文会把这套技能包的设计思路、内部结构和实际落地过程中的坑都讲透适合正在折腾 AI 编程工作流又需要处理二进制协议、未知格式、算法还原这类任务的工程师参考。1. 为什么 AI 编码客户端做逆向总是差一口气1.1 通用能力强不代表逆向任务就能用先讲一个我自己的观察。过去一年里我陆陆续续在 Cline、Continue、Codex CLI 这些客户端上测试过不少逆向工程任务包括解析一个私有二进制配置格式、还原一段自定义加密协议、定位一个老服务崩溃的根因。结论很一致模型在和代码生成相关的逆向任务上表现尚可但一旦涉及“从数据中推断出规则”效果就剧烈下降。原因不复杂。AI 编码客户端的训练信号主要来自“输入描述、输出代码”的海量样本它擅长的是把明确需求翻译成实现。而逆向工程里最核心的动作是“观测产物、提出假设、设计实验验证假设、修正模型”这是一个类科学方法的过程。比如给你一段十六进制数据你要先判断它是定长结构还是变长结构字段是按字节对齐还是按位对齐有没有校验和数据是 network byte order 还是 host byte order。这些问题在没有验证手段时模型只能靠统计规律瞎猜而统计规律在私有格式面前基本没用。通用 prompt 的方式之所以不行是因为它把逆向工程当成一次问答而不是一个多阶段迭代过程。你去问 GPT“这段数据是什么格式”它能给你一堆可能性但没有一个是被验证过的。而真正做逆向的人都知道答案不是猜出来的是排错排出来的。1.2 逆向工程天然是“假设-验证-迭代”循环说到这就要点破一个本质逆向工程和正向开发的思维方式是镜像的。正向着眼于设计意图逆向着眼于观测事实。每一条结论都得有对应证据不然就是瞎编。我常用一个类比来跟同事解释正向开发像是在盖房子图纸在先逆向工程像是考古你挖到一堵墙得判断它是承重墙还是隔断墙判断依据不是墙本身而是旁边的柱基、梁口和地面铺装的相对关系。每一条判断都要有地层证据支持而且结论可能随新证据出来被推翻。这个思路翻译到技术执行层就是一条不短的链路先做信息收集看文件头、熵值、字符串、二进制分布再建立初步结构模型然后用工具去切割、标注、验证字段边界最后把确认的部分沉淀成结构化描述。传统做法里这条链路靠人的经验和工具链串起来一个人同时操作十六进制编辑器、反汇编器、抓包工具、脚本环境。而 AI 编码客户端默认不具备这种多阶段工作流的编排能力它更习惯一锤子买卖。1.3 技能路由包补齐的不是知识是流程所以 reverse-skill 的切入点很明确不打算教模型更多逆向知识而是把上面说的“假设-验证-迭代”循环编码成一套可执行的流程规范。这里有个关键概念“技能路由包”和普通的系统提示词有什么不同普通的 system prompt 是一段静态文本模型每次对话都要重新理解一遍且没有任何强制性。技能路由包则把任务分片每一片都有独立的上下文、工具列表、输出格式和验收标准然后由路由层根据输入任务的意图去匹配最合适的技能模块。我举个具体例子。你在 AI 编码客户端里丢给它一个任务“这个 config.bin 文件不知道什么结构帮我解析一下字段。”没有路由包时模型会基于训练数据里见过的各类二进制格式给出猜测性解析输出一段 Python 代码让你跑跑了不对再改改完再猜效率很低。有路由包时它会先被路由到“二进制格式逆向”技能下这个技能强制要求先做熵值分析、字符串提取、结构对齐检测然后才会产出解析脚本而且脚本必须输出验证日志不能只给结论。说白了路由包是把“AI 做逆向”从碰运气变成了走流程。2. reverse-skill 核心机制三层结构与路由逻辑2.1 路由层从任务意图到技能索引reverse-skill 的第一层是路由层。它做的事情是读入用户请求的文本识别出任务类型然后决定激活哪个或哪几个技能模块。这里的技术本质其实是意图分类但和普通意图分类的区别在于分类对象高度垂直且分类结果直接决定后续工具链的绑定。在我的实现里技能索引分成几个主类二进制格式分析、网络协议还原、加密算法识别与参数提取、崩溃与异常定位、补丁生成与验证、遗留代码结构梳理。每个主类下还有若干子技能比如“网络协议还原”下面会区分“文本协议”“定长二进制协议”“TLV 变长协议”和“带状态机的流协议”。为什么一定要做这种细分因为不同协议的分析路径完全不一样。文本协议你用 grep 和正则就够了定长二进制协议需要做字段对齐和样本聚类TLV 协议的关键是找出 Type 字段的取值范围和 Length 的长度编码方式带状态机的协议则要从交互时序反推状态转移条件。如果把这几类混在一个技能里模型会倾向于用同一种方法处理所有协议这是最致命的。路由规则我用的是关键词加语义打分结合的方式。关键词负责粗筛比如出现“报头”“字段”“偏移”就偏向二进制格式分析出现“握手”“包”“流量”就偏向协议还原。语义打分则是一个轻量的 embedding 匹配把用户请求和一个技能描述库做余弦相似度计算取最高分。粗筛是为了控制候选集语义打分是为了处理那些用词不典型的请求。2.2 技能层每个技能的 SOP 化描述技能层是 reverse-skill 的核心每个技能模块本质上是一份 SOP 化的指令集。和通用思维链提示词不同技能模块里写的不是“请一步步思考”而是具体的操作指令、工具命令、验证节点和失败回退策略。以“二进制格式逆向”这个技能为例它内部写死了一套执行节奏观察文件基础属性大小、扩展名、魔数、熵值。提取字符串和可见字符分布用于判断是否含文本段。分块分析按 1 字节、2 字节、4 字节对齐做统计寻找重复模式和边界特征。建立结构假设区分头部、索引区、数据区。用脚本验证假设对样本文件做结构化切割输出每个字段的偏移、长度、取值分布。将验证通过的字段写入结构化描述验证不通过的字段标记为“待确认”回到第 4 步。注意第 3 步到第 5 步是强制的而且第 6 步要求模型必须保留“待确认”标签。这个设计是有意为之因为逆向工程最大的坑是过度自信模型倾向于把猜测当结论写出来。强制保留未知项是为了让结论可审计。技能层还绑定了工具调用规范。每个技能模块会声明它允许调用的工具白名单比如二进制格式逆向技能允许调用 xxd、file、ent、binwalk、radare2 和 Python 脚本环境不允许模型直接给出“根据经验这里应该是 XXX”。工具的输出会回填到上下文里作为下一步推理的事实依据。2.3 工具层命令模板与产物规范第三层是工具层它的作用是降低模型调用工具的出错率。你可能也有体验直接让 AI 用命令行工具时它经常会把参数写错或者忘了把输出保存到文件。工具模板就是为了解决这个问题。每个技能模块背后挂着一组已验证过的命令模板。比如熵值分析固定用ent file.bin字符串提取固定用strings -n 6 -t x file.bin2 字节对齐统计固定用一段 Python 脚本。模型不用现场发明命令只需要选择合适的模板然后把文件路径填进去。产物规范也很关键。每个技能执行完后必须输出一份标准格式的报告字段包括任务概述、执行过的工具命令、关键观测、已验证的结论、待确认项、建议的下一步动作。这个规范的直接好处是任务的中间产物可以串起来。第一个技能的报告可以成为第二个技能的输入比如“二进制格式逆向”报告里的“待确认项”会直接影响“补丁生成”技能的执行范围。我把三层的关系总结成一张表方便你理解层级职责典型内容失败表现路由层判断任务类型选择技能意图分类词表、语义匹配模型任务分错技能用文本协议方法解析二进制技能层定义执行步骤和验证节点SOP描述、工具白名单、回退策略跳步执行跳过验证直接给结论工具层提供命令模板和产物格式xxd、ent、radare2命令模板命令参数错误、产物格式不可解析3. 一次协议还原任务的完整路由过程3.1 任务输入一个没有文档的 TCP 流理论讲完我们走一个真实的任务链路。假设我拿到一个 PCAP 文件场景是一个 IoT 设备和一个云端服务器之间的通信协议未知文档早丢了。任务描述是“分析这个 PCAP弄明白客户端登录过程是怎么实现的”。这个任务丢给普通 AI 编码客户端模型会怎么做大概率是直接打开 PCAP看几个 TCP 流然后给出“这看起来像是基于 JSON 的协议服务端返回了 token”这类泛泛而谈的结论。但实际上IoT 厂商很少用纯文本协议大多数是自定义二进制协议甚至还有一层轻量加密。泛泛而谈的结论等于没做。用 reverse-skill 走一遍路由层首先会识别出三个关键词“PCAP”“TCP”“登录过程”。这些词通过粗筛落入“网络协议还原”的技能候选集语义打分时“登录过程”这个短语又和“带状态机的流协议”子技能匹配度最高因为登录通常涉及多次交互和状态转移所以最终路由结果是主技能“网络协议还原”子技能“状态机流协议分析”。3.2 路由决策为什么落在“状态机流协议”上你可能想问如果路由到“定长二进制协议”是不是也能做能但会漏掉关键信息。登录过程的特点是客户端先发一个 hello服务端回一个 challenge客户端再回一个 response服务端最后确认。这四步之间存在严格的先后依赖是典型的有限状态机。如果只是分析单个包的结构你只能看到“每个包长什么样”看不到“协议允许在什么状态下发什么包”而后者的价值远大于前者。这就是路由决策的意义。它不只是选一个方法而是选一个看待任务的视角。状态机流协议技能会给模型注入一套分析范式先把所有 TCP 流按五元组分流再按时间序重建每个连接里的请求-响应对然后对每一对做结构分析最后把多条连接的交互模式抽象成状态转移图。这套分析范式执行下来产出的就不是一份简单的“字段列表”而是一份交互时序协议文档里面包含状态、事件、条件和转换。登录过程的 challenge-response 逻辑用状态机视角一眼就能看穿。3.3 执行中的关键支点分流、字段聚类、状态假设具体执行层面有几个关键操作值得展开。第一步是分流。PCAP 文件里可能有几十个连接混在一起看只会让模型糊涂。我的技能包强制要求先用 tshark 按五元组分流每个连接单独输出成一个小 PCAP然后逐个分析。命令模板长这样tshark -r login.pcap -q -z conv,tcp # 查看有多少条 TCP 连接 tshark -r login.pcap -Y tcp.stream0 -w stream_0.pcap # 按 stream 索引导出单独连接这里为什么要强制分流因为 AI 模型的注意力窗口有限大量无关流量混在一起会稀释它对关键字段的敏感度。单独分析一个连接模型才能看清请求和响应的对应关系。第二步是字段聚类。对每个包做 hex dump然后按偏移位置统计字节值分布。这个操作的核心目的是找出那些在不同包里保持不变、但语义位置固定的字节它们大概率是类型字段或命令字同时找出那些变化但有规律可循的字节它们大概率是序列号、时间戳或校验和。技能包里内置了一段 Python 代码来做聚类统计结果回填给模型的时候模型就不需要靠猜来判断字段边界了。第三步是状态假设。当模型从交互序列中观察到“连接建立后的第一个包总是以 0x01 开头第二个包总是以 0x02 开头”技能包会要求它输出一个临时状态表把观测到的模式映射成状态假设然后为了验证假设去 PCAP 里搜索违反该模式的反例。如果找到反例就修正状态表找不到再把状态表写进最终报告。这三步操作是这套技能包的灵魂。分流保证上下文干净聚类保证字段判断有据状态假设保证协议逻辑可以被验证。每一步都有命令产出每一步的产出都留痕。3.4 产物沉淀签名文件与分析报告任务收尾时技能包会强制输出两类产物。一类是机器可读的签名文件用 YAML 格式描述协议的消息类型、字段偏移、字段长度、状态转换条件另一类是面向工程师的分析报告描述分析过程、工具命令、证据链和未决问题。签名文件的价值在于可复用。下次再遇到同一个设备的其他接口就不用重新分析了直接把签名文件丢给模型作为先验知识。我在技能包里特意设计了一个“签名文件加载”入口允许用户在任务描述里附带已有的签名文件路由层会把它们作为上下文注入到技能执行前。这个设计上的小细节在实际使用中带来了非常大的效率提升——协议逆向不是一次性工作它是一系列相关任务的起点。分析报告的价值在于可审计。模型在哪个环节下了什么结论、依据是什么、还有哪些没验证全部写清楚。这一点在代码评审、合规审查和团队协作里尤其重要不然 AI 给了一个错误结论你根本没法追查它错在哪个环节。4. 搭建与调优把 reverse-skill 配置进你的 AI 编码客户端4.1 目录结构技能包在文件系统里长什么样这部分讲怎么落盘。reverse-skill 不是一个独立程序它是一套有结构的文件AI 编码客户端通过约定好的路径加载。我的项目里目录结构是这样的reverse-skill/ ├── router/ │ ├── intent_words.yaml # 任务意图粗筛关键词 │ ├── skill_index.yaml # 技能索引与语义描述 │ └── match_model/ # 轻量 embedding 匹配模型 ├── skills/ │ ├── binary_format/ │ │ ├── SOP.md # 技能流程描述 │ │ ├── tool_whitelist.yaml # 允许调用的工具 │ │ └── report_schema.yaml # 报告输出格式 │ ├── protocol_reverse/ │ │ ├── SOP.md │ │ ├── tool_whitelist.yaml │ │ └── report_schema.yaml │ ├── crypto_id/ │ │ ├── SOP.md │ │ └── tool_whitelist.yaml │ ├── crash_diagnosis/ │ │ └── ... │ └── patch_gen/ │ └── ... ├── tools/ │ ├── templates/ # 命令模板 │ └── scripts/ # 字段聚类等内置脚本 └── context/ ├── scope_note.md # 安全与合规边界说明 └── glossary.md # 逆向工程术语表这个结构的核心设计原则是“把描述和工具分离”。SOP.md 描述流程tool_whitelist.yaml 限定工具report_schema.yaml 定义产物格式。三者各司其职修改流程时不需要动工具配置反过来也一样。如果你是第一次搭建我建议先别贪多。把binary_format和protocol_reverse两个技能模块做扎实足够覆盖 80% 的日常逆向需求。等跑顺了再逐步加crypto_id和patch_gen否则调试路由规则时会很痛苦。4.2 加载方式不同客户端怎么挂载不同 AI 编码客户端加载外部技能包的方式不太一样。以我实测过的几个为例客户端加载机制注意事项Claude CodeCLAUDE.md 引用外部文件需要把路由规则写在项目级 CLAUDE.md 中Cline.clinerules 或 Skills 插件方式可以加载本地目录适合复杂技能包Continue自定义命令和上下文文件适合按任务手动触发Codex CLI启动时的 instruction 文件通过 prompt 附带技能包内容不管你用哪个客户端核心思路都是项目启动时把 router 层的核心路由规则和当前任务命中的技能 SOP 注入到上下文中。注意不要全量注入整个技能包我见过有人把几百 K 的技能描述一股脑塞给模型结果还没开始干活上下文就挤爆了后续一点有效推理都做不出来。正确做法是两段式加载。客户端的指令文件里只放路由规则的最小子集通常是关键词表和技能索引等路由层判定任务类型后再把对应技能的 SOP.md 和 tool_whitelist.yaml 作为工具调用结果活加载进来。这样上下文占用最小且在任务中途切换技能时不会污染前面的推理。4.3 调优的三个常见问题与我的处理方式问题一路由判断错了模型用二进制格式分析的方法去解协议还原任务。这个最烦人。我的经验是关键词粗筛的优先级不要设太高语义打分比重可以适当加大。因为用户描述任务时经常用很口语化的话比如“这个流量里的魔法数字是什么”这里根本没有“协议”两个字靠关键词必挂但 embedding 匹配能捕捉到“流量”和“协议分析”之间的语义关系。我调优时是让每个子技能手写了 15~20 条典型请求作为语料然后用这些语料微调打分权重。问题二技能执行到一半模型把任务完成了但产物报告格式不对。这种情况多半是报告约束写得不够具体。我在 report_schema.yaml 里不只是写字段名而是给每个字段写了填充示例和反例。比如“已验证的结论”这一字段我给的反例是“可能有字段 A”正例是“0x02 在偏移 0x12长度 2 字节取值 0x0A~0x14对应挑战码”。强约束让模型输出规范化后续自动化分析这些报告时才不会解析失败。问题三模型在过程中自作主张加入训练数据里见过的协议规则。比如分析一个私有协议时模型突然说“这个字段类似 HTTP 的 Content-Length所以它表示长度”。这个话术很危险。我的处理方式是在 SOP.md 里写死一条规则所有从数据中观察到的结论必须标注对应的偏移和样本数量从外部经验类推的结论只能放在“待确认项”里绝不能和观测结论混在一起。这条规则救了我很多次。4.4 按行业场景裁剪技能包最后聊聊扩展。reverse-skill 的默认技能覆盖的是通用逆向场景但实际使用中不同行业的需求差异很大我建议按下面几个方向裁剪。Web 前端方向的团队可以重点强化binary_format里对 JS 混淆代码和 source map 的分析子技能并且在工具白名单里加入 js-beautify、JStillery 这类工具。嵌入式方向crypto_id和crash_diagnosis的优先级更高因为固件分析经常要面对启动流程中的校验算法和硬件异常定位。移动端方向需要额外挂一个 APK/DEX 结构分析的子技能默认技能包里没覆盖到要自己补。裁剪时有一个我反复强调的原则保留验证节点不要为了速度删掉强制验证步骤。你可以减少技能模块的数量但不要压缩单个技能内部的 SOP 流水线。一旦你跳过“熵值分析”或“聚类统计”这种验证节点模型就会回到光学猜测的老路上去。验证节点是整个技能包和普通 prompt 的唯一本质区别删了就一文不值。另外context/scope_note.md这个文件别删。它写的是这套技能包适用的合法边界解析自己拥有或有权分析的协议与文件格式、调试自有程序、兼容性研究以及对已公开信息的技术分析。它不仅是合规保障还会在模型即将越过边界时触发自动拦截回退。我在 scope_note 里写了几条硬规则比如“不允许分析未授权获取的通信内容”“不允许生成用于绕过程序保护措施的代码”模型在上下文里读到这些规则会主动拒绝越界请求这比事后人工审查省心得多。5. 实践中的踩坑记录与技术边界5.1 工具调用失控模型输出命令但忘了保存结果我遇到最多次的坑是命令执行和结果回传的断链。在大多数 AI 编码客户端里模型是“先生成命令字符串再调用工具执行”执行完的结果会追加到上下文。但问题是模型经常生成形如xxd file.bin | head -50的命令把结果直接输出到终端而不是保存成文件。这个习惯在普通开发任务里问题不大但在逆向分析里很致命。因为逆向分析经常要拿多个工具的输出做交叉验证比如对比file的识别结果、strings的提取结果和ent的熵值结果如果每次都是临时打印模型在后续推理时只能看到截断的输出关键信息很容易丢。我的解决方式是在工具模板层把“必须保存到文件”写死。比如字符串提取的模板是strings -n 6 -t x file.bin strings_analysis.txt wc -l strings_analysis.txt并且 SOP 里规定每个工具执行后模型必须引用它保存的文件名不能在上下文里贴大段输出。这个习惯一旦养成整个分析过程的可复现性会大幅提升。5.2 上下文污染多技能并发执行时的推理退化另一个坑出现在任务复杂度较高的时候。比如“解析这个文件格式再写一个解析器最后验证解析器正确性”这种多技能任务如果路由层把所有技能的 SOP 一次性注入模型很容易发生上下文污染——它会把二进制分析技能里的术语用到解析器编写里或者把网络协议分析的模板带到文件解析里推理质量明显退化。我的应对策略是引入“任务分段”机制。路由层不只是选技能还会把长任务拆成多个子任务子任务之间用结构化接口传递信息而不是共享全部上下文。以刚才那个任务为例路由层会拆成三段第一段走binary_format技能产物是协议签名文件第二段走patch_gen技能输入是签名文件而不是原始二进制第三段走crash_diagnosis技能验证解析器在异常输入上的表现。每一段的上下文边界都很清晰模型不会被无关信息干扰。这种分段设计的代价是任务耗时变长因为每个子任务都要重新加载上下文。但逆向工程本来就慢工出细活与其让模型在混乱上下文里快速给出错误答案不如按阶段推进宁可多花几轮调用也要保证每一步结论可信。5.3 技术边界什么场景 reverse-skill 也救不了必须诚实地讲技能包不是万能的。有两类场景我测试下来效果依然不理想。第一类是强混淆场景比如代码被高强度的控制流平坦化处理过或者数据经过了未知的多次变换。这种情况下工具链能提供的观测信息极其有限模型缺乏足够的“证据”来形成假设技能包再完善也只能输出“无法判断”。第二类是极度依赖运行时状态的任务。比如要分析一个漏洞利用链的完整触发条件这不仅涉及静态结构还涉及堆布局、异步时序、平台版本行为等动态因素。仅靠技能包里的静态分析工具集根本无法捕获这些运行时信息。要解决这个问题需要的是把调试器、符号执行引擎也接入工具层而这一块我目前的实现还比较初步。如果你有这方面的实践欢迎交流。6. 一些简化思路让技能包从“能用”到“好用”6.1 从“记录流程”到“积累语料”技能包做到能跑只是第一步真正让它好用的是语料的持续积累。每次任务完成后把成功和失败的案例按技能类型归档定期把失败案例中的错误输出做成“反例”追加到对应技能的 SOP 描述里。比如我发现模型在“字段聚类”这个步骤上经常把 4 字节对齐的整数错看成两个 2 字节整数就特意在binary_format/SOP.md里加了一段反例说明附上真实的 hex dump 对比。之后同类型任务出错率明显下降。这个过程其实是把人的实践经验持续转化为模型的训练数据只不过是通过提示词工程实现的不需要微调模型。6.2 路由规则的自动化回归测试路由层是技能包的门面但它也是最容易出问题的环节。我建议写一个简单的回归测试脚本每次修改路由规则后自动跑一遍历史任务集检查每个任务是否被路由到了预期技能。这个脚本本身不复杂本质上就是模拟用户请求、对比路由输出和期望值。我都把它放在tests/目录下改完规则先跑回归再手动验证两个新任务基本能防住绝大多数路由退化。路由规则如果做复杂了还有个容易踩的坑是“过度路由”——本来一个任务用通用分析能力就够了非要用特殊技能。我的判断标准是如果任务没有明确提到任何逆向相关对象二进制、协议、崩溃文件路由层就应该直接拒绝路由返回用户“这个任务不在 reverse-skill 处理范围内”。这个“拒绝路由”的设计看着不起眼实际能省下大量无意义的上下文开销。6.3 技能包开源化的个人建议最后聊聊把这套东西开源时的注意事项。逆向工程技能包和普通代码库不一样它里面包含大量方法论的编排细节而方法论本身又带有边界意识。我在整理开源版本时刻意把scope_note.md放在了最高优先级的位置目的就是让人在使用时第一时间看到边界。代码层面建议把工具层的脚本和路由层的配置文件分开维护因为前者的变更频率远低于后者。工具脚本一旦稳定就尽量不再改路由配置则可以根据社区反馈持续迭代。版本管理上可以用 semver主版本号只在技能结构变更时递增新增子技能只需要小版本号变更。这套管理方式是我踩了一圈坑以后总结出来的希望能帮你少走弯路。技术上我建议把“验证节点”当作第一公民来设计。它应该是你这个技能包区别于所有普通 prompt 的最大卖点也是逆向工程这类高不确定性任务能否从 AI 能力中真正受益的分水岭。你在搭建自己的版本时优先考虑的不是增加多少技能而是怎么保证已有技能里的每一步都有验证、有留痕、可回退。能做到这一点这套技能路由包就立住了。