一句话怎么变成一个工程：从解析到反编译的五个静默动作

大多数人以为“AI 改包”的核心是那个 AI。用久了会发现不是——核心是那句人话被翻译成一份工程的全过程。一句话之所以能变成一次真实的改动，是因为在它前后有一串很土但很关键的动作：认出这个包是什么、给它建一个独立目录、把包拆成能改的样子、把需求补全成一份没有歧义的指令、改完再装回去。任何一环断了，那句话就只是一句话。

这篇就顺着这条链路走一遍，讲清楚安卓修改大师电脑版把“一句话”落到磁盘上时，中间到底发生了什么。里面会有几个真实的工程细节——比如为什么图标要按密度挑、为什么反编译失败项目照样能建、为什么修改历史里只存你的原话而不存系统补全后的那一大段。这些细节决定了它是“玩具”还是“工具”。

一、一句话在系统里走了哪几步

把 apk 拖进窗口，到你能在输入框里写需求，中间其实已经发生了五件事：解析包信息、创建项目目录、复制原始文件、反编译出工程、唤醒右侧的 AI 改包工作台。这五件事都在后台线程跑，界面上只显示一个“解析中”的遮罩，所以你感觉是“拖进去就好了”。

为什么要把这五步拆开而不是一步做完？因为它们失败的后果不一样。解析失败，你连这个包叫什么都不确定；建目录失败，说明磁盘权限有问题；反编译失败，包还是好的，只是改不了；唤醒失败，环境和权限要查。拆开之后，每一步失败都能给你一句准确的话，而不是一个笼统的“操作失败”。

这个原则贯穿整个工具：能定位到具体环节的错误，才是有用的错误。所以你会看到它把“打包”拆成四个步骤逐条打勾，把“工具检测”拆成六行逐个显示路径——不是为了好看，是为了让你知道该修哪里。

二、第一步：先认出这个包是什么

apk 本质上是个 zip，但你不能靠解压去看它叫什么——应用名可能在几十种语言的资源里，包名藏在二进制清单里，图标有五六套不同分辨率。所以第一步是调用 aapt 解析，一次拿到包名、应用名、版本号、最低与目标 SDK、启动页、图标路径。这些信息会写进项目的配置文件，后面每一步都要用。

图标这块有个坑值得说：aapt 会列出每个密度对应的图标路径，其中有一个特殊值 65534，意思是“任意密度”，不是“最高密度”。如果按数值大小排序直接取最大，就会选到一张很小的图，做出来的项目图标糊成一片。正确做法是只认 1 到 640 这些真实密度，取最高的那一档（通常是超超高密度）。这种细节没人会写在教程里，但它决定了你第一眼看到的项目卡片清不清晰。

还有两种例外。一种是图标是 webp 格式而系统没装解码器，位图解不出来——这时界面会退回成文字头像，但图标原文件照样存进项目目录，不影响后面替换。另一种是分包格式（apks / xapk）或者被加密的包，解析不出包名，这时不报错中断，而是拿文件名当应用名继续建项目，并在界面上说明一句。能不中断就不中断，是这个工具一贯的选择。

三、第二步：给它一个家

每个项目在项目目录下有一个八位随机字符串的子目录。为什么不按应用名建目录？因为应用名会重名、会带斜杠、会有各种奇怪字符，而且改完名字后目录名就对不上了。随机串不会冲突，也不会因为你改了应用名而“名不副实”。

目录里落地四样东西：图标原图、配置文件、原始文件副本、反编译产物。配置文件里记着项目名、创建时间、工作目录、图标文件名、源文件名、项目类型，以及从包里解析出来的应用名、包名、版本、SDK、启动页。这些字段不是给你看的，是给后面每一步用的——回编要知道工程在哪，签名要知道用哪套，装机预览要知道拉起哪个页面。

原始文件副本这一样最容易被忽略，但它是最重要的保险。导入时会把你的 apk 复制一份成固定名字放在项目里，之后再怎么改、改坏多少次，这一份永远不动。它相当于“出厂设置”——任何时候你都可以拿它重新开一个项目，从零再来。我们见过太多人改到一半发现方向错了，却没有原始文件，只能去找客户再要一次。

四、第三步：把包拆开

