常见需求案例集（下）：十个进阶「一句话需求」的写法与边界

只需说话，就能让应用变成你想要的样子

安卓修改大师智改工坊 · Windows 桌面端 · 拖入安装包，用中文写需求

先说清楚我们在讲什么。安卓修改大师智改工坊是一款 Windows 桌面工具，把“改 APK”这件事压缩成一句话：拖入安装包，用中文写需求，AI 改 smali 与资源，改完自动回编、对齐、签名、校验，最后一键装到手机或模拟器上看效果。它的介绍页在 https://www.apkeditor.cn/ai-version.aspx，官网是 www.apkeditor.cn。

这是「常见需求案例集」的下半篇，专讲进阶需求。基础需求和进阶需求的分界，不在难不难，而在范围：基础需求改的是一处看得见的东西——换一个图标、改一个名字、换一张图；进阶需求改的往往是“一类东西”或者“多个位置”——所有语言里的同一句话、所有密度档里的同一张图、所有引用同一个接口地址的地方。范围一多，风险就从“改不动”变成三件事：改漏、改多、改错位置。所以进阶需求的一句话，重点不是说得漂亮，而是把范围和验收写进去。

这篇的结构：先讲写法（一句话里该有哪四样东西、这句话是怎么被送出去的、工程目录长什么样），再给十个进阶案例——每条都有“需求原话示范 / 连带影响 / 改完怎么验证”，然后把“打包标记”这套给包留记号的机制拆开讲透，最后是一张翻车点速查表和两个自家改包实例。所有例子都只针对自有应用、内部应用或已获得授权的应用，素材也是自己的；对别人的应用，下面这些事一件都不要做。

一、进阶需求的四个要素：把范围与验收写进那句话

同一句“把文案改一下”，有人一次过，有人要返工三轮。差别不在文采，在于那句话里有没有把下面四样东西交代清楚。这四样是通用规律，不管改的是文案、图片还是地址，都适用。

要素一：目标物要具体到能唯一确定

“把首页那张图换掉”这种说法，执行的一方只能靠猜。更稳的写法是给一个能唯一确定的目标：所在目录加文件名，或者把它“长什么样、在哪个页面、什么位置出现”描述到位。新素材本身用附件送进去，别用“上一条消息里那张”“我桌面上那个”这类指代——指代和路径是两回事，路径是确定的，指代不是。

要素二：范围要写明“改哪、不改哪”

“所有语言都改”和“只改简体中文”是两个完全不同的活。范围不写，执行的一方要么保守（只改默认目录，其他语言照旧），要么激进（连包名、类名里含同一个词的地方一起替换）。主动写一句“不要动包名、类名和任何标识符”，是防翻车最便宜的一招。

要素三：动作与保留项一起说

是替换、删除还是新增？替换时要不要保持原比例、原尺寸、原样式？“把启动页背景换成附件里的新图，保持原来的显示比例”——多这半句，就免掉了后面一次“图被拉变形”的返工。保留项和动作一样重要，因为它决定了这次改动的边界在哪。

要素四：验收标准写进需求

把“改完怎么确认它对了”提前写进需求，例如“改完后应用内五个页面的文案要一致”“通知栏里能看到新的渠道名”。这句话不只是给执行的一方看的，更是给你自己后面验证用的清单——需求写完顺手就得到了一份验收表。

那句话是怎么被送出去的：三层文本

点了「立刻修改」之后，真正送出去的文本其实是三层拼起来的：你的需求原话 + 附件说明 + 一段固定的环境说明。附件说明来自“选择附件”窗口——每挑一个文件，都要给这个文件写一句“它是干什么用的”，说明不能少于 10 个字；确认时还会校验这个文件现在能不能用（存在、不是目录、不是 0 字节、能读出来），同一个路径重复选到只会保留一条。拼出来的样子是“1. D:\素材ew_logo.png —— 应用图标换成这个文件”，跟着需求一起发出去。

环境说明是给执行方看的操作约定：把工作目录切到当前项目下面、改完在项目目录留一个标志文件（ai_done.flag，主窗口轮询到它就知道改完了）、不需要自己打包。这三层里，只有你的原话会进修改历史（history.ini），附件说明和环境说明都不进——历史里干干净净，回看时不会被一堆固定话术刷屏；每条历史都完整保留不截断，右侧点「选择」就能把那条需求填回输入框，“照上次那条再改一遍”不用重新打字。

