大部分人对这套工具的印象停留在"写一句话就能改包"。但如果你只把注意力放在自己写的那句话上，就会忽略掉一件更有意思的事：那段真正送进 AI 的文本，并不是你写的那句话本身。它是一段三层拼装出来的内容——你的原话、附件说明、以及一段固定的环境说明。理解这三层各自负责什么，你才算真正会用这个工具：知道哪些话该说、哪些话不必说，也知道 AI 为什么会"知道"该去哪儿改、改完怎么回报。产品介绍页在 https://www.apkeditor.cn/ai-version.aspx，官网是 www.apkeditor.cn。

先看一眼拼装的全貌。假设你在输入框里写的是"把应用图标换成附件里这张图"，那么实际发出去的文本大致长这样：

把应用图标换成附件里这张图

【附件】下面这些文件我已经准备好放在磁盘上了，请按各自的说明使用（路径是本地绝对路径，需要放进应用里的，请自己决定放到 apktool 工程的哪个位置）：
1. D:\素材\新图标.png —— 应用图标换成这个文件

你是一位专业的中文助手……请将工作目录切换到 <项目工作目录> 下面进行修改，按照上面的需求修改完毕后（怎么算修改完毕：请在**确认全部改完**之后，在项目工作目录下面生成一个名为 ai_done.flag 的标志文件……），不需要自动打包。

三段之间用空行隔开，位置固定：原话在最前，附件居中，环境说明压在最后。下面逐层拆开讲——每层为什么存在、它是怎么拼进来的、以及你在使用时的注意事项。

一、第一层：原话——你写什么，AI 就收到什么

第一层最简单：你在输入框里写的那句需求，去掉首尾空白之后原样送出去。它不是"摘要"、不是"翻译"，就是你自己写的那段字。这一层完全由你负责——AI 对你意图的全部理解，起点都在这里。

但这里有一个机制上的关键分歧点，值得单独讲：写进历史的和发出去的，不是同一份内容。点「立刻修改」的时候，程序会把你的需求原文记进项目的修改历史（history.ini），而在发送之前，才在原文后面追加附件说明与环境说明。也就是说——

• 历史里留下的，只有你写的那句原话，加上修改日期；那段固定环境说明不进历史，附件说明也不进历史。
• 发出去的那一份，才是三层拼装后的完整文本。

为什么要这么分？理由很朴素：回看历史是为了找回你自己说过的话，不是看一份被固定模板刷屏的流水账。如果每一历史条目后面都跟着同一段"请将工作目录切换到……、改完生成标志文件……"，几十条记录读起来会变成一场灾难。而现在，历史列表里是干净的一条条需求原文（完整显示、不截断），每条前面带序号和时间；你点那条记录右侧的「选择」，原话就被填回输入框——想"照上次那条再改一遍"，这是最快的路径。

还有一条对"空输入"的处理也在这里说明一下：如果需求是空的（你什么都没写），拼装会直接返回空串，调用方按"需求是空的"处理，不会送出任何文本。这个判断放在第一层做，意义是"没有意图就不发指令"——环境说明再完整，也不能替代你要表达的那件事。换句话说，三层里的第一层是不可省略的：附件是素材、说明是约定，只有原话才是"你想要的改变"本身。

从使用角度看，这个设计还有一层隐含要求：你的原话要能"自解释"。因为历史里只留原话、不留附件说明，所以几个月后你翻历史时，看到的必须是能看懂的需求。写"把应用图标换成附件里的图"比写"换成那张图"要好——前者至少说明了附件是什么类型的东西；写"启动页背景换成新宣传图"比写"换一下背景"要清楚——后者过两天你自己都记不清换的是哪一块。这条建议不涉及任何技术，但它决定了你以后"翻历史"是资产还是负担。

一句话抓住这一层：原话是"要改什么"的完整表达，历史是它的留档，附件说明和环境说明都是"随行文件"——随行文件不留在档里。

