客户发来一个 APK，先别急着改：五个必须看清的信息

大多数人拿到一个 APK 的第一反应是「解开看看」。这个反应很自然，但往往是最费时间的顺序。因为在你解开之前，有五件事只要看一眼就能知道，而它们决定了你后面所有的动作该怎么做。

这五件事是：包名、版本号和版本名、签名、最低支持的系统版本、图标密度。它们都不需要反编译，看一眼就能拿到，加起来不超过五分钟。但如果你跳过这五分钟，很可能在改了两小时之后才发现——这是个加固过的包，根本改不了；或者这是个分卷包，你手上只有一半；或者这个包已经被别人改过一遍，签名早就不是原厂的。

这篇文章讲的就是这五分钟怎么花。它的立场很明确：改包的手艺，一半在改，一半在看。会看的人，动手次数少、返工少、交得快；不会看的人，看起来一直在忙，实际上一直在给自己挖坑。

一、为什么「先看再改」比「先改再看」快得多

这两个顺序的差别，第一次改包的人感受不到，改过二十次的人深有体会。

「先改再看」的路径是这样的：解开 → 找到要改的地方 → 改 → 回编 → 签名 → 装机 → 发现不对 → 回头找原因。问题在于，到了「发现不对」这一步，你已经在一个被改动过的目录里了。你不知道是原始包本身有问题，还是你的改动有问题。要区分，就得再解一次原包做对照，等于把前面的活重做一遍。

「先改再看」还会遇到一种更糟的情况：你改的东西根本改不进去。比如包是加固过的，代码段是加密的，你反编译出来的是一堆看不懂的东西；比如包是分卷的，主包里没有你要的资源；比如这个应用的资源做了混淆，目录名全是 abc。这些情况在动手之前看一眼就能知道，动手之后才知道，就白花了时间。

「先看再改」的路径是：看一眼它是什么 → 判断能不能改、该怎么改 → 再动手。多花的五分钟，买到的是「知道自己在干什么」。

二、第一件事：它是什么包

「什么包」问的不是它是什么应用，而是它的文件形态。同一个应用，可能以三种不同的形态到你手上。

区分的方法很简单：看文件后缀和数量。如果是单个 .apk，就是第一种。如果是一堆文件、里面有 base 加若干 split，那是第二种。如果是单个 apk 但体积明显偏小、或者里面的资源目录结构和常见的不一样，就要怀疑是第三种。

第三种最容易被忽略，也最容易出事。因为它看起来完全正常，能装、能开、能改。但它的签名是别人的，你在这个基础上再出包，要么用别人的签名（你没有密钥），要么换一个新签名（那它就成了另一个应用，装不上、升不了）。

三、第二件事：它能不能改

这个问题听起来刺耳，但确实是很多新手第一次撞墙的地方：不是所有 APK 都能按常规方式改。

常见的有三种情况会让「改」变得困难。第一种是代码加固，代码段被加密保护，反编译出来是一堆无法阅读的内容。这类包在资源层面还能改（换图、改文案、改名称），但在代码层面基本无从下手。

第二种是资源混淆或资源压缩，资源文件名被重命名成一串无意义的字符，你要找的那张图或那句话，得靠内容去匹配，不能靠名字。这不影响能不能改，但影响改的效率，需要换一种找法。

第三种是完整性校验，应用启动时会检查自己的文件是否被改动。这类包改完之后能装上，但一打开就退出。遇到这种，正确的做法不是硬碰，是联系应用方——因为你没有授权去绕过它的校验。

这四种判断，其实是同一个判断：这个包值不值得我花时间。值得就往下走，不值得就当场说清楚，别接了活做到一半才发现做不了。对客户负责，也是对自己的时间负责。

四、第三件事：改完之后怎么验证

这一条最容易被跳过，但它决定了你交付的质量。

验证需要三样东西：一台能装的设备、一个能登录的账号、一条能走通的主流程。听起来理所当然，实际上经常缺。比如应用需要企业账号才能登录，你没有；比如主流程要连内网，你连不上；比如设备系统版本太低，装不上新包。

这三样应该在动手之前确认，而不是在装上去打不开的时候才发现。确认的成本很低：问一句「这个应用要登录吗，能给我一个测试账号吗」，比改完之后卡在登录页要省事得多。