顺手认识一下工程目录

每个项目在 Project 目录下有一个 8 位随机字符串命名的目录，里面装着：config.ini（应用名、包名、版本号、图标、启动页组件名等基本信息）、source.apk（导入的原始包副本）、apktool 目录（反编译出来的 smali 与资源）、以及反编译日志 apktool.log。

知道这几个文件在哪，有两个直接好处：一是写需求时可以带上“它现在长什么样、在哪个目录”，把目标物说到唯一确定；二是验证时可以自己去翻工程目录核对，不必只看界面上的提示。反编译本身很快（12MB 的包实测约 3 秒），失败也不影响项目——配置、图标、源包已经落地，只是会在界面上说明原因并给出日志路径。像分包 apks、加密包、jar、class 这类解析不出包信息的，程序会以文件名继续建项目，并给一句说明。

另外，程序自带一个话术库：6 大分类（界面美化 / 弹窗引流 / 去除限制 / 常规修改 / 混淆去毒 / 插件添加）共 3000 条成型指令，每条把“要做什么 / 细节要求 / 参数参考 / 范围 / 验收”写全，点「选择」直接填进输入框，点「复制」可以复制正文。进阶需求第一次写不顺，先用模板起个头再补自己那几句，是最省事的路子。话术库在程序目录的 Resources\话术库.xml 里，可以自己改、自己加——把团队里常说的那几句沉淀进去，下次就不用重写了。（这些类别和模板，都只在你自有或已获授权的应用上使用。）

二、十个进阶需求：原话、连带影响与验证

下面十条按“改在哪一层”分成三组：资源层（字、图、语言）、清单与代码层（身份、权限、地址）、数据与逻辑层（默认值、提示、通知、记号）。每条给三样东西：可以直接照抄的需求原话、最容易忽略的连带影响、改完之后的验证动作。再说一次前提：这些需求只对自有应用、内部应用或已获授权的应用使用；给别人的应用做其中任何一条，都越界了。

第一组 · 资源层：改的是包里的字、图与语言

案例 1：批量替换文案

需求原话示范：

「把应用里所有界面出现的“记账”统一改成“记一笔”，只改简体中文文案，英文和繁体保持原样；包括代码里写死的那几处文案；不要改包名、类名和任何标识符。」

连带影响：

界面文案有两个来源：资源文件里的字符串，以及代码里写死的常量。只改资源，会留下“有的页面换了、有的页面没换”这种怪现象——需求里点名“包括代码里写死的”，能一次说清。
全局替换最怕误伤：包名、类名、字段名里完全可能含同一个词。把“不改什么”写进需求，比事后逐处核对便宜得多。
带占位符的文案（%1$s、%d 这类）要连着占位符一起保留，占位符丢了，界面在运行时就会出错。

改完怎么验证：装机后把涉及页面走一遍；再回到工程目录的解包资源里搜一遍旧词，确认它要么绝迹，要么只出现在标识符里（那是不该动的）。正向看一遍、反向搜一遍，这两步做完才算改完。

案例 2：按语言分别改

需求原话示范：

「把欢迎语按语言分别改：简体改成“欢迎回来”、繁体改成“歡迎回來”、英文改成“Welcome back”；默认目录和两个语言目录都要改到，不要漏。」

连带影响：

默认目录是所有语言的兜底：漏了它，个别语言环境下会显示旧文案——这类问题在自己机器上永远复现不出来，只有换成对应语言才看得到。
同一个 key 少改一个语言目录，用户切换语言时就会看到中英混排，比“没改”更难看。
语言目录名按实际目录来写，不要凭印象；不同包的语言目录划分方式可能不一样，写需求前先在工程目录里确认一眼。

改完怎么验证：在设备的语言设置里逐个切换，检查同一页面；或者直接核对每个语言目录里的对应条目是不是都改了。语言这类改动的验证成本主要在“切换”，别省。

案例 3：按密度分别换图

需求原话示范：

「把启动页背景图换成附件里这张新图，各个密度档都要换到，保持原来的显示比例。」

连带影响：