二、第二层：附件说明——"路径 —— 用途"为什么必须逐条写

第二层是附件。点「选择附件」可以一次挑多个文件，并且给每个文件写一句"它是干什么用的"。拼进文本时，每个附件占一行，格式是：

1. D:\素材\新图标.png —— 应用图标换成这个文件

序号 + 绝对路径 + 用途说明，三段拼起来。前面还有一句总起说明，大意是"这些文件已经准备好放在磁盘上了，按各自的说明使用；需要放进应用里的，你自己决定放到工程的哪个位置"——这句话是特意加的，它顺手回答了一个 AI 最可能犯的犹豫：这张图要不要先拷进工程目录？答案是：不用你操心拷贝，AI 自己决定目标位置。把"我不确定你要不要做"的环节从流程里提前消掉，比事后纠正便宜得多。

为什么每个附件都要写用途，而不是只给一串路径？从一个具体的对比就能看出来：

附件说明这么写	AI 可能怎么理解
只给路径，没有说明	"这个文件要干什么？"——只能猜，可能猜成把图拷进工程、可能猜成分析它
"这张图是新的 logo"	说的是"它是什么"，仍然没说"要拿它替换哪一处"
"应用图标换成这个文件"	动作、对象、范围都在："替换应用图标"，没有歧义

所以界面在附件确认时做了两道校验，而且是硬性的：

1. 文件现在能不能用：存在、不是目录、不是 0 字节、并且能读出来。最后一条特别讲究——校验会以共享读方式打开一次文件，被别的程序独占锁住的文件也会被判为不可用。原因很直接：发给 AI 的只是一个路径，如果那个文件此刻读不到，AI 也读不到；与其让 AI 在半路上"打不开文件"，不如在选附件这一步就把话说清楚。
2. 用途说明不少于 10 个字：写"logo"不行，写"应用图标换成这个文件"可以。这条规则看起来有点武断，但它剔除的正是最没信息量的那类说明——一个词的名字。10 个字大致能承载"动作 + 对象"的最小信息量，这也是提示文案里给出的示范格式（"说清楚拿这个文件干什么，例如：应用图标换成这个文件"）。

挑文件的对话框也做了分类：除了"所有文件"，还单独列了"图片"和"文本 / 配置"两组过滤器——因为这类素材（图标、背景图、logo、配色表、文案表格）是改包场景里出现频率最高的东西，分类之后找文件会快很多，而且直接过滤掉了旁边那些根本没打算用的文件类型。 还有一个小机制值得知道：同一个路径重复选择不会新增一行。你把同一个文件又选了一次，列表里不会出现两行——因为同一份文件在一句话里出现两次、还带着两条可能不一致的说明，反而会让 AI 不知道该听哪条。去重的规则是"同路径（不区分大小写）只保留一条"，这属于"宁可少、不要乱"的取舍。

三、第三层：环境说明——{workdir} 替换与那句"确认全部改完之后"

第三层是最固定的，也是你平时看不到的：一段每次都一样的说明文字，压在整段文本的最后。它的内容由几件事组成，每一件都对应一个具体的流程问题。

第一件事：语言与工作目录。说明的前半句是"你是一位专业的中文助手，无论用户使用什么语言提问，请始终使用简体中文回答。请将工作目录切换到 {workdir} 下面进行修改"。这里的 {workdir} 是一个占位符，在发送之前会被替换成当前项目的工作目录——也就是这个项目反编译出来的那份工程所在的目录。这正是 AI 不需要你告诉它"文件在哪"的原因：它收到的说明里已经带了绝对路径。

顺带说一个边界处理：万一拿不到工作目录（正常流程不会发生，因为调用方会退回工作目录根目录），程序会把"请将工作目录切换到 xxx 下面进行修改"整句去掉，只发后半段。为什么不把占位符留着或者留个空？因为那样会拼出"请将工作目录切换到下面进行修改"这种病句——宁可少说一句，也不给 AI 一句读不通的指令。这是文本拼装里的一个小原则：拼接产生的内容必须永远可读。

