手机上写需求AI能听懂：3000条话术库的生成与匹配机制拆解

先交代背景。安卓修改大师智改工坊是一款把「改 APK」压缩成一句话的工具：选出自家安装包，用中文写需求，AI 改资源与代码，改完自动回编、对齐、签名、校验，再装到手机或模拟器上看效果。它的介绍页在 https://www.apkeditor.cn/ai-version.aspx，官网是 https://www.apkeditor.cn/。而今天要拆的安卓修改大师安卓版，把这套能力搬到了手机和平板上——你在工位上、在测试现场、在通勤路上，都能直接掏出设备改自己的包。

但"用中文写需求"这件事，说起来一句话，做起来第一道坎从来不是改代码，而是AI 能不能听懂你说的这句话。你在输入框里敲一句"把图标换了"，AI 要问自己一串问题：换哪个图标？换成什么？只换桌面图标还是连通知栏图标一起换？改到什么程度算完？这些问题你心里都有答案，但话没说出口，AI 就只能猜——猜中了是运气，猜不中就是一轮返工。

智改工坊安卓版为这道坎做了两件事：一件是话术库——把高频改包场景写成 3000 条成型指令，每条都把"要做什么、细节要求、参数参考、范围、验收"写全，你点一下就能用；另一件是需求文本分层——你说的原话、附件的说明、发给 AI 的环境参数，三份文本各走各的通道，互不污染。这篇文章就把这两件事拆开讲透：话术库是怎么分类和设计的、一句话从输入框到修改动作走了哪几条流水线、为什么历史记录里只准留你的原话，以及这套机制在手机小屏上为什么反而比电脑上更好用。

反过来说，如果没有这套机制，"用中文写需求"在手机上就是一句空话：你说得再自然，AI 收到的也只是一串没有上下文的汉字。智改工坊安卓版之所以敢把"只需说话"做成口号，底气就在于背后这套把"话"翻译成"可执行简报"的机制——你说人话，机器补全环境，两边各司其职。

这也是为什么这篇文章要花这么多篇幅讲"听懂人话"。在 AI 改包这件事上，模型能力是通用的，真正拉开差距的是"输入质量"——你给的信息越全，AI 发挥越稳定。话术库和文本分层，就是把输入质量这件事做成产品能力：不需要用户学提示词工程，不需要用户研究怎么跟 AI 说话，挑一条话术就是默认最高质量的输入。

所以，这篇文章的标题里"AI 能听懂"四个字，不是夸张。AI 能听懂，不是因为它变聪明了，而是因为你给它的话被话术库补全了五要素、被分层机制补齐了环境。"听懂"是设计出来的，不是运气碰出来的。这就是智改工坊安卓版和那些"你随便说、AI 随便猜"的工具之间的根本区别。

这就是为什么这篇文章要花这么多篇幅讲"听懂人话"。因为它不是一个 slogan，而是一整套机制的总和——话术库补全输入、分层补齐环境、流水线负责执行、留痕负责可追溯。把这四件事拆开看，你会发现"AI 能听懂"其实是"产品把能做的都做了"。

一、为什么 AI 改包要先听懂人话

先做一个思想实验。假设你要给自家应用换个图标，你在输入框里只写五个字："把图标换了。"这句话在人类同事眼里是完整的——因为你和同事共享了太多上下文：昨天的设计稿就在桌上、新 logo 已经发到群里、改完装到哪台测试机上你们也说过。但对 AI 来说，这些上下文一句都不在。它看到的只有五个字，于是它必须猜：图标是哪张图？新图标在哪？要不要同时改名称？改完怎么算对？

这就是所有"一句话改包"工具的真正分水岭：不是 AI 会不会改，而是你给的那句话里有没有足够的信息让它不用猜。人话里天然带着大量省略，因为对话双方共享场景；而发出去的需求是一份单独的、没有人可以当面追问的指令。它必须在一次发送里就把五件事说清楚：

你自己逐字写这五件事，在电脑键盘上尚且费劲，在手机触屏上更是一场折磨——这正是智改工坊安卓版把话术库做成核心组件的原因。它把成千上万人说过的需求，预先归纳成 3000 条已经写全五要素的成型指令。你不是在"写作文"，而是在"点菜"：找到对应场景那一条，点「选择」，整段话自动填进输入框；需要按自己的包改两个字（比如把"应用名"改成真实名称），改完发送。一句话需求从"憋出来"变成"挑出来再微调"，这是它在手机上成立的前提。

还有一层容易被忽略：AI 改包不是在真空中改。它需要知道这个项目的工作目录在哪、反编译产物放在哪、改完由谁来回编打包。这些信息用户不可能每次都写，也不该由用户写——于是它们由程序在发送时自动拼进需求文本里。这就引出了后面第四章要细讲的"需求文本分层"：你只管写人话，程序负责补齐环境。听懂人话 = 人写全五要素（话术库兜底）+ 程序补齐环境（分层机制兜底），两件事缺一不可。

为了让你对"写全"两个字有体感，再做一次对比：同一件"换图标"的事，一句话版本和话术版本发出去之后，AI 手里的信息差距是五比一——前者只说了动作，后者连"改完去哪检查"都说了。差距大到这种程度，"AI 聪不聪明"已经不是变量，"你给的信息全不全"才是。这也是智改工坊安卓版把产品资源向话术库倾斜的原因：与其在模型端赌运气，不如在输入端把确定性拉满。

举一个更具体的场景。你在现场拿到反馈："你们那个内测版，图标换成新 logo 之后，关于页的标题没跟着变。"如果用一句话需求，你得自己组织：换成新 logo、关于页标题也改成新名称、桌面图标下方文字不变。这句话里有动作、有范围、有验收——但你要在手机上逐字敲出来，拇指会罢工。如果走话术库：进「常规修改」找一条"改显示名 + 关于页标题"的话术，点「选择」，把名称换成你应用的真实名，发送。五要素已经在里面了，你只动了一个词。

这就是话术库在现场场景里的真正角色：它把"组织语言"这件需要思考的事，变成了"挑选现成语言"这件不需要思考的事。你的注意力全部放在"这次要改什么"上，"怎么写"交给话术库。

一句需求被退回来的三种典型死法

把"听不懂人话"拆开看，失败不是随机的，它几乎总是死在三个固定的缺口上。看这三个真实感很强的句子：

这三种死法有一个共同点：缺的都不是"改"的能力，而是"说清楚"的能力。所以智改工坊安卓版把力气花在前端——话术库负责帮你把话写全，附件校验负责逼你把参考物说清楚，验收句直接写进话术模板里。AI 不是更聪明了，而是收到的信息终于够它一次做对。

这也是为什么"话术库"这件事在产品里的地位远超"一个辅助功能"：它实际上是用户和 AI 之间的一份合约模板。你用它发出去的每一条需求，都是一份五要素齐全的合约——动作、细节、参考、范围、验收，一项不缺。AI 不需要追问，你也不需要来回补话。在手机这种"随时掏出来、当场就要结果"的场景里，一次做对的价值，比电脑端高得多。

追问一轮的成本，比写全一句话高得多

为什么要强调"一次写全"？因为 AI 改包不是聊天框里的闲聊，每一轮追问背后都是真实的工程成本。需求含糊 → AI 猜错 → 改出一个不对的包 → 回编、对齐、签名跑完 → 装机看效果 → 发现不对 → 回来补一句需求 → 再来一轮。这个循环每转一圈，消耗的不只是时间，还有你对"到底哪个包才是对的"的判断力——桌面上可能躺着三四个名字相近的包。

这张表解释了话术库设计的根本动机：把"写全"的成本压到最低，是为了把"返工"的可能性压到最低。用户在输入框前多花十秒钟选对话术，换来的是少跑两三轮完整的打包流水线。在手机这种"掏出来就要结果"的场景里，这笔账尤其划算。

二、3000 条话术是怎么组织出来的：分类树与五要素字段