拆包用的是 apktool，这是安卓圈用了十几年的开源工具，稳定、兼容性好。它把 apk 解成三块：清单文件、资源目录、smali 代码。清单决定应用叫什么、要什么权限、从哪个页面启动；资源是图片、布局、字符串、颜色；smali 是反汇编出来的代码，可读性一般，但改逻辑够用。

判断“拆成功了”不能只看退出码。apktool 有时会带着警告返回 0，实际没产出完整工程。所以判定条件是两条同时成立：退出码为 0，并且工程目录里出现了它的标志文件。两条都满足才写回配置、才允许进入下一步。这个“双条件”判断在后面打包那一步也用了一次——签名到底成没成，要额外跑一次校验才算数。

耗时方面，实测一个 12MB 的包大约三秒；几十兆的包可能到几分钟。超过十分钟会中断并报错，不让你对着一个转圈的界面干等。同类包第二次拆会快一些，因为框架缓存已经在了。这也是为什么批量改同一类包时，第一个最慢、后面越来越快。

五、反编译失败，其实不算致命

这是新手最容易慌的一步：弹窗说反编译失败，是不是白干了？不是。失败的那一刻，配置、图标、原始文件副本都已经落地了，项目是完整的，只是少了一个能改的工程目录。你可以照常进详情页，看历史、看信息，也可以修好环境后重新导入。

失败原因通常三类：工具目录不全（缺 Java、缺拆包工具）、包本身有问题（加固、损坏、分包）、权限问题（目录不可写）。提示里会附上输出的最后几行和日志路径，这三类基本能一眼分开。参数页的工具检测可以先把“缺不缺”这件事排掉。

有意思的是，反编译失败之后的行为是有讲究的：它不会弹一个“重试”按钮让你反复点，因为同一个环境重试一百次也是一样的结果；它也不会把半成品工程留在目录里让你误以为能用。失败就停在失败，把现场留给你，把判断权也留给你。

六、第四步：把话说明白，才是真功夫

到这一步，用户写下的那句人话要变成一份 AI 能执行的指令。这里有个设计决定了整个工具的体验：真正送出去的文本，不等于你写的那句话。

送出去的文本由三段拼成：你写的原话、附件说明（如果你加了附件）、以及一段固定的环境说明。环境说明会告诉执行方：当前项目的工程目录在哪、改完怎么通知主窗口、不要在右侧窗口里自己打包、打包后要对齐并用项目里设定的那套签名。附件说明则是“文件名 + 一句用途”，比如“这张图是应用图标”。

为什么要加这一段？因为一句话再清楚，也缺上下文。“把图标换掉”这句话，人听了会去找你刚发的图，机器听了不知道图在哪；“改完给我”这句话，人知道你要一个包，机器不知道要放在哪个目录、叫什么名字。环境说明补的就是这些“人默认知道、机器不知道”的部分。

而修改历史里只存你的原话。原因很实际：那段环境说明里带着绝对路径，换台机器、换个目录就失效了；存下来只会让历史变得又长又不可读。原话是资产，补全是临时工。

七、第五步：唤醒工作台，并且别抢你的焦点

工程准备好了，接下来要把右侧的 AI 工作台叫起来。这里有两个小设计，用过的人未必察觉，但少了会很难受。

第一个：如果它已经在跑，就不再重复启动，只是唤醒窗口。反复启动会导致多开、内存翻倍、甚至两个实例抢同一个工程目录。第二个：唤醒的时候不抢回主窗口的焦点。你刚写完需求，光标还在输入框里，如果这时候主窗口被顶到后面去，你会下意识地再点一下——这一下就是一次无谓的操作。好工具不打断你，只配合你。

如果唤醒失败，也会分情况说清楚：是没配路径、文件不存在、还是启动失败。这三种的处理方式完全不同，笼统说一句“打不开”等于没说。项目本身不受影响，你随时可以修好再来。

八、实例一：改包名和应用名，从三处漏一处说起

这是改包里最基础的一件事，也是最容易“看起来改好了、实际没改干净”的一件事。用我们自家的一个工具类应用做例子。

以前怎么做：要改的地方至少三处——清单里的包名（决定安装身份）、清单里的应用名（桌面显示）、以及关于页里的版本信息文案（很多应用把它写死在字符串资源里）。改包名还牵动启动页的完整类路径，漏改一处，装上去就是闪退。我们最早做这件事的时候，改了包名和应用名，交付后客户说“设置里还是旧名字”，一查，是“关于”页里那句写死的文案。三个位置，漏一个，等于没改。

