需求的两份文本：历史里只留你的原话，发给 AI 的要带说明

「安卓修改大师智改工坊」是一个把改 APK 变成一句话的 Windows 桌面工具，官方介绍页在 https://www.apkeditor.cn/ai-version.aspx，官网是 www.apkeditor.cn。很多人第一次用它，注意力都在「AI 改得准不准」上，却很少注意一个更基础的设计：你在输入框里写的那句需求，在工具内部其实会有两个版本。

一个版本躺进项目目录的 history.ini，里面只有你亲手打的字；另一个版本被送进右侧的 AI 改包窗口，在你那句话后面还接着两段你从没写过的内容——附件清单和一段固定的环境说明。这不是重复劳动，而是一套有明确分工的双轨制。把这套机制看明白，你对「历史记录」这件小事的用法会完全不一样：它不再只是流水账，而是一个可以回填、可以迭代、可以手工修正的需求库。

一、先立规矩：同一句需求，为什么要存两份

双击详情页上的「立刻修改」时，程序内部发生的事可以概括成一句话：先把你的原话记下来，再拼一份更完整的文本发出去。记下来的那份是「档案」，发出去的那份是「工单」。两者的读者不同，用途不同，生命周期也不同。

为什么非要分开？因为「要什么」和「在这个环境里怎么干活」是两件性质完全不同的事。前者只有你知道，需要人来写、人来改、人来看；后者是程序自己就能维护的约定——工作目录换了、标志文件名改了、打包规矩变了，程序跟着变就行，不该让用户去记，更不该让用户去抄。把它们混在一起写进历史，等于把一份私人笔记变成了一份每次都重复几百字的操作手册。

先记住一个判断标准，后面所有细节都从它推出来：凡是「这一轮才成立」的信息，都属于执行轨；凡是「你想要的最终形态」的信息，都属于历史轨。目录属于前者，图标换成什么样子属于后者。

二、发出去的那份：原话 + 附件说明 + 环境说明，三段怎么拼

执行轨的拼接规则很克制：先把你写的需求去掉首尾空白；如果去掉之后是空的，直接不发送——这意味着仅在输入框里敲几个空格是过不了关的，程序会按「需求是空的」处理，不会发出一段空话去打扰 AI。

需求非空时，最终发出去的文本由三段构成，段与段之间用空行隔开：

1. 第一段：你的原话。原样保留，不改写、不润色、不替你补全。
2. 第二段：附件说明（有附件才有）。点过「选择附件」并确认之后，每个文件会拼成一行「序号. 绝对路径 —— 用途说明」，前面还有一句统一的开场白，大意是这些文件已经放在磁盘上了、路径是本地绝对路径、需要放进应用里的请自行决定放到 apktool 工程的哪个位置。
3. 第三段：固定的环境说明。一段由程序维护的操作约定，逐字固定，只有工作目录会变。

顺序不是随便排的。附件说明跟在需求后面、环境说明前面：它是「这次要改什么」的一部分，理应贴着需求；而环境说明是对 AI 的操作约定，属于收尾的规矩，压在最后才不会被当成需求内容的一部分。这个小顺序决定了 AI 读文本时的语义重心，也决定了你回看需求时不会被附件路径挡住眼睛。

2.1 环境说明里到底写了什么

这段说明是程序写死的，措辞不允许随手改动，因为它同时约束了四件事：用什么语言回答、去哪个目录干活、怎么通知主窗口「改完了」、改完之后不要多做什么。把它的要点摊开看：

你是一位专业的中文助手，无论用户使用什么语言提问，请始终使用简体中文回答。请将工作目录切换到 {workdir} 下面进行修改……

第一句里有个必须拆开讲的东西：{workdir} 是一个占位符，发出去之前会被替换成当前项目的工作目录——也就是详情页上那一栏显示的路径，反编译出来的那份 apktool 工程所在的地方。这样设计的好处很直接：同一条原话，在 A 项目和 B 项目里发出去时会自动带上各自正确的目录，你不需要在需求里写任何路径。

还有个更细的兜底：万一程序拿不到工作目录（正常流程不会发生，调用方会退回到工作目录根目录），那句「请将工作目录切换到……下面进行修改」会被整句去掉，而不是留一个空占位符。原因很朴素——留着就会变成「请将工作目录切换到下面进行修改」这种病句，反而让 AI 犯迷糊。宁可少说一句，也不写病句，这是这段文本的编写原则。

