3000 条话术怎么用：安卓修改大师电脑版的指令写法与附件机制

话术库 · 附件 · 需求写法

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

安卓修改大师智改工坊 · 说话也要说得准

「只需说话，就能让应用变成你想要的样子」——这句话很容易被误读成"随便说一句就行"。实际上，说话的结果取决于说得有多准。同样一句"改一下图标"，有人一次改对，有人改了三遍才发现是把启动页的图标也换掉了。

这就是安卓修改大师智改工坊为什么要在对话框旁边放一个 3000 条的话术库，还要单独做一套附件机制。它们解决的是同一个问题的两端：怎么说清"要什么"，以及怎么让 AI 看见"用什么"。

这篇文章不谈打包也不谈签名，只谈需求。一条好的改包需求长什么样、六大分类各自适合什么场景、附件说明为什么必须写够十个字、话术库那个 XML 怎么改成你们团队自己的术语表——以及两个把"改三次"变成"一次改对"的真实例子。

一、改包这件事，难的不是改，是说

先看一个反直觉的现象：在整条链路上，最慢的环节往往不是反编译、不是打包、不是签名，而是"想清楚要改什么、并且说清楚"。

因为前面那些步骤都有确定的成功判据：反编译成功就是生成了 apktool.yml，签名成功就是 verify 通过。而"改对了没有"没有机械判据，只有人的判断。这就意味着，需求本身的模糊性会被完整地带到结果里，一点都不会被技术环节消化掉。

举个具体的：你说"把应用名改一下"。这句话里有四个没说的东西——改成什么？只改桌面上显示的名字，还是连设置页里的标题、关于页里的版本信息一起改？如果应用有多语言资源，中文改了，英文和繁体改不改？包名要不要跟着改（改了就不能覆盖升级）？

这四个问题不问清楚，改出来的结果就有十六种可能，而其中只有一种是你要的。这不是 AI 能力的问题，是需求信息量的问题。任何执行者面对信息不足的需求，都只能猜。

二、一条好需求的五段结构

话术库里那 3000 条指令，每一条都是同一个结构。这不是巧合，是刻意统一的结果——因为它们要教你的不是"这句话怎么说"，而是"一条需求该包含哪几段"。

五段里最容易被跳过的是范围和验收，而这两段恰恰是决定返工率的。

范围的意义在于划出"不要动"的边界。改一个应用名，如果不说"不要改包名"，执行者可能顺手把包名一起改了，结果老用户装不上新版本。这类问题不是"做错了"，而是"多做了一件不该做的事"——而多做往往比少做更难发现。

验收的意义在于把主观判断变成客观检查。不要说"改得好看一点"，要说"改成附件这张图，主色是 #0EA5E9"。前者无法验证，后者装到手机上瞄一眼就知道对不对。

把五段串起来，一条需求大致是这个形状：

把应用图标换成本次附的这张 png（要做什么）
圆角矩形，不要自己加描边，保持原图留白（细节要求）
主色 #0EA5E9，在 192x192 下不能被裁掉内容（参数参考）
只改桌面图标与设置页顶部图标，启动页图和关于页不动，包名不要改（范围）
改完图标在桌面上应显示为新图，且应用能正常打开（验收）

这五段写完，字数也就一百出头，比"把图标换成新的"多花两分钟。但它把"十六种可能"压缩成了"一种结果"。这就是这套话术库想传达的东西：不是让你记住 3000 句话，而是让你记住这五段。

三、六大分类：先说清它想帮你解决哪类问题

话术库分了六个大类，共 3000 条。分类本身就是一个信息——它告诉你这个工具认为改包这件事可以拆成哪六种诉求。

这六个分类的排序不是随意的：从"最表层的视觉"到"最深层的代码"。界面美化只动资源文件，风险最低；插件添加要动代码逻辑，风险最高。这个顺序天然构成了一条学习路径——新人不该从插件添加开始，而应该从常规修改或界面美化开始。