3000 条不是一个拍脑袋的数字，它是按"动作性质"分出来的：6 大分类，每类约 500 条。这个分类轴很关键——它不是按"应用页面"分（首页图标设置、启动页设置……），因为同一类修改动作会出现在无穷多种应用里；而是按"你想对这个包做什么"分，这样任何一个包进来，你都能沿着"我的动作"找到那一条。

话术分类	典型场景	说明
界面美化	图标、显示名、启动页背景、主题配色	视觉资源类的替换与调整，是最高频的一类
弹窗引流	启动弹窗、退出弹窗的展示与跳转文案	面向自家活动页与更新提示的配置类话术
去除限制	自家测试版里的试用提醒、次数提示等	仅适用于自有版权应用的内测场景
常规修改	应用名、版本号、显示文字等基础信息	改动小、验证快，最适合新手练手
混淆去毒	反编译后代码可读性整理、冗余清理	为后续精准定位修改点服务
插件添加	往自家应用里增加功能模块入口	改动较大，建议先在备份包上试

每一类下面的约 500 条话术，差别不在"动作"，而在动作的具体语境。同样是"改名称"，有的话术针对桌面图标下方文字，有的针对系统设置里的应用列表，有的针对关于页面；有的要求"只改显示名不动包名"，有的允许"连同版本号一起改成内测版号"。把这些细分语境各写一条，用户就能找到和自己需求最贴的那一条，而不是挑一条最像的再大改。这就是 500 条/类的来由：分类管"动作轴"，细分条目管"语境轴"，两个轴交叉起来才覆盖得住真实需求。

更关键的是每条话术内部的字段设计。前面说的五要素，在话术里不是五个空栏，而是写死在句子里的完整段落。看一条「常规修改」类话术的典型样子（为便于说明做了示意）：

你把这条和你自己随手写的"把名字改成记账助手2.0"放在一起对比，差别一目了然：后者只说了【要做什么】的一半，前者把 AI 可能要追问的问题全部提前答完。话术库的本质，是把"AI 反问你的成本"提前折算进了话术编写阶段——编写者替用户把场景预演过，AI 拿到的是一份可以直接执行的简报，而不是一个需要来回追问的开场白。

界面上的两个动作也值得说清，因为它决定了你怎么用这 3000 条：

• 点「选择」——把这条话术整段填进输入框。填进去之后它还是你的文本，你可以接着改：把名字换成你自己应用的名字、把验收标准按你的测试机情况调一调。适合"挑一条最像的，改两个字"。
• 点「复制」——把这条话术的正文复制到剪贴板。适合你想拿去别的地方贴：贴到备忘录里备份、贴到工作群里跟同事对齐需求、贴到另一台设备的输入框里。

3000 条不是写出来的，是归纳出来的

顺带说清楚一个认知：这 3000 条话术，不是坐在办公室里对着功能清单"编"出来的，而是从真实高频需求里归纳出来的。做归纳的人其实只回答一个问题——"用户真正会要求 AI 做的那类事，到底长什么样？"这个问题决定了话术的写法：它不是"操作手册"（第一步点哪、第二步点哪），而是"成果描述"（我要的结果是什么样、怎么验收）。因为 AI 改包执行的是修改动作，不是界面操作，所以话术里写的全是结果导向的句子。

把"随手写的一句话"和"一条成型话术"并排放在一起，这个差别会看得很清楚：

对比项	随手写的一句话	话术库里的成型指令
要做什么	有（"把名字改了"）	有，且写明改成什么
细节要求	缺	写清动不动包名、动不动版本号
参数参考	缺	写明名称的字数与格式
范围	缺	列明桌面、设置列表、关于页三处
验收	缺	给出可执行的检查标准

这张表也是"为什么必须用话术"的反面论证：你逐字写一句完整需求，在电脑上要三到五分钟，在手机上可能要十分钟；而挑一条最贴的话术、改两个字，只要十几秒。话术库没有让你失去表达自由，它只是把"写全"这件事的边际成本打到了零。你真正需要动脑的，永远只有"这次到底要改什么"这一个问题。

还可以再想一层：为什么分类轴选"动作"而不是"应用页面"？因为按页面分（"桌面图标设置""启动页设置""关于页设置"）看起来直观，实际上每个应用的页面结构都不一样，你没法预测用户的包里有哪些页面；而"动作"是跨应用通用的——任何应用都能换图标、改名称、换启动页背景。分类轴选在通用维度上，话术库才能覆盖无穷多种包；选在具体页面上，就只能覆盖那几种你预设过的包。这是一个典型的"抽象层级选对了，覆盖面自动就大了"的设计决策。

每一类约 500 条的细分，靠的就是"语境变体"：同一个动作，在不同语境下的五要素写法不同。改名称的语境差异，可能是"只改桌面名"和"连同关于页一起改"；换图标的语境差异，可能是"只换桌面图标"和"连通知栏图标一起换"。这些差异都是真实用户在真实改包里提出来的，每一个变体都替你挡掉一类"理解偏差"。你在列表里挑的时候，本质上是在"认领"一个和你意图最接近的语境，然后微调参数。

有两个分类值得单独说明它的合规边界，因为它们最容易被误用。「去除限制」类话术，只适用于自有版权应用——比如你自己团队开发的测试版应用里留着试用期提醒、次数限制，在企业内测场景里把它去掉，这是正当使用；拿它去碰别人的付费应用授权校验，则完全超出了这个工具的合法用途。「弹窗引流」类话术也是同理——它服务于自家活动页、自家更新提示的配置，不是给你往别人的包里塞东西用的。工具把分类摆在那里，用法的边界由用户自己守住，这也是文末合规提醒存在的原因。

「插件添加」类是改动幅度最大的一类。往自家应用里加功能模块入口，涉及的资源和代码改动面都比换图标、改名称大得多。我们的建议是：第一次用这类话术时，先拿一个备份包在模拟器上跑一遍完整流程，确认产物、确认装机能起、确认改动范围，再在正式内测包上用。话术里的验收句就是为这个步骤服务的——它把"怎么算改对"写成可检查的清单，而不是让你凭感觉猜。

把那条示例话术逐句拆开看，你会发现每个字段都在替 AI 回答一个问题：【要做什么】回答"改哪个东西"——显示名称；【细节要求】回答"改到什么程度"——不动包名、不动版本号，防止 AI 顺手把包名也改了导致装不上；【参数参考】回答"新值长什么样"——六个汉字、半角空格、版本号格式；【范围】回答"改哪几处"——桌面、设置列表、关于页，防止漏改；【验收】回答"怎么确认改好了"——装机后看两处文字且包名不变。五个字段，五个问题，AI 拿到之后不需要反问任何一个。

这种"字段化"写法还有一个隐藏好处：它让话术可以被"参数化复用"。你把这条话术里的"记账助手 2.0"换成别的名字，它就变成另一条话术；把验收句里的"桌面图标"换成"启动页"，它就变成另一条场景。话术库的 3000 条，本质上就是在这五个字段上做组合变体——每一类约 500 条变体，覆盖该动作下的常见语境。

从 3000 条里挑对那一条：一个挑选技巧

3000 条摆在面前，怎么挑？实战里最顺的路径不是"翻分类一页页看"，而是先想动作，再定语境：第一步先回答"我对这个包做的动作属于哪一类"——改视觉就去「界面美化」，改名称就去「常规修改」，这个选择通常三秒完成；第二步在这一类里找"语境最贴的那条"——比如同样改名称，你要确认的是"改桌面名称"那条，还是"改关于页标题"那条。找到之后点「选择」，把里面写死的参数换成你自己的真实值。

如果一条话术改完之后还差两句才能说清你的需求，说明它不是"最贴"的，但这完全不妨碍你用它——两条话术拼接是允许的：先「选择」A 话术填进输入框，再「选择」B 话术，它会接着填进来，你把两段之间不顺的连接词删掉即可。一句话需求里同时含"改名称 + 换图标"就是这么拼出来的。比起从零写两段五要素齐全的话，拼现成的两段仍然快得多，也不容易漏要素。