2.2 标志文件：跨进程的一次「握手」

环境说明里最重要的一句，是约定「怎么算修改完毕」：AI 在确认全部改完之后，要在项目工作目录下面生成一个名为 ai_done.flag 的标志文件；主窗口会轮询读取这个文件，读到就认为改完了，然后把它删掉。说明里还特意补了一句：这个文件只能在整个修改真正结束之后再生成，中途不要生成。

为什么用「写一个文件」当信号？因为 AI 那边是一个独立的聊天窗口，属于另一个进程，没法像函数返回那样直接回调主程序。文件是最简单、最不容易出错的跨进程约定：写起来零成本，读起来也零成本，AI 只要照做就行，而且即便 AI 忘了写，也只是让主窗口继续等，不会把谁的流程卡死。工程上，能用一个空文件表达的状态，就不要引入更复杂的协议。

对应的，主窗口这边也不敢大意：开始监视前会先删一次同名的残留文件——上一轮跑完没清掉的、或者 AI 手滑提前留了一个，都要先扫干净，保证这一次等的是这一轮的成果；读到文件后立刻删除，免得下一轮又把它当成新信号。这一「先清、后等、读到即删」的三步，是这类轮询式握手最容易被忽略、也最容易出错的细节。等待本身还有个 1 小时的上限，到点就不再干等——状态行会写明已停止等待，界面上不会永远挂着一个「等待中」。

2.3 「不需要自动打包」这句是给谁看的

环境说明的最后一句是「不需要自动打包」。这句话乍看多余，其实是在划清职责边界：回编、对齐、签名、校验这条打包流水线是智改工坊自己做的（apktool b → zipalign → apksigner sign → apksigner verify），产物落在项目目录的 build 下，全过程写进 pack.log。让 AI 也去打包，只会多出一份来源不明的产物，出了问题谁也说不清是哪一步干的。所以这句话不是客套，是分工声明。

把这三段放在一起看，执行轨的完整形象就出来了：第一段是「你要什么」，第二段是「素材在哪」，第三段是「在这个项目里按什么规矩干、干完怎么叫我」。一条文本，三重信息，各归各位。

2.4 你的原话只会被改两个地方，其余一字不动

很多人在意「AI 会不会把我写的话理解跑偏」，其实更值得先确认的是：程序本身有没有动过我的字。答案是几乎没有——从你点下按钮到文本送出去，你的原话只经历两处处理：去掉首尾空白（Trim），以及在环境说明那一段里把 {workdir} 换成真实路径。你的措辞、标点、换行，全部原样保留。

这条「不加工」的承诺有个很实际的后果：你可以用自己习惯的方式写需求。口语化可以，写编号列表可以，用「别动原来的圆角」这种否定句也可以。程序不会替你把它们「翻译」成另一种说法，也就不会在翻译过程中丢掉你真正在意的那半句。反过来说，如果某次改包效果和你的预期有偏差，你排查时也可以放心：问题一定出在这句话本身写得够不够清楚，而不是被谁悄悄改写了。

顺带说清另一件小事：Trim 只去首尾空白，句子中间的换行与空行都留着。所以你完全可以写成三行小清单——第一行说改什么，第二行说约束，第三行说验收标准。空白在语义上帮 AI 断句，也在历史里帮你快速定位。

三、留下来的那份：history.ini 只记原话，写在发送之前

历史轨要简单得多，但它的时机会被很多人忽略。点「立刻修改」之后，程序的顺序是这样的：先确认需求不是空的，再过大使币这一关（大师币不足时导入 APK、编辑项目都不受影响，只有详情页的「立刻修改」和「去打包」才会提示充值），然后把你的原话与当前时间追加进 history.ini，紧接着清空输入框、刷新历史列表，状态行写下一句「已记录到 history.ini（时间）」，最后才把需求交给宿主程序送出。

换句话说：发送是后一步，记录是前一步。看到状态行那句「已记录到 history.ini」才算发出去了；如果发送环节出了问题（被吸附的程序没醒、模拟按键没成功），状态行会改写成「已记录到 history.ini，但发送失败：……」——注意，历史里那条记录依然在。这是先记后发的直接好处：你的需求不会因为一次环境故障而丢掉，把右边那个程序处理好，把需求重新发一次就行，不需要凭记忆重打一遍。

3.1 history.ini 长什么样