现在怎么做：一句话——“把应用名改成‘极速清理助手’，包名改成 com.example.fastclean，关于页里的名字和版本信息一起同步”。点修改，等出包。工具会把这三处当作一件事来做，而不是让你分别说三遍。

改完怎么验证：四个地方各看一眼。桌面图标下面的名字；设置里“应用信息”的名字；应用内“关于”页；以及安装时系统弹的权限确认框（那里显示的是应用名）。包名则看“应用信息”页最下面那一行，或者在电脑上重新解析一次包。四处都对，才算改干净。

九、实例二：改版本号，为什么必须同时动两个数字

第二个例子还是自家应用，这次是发版前的常规动作：改版本号。看着最简单，其实藏着改包里最经典的一个坑。

安卓的版本号有两个：一个给人看的（比如 3.2.0），一个给系统看的（一个整数，比如 6）。系统判断“能不能覆盖安装”只看那个整数：新包的整数必须大于等于已装的，否则会被拒绝，报“版本降级”。很多人只改了给人看的那一个，结果装的时候被拦下来，还以为是签名问题。

以前怎么做：两个数字都要改，还要记得同步“关于”页里那句手写的版本文案，否则界面显示 3.2.0、系统里是 3.1.9，客户一看就露馅。三处，一个都不能少。

现在怎么做：一句话——“版本号改成 3.3.0，版本代码加一，关于页的版本文案一起更新”。出包之后，装到旧版本上，能覆盖、能打开、设置里显示一致，就算过。

改完怎么验证：先不卸载，直接装。能装上说明版本代码对了；打开看“关于”页，说明文案同步了；再看系统“应用信息”里的版本，和界面显示一致，说明两个数字都改了。三步，一分钟。

这两个例子放在一起，是想说明一件事：改包最难的部分从来不是“改”，是“知道有几处要改”。新人踩的坑几乎全在这一类——不是不会操作，是不知道还有第二个位置。工具的价值，是把这些“隐性位置”变成一句话就能覆盖的整体动作。

十、三千条话术是怎么写出来的：一条需求该有的七段

很多人第一次打开话术列表会惊讶：怎么会有三千条？其实不是三千种功能，是同一个功能的不同说法与不同参数组合。六个分类各五百条，覆盖界面美化、弹窗引流、去除限制、常规修改、混淆去毒、插件添加。

真正的价值不在数量，在结构。每一条都按同一个骨架写：开头一句目标，然后是【要做什么】【细节要求】【参数参考】【范围】，最后是验收和【约束】。长度在两百八到四百多字之间，平均三百六十字左右。

为什么要有“参数参考”这一段？因为“圆角大一点”这种描述没法执行。参数段会给出具体数值——圆角多少、阴影偏移多少、渐变从哪个色到哪个色。这些数值是按固定种子随机生成的，所以同一条话术你每次看到的值是一样的，不会今天 12、明天 18。

为什么要有【范围】和【约束】？因为它们防的是“改过头”。范围说清这次只动哪几个页面，约束说清不许动什么——比如“不要修改启动流程”“保留原有权限声明”。没有这两段，一句“优化界面”可能把整个导航结构都重排了。

十一、小白怎么用这三千条：选、改、发

话术列表不是让你从头读的。正确用法是三步：按分类筛、按关键字搜、挑一条最接近的。比如你想把界面改成深色，就进“界面美化”，搜“深色”，出来一堆，挑一条描述最贴近你想象的。

点右侧的“选择”，这条话术的正文会直接填进详情页的输入框。这时候不要急着发——先改两个字。把里面的应用名换成你的、把颜色值换成你要的、把“全应用”改成“只改首页”。话术是起点，不是答案。

改完就发。如果不满意，别重新写一遍，直接在原话后面追加一句“再淡一点”“圆角再小两像素”“标题字号加大”。这种“在结果上追加”的方式，比重新描述一遍效率高得多，也更接近人跟设计师沟通的真实方式。

顺带说一句，这个话术库是一个可读的 XML 文件，跟着程序放在资源目录里，用记事本就能改。你可以把自己常用的那几条改得更贴合自己的说法，改完点一下刷新就生效，不用重启。公司内部如果有统一的设计规范，把它写进话术里，团队里每个人的输出就会一致。