第二件事：怎么算"改完了"。说明的后半段用一句话定义了完工信号：在确认全部改完之后，在项目工作目录下面生成一个名为 ai_done.flag 的标志文件；主窗口会轮询读取它，读到就认为改完了，然后把它删掉；所以这个文件只能在整个修改真正结束之后再生成，中途不要生成。

这段约定的背后，是整套工具里最巧妙的一处"握手"设计：AI 那边是一个聊天窗口，没法直接回调主程序；用一个文件当信号，是两边都最省力的约定。对 AI 来说，"生成一个文件"是它能力范围内最直接的动作；对主窗口来说，"看一个文件在不在"成本几乎为零，而且不怕出错——读不到就继续等，不会因为信号机制的意外把谁卡死。主窗口每 2 秒轮询一次，读到标志文件的瞬间就删掉它（免得下次误判），然后自动弹出打包窗口。

这条链路上还有几个容易被忽略的细节，全都指向同一个词：确定性。

• 开始等待之前先清一次同名残留：上一次跑完如果因为某种原因没清掉标志文件，这一轮一开始就会误判"已完成"。所以每次开始监视时，先删一遍旧的——等的一定是这一轮的新文件。
• 等待有上限，一小时：到点就停止监视，而不是永远挂着一个"等待中"。失败也要有边界，这是流程设计的通用纪律。
• 等候窗口可以取消：中途不想改了，可以取消这次等待（连右侧被吸附程序里的生成一起停掉），不用干等它跑完。
• 标志文件的内容不被关心：只看在不在，不看写了什么。信号越简单，出错的面就越小。

第三件事：不需要自动打包。说明的最后一句特意写明这一点。为什么？因为回编、对齐、签名、校验是一条确定的机械流水线，由主窗口统一负责；如果让 AI 顺手去打包，就多出一条不可控的打包路径。这和"附件那句总起说明"是同一种思路——把边界写清楚，让每个角色只做自己那一段。

关于这段说明，还有两点值得交代清楚。第一，它每次都会被原样带上，你不需要（也不应该）自己去编辑它——它不属于"你的需求"，而是这套工具和 AI 之间的工作约定。第二，它出现在你发送的每一段文本里，但你在界面上看不到它：详情页能看到的是你自己写的那句和历史记录，环境说明只在"发送那一刻"被拼进正文。所以如果你好奇"AI 怎么知道要往哪个目录改"，答案就在这段你看不见的文字里——它把“在哪儿干活”这件事，从你的输入里搬进了系统约定里。这也是为什么整套流程里你只需要关心"改什么"，而不需要知道工程目录长什么样。

另外，"工作目录"这个词本身也值得一句话说明：它指的是这个项目自己的工作目录（项目目录名是一串随机字符，程序自动建好并写入配置、拷贝源包、放好反编译产物），也就是反编译出来的那份工程所在的目录。它和你在详情页里看到的路径是同一个——所以如果你真想确认 AI 在哪儿干活，看详情页的那一栏就够了，不用去猜。

整段三层文本的核心：原话负责"意图"，附件负责"素材"，环境说明负责"约定"。约定不会因为你写得多详细而改变，所以——你只管把前两层说清楚，第三层永远替你兜底。

再补一个"反向理解"的视角：这段固定说明也让你的需求可以被写得更短。没有约定层的时候，人写需求会本能地越写越长——因为你要同时交代"改什么"和"怎么改、改完怎样"；而约定层把后一半全部吸收之后，需求就退化成一个纯粹的"意图表达"。这就是为什么"一句话改包"能成立：不是要求你写得少，而是把不需要你说的话，从你的输入里拿走了。