这 3000 条的覆盖面，其实是"动作 × 语境"两个维度的乘积。动作维度就 6 类，语境维度每类约 500 个变体。这个设计的好处是：当你要改的动作落在 6 类里，你几乎一定能在该类里找到一个"语境最贴"的变体——因为变体就是按"真实用户在不同语境下会怎么说"归纳出来的。你不需要自己组织语言，只需要在已有的变体里挑一个最像的。

从"写"到"挑"，这是话术库带来的根本变化。以前你要在手机上逐字组织一句五要素齐全的话；现在你从 3000 条里挑一条最贴的，改两个参数，发送。这个变化在手机端尤其明显——触屏输入慢，"挑"比"写"快十倍，而且写出来的质量还更稳定。

理解了分类逻辑，你就理解了话术库的"可扩展性"。当你们团队要加一条新话术，你知道它应该落在哪个分类下（动作轴）、应该写哪些字段（五要素）、应该怎么描述语境（和现有变体保持同粒度）。这不是"随便写一条"，而是"在已有体系里加一条"——结构统一了，新人也能照着写。

三、一句话需求到修改动作的流水线：AI 凭什么知道改哪个包

话术解决了"人话写全"，但 AI 还需要第二个前提：它得知道这个包是谁、东西放在哪。你在手机上选出自家 APK 的那一刻，程序在后台做的第一件事不是等你写需求，而是用工作目录里的 aapt 把这个包"读一遍户口"：应用名、包名、版本号、最低与目标 SDK 版本、启动页组件，全部解析出来。这一层解析是后面一切修改动作的定位基础——AI 说"改显示名称"，它得先知道当前名称是什么、改的是哪个资源表；说"装完拉起看效果"，它得知道启动页组件叫什么。

解析过程有几个设计细节，值得单独讲，因为它们都对应真实踩过的坑：

aapt 读出来的"户口清单"长什么样

很多人以为"解析包信息"只是显示个图标和名字给人看，其实它是 AI 后续所有动作的事实底座。程序用工作目录里的 aapt 把包读一遍，落到项目里的信息大致是这几项：

解析项	用它干什么
应用名	项目列表展示；改名时知道"原来叫什么"
包名	装机、拉起、复核前台应用时的身份标识
版本号	默认产物命名（应用名_版本号_signed.apk）
最低 / 目标 SDK	判断改动的兼容边界
启动页组件	改完拉起看效果时的入口
图标原图	从包里取出、按最高密度档挑选

为什么这一步要"先读户口再等需求"？因为用户读完详情页上的应用名、图标、版本号之后，写出来的需求自然就带着上下文：他知道包名是什么、知道自己要改的是哪个版本，话术里那两个要手改的空（新名称、新参数），他填的是自己应用的真实值，而不是凭空编的占位符。界面上展示解析结果这件事，本身就是在帮用户把需求写准。

为什么反编译失败不能拖垮项目？反编译是整个流水线里最重、也最容易出意外的一步（包体结构怪异、资源被加固、工具链缺组件都可能让它失败）。如果把项目建立和反编译绑成一步，反编译一崩，你选的包、填的项目名、看到的图标就全没了——这在工程上是很糟糕的耦合。所以产品的做法是"先落地、再反编译"：项目目录、config.ini、拷好的 source.apk 先全部写好，反编译只是往 apktool 目录里填东西。它失败了，项目照样成立、照样能打开、照样能看历史；程序给你原因和 apktool.log 路径，你修好工具链之后再来，包还在原地。

户口读完，你在详情页中间的输入框里写需求（或从话术库「选择」一条填进来），需要参考物就点「选择附件」一次挑多个文件。附件系统有一个很"轴"的设计：每个附件必须配一句"它是干什么用的"，且不少于 10 个字。发送前程序会做两项校验——文件现在能不能用（存在、不是目录、不是 0 字节、能读出来），以及说明够不够 10 个字。校验不过就拦下，不让发。这看起来像添堵，实际上是替你挡"AI 对着一个来历不明的附件瞎猜"的事故：拼给 AI 的附件说明长这样，序号. 文件路径 —— 用途说明，每一条都有名有姓。

点「立刻修改」之后，流水线正式启动：

1. 需求原文连同修改日期，一起写进项目的 history.ini；
2. 发出去的那份文本 = 你的原话 + 附件说明 + 固定的环境说明（下一章细拆），送进 AI 执行；
3. AI 改完，在项目目录里留一个标志文件；主窗口每 2 秒轮询一次，读到标志就自动弹打包窗口；
4. 打包四步跑完：回编（apktool b）→ 对齐（zipalign -p 4）→ 签名（apksigner + 内置签名（可在项目里换成自己的签名））→ 校验（apksigner verify）；
5. 产物依次落在 build 目录：unsigned.apk、aligned.apk、signed.apk，每次出包生成完整打包日志 pack.log，产物可追溯。

第 4 步里"多做一步 verify"值得展开：回编、对齐、签名这三步，程序只看退出码——退出码是 0 就当成功。但"签名这一步退出码为 0"和"包到底签没签上"，在某些边界情况下不是同一件事。所以最后加一步 verify，由它打印证书信息说了算：前三步是"我跑过了"，最后一步是"它真的成立了"。你想在项目里换自己的签名也行——详情页「设置签名」里可以选默认签名，或挑自己的 jks、keystore，也可以选证书加私钥（pem、pk8），选好存进项目配置，之后每次打包直接用，不用重填。

从标志文件到打包窗口：等待 AI 的那段时间发生了什么

点完「立刻修改」之后，到打包窗口弹出来之前，有一段"等待时间"。这段时间里程序并没有闲着，它用一套很朴素的文件握手在等 AI 收工：AI 改完之后，会在项目目录里留下一个标志文件；主窗口每 2 秒轮询一次这个目录，读到标志就把它删掉、自动弹出打包窗口。在开始等待之前，程序还会先清理一次同名残留——避免上一轮没删干净的旧标志让你误以为"AI 改完了"。

为什么用"标志文件 + 轮询"而不是更"实时"的通信？因为这两个环节之间最可靠的共享介质就是项目目录本身：AI 写东西、程序读东西，都在同一个文件系统上，不依赖网络端口、不依赖进程间通道、不依赖谁先启动。2 秒的轮询间隔也不是拍脑袋——AI 改包本来就是几十秒到几分钟量级的工作，2 秒一次的检查频率完全不会错过时机，开销又可以忽略。这套"文件即接口"的思路贯穿了整个产品：需求进 history.ini、附件路径写进说明、标志文件握手、全过程写进 pack.log——所有跨环节的交接，都是看得见的文件，出了问题翻开目录就能还原现场。

打包窗口弹出来之后，四步流水线跑过的每一步也都留痕：回编产物 unsigned.apk、对齐后的 aligned.apk、签名后的 signed.apk 依次落在 build 目录，全过程写进项目目录里的 pack.log。打包过程中窗口不给关——这不是限制你，而是避免你以为"没在跑"而重复点。跑完之后你可以「保存 APK」（默认命名是 应用名_版本号_signed.apk），也可以「打开所在文件夹」直接拿产物。诊断体系也是按这个思路建的：打包过程看 pack.log，反编译输出看 apktool.log，异常情况看 error.log——每一类问题都有它自己的日志。

附件校验那一段还有一个值得知道的细节：它校验的是"文件现在能不能用"——文件存在、不是一个目录、不是 0 字节、能正常读出来。这四件事任何一件不过都拦下，因为挂一个打不开的附件给 AI，比不挂附件更糟：它会让 AI 以为有参考物，从而做出更自信也更错误的判断。

把四步打包链路列成一张表，每一步的产物和它存在的意义就一目了然：

步骤	干了什么	产物	存在的意义
① 回编	把改过的反编译目录重新打成包	build\unsigned.apk	改动真正变成一个安装包
② 对齐	包内资源按 4 字节对齐	build\aligned.apk	运行时内存访问更高效，系统要求
③ 签名	用选定的签名给包签名	build\signed.apk	没签名的包装不上
④ 校验	复核签名证书信息	证书信息打印在日志	"签没签上"由它说了算，不只看退出码