每个项目在 Project 目录下有一个 8 位随机字符串命名的目录，history.ini 就在里面，和 config.ini、source.apk、apktool 工程目录做邻居。它的结构非常朴素——按「记录1、记录2、记录3……」递增分节，每节两个键：

[记录3]
Date=2026-10-02 10:24:31
Demand=把启动页背景换成深蓝渐变，标题保持居中，底部加一行内测版说明

Date 用固定的「年-月-日 时:分:秒」格式，界面上的时间就是从这来的；Demand 就是你写的那句原话，一字不多。附件说明、环境说明都不会出现在这里——这是本篇文章反复强调的一条边界。

序号是怎么定的？新记录的序号 = 现有记录里最大的序号 + 1。所以在中间插一条、删一条，都不会让后续的编号撞车：即便你把「记录2」整节删掉，下一条仍然会叫「记录4」往后排。这个「只增不改」的编号策略让历史天然带着时间感——序号越大越新，一眼就能排出版本顺序，比翻时间戳还快。

3.2 为什么记录要排在发送之前

把写入放在发送前，还顺手解决了另外两个问题。

• 避免重复拼接。点完「立刻修改」输入框会被清空。如果不清空，你看到发送失败又点一次，很容易在原文基础上再粘一遍，变成「改一下背景改一下背景」这种自我重复的需求。
• 给「选择」留一个干净落点。输入框空着的时候，从历史里点「选择」填回来的内容就是完整的一段，不会和上一次的残留粘在一起。这条在使用技巧里很关键，第五节会展开。
• 让历史成为唯一事实来源。不管你后面又发了多少次、又改了多少版，历史里按顺序躺着每一条原话。项目整体状态与「改了几轮」是可以对上的：项目列表和用户中心里的「修改总次数」，数的就是所有项目 history.ini 里的记录条数。

顺便说清一个容易混淆的地方：详情页的「去打包」不写 history.ini，也不发 AI。它的含义是「拿当前这个项目直接打包」，通常用于两轮修改之间想先出一版装到手机上看看。打包不是一条修改需求，程序也没有把它硬塞进历史里凑数——这正是「历史只放意图」这条原则的体现。

四、分开的四条理由：把「要什么」和「怎么干」彻底解耦

双轨制不是一个为了好看而设的花架子，它至少解决四个具体问题。把这四条想明白，你对「历史里能不能顺手记点别的」这类念头就会有判断力。

一句话总结这套分工：历史里记的是「你要什么」，发出去的是「你要什么 + 这次在哪个目录、按什么规矩干」。前者是你的资产，后者是程序的工作副本。

五、历史列表怎么用：四条使用铁律与「选择」的追加语义

历史轨存下来了，接下来是它最有价值的出口：详情页上的修改历史列表。这一栏不用开窗口，打开项目就在页面上，最新的一轮排在最上面。每条记录显示三样东西：#序号、修改时间（精确到秒）、以及需求原文。

这里有个细节值得单独说：需求原文是完整显示、不做截断的。长需求在列表里会整体铺开，而不是缩成一行加省略号。看起来只是排版偏好，实际是判断依据——迭代的时候，两版需求的差别往往就在末尾那一句，截断了你就没法在列表里直接比对。

5.1 「选择」为什么是追加，而不是替换

点「选择」的时候，程序并不粗暴地清空输入框再填入，而是做了一次合并：输入框为空，就直接填入；输入框里已经有内容，就换行接在后面。同一个行为也发生在从话术库点「选择」的时候——话术内容是插进输入框，不会动你已经写了一半的东西。

追加语义有两个现实理由。第一，你经常需要「拿旧需求当底稿」：把上一轮那句拉回来，再补一句新要求，比起从头重打，前者不容易漏掉约束条件。第二，你可能同时想合两条历史：先点 #1 拿到「启动页背景改成深蓝渐变」，再点 #4 拿到「底部加一行内测版说明」，两次追加就拼成了一条新的复合需求，它们之间的换行让 AI 也能清楚分辨这是两件事。

当然，追加语义也要求你养成一个顺手的小习惯：点完「立刻修改」输入框会被清空，所以正常情况下你从历史里点「选择」时，落点都是干净的；如果输入框里还留着草稿（比如你写了两句又跑去改了别的地方），先看一眼再决定是留着还是清掉，免得旧草稿和新需求粘成一句话。

5.2 三个入口，同一份数据

