最近在用 AI 做反编译和网络安全相关的学习，陆陆续续踩了一些坑，遂有此文。

我把这个过程叫作“破甲”。这个词听起来多少有点江湖气，不过我的用法很克制，只在自己拥有或者明确获得授权的程序、靶场、协议和测试环境里研究。我的实际需求也很朴素：让模型别看到“反编译”“漏洞”“抓包”几个词就直接结束对话，能够继续参与后面的分析。

目前实践下来，体验好坏主要看前面的上下文有没有搭好。一句神奇提示词撑不起长任务，目标、授权范围、环境和交付物都说不清楚，模型只能把任务往最危险的方向猜。猜完以后拒绝，其实也很正常。

第一步：先把研究模式开对

刚开始时，我会先把研究背景讲清楚，相当于开启一次受约束的安全研究模式。

这里至少要说明几件事：

分析对象是什么，所有权或者授权从哪里来
研究目的是什么，是学习、兼容性分析、漏洞复现，还是恶意代码检测
工作在哪个环境里进行，比如本地副本、CTF、虚拟机或者隔离靶场
哪些动作允许做，哪些动作禁止做
最终需要什么结果，是函数说明、协议文档、风险报告，还是修复建议

这一步看起来有点啰嗦，实际非常省时间。模型知道我们在分析自己的二进制文件，和它以为我们要入侵线上服务，完全是两件事。

我现在不太依赖所谓的“破甲关键词”。关键词偶尔能改变一轮对话的语气，却很难支撑一个长任务。更稳定的做法，还是把边界写成项目约束，让后面的每一步都有东西可以对照。

懒得从零折腾，可以先看 GPT-5.6 Instruct

破甲远没有复制一段提示词那么简单。提示词要迭代，失败案例要收集，模型版本变了还得重新测试，配置写坏以后也要能回滚。真要从头做一套，背后其实有不少脏活累活。

如果用的是 GPT-5.6 和 Codex，可以先看看 MDX-Tom/gpt-5.6-instruct。这个仓库把破甲提示词、版本管理、部署与回滚脚本、测试集和回归验证都整理到了一起，给了一个接近一键式的入口。对于只想先把环境跑起来的人，直接用别人已经反复测试过的方案，肯定比自己临时拼一大段 Prompt 省事。

我更愿意把它当作一个开箱可用的实验包和参考实现。先读 README，再检查脚本会修改哪些 Codex 配置，做好备份，只在自有或明确授权的隔离环境里使用。仓库本身也提示了账号风险，这件事不能装作没看见。一键部署降低的是配置成本，项目边界、证据验证和最终责任仍然得自己扛。

第二步：先搭项目，再开始啃硬骨头

研究模式确认以后，我一般不会马上让 AI 反编译一个大程序，或者直接分析一整段网络流量。我更倾向先让它把项目搭起来。

例如先建立下面这些东西：

README.md：记录目标、授权范围、环境和启动方式
docs/：存放函数说明、协议字段、调用链和阶段结论
samples/：只保存可公开、可授权分析的样本及其哈希
scripts/：放解析、提取、验证用的小工具
reports/：记录风险、证据、复现条件和修复建议

项目骨架出来以后，再让 AI 补文档、统一术语、整理命名，把原本一句很模糊的“帮我逆向这个程序”，拆成若干个可以验证的小任务。

这里说的修饰，重点是把任务说准确，不能靠隐藏真实目的来骗模型。比如“绕过某系统的鉴权”很容易落到越权攻击上；如果我研究的是自己项目里的鉴权缺陷，就应该直接写明测试环境、代码仓库、预期行为和验证边界。上下文越具体，模型越容易干活，我们自己也更容易发现任务有没有跑偏。

讲道理，这一步才是整个流程里最重要的地方。工程结构、日志和文档一旦搭好，后面就算换模型、换会话，甚至换人接手，也不用重新猜前面发生了什么。

第三步：切回正常模型干活

很多所谓的破甲提示会塞入大量角色设定、强制指令和对抗性文本。它们确实可能让模型暂时换一种回答方式，代价也很明显：上下文被污染，推理变慢，工具调用开始发飘，原本聪明的模型像是穿着十层棉袄写代码。

所以项目和边界搭好之后，我会切回正常模型继续工作。

这时候已经有 README、任务拆分、样本来源和研究范围，正常模型可以直接沿着工程上下文推进：阅读反编译结果、还原数据结构、梳理调用链、解释协议字段、分析靶场日志、写检测规则、补测试和整理报告。一次只处理一个可以验证的问题，效果通常比带着一大坨注入提示硬冲好得多。

模型切换之后，速度和推理质量都会回来。更重要的是，正常模型更适合做长期工程任务。它能看项目文件、读日志、跑验证、根据失败结果继续修改，不必每一轮都维护一个摇摇欲坠的角色扮演设定。

我现在常用的任务说明

为了减少来回拉扯，我通常会先给出一份很短的任务说明：

项目背景：这是我拥有并可授权分析的程序，研究在本地隔离环境中进行。

研究目标：理解指定模块的行为，整理数据结构和调用链，并给出安全风险与修复建议。

允许范围：读取项目文件、分析本地样本、运行现有测试、编写辅助解析脚本。

禁止范围：访问第三方真实系统、获取凭据、建立持久化、规避审计或扩大影响范围。

工作方式：先检查现有文档和目录，再拆分任务；每个结论附上文件、日志或测试证据。

交付物：更新 docs 下的分析文档，保留待确认项，不确定的地方不要编造。

这份说明没有什么神秘的地方，胜在稳定。模型知道自己能做什么，我们也知道该拿什么验收。