三条使用提示，能省不少时间：

1. 点「选择」直接填进输入框，不用手动复制。填进去之后一定要改——把里面的占位内容换成你自己的值。
2. 点「复制」复制正文，适合你要把它粘到别的地方（比如团队文档、需求单）再改。
3. 先按分类找方向，再按关键词找具体。不要从第一条开始翻——3000 条翻不完。

有一个心态上的建议：把话术库当成句型模板，而不是答案库。它的价值不在于"这条正好是我要的"，而在于"这条示范了这类需求该怎么写"。看懂三条，你就能自己写第四条，而且比库里的更贴合你的场景。

四、附件机制：让执行者看见你的素材

需求里最难说清的东西，往往是"那张图"和"那个文件"。你说"用我们新的 logo"，对方不知道是哪一个文件；你把文件放在桌面，执行者看不见桌面。

点「选择附件」可以一次挑多个文件，并且为每个文件写一句"它是干什么用的"。这一步是整个机制的核心，也是最多人偷懒的地方。

程序会校验两件事：

为什么是 10 个字？因为"logo"（4 个字）和"新 logo，主色蓝、透明底、192 见方"（十几个字）的区别，不在于长短，而在于后者包含了一个判断依据。10 个字是一个下限，它拦不住所有敷衍，但能拦住"懒得写"。

校验通过之后，这些附件会被拼成一段结构化的文本，跟着需求一起发出去，格式大致是：序号 + 文件路径 + 一句分隔符 + 用途说明。也就是说，执行者收到的不是一堆孤立的文件，而是"这个文件是干什么的"这份说明书。

还有一个容易被误解的点：附件说明不会进历史。历史里只留你的需求原话。原因很实际——附件路径会过期，文件会被移动或删除。把会过期的信息存进历史，下次点「选择」复用那条需求时就会指向一个不存在的文件，反而增加困惑。所以复用时需要重新选一次附件，这是有意为之的。

五、你写的那段话，发出去时被加了三层

点下「立刻修改」之后，你写的那段话并不是原样发出去的。它在离开输入框之后被组装了一次，最终发出去的内容由三部分构成。

第三层最值得说。它看起来是"技术细节"，实际上解决了一个协作上的根本问题：执行者不该负责它不该负责的事。

如果没有这段固定说明，改包这件事很容易变成"谁都想做全流程"：改完了顺手打个包，包打出来了顺手签个名，签名方式还和主程序用的不一样。结果就是同一份改动，产出两个来历不同的 apk，谁也不知道哪个该发出去。

把边界写进每次请求里，等于每次都重申一次分工：你只负责改，打完包这件事交给链路。这不是不信任，是让整条流水线只有一个出口——所有产物都从同一个打包窗口出来，用同一套签名方案，写同一份 pack.log。这样才能追溯。

改完之后，标志文件 ai_done.flag 会被写进项目目录，主窗口每 2 秒轮询一次，读到就弹打包窗口，同时把标志删掉。这个"读到即删"的细节很重要：它保证了同一个标志不会被消费两次，也就不会重复打包。

六、把话术库改成你们团队自己的术语表

3000 条话术的内容来源是一个 XML 文件，位于程序目录下的 Resources\话术库.xml。关键在于：它可以手改，改完点刷新就会重新读取。

这个设计打开了一个很大的口子：你可以把团队的专有说法写进去。比如你们内部把"开屏广告"叫"闪屏位"，把"关于页"叫"版本信息页"，把主色叫"品牌蓝 #0EA5E9"——这些词在通用话术库里不会出现，但在你们的项目里天天出现。

做法很朴素：

1. 先备份原文件。手改 XML 有语法风险，改坏了要能退回去。
2. 照现有条目的结构写。不要自己发明新字段——程序按固定结构读，多出来的字段不会生效，少了的会导致整条读不出来。
3. 一次只加十条以内，加完立刻刷新验证。加一百条再刷新，出问题时你不知道是哪一条坏了。
4. 改完在团队里同步这份文件。否则每个人机器上都是一份不同的术语表，沟通成本反而上升。