除了详情页直接列出的那一栏，历史还有两个入口：项目列表里每条的「历史」按钮，以及详情页右上角的「修改历史」。三个入口打开的是同一个窗口、同一份 history.ini，没有任何缓存副本——你手工改过 ini 再点刷新，三处看到的结果一致。

从项目列表的「历史」进来时，程序会先把那个项目的详情页打开，再回填需求，不会出现「在 A 项目的输入框里填进 B 项目历史」这种串台。这个顺序上的小心思，多人协作、或者一个人同时维护好几个内部应用的时候特别重要。

还有一个容易被当成 bug 的地方：如果某一节只有时间、Demand 是空的，界面上不会出现这条记录。列表读取时只认「序号有效且需求非空」的记录——空记录没有展示价值，让它消失反而更干净。所以如果你手工加了一节却忘了写 Demand，别怀疑程序，是这条规则在起作用。

5.3 状态行那句话，值得每次看一眼

详情页的状态行很短，但它把两件事分得很清楚：「已记录到 history.ini（时间）」意味着记录这一步已经成功落盘；如果需要等待 AI，后面还会接着写「正在发送到……」「已把需求发送到……并回车执行，正在等它改完……」。而失败时会写成「已记录到 history.ini，但发送失败：原因」——记录成功与发送成功从来没被混为一句话。

对使用者来说，这句话就是一个廉价的状态检查点：看到「已记录」再去干别的事，就知道这次的需求不会丢；看到「发送失败」，直接处理右边那个程序，然后回历史点「选择」重发。养成看一眼状态行的习惯，比事后猜「我到底发出去没有」省事得多。

六、靠历史做迭代：一个三步法，两个自家应用实例

双轨制的价值，最终体现在「改第二版」的时候。手工改包最痛的不是第一次改，而是第二次改的时候，你已经不记得第一次到底写清楚了什么。历史轨就是为这一刻准备的。下面这个三步法，把「回填、补一句、再发一次」变成一个固定动作。

为什么强调「不要重述」？因为重述是有损的。人写第二版的时候会不自觉地把第一版的细节简化——「深蓝渐变」写成「蓝色」，「标题保持居中」干脆忘了写。而这些细节恰恰是上一轮需求里最有价值的部分。把原话原样回填，等于把上一轮的全部约束条件免费继承下来，你只需要对增量负责。

6.1 实例一：自家内部打卡助手，启动页改版三轮迭代

背景：我们内部有个自研的考勤打卡应用「打卡助手」，装在几个同事的备用机上，一直跑的是个纯色启动页。这段时间它要跟着一次内部活动换皮肤，启动页要改背景、保留居中标题、底部加一行内测版说明。这个需求一眼看去是三件事，但真做起来大概率要改两到三轮——颜色深浅、字号大小，光看需求文字是想不准的，得装到机器上看。

以前怎么做。需求记在记事本里：第一轮写完，改完发现深蓝偏紫；第二轮想在记事本那条上补一句话，但当时的原话已经变成「历史草稿」和「聊天记录」两个版本，得先确认哪句才是最终发出的；最麻烦的是约束条件——「标题保持居中」这句在第二轮自己重写需求时被漏掉了，装到机器上才发现标题挪了位置，又得回退重来。

现在一句话怎么做。第一轮在输入框里写清楚：「把启动页背景换成深蓝渐变，标题保持居中，底部加一行内测版说明」——注意这句话里既有动作（换背景、加说明），也有约束（标题保持居中）。点「立刻修改」之后，这句原话进 history.ini 成为 #1，输入框清空。看完成品，第二轮在历史列表里点 #1 旁边的「选择」，原话整句回到输入框，在末尾补一句：「深蓝再深一点，底部那行说明的字号小一号」。第三条同理，补的是「渐变的左侧偏亮一点」。三轮下来，历史里躺着 #1 #2 #3 三条记录，每一轮只差最后一句——这就是我想要的版本序列。

改完怎么验证。点完「立刻修改」以后不用守着：AI 按约定改完、在项目工作目录留下标志文件，主窗口每 2 秒看一次，看到就自动弹打包窗口，接着跑完回编、对齐、签名、校验四步，产物是 build 目录下的 signed.apk，全过程写进 pack.log。打包完成后勾上「打包后自动运行」，程序会用 adb 把包装到手机或模拟器并拉起应用，直接看启动页对不对；想自己确认装没装上，也可以用 dumpsys 看一眼前台应用是不是它。不满意？回历史点「选择」，再补一句。

