用 AI 改包，最大的门槛其实不在工具，而在「开口」这一下。有想法但写不出来，是绝大多数新手的真实状态： 脑子里清楚「我要把启动页那张图换掉、顺便把应用名改短一点」，打开输入框却只打出一句 「帮我改一下这个 App」。这句话发出去，AI 只能猜；猜出来的东西，多半不是你想要的。 智改工坊在这件事上的做法是：把别人已经写好的需求摆在你面前，让你从改它开始。

一、「不会写需求」到底卡在哪：三种典型状态

在教人用 AI 改包的过程中，你会发现「不会写」并不是一种状态，而是三种完全不同的状态。 它们的成因不同，解法也不同；话术库之所以有效，是因为它同时照顾到了这三种。

状态一：不知道能改什么，所以不知道要说什么

这是最普遍的一种。你手上有一个应用，觉得它「哪里不太对」，但说不出具体哪里不对， 更不知道哪些东西是「可以改的」。人在不知道边界的时候，描述会自然变得非常笼统。

对应的解法是「先看菜单再点菜」：把 3000 条话术当成一份可以逐条浏览的清单。 你不需要带着明确的目标去搜索，只要按分类翻一翻，就会不断遇到「原来这个也能改」的瞬间。 翻的过程本身就是学习——它帮你把模糊的不满，翻译成了具体的可执行项。

状态二：知道自己要什么，但不知道怎么描述得让 AI 听懂

第二种人目标很清楚：「我要把首页那个一直弹的窗口去掉」。但他说出来就是这一句， 里面缺了关键的东西——什么样的窗口算「那个窗口」、去掉之后原来的位置怎么处理、 会不会影响别的功能、改完之后怎么判断成功了。这些缺失的部分，恰恰是 AI 最容易猜错的地方。

对应的解法是「照着结构填」：一条成型话术已经把该说的位置都留好了。 你只需要把它里面的具体对象换成你的，其余部分照抄。相当于有人先替你写了提纲， 你负责填内容——比从白纸开始容易十倍。

状态三：技术没问题，但懒得每次都重写一遍

还有一类使用者本身就懂改包，甚至自己写过 smali。他不需要别人教，但他也不想每改一个包， 就把「应用名要改、图标要换、版本号要动、启动页要清理」这一串重复描述再打一遍。

对应的解法是「模板化」：话术库对这类人来说是效率工具。挑一条最接近的， 改几个参数直接发出去，省下的不是理解成本，而是打字成本和遗漏风险。 越是熟练的人越清楚「每次重写容易漏」，所以他们反而更愿意用模板。

一个判断标准：如果你写下的需求读起来像「帮我把它弄得好看一点」， 那你处在状态一；如果像「去掉那个弹窗」但只有一句话，你处在状态二； 如果你写得又长又准只是嫌麻烦，你处在状态三。三种状态都用得上话术库，但用法不同—— 状态一适合浏览，状态二适合照抄结构，状态三适合拿来直接改参数。

为什么一套话术能顶掉一部分「经验」

传统上，改包的「会」与「不会」之间隔着一层经验。老师傅知道一件事该描述到什么颗粒度： 要换启动页，他会顺口说明是新装首次启动还是每次启动；要改应用名，他会想到顺便确认一下 桌面快捷方式上的名字是否同步。这些考虑不是天赋，而是踩过坑之后留下的条件反射。

经验之所以难以传递，是因为它太零散——没人能一次把两百条注意事项讲完， 而讲完你也记不住。话术库提供了一条不同的路径：不去讲道理，直接把「考虑周全之后的需求长什么样」 摆出来给你看。你看多了，自然就形成了自己的条件反射。

这也是为什么话术库值得被当成学习材料，而不只是一个复制粘贴的来源。 每一条都是一份「别人怎么想这件事」的样本，看的是措辞，学的是思路。

换个角度看：「不会写需求」这件事最麻烦的地方是，它看上去像是你不努力， 实际上只是没人告诉过你一条完整需求该包含什么。话术库补的是这个信息差， 而信息差是最容易被补上的一种差距。

二、话术库的骨架：六大分类各自解决什么问题

3000 条指令不是一堆散装文本，它们被收在六个分类下。分类的意义不只是「好找」， 更重要的是让你在动手之前先想清楚：这次改动属于哪一类、它天然会牵扯到什么。