打包之后，装到设备上这一段也有讲究。程序用 adb 找手机或模拟器，把包装上并拉起应用。拉起用的是显式启动命令而不是 monkey——新版安卓镜像里 monkey 已经没有了，而且它失败时退出码仍然是 0，很容易让你误以为"装成功了、起来了"，实际根本没起来。启动页组件名是三档查找：先查项目 config.ini 里记录的 LaunchableActivity，问设备 resolve-activity，最后才兜底。拉起之后还会用 dumpsys 看一眼前台应用是不是它，确认闭环。手机走 scrcpy 投屏到电脑，模拟器把窗口提到最前；常见国内模拟器装了但 adb 没连上时会自动扫端口连上，装了没开则搜出安装路径问你要不要现在打开。

附件校验那一段再讲细一点。发送前程序做两项校验：第一是"文件现在能不能用"——存在、不是目录、不是 0 字节、能读出来；第二是"说明够不够 10 个字"。拼给 AI 的格式是 序号. 文件路径 —— 用途说明，每个附件一条。这套校验看起来"轴"，但它拦住的是最常见的一种失败：附件挂了但 AI 不知道它干嘛用，于是对着一张图瞎猜——猜成图标、猜成启动页背景、猜成参考尺寸，每次猜错都是一轮完整的反编译、回编、签名、装机才发现不对。

为什么"说明不少于 10 个字"是个有用的下限？少于 10 个字的说明，往往是"新图""logo""参考"这类词汇——它们等于没说。10 个字是个粗糙但有效的门槛：逼你多写半句，AI 就能多拿到一半信息。这和话术库"五要素写全"是同一个设计哲学：在输入端多花十个字，在输出端省掉一轮返工。

为什么是"2 秒轮询"这个数字？AI 改包的时长通常在几十秒到几分钟，2 秒检查一次意味着最多延迟 2 秒就能触发打包窗口——这个延迟在用户感知里就是"刚改完就弹出来"，几乎无感觉。如果用 10 秒轮询，用户会看到一个明显的空窗期，以为卡住了；如果用 100ms 轮询，则是在浪费 CPU。2 秒是"感知不到延迟"和"不浪费资源"之间的平衡点。

标志文件握手还有一个细节：开始等待前先清一次同名残留。这是为了避免上一轮没删干净的旧标志文件，让你误以为"AI 又改完了"。这种细节看似多余，但在长时间运行、反复改包的场景里，它能避免"莫名其妙弹打包窗口"的困惑。等待上限也有兜底，超时不再等，避免你对着一个永远不会来的标志干等。

顺带把"从选包到出包"的完整路径在脑子里建一张地图：选包 → aapt 解析户口 → 后台反编译 → 详情页写/选话术 → 挂附件 → 点立刻修改 → 历史留原话 → 发送拼成品 → AI 修改 → 标志文件 → 四步打包 → verify 校验 → 装机拉起 → 对照验收句检查。这条路上每一步都有留痕：config.ini 记项目、history.ini 记需求、apktool.log 记反编译、pack.log 记打包。任何一步出问题，翻对应的文件就能知道卡在哪——这也是"产物可追溯"四个字的具体含义。

工具链层面也有一个自动兜底：程序启动会自动挑盘（D→E→F→G→C 依次试，取第一个可读写且剩余 ≥1GB 的盘），拼成 <盘符>:\AiApkEditor；目录下 tools 与 Project 两个子目录，java、aapt、apktool、7z、zipalign、apksigner 这些组件放在 tools 里自动递归搜索，不用手动登记。「参数设置」页有一次工具链体检，把每个组件逐个报"是否就绪 + 完整路径"；环境不齐时点「立刻更新」自动下载解压工具包再复检。新接手的同事打开软件先做一次体检，五分钟内就能确认环境全绿。

再说说"界面不卡"这件事为什么值得做。解析与反编译跑在后台线程上，意味着你点完选择包之后，列表还能刷、历史还能看、别的项目还能翻——不会被一个转圈的加载页锁死。实测 12MB 的包反编译约 3 秒；超过 10 分钟会主动中断报错。这种"重活放后台、界面随时响应"的安排，在手机上尤其重要：手机端的用户习惯是随时切出去回个消息再切回来，界面卡死十秒钟，体验就垮了。

把整条流水线串起来看，你会发现它的设计哲学：每一环都留痕，每一环都可恢复。选包落地、解析留档、反编译隔离、需求进历史、发送拼成品、标志文件握手、四步打包留产物、全过程写日志。任何一步出问题，你都能翻到对应的文件知道发生了什么；任何一步失败，前面的成果都不会白费。这就是"产物可追溯"的具体含义。

这条流水线的设计，本质上是把"改包"这件事拆成了"人做决定、程序做执行"。人负责"要改什么、改成什么样、怎么验收"——这些只有用户知道；程序负责"找文件、改资源、回编、对齐、签名、校验、装机"——这些是确定性的工程动作。话术库把"人做决定"这一步标准化，分层机制把"程序做执行"这一步自动化。两者合起来，用户只做最有价值的那部分：决定。

四、需求文本分层的工程学：为什么历史里只留你的原话

现在拆这篇文章最核心的一个机制。表面上看，你点「立刻修改」，需求就"发出去了"。但实际上，这一刻存在着两份不同的文本，它们分别走进不同的地方：

为什么要把两份文本分开？这不是洁癖，而是三个非常实际的工程理由。

理由一：历史是给"你"看的，不是给 AI 看的。你翻历史的时候想看到什么？想看到"我上次到底要求它做了什么"。如果历史里焊进了程序拼的环境说明——那是一段你从未写过、以后也不会逐字读的机器文本——你的历史列表就会被十几行模板灌水，真正想看的需求原文被淹在里面。人看的记录，只记人说的话。

理由二：「选择」回填时，拼环境的活儿永远由发送动作来做。历史记录的右侧有一个「选择」按钮，作用是把那条原话填回输入框，方便你"照上次那条再改一遍"。想一个反例：如果历史里存的是当年发出去的完整文本（含当时的 {workdir} 实路径），今天你把那条记录填回来直接发送——AI 就会被指到半年前那个项目目录去。而现在的做法下，历史只存原话，每次发送都重新拼一份新环境说明，{workdir} 永远指向当前这个项目。旧记录因此永远不过期，这正是分层最关键的收益。

理由三：动态信息不进静态档案。附件路径会变、文件会被删、目录会重建——附件说明是"当时当刻"的动态信息，焊进历史这种长期档案里，几个月后再翻出来就是一堆死链。让动态信息只活在"发送那一刻"，是对历史的尊重。

这套分层和产品里另一个设计是同一个哲学：给人看的配置和给程序记的状态，分开存放。settings.ini 是给人改的——尺寸、占屏比例、间隙、开关、主题，每一项都带中文注释；另一份 local.ini 是给程序自己记的——登录缓存、头像地址、机器码、登录方式。你手改配置写坏了，顶多布局不好看，不会把登录状态弄丢；程序自己写状态时，也不会顺手覆盖你手写的注释。需求文本分层就是这个哲学在"对话记录"上的投影：人说的话进历史，环境的活儿归发送。

history.ini 本身的结构也很朴素：记录 1、记录 2、记录 3 这样递增，每一节是一条需求。想删某一条，删掉对应的那一节就行——它没有数据库、没有索引、没有加密，是一份你能用任何文本编辑器打开、核对、修改的纯文本档案。项目列表里每条的「历史」按钮可以打开历史窗口，详情页则直接把历史列出来（最新在最上）。这种"把记录写成可读文件"的选择，和 pack.log 一样，都是为了可追溯：改了什么、什么时候改的、打包过程中每一步发生了什么，全部留痕，不靠回忆。

对比项	进 history.ini 的原话	发给 AI 的完整文本
内容	你亲手写的那段需求	原话 + 附件说明清单 + 固定环境说明
{workdir}	不存在这个占位符	发送时替换为当前项目真实目录
附件说明	不进历史	按「序号. 路径 —— 用途」拼入
用途	给人回看、回填「选择」	让 AI 一次拿到全部上下文
过期问题	永不过期，随取随用	每次发送重新拼装，不残留