还有一层：验证要验什么。改一处文案，验证的是那一处文案对不对；但如果这个文案出现在首页，你还要顺带确认首页其他东西没被带坏。所以验证的清单至少包含两条：改的那一处对了，没改的那些没坏。

五、五个必须记下来的信息

前面三件事是判断，这一节是记录。有些信息你现在看到了，但半小时后就忘了，而后面每一步都要用到它们。

这五项里，前四项都能在不解包的情况下拿到，第五项需要解包之后看目录结构。所以它们正好可以分两步：先在拿到包的时候记前四项，解开之后补第五项。

记在哪里？不用很正式的工具，一个文本文件就行。但格式建议固定：一行一个应用，用固定的分隔符。因为你会需要在一堆应用里找某一个，格式乱了就找不着。

六、案例一：看了一眼，省下两小时

第一个案例里，「看一眼」直接改变了一单生意的做法。

一个做餐饮连锁的客户发来一个 APK，说要改三处：应用名称换成他们新的品牌名，首页横幅换成新店开业的图，启动页加一句「xx 餐饮」。需求很清楚，价格也谈好了。

按习惯，先没解包，直接在手机上把这个包的信息看了一遍：包名是 com.xxx.waimai 这种典型的第三方平台包，版本号不小，签名证书那一栏显示的是一家技术公司的名字，不是客户自己的公司。

这个信息很关键。它说明这个应用不是客户开发的，是某个外卖平台给商家用的客户端。客户想改的「自己的应用」，其实是平台的应用。

于是先给客户打了个电话，问了一句：「这个应用是你们自己开发的，还是平台给的？」客户说是平台给商家用的。到这里，这件事的性质就变了——改一个自己没授权的第三方平台应用，既不合规，也不可行：平台的应用会校验、会更新、会覆盖你的改动。

后面的处理是：告诉客户，能做的不是改这个平台应用，而是做一个自己的品牌小程序或独立应用，把菜单、门店、活动这些内容装进去。这单活从「改包」变成了「做一个自己的入口」，价格更高，但对客户是真有用的。

如果当时先解包、先动手改，会发生什么？会花两小时改完，装上去能用，交付，收钱。然后平台一更新，改动全没了，客户回来找你。再改一遍，再被覆盖。三次之后，客户会觉得你不专业。

所以这五分钟真正的价值，不是省时间，是让你在动手之前就知道这件事该不该做。

七、案例二：改到一半才发现只拿到一半

第二个案例是纯粹的流程问题，但很典型。

客户从某个渠道下载了一个应用，把下载下来的文件打包发过来。发过来的是一个压缩包，解开来里面有四五个文件：一个 base.apk，几个名字里带 config 的 apk，还有一个 json。

没细看，直接拿体积最大的那个 base.apk 去改。解开、改图、改文案、回编、签名，一切顺利。装到手机上，应用能打开，但首页一片空白，几个图标是默认的安卓小机器人。

原因很简单：这个应用的资源被拆成了多份，主包里只有骨架，图片和语言资源在另外几个分卷里。只改主包、只装主包，等于装了一个缺零件的东西。

正确的做法是：把分卷一起处理，或者先把分卷合并成一个完整的包再改。判断方法也很简单——看文件名。带 config、带 split、带架构名（比如 arm64）的，都是分卷。看到这类文件，就不该只拿一个去改。

这个案例的教训不在技术，在拿到东西先看清楚一共有几件。客户发来一个压缩包，你不解压就不知道里面是什么；解压了不看文件名，就不知道哪个是主、哪个是辅。这两步加起来一分钟，能省掉一次重做。

八、签名怎么读：三个数看懂一张证书

签名是这五项信息里最技术、也最容易被跳过的一项。但它其实很容易读，只要看三个地方。

第一个：证书是谁的

证书里有一个主题字段，通常写着组织名。原厂包的这里一般是公司名或者产品名，看起来像个正经名字；改过的包、调试包，这里往往是「Android Debug」或者一串无意义的字符。这一栏决定了这个包能不能作为「你的包」继续往下走。

第二个：用的什么算法

签名有不同的方案，越新的方案越安全，但对老系统兼容性越差。证书里能看到实际用了哪几套。如果只看到最老的那一套，说明这个包是给很老的设备准备的；如果看到好几套并存，说明兼容性做得比较全。你后面出包时，方案不能比它少——少了，老设备就装不上。