分类	典型的改动对象	动手前该先想清楚什么
界面美化	图标、启动页、背景图、配色、按钮与文案样式	素材准备好了吗？同一张图在不同密度目录下都要处理吗？
弹窗引流	启动弹窗、公告、入口按钮与跳转时机	什么时候出现、出现几次、会不会挡住关键操作要点写清
去除限制	自有应用里的功能开关、试用期与内部账号校验	确认是你自己或已获授权的应用，且改动范围事先划定
常规修改	应用名、版本号、包信息、默认语言与默认项	这类改动表面简单但影响面广，验收项要一条条列
混淆去毒	冗余权限、可疑组件、多余的后台行为	先确认哪些是应用本身需要的，避免误删导致功能失效
插件添加	接入自定义功能模块、扩展能力与配套资源	插件文件与使用说明要作为附件一起给它，别只给路径

仔细看第三列，会发现一个共同的规律：每一类改动，真正的难点都不在「改」， 而在「说清边界」。界面美化要交代素材和适配范围，弹窗引流要交代时机与频次， 常规修改要交代验收项，插件添加要交代配套文件。话术库把这些边界问题提前摆出来， 让你在写需求时就顺手回答了它们。

新手应该从哪一类开始

六大分类的难度并不相同。对完全没接触过改包的人来说，从哪一类入手，会明显影响第一次的体验。

这个顺序不是硬性规定，而是一个降低第一次失败概率的建议。第一次成功很重要—— 它会让你愿意写第二条需求；而第一条就撞墙的人，往往就此认为「这东西不适合我」。 把容易见效的放在前面，是一种对自己友好的学习安排。

三、拆开一条话术：五个字段是怎么分工的

这是整篇文章最值得慢慢看的一节。一条成型话术的信息量，远大于「一句话描述」， 因为它被拆成了五个字段，每个字段回答一个问题。

为什么必须有「范围」和「验收」这两个字段

前三个字段很直观，多数人凭直觉也会想到；后两个字段才是话术库真正的价值所在。

「范围」防的是误伤。改包最常见的事故不是「没改到」，而是「改多了」： 想换一个图标，结果整套图标资源都被替换；想去掉一个弹窗，结果连带把相关的引导流程也弄没了。 AI 在缺少约束时，会倾向于把「看起来相关的东西」一起处理——这不是它的错， 是你没告诉它哪里是边界。

「验收」防的是自我欺骗。没有验收项的需求，改完之后你只能凭感觉说「好像可以了」。 有验收项的需求，改完之后你可以一条条对照：应用名是否已改、启动页是否已换、 原功能是否可用、有没有新增的弹窗。这些条目在写需求时可能只花你半分钟， 但在验收时能帮你省下一整轮返工。

怎么改一条话术：只动该动的部分

话术是模板，不是填空题的标准答案。改它的原则只有一条：动参数，别动结构。 参数指的是具体的文件名、文本内容、数值、时机这类只能由你决定的东西； 结构指的是「要做什么 / 细节要求 / 参数参考 / 范围 / 验收」这套骨架——它已经被验证过好用，不需要你优化。

初学者最容易犯的错，是觉得模板「太啰嗦」，于是动手把细节要求和范围两段删掉， 只留下「要做什么」和一句参数。结果就是改出来的东西方向对、细节全不对， 再改一轮又要重新描述一遍——反而更慢。

四、四步上手：从选择到发出，一次走通

讲完结构，说操作。第一次用话术库，按这四步走一遍，你会发现整个过程比想象中短。

第一步：挑一条最接近的话术

打开项目详情页，点「选择话术」，按分类找到最接近你意图的那一条。 判断标准不是「完全匹配」——完全匹配几乎不存在——而是「改动的对象一致」。 只要目标对象对了，具体参数都是可以替换的。

挑好之后有两个动作可选：点「选择」直接填进输入框，或者点「复制」把正文复制走。 前者适合就在这儿改，后者适合你想先放到别处斟酌一下措辞。多数情况下用「选择」更顺， 因为填进去之后就能看到它和你项目的上下文放在一起是什么样子。

第二步：把参数换成你的

填进输入框之后，逐项检查那些「必须由你决定」的值：文本要改成什么、 图片文件叫什么名字、时机是在启动时还是操作后、范围是否要缩小到某一个页面。 这一步花的时间最多，也最值得花——它决定了改出来的东西是不是你的。