值得强调的是最后一条。术语表的价值来自共享——如果只有你一个人在用改过的版本，那它就不是术语表，只是一份私人笔记。要么全员统一，要么干脆别改。

另一个更轻量的做法：不修改 XML，而是把团队常用的几条需求存在一个文档里，需要时复制粘贴。这样做的好处是不动程序文件，升级版本不会覆盖；坏处是不能点「选择」一键填入。两种做法都行，取决于你们改包的频率。

七、两个实例：从"改三次"到"一次改对"

技术和方法讲完，最后还是要落到具体动作上。下面两个例子都来自自家的应用，一个是纯视觉改动，一个涉及边界判断。

实例一：把内部工具的启动页换成新宣传图

模糊的写法："把启动页换一下，用附件这张图。"

这条需求会带来什么结果？大概率是：图放上去了，但被拉伸变形了；或者图只覆盖了中间一块，上下有黑边；又或者启动页是换了，但应用图标也跟着变了——因为对方不确定你说的"启动页"是指哪个资源。

改写成五段之后：

把启动页背景换成附件这张图（要做什么）
全屏铺满，等比缩放到充满，允许裁掉左右多余部分，不要拉伸变形（细节要求）
图片原始尺寸 1080x1920，主色 #0B62D6（参数参考）
只改启动页背景；应用图标、关于页、登录页都不要动，包名不改（范围）
打开应用时第一屏应看到这张图，铺满全屏且没有黑边，随后正常进入主界面（验收）

附件说明怎么写：不是"新图"，而是"这张图用在启动页背景，不要裁掉中间的文字区域，不要加圆角"。

改完怎么验证：打包完成后程序会自动装到设备并拉起应用。第一眼看第一屏——图是不是铺满、有没有黑边、中间的文字有没有被裁。这一步的验证成本极低，看一眼就够了，因为验收条件在需求里已经写明确了。

实例二：给自家应用名加"内测版"后缀，但不能影响升级

这个例子看起来简单，其实藏着一个边界问题：改应用名的时候，会不会顺手把包名也改了？

模糊的写法："应用名后面加个内测版。"

风险在于：如果执行者把包名也改了，这个包就不再是原应用的"下一版"，而是一个全新的应用。装上去之后是两个图标、两份数据，而不是覆盖升级。用户会以为自己的数据丢了。

改写成五段之后：

把桌面上显示的应用名改成「记账助手 内测版」（要做什么）
只改显示名称，保留原名作为前缀，中间一个空格，后缀用全角括号里的"内测版"（细节要求）
保持原有字体与大小，不要缩短到被系统截断（参数参考）
只改应用显示名；包名、版本号、图标、所有界面内文字一律不动（范围）
装到设备上，桌面图标下方的文字应是新名字且完整显示，应用能正常打开（验收）

为什么"包名不动"这句必须写：因为它是这条需求里唯一一个"不说就可能被做"的动作。改应用名的时候，包名与显示名在资源里离得很近，顺手一起改是很自然的事。写清楚"不要动"，成本是一句话，收益是省掉一次"用户数据看起来丢了"的事故。

改完怎么验证：装到已经有旧版的设备上。如果能直接覆盖安装、打开后数据还在，说明包名没变；如果提示安装失败或者出现第二个图标，说明包名被改了——这时候不要怀疑设备，回去看需求里的范围那段有没有写清楚。

这两个例子的共同点：真正决定成败的不是"要做什么"，而是"不要做什么"。人写需求时天然只想着想要的结果，而执行者面对的是所有可能的结果。把不要的那些划掉，才是需求的价值所在。

八、六则可以直接抄的需求模板