同一张图在包里按密度分成好几档存放。只换一档，部分机型会继续显示旧图，或者把低密度的图放大导致发糊。
这里有一个容易看错的数：解析工具报出的 65534 表示“任意密度”，是哨兵值，不是“最高密度”；真实密度档只到 640（对应 xxxhdpi）。程序在项目列表里挑图标时只认 1~640 的密度档，按最高的一档取原图，不会被这个数骗到，避免挑出一张小图当图标。
格式上 webp 与 png 各有去处：某些环境缺少 webp 解码能力时，界面上只能退化成文字头像显示，但原图仍然照存不误，不影响它进包。

改完怎么验证：装机直接看效果；想更保险，就在工程目录里核对每个密度目录下的文件是不是都换了、尺寸比例与原来是否一致。

第二组 · 清单与代码层：改的是身份、权限与地址

案例 4：改包名做内测版

需求原话示范：

「把包名从 com.example.ledger 改成 com.example.ledger.beta，应用名后面加“内测版”；目标是让内测版和正式版能装在同一台手机上。」

连带影响：

两个版本签名不同，改名之后的包不能覆盖安装正式版——这正是“并存”的前提，别指望它们互相升级。
数据目录跟着包名走：登录态、本地数据库、缓存都不共享，内测版等于全新安装，要重新登录、重新攒本地数据。
服务端、推送、第三方 SDK 的绑定关系往往按包名或签名配置，测试环境要同步把新包名加进白名单，否则会出现“包能装、接口全挂”。
深链、分享回调、桌面快捷方式一般也带包名，回归时顺手看一眼，能省掉一次“装完才发现分享打不开”。

改完怎么验证：两个版本同机并装；在系统设置的应用信息里核对包名与应用名；用内测账号把主流程走一遍，重点看接口与登录。

案例 5：调权限

需求原话示范：

「内测版去掉读取通讯录这条权限，其他权限保持不动；如果代码里有依赖它的地方，一起处理掉，不要留下闪退。」

连带影响：

权限声明在清单里，但真正生效还要看系统版本与目标 SDK：老系统装包时直接给，新系统要用户手动点——验证时两条路线都要走一遍。
有些 SDK 会把这个权限当兜底手段，去掉之后要有替代逻辑（比如“跳过”），否则相关功能会直接崩。
这条只对自家包的内测版成立。给别人的应用调权限，无论出于什么目的，都不在本文讨论范围里，也不要去试。

改完怎么验证：装机后到应用权限页核对清单；跑一遍与该权限相关的功能，看有没有闪退或异常提示。

案例 6：改请求地址

需求原话示范：

「把接口地址从 https://api.example.com 改成 https://api-test.example.com，所有出现的位置都要改到，包括日志上报的地址。」

连带影响：

同一个域名可能出现在好几处：代码常量、资源字符串、assets 里的配置文件。漏一处的典型表现是“主流程通了、埋点全打到正式环境”。
有的包会把地址拆开拼接、或者放进受保护的配置里。改不动的部分先判断清楚，再决定是换思路还是放弃，别硬改。
换域名之后，跟域名绑定的证书类检查要一起确认——地址改了却连不上，八成卡在这里。

改完怎么验证：装机后跑关键流程，到自家测试服务端看有没有收到请求；再翻打包日志确认没有编译层面的报错。两边都对上，才算换干净了。

第三组 · 数据与逻辑层：默认值、提示、通知与记号

案例 7：改数据库默认值

需求原话示范：

「把首次启动时预置数据库里的默认提醒时间从 9:00 改成 8:30；只要求新装的机器生效，已经装过的机器不用管。」

连带影响：

预置数据在包里，但代码里通常还有一份“读不到就用它”的默认常量。两边不一致，就会出现“有的机器 8:30、有的机器 9:00”。
已经装过应用的设备，数据库早就是旧的了——改包只影响新装或清过数据的机器。验证前必须先卸载或清数据，否则你看到的永远是旧值。
只改值，别动表结构和字段类型，避免升级后打不开库。

改完怎么验证：卸载后重装（或清应用数据），进相关页面看默认值；必要时直接读设备上的库核对，比看界面更确定。

案例 8：隐藏入口的风控提示

需求原话示范：

「连续点版本号进入的内部调试入口，把弹出的“仅限内部测试、请勿外传”提示换成一行更短的说明；入口的触发条件和其他校验都不要动。」

连带影响：