第三步：需要素材就上附件，并写清用途

凡是涉及外部素材的改动——换图标、换背景图、添加插件——都应该走附件，而不是在需求里写一句路径。 点「选择附件」可以一次挑多个文件，然后给每个文件写一句它是干什么用的。

提交时会校验两件事：文件现在能不能用（是否存在、是不是目录、是不是 0 字节、能不能读出来）， 以及说明是不是写够了 10 个字。第二项校验看似严格，其实是在保护你： 「换图标」三个字和「把桌面图标换成这个文件，注意保留圆角」十个字，交出去的信息量完全不同。

通过校验后，程序会把这些内容拼成一段固定的格式跟着需求发出去，形如「序号. 文件路径 —— 用途说明」。 AI 拿到的不再是一个孤零零的路径，而是「文件 + 用途」，改起来不会猜错位置。 还有一处细节很贴心：附件说明不会进历史记录，历史里只留你的需求原话—— 这样下次把这条需求填回输入框时，也不会带着一个可能已经失效的旧路径。

第四步：发出、等待、验收

点「立刻修改」，需求原文和修改日期会写进项目的 history.ini，需求送进右侧 AI 窗口执行。 AI 改完会在项目目录留下标志文件，主窗口每 2 秒看一次，读到就自动弹打包窗口， 从回编、对齐、签名一路跑到校验。

出包之后就是验收时刻：把你写下的验收项一条条对。哪一条没达到， 回到详情页的历史里找到这条需求，点「选择」把它填回输入框，补上这次的调整再发一次—— 不必从零重写，这也是话术库和历史记录配合起来最省事的地方。

步骤	你在做什么	程序在做什么
挑话术	按分类找到最接近的一条，点「选择」填入输入框	从 Resources\话术库.xml 读取并按分类展示，可点刷新重新读
改参数	替换文本、文件名、时机、范围这些只能由你定的值	——
上附件	多选文件，给每个文件写一句用途	校验文件可用性 + 说明不少于 10 个字，拼成「序号. 路径 —— 用途」发出
发出	点「立刻修改」	需求原文 + 修改日期写入 history.ini，需求送进右侧 AI 窗口
验收	对着验收项逐条核对	读到 ai_done.flag 自动打包，装到设备上并拉起应用

把四步走一遍：以「改应用名」为例

抽象地讲流程不容易记住，用一个最简单的例子走一遍会清楚很多。假设你要把一个自有应用的名字改掉， 顺便把桌面图标换成新设计的版本。

挑话术。这属于「常规修改」（改名称）与「界面美化」（换图标）的组合。 先在常规修改里找到改应用名的那条，点「选择」填进输入框。

改参数。把模板里示例的名字换成你的实际名字；如果模板提到别的地方 （比如应用内展示的名称、关于页面里的版本信息），确认这些要不要一起处理， 并在需求里写清你的决定。这一步是对模板最关键的改动，也是最容易偷懒的地方。

上附件。图标属于外部素材，点「选择附件」把设计稿文件选进来， 给它写一句用途——注意要写够 10 个字，比如「把桌面图标换成这个文件，尽量保留原有留白」。 这句话会以「序号. 文件路径 —— 用途说明」的形式跟着需求一起发出去。

发出与验收。点「立刻修改」。需求原文进 history.ini，AI 在右侧窗口执行； 完成后留下标志文件，主窗口读到就自动弹打包窗口，四步出包，随后自动装到设备上并拉起应用。 这时你按自己写下的验收项核对：应用名是否已改、图标是否换成了新版本、 原有的功能是否仍然可用、有没有出现多余的提示。

如果图标换了但边距不对，不要重新写一条需求。回到详情页的历史，找到刚才那条， 点「选择」把它填回输入框，在原文后面补一句对边距的要求再发一次。 整个过程你在做的事只有一件：在上一次的基础上把话越说越准。

五、五种常见误用与对应的改法

用了一阵子之后，绝大多数人的问题都很相似。下面这五种情况，几乎每个人都会遇到至少一种。 它们有一个共同的规律：都不是「不会写」的问题，而是「写漏了某一段」的问题。 换句话说，只要你在发出需求之前，把五个字段从头到尾扫一遍，其中大部分都能提前避免。

六、让它长成你自己的库：话术库.xml 与刷新