第三个：指纹是多少

指纹是证书的一串摘要值，长度固定，看起来像乱码。它的用处是「确认是不是同一把钥匙」：你手上有两个包，比一下指纹，一样就是同一个签名，不一样就是两个应用。这个动作在你怀疑「这个包是不是被人改过」的时候特别有用。

把这三个数记下来，一共不到一分钟。但它们在后面会反复被用到：出包时要选对方案、装机时要判断能不能覆盖、交付时要跟客户说清「这版和上版是同一个签名，可以直接升级」。

九、最低系统版本，决定了签名方案怎么选

这一项看起来只是个数字，实际上它管着一件很实际的事：你的包能不能装到目标设备上。

原理是这样的：安卓的签名方案有几代，越新的越严格。老系统只认最早的那一代，新系统几代都认。所以如果你的应用要覆盖老设备，出包时就必须保留最早那一代方案；如果你的应用只面向新系统，那可以只用新方案，更安全也更小。

问题在于，这个选择不是拍脑袋定的，是由「最低系统版本」这个数字定的。数字低，就必须留旧方案；数字高，才可以不要。工具通常会在保存配置时做一次检查：如果最低版本低、而你把旧方案关了，它会拦住你，因为这个组合一定装不上。

这个拦截看起来有点烦，但它挡住的是一个很难自己发现的错误。因为这类错误不会在出包时报错，只会在装到某台老设备上时失败，而那时候你手上未必有那台设备。

所以「看一眼最低系统版本」这件事，实际是在提前决定两件事：签名方案怎么配、要不要准备一台老设备做验证。这两件事都不难，难的是想起来。

十、图标密度：换了图为什么会糊

这是新手最常踩的一个坑，也是「看一眼」能完全避免的坑。

一个应用的图标，通常不是一张图，而是一组图：同一张图按不同尺寸放在不同目录里，系统按设备屏幕的密度去挑最合适的那一张。常见的有五六个目录，从很小的到很大的都有。

如果你只替换了其中一个目录里的图，会发生什么？在高密度设备上，系统会去找大尺寸那一张，找不到就用别的目录的图放大——放大就糊。在低密度设备上，系统找小尺寸那一张，你换的是大图，它缩小——缩小一般还行，但也可能因为比例不对而变形。

所以正确的做法是：先看清这个应用有几个密度目录、每个目录里的图是多大，然后按同样的尺寸、同样的目录逐个替换。这一步看起来笨，但它是唯一不会出错的做法。

还有一个细节：图的格式。有些应用用的是带透明通道的格式，有些是不带的。你把带透明的图放进不带透明的目录，透明部分会变成黑块；反过来，把不带的图放进带透明的目录，一般没问题但体积会变大。看一眼原图的格式，比事后猜要快。

这些细节凑在一起，构成了「看图」这件事的完整含义：不是看一眼有没有图，是看清它有几个、多大、什么格式、放在哪。这四样看清楚了，换图就是纯体力活，不会出错。

十一、语言目录：只改中文，常常改不全

这一条是「改文案」这个需求里最容易出岔子的地方，而且它出岔子的方式很隐蔽：你以为改完了，装机看着也对，客户用了一周说「英文界面还是旧的」。

原因在于，应用里的文字通常不是只存一份。它按语言分目录存，中文一份、英文一份，有的应用还有十几种。你改了中文那份，英文那份原封不动。系统语言是中文时读中文那份，是英文时读英文那份。

所以改文案之前要看的是：这句话一共在几个语言目录里出现。如果只打算改中文，那就明确告诉客户「只改了中文界面」；如果要全改，就一份一份过。这两件事都不难，难的是你根本没意识到有第二份。

还有一种更细的情况：同一句话在同一个语言目录里出现两次，分别用在两个不同的地方。你只改了其中一处，另一处还是旧的。这种情况在界面上看起来像是「没改成功」，实际上是「改了一半」。

判断方法很简单：改之前，用这句话的原文在整个资源目录里搜一遍，看命中几处。命中一处，放心改；命中多处，逐个确认它们各自用在哪里，再决定改哪几个。这个动作花不了一分钟，但能省掉一次「客户说没改对」的返工。

十二、包名与版本号：两个最容易记错的数