入口的触发条件（点几下、在多长时间窗内点完）也写在代码里，改文案时很容易顺手改到判定逻辑——需求里先声明“不要动”，等于给自己上了一道保险。
想清楚“改提示”的代价：这行字本身就是对外流的一层告知与追溯依据，只适合在内测包里做这种调整，正式包不建议动。
这里改的是自家代码里的提示文案与显示条件，不涉及任何第三方应用的校验或防护——那种事一件都不要碰。

改完怎么验证：按原来的条件进入入口，看文案是否符合预期；再对照需求确认没有改动到别的判定逻辑（进不去、或者进的路径变了，都是改动越界的信号）。

案例 9：改通知文案与图标

需求原话示范：

「把通知渠道名改成“任务提醒”，通知小图标换成附件里的这张单色图标；通知内容里的应用名保持不动。」

连带影响：

通知小图标必须是单色的（本质上只使用透明通道），彩色图会被系统压成白块或灰块——“通知栏小图标变成白块”最常见的原因就是这个。
通知渠道一旦被创建，它的记录由系统持有；改名在已装设备上常常看不到变化。必要时换一个渠道 ID，或者卸载重装让渠道重建。
通知里显示的应用名一般由系统取应用的标签，它会跟着应用名一起连带变化，别把它当成两件独立的事。

改完怎么验证：装机后拉一条真实通知，看标题与图标；再在卸载重装（或换过渠道）的机器上确认一次，这一步不能省。

案例 10：加构建标识

需求原话示范：

「给这个内测包加一个可识别的标记：出包时间和打包人；同时把关于页的版本号后面加上 -beta。」

连带影响：

包里的标记是“线索”，不是“版本管理”，更不是防篡改：它能回答“这个包是谁、在哪台机器、什么时候打出来的”，仅此而已。
如果标记加在关于页的展示文案上，记得把版本号和它一起回归——分开改容易漏。
-beta 这类后缀可能被某些渠道或校验逻辑当成“另一个版本”处理，预览与分发环节要同步确认。

改完怎么验证：先看关于页；出问题时按标记定位到人和时间。这种“记号”其实还有一套自动机制，下一章单独讲。

三、给包留一个可识别的记号：打包标记的写入机制

案例 10 说的“标记”，在程序里有一半是自动完成的：每次出包之前，它会自动往反编译工程的 res/values/styles.xml 里写一个 name="info" 的样式，样式的值是一串编码后的标记——里面是这次打包的时间、登录账号、机器码、机器名、系统用户名、程序版本，以及这个包自己的应用名和包名。它写在回编之前，所以会跟着回编一起被编进包里，而不是“存在旁边某个文件里”。

为什么选这个位置、这个形式？因为 styles.xml 是 apktool 工程里几乎必然存在、而且结构极简单的资源文件；style 是资源的一种，写进去不用动任何代码逻辑。读取的一方按 name="info" 这个名字去找，就能把这串标记取出来。

真正写入的时候会碰到三种情况，处理方式各不相同——这也是这套机制最值得看的部分：

工程里的情况	处理方式	为什么这么定
没有 styles.xml	先造一个空壳 <resources></resources>，再往里插	“文件不存在”不该成为写不进标记的理由
有文件，但没有 name="info"	插在 </resources> 前面	不覆盖、不改写文件里已有的任何一个样式
已经有 name="info"	整块替换成新的那一份	重新打包时，时间等字段会更新为这一次的值

两个克制的地方值得单独说。第一，写回去时会记住文件原来有没有 BOM（字节顺序标记），保持一致——这种细节不影响“能不能读”，但能少给回编工具添堵。第二，也是最关键的：写不进去不拦打包。任何一个环节出问题（文件读不出、结构不对、没有可插入的位置），它都只记一句话就继续往下跑，这句话会出现在项目目录的 pack.log 里。取舍很直白：打一个“少了标记”的包，总比整个包打不出来强。

使用技巧上，可以把这条日志当作出包自检的一环：打完包在工程目录里打开 res/values/styles.xml，看到 name="info" 在，就说明标记写上了；把它发出去之后，如果同事反馈“这个包有问题”，标记能回答“这是哪台机器、什么时候打的那一份”——很多“我装的到底是哪个包”的扯皮，到这一步就结束了。再强调一次它的边界：它是给人做追溯用的线索，不是防篡改，也不是加密，不要拿它当安全机制用。

四、改完怎么验证：一条四步流水线 + 几份日志