3000 条是起点，不是上限。这套话术库的存储方式很朴素：内容来自程序目录下的 Resources\话术库.xml， 这是一个可以直接手改的文件；改完之后点一下「刷新」，程序会重新读取。

这个设计的意义在于：你的行业经验可以沉淀下来。比如你是做门店工具的，常年的改动就那么几类—— 改店名、改客服电话、换 banner、调公告弹窗时机。与其每次去 3000 条里翻找再改参数， 不如把自己最常用的几条固定成模板，写明你们自己的范围与验收标准。 半年之后，这个库就是你自己的资产。

另外，话术库和附件系统是互补的：话术负责说明「做什么、做到什么程度」， 附件负责交付「用哪些文件」。一个成熟的自建话术，往往开头就把需要随附的素材列清楚了， 这样你在准备素材的时候不会漏东西。

团队里怎么共用这一套

如果改包不是你一个人的事，话术库还能承担一个额外角色：统一团队的描述方式。

在没有统一模板的团队里，同一个改动由两个人描述，往往会变成两条不同的需求， 改出来的结果也就有细微差别。这种差别在单个包上看不出来，但积累到几十个包之后， 会变成「同一个应用的各个版本风格不统一」这种很难返工的问题。

把你们团队的标准改动整理进话术库，好处有三点：一是描述方式统一，谁发出去的需求都是同一个结构； 二是验收标准统一，验收项写在模板里，不会因为执行的人不同而放松； 三是新人上手快，他不需要理解为什么这么写，先照着做，做着做着就懂了。

落地方式也很轻：直接在程序目录的 Resources\话术库.xml 里加条目，改完点一次刷新， 所有人重新打开就能看到。不需要额外的部署流程，也不需要谁去维护一份文档—— 模板本身就是文档，而且是被真实使用的那一种。

把话术库当成一本可以查的手册

最后一个建议与操作无关，与心态有关：不要只在「准备改包的时候」打开话术库。 平时没事翻一翻，看看六大分类里都有什么，对自己手上这些应用能做哪些改动形成一个大致的地图。 这份地图会让你在看到问题时反应更快——客户说「这个弹窗太烦」，你立刻知道这属于弹窗引流， 里面有一类现成的写法；同事说「这个包的权限有点多」，你知道这属于混淆去毒那一类。

换句话说，话术库不只是一套模板，它还是一份关于「改包能做什么」的说明书。 新手从它身上学到的，往往不是怎么写一条需求，而是这个领域的动作清单长什么样。

七、用户评价：新手是怎么迈过第一步的

下面这些反馈的共同点很明确：他们都不是从「会写需求」开始的，而是从「先照着一条模板改」开始的。

换个角度说，话术库解决的是一个很像「第一次做饭」的问题：没人指望你先背下菜谱原理再进厨房， 通常是照着菜谱做两次，手感就来了。改包也是一样——先把话说得像一条完整的需求， 至于为什么要这么说，做上几次自然就想通了。先模仿，后理解，顺序反了反而学得慢。

八、适用范围与合规提醒

回到「不会写需求」这件事上。写不出需求，本质上不是表达能力的问题，而是信息结构的问题： 你不知道一条完整的需求应该包含哪些部分，于是只能写出脑子里最先浮现的那半句。 话术库把结构摆在你面前，你只需要往里填内容——先照抄，再改写，最后形成自己的习惯。

还有一点需要说清楚：话术库是描述方法的集合，不是功能边界的承诺。 一条话术能不能落地，取决于应用本身的结构、你拥有的权利范围，以及你写得够不够具体。 遇到改不动的地方，程序会给出提示与日志（比如反编译阶段的失败会指向 apktool.log）， 这些反馈同样是学习的一部分——它们告诉你这个包的真实边界在哪里。

所以第一次用的话，最好的路径是：挑一条最像的、只改参数不改结构、发出去、按验收项检查一遍。 走完这一轮，你会对「一条需求该长什么样」有具体的认识。之后你写出来的需求， 会比你自己以为的规范得多。

如果要把这套方法浓缩成一句话，那就是：模板负责结构，你负责具体，验收负责结论。 结构不用你操心，具体必须你来说，结论必须能被检查。 三件事各归各位之后，「不会写需求」就不再是一个障碍，而只是一个需要花二十分钟跨过去的起点。