还有一个使用层面的推论：既然约定层是固定的，那它也是可依赖的——你不用怀疑"这次 AI 会不会又忘了生成标志文件"。它每次收到的都是同一句话，流程的可靠性不再取决于你每次怎么写。对一个要反复使用的工具来说，"每次的行为一致"比"某一次特别顺利"重要得多。

四、拼装顺序：为什么附件在前、约定压最后

回头看拼装的顺序：原话 → 空行 → 附件块 → 空行 → 环境说明。为什么是这个顺序？可以理解为"信息按'与这次修改的相关度'由近及远排开"：

• 原话在最前，因为它是这次任务的标题和主旨，AI 读到的第一件事就是"要干什么"。
• 附件紧跟在原话之后，因为它属于"这次要改什么"的素材，和原话是同一件事的两半：一个说要求，一个给材料。
• 环境说明压在最末尾，因为它是"每次都不变"的操作约定。放在后面有两个好处：其一，它不会被误当成需求的一部分（你写的需求才是需求）；其二，它的位置固定，AI 更容易把它理解成"流程规则"而不是"内容"。一句话概括：变化的在前，不变的在后；内容的在前，规则的在后。

还有一个实际的顺序约束：附件块只有"有附件"时才存在，环境说明永远存在（除非拿不到工作目录时去掉前半句）。所以这段文本会呈现三种长度：只有原话 + 约定（纯文字需求）、原话 + 附件 + 约定（带素材需求）。你不需要为这两种情况做任何区别操作，拼装逻辑自己处理。

三层之间统一用空行分隔，这个细节也不是随手为之：空行是"段落边界"最直白的表达，对不同阅读方式的接受度都最好——无论 AI 是按段理解还是通读全文，两处空行都在明确告诉它"这里换了一层意思"。如果三层首尾相连挤成一段，"这是需求还是流程要求"就变成需要猜的事；加了空行，结构自明。文本工程里很多这类"微小但有效"的规范：成本接近零，收益是每次都不出错。

五、技巧清单：怎么写需求，AI 才不容易误解

知道了三层结构，很多"使用技巧"其实就是自然的推论。下面这份清单按"最值得先掌握"的顺序排。

技巧一：先要"动作 + 对象 + 范围"，再谈修饰

一句能被可靠执行的需求，至少包含三样东西：要做什么动作（换成、去掉、改成）、作用在什么对象上（应用图标、开机启动页、应用名）、范围边界（"其他都不要动"）。第三样最容易被省略，却最值钱——没有边界，AI 只能自己判断"顺手要不要改点别的"。一句"把应用图标换成附件里的这张图，其他都不要动"，比"换一下图标吧"稳得多。

技巧二：用话术库起步，再改成自己的话

不知道怎么写的时候，别对着空白输入框硬憋。工具里有一套话术库：6 大分类（界面美化 / 弹窗引流 / 去除限制 / 常规修改 / 混淆去毒 / 插件添加）共 3000 条成型指令，每一条都把"要做什么、细节要求、参数参考、范围、验收"写全了。找到接近你需求的那条，点「选择」直接填进输入框，然后把里面的对象改成自家应用的说法（比如把"XX应用"换成你的应用、把素材指向你的附件）。话术库给的是结构，你负责填具体内容。内容放在程序目录下的 Resources\话术库.xml，可以自己手改，改完点刷新重新读。

技巧三：多件事就分开编号，不要写成一大团

一句话里塞三件事，AI 不是不能做，而是更容易漏——而且漏掉哪件往往由它自己决定。把需求写成"1) …… 2) …… 3) ……"的编号列表，每件事各自带上对象和范围，出问题的概率会明显下降；更重要的是，万一某一项没做到位，你能一眼指出是哪一号，改需求时也只动那一号。

技巧四：附件说明写"用途"，不写"描述"

前面表格里的对已经说明了：说明的落点是"拿这个文件干什么"，不是"这个文件是什么"。三种可用的句式："应用图标换成这个文件""启动页背景换成这张图""参照这张图的配色调整弹窗按钮颜色"。写的时候再自查一遍：如果把这句说明单独拿出来，能不能推出一个明确动作？推不出，就还得再具体一点。另外注意两条硬性校验：说明不少于 10 个字；文件必须此刻可读（被独占打开的文件会被拦下）。