这里顺便说清官网的位置：安卓修改大师的产品介绍页在 https://www.apkeditor.cn/ai-version.aspx ，官网是 www.apkeditor.cn。话术库、版本说明、常见问题都在那边，遇到不确定的先翻一眼，比在群里问快。

十二、工程目录长什么样：一个项目就是一个文件夹

把这套东西讲给同事听，最有效的一句是：一个项目就是一个文件夹，拷走就能带走全部上下文。这句话背后是一套很克制的目录设计——没有数据库、没有云端索引、没有“导入导出”，全是文件。

为什么坚持用文件？因为改包这个活天然是“断续”的：今天改一半，明天客户改需求，后天要发给别人接着做。如果状态存在数据库里，换台机器就断了；存成文件，压缩包发过去，对方解压就能接上。而且出了问题你能直接打开看——日志是文本，配置是文本，历史也是文本。

代价是文件名不能乱改。配置文件里的路径是相对的，图标读的是配置里写的那个名字，你把图标文件重命名了，项目列表那一栏就会变成文字头像。这不是 bug，是“文件即状态”必然的约束。

十三、配置里真正有用的只有三行

配置文件是纯文本，带注释，可以手工改。但绝大多数人一辈子只会看其中三行：包名、应用名、项目类型。包名决定安装身份，应用名决定桌面显示，项目类型决定后面走哪条路。

项目类型这个字段值得单独说：它区分“要拆包的”和“不拆包的”。apk 及其变体走拆包路线；exe、jar、class 走另一条线——不解析、不拆包，原文件直接躺在项目里，由执行方直接改这个文件并自己打包，成品命名成一个固定名字放进目录。所以这类项目的详情页会少掉一半按钮：没有“去打包”、没有签名设置、没有打包勾选项。

这个区分不是技术洁癖，是避免误导。给一个 exe 项目显示“去打包”按钮，用户点了会以为能出 apk，结果什么都没发生——这种“看起来能用其实不能用”的设计，比没有按钮更伤人。

十四、三条排错思路：环境、权限、签名

这套链路出错，八成集中在这三处。按顺序排，能省掉大量瞎试的时间。

环境排在最前，因为它决定“能不能开工”。缺 Java、缺拆包工具、缺对齐工具，都会在参数页的工具检测里显形，六行逐个显示“找到没有 + 完整路径”。哪一行是红的就补哪一行，别一口气全重装。

权限排第二。两个典型场景：工作目录选在了系统盘根目录这种需要提权的位置，写不进去；或者右侧工作台是管理员身份跑的，主窗口不是，窗口联动被系统静默拦下。前者换目录，后者让两边同级。

签名排第三，因为它只影响“装不装得上”，不影响“改没改成”。签名不一致、版本降级、仅测试包这几种，提示里会明确写出来，按提示处理就行。最忌讳的是遇到装不上就卸载重装——那是把用户数据一起删了，得先问过人家。

十五、为什么这套流程对批量特别友好

一个人一天改三个包，和一天改三十个包，需要的不是更快的键盘，是“不用记”的流程。这套设计里有三样东西是专门为批量准备的。

第一样是模板化的需求。三千条话术里，同一个特性会派生二十条变体：五个作用位置乘四种改造口径（最小改动、整体重做、沿用原风格、突出科技感）。批量改十个渠道包时，你要做的不是写十遍需求，而是选一条口径，改一下应用名，发十次。

第二样是可回填的历史。每个项目的历史记录都能一键填回输入框，所以“按上次那个再来一版”只需要两次点击。更妙的是历史不会因为回填而被改写——它只增不改，你随时能看到最初那条是什么。

第三样是无人值守循环。勾上一个选项之后，改完一轮自动打包、按规则命名、上传到指定位置，然后自动开始下一轮。文件名规则支持前缀、时间戳、数字后缀循环，同名会覆盖，所以对外发出去的那个链接永远指向最新包。这个功能听着像“批量生产”，实际最常用的场景是“反复微调直到满意”——你睡觉，它改一百版，早上挑一个。

十六、手机端把这几步压缩成了什么样

上面这一整套链路，在手机上被压得很短。没有“建项目目录”这一步的感知，没有“反编译出工程”的等待，你看到的就是：选一个包、写一句话、等一会儿、装上看。