下面六条覆盖了最常见的六类改动。每条都按五段写全，可以直接复制、改掉方括号里的值就能用。它们不是话术库里那 3000 条的替代，而是让你在打开话术库之前，先有一个能对照的样板。

注意这六个模板都有一个共同的收尾：最后一句一定是可观察的现象，而不是主观评价。"能看到新图""不出现黑边""文字不溢出""白字仍然清晰"——这些都能在装上去的一瞬间判断真假。"改得好看一点"不能。

九、十个关于写需求的提问

这些问题大多来自"用了几天之后才意识到"的场合，也正是它们让改包从"试试看"变成"稳定产出"。

十、需求的三个层次：从改动到规范

写需求这件事有一个成长曲线。同样一个人，用一个月之后写出来的需求会和第一天完全不同。这个过程大致分三层。

第一层：描述改动。"把图标换掉""把名字改了"。这一层的需求只说了方向，结果高度依赖执行者的理解。新人几乎都从这里开始，也几乎都要经历一两次返工才会往上走。

第二层：描述边界。开始懂得写"不要动什么"，开始给具体值，开始写验收。这一层的需求已经能稳定产出正确结果，但每次都要重新想一遍，成本不低。

第三层：沉淀规范。把反复用到的判断写成固定文本——图标规范、文案语气、主色与层级、什么该改什么不该改。这一层的需求会变得很短，因为大量的共识已经存在于规范里，不需要每次重复。

值得一提的是，这三个层次不是替代关系。改一个小东西，第一层的写法就够了——为了一次换图标去翻规范，反而是浪费。而在做一批应用的统一改造时，第三层的价值才会显现。

判断自己在哪一层，有个简单的标志：你返工的次数。如果同类型的改动每次都要改两遍以上，说明你的需求还停在前两层；如果你已经能一次说对，那不管你有没有写下来，你其实已经在用第三层的思维了——只差把它变成文本，让别人也能用。

十一、三种失败模式：需求写得越认真，越容易踩

写完一大段精确的需求之后，还会出现一种新的挫败：结果依然不对，而且看不出哪里错了。这种情况通常不是"写得太少"，而是"写得太多"或"写歪了"。有三种失败模式，几乎每一个人都会遇到一次。

模式一：过度指定，把实现方式也规定死了

症状：需求里出现了大量"用什么文件、放哪个目录、改哪个字段"这类实现细节，但结果反而不对。

原因：需求的本质是"描述目标"，而不是"描述步骤"。一旦你把步骤写死，就等于替你并不完全了解的现场做了一个决定。而现场可能有比你想象中更多的分支——比如同一个图标资源在深色模式下还有一份副本，你只指定了那一份，另一份没改，结果用户切到深色模式就看到了旧图。

怎么改：把"步骤"换成"结果"。不要写"改 res/drawable-xxhdpi 下的那个文件"，而是写"桌面上显示的图标应变成新图，深色模式下也一样，设置页顶部图标也同步"。后者覆盖了所有实现路径，前者只覆盖了一条。

模式二：指令互相冲突，执行者只能二选一

症状：需求里有两句话在逻辑上不能同时成立，结果只实现了其中一句。

常见组合："全屏铺满"和"不要裁掉图的任何部分"（图的比例和屏幕不一致时必然冲突）；"字号加大"和"不要改变整体高度"（文字变大必然撑高）；"去掉开屏广告"和"不要改动任何界面跳转"（去掉广告本身就是一次跳转变更）。

怎么改：写完需求后，逐句问一遍"这两句能不能同时成立"。如果不能，指定优先级——"以铺满为优先，允许裁掉左右，但不要裁掉中间的文字区域"。指定优先级本身就是一种专业表达，它说明你理解这里有取舍。

模式三：依赖了没写出来的隐含状态

症状：需求本身没问题，但结果和预期不符，而且换一台机器、换一个包结果就不一样。