一条半年前的记录，为什么今天还能用

把这个分层机制放到时间轴上看，它的价值会更具体。假设半年前你给"巡检打卡 1.4 版"这个项目发过一条需求："把启动页背景换成新宣传图。"今天你翻历史，找到那条记录，点「选择」，它填回输入框的就是那十一个字——干净、完整、没有任何杂质。然后你点发送：程序把当前项目的附件说明拼上、把当前项目目录替换进 {workdir}、把固定环境说明拼好，发出一份全新的完整文本。

如果当年的历史里存的是发出去的完整文本，今天这一下就出事了：AI 会读到半年前那个项目目录的路径——那个目录可能早就被清理、那个旧包的反编译产物可能早就不在了。AI 对着一个不存在的目录"干活"，失败信息都会充满误导性。"历史只留原话"看起来是少存了几个字，实际上是把所有动态信息的生命周期管了起来：动态信息只活在发送那一刻，静态档案永远只放不会过期的东西。

history.ini 的加减法也很朴素：记录 1、记录 2 这样递增，每一节一条需求，按时间追加，最新的在详情页最上面显示。想删掉某一条不满意的记录？用文本编辑器打开 history.ini，删掉对应的那一节即可——它不是黑盒数据库，删一节就是删一条，没有回收站、没有级联。这种透明性和 pack.log 是同一个取向：你经手过的每一件事，都应该有地方可查、有办法可改。删除项目也有防呆设计——只允许删 Project 目录的直接子目录，防止误删到工作目录本身。

环境说明里到底替你写了什么

很多人好奇那段"固定环境说明"里到底是什么内容。拆开看，它其实就回答 AI 必须知道的三件事：第一，活儿在哪干——{workdir} 占位符替换后的项目目录，告诉 AI 反编译产物在哪个目录里改；第二，改完怎么交接——改完在项目目录留标志文件，剩下的回编、对齐、签名、打包统一由主程序完成，AI 不需要也不该自己去跑打包命令；第三，边界在哪——只改这个项目目录里的东西，别动别的项目。

为什么这三句话必须由程序拼、不能由用户写？因为它们是"随项目变"的：{workdir} 每个项目不同，今天这个项目和明天那个项目的目录完全是两个字符串。让用户背自己项目的目录名、每次发送手敲进去，既不现实也容易敲错——敲错一个字符，AI 就改到别的目录去了。把易变的环境信息交给程序替换，把稳定的业务需求交给用户写，这就是分层最朴素的分工。

信息类别	谁负责	为什么
业务需求（改什么、改成啥样）	用户写（话术库辅助）	只有用户知道目标
项目目录 {workdir}	程序发送时替换	随项目变，手敲必错
附件用途清单	用户写说明，程序拼装	说明归人，格式归程序
交接与边界规则	固定文本，程序拼	所有项目通用，写死即可

详情页的历史列表本身也有几个体贴的小设计：最新记录在最上面；每条完整显示需求原文不截断——不会把你的长话术省略成半句；右侧「选择」一键填回输入框；项目列表每条的「历史」按钮可以单独打开历史窗口，不用进详情页就能翻这个项目说过什么。你和这个项目的对话史，就是一份可以随时回看、随时复用的档案。这种"把历史当资产"的思路，和话术库可编辑是一脉相承的：用户在产品里留下的每一句话，都应该是可再利用的，而不是用完即弃的。

配置分层：哪些文件该手改，哪些别碰

把"分层"的思路从对话记录扩展到配置文件，你会看到同一套哲学：settings.ini 是给人改的——两窗口宽度合计占屏比例、间隙、轮询间隔、最小宽高、启动是否自动对齐摆放、退出是否关闭 AI 工作区进程、10 套配色主题，每一项都带中文注释，写清了这个值怎么参与计算。另一份 local.ini 是给程序自己记的——登录缓存、头像地址、机器码、登录方式。两份文件分开的好处很实在：你手改配置写坏了，顶多布局不好看，不会把登录状态和机器码一起弄丢；程序写状态时，也不会顺手覆盖你手写的注释。

界面上的「参数设置」页把最常用的几项做成可视开关和输入框，改动只更新配置文件里对应的那一行，你在文件里自己写的注释不会被动。同一页还有工具链体检，aapt、java、apktool、zipalign、apksigner 逐个报是否就绪与完整路径；环境不齐时点「立刻更新」自动下载解压工具包，装完重新检测。排查"我改了包但打不出来"这类问题，先看这一页比翻日志更快。

为什么附件说明不进历史？再单独说一遍这件事，因为它是分层里最容易被误会的一条。附件说明是"动态信息"：它描述的是那个时间点那个附件的用途，附件路径可能失效、文件可能被替换、你可能换了一张新图。如果把它焊进 history.ini，半年后你翻到这条记录，看到的是一段描述着"旧附件"的文字——那个附件早已不在了，这段说明就成了没有指向的说明。让它只活在发送那一刻，是对历史的尊重。历史里只留你写的那句需求，因为只有它是永恒有效的。

把"分层"这个概念再往上提一层：它其实是一种对"用户信任"的设计。用户不需要理解 {workdir} 是什么、附件说明怎么拼、环境说明里写了什么——他只需要知道"我说的话会被原原本本记下来，发出去的东西会被补齐成完整简报"。这种"你负责业务，我负责环境"的分工，让用户在手机上也敢写需求，因为他知道程序不会漏掉他说的任何一个字，也不会把不该用户管的细节塞给他。

分层机制的最后一个好处：它让"历史"成为真正的资产。因为历史里只留你的原话，它永远不会过期、永远可以回填、永远可以作为"上次那条"再发一次。如果历史里焊进了环境参数，半年后那条记录就废了；现在它永远是鲜活的——你随时可以把三个月前那句需求重新发一次，程序自动拼好今天的环境。这种"时间无关性"，是分层设计给历史记录的最大礼物。

需求文本分层，说到底是"把对的信息放在对的地方"。用户写的话进历史，因为它是人说的；程序拼的参数进发送文本，因为它是机器补的；附件说明只活在发送那一刻，因为它是动态信息。这种分层看起来琐碎，实际上是整套"听懂人话"机制的地基——没有它，历史会被污染、环境会出错、记录会过期。

五、话术库自定义与刷新：它是一份可以手改的文本资产

3000 条话术听起来是"官方内容"，但它在产品里的存放方式非常开放：话术库就是程序目录下的一个文本文件 —— Resources\话术库.xml。它不是写死在程序里的，而是一份可以直接用文本编辑器打开、手改、增补的资产文件；改完之后回到界面，点一下「刷新」，程序重新读一遍文件，你新写的话术立刻出现在分类列表里。

这个设计的工程含义很值得讲。话术本质上是"经验文本"，而经验是会增长的：你所在的团队可能反复给同一批内部应用做同类修改——比如每次版本迭代都要把显示名加上"内测版"后缀、每次活动都要换同一位置的启动页图。这些高频动作，与其每次从 3000 条里找最接近的一条再改，不如沉淀成你们自己的专属话术条目，写进 xml 文件：把团队惯用语、固定验收口径写死，新人打开话术库就能直接选、直接发，沟通成本在文本层面就被消化掉了。

"可手改 + 点刷新重读"这套组合，背后是一个很克制的架构决策：话术库是数据，不是代码。把话术做成独立文本文件，意味着新增一条经验话术不需要发版、不需要改程序、不需要等任何流程——改文本、点刷新、生效。程序启动时读一次文件，刷新时再读一次，除此之外不缓存、不写库。这种"无状态读取"让文件本身永远是唯一事实来源：你用任何编辑器改坏了，大不了改回去；改对了，刷新即生效。

顺带把话术界面的两个入口再对一遍，免得用混：「选择」是"填进输入框再编辑"——你的主要工作流；「复制」是"带走原文"——适合备份需求模板、跨设备搬运。点「选择」之后，话术文本就和你自己敲的字没有任何区别，可以接着删改、可以在后面追加附件说明对应的参数、可以连点几次「选择」把两条话术拼成一条复合需求（比如"改名称 + 换图标"一次说完）。这种自由组合是话术库真正的用法：它给你的是乐高积木，不是单选按钮。