技巧五：不要在需求里重复写"流程约定"

环境说明里已经写了"改完生成 ai_done.flag""不需要自动打包"，你的需求里就不要再写一遍这类话。重复不但没有增益，还可能带来冲突——最典型的是在需求里写"每完成一步就生成一个标志文件"：主窗口读到标志文件就会立刻触发打包，如果 AI 中途生成了它，你等来的就是一个"改了一半的包"。所以：约定的事交给约定，需求里只谈改动。同理，也别在需求里写"记得自己要打包"——打包不在 AI 的职责范围内，这句话只会让它犹豫。

技巧六：从历史里"捡"需求时，记得重新挂附件

历史里存的只有原话，附件说明不跟着回来。所以点历史记录右侧的「选择」把需求填回输入框之后，如果那句需求依赖附件，你还要再点一次「选择附件」把文件挂上（界面上那句"已附加 N 个文件"会告诉你当前挂了几个）。这是机制的必然结果，不是 bug——把它当成一个固定动作，形成肌肉记忆就不会漏。

技巧七：语言不用操心，约定层已经替你说了

环境说明的第一句就要求"始终使用简体中文回答"，所以你不需要在需求里再补一句"请用中文回复"——写了也不出错，但属于重复；更有价值的是把这句话的额度省下来，用于把改动本身说清楚。同理，你也不需要交代"改完先不要打包"：固定层里已经写明"不需要自动打包"。判断标准很简单：凡是每次都要重复的交代，都是约定层的活；你只需要写那种"只属于这一次"的内容。

技巧八：让原话自己"带上下文"

既然历史只留原话，那就让原话值得被留：写"把应用名改成『工单小助手 内测版』"比写"改个名字"好；写"去掉打开应用时的开屏广告，直接进首页"比写"把广告去了"好。几个月后你翻历史时，这些句子能直接看懂；发出去的需求里，"其他都不要动"之类的边界句也顺便留了档。这一条不改任何机制，但它决定了你未来的历史记录是"能用的档案"还是"看不懂的碎片"。

六、三个自家应用实例：从"写一大段"到"写一句话"

实例一：自家的「随手记账」换图标 + 改应用名

以前怎么做：改自家应用的图标和名称，要么用别的工具翻目录，要么得把话说得极其技术化："把 res 下各密度目录里的启动图标替换掉、把 strings.xml 里 app_name 的值改掉"。写这一串的前提是你自己得先知道文件在哪；写错一个目录名，改的就是一张没被用到的图。

现在一句话怎么做：输入框里写"把应用图标换成附件里的图标，应用名改成『随手记账 内测版』，其他都不要动"，然后点「选择附件」挂上新图标，说明写"应用图标换成这个文件"。点「立刻修改」，这段话会带着附件行和固定环境说明一起送进 AI 窗口。

改完怎么验证：AI 生成标志文件后主窗口自动弹打包窗口，四步跑完自动装到模拟器上——看桌面图标和应用名是不是新的。如果只想改名字不想动图标，把需求里的前半句删掉重发一次即可（历史里那条原话点「选择」就能填回来）。

实例二：自家的「巡检助手」去掉开屏广告（纯文字需求）

以前怎么做：开屏广告是自己加的，去掉它需要改跳转逻辑。手工做的话，第一步是找到"哪个类在什么时候跳到广告页"，这一步就劝退了大部分人——不是改不动，是找不动。

现在一句话怎么做：这个需求不需要附件，直接在输入框写"去掉打开应用时的开屏广告，启动后直接进首页，其他都不要动"，点「立刻修改」。