压缩的方式不是省略步骤，是把步骤藏起来。目录还是有的，只是不让你管；反编译还是要做的，只是不占你的注意力。这就是移动端设计的原则：能自动的绝不让你选，必须你决定的才弹出来。

代价是可控性下降。你想手工改配置文件、想翻日志、想调签名方案，手机上做不了，得回电脑。所以三个版本不是替代关系，是分工：手机上接活和快速验证，电脑上做复杂改动和批量，经典版给只需要改一两处的人。

同一句话在三个版本里都成立，这是这套产品最舒服的地方——你不用因为换了设备而重新学一套说法。

十七、把这条链路走一遍：十分钟里你只动四次手

把前面所有步骤串起来，一次真实的改包是这样的：拖文件（第一次动手）、等解析弹窗、填项目名、点创建、写需求（第二次动手）、点立刻修改、等出包、点保存（第三次动手）、装到手机上看一眼（第四次动手）。四次动手，其余全是等待。

等待的时间里，界面不是死的：解析时有遮罩和进度，反编译有日志在滚，改的时候右侧窗口在动，打包时四个步骤逐条打勾。“看得见在干什么”这件事，对小白的意义远大于“快”。因为看不见的时候，人会以为卡死了，然后去点第二次、第三次，最后把流程搞乱。

所以如果只让我留一句建议给第一次用的人，那就是：点完之后别急着再点，看它一步一步走完。这套流程里每一段都有明确的结束信号，你只要认那几个信号就够了。

从一句话到一整个工程，中间那些步骤你不需要记住。但知道它们存在，会让你在出问题的时候不慌——因为你知道该看哪里：拆包失败看反编译日志，装不上看签名，吸不上窗口看权限。工具把复杂收起来，但没把它藏掉，这就是它和“黑箱”的区别。

十八、被问得最多的五个问题

问：为什么我拖进去没反应？先看是不是没登录。导入、编辑项目都要先登录，没登录会弹登录窗口，但有些人的窗口被其他程序挡在后面，看起来就像“点了没动”。其次看文件类型，支持的是 apk 及其变体，加上 exe、jar、class 这几类，其他格式会被文件对话框直接过滤掉。

问：反编译要多久？12MB 的包大约三秒，几十兆的到几分钟。同类包第二次会快，因为有缓存。超过十分钟会中断，避免你无限等。如果每次都很慢，考虑先做资源精简，或者换台内存大点的机器。

问：改完的包在哪？出包成功会弹保存框，默认文件名是应用名加版本号。你也可以点“打开所在文件夹”直接跳过去。就算你取消了保存，成品还在项目的打包产物目录里，不会白跑。

问：能在手机上改吗？能，用安卓版。电脑版强在看得全、能批量、能翻日志，手机上强在随时能改。同一句话两边都认。

问：会不会把我的应用改坏？会——如果你让它改它不该改的地方。所以项目里永远留着一份原始文件副本，改坏了拿它重开一个项目就行。这也是我们坚持“一个项目一个目录”的原因：坏的那一份和好的那一份，物理上分开。

十九、模板化的代价：为什么它不能替你决定“要什么”

三千条话术、七个段落、二十种变体——这套东西看起来很“全”。但用得久了会发现它的边界很清楚：它能替你把“怎么做”写清楚，替不了你决定“做什么”。

举个例子。同样是“去掉开屏广告”，有的应用是把广告页整个删掉直接进首页，有的是保留广告页但把倒计时改成零，有的是把广告图换成一张自己的品牌图。三种做法在不同的场景下都对：第一种最干净，第二种改动最小，第三种适合你还想留个品牌曝光位。工具不会替你选，因为选错了他也不知道。

所以话术的作用是“把选项摆出来”，不是“替你做决定”。你选一个方向，它给你一版具体的，你在具体的上面说“再淡一点”。这个循环，跟人跟设计师沟通的方式是一样的——没有人能一次说清自己要什么，都是在看到第一版之后才开始知道自己要什么。

理解这一点，你就不会指望“一句话出完美成品”。一句话出的是第一版，第二版靠你补的那句话。这也是为什么我们把“在结果上追加”做得这么顺：不满意不用重写，加一句就行。

二十、给第一次用的人一张清单