不管改的是上面哪一类，验证的路径是同一条：回编 → 对齐 → 签名 → 校验。改完之后，执行的一方会在项目目录里留下标志文件，主窗口每 2 秒轮询一次，读到就自动弹出打包窗口，四步跑完，产物落在项目目录的 build 里：unsigned.apk（回编产物）、aligned.apk（对齐产物）、signed.apk（签名产物，这才是能装的）。

四步里最容易被当成“多余”的是最后一步校验。前三步只看退出码——命令跑完了就算过；而“到底签没签上”，只有校验这一步说了算，它还会把签名证书的信息打印出来。密钥格式不对（私钥不是 DER、证书不是 X.509）这类问题，也只有这一步会明确报出来，而不是让你装到一半才发现。

再往下就是装机：用 adb 找手机或模拟器，装上并拉起应用，拉起之后还会用系统命令复核一次前台应用确实是它；手机走投屏、模拟器把窗口提到最前面，改完立刻就能看。想留一份产物，「保存 APK」的默认文件名是“应用名_版本号_signed.apk”，也可以直接打开所在文件夹。

出问题时看哪份日志，这里给一张对照表：

你遇到的现象	先看	再看
包没打出来	pack.log（打包全过程与每一条命令）	apktool.log（反编译那一步的完整输出）
装不上、或装上了打不开	pack.log 的签名与校验段	设备上的安装提示原文
改的地方没生效	工程目录里对应的资源文件本身	修改历史里这条需求的原话（对照这次到底改了什么）
界面或吸附异常	dock.log（吸附与布局的自检记录）	error.log（未处理异常）

这张表的用法是“从粗到细”：先看那句话级别的日志（打包说了什么），再看命令级别的输出（工具报了什么），最后才回到资源本身逐处核对。顺序颠倒的话，很容易在几百行输出里翻半天却抓错重点。

五、两个自家改包实例复盘

上面十条是“怎么写”，下面两个例子是“怎么用”——都来自我们自己或同事的日常场景，改的是自家应用、用的是自家素材。每个例子都按“以前怎么做 / 现在一句话怎么做 / 改完怎么验证”三步讲。

实例一：自家「记账助手」内测包——把界面里的“记账”统一改成“记一笔”，顺带换上新 logo。

以前的流程是一条不短的流水线：先在编辑器里全局搜这个词，逐条判断每一处是“文案”还是“标识符”；确认之后改资源文件、再找代码里硬编码的那几处；然后回编、对齐、签名、装机，把主要页面走一遍确认没有漏网的。最费时间的恰恰是“判断”和“复核”两步——搜出来的每一处都要人看一眼，看完还要再看一遍。

现在一句话：把自家安装包拖进安卓修改大师智改工坊，在需求框里写“把应用里所有界面出现的‘记账’统一改成‘记一笔’，只改简体中文文案，包括代码里写死的几处；不要改包名、类名和标识符”，把新 logo 作为附件加上、写清用途（说明不少于 10 个字，避免“这个文件是干什么的”只能靠猜），点「立刻修改」。左边继续显示需求与历史，右边并排的窗口里就是在改。改完自动打包，装到机器上把主要页面走一遍；回到工程目录的资源里搜一遍旧词，确认它只可能出现在标识符里。

这个例子里“范围”要素最值钱：需求里那句“不要改包名、类名和标识符”，省掉的正是以前最花时间的“逐处判断”。验证也变成了两件确定的事——正向看页面、反向搜旧词，做完就是做完了。

实例二：内部「巡检打卡」工具——启动页背景图按密度整组换新，同时改通知渠道名。

以前：先翻资源目录确认背景图有哪些密度档，从设计那边拿对应尺寸的好几份图，一档一档替换；再回编签名装机。通知渠道改名更麻烦，装完还要在真机上反复看通知，因为“渠道记录是系统持有的”，改了不一定刷新。

现在一句话：“把启动页背景图换成附件里这张新图，各个密度档都要换到，保持原来的显示比例；把通知渠道名改成‘任务提醒’”——两张用途写清楚的附件一起送上，点「立刻修改」，改完自动打包、自动装机拉起来看。

验证分两段：启动页一闪而过，就多看两次；通知渠道则必须在卸载重装过（或换过渠道）的机器上确认，这一步不能省。另一处细节是密度：程序在项目列表里挑图标时按真实密度档取最高的一档，不会把“任意密度”的哨兵值当成最高密度——知道这一点，你在核对时就不会被那个 65534 吓到。

