两个周末，我把手头一台旧电脑变成了半个“逆向搭子”。其实这事说起来没那么玄：我用大模型的能力，接上 jadx、apktool 这些常规反编译工具，搭了一套叫 Antigravity 的分析流水线，让 AI 自己完成解包、读代码、追调用链、出报告。以前我手动拆一个 App，光是把入口类到核心逻辑翻一遍就得两三天，现在这套工作流半天能出一版初始结论，虽然还得人工复核，但省掉的大头不是时间，而是反复翻源码的精力消耗。这篇文章就把整个搭建过程完整复盘一遍：为什么选这套方案、工具怎么接、任务怎么拆、哪些坑我踩过，以及合规边界在哪里。适合正在做安全测试、隐私审计的人，或者想给团队搞一套辅助分析工具的朋友参考。如果你是个新手，按着这些步骤也能复现出来，只是中间有些地方需要多啃几遍。1. 先想清楚：让 AI 学会“拆”App，到底拆什么1.1 传统手动逆向的四个痛点先说逆向分析这件事本身。拿到一个 APK，常规操作是先用反编译工具解包，然后看 AndroidManifest、看 Java/Kotlin 源码、查字符串、追调用关系。听起来流程清晰，实际操作起来全是坑。第一，文件量太大。一个正常大小的 APK 解包后可能有一万个类文件，核心逻辑散落在几百个方法里。靠人肉翻，翻到最后前面看过的早忘了。第二，搜索靠“猜”。你想找某个敏感操作，得先猜关键词，猜到了再一层层点进去看调用来源。第三，记忆负担重。分析到一半，要记住这个函数从哪来、那个数据流到哪去，脑子不够用。第四，报告成本高。分析完还得把结论整理成别人能看懂的文档，又是一个下午。我接过的不少测试单子，很多时间其实耗在“反复找证据”上，而不是“思考”上。于是我开始想，能不能让大模型替我做这些脏活。1.2 Antigravity 的定位：不是单点工具，而是一套指挥系统Antigravity 不是一个 App，也不是某个现成的分析平台，它是我自己搭的一套工作流方案。核心思路很简单：大模型擅长归纳总结、按步骤执行，但它没法直接读取二进制包里的内容，所以我给它装了一堆“手”——也就是能调用的分析工具，再给它一张“图纸”——就是分析流程的编排规则。这么设计的好处是，AI 不再是凭空猜代码逻辑，而是像研究员一样，先查目录、再翻正文、最后做交叉验证。它分析每一步都有据可查，结论后面能挂上证据位置。这个“证据可追溯”对后续人工复核特别重要。1.3 第一版范围：静态为主，动态只做验证搭建 Antigravity 之前，我给自己划了挺清晰的边界——第一版只做静态分析，不做动态插桩和运行时调试。静态分析能覆盖的场景已经很多：组件暴露、敏感权限滥用、硬编码密钥、明文通信、危险函数调用等等。动态部分只用来做结果验证，比如静态分析发现某个方法有异常，再单独到测试环境里确认。后来我把这个边界写进了项目文档里，避免了后面越做越飞。做工具的人最容易犯的毛病就是想一口气全接上，结果反而啥都做不深。如果你也要搭类似的系统，建议第一版先砍掉一半功能，跑通一条主链路再说。2. 方案选型：这套工作流为什么能跑起来2.1 反编译层选型：jadx + apktool，一个看逻辑一个看资源反编译工具我用的是 jadx 和 apktool 的组合。jadx 负责把 APK 的 dex 字节码还原成可读的 Java/Kotlin 源码，输出结构清晰，还自带简单的反混淆效果。这里要特别说明，我选择让 AI 直接读 Java 层源码而不是 smali 字节码，原因很简单：大模型对高级语言的理解能力远强于对字节码的理解，读 Java 源码就能跑通绝大多数分析场景，读 smali 纯属给自己加难度。apktool 这边主要负责资源文件和三方配置，比如 AndroidManifest.xml、assets、res 目录。很多分析线索其实藏在资源里：组件声明、权限申请、软件开发工具包配置、甚至某些被开发者刻意藏起来的文件路径。jadx 有时候对资源处理得没那么全，apktool 正好补上这一块。两个工具输出要做完，代码索引才能建得起来。我在项目里把它们比喻成“一个拆逻辑，一个拆皮囊”，实际配合起来效率提升很明显。2.2 智能体层选型：Function Calling 比 RAG 更适合分析任务在设计 Antigravity 的智能体时，我对比过两种路线：一种是 RAG，就是先把代码向量化、存进知识库，然后让 AI 基于向量检索做问答；另一种是函数调用，让 AI 通过调用工具去实时获取精确的代码片段和类信息。最终我选了 Function Calling。原因很简单，代码分析要的是“精准定位”，不是“语义相似”。你想找一个方法的具体实现，用 RAG 检索返回的可能是一堆长得像但实际无关的函数，而用函数调用直接按类名和方法签名去查，准度完全不同。还有一个附带的优点：函数调用天然带出溯源路径。AI 查了哪个类、读了哪个方法、搜了哪条字符串，这些都能记录下来，形成一条完整的分析轨迹，方便我后面复核。2.3 上下文管理：把大任务切碎，一切围绕“局部聚焦”大模型有个老毛病：上下文窗口有限，喂太多会“失忆”，喂得太碎会“断片”。在逆向分析这种需要长链路推理的任务里，这个问题尤其致命。我的解决办法是“局部聚焦”策略。整个分析过程被拆成若干个小任务，每一步只让 AI 关注当前任务涉及的那几个类或方法。比如分析某个函数的调用来源时，只把当前函数的代码和调用它的父类代码放进去，而不是把整个包都塞给它。分析完一个局部，把结论压缩成结构化摘要存起来，再进入下一个局部。这里有个小技巧：读完一个类后，别急着让 AI 下大结论，先让它输出这个类的“角色描述”，包括它干什么、依赖什么、被谁调用。这些局部判断最后再汇总，比让 AI 一口气分析整个 App 准确得多。2.4 结构化输出：让人能审、AI能接得住如果让 AI 自由发挥写结论，很快你就会发现一个问题：它写的报告华丽但格式五花八门，没法自动审查，也没法跟上游任务衔接。所以我很早就在 Antigravity 里定义了统一的输出协议。每一条分析结论都按固定字段输出：组件名称、类型、风险等级、证据位置、分析详情、置信度。证据位置这一项特别关键，它必须指向实际的文件和代码行号，方便人工点击核对。做了这个约定之后，后面写报告、做统计、人工复核全都轻松了。3. 实操全流程：从 APK 到结构化报告3.1 预处理：解包、建索引，先给 AI 一张“地图”Antigravity 的第一步不是让 AI 开始分析，而是先做预处理。我会先跑aapt dump badging拿到包名和版本号，然后用 apktool 解资源、用 jadx 反编译代码，把所有输出归拢到一个临时工作目录里。接下来是关键：建索引。我会扫一遍所有反编译出来的文件，生成三类索引：类名列表，包括每个类所在的文件路径方法签名列表，提取每个公开方法的名字和参数字符串表，把代码中的字符串常量抽出来，供后续关键词搜索用索引文件我用 JSONL 格式存，一行一条记录，方便按需读取。这一步做完，AI 手里就有了一张“地图”，想查什么直接按图索骥，不用我临时翻文件系统。3.2 编写工具描述：让 AI 知道自己的“工具箱”有了地图，接下来要把“地图”开放给 AI。我在智能体里定义了十几个函数调用接口，每个接口都配了详细的自然语言描述。描述写得好不好，直接决定 AI 用工具的准确率，这块绝对不能偷懒。拿“全局搜索字符串”这个功能举例，我给 AI 的接口说明大概是这个意思：这是一个在全部代码中按关键词搜索字符串的工具，适合在定位敏感操作、硬编码密钥、可疑 URL 时使用，输入参数是关键词和搜索范围，返回结果是匹配的文件路径和所在代码段。如果一次返回太多结果，AI 会自动缩小范围继续搜。这里踩过一个坑：工具描述写得太干巴，只写“搜索字符串”四个字，AI 根本不知道什么时候该用、用错了怎么办。后来我在每个描述里都加上了使用场景、参数含义、返回格式和常见误用提醒，准确率立刻上去了。3.3 设计分析 SOP：三层走查法工具就位后，真正的核心是任务编排。Antigravity 的分析流程我起名叫“三层走查法”，每一层解决一个阶段的问题。第一层叫“入口侦察”。 AI 先读取 AndroidManifest.xml，枚举出 MainActivity、Service、Receiver、ContentProvider 等组件，形成一张“入口清单”。这一步的目的是搞清楚 App 的暴露面在哪里，下一步重点看哪里。第二层叫“关键面扫描”。 基于入口清单，AI 开始对权限列表、敏感 API 调用、可疑字符串做大范围扫描。搜索关键词我维护了一个比较干净的清单，包括常见加密算法名、网络请求关键字、文件读写相关、反射调用等。这一步的输出是一批“疑似风险点”。第三层叫“调用链追踪”。 针对上一步的每个疑似点，AI 会反向追查它的调用来源，从哪个方法发起、数据从哪里来、最终流到哪。这一步最容易暴露问题，很多风险点只有在调用链上才能判断是刻意设计还是无意识引入。三层走查完后，AI 把所有局部结论汇总，按预设模板生成分析报告。3.4 跑一个真实例子：模拟项目X的完整过程理论讲了这么多，实际跑一遍最有说服力。我拿一个内部测试用的模拟项目 X 做了完整演示，这个项目本身自带几个典型问题，适合用来验证 Antigravity 的效果。第一层入口侦察阶段，AI 花了不到一分钟就枚举出 3 个 Activity、2 个 Service、1 个 Receiver，还自动标注了哪些组件是导出的。第二层扫描阶段，它定位到 7 处敏感字符串，其中包括一组疑似硬编码密钥和两个看起来像后台服务地址的 URL。第三层调用链追踪阶段，它把其中一个密钥的使用链路完整串了出来——从 MainActivity 读取密钥、传入某某工具类、最后用于本地加密文件。整个流程跑下来四十多分钟，中间我基本没插手。对照我手动分析的结果，漏检了一个低危项，其余结论基本一致。最关键的是，所有结论都带证据位置，我能直接点击到具体代码行验证真伪。这个“可核验”能力，才是 Antigravity 真正的价值。3.5 报告模板与人工复核环节报告生成这步，我做了个固定模板，分成几块：资产概览、风险清单、调用链说明、结论与建议。风险清单按高危、中危、低危排列，每一项都带证据位置和置信度。置信度低于某个阈值的条目，模板里会明确标注“需要人工确认”，不会让 AI 强行下结论。人工复核我习惯这么干：拿报告里的每个证据位置，在 jadx 里直接跳到代码现场看一遍。高危项一定全核，中低危项按比例抽核。这半小时的功夫不能省，因为 AI 再强也有幻觉，尤其是调用链判断这种需要长链路推理的场景，人工兜底是最后一道防线。4. 常见问题与排查技巧实录4.1 上下文窗口被冲爆的问题最早跑 Antigravity 时，最常见的故障就是上下文溢出。AI 在分析一个大型混淆过的类时，我为了让“理解更完整”，把整个类文件几千行代码直接丢给它，结果一次任务还没跑完就报错。后来我加了两个约束：一是单次读取代码片段的最大行数，超过阈值先让 AI 生成摘要、再决定要不要继续读全文；二是强制任务分片，每完成一个局部任务就清空一段上下文，只保留结构化摘要。这一改，上下文溢出问题基本绝迹。4.2 工具调用失败的几个坑工具调用失败主要集中在三类：参数格式不对、索引缺字段、apktool/jadx 输出异常。参数格式问题最好解决，在工具描述里加上“示例调用”就能减少大半；索引缺字段是前期设计问题，后来我在生成索引时统一校验必填字段，缺了当场报错，不会等到 AI 调用时才发现。jadx 偶尔会在解包超大 APK 时卡死，我在调度层加了超时重试和单文件拆分机制，把单个 dex 拆小再反编译，基本能跑过关。4.3 误判与漏判：处理方式和校准方法AI 误判这事，最有代表性的就是“看着像风险其实不是”。比如一个检测 root 环境的方法，本质是风控逻辑，却被 AI 归为危险 API。问题出在判断标准太死板，只看调用了什么 API，不看调用意图。我加了“意图判定”步骤：每个敏感调用都要先回答三个问题——调用方是谁、触发条件是什么、数据用途是什么。只有三个问题都指向恶意或异常，才定级为风险点。校准方面，我在项目里保留了一个小小的测试集，里面提前标好了正确答案，每次改动流程都会拿测试集跑一遍，确保误报率不会因为调整而失控。4.4 安全底线：授权范围与数据隔离这一点我没有写在文档里显眼位置，执行的严格程度一点都不亚于技术方案。Antigravity 只处理两类样本：自己开发的应用、客户委托并明确书面授权的应用。分析过程保持在本地环境，代码不会自动上传到第三方接口，能用本地小模型处理的部分尽量在本地跑。更重要的是，Antigravity 的能力边界是“识别和解释”，不是“利用和绕过”。它能告诉你哪里可能有风险，但不会给你生成攻击代码，也不会教你如何利用漏洞。这个边界从一开始就写在系统提示词里，宁可漏报，也不越线。5. 扩展方向与个人体会5.1 如果继续做，我会先加动态验证Antigravity 目前是纯静态方案，静态分析的天然局限在于“看起来有问题”未必“跑起来有问题”。我下一步想做的，是加一层轻量的动态验证：把静态分析找到的疑似点，在隔离测试环境里做运行时确认。重点只验证结论，不写利用逻辑，避免越界。5.2 把“经验”沉淀成知识库跑了几轮项目后我发现，AI 每次分析都会重新“发明一遍轮子”——同样的模式它可能这次判断高风险、下次判断低风险。我打算把已经确认过的分析模式沉淀成规则包，作为内置知识提前喂给 AI，减少随机性。5.3 给新手的几点建议如果你也想搭一套类似的东西，我的建议很简单：先手动拆一个小 App，把所有流程走通，再动手写自动化。连手动分析都没做过，上来就搭 AI 工作流，最后八成是在调 prompt 而不是在理解问题。个人实际体会是，工具是用来放大分析能力的，不是替代分析能力的。AI 能帮我们从一万个类里找出十个可疑点，但判断这个点是不是真的有问题、问题有多严重，最终还得靠人的脑子，以及守住的那条底线。
两个周末，我把手头一台旧电脑变成了半个“逆向搭子”。其实这事说起来没那么玄：我用大模型的能力，接上 jadx、apktool 这些常规反编译工具，搭了一套叫 Antigravity 的分析流水线，让 AI 自己完成解包、读代码、追调用链、出报告。以前我手动拆一个 App，光是把入口类到核心逻辑翻一遍就得两三天，现在这套工作流半天能出一版初始结论，虽然还得人工复核，但省掉的大头不是时间，而是反复翻源码的精力消耗。这篇文章就把整个搭建过程完整复盘一遍：为什么选这套方案、工具怎么接、任务怎么拆、哪些坑我踩过，以及合规边界在哪里。适合正在做安全测试、隐私审计的人，或者想给团队搞一套辅助分析工具的朋友参考。如果你是个新手，按着这些步骤也能复现出来，只是中间有些地方需要多啃几遍。1. 先想清楚：让 AI 学会“拆”App，到底拆什么1.1 传统手动逆向的四个痛点先说逆向分析这件事本身。拿到一个 APK，常规操作是先用反编译工具解包，然后看 AndroidManifest、看 Java/Kotlin 源码、查字符串、追调用关系。听起来流程清晰，实际操作起来全是坑。第一，文件量太大。一个正常大小的 APK 解包后可能有一万个类文件，核心逻辑散落在几百个方法里。靠人肉翻，翻到最后前面看过的早忘了。第二，搜索靠“猜”。你想找某个敏感操作，得先猜关键词，猜到了再一层层点进去看调用来源。第三，记忆负担重。分析到一半，要记住这个函数从哪来、那个数据流到哪去，脑子不够用。第四，报告成本高。分析完还得把结论整理成别人能看懂的文档，又是一个下午。我接过的不少测试单子，很多时间其实耗在“反复找证据”上，而不是“思考”上。于是我开始想，能不能让大模型替我做这些脏活。1.2 Antigravity 的定位：不是单点工具，而是一套指挥系统Antigravity 不是一个 App，也不是某个现成的分析平台，它是我自己搭的一套工作流方案。核心思路很简单：大模型擅长归纳总结、按步骤执行，但它没法直接读取二进制包里的内容，所以我给它装了一堆“手”——也就是能调用的分析工具，再给它一张“图纸”——就是分析流程的编排规则。这么设计的好处是，AI 不再是凭空猜代码逻辑，而是像研究员一样，先查目录、再翻正文、最后做交叉验证。它分析每一步都有据可查，结论后面能挂上证据位置。这个“证据可追溯”对后续人工复核特别重要。1.3 第一版范围：静态为主，动态只做验证搭建 Antigravity 之前，我给自己划了挺清晰的边界——第一版只做静态分析，不做动态插桩和运行时调试。静态分析能覆盖的场景已经很多：组件暴露、敏感权限滥用、硬编码密钥、明文通信、危险函数调用等等。动态部分只用来做结果验证，比如静态分析发现某个方法有异常，再单独到测试环境里确认。后来我把这个边界写进了项目文档里，避免了后面越做越飞。做工具的人最容易犯的毛病就是想一口气全接上，结果反而啥都做不深。如果你也要搭类似的系统，建议第一版先砍掉一半功能，跑通一条主链路再说。2. 方案选型：这套工作流为什么能跑起来2.1 反编译层选型：jadx + apktool，一个看逻辑一个看资源反编译工具我用的是 jadx 和 apktool 的组合。jadx 负责把 APK 的 dex 字节码还原成可读的 Java/Kotlin 源码，输出结构清晰，还自带简单的反混淆效果。这里要特别说明，我选择让 AI 直接读 Java 层源码而不是 smali 字节码，原因很简单：大模型对高级语言的理解能力远强于对字节码的理解，读 Java 源码就能跑通绝大多数分析场景，读 smali 纯属给自己加难度。apktool 这边主要负责资源文件和三方配置，比如 AndroidManifest.xml、assets、res 目录。很多分析线索其实藏在资源里：组件声明、权限申请、软件开发工具包配置、甚至某些被开发者刻意藏起来的文件路径。jadx 有时候对资源处理得没那么全，apktool 正好补上这一块。两个工具输出要做完，代码索引才能建得起来。我在项目里把它们比喻成“一个拆逻辑，一个拆皮囊”，实际配合起来效率提升很明显。2.2 智能体层选型：Function Calling 比 RAG 更适合分析任务在设计 Antigravity 的智能体时，我对比过两种路线：一种是 RAG，就是先把代码向量化、存进知识库，然后让 AI 基于向量检索做问答；另一种是函数调用，让 AI 通过调用工具去实时获取精确的代码片段和类信息。最终我选了 Function Calling。原因很简单，代码分析要的是“精准定位”，不是“语义相似”。你想找一个方法的具体实现，用 RAG 检索返回的可能是一堆长得像但实际无关的函数，而用函数调用直接按类名和方法签名去查，准度完全不同。还有一个附带的优点：函数调用天然带出溯源路径。AI 查了哪个类、读了哪个方法、搜了哪条字符串，这些都能记录下来，形成一条完整的分析轨迹，方便我后面复核。2.3 上下文管理：把大任务切碎，一切围绕“局部聚焦”大模型有个老毛病：上下文窗口有限，喂太多会“失忆”，喂得太碎会“断片”。在逆向分析这种需要长链路推理的任务里，这个问题尤其致命。我的解决办法是“局部聚焦”策略。整个分析过程被拆成若干个小任务，每一步只让 AI 关注当前任务涉及的那几个类或方法。比如分析某个函数的调用来源时，只把当前函数的代码和调用它的父类代码放进去，而不是把整个包都塞给它。分析完一个局部，把结论压缩成结构化摘要存起来，再进入下一个局部。这里有个小技巧：读完一个类后，别急着让 AI 下大结论，先让它输出这个类的“角色描述”，包括它干什么、依赖什么、被谁调用。这些局部判断最后再汇总，比让 AI 一口气分析整个 App 准确得多。2.4 结构化输出：让人能审、AI能接得住如果让 AI 自由发挥写结论，很快你就会发现一个问题：它写的报告华丽但格式五花八门，没法自动审查，也没法跟上游任务衔接。所以我很早就在 Antigravity 里定义了统一的输出协议。每一条分析结论都按固定字段输出：组件名称、类型、风险等级、证据位置、分析详情、置信度。证据位置这一项特别关键，它必须指向实际的文件和代码行号，方便人工点击核对。做了这个约定之后，后面写报告、做统计、人工复核全都轻松了。3. 实操全流程：从 APK 到结构化报告3.1 预处理：解包、建索引，先给 AI 一张“地图”Antigravity 的第一步不是让 AI 开始分析，而是先做预处理。我会先跑aapt dump badging拿到包名和版本号，然后用 apktool 解资源、用 jadx 反编译代码，把所有输出归拢到一个临时工作目录里。接下来是关键：建索引。我会扫一遍所有反编译出来的文件，生成三类索引：类名列表，包括每个类所在的文件路径方法签名列表，提取每个公开方法的名字和参数字符串表，把代码中的字符串常量抽出来，供后续关键词搜索用索引文件我用 JSONL 格式存，一行一条记录，方便按需读取。这一步做完，AI 手里就有了一张“地图”，想查什么直接按图索骥，不用我临时翻文件系统。3.2 编写工具描述：让 AI 知道自己的“工具箱”有了地图，接下来要把“地图”开放给 AI。我在智能体里定义了十几个函数调用接口，每个接口都配了详细的自然语言描述。描述写得好不好，直接决定 AI 用工具的准确率，这块绝对不能偷懒。拿“全局搜索字符串”这个功能举例，我给 AI 的接口说明大概是这个意思：这是一个在全部代码中按关键词搜索字符串的工具，适合在定位敏感操作、硬编码密钥、可疑 URL 时使用，输入参数是关键词和搜索范围，返回结果是匹配的文件路径和所在代码段。如果一次返回太多结果，AI 会自动缩小范围继续搜。这里踩过一个坑：工具描述写得太干巴，只写“搜索字符串”四个字，AI 根本不知道什么时候该用、用错了怎么办。后来我在每个描述里都加上了使用场景、参数含义、返回格式和常见误用提醒，准确率立刻上去了。3.3 设计分析 SOP：三层走查法工具就位后，真正的核心是任务编排。Antigravity 的分析流程我起名叫“三层走查法”，每一层解决一个阶段的问题。第一层叫“入口侦察”。 AI 先读取 AndroidManifest.xml，枚举出 MainActivity、Service、Receiver、ContentProvider 等组件，形成一张“入口清单”。这一步的目的是搞清楚 App 的暴露面在哪里，下一步重点看哪里。第二层叫“关键面扫描”。 基于入口清单，AI 开始对权限列表、敏感 API 调用、可疑字符串做大范围扫描。搜索关键词我维护了一个比较干净的清单，包括常见加密算法名、网络请求关键字、文件读写相关、反射调用等。这一步的输出是一批“疑似风险点”。第三层叫“调用链追踪”。 针对上一步的每个疑似点，AI 会反向追查它的调用来源，从哪个方法发起、数据从哪里来、最终流到哪。这一步最容易暴露问题，很多风险点只有在调用链上才能判断是刻意设计还是无意识引入。三层走查完后，AI 把所有局部结论汇总，按预设模板生成分析报告。3.4 跑一个真实例子：模拟项目X的完整过程理论讲了这么多，实际跑一遍最有说服力。我拿一个内部测试用的模拟项目 X 做了完整演示，这个项目本身自带几个典型问题，适合用来验证 Antigravity 的效果。第一层入口侦察阶段，AI 花了不到一分钟就枚举出 3 个 Activity、2 个 Service、1 个 Receiver，还自动标注了哪些组件是导出的。第二层扫描阶段，它定位到 7 处敏感字符串，其中包括一组疑似硬编码密钥和两个看起来像后台服务地址的 URL。第三层调用链追踪阶段，它把其中一个密钥的使用链路完整串了出来——从 MainActivity 读取密钥、传入某某工具类、最后用于本地加密文件。整个流程跑下来四十多分钟，中间我基本没插手。对照我手动分析的结果，漏检了一个低危项，其余结论基本一致。最关键的是，所有结论都带证据位置，我能直接点击到具体代码行验证真伪。这个“可核验”能力，才是 Antigravity 真正的价值。3.5 报告模板与人工复核环节报告生成这步，我做了个固定模板，分成几块：资产概览、风险清单、调用链说明、结论与建议。风险清单按高危、中危、低危排列，每一项都带证据位置和置信度。置信度低于某个阈值的条目，模板里会明确标注“需要人工确认”，不会让 AI 强行下结论。人工复核我习惯这么干：拿报告里的每个证据位置，在 jadx 里直接跳到代码现场看一遍。高危项一定全核，中低危项按比例抽核。这半小时的功夫不能省，因为 AI 再强也有幻觉，尤其是调用链判断这种需要长链路推理的场景，人工兜底是最后一道防线。4. 常见问题与排查技巧实录4.1 上下文窗口被冲爆的问题最早跑 Antigravity 时，最常见的故障就是上下文溢出。AI 在分析一个大型混淆过的类时，我为了让“理解更完整”，把整个类文件几千行代码直接丢给它，结果一次任务还没跑完就报错。后来我加了两个约束：一是单次读取代码片段的最大行数，超过阈值先让 AI 生成摘要、再决定要不要继续读全文；二是强制任务分片，每完成一个局部任务就清空一段上下文，只保留结构化摘要。这一改，上下文溢出问题基本绝迹。4.2 工具调用失败的几个坑工具调用失败主要集中在三类：参数格式不对、索引缺字段、apktool/jadx 输出异常。参数格式问题最好解决，在工具描述里加上“示例调用”就能减少大半；索引缺字段是前期设计问题，后来我在生成索引时统一校验必填字段，缺了当场报错，不会等到 AI 调用时才发现。jadx 偶尔会在解包超大 APK 时卡死，我在调度层加了超时重试和单文件拆分机制，把单个 dex 拆小再反编译，基本能跑过关。4.3 误判与漏判：处理方式和校准方法AI 误判这事，最有代表性的就是“看着像风险其实不是”。比如一个检测 root 环境的方法，本质是风控逻辑，却被 AI 归为危险 API。问题出在判断标准太死板，只看调用了什么 API，不看调用意图。我加了“意图判定”步骤：每个敏感调用都要先回答三个问题——调用方是谁、触发条件是什么、数据用途是什么。只有三个问题都指向恶意或异常，才定级为风险点。校准方面，我在项目里保留了一个小小的测试集，里面提前标好了正确答案，每次改动流程都会拿测试集跑一遍，确保误报率不会因为调整而失控。4.4 安全底线：授权范围与数据隔离这一点我没有写在文档里显眼位置，执行的严格程度一点都不亚于技术方案。Antigravity 只处理两类样本：自己开发的应用、客户委托并明确书面授权的应用。分析过程保持在本地环境，代码不会自动上传到第三方接口，能用本地小模型处理的部分尽量在本地跑。更重要的是，Antigravity 的能力边界是“识别和解释”，不是“利用和绕过”。它能告诉你哪里可能有风险，但不会给你生成攻击代码，也不会教你如何利用漏洞。这个边界从一开始就写在系统提示词里，宁可漏报，也不越线。5. 扩展方向与个人体会5.1 如果继续做，我会先加动态验证Antigravity 目前是纯静态方案，静态分析的天然局限在于“看起来有问题”未必“跑起来有问题”。我下一步想做的，是加一层轻量的动态验证：把静态分析找到的疑似点，在隔离测试环境里做运行时确认。重点只验证结论，不写利用逻辑，避免越界。5.2 把“经验”沉淀成知识库跑了几轮项目后我发现，AI 每次分析都会重新“发明一遍轮子”——同样的模式它可能这次判断高风险、下次判断低风险。我打算把已经确认过的分析模式沉淀成规则包，作为内置知识提前喂给 AI，减少随机性。5.3 给新手的几点建议如果你也想搭一套类似的东西，我的建议很简单：先手动拆一个小 App，把所有流程走通，再动手写自动化。连手动分析都没做过，上来就搭 AI 工作流，最后八成是在调 prompt 而不是在理解问题。个人实际体会是，工具是用来放大分析能力的，不是替代分析能力的。AI 能帮我们从一万个类里找出十个可疑点，但判断这个点是不是真的有问题、问题有多严重，最终还得靠人的脑子，以及守住的那条底线。