6.2 实例二：自家门店巡检 App，深色模式下的标题配色

背景：「门店巡检」是内部自研的巡检记录应用，首页顶部有一条自绘的标题栏。上一轮已经把它改成了浅色磨砂风格，标题文字是深灰——白天看着挺干净，一到深色模式就翻车：标题和背景的对比度不够，字几乎糊在底上。

以前怎么做。这种「只改一个状态下的一处颜色」的增量需求最难描述：你要么把上一轮的需求从头重写一遍（还未必写得比原来准），要么在聊天窗口里翻半天找上一轮说过什么。更糟的是，AI 那边的会话越长，你要找的那句话越难定位；真找不到了，只能重新描述一遍整体风格，风险是它顺手把已经改好的浅色状态也一起改了。

现在一句话怎么做。历史列表里找到上一轮那条，点「选择」把原话捞回来，末尾补一句：「并把深色模式下的标题文字颜色一起调整，保证深色底上的对比度足够」。两条需求的差别只有这一句，AI 只需要处理增量，你也只需要对这一句负责。点「立刻修改」发出，等标志文件出现，自动打包。

改完怎么验证。打包完成后自动装到测试机上拉起应用，把系统切到深色模式看一眼标题是否清楚；同时把浅色模式再扫一遍，确认上一轮的成果没被回退——这正是「原话回填」的价值：上一轮那句「浅色磨砂、深灰文字」还在需求里，AI 有依据保住它，而不是凭记忆。另外，打包产物分三层（unsigned / aligned / signed）都留在 build 目录，pack.log 记着每一步的命令与结果，哪一轮出的问题，对着日志就能定位。

6.3 迭代的节奏感：一条需求一个目的

用熟了历史之后，你会自然形成一种节奏：一条需求只解决一件事。把「改图标 + 去开屏 + 改应用名」塞进一条需求，改完发现开屏没去掉，你甚至无法判断是需求没写清、还是 AI 漏做了——回退的时候，三件事一起回。拆成三条，每条独立可验证，哪条不成，历史里点哪条「选择」重发一遍就是了。

这也是历史轨的另一个隐含价值：它让「回到某一版」变得可行。想回到第二版的效果？历史里点 #2 的「选择」，把你的原话重新发一遍——因为原话是完整的意图描述，重发一遍等价于「以那一版的需求重新做一次」。这在手工流程里几乎做不到，因为那时你手里只有一堆散落的聊天记录。

七、技巧合集：改细节时，历史里的需求到底该怎么改

上面讲的都是「为什么」，这一节讲「怎么做」。下面这张表把迭代中最常遇到的七种场景攒在一起，照着做基本不会踩坑。

7.1 写原话的四个习惯

• 把验收标准写进原话。「改完启动页标题仍然居中」「底部说明保持一行不换行」——这类句子看起来像废话，但它会随着「选择」一起回到输入框，等于每轮迭代都自动带上一次回归检查。上面实例一里那句「标题保持居中」就是这个作用。
• 动作与约束分开写。先说改什么（把 X 改成 Y），再说不能动什么（其余样式保持原样）。AI 读需求时对「不要动」的句子同样敏感，写清楚比事后返工便宜。
• 一句一条，别用逗号堆十件事。一条需求解决一件事，历史列表读起来也清爽；真要一次说三件事，用换行分条，别让它们糊成一句长句。
• 不写环境说明。切目录、留标志文件、别在它那边打包这些事，程序自己会加在需求后面。你写了，只会和程序那段重复，还可能出现两套说法。

7.2 四个常见疑问

八、用户评价：他们最在意「第二次改」的那几分钟

下面这几位使用者的反馈，集中在同一件事上：改包不难，难的是「改完再改」。历史轨的意义，正是在这几分钟里体现出来的。

---

一句话需求会有两个版本，不是啰嗦，而是分工。历史里留着你的原话，发出去的那份替你把环境交代清楚——你要做的，始终只是把想改的地方说清楚，然后点一下「立刻修改」。

想亲手试一遍这条双轨链路，从把手上那个自家应用的包拖进 安卓修改大师智改工坊 开始。安装与介绍都在 https://www.apkeditor.cn/ai-version.aspx，官网是 www.apkeditor.cn。拖入安装包、中文写需求、AI 改 smali 与资源、自动回编对齐签名校验、一键装到手机或模拟器看效果——只需说话，就能让应用变成你想要的样子。