如果你今天第一次打开它，照着这张清单走一遍，大概二十分钟能摸清全部关键动作。

第一步，确认工作目录。默认会自动挑盘，参数页能看到挑到了哪。挑到的位置剩余空间要够，不然拆大包会失败。

第二步，导入一个自己做的、或者有授权的应用。别拿别人的商业应用练手，一是法律问题，二是改坏了你也不知道原样是什么。

第三步，从话术列表里挑一条最简单的——比如“修改应用名称”。点选择、改两个字、发出去、等出包、装上看。这一轮的目的不是改出什么成果，是让你看见整条链路长什么样。

第四步，打开项目的修改历史，点一下那条记录右侧的“选择”，看它怎么回填。这个动作你以后会用几百次。

第五步，出问题时先看参数页的工具检测，再看日志。这两处能解决八成问题，剩下的再看提示文字。

二十一、附：一句话被补全之后大概长这样

很多人好奇“补全”到底补了什么。下面是脱敏后的示意，真正的文本里路径会换成你当前项目的实际路径。

再说一个容易被忽略的收益：这套链路让“改动”变成了可复制的东西。同一个应用，你要出十个渠道版本，差别只在名字、图标、启动图。以前的做法是改十次、打十个包、每次都可能漏一处；现在的做法是建十个项目，每个项目一句话，剩下的交给流水线。项目之间互不干扰，因为目录是独立的。

而且每个项目的改动都留了痕。三个月后客户问“这个渠道包的图标是哪一版”，你翻项目目录就能看到当时的图标原图和历史记录，不用靠记忆。这种“可回溯”，在批量交付里比速度更值钱——因为出问题的时候，能说清楚比能改快更重要。

最后一个体会：工具做得越细，你越不需要记住它。你不需要记住反编译用了什么参数、签名用了哪套方案、日志放在哪个目录，因为每一步都有默认值和提示。你需要记住的只有一件事——把要改的东西说清楚。这也是我们一直把“话术”放在显眼位置的原因：说清楚，是这个行业里最值钱的技能。

补一个实操细节：同一个应用要出多个版本时，建议先复制一份项目目录再改，而不是在原项目上反复改。因为项目目录里存着历史、日志、原始文件，这些都带时间戳，是有证据价值的。复制一份之后，新目录就是一条新的分支，两条互不影响。等确定最终版，把其他的删掉就行。

还有一个和手机端配合的小技巧：每次出包后，把成品文件名里的版本号留着，不要图省事改成 final、new、last 这类词。三个月后回头找“到底是哪一版发出去的”，版本号是唯一可靠的线索，final 三个字一点用都没有。

最后补一句关于“版本”的提醒。不同版本之间的差别，往往不在功能列表上，而在“它替你处理了多少琐事”。同样一句话，能改和改得干净，中间隔着的就是这些琐事：图标按密度挑、资源引用不留断链、签名方案选对、装到机器上看一眼。这些东西没人会写在宣传语里，但你用第二次的时候就感觉得到。

顺带说一个经常被问到的细节：为什么改完之后，包会比原来大一点或小一点？大一点通常是加进去的图没压好，或者多了一层资源；小一点通常是删掉了广告位和相关图片。这两种都正常，判断标准不是“大小变没变”，是“功能对不对、界面有没有塌”。

二十二、用过的人怎么说

安卓修改大师智改工坊这套东西，说到底是把“改包”从一门手艺拆成了一条流水线：认包、建目录、拆工程、补需求、改、回编、签名、验证。每一段都有明确的输入输出，也都有明确的失败提示。你不需要会整条流水线，只要会用其中一段，就能干活。

合规提醒：只改自己拥有版权或已获得明确授权的应用。不要用它破解付费、绕过授权校验或去除任何安全机制。改包前务必保留原始文件，改完在真机上验证再交付。

回到标题：一句话怎么变成一个工程？答案是中间有五个安静的动作，加一段替你把话补全的说明。你把话说清楚，剩下的交给流水线——“只需说话，就能让应用变成你想要的样子”，说的就是这条链路已经被铺好了。

安卓修改大师智改工坊把改包之后那一串动作收在同一个界面里：说一句话，改完自动回编、对齐、签名，还能装回手机看一眼再交付。官网是 www.apkeditor.cn，产品介绍页 https://www.apkeditor.cn/ai-version.aspx。