团队场景下这套机制会更香。假设你是工作室里负责改包的那个人：把团队反复要用的八条话术整理进 xml——每条都写清你们团队的验收口径（比如"以测试机上桌面图标与关于页两处为准"）、你们惯常的命名规则（"内测版后缀"）、你们的附件说明句式。同事拿到这份文件放进自己的 Resources 目录，点刷新，他发出去的每一条需求都自动带着团队统一的口径。话术库在这个场景里就是一份"团队改包语言标准"，新人入职不用先学"咱们改包怎么跟 AI 说话"，打开话术库选就是了。这种沉淀方式零成本、可版本化、可随时增删——比在群文件里传 Word 文档实用得多。

刷新机制：为什么不做后台自动热加载

可能有人会问：既然话术库是个文本文件，为什么程序不监视文件变化、改了就自动重载，非要用户手动点「刷新」？这里有一个刻意的取舍。自动热加载听起来高级，但在多人共用、团队分发话术文件的场景里，它会带来一个很烦躁的问题：你刚在界面上翻到一条想用的话术，背后文件被同事更新了，列表突然整个变了，你正在看的那条跳到别处甚至消失。手动刷新把"什么时候换内容"的决定权交回给用户——你想换新内容时点一下，它才换；你在用的时候，列表保持稳定。

这和"可手改"组合起来，就是一条很完整的工作流：你（或你团队）整理话术 → 编辑器写进 xml → 回到界面点刷新 → 新话术出现。没有导入按钮、没有同步服务、没有版本管理——文件即事实，刷新即生效。对一个文本资产来说，这是能做到的最简单也最可靠的形态：任何简单到能被文本编辑器理解的格式，都能被任何工具链处理。

团队分发话术文件的具体做法。你把整理好的 话术库.xml 通过工作群发给同事，让他替换到自己程序目录下的 Resources 文件夹，点一下「刷新」即可。不需要导入按钮、不需要账号同步、不需要"我的话术库云同步"——文件即事实。这种朴素方式的好处是：话术库可以跟着你们的项目文档一起走，新人入职时把 xml 文件放进交接材料里，他的第一句话术就是你们团队统一口径的。

什么时候该刷新？改完 xml 立刻点刷新；多人共用一份话术文件、有人刚更新过，开始正式改包前点一次刷新。不刷新就开始选话术，界面里看到的还是旧内容，容易让你以为"这条怎么跟昨天改的不一样"。养成"改完即刷新"的习惯，就不会有这个困惑。

话术库和首页那 191 条使用技巧提示条是什么关系？提示条是"怎么操作这个软件"的小知识（每 12 秒轮换一条），话术库是"怎么跟 AI 说话"的成型指令。前者教你点哪里，后者教你说什么。新手先看提示条学会操作路径，再用话术库写出第一句完整需求——两者是从"会用"到"用得好"的递进关系。不想看提示条可以在设置里关掉，话术库则是核心组件，不能关。

话术库可编辑这件事，其实把"产品内容"和"用户资产"的边界模糊了。官方给的 3000 条是起点，你和你的团队可以在上面长出自已的条目。这些条目是你的经验沉淀，跟着你的文件走，不会因为产品升级而丢失（升级会保留 Resources 目录下的文件）。从这个角度看，话术库不是"产品的一部分"，而是"你团队的一部分"。

可编辑、可刷新、可分发——这三个词合起来，就是话术库作为"文本资产"的完整含义。它不是写死在程序里的内容，而是一份你可以拿去改、拿去分、拿去沉淀的文档。团队的经验在里面长出来，产品升级也不会把它弄丢。这是把"产品内容"做成"用户资产"的一次尝试。

六、手机上为什么反而更适合话术输入

直觉上，手机触屏打字慢、屏幕小，写需求这种"文字活"应该是电脑的强项。但智改工坊安卓版的实际使用反馈恰恰相反：在手机上，话术库的价值被放大了。原因在于，手机改包的痛点从来不是"写不快"，而是"写不全"——触屏上逐字敲一段五要素齐全的需求，拇指会罢工；而话术库把"输入"从"打字"变成了"点选"。

具体拆开讲，手机场景有三个天然适配点：

• 详情页中间就是输入框，不需要在多个窗口之间跳转：选完包、看完解析出来的应用名和图标，视线不挪窝，直接在下面选话术、改两个字、点发送。
• 现场改包是高频场景：测试同事在现场拿着你家内测机，发现一个问题，当场掏出设备把自家包改一版给旁边人试——这种"说改就改"的节奏，等不及回办公室开电脑。话术点选式输入让这种即时性成立。
• 小屏反而逼你用最省事的路径：电脑上你可能还会逐字写，手机上你会自然地养成"先翻话术库"的习惯——而这恰恰是把需求写全的最短路径。

工作目录的落点也不用操心：启动时自动挑盘，依次尝试 D、E、F、G，取第一个能读写且剩余空间不少于 1GB 的盘，拼出 <盘符>:\AiApkEditor，系统盘权限限制多所以排在最后。这些细节单看都小，合起来就是"在手机上改包不别扭"的底气。

小屏操作的三个反直觉结论

用了一段时间手机端之后，我们总结出三条和直觉相反的结论，供你参考：

围绕"在手机上把这句话写顺手"，产品还有一组小细节值得单独说：首页底部的使用技巧提示条每 12 秒轮换一条小技巧，内置 191 条，全是"怎么用这个软件"的实用招法——比如怎么找历史、怎么换签名、怎么看日志。它的设计意图是让新用户在等待加载、滑动浏览的间隙，不知不觉把操作学会，而不是逼着人先读一篇说明书。不想看也可以在设置里关掉。

配色上给了 10 套主题（极夜蓝、深海蓝、紫罗兰、樱花粉、烈焰红、落日橙、古铜金、青柠绿、薄荷绿、石墨灰），点一下立刻换。手机小屏上，配色不只是好看：浅色主题在户外阳光下看得清，深色主题在深夜测试现场不刺眼。窗口本身没有系统标题栏但可以拖动、四边可缩放，在手机那种寸土寸金的屏幕上，每一毫米都留给内容。

还有一个容易被忽略的现场价值：验证设备就在手边。电脑端改包，装包验证往往要再把手机插上线；手机端改包，改完的包直接装在这台设备上——你在现场递给同事的那台手机，既是写需求的终端，也是验证结果的终端。从"发现问题"到"给出新版"到"看到结果"，全部在同一块屏幕上完成。这也是为什么话术库把"验收句"写得那么具体：现场验证就是掏出来看一眼，一句话写清"看桌面图标、看启动页前三秒、看关于页名称"，旁边的同事也能照着检查。

想象一个真实的现场：你在客户现场做内测演示，对方指着屏幕说"这个启动页背景能不能换成最新那张宣传图"。在以前，你得说"等我回办公室开电脑弄"；现在你掏出手机，选出自家内测包，从话术库挑一条启动页背景的话术，把新宣传图作为附件挂上去、写清用途，发送。十几分钟后，改好的包已经装在你这台手机上，你打开启动页，现场给对方看新背景。整个过程没有离开过那间会议室。

这就是"手机上改包"这件事的全部意义：把改包的可能性从工位上解放出来。而话术库是让这种解放成立的关键——如果还是逐字写需求，现场那种节奏根本撑不住；点选话术、改两个字、发送，整个动作不超过一分钟。

这三条合起来说明一件事：手机端不是"电脑端的缩水版"，它的工作方式天然更靠近话术库。电脑上你还会想自己写，手机上你会自然地学会点选——而这恰恰是被设计好的最佳路径。

所以，手机端不是电脑端的"补充场景"，而是一种不同的工作方式。电脑端适合坐下来做复杂改包，手机端适合现场快速迭代。话术库和分层机制让这种现场迭代成为可能——你不需要带着电脑出门，一部手机就能给自家应用打补丁。这就是"手机上写需求 AI 能听懂"的真正意义：改包这件事，从工位上解放出来了。