六、十条需求的翻车点速查表

把上面十条里最容易出问题的点收成一张表。用法很简单：动手之前扫一眼对应那行，把“一条防线”写进你的需求里。

需求类型	最常见的翻车	一条防线
批量替换文案	误伤标识符或漏掉代码里的文案	需求里同时写明“改什么”和“不改什么”
按语言分别改	漏掉默认目录或某个语言目录	先列出要改的语言目录，改完逐个核对
按密度分别换图	只换了一档，部分机型不生效	解包核对每个密度目录，确认尺寸比例一致
改包名做内测版	忘了同步服务端与 SDK 的白名单	装完先跑接口与登录，再谈别的
调权限	依赖被切断后相关功能崩溃	回归与该权限相关的全部功能入口
改请求地址	埋点或次要地址漏改，数据进了正式环境	在测试服务端看完整请求，不只看主流程
改数据库默认值	旧机器没变化就以为改失败了	卸载重装或清数据后再验证
隐藏入口的提示	顺手改到了入口的触发条件	需求里声明“其他逻辑不要动”，改完按原路径进一次
通知文案与图标	彩色小图标变白块、渠道名不刷新	用单色图标；在重装过的机器上复核
加构建标识	把标记当成防篡改或版本管理	只把它当追溯线索，版本另做管理

七、用户评价：进阶需求他们是怎么写的

「批量改文案那次，最省的是不用再逐条判断“这处是文案还是标识符”——我把不改什么写在需求里，改完只做了两件事：翻页面、搜旧词。」

—— 林工 · 企业内部工具开发

「我们做内测版共存，包名改完之后先在测试服把白名单加上，再装的包。这个顺序写进需求里之后，新人也不会漏。」

—— 阿凯 · 企业 IT 运维

「密度这件事我以前只换一张图，被同事反馈“我的手机上还是旧的”。后来按说明每个密度档都换，问题就没了。」

—— 小庄 · 安卓应用维护

「通知图标原来放的是彩色图，通知栏永远是一块白。换成单色之后一次就对上了，这个坑值得写进教程。」

—— 周舟 · 个人开发者

「打包标记我是当“出厂钢印”用的：发出去的包出问题，先看它是哪台机器哪个时间打的，沟通成本一下就降下来了。」

—— 老陈 · 小型工作室安卓开发

试用反馈的三类归纳（来自内部试用用户的交流整理，属于文案表达）

提得最多的是“范围写清楚”这一条：把“不改什么”写进需求的人，返工次数明显更少；
其次是“验证方式”：多数人会固定做“正向看一遍、反向搜一遍”这两步，语言与密度类改动则必须换机器或换语言再看；
关于打包标记，几乎所有人都把它当成排查工具而不是安全机制——这个认知是对的，也建议保持。

合规提醒：本文与这款工具面向自有版权或已获得授权的应用，适用于学习研究、企业内测、自有应用迭代等合法场景。请勿用于破解他人付费应用、绕过安全机制或未获授权的分发。文中所有实例均基于自有应用与自有素材；涉及权限、提示、标识等改动，只应在你拥有版权的包上做。

八、结语：把“一句话”写成一件事

把这篇收成一句：进阶需求的一句原话，其实是一份小型的施工单——目标物、范围、动作与保留项、验收标准，四样写齐，改动就等于完成了一半；剩下的一半，是那条固定的验证路径：四步打包、装机复核、出问题按日志从粗到细地看。再加一件小事——给包留个记号，让“这是哪一份包”永远有答案。

这就是我们用安卓修改大师智改工坊做这些事时看到的形态：只需说话，就能让应用变成你想要的样子——批量文案、多语言、多密度、包名、权限、接口地址、默认值、提示、通知、构建标识，都能被“一句话 + 附件 + 验收”这套写法说清楚，改完自动回编、对齐、签名、校验，再一键装到设备上看效果。

产品介绍页与下载入口：https://www.apkeditor.cn/ai-version.aspx（官网 www.apkeditor.cn）。

只需说话，就能让应用变成你想要的样子

Windows 桌面端 · 拖入 APK · 中文写需求 · 自动回编 / 对齐 / 签名 / 校验 · 一键装机看效果

立即下载智改工坊（AI 版）

环境要求：Windows 桌面系统；首次使用建议在「参数设置」里做一次工具链体检