改完怎么验证：打包完成后自动装到手机或模拟器并拉起应用，盯着启动过程：是不是直接进首页、有没有闪一下广告页。如果启动页还在，说明"开屏广告"在你的应用里对应的是另一个界面（比如倒计时跳过页），把需求改得更具体一点再发一次——每一次循环的终点都是同一条打包流水线，验证方式不变。

实例三：自家的「工单小助手」换启动页背景（说明写法决定成败）

以前怎么做：我先写的是"启动页背景换成这个文件"，附件说明也随手写成"背景图"三个字——结果被校验拦下了（说明不足 10 个字）。改好说明之后才意识到：这类需求真正的关键是说清楚"换哪一块"。自家应用的启动页上有背景、有横排 logo、有底部标语，只写"背景"仍然有歧义。

现在一句话怎么做：需求写"把启动页的背景图换成附件这张，顶部 logo 和底部文字都不要动"，附件说明写"启动页背景图换成这个文件"。两句话把"改什么、不改什么、这个文件用来干什么"全部说清。

改完怎么验证：自动装到模拟器上，看启动页的背景、logo、标语三处是不是符合预期；打包后的包如果没问题，就把它作为这一版的基线——后面再改别的功能时，只要历史里那条"启动页背景换成附件这张"还在，你就随时能想起当初挂了什么附件、改了哪一块。

七、把三层串起来：一次需求从写下到装机的全过程

把机制并排看一遍，不如按时间顺序走一遍。下面是一次典型需求的完整流程——每一站都能对应到前面讲过的某一层：

你在做什么	程序在做什么
在输入框写下需求原话	等着这句话成为第一层
点「选择附件」，挑文件、逐个写用途说明	校验文件（存在 / 非目录 / 非 0 字节 / 可读）与说明（不少于 10 字），同路径去重
点「立刻修改」	需求原文写进修改历史；把原话 + 附件块 + 环境说明拼成完整文本，替换 {workdir}，送进 AI 窗口执行
看着等候窗口，去接杯水	AI 按约定在工作目录里改，改完生成 ai_done.flag；主窗口每 2 秒看一次
收到"改完了，开始打包"的动静	读到标志文件（读完即删），自动弹打包窗口，回编 → 对齐 → 签名 → 校验依次跑
装到手机 / 模拟器上看效果	装包、拉起应用；如果满意，保存 APK 发给同事或渠道

这张表里最值得回味的，是"你做的"那一列有多轻：写一句话、挂附件、点一下、看一眼。而"程序做的"那一列里没有任何一步需要你去推动——这就是三层文本真正的作用：它们把"你脑子里以为要交代的东西"分成了两类，一类必须由你说（改什么），一类由系统替你说（在哪儿改、怎么算改完、下一步谁接手）。很多人以为自动化靠的是"AI 聪明"，其实这套流程里，聪明的是把不确定的事情都写成了确定的约定。

八、用户评价与合规提醒

在试用反馈里，被提到最多的一条是"不用再解释路径和流程"；问大家对哪条约定印象最深，多数人的答案是同一个——"改完才生成标志文件"这句听上去很朴素，但它解决了'什么时候算改完'这个最难说清的问题。把"改完"定义成一件具体的事（一个文件出现），整个自动化的链条才立得住。

把这篇收成一句话：你写的那句话是"意图"，附件是"素材"，环境说明是"规则"；三层各司其职，拼装顺序固定不变。所以使用它的正确姿势，不是把流程也写进需求里，而是把意图说清楚、把素材挂对、把边界画出来——剩下的交给那条永远一样的固定说明。

只需说话，就能让应用变成你想要的样子。「安卓修改大师智改工坊」把这句话做成了完整的链路：拖入安装包、中文写需求（可挂附件）、AI 改 smali 与资源、改完自动回编对齐签名校验、一键装到手机或模拟器看效果。产品介绍页：https://www.apkeditor.cn/ai-version.aspx（官网 www.apkeditor.cn）。

安卓修改大师智改工坊 · 让改包回到"你说了算"