原因：你的需求依赖了一些"你以为对方知道"的前提。比如"把主色改成品牌蓝"，但没说是哪个蓝；"按上次那个图改"，但上次是在另一个项目里；"应用名加内测版"，但没说加在什么位置、用什么括号。

怎么改：凡是能用具体值表达的，就不要用指代。"品牌蓝"写成 #0B62D6；"上次那个图"变成附件加一句说明；"内测版"写成"记账助手 内测版"。这一步没有技巧，只有纪律——把每个指代词都换成具体值，需求的可执行性会立刻提升一个档次。

十二、一句话和三千条，其实是同一件事

文章写到这里，可能会有一个疑问：既然强调"只需说话"，为什么又要搞出三千条话术、五段结构、十项校验这么多规矩？这不是自相矛盾吗？

并不矛盾。那三千条存在的意义，是让"说话"这件事的门槛降到最低——你不需要从零构思，只要在现成的骨架上改几个值。而五段结构存在的意义，是让"说话"这件事的上限足够高——熟练之后，你能写出一次就对的复杂需求。

换句话说，三千条是给小白的扶手，五段结构是给熟练者的语言。同一套机制同时服务两个人群，这才是它真正的设计难点。如果只做话术库，熟练的人会觉得束手束脚；如果只做输入框，小白会卡在第一句话上不知道该说什么。

这也是"适用人群广"这句话在技术上的具体含义。它不是一句宣传，而是由几个具体设计支撑起来的：

还有一个设计上的细节同样服务于此：那个使用技巧提示条可以在设置里关掉。对新手它是有用的引导，对熟练者它是视觉噪音。同一个功能，对两种人意味着两件相反的事——这种时候唯一正确的做法不是"选一个人群站队"，而是给一个开关。类似的开关在这套软件里还有很多：占屏比例能调、间隙能调、启动是否吸附能调、主题能换。它们共同构成了一个判断：默认值服务大多数人，可配置项服务所有人。前者决定了第一印象，后者决定了长期关系，两者缺一不可——只有默认值，熟练的人会嫌吵；只有可配置项，新手会不知道该选什么。

这张表里最值得注意的是最后一行。偶尔用一次的人是最容易被忽视的群体：他们不会去学任何东西，也不会读文档，只会在需要的时候打开软件试一下。对这个群体来说，决定成败的不是功能多强，而是"第一次打开有没有被吓到"。所以有了十套配色、有了可拖动的无标题栏窗口、有了每 12 秒轮换一条的使用技巧——这些都不是核心功能，但它们决定了这个软件对一个陌生人友不友好。而这件事几乎没有中间状态：第一次打开要么顺畅，要么被吓退，很少会有人给自己第二次机会。

十三、他们怎么说：来自真实使用的反馈

这些反馈里反复出现一个词：返工。有意思的是，几乎没有人把返工归因于工具不行，而是归因于自己一开始没说清。这是一个很健康的认知——它意味着人开始把"表达"当成一项可以练习的能力，而不是把结果交给运气。这种转变一旦发生，效率的提升是复利的——因为一条写清楚的需求会被反复复用，而一条模糊的需求每次都要重新想一遍。

回到那句口号：只需说话，就能让应用变成你想要的样子。这句话的前半句是承诺，后半句是条件——前提是"你想要的样子"在你心里是清楚的，并且说出来了。这套话术库和附件机制，做的就是帮你把心里那团模糊的东西，变成一段能被执行的文字。

所以它真正的门槛不在技术，在表达。而表达这件事，恰恰是所有人都能练、且练了就有效的——你不需要懂 smali，也不需要知道 zipalign 在做什么，只需要把"要什么"和"不要什么"分开说清。这大概就是这套设计最想传达的一点：改包这件事，对小白友好，不是因为把复杂藏起来了，而是因为把入口放在了人人都有的能力上。

想了解安卓修改大师智改工坊的话术库分类与完整功能，请访问产品介绍页：https://www.apkeditor.cn/ai-version.aspx。