手机端改包的未来感就在这里：你不需要带着电脑出门，一部手机就能给自家应用打补丁。话术库让你不用逐字写需求，分层机制让你不用管环境参数，流水线让你不用手动打包。你只需要决定"要改什么"，剩下的全交给机制。这就是"手机上写需求 AI 能听懂"的真正价值。

七、两个自家改包实例：一句话怎么落到屏幕上

下面两个例子都来自我们自己和同事的日常场景，用的都是自家应用和自有素材。每个都按"以前怎么做 / 现在一句话怎么做 / 改完怎么验证"三步讲，你可以对照着看话术库和文本分层在真实工作里扮演了什么角色。

实例一：给自家「记账助手」换图标 + 改显示名。

以前怎么做：在电脑上先拿到新 logo 的各尺寸版本，跑反编译把包解开，按 mdpi 到 xxxhdpi 逐档替换 mipmap 里的图标（这一步最容易漏档，漏了就在某些机型上看到新旧图标混用），再回编、对齐、手动签名，最后 adb 装到测试机上看桌面。整条流水线十来分钟，全程在编辑器、命令行、文件管理器之间来回切。

现在一句话怎么做：手机上选出自家安装包，进详情页，话术库「常规修改」分类里选一条改显示名的话术点「选择」，把新 logo 作为附件加上并写清用途（"新版品牌 logo，用于替换桌面与启动图标"——不少于 10 个字的校验会帮你确认写清了），在填好的话术上把名称改成"记账助手 2.0"，点「立刻修改」。你说出去的就是一句五要素齐全的话；程序在发送时自动把附件说明和环境参数拼好，AI 收到的是完整简报。

改完怎么验证：AI 改完留下标志文件，主窗口 2 秒轮询读到，自动进入打包四步；最后 verify 打印出证书信息，确认"确实签上了"；包装到手机上拉起，看一眼桌面——图标是新的，图标下方的名称是新的，系统设置里的应用列表也是新名称。整个项目目录里，配置文件、源包、反编译产物、build 下三个中间包、pack.log 全部留痕，产物可追溯。

这个例子里最值得回味的，是"漏档"这个老坑被机制性地填平了：以前按密度替换图标，mdpi 到 xxxhdpi 五六个文件夹，漏一个档就在某类屏幕上露馅；现在话术把验收写成"桌面图标下方文字与设置中应用名称均显示新名称"，AI 在资源层面统一处理各档图标，你只需要在装机后的桌面这一处做最终确认。需求文本分层在这里也帮了忙：新 logo 附件挂着"新版品牌 logo，用于替换桌面与启动图标"的说明，AI 不会把它错当成启动页背景——这就是那句"不少于 10 个字"校验换来的确定性。

实例二：给内部「巡检打卡」工具换启动页背景图。

以前怎么做：先确认启动页背景图在资源里的文件名和目录（常在几百个文件名里翻），新图按原尺寸导出覆盖，回编、签名、装机——最痛苦的是"验证"这一环：启动页一闪而过，同事常常要装三四次才能看清到底换的是哪张图。

现在一句话怎么做：选出自家内部工具的包，话术库「界面美化」分类里挑启动页背景相关的话术点「选择」，把新宣传图作为附件、写明用途，在话术里把验收那句改成"保持原显示比例，打开应用前三秒可见"，发送。AI 拿到的文本里，原话是你改好的那一句，附件说明告诉你这张图是新宣传图，环境说明告诉它工作目录在哪、改完留标志——三份信息各就各位。

改完怎么验证：打包四步跑完后，程序用 adb 找手机或模拟器把包装上并拉起——拉起用的是显式启动（新版安卓镜像里 monkey 已不可用，且它失败时退出码仍为 0，容易误判成功），拉起后还会复核一次前台应用是不是它。启动页这次不用靠"一闪而过的记忆"：模拟器会把窗口提到最前，手机走投屏，你盯着屏幕看三秒就行。过程中如果发现模拟器装了没连上，程序会自动扫端口连接；装了没开，会搜出安装路径问你要不要现在打开。

这个例子里，话术库的价值集中在"验收句被改写"这一小步上。模板话术的验收写的是通用检查，你把它改成"保持原显示比例，打开应用前三秒可见"——一句话把"看图大小对不对"和"看启动页出不出现"两件事钉死。AI 拿到的文本里，这句话属于你的原话部分，会和当时的附件说明、环境说明一起发出去；它不会进历史以外的任何地方，下次翻历史看到的还是你写的那一句。

把两个实例并排看，你会发现话术库用法的一个共通点：验收句都被"本地化"了。模板话术给的是通用检查项，而你真正改包时，验收永远是对着你手头那台设备、那个版本去的——所以"改完怎么验证"这一句，永远值得你在发送前花十秒钟改成自己的真实检查点。这一句话是话术库给你的留白，也是它真正的用法：框架它来给，细节你去填。

两个例子放在一起看，话术库和文本分层的角色就清楚了：话术库负责把"人话"写全，文本分层负责让"AI 的工作环境"永远正确。前者解决"听得懂"，后者解决"找得到、做得对、查得到"。

最后把两个实例里"一句话"的旅程复盘成一张表，你可以直观看到一句话在流水线上被加工成了什么：

环节	这句话经历了什么
挑选话术	从分类树里定位到五要素齐全的那条，点「选择」填入
微调人话	把占位参数换成自己应用的真实值（名称、验收口径）
挂附件	新 logo / 新宣传图，各配一句不少于 10 字的用途说明
写进历史	原话 + 日期进 history.ini，完整不截断
发出成品	原话 + 附件清单 + 环境说明（{workdir} 已替换）送 AI
改完交接	标志文件 → 主窗口 2 秒轮询 → 四步打包 → pack.log 留痕
验证闭环	装机拉起，按话术里的验收句逐项检查

这张表值得你存在手机备忘录里。第一次走完整条流水线可能要二十分钟（含摸索），走熟之后，"挑话术 → 改参数 → 挂附件 → 发送 → 等打包 → 装机验证"往往五分钟内闭环。快的不是打字，而是每一步都有现成路径可走，不需要现想"下一步该干嘛"。话术库给你动作，分层机制给你环境，流水线给你收尾，你只负责"决定要改什么"。

这两个实例放在一起，你会发现话术库用法的共通点：验收句都被本地化了。模板话术给的是通用检查项，而你真正改包时，验收永远是对着你手头那台设备、那个版本去的——所以"改完怎么验证"这一句，永远值得你在发送前花十秒钟改成自己的真实检查点。这一句话是话术库给你的留白，也是它真正的用法：框架它来给，细节你去填。

最后一个提醒：话术库不是背下来用的，是挑着用的。没有人会记住 3000 条里哪一条长什么样。正确的用法是：你先想清楚"我这次要改什么"，然后按动作分类去找，找到最贴的那一条，点「选择」，改两个参数，发送。话术库的价值在于"有得挑"，而不是"要全记"。

两个实例放在一起，你会发现话术库用法的共性：框架它来给，细节你去填。模板话术把五要素写全，你把占位参数换成真实值、把验收句改成你的检查点。这个"挑模板 + 填空"的过程，比从零写一段完整需求快十倍，而且质量更稳定——因为模板已经替你把容易漏的部分都想过了。

八、踩坑与技巧：老手的 checklist

机制讲完，收尾给一份实战 checklist——都是真实使用里最常遇到的情况，照着过一遍能少走很多弯路。

一套建议的使用顺序：新到手的包，先看 aapt 解析出来的应用名、版本号和图标（确认没选错包）→ 再去话术库按动作分类找最贴的一条（不要急着自己敲）→ 把占位参数换成真实值、把验收句改成你这次真正要检查的点 → 挂附件并写足用途说明 → 发送。第一版改完之后，如果只需要"微调一处"，永远走历史的「选择」回填，而不是重写——回填的原话配上重新拼装的环境说明，就是最省字也最不容易错的路径。