这两样东西都是「看着简单、抄错就完」的类型，所以值得单独说。

包名是一串用点分隔的标识，看起来像网址反过来写。它长、它没有意义、它经常包含数字和缩写，所以人抄的时候极容易错一个字符。而它错了会怎样？你以为自己在改 A 应用，实际上在改 B 应用，或者出包时因为包名对不上而装成了两个应用。

版本号有两个：一个是给系统看的整数，每次出包必须比上一个大；一个是给人看的字符串，可以带小数点。这两个数经常被混为一谈。混了会怎样？系统只看那个整数，你改了字符串没改整数，系统认为这是同一个版本，装不上去，或者装上了但被认为是旧版。

所以正确的记录方式是分开记：包名照抄（不要手打，复制）、版本整数单独一行、版本字符串单独一行。三个值，三行，不要合并。

这三个值还有一个用处：它们是项目身份。当你有十个项目同时在做，靠什么区分？靠文件名不靠谱（文件名会改），靠包名最靠谱，因为它在应用内部，改不了也没人会去改。所以项目命名建议直接用包名，一眼就知道是哪个。

十三、看清单：三分钟知道自己改的是什么程序

清单是 APK 里最核心的一个文件，它决定了这个应用叫什么、要什么权限、从哪个界面启动、支持哪些系统版本。看清单不需要会写代码，看几个关键项就够。

应用名称

这里显示的是装到手机上以后，图标下面那行字。很多人说要「改应用名」，改的就是这里。改的时候要注意长度：太长了在桌面上会被截断，显示成「xxx…」，看起来像坏了。一般建议不超过八个汉字。

入口界面

这里指定了点击图标之后先进哪个界面。这个值一般不用动，但如果你要改启动页，就要知道它——因为启动页往往就是这个入口界面里的第一个画面。改错这里最典型的后果是「点开就退出」，因为系统找不到该启动的东西。

权限列表

这里列出这个应用要哪些系统能力。看这一项有两个用处：一是判断这个应用「该不该要这些权限」（比如一个计算器要读通讯录就很可疑）；二是你自己加功能时知道该不该补权限。加了不该加的权限，可能装不上，也可能上架时被拒。

最低与目标系统版本

前面说过最低版本决定签名方案。目标版本则是这个应用「针对哪个系统版本做的适配」，它影响一些系统行为。这两个数看一眼记住就行，不用深究。

看清单这件事，最大的价值不是「知道」，是确认自己的理解跟这个应用的实际结构对得上。你以为要改应用名，看了清单发现要改的那行字其实在另一个配置文件里；你以为不用动权限，看了清单发现这个应用根本没有存储权限，那你要加的「保存图片」功能就得先补权限。

十四、权限这一项，比想象的更容易出事

权限在改包里是个小项，但它引发的失败往往很难定位，所以值得单独讲。

第一种翻车：加了权限，装不上。原因是有些权限在老系统上是「安装时授予」的，如果清单里写了但系统版本不支持，安装会直接失败。这类失败的错误提示往往不明确，看起来像是包坏了。

第二种翻车：加了权限，能装，但功能一用就崩。原因是权限在清单里声明了，但运行时还需要向用户申请，而应用代码里没有申请的逻辑。清单只是「声明我想要」，真正拿到还需要一步。

第三种翻车：删了权限，功能悄悄坏掉。这种最难发现，因为应用能装、能开、大部分功能正常，只有用到某个能力时才失败，而你可能根本走不到那条路径。

所以对权限的正确态度是：能不动就不动。如果确实要动，动之前先确认三件事：这个权限在这个系统版本上存不存在、应用有没有对应的运行时申请、删掉它之后哪些功能会用到。这三件事都能在清单和代码里查到，花五分钟。

十五、改之前的五分钟清单

把前面所有内容压成一张可以照着做的清单。每次拿到新包，走一遍，五分钟。

走完这五步，你会得到一张纸：上面有五个值、三个判断、一个结论——这个包能改、该怎么改、改完怎么验。这张纸就是你后面所有动作的依据。没有这张纸，你是在摸黑走；有了这张纸，你是在按图施工。

这五步里最容易被跳过的是第 4 分钟和第 5 分钟，因为它们「看起来不影响改」。但恰恰是这两步决定了改完之后能不能装、装了之后好不好看。跳过它们的代价，通常在交付那一刻才结算。

