提到 AI 逆向很多人第一反应是让 AI 帮助还原小程序代码、提取接口签名、绕过校验。但在真实工程里逆向分析最常见的瓶颈并不是读不懂源码而是代码依赖的运行环境在本地完全建不起来。OpenCode 这类终端 AI 编码工具出现后补环境这件事从“逐行阅读源码、手动猜 window 和 navigator 怎么补齐”变成了可以交给模型辅助分析的工程化操作。这篇内容会围绕“AI 逆向 OpenCode 补环境 小程序场景”展开。先说明哪些操作可以做、哪些不能做然后从 OpenCode 的安装和项目配置讲起再通过一个最小前端模块演示如何识别缺失环境、用原型链补环境、跑通自动化验证。示例代码的目的是理解程序行为和搭建环境模拟层对于任何未授权的小程序不建议也没有必要做完整逆向。关于标题里提到的瑞幸小程序需要先划一条边界商业线上应用在没有授权的情况下不应该做解包、数据采集、提取签名、读取用户数据等操作。想要练手时最稳妥的方式是用自己的小程序测试包或选择开源、明确允许安全分析的 Demo。下面所有代码都按这个前提设计。1. 先搞清 AI 补环境到底补的是什么1.1 逆向不是目的理解程序运行机制才是在开发和安全测试中逆向分析是理解程序行为的手段。比如一个旧前端项目没有文档连哪些全局变量被引用都不知道这时需要分析代码、定位依赖、构造运行环境。这类工作不需要“破解”任何东西只需要把程序放到一个可运行的环境里观察它的输入输出。AI 工具在这个环节的价值是快速建立代码地图。把项目目录丢给 OpenCode模型会先扫描文件、识别入口、找出外部依赖和全局变量再按指令生成修复或兼容代码。相比逐行读源码这种工作方式把“理解程序”的效率提升了很多。换个角度讲逆向分析更接近“代码考古”。你需要从运行结果反推模块结构从报错信息反推环境依赖从接口调用反推数据流。AI 擅长的是快速扫描和模式匹配真正决定分析质量的仍然是开发者对运行机制的理解。1.2 补环境就是给程序一个可以运行的家小程序代码通常运行在微信提供的容器里容器里有wx、Page、getApp等全局对象。代码一旦拿到 Node.js 或浏览器里执行这些对象就消失了。补环境就是在目标运行时中补齐这些缺失的全局对象和 API让代码能继续执行。这里要区分两种补环境兼容层补环境为代码提供假的window、navigator、wx等对象目的是让业务逻辑可以在本地测试或自动化验证中运行。对抗性补环境通过伪造完整浏览器环境数据让程序以为自己仍在原始容器中运行从而规避服务端或客户端的检测。本文只讨论前者。对抗性补环境经常涉及安全检测规避不建议也不会在合规场景里展开。补环境能力本身是中性的用在测试、兼容性分析、自动化脚本里是正向价值用在绕过校验上就是另一回事。1.3 合规边界先确认自己有没有权限把“能不能做”的判断放在“怎么做”之前。下面的表给出常见场景的边界。场景建议说明分析自己开发的代码可以做自己写的业务逻辑本地补环境能帮助测试分析授权测试的小程序需要书面授权安全测试必须先确认授权范围分析开源 Demo按开源协议执行保留来源声明不用于非法用途分析未授权的第三方商业应用不要做解包、数据采集、提取签名等都有合规风险提取用户信息、绕过支付、篡改数据绝对不要做属于违法或违反平台规则的行为很多开发者对“补环境”产生兴趣是因为想复现某个网页或小程序里的加密逻辑。这个目标本身没有错但一定要选对练习对象。用自己搭的测试项目练习既能理解原理又不会触碰安全红线。2. 为什么选 OpenCode 作为补环境辅助工具2.1 OpenCode 是什么OpenCode 是一款可以运行在终端里的 AI 编码代理它的定位不是“聊天机器人”而是“能读取项目文件、执行命令、生成文件并持续维护上下文的开发助手”。它会根据项目目录、配置文件和用户指令把任务拆成多个动作完成。在补环境场景里OpenCode 特别适合处理一个问题环境缺失点分散在多个文件里。人工找navigator、window、wx的引用非常耗时交给模型扫描后它能在短时间内列出一份“缺失环境清单”然后逐个补齐。实际使用前要确认两点第一OpenCode 有不同的版本和入口比如终端版、桌面版、VSCode 扩展命令可能不一样第二模型服务需要单独配置比如使用云模型 API Key或者本地部署模型。安装方式和套餐以你使用的发行渠道为准不要直接照搬记忆里的命令。这类工具并不只有 OpenCode 一个其他终端型 AI 编码代理也支持类似的工作流。选 OpenCode 做示例是因为它的项目上下文和 Skills 机制比较适合“分析代码 生成补丁 运行验证”的循环。2.2 在补环境场景里的三个优势把 OpenCode 放进“AI 逆向 小程序环境补全”的工作流有三个好处上下文持续维护。模型会记住项目结构修改src/env-mock.js后再运行验证脚本它知道两者之间的关系。可以执行命令。补完环境后直接让 AI 运行node scripts/run-check.js迭代速度比纯聊天工具快。适合沉淀规则。通过AGENTS.md和 Skills把团队的补环境规范变成模型能读取的指令。也有限制AI 生成的 mock 代码不能直接信任所有输出都要经过人工审查和测试验证。补环境不是“一键修复”模型给出的代码只能作为初稿。2.3 安装与基础配置本节只给出通用思路。OpenCode 的发布入口和命令随版本变化落地前先打开官方文档确认。# 示意从终端启动 OpenCode。 # 具体启动命令可能是 opencode也可能是 npm 全局命令以你安装的版本为准。 opencode首次启动后会要求选择模型服务。常见的配置方式有使用云模型服务的 API Key。使用本地模型服务适合内网环境。使用工具内置的默认模型需要联网注册。配置完成后可以在项目目录执行初始化命令让 OpenCode 读取当前目录结构。# 在项目根目录初始化上下文 opencode init如果命令不存在不要硬试。先执行opencode --help查看当前版本支持的命令。2.4 用 AGENTS.md 建立项目规则AGENTS.md 是很多 AI 编码工具支持的项目说明文件作用是告诉模型“这个项目的约定是什么”。补环境项目很适合在这里写明底线。示例# 项目规则 ## 任务边界 - 本目录用于前端/小程序代码的本地环境模拟与测试。 - 禁止修改 src/business-code.js 中的业务逻辑。 - 只补充运行环境不用于绕过鉴权、提取签名或读取用户数据。 ## 补环境规范 - 所有 mock 对象必须放在 src/env-mock.js 中。 - 每个 mock 方法都需要注释说明被谁调用、返回什么。 - 对关键字段使用断言验证。 - 如果某个全局对象在 Node 中原生存在不要重复 mock。模型读到这份文件后生成代码的风格会稳定很多。注意AGENTS.md是“规则”不是“功能清单”不能代替人工 code review。2.5 用 Skills 沉淀补环境套路Skills 是 OpenCode 的扩展机制可以把一类任务包装成可复用的技能。比如团队经常要分析小程序环境就可以创建一个mini-env-mockSkill描述补环境的标准流程。一个常见的目录结构.opencode/ └── skills/ └── mini-env-mock/ ├── SKILL.md └── templates/env-mock.jsSKILL.md里说明这个 Skill 的使用条件、输入和输出。这样下次再遇到类似的小程序代码模型会优先按照这个技能执行。由于不同版本对 Skills 的路径和格式要求不同实际落地时先查阅当前版本文档再用最小用例验证。3. 准备一个可以被分析的最小前端模块3.1 项目结构为了讲清楚补环境的闭环下面构造一个最小项目。它模拟了一个小程序页面的公共逻辑模块运行在 Node.js 环境。demo-mini-env/ ├── .opencode/ │ └── skills/mini-env-mock/SKILL.md ├── AGENTS.md ├── scripts/ │ └── run-check.js ├── src/ │ ├── business-code.js │ └── env-mock.js └── package.jsonsrc/business-code.js待分析的业务代码里面引用了wx、navigator等全局对象。src/env-mock.js补环境模块负责补齐缺失全局对象。scripts/run-check.js验证脚本运行业务代码并检查输出。AGENTS.mdOpenCode 项目规则文件根目录下生效。.opencode/skillsSkills 配置目录。这个结构不需要很复杂。补环境项目的重点不是目录数量而是业务代码、mock 代码、验证脚本三者之间的边界是否清晰。3.2 模拟小程序环境的一段业务代码下面的getPageEnvInfo模拟了一个小程序页面获取环境信息的逻辑。真实项目里类似的公共方法会被多个页面调用。// src/business-code.js function getPageEnvInfo() { const system wx.getSystemInfoSync ? wx.getSystemInfoSync() : {}; return { userAgent: navigator.userAgent, platform: system.platform || unknown, language: system.language || navigator.language, canUseWorker: typeof Worker function }; } if (typeof module ! undefined module.exports) { module.exports { getPageEnvInfo }; }这段代码依赖四个环境能力wx.getSystemInfoSyncnavigator.userAgentnavigator.languageWorker这里有一个关键细节Worker在 Node 18 以上版本已经是原生全局对象补环境时不需要再 mock。模型如果不清楚这一点很可能会画蛇添足。3.3 直接运行会发生什么在不补环境的情况下运行业务代码node -e const m require(./src/business-code.js); console.log(m.getPageEnvInfo())会得到类似下面的报错/Users/you/demo-mini-env/src/business-code.js:3 function getPageEnvInfo() { const system wx.getSystemInfoSync ? wx.getSystemInfoSync() : {}; ^ AI逆向补环境：用OpenCode搭建小程序运行环境
提到 AI 逆向很多人第一反应是让 AI 帮助还原小程序代码、提取接口签名、绕过校验。但在真实工程里逆向分析最常见的瓶颈并不是读不懂源码而是代码依赖的运行环境在本地完全建不起来。OpenCode 这类终端 AI 编码工具出现后补环境这件事从“逐行阅读源码、手动猜 window 和 navigator 怎么补齐”变成了可以交给模型辅助分析的工程化操作。这篇内容会围绕“AI 逆向 OpenCode 补环境 小程序场景”展开。先说明哪些操作可以做、哪些不能做然后从 OpenCode 的安装和项目配置讲起再通过一个最小前端模块演示如何识别缺失环境、用原型链补环境、跑通自动化验证。示例代码的目的是理解程序行为和搭建环境模拟层对于任何未授权的小程序不建议也没有必要做完整逆向。关于标题里提到的瑞幸小程序需要先划一条边界商业线上应用在没有授权的情况下不应该做解包、数据采集、提取签名、读取用户数据等操作。想要练手时最稳妥的方式是用自己的小程序测试包或选择开源、明确允许安全分析的 Demo。下面所有代码都按这个前提设计。1. 先搞清 AI 补环境到底补的是什么1.1 逆向不是目的理解程序运行机制才是在开发和安全测试中逆向分析是理解程序行为的手段。比如一个旧前端项目没有文档连哪些全局变量被引用都不知道这时需要分析代码、定位依赖、构造运行环境。这类工作不需要“破解”任何东西只需要把程序放到一个可运行的环境里观察它的输入输出。AI 工具在这个环节的价值是快速建立代码地图。把项目目录丢给 OpenCode模型会先扫描文件、识别入口、找出外部依赖和全局变量再按指令生成修复或兼容代码。相比逐行读源码这种工作方式把“理解程序”的效率提升了很多。换个角度讲逆向分析更接近“代码考古”。你需要从运行结果反推模块结构从报错信息反推环境依赖从接口调用反推数据流。AI 擅长的是快速扫描和模式匹配真正决定分析质量的仍然是开发者对运行机制的理解。1.2 补环境就是给程序一个可以运行的家小程序代码通常运行在微信提供的容器里容器里有wx、Page、getApp等全局对象。代码一旦拿到 Node.js 或浏览器里执行这些对象就消失了。补环境就是在目标运行时中补齐这些缺失的全局对象和 API让代码能继续执行。这里要区分两种补环境兼容层补环境为代码提供假的window、navigator、wx等对象目的是让业务逻辑可以在本地测试或自动化验证中运行。对抗性补环境通过伪造完整浏览器环境数据让程序以为自己仍在原始容器中运行从而规避服务端或客户端的检测。本文只讨论前者。对抗性补环境经常涉及安全检测规避不建议也不会在合规场景里展开。补环境能力本身是中性的用在测试、兼容性分析、自动化脚本里是正向价值用在绕过校验上就是另一回事。1.3 合规边界先确认自己有没有权限把“能不能做”的判断放在“怎么做”之前。下面的表给出常见场景的边界。场景建议说明分析自己开发的代码可以做自己写的业务逻辑本地补环境能帮助测试分析授权测试的小程序需要书面授权安全测试必须先确认授权范围分析开源 Demo按开源协议执行保留来源声明不用于非法用途分析未授权的第三方商业应用不要做解包、数据采集、提取签名等都有合规风险提取用户信息、绕过支付、篡改数据绝对不要做属于违法或违反平台规则的行为很多开发者对“补环境”产生兴趣是因为想复现某个网页或小程序里的加密逻辑。这个目标本身没有错但一定要选对练习对象。用自己搭的测试项目练习既能理解原理又不会触碰安全红线。2. 为什么选 OpenCode 作为补环境辅助工具2.1 OpenCode 是什么OpenCode 是一款可以运行在终端里的 AI 编码代理它的定位不是“聊天机器人”而是“能读取项目文件、执行命令、生成文件并持续维护上下文的开发助手”。它会根据项目目录、配置文件和用户指令把任务拆成多个动作完成。在补环境场景里OpenCode 特别适合处理一个问题环境缺失点分散在多个文件里。人工找navigator、window、wx的引用非常耗时交给模型扫描后它能在短时间内列出一份“缺失环境清单”然后逐个补齐。实际使用前要确认两点第一OpenCode 有不同的版本和入口比如终端版、桌面版、VSCode 扩展命令可能不一样第二模型服务需要单独配置比如使用云模型 API Key或者本地部署模型。安装方式和套餐以你使用的发行渠道为准不要直接照搬记忆里的命令。这类工具并不只有 OpenCode 一个其他终端型 AI 编码代理也支持类似的工作流。选 OpenCode 做示例是因为它的项目上下文和 Skills 机制比较适合“分析代码 生成补丁 运行验证”的循环。2.2 在补环境场景里的三个优势把 OpenCode 放进“AI 逆向 小程序环境补全”的工作流有三个好处上下文持续维护。模型会记住项目结构修改src/env-mock.js后再运行验证脚本它知道两者之间的关系。可以执行命令。补完环境后直接让 AI 运行node scripts/run-check.js迭代速度比纯聊天工具快。适合沉淀规则。通过AGENTS.md和 Skills把团队的补环境规范变成模型能读取的指令。也有限制AI 生成的 mock 代码不能直接信任所有输出都要经过人工审查和测试验证。补环境不是“一键修复”模型给出的代码只能作为初稿。2.3 安装与基础配置本节只给出通用思路。OpenCode 的发布入口和命令随版本变化落地前先打开官方文档确认。# 示意从终端启动 OpenCode。 # 具体启动命令可能是 opencode也可能是 npm 全局命令以你安装的版本为准。 opencode首次启动后会要求选择模型服务。常见的配置方式有使用云模型服务的 API Key。使用本地模型服务适合内网环境。使用工具内置的默认模型需要联网注册。配置完成后可以在项目目录执行初始化命令让 OpenCode 读取当前目录结构。# 在项目根目录初始化上下文 opencode init如果命令不存在不要硬试。先执行opencode --help查看当前版本支持的命令。2.4 用 AGENTS.md 建立项目规则AGENTS.md 是很多 AI 编码工具支持的项目说明文件作用是告诉模型“这个项目的约定是什么”。补环境项目很适合在这里写明底线。示例# 项目规则 ## 任务边界 - 本目录用于前端/小程序代码的本地环境模拟与测试。 - 禁止修改 src/business-code.js 中的业务逻辑。 - 只补充运行环境不用于绕过鉴权、提取签名或读取用户数据。 ## 补环境规范 - 所有 mock 对象必须放在 src/env-mock.js 中。 - 每个 mock 方法都需要注释说明被谁调用、返回什么。 - 对关键字段使用断言验证。 - 如果某个全局对象在 Node 中原生存在不要重复 mock。模型读到这份文件后生成代码的风格会稳定很多。注意AGENTS.md是“规则”不是“功能清单”不能代替人工 code review。2.5 用 Skills 沉淀补环境套路Skills 是 OpenCode 的扩展机制可以把一类任务包装成可复用的技能。比如团队经常要分析小程序环境就可以创建一个mini-env-mockSkill描述补环境的标准流程。一个常见的目录结构.opencode/ └── skills/ └── mini-env-mock/ ├── SKILL.md └── templates/env-mock.jsSKILL.md里说明这个 Skill 的使用条件、输入和输出。这样下次再遇到类似的小程序代码模型会优先按照这个技能执行。由于不同版本对 Skills 的路径和格式要求不同实际落地时先查阅当前版本文档再用最小用例验证。3. 准备一个可以被分析的最小前端模块3.1 项目结构为了讲清楚补环境的闭环下面构造一个最小项目。它模拟了一个小程序页面的公共逻辑模块运行在 Node.js 环境。demo-mini-env/ ├── .opencode/ │ └── skills/mini-env-mock/SKILL.md ├── AGENTS.md ├── scripts/ │ └── run-check.js ├── src/ │ ├── business-code.js │ └── env-mock.js └── package.jsonsrc/business-code.js待分析的业务代码里面引用了wx、navigator等全局对象。src/env-mock.js补环境模块负责补齐缺失全局对象。scripts/run-check.js验证脚本运行业务代码并检查输出。AGENTS.mdOpenCode 项目规则文件根目录下生效。.opencode/skillsSkills 配置目录。这个结构不需要很复杂。补环境项目的重点不是目录数量而是业务代码、mock 代码、验证脚本三者之间的边界是否清晰。3.2 模拟小程序环境的一段业务代码下面的getPageEnvInfo模拟了一个小程序页面获取环境信息的逻辑。真实项目里类似的公共方法会被多个页面调用。// src/business-code.js function getPageEnvInfo() { const system wx.getSystemInfoSync ? wx.getSystemInfoSync() : {}; return { userAgent: navigator.userAgent, platform: system.platform || unknown, language: system.language || navigator.language, canUseWorker: typeof Worker function }; } if (typeof module ! undefined module.exports) { module.exports { getPageEnvInfo }; }这段代码依赖四个环境能力wx.getSystemInfoSyncnavigator.userAgentnavigator.languageWorker这里有一个关键细节Worker在 Node 18 以上版本已经是原生全局对象补环境时不需要再 mock。模型如果不清楚这一点很可能会画蛇添足。3.3 直接运行会发生什么在不补环境的情况下运行业务代码node -e const m require(./src/business-code.js); console.log(m.getPageEnvInfo())会得到类似下面的报错/Users/you/demo-mini-env/src/business-code.js:3 function getPageEnvInfo() { const system wx.getSystemInfoSync ? wx.getSystemInfoSync() : {}; ^