两个最值钱的习惯：一是每次改完都对着验收句做验证——话术里写的"桌面图标与设置中应用名称均显示新名称"不是客套话，它就是你这次点几下屏幕的检查清单；二是项目目录定期清理但别乱删——删除项目有防呆（只允许删 Project 的直接子目录），但 build 目录里的 signed.apk 确认要了再留，空间被占满时程序会在用户中心告诉你项目占了多少。

最后补一段常见问题速查：「点了发送没反应？」先看是不是附件校验没过（说明不足 10 个字、文件读不出来）；「改完装不上？」去看 verify 那一步的证书信息，以及 pack.log 里哪一步报错；「AI 改的方向不对？」八成是需求里的范围句没写清，下次在话术里把"只改哪部分"补全；「历史里怎么找不到我上次那条？」项目选错了——历史是按项目分的，每个项目有自己的 history.ini；「想换自己的签名？」详情页「设置签名」里选 jks/keystore 或证书加私钥，选好存进项目，之后每次打包直接用。

最后提醒一个心态：不要追求"一次到位"，要追求"可迭代"。第一次发出去的需求不完美没关系，历史里那条原话可以回填、可以改一个词再发；AI 改错了也没关系，pack.log 和 build 目录里的中间件能帮你定位是哪一步出了问题。这套机制的设计目标不是"一次做对"，而是"每次都能复现、每次都能改进"。

两个常见误解

误解一："话术库就是固定模板，填进去不能改。"恰恰相反——点「选择」填进输入框之后，它就是你的普通文本，增删改全自由。话术库给你的是"写全五要素的起点"，不是"锁死的句子"。你可以把两条话术拼成一条复合需求，也可以把验收标准换成你团队的检查口径。

误解二："历史记录会自动发给 AI。"历史只是记录，不会自动提交。你在历史里看到某一条，只有点「选择」把它填回输入框、再点「立刻修改」，它才会作为一次新的需求发出去。历史是档案，输入框才是发件箱——这两件事的边界，正是"历史只留原话"这套设计想让你养成的习惯。

这份 checklist 的使用方式：第一次用智改工坊安卓版时照着过一遍，十分钟就能把坑都踩完；之后遇到问题时回来查对应的那一条。它不是说明书，是一份"避坑地图"——每一条都是真实用户踩到、然后被机制解决了的问题。

这份 checklist 不是让你一次背下来，而是遇到问题时回来查。第一次用的时候，照着过一遍，十分钟把坑踩完；之后遇到"怎么又不对了"，翻到对应的那一条，三秒钟找到原因。它和话术库是同一个设计哲学：把经验前置，让用户少走弯路。

用户评价：他们怎么用这套话术库

九、结语：听懂人话，是改包的第一道工序

把这篇文章收成一句话：话术库把"要做什么、细节要求、参数参考、范围、验收"预先写进了 3000 条成型指令；文本分层让你的原话干干净净进历史，让环境参数每次发送都重新拼装。一个负责"写全人话"，一个负责"接对环境"，AI 改包这件事的第一道工序——听懂人话——就这样被拆开了、做扎实了。

回顾这一路的设计选择，你会发现它们都指向同一个价值观：把确定性尽量放在用户看得见、改得动的地方。话术库是文本文件，你能手改；history.ini 是纯文本，你能核对；{workdir} 由程序替换，不会敲错；附件说明由校验逼着你写全；打包全过程写进 pack.log，产物可追溯。没有一处是"黑盒里发生的事"，每一步你都能翻开来看个明白。

对新手来说，这套机制的意义是"降低第一次说对话的门槛"——不用研究 AI 提示词工程，挑一条话术就已经站在五要素齐全的起跑线上；对老手来说，它的意义是"把团队经验沉淀成可分发的文本资产"——改 xml、点刷新、全员统一口径。无论你是哪种用户，"只需说话，就能让应用变成你想要的样子"这句话，背后是 3000 条话术和一套分层机制在替你兜底。

最后留一个思考题给你：下次给自家应用改包时，试着故意不选话术、自己写一句，然后和话术库那条并排对比。你会一眼看到"写全"和"写了个大概"的差距——这种对比做一次，你就理解了为什么 3000 条话术库不是"多此一举的内容填充"，而是让 AI 一次做对的最短路径。

如果你读到这里，应该已经明白：这篇文章讲的不是"一个话术库怎么用"，而是一套把人话翻译成可执行指令的工程机制。话术库是它的前端，分层是它的后端，文件留痕是它的可追溯性。三者合起来，才让"只需说话"四个字不是一句口号，而是一条可以复现的流水线。

最后一句：这套机制不是为"技术大神"设计的，是为"要干活的人"设计的。你不需要懂 aapt 怎么解析、不需要懂 apktool 怎么回编、不需要懂签名证书长什么样——你只需要会从话术库里挑一条最贴的，改两个字，发送。剩下的事，流水线替你做完。这就是"只需说话，就能让应用变成你想要的样子"这句话背后的全部工程。

如果你读到这里，应该已经明白：这篇文章讲的不是"一个话术库怎么用"，而是一套把人话翻译成可执行指令的工程机制。话术库是它的前端，分层是它的后端，文件留痕是它的可追溯性。三者合起来，才让"只需说话"四个字不是一句口号，而是一条可以复现的流水线。

这套机制的最终受益者，是那些"要干活但不懂技术"的人。测试同事、运营同事、产品同事——他们不需要学反编译、不需要懂签名、不需要研究怎么写提示词。他们只需要从话术库里挑一条最贴的，改两个参数，发送。剩下的事，机制替他们做完。这就是"只需说话"四个字背后，真正的产品野心。

下次你打开安卓修改大师智改工坊时，不妨试一次：先别急着敲字，从话术库里挑一条最贴的，改两个参数，发送。你会发现，AI 一次就听懂了——因为你给的那句话，本来就是一份写全了的简报。这就是 3000 条话术和分层机制在背后替你做的事。

这就是这篇文章想讲透的事："AI 能听懂人话"不是一句宣传语，而是一套可以拆解、可以验证、可以复用的工程机制。话术库是它的前端，分层是它的后端，文件留痕是它的可追溯性。三者合起来，才让"只需说话"四个字真正成立。

所以，别把这篇文章当成"话术库使用指南"。它是一份关于"AI 改包产品怎么设计输入端"的拆解——话术库怎么分类、需求怎么分层、环境怎么补齐、留痕怎么做。理解了这些，你下次用智改工坊安卓版时，就不只是"会点选话术"，而是明白为什么这样点、点完之后程序在背后做了什么。

最后，送给第一次读这篇文章的你一句话：下次用智改工坊安卓版时，别急着敲字，先去话术库挑一条。你会发现，原来"让 AI 听懂人话"这件事，从来不是靠你写得多完美，而是靠产品把能替你做的都做了。这就是 3000 条话术和分层机制在背后的意义。

这就是这篇文章的全部用意：把"AI 能听懂人话"从一句口号，拆成一套你可以理解、可以验证、可以复用的工程机制。话术库、分层、流水线、留痕——每一环都看得见、摸得着、调得动。理解了它们，你用起智改工坊安卓版来，就不只是"会用"，而是"知道为什么这样用"。

好，这篇文章就讲到这里。希望你下次打开智改工坊安卓版时，不再把它当成一个"会改包的魔法盒子"，而是明白它背后那套"把人话翻译成可执行指令"的机制。理解了机制，你用起来会更顺手、更放心。

下次见。希望你在手机上改包的那一刻，会想起这篇文章里说的：只需说话，就能让应用变成你想要的样子。

（全文完。）

愿你在改包的路上，越用越顺手。

—— 全文完，感谢阅读。

于是你打开安卓修改大师智改工坊（安卓版）时看到的，就是那句口号描述的样子：只需说话，就能让应用变成你想要的样子——在手机上、在现场、在任何有网络的地方，挑一条话术、写一句需求，剩下的定位、修改、打包、验证，交给流水线。产品介绍页与下载入口：https://www.apkeditor.cn/ai-version.aspx（官网 https://www.apkeditor.cn/）。