十六、手机上就能做这一步：包发过来，当场看清

前面这五分钟，传统做法是坐在电脑前做的：把包传到电脑、打开工具、点开信息。这一套流程有个前提——你得在电脑前。

但包到你手上的场景，往往不在电脑前。客户在微信上发来一个文件，你在外面；同事在群里甩来一个安装包，你在会议室；自己从某个页面下载下来，你正躺在床上。这时候「传回电脑再看」这个动作，就把五分钟变成了五十分钟。

所以更顺的做法是：把开箱检查这件事也搬到手机上。包就在手机上，直接打开看，看完再决定要不要传电脑细做。安卓修改大师智改工坊的安卓版就是这个用法——收到包，导入，包名、版本、签名、支持的系统版本、图标资源全都摆在项目信息里，不用先传电脑，也不用记命令行参数。

这个顺序调整带来的改变不只是省时间，更是决策提前。你可以在回客户消息之前就知道「这个包能改」或者「这个包不能改」，于是可以立刻回复，而不是「我看一下再回你」。在接单这件事上，回复速度经常比报价更能决定成不成。

十七、三种版本在这五分钟里分别做什么

安卓修改大师有三个版本，在这个「先看」的环节里，各有各的顺手之处。

一个实际的搭配是：安卓版做初判，电脑版做复核，经典版做留痕。初判只需要一分钟，判断「能不能接」；复核在动手之前，确认「该怎么改」；留痕在交付之前，把关键信息写进交付说明。三步加起来不超过十五分钟，但它们把「拍脑袋开工」变成了「有依据开工」。

十八、五个常见误判

这一节列的是「看了但看错」的情况，比「没看」更危险，因为你以为自己看过了。

误判一：把版本字符串当版本号

看到界面上写着 3.2.1，就以为版本号是 3.2.1，出包时把它改成 3.2.2。结果装不上去——因为系统看的是另一个整数，那个数没变。正确的做法是两个都改：整数加一，字符串跟着走。

误判二：把「能打开」当成「签名对」

有些包用调试签名也能装、也能开，看起来一切正常。但调试签名不能用于发布，而且不同次的调试签名还不一样，装第二个版本时会冲突。判断签名对不对，不能看能不能开，要看证书信息。

误判三：以为图标只有一张图

在文件管理器里预览到一个图标，就以为只有这一张。实际上它在五六个目录里各有一份。只换一张的后果前面说过：糊、变形、或者干脆不显示。

误判四：以为分卷包合并了就等于完整包

把分卷合并成一个包，看起来完整了，但合并的顺序和方式有讲究，弄错了会出现「能装但缺资源」的情况，而且比只改主包更难排查，因为包本身看起来是完整的。合并这件事，要么用可靠的工具，要么就别合，直接按分卷处理。

误判五：以为「原厂包」一定是没改过的

客户发来的「原厂包」，可能已经经过渠道二次处理：加了渠道标识、换了启动图、甚至重新签过名。这类包在信息上看起来正常，但签名那一栏会露馅。所以「客户说是原厂」和「信息显示是原厂」是两件事，以后者为准。

十九、把检查变成习惯：三个动作

知道了要检查，和每次真的检查，中间差着一段距离。要让检查变成习惯，得把它压缩成不用想就能做的动作。

第一个动作：导入前先看一眼文件列表。不需要任何工具，就在文件管理器里看：几个文件、什么后缀、体积多大。这一步能挡住分卷包和压缩包这两个坑。

第二个动作：导入后先看项目信息页。包名、版本、签名，三个值扫一眼，跟客户说的对不对得上。对不上就当场问，别往下走。

第三个动作：动手前先写一行字。写下「这次要改什么、改完怎么验」，一行就够。这一行字的作用是让你在改的过程中不跑偏——很多人改着改着顺手改了别的东西，最后自己都说不清改了哪些。

这三个动作加起来不到三分钟，但它们覆盖了前面讲的绝大部分风险。习惯的好处就在这儿：你不需要每次都想清楚为什么要做，做了就对了。

二十、为什么安卓修改大师安卓版把信息摆在最前面

工具的设计往往反映它对「什么事最容易出错」的判断。安卓修改大师智改工坊把项目信息放在最显眼的位置，是因为改包这件事出错最多的地方，不是改，是改错了对象。

导入一个包之后，你会先看到它是什么：包名、版本、签名、支持的系统、图标和资源的概况。这些信息不是装饰，它们是你在动手前必须确认的东西。摆在这里的意思是：先看清，再动手。

再往后是改：你可以用一句话说清想改成什么，AI 智能改包引擎负责落到具体文件、处理编码和资源索引。这一步把「找文件、改编码、重索引」这些容易出错的机械动作接走了，让你专注在「想改成什么」上。

然后是出包和装机：回编、对齐、签名、校验四步自动跑完并分别给出结果，装到设备上之后会把版本信息读回来。这一步的意义是「让你看到证据」，而不是靠猜。

整条链路合起来就是那句话：只需说话，就能让应用变成你想要的样子。而它成立的前提，是前面那五分钟的「看清」——看清了对象，说的人才说得准，机器才做得对。

安卓修改大师智改工坊的产品介绍页在 https://www.apkeditor.cn/ai-version.aspx，官网是 www.apkeditor.cn。如果你想试试「包发到手机上，当场看清它是什么」，安卓版是最快的那条路——不用装环境、不用记参数，导入就看。

二十一、顺便看一眼体积：改完为什么变大了

还有一项信息值得在动手前后各看一次：包体积。它不是必看项，但它是一个很好的健康指标。

改完之后体积变大，通常有三个原因。第一是换进去的图比原来的大，尤其是从设计稿直接导出的图，尺寸和压缩率都没按原目录的规格来。第二是回编时把原始资源也带进了产物，等于一份东西存了两遍。第三是语言的资源没精简，包里有十几种语言的字符串，你只用一种。

这三个原因里，第一个最常见也最容易修：按原目录的尺寸重新导出一次就行。第二个需要看一眼产物目录结构。第三个一般不用管，除非体积大到影响分发。

反过来，体积突然变小也要留意。变小通常意味着「丢了东西」——某个资源目录没被带上，或者某个分卷没合并进来。这时候装机往往能装上、能打开，但某个页面会缺图。这种情况比变大更危险，因为它不吵不闹。

二十二、把「看」这件事，变成你的第一反应

写到这里，前面那些具体的方法可以忘掉，但有一个反应值得留下：拿到任何东西，先看清它是什么，再决定怎么动它。

这个反应不只适用于改包。拿到一份需求，先看清它要的是什么；拿到一个 bug，先看清它是哪一类；拿到一个客户，先看清他真正在意什么。所有「先动手后想」的失败，本质上是同一个失败。

改包只是把这个道理变得很具体：五分钟的看清，能省掉五小时的返工；一句「这个包是谁的」，能挡掉一单注定做不成的生意。而这些判断，都不需要你有多高的技术，只需要你愿意在动手之前停一下。

停下来看一眼，是这门手艺里最便宜、也最容易被跳过的一步。跳过它的人很多，所以做到它的人，看起来就像很专业。

拿到一个 APK，先别急着解开。花五分钟看清五件事：它是什么形态的包、能不能改、改完怎么验证、五个关键值是多少、资源结构长什么样。这五分钟买到的是「知道自己在干什么」，而它省下的，通常是一次完整的重做。安卓修改大师智改工坊把这些信息摆在项目最前面，包发到手机上就能看清，看完直接接着改。

www.apkeditor.cn

顺便说一句：这篇里所有的「看一眼」，都不需要你懂代码。包名是一串字符，版本号是两个数字，签名是一张证书，密度是一堆目录名——它们全都是「信息」，不是「技术」。把信息看懂，是这个行业里门槛最低、回报最高的一件事——它不需要天赋，只需要你愿意在动手之前，先停下来看一眼。

合规提醒：本文所述操作仅适用于你拥有或已获得授权的应用。代他人修改应用前请取得书面授权，不得用于去除授权校验、绕过付费限制、冒充官方发布等用途；相关行为可能违反《著作权法》《计算机软件保护条例》与《网络安全法》。

改包的手艺，一半在改，一半在看。

安卓修改大师智改工坊把「说一句」和「出成品」之间那一大段收进同一个界面：自动回编、自动对齐、内置签名、一键装回手机看效果，还能把包还原成能编译的工程交给开发接手。官网是 www.apkeditor.cn，产品介绍页 https://www.apkeditor.cn/ai-version.aspx。