把 3000 条话术变成自己的模板库：搜索、改造、复用

如果你用过智能修改电脑版，大概经历过这样的场景：把 APK 拖进窗口，等反编译完成，进入详情页，左边是需求输入框，右边是一排排话术。数量很多，分类也不少，翻了两页之后，你会随便点一条看起来差不多的，填进去，点“立刻修改”。结果要么能用，要么差一点意思，要么得反复补充说明。问题通常不在工具，而在“话术”和“需求”之间还差一步：把别人的句子，改成你自己的、可执行的那一句。

这篇教程不讨论底层原理，只讲使用技巧。我们把这 3000 条话术当成一座原料仓库，目标是搭出一条稳定的流水线：先用分类和关键词找到 3 条候选，再把候选改写成带验收标准的需求，最后把验证过的那一条存进自己的模板库。整个过程不需要背命令，也不需要记住复杂的文件路径，需要的是判断力和一点点格式感。

一、先想清楚：模板库解决的是“重复解释”的问题

很多人第一次打开话术库，会把它当成“照抄就能出结果”的答案书。实际用几次就会发现，直接照抄的成功率并不稳定。原因很简单：话术库里的话是通用句式，而你的应用有具体的名称、颜色、页面、版本号和业务边界。通用句式少了这些信息，执行时就只能靠猜。猜对了是运气，猜错了就变成了返工。

所以我建议先建立三个概念，后面的操作都会围绕它们展开。

第一层：原话库。就是内置的 3000 条，按六大分类组织，每条都是一种“说法”。它的价值是提供措辞和思路，让你知道一件事可以怎么描述，而不是替你决定要改成什么样。

第二层：改写稿。你选中一条话术，填入输入框，然后补上目标、范围、边界和验收。改写稿只对当前这个项目有效，做完就结束，不需要长期保存。

第三层：模板库。把验证成功的改写稿去掉具体项目信息，留下结构和可替换的占位符，存进 Resources\话术库.xml。下次遇到同类需求，直接搜出来，替换三五处信息就能用。这一层才是真正的资产。

三层之间的关系，可以用一个很朴素的标准判断：原话库负责“怎么说”，改写稿负责“这次怎么做”，模板库负责“下次怎么更快”。如果一条内容不能让你下次更快，它就不值得进模板库。

再说说工具本身。智能修改电脑版运行在 Windows 10/11 64 位环境，需要 .NET Framework 4.6.2 或更高版本。拖入 APK 后，它会自动完成解析、反编译，把工程准备好；你在详情页用自然语言描述需求，点“立刻修改”，需求会被送进右侧的 AI 工作区执行；执行完成后，程序继续回编、对齐、签名、校验，必要时还能自动装到手机或模拟器里看效果。一个 12 MB 左右的包，反编译通常三秒左右就能完成；如果超过十分钟还没有结束，程序会中断并报错，避免你无限等待。这些细节决定了我们的操作节奏：反编译很快，所以可以小步试错；打包和安装需要时间，所以每次提交前要把需求写清楚。

学会这套方法之后，你得到的不是一个“话术收藏夹”，而是一套可以交接的工作方式。新人拿到你的模板库，不需要理解每条话术背后的全部背景，也能按格式写出合格的需求；你自己隔三个月回来，也能一眼看懂当时为什么这样改。

二、话术库到底在哪里：Resources\话术库.xml 的位置、结构与刷新

要把话术变成自己的，第一步不是改内容，而是先找到文件。智能修改电脑版的话术库放在安装目录下的 Resources\话术库.xml。如果你不记得安装到哪里，可以右键桌面快捷方式，选择“打开文件所在的位置”，然后进入 Resources 文件夹。便携版或自定义目录安装的，同理，找到主程序所在目录即可。

这里有一个很现实的坑：如果程序安装在系统盘的程序目录里，直接修改文件可能遇到权限不足，保存失败，或者保存到了另一个位置。解决办法有两个：一是用管理员权限打开文本编辑器；二是把整个程序目录放到自己有写权限的位置，比如 D 盘的自建文件夹。后者更省心，也方便后面做版本备份。

动手之前先备份。把原文件复制一份，命名为 话术库.backup.xml，或者放进一个带日期的文件夹。备份的意义不只是防手滑，更是让你在改坏之后能快速回到已知可用的状态。后面讲团队共享和版本备份时，这套习惯会继续用到。

用任意文本编辑器打开文件，你会看到它是 XML 结构：整体有一个根节点，下面按六大分类组织，每个分类里有大量条目，每条包含一句完整的话术。不同版本的具体字段可能略有差异，所以不要凭想象改标签名，先观察两三条的写法，照着现有结构改文字，是最稳妥的方式。需要记住三条底线：标签必须成对闭合；不要删除分类节点；不要破坏条目之间的层级关系。只改引号里的文字内容，风险最低。

还有两个 XML 的小细节，很多人栽在这里。第一，正文里如果要出现 & 或 < 这类符号，需要写成实体形式，否则文件会解析失败。第二，保存时保持原来的编码，通常是 UTF-8；如果不确定，就不要在编辑器里切换编码，只改文字、按原样保存。中文乱码绝大多数时候不是程序的问题，而是保存编码变了。

接下来是“刷新”。话术库不是每次按键都实时重载的，程序通常在进入详情页、读取话术列表时加载文件。所以改完并保存后，正确顺序是：关闭当前详情页，重新进入；在搜索框里搜一个刚改过的关键词，确认新内容出现。如果没出现，再完全退出程序并重新打开；仍然没出现，就按下面的顺序排查。

现象	常见原因	处理办法
改完没生效	改的是备份文件，或程序读的是另一个安装目录	从快捷方式定位主程序，确认 Resources 就在同一目录下
打开程序后话术列表为空	XML 结构被破坏，标签没闭合或出现非法字符	用备份文件覆盖，再逐条重改，改一段保存一次
中文变成乱码	保存编码不是 UTF-8	用编辑器重新以 UTF-8 保存，不要用系统记事本的默认编码
保存时提示拒绝访问	安装目录在受保护位置，当前账户没有写权限	以管理员身份运行编辑器，或把程序迁到自己有权限的目录

刷新这件事，建议养成一个固定动作：每次改完，先搜索，再离开。搜索是最快的自检方式，比重新翻分类快得多。如果搜索不到，说明加载或保存有问题，先解决再继续写，别在错误的基础上越改越多。

三、六大分类：先判断“改什么”，再决定“怎么说”

话术库按六大分类组织，每类约 500 条，合计 3000 条。分类不是为了好看，而是为了让你在动手之前先回答一个问题：我这次要解决的，到底是界面问题、运营问题、限制问题、常规配置问题、代码质量问题，还是功能扩展问题。问题类型判断对了，后面的搜索和改写会顺很多；判断错了，就会在一堆看似相关的句子里打转。

分类	典型问题	常用关键词	验收时先看什么
界面美化	图标、名称、启动页、主题色、文案排版	图标、应用名、启动页、主题色、字体	桌面显示是否正常，遮罩下是否变形
弹窗引流	公告、更新提示、活动弹窗、分享引导	弹窗、公告、更新、活动、引导	能否关闭，是否重复弹出，文案是否准确
去除限制	自家应用的试用次数、内测白名单、功能开关	限制、次数、白名单、开关、校验	原逻辑是否保留，异常分支是否还在
常规修改	版本号、接口地址、网页地址、默认配置、文案	版本号、地址、网址、配置、文案	改动是否只在目标位置，旧值是否彻底消失
混淆去毒	自家包被二次打包后混入推广代码，或混淆后难维护	混淆、去毒、清理、二次打包、还原	多余入口是否消失，原功能是否完整
插件添加	给自家应用加入分享、更新检查、统计等模块	插件、模块、分享、更新、统计	入口是否出现，权限与隐私提示是否合规

1. 界面美化：改的是“看见的第一眼”

界面美化类话术解决的是外观问题：桌面图标、应用名称、启动页背景、主题色、按钮颜色、字体大小、首页文案排版。这类话术通常长这样：“把应用图标替换为指定图片，应用名称改为指定文字，启动页背景改为指定颜色，主题色统一调整为指定色值，其他界面保持不变。”句式看起来简单，但它把四个动作压在一句话里，直接照抄很容易只改了其中两项。

更稳妥的做法是拆开：一次只改一类。图标和应用名一起改，因为它们都在桌面入口体现；启动页单独改，因为涉及图片、背景色和显示时长；主题色单独改，因为它会牵动大量控件。每次改完都安装看一眼，比一次改十处再猜哪里出了问题要快。

这一类的验收重点在“遮罩”和“密度”。同一个图标，在圆形、方形、圆角矩形遮罩下显示效果可能完全不同；同一张图，放在不同分辨率的桌面上可能发虚。所以需求里要写清楚：使用哪个尺寸的原图、是否需要适配自适应图标、是否保留透明背景。应用名则要注意长度，太长的名字在桌面上会被截断，内测版建议控制在六到八个汉字以内。

2. 弹窗引流：改的是“什么时候说什么话”

弹窗引流类话术，覆盖公告弹窗、更新提示、活动入口、分享引导、评分邀请等。这类话术的关键不是“弹出来”，而是“什么时候弹、弹给谁、能不能关”。内置话术里有很多现成句式，比如“应用启动后弹出公告弹窗，标题为……，内容为……，提供关闭按钮，点击跳转到指定页面”。你要做的是把省略号补全，并且补上频率限制和关闭逻辑。

如果只写“加一个公告弹窗”，执行结果可能是每次启动都弹，也可能是关不掉，还可能是点击区域和关闭按钮重叠。把边界写进去，问题会少很多：每天最多弹一次、点击“稍后再说”后当天不再出现、右上角关闭按钮始终可点、内容区域超出时内部滚动。这些都属于使用体验，不是吹毛求疵。

需要提醒的是，弹窗只能用在自家应用或已获授权的应用上。不要用弹窗伪造系统提示，不要做诱导点击，也不要把关闭按钮做得很小来逼用户误触。这些做法短期可能带来一点流量，长期会伤害品牌，也可能违反平台规则。

3. 去除限制：改的是“自家应用内部的规则”

去除限制这个分类最容易被误解。它指的是去掉你自己的应用里那些为了内测、演示、临时运营而加的限制，例如试用次数、内测白名单、某功能的地域开关、某页面的临时隐藏。它不包含去掉别人的付费限制，也不包含绕过别人的授权校验。这条界线必须清清楚楚，写作和使用都一样。

这类话术通常包含条件判断的描述，比如“找到控制试用次数的逻辑，将上限调整为不限制，保留原有提示文案，其他逻辑不变”。照抄时最容易漏掉“其他逻辑不变”，结果执行范围扩大，把正常的业务判断也一起改掉了。改写时要把范围收窄：只改哪一个开关、哪一个上限、哪一个白名单列表，改完哪些提示要保留。

验收时不要只看“限制没了”，还要看“原有功能还在”。比如试用次数去掉之后，正常的登录、数据保存、页面跳转是否仍然工作；白名单放开之后，非白名单用户的提示是否仍然合理。更稳妥的做法是保留一份改动前的安装包，遇到问题可以对照。

4. 常规修改：改的是“配置和文案”

常规修改是日常使用频率最高的一类：版本号、接口地址、网页地址、默认开关、提示文案、分享标题、关于页面信息。它们的共同点是“目标明确、影响面可控”，非常适合拿来练手，也最适合沉淀成模板。比如“把版本号从旧值改为新值，其他信息不变”“把首页 WebView 加载的地址改为指定网址，其他页面不变”。

这类话术的关键是写清楚“旧值”和“新值”。只写新值，执行时可能找不到目标；只写旧值，执行时可能不知道要改成什么。最稳的写法是：在哪个位置，把哪个旧值，改成哪个新值，其他位置不要动。如果旧值在多个文件里出现，还要说明是全部替换，还是只替换某一处。比如接口地址，测试环境和正式环境可能同时存在，不能一把梭全换。

验收方法很直接：安装后进入对应页面，看显示值是否正确；如果是接口地址，触发一次请求，看日志里实际访问的是不是新地址；如果是文案，检查是否还有旧文案残留。对于网页地址，还要确认返回的页面能在应用内正常打开，不会因为跨域或证书问题白屏。

5. 混淆去毒：改的是“自家包里的多余东西”

混淆去毒包含两种场景。第一种是自家应用经过混淆后，代码可读性很差，维护和排查困难，需要做结构梳理和必要的还原；第二种是自家应用被某些渠道二次打包，混入了额外的弹窗、推广入口或后台逻辑，需要清理回干净状态。两种场景都只适用于自家拥有版权或已经获得明确授权的应用。

这类话术不能写得太笼统。“把病毒清理掉”这种描述没有可执行性，因为执行方不知道你说的“毒”具体指哪一个入口、哪一段逻辑、哪一个权限。更好的写法是：先描述现象，再给出定位线索，最后说明保留范围。例如“应用启动后会出现一个不在原设计中的推广弹窗，入口在启动流程之后；请移除该弹窗及其跳转逻辑，保留原有启动页和登录流程，其他功能不变”。

操作上建议先对比。拿官方渠道的原始包和问题包做对照，观察多了哪些页面、哪些权限、哪些网络请求。定位越具体，改写稿越短，执行越稳。清理完成后，除了看弹窗是否消失，还要跑一遍主流程：启动、登录、核心页面、退出，确认没有误删。涉及版权争议的，先保留证据并走正规渠道，不要自己动手改别人的商业应用。

6. 插件添加：改的是“给自家应用加一块能力”

插件添加类话术，适合给自家应用加入分享、更新检查、简单统计、客服入口等模块。这类需求比改文案复杂，因为它会引入新的入口、新的依赖，甚至新的权限。内置话术能提供结构，比如“在设置页新增一个入口，点击后打开指定页面，页面标题为……，返回键行为与现有页面一致”，但具体参数必须由你补齐。

改写时要多写两句“接入方式”和“失败处理”。接入方式包括：入口放在哪个页面、图标和文字是什么、点击后是打开原生页面还是网页、需不需要登录态。失败处理包括：网络不可用时提示什么、页面加载失败时是否提供重试、返回后是否回到原页面。把这些写清楚，成品才像产品，而不是一个点进去就白屏的按钮。

如果引入第三方模块，还要确认授权和隐私合规：这个模块有没有使用许可、会不会采集用户信息、需不需要在隐私政策里补充说明。不要为了一个小功能引入来路不明的依赖，更不要把别人的商业插件直接塞进自己的包里。

四、搜索与筛选：三十秒把 3000 条缩到 3 条

分类解决“大方向”，搜索解决“最后一公里”。3000 条话术里，同一个意思往往有几十种说法，靠翻页找非常低效。正确的顺序是：先选分类，再输关键词；先搜名词，再补限定词；先看三条，再决定要不要换词。这套顺序听起来普通，但能把你从“翻五分钟找不到”变成“三十秒选出三条”。

关键词怎么选？一个简单原则：搜“你要改的东西”，不要搜“你要做的动作”。“改一下”“优化一下”“弄好看点”这类词，在话术库里几乎没有区分度；“图标”“启动页”“版本号”“主题色”“接口地址”这类名词，命中率高得多。如果第一轮结果太多，再加一个限定词，比如“图标 自适应”“启动页 背景”“版本号 显示”。

你想改的东西	建议搜索词	建议分类
桌面图标	图标、应用图标、自适应图标	界面美化
应用名称	应用名、名称、桌面显示	界面美化
开屏画面	启动页、开屏、闪屏、背景	界面美化
整体配色	主题色、颜色、色值、按钮颜色	界面美化
启动公告	弹窗、公告、更新提示、频率	弹窗引流
版本号	版本号、版本、显示版本	常规修改
接口地址	接口、地址、域名、环境	常规修改
网页入口	网址、WebView、页面地址	常规修改

把流程拆成六个动作，基本就是三十秒的节奏：

1. 选分类。用上面那张表判断问题类型，点击对应分类，先把范围从 3000 条缩到 500 条。
2. 搜名词。输入你要改的对象，不要输入情绪化描述，观察结果数量。
3. 加限定。结果仍然很多时，补一个特征词，例如“背景”“自适应”“显示”“失败”。
4. 看三条。只挑三条详读，比较它们的范围和语气，不要无限往下翻。
5. 选一条。优先选“范围写得最窄、验收最好写”的那条，而不是字数最多的那条。
6. 做标记。在笔记里记下分类、关键词和条目大意，方便下次直接复现路径。

搜索不到怎么办？先排除最傻的三种情况：分类选错了、关键词写成了错别字、程序读的还是旧文件。排除之后，换同义词再试。“图标”可以换成“应用图标”，“启动页”可以换成“开屏”或“闪屏”，“版本号”可以换成“版本显示”。中文里同一个东西有多个叫法，话术库不一定用了你最常用的那一个。再不行，就切到“全部”分类，用最短的词搜，宁可多几个结果，也不要一个都没有。

五、详情、填入、复制：三个动作，三种用途

选中一条话术后，界面上通常有三个动作：看详情、填入输入框、复制文本。很多人图快，直接点“填入”再点提交，结果把一条通用句子原样发了出去。三个动作本身没有优劣，关键是知道它们各自适合什么场景。

动作	你得到什么	最适合	注意
详情	完整原文、范围和措辞	第一次遇到某类需求，先理解再动手	注意省略号和“等”字后面的隐含范围
填入	一条已放进输入框、可编辑的草稿	准备马上改写并提交	必须替换占位信息，不能原样提交
复制	纯文本，可粘贴到笔记或团队文档	整理模板库、开会讨论、跨项目复用	复制不会自动带上项目上下文，要自己补

先看详情，是为了识别“变量”。一条合格的话术里，通常藏着几处需要你替换的信息：应用名、旧值、新值、颜色值、页面名、文件路径、显示时机。详情页会把整句话展开，你能看清它到底要求改几处。如果一句话里塞了五六个动作，就要考虑拆开执行，而不是硬着头皮提交。

填入，是为了省去重复打字。点一下，句子进入输入框，你在这句话的基础上删改、补充、调顺序。填入之后的第一件事，是把所有泛化的词换成具体信息。比如“指定图片”要换成附件序号或文件名，“指定颜色”要换成具体色值，“指定页面”要换成页面名称。泛化词不替换，执行方只能猜，结果自然不稳定。

复制，是为了把经验搬到别处。当你验证一条话术好用，可以复制出来，去掉具体项目信息，改成带占位符的模板，存进自己的文档或话术库。复制也适合团队沟通：把候选话术发到群里，让大家比较哪一种范围写得最清楚，比口头描述高效得多。

提交前，用下面这份清单快速过一遍。五项都打勾，再点“立刻修改”：

• □具体信息已经替换：名称、旧值、新值、颜色、页面、文件都写明了。
• □范围已经收窄：写清了只改哪里，没有“顺便优化一下”这种模糊要求。
• □边界已经声明：包名、签名、权限、其他语言、业务逻辑，哪些不能动。
• □验收可以执行：安装后看什么、点哪里、出现什么算通过。
• □附件已经挂好：每个文件的用途都写清楚，路径没有失效。

还有一个容易忽略的点：一次提交只做一类事。图标、启动页、接口地址、弹窗，四件事写在同一段话里，执行顺序和影响面都不可控。拆成四次提交，每次都能单独验收，出问题也知道是哪一步。复杂需求不是靠一段长文解决的，而是靠清晰的步骤解决的。

六、把模板改成可执行需求：目标、范围、边界、验收

这一节是整篇教程的核心。话术库给你的是“说法”，而 AI 工作区需要的是“可执行的需求”。两者之间差的不是文采，而是结构。最稳定的结构只有四块：目标、范围、边界、验收。四块写全，一段话通常控制在八十到两百字，既不会遗漏，也不会啰嗦。

1. 目标：一句话说清“改完之后是什么样”

目标不是动作清单，而是结果描述。不要写“改一下图标和名字”，要写“桌面图标换成新版 logo，应用名显示为‘记账助手 内测版’”。前者只说了动作，后者说了完成状态。结果描述有一个好处：验收时你可以直接对照，不用猜“改到什么程度算完”。

目标要可观察。颜色、文字、图标、页面、版本号、弹窗时机，这些都是可观察的；“高级一点”“好看一点”“流畅一点”不是。如果确实想提升观感，也要落成可观察的指标，比如“主按钮颜色改为薄荷绿 #2DD4BF，文字保持白色，对比度清晰”。

2. 范围：说清“只改哪里”

范围是防止改漏和改多的关键。写范围时，先把改动对象列出来：哪个页面、哪个资源、哪个字段、哪个入口。然后再补一句“其他位置保持不变”。这两句话合起来，既告诉执行方要做什么，也告诉它不要做什么。

举个例子。换图标这件事，范围可以写成：“只改桌面图标各密度资源，使用附件 1 的图片，保留透明背景；应用名只改中文显示名；不改启动页图标，不改关于页面图标。”这样写，执行方不会顺手把启动页的 logo 也换掉，也不会去改英文语言包。

3. 边界：说清“哪些绝对不能动”

边界是很多人漏掉的一块，也是返工的主要来源。默认建议写四条：不改包名、不动签名配置、不新增权限、不改其他语言和业务页面。这四条不是每次都适用，但每次都可以先写上，再按需删减。包名一改，老用户升级会变成两个应用；签名一换，覆盖安装会失败；权限一加，应用商店审核和用户信任都会受影响。

边界还要写清“保留什么”。比如去除限制时，要保留原有的提示文案和异常分支；清理弹窗时，要保留原有的启动流程和登录流程。只写“不要什么”，执行方可能把相关逻辑一起删掉；把“要保留什么”也写上，范围才完整。

4. 验收：说清“怎么证明改对了”

验收要写成动作加结果：安装后看哪里、点什么、出现什么。好的验收标准，换一个人也能照着执行。比如换图标这件事，验收可以写：“安装后桌面名称显示正确；在圆形和方形遮罩下图标不变形、不模糊；冷启动进入首页无崩溃；设置页版本号与改前一致。”这四句分别覆盖名称、图标、稳定性、未误改，基本够用。

验收不要写“看起来正常”。正常与否取决于看的人。把它拆成可检查的点：文字是否截断、颜色是否符合色值、页面是否能返回、请求是否打到新地址、日志里是否有异常。能落到“看什么”的标准，才是标准。

写法	示例	问题
模糊写法	把界面优化一下，颜色弄好看点，图标也换换。	没有对象、没有结果、没有范围，无法验收。
合格写法	只把首页主按钮颜色改为 #2DD4BF，文字保持白色；其他页面颜色不变；安装后检查首页、设置页、详情页按钮，确认无崩溃。	对象、结果、范围、验收齐全，影响面可控。

写完之后，建议自己读一遍，做一次“反方测试”：如果有人只按这段话执行，他会不会有歧义？哪里可能被理解成另一个意思？把最容易误解的那一句改掉，通常就差不多了。比如“改成品牌色”，品牌色到底是哪一个色值？补上十六进制值，歧义立刻消失。

七、两个自家应用实例：从一句模板到可验收的成品

下面用两个自家应用的例子，把上面的方法完整走一遍。两个例子都不涉及他人的商业应用，也不涉及付费内容或安全校验，只讨论自有版权范围内的常规修改。你可以把它们当成练习模板，换成自己的应用名和参数。

实例一：自家记账 App 换图标，加“内测版”名称

以前怎么做。先用图片工具把新 logo 导出五种密度，逐个改名放进对应目录；再手动反编译，找到应用名所在的资源，改完回编；回编之后对齐、签名，用数据线装到手机；装上发现圆形遮罩下图标被裁掉一圈，又回去补边距；名称太长在桌面上被截断，再改一次。一轮下来半小时起步，改三轮就是一下午。最麻烦的是每次都要重新记命令，换台电脑又得重来。

现在怎么做。把 APK 拖进智能修改电脑版，等反编译完成，进入详情页。先选“界面美化”，搜“图标”，看三条候选，选一条范围最窄的点“填入”。然后把输入框里的内容改成下面这样：

接着在附件区选择新版 logo 图片，用途写清楚：“用于替换桌面图标，1024×1024，透明背景，四周留白约百分之八”。用途至少写十个字，这不是形式主义，而是让执行方知道这张图怎么用。点“立刻修改”后，原文和日期会记进项目的 history.ini，需求进入右侧 AI 工作区。AI 完成后，项目目录会留下完成信号，主窗口每两秒检查一次，读到就继续后面的流程；等待上限是一小时，超时会中止，不会无限挂着。

AI 改完，回到打包环节。程序会依次做四步：回编、对齐、签名、校验，全过程写进 pack.log。签名方式按项目需要选：默认签名适合内部快速验证，JKS 或 keystore 适合长期维护，PEM 加 PK8 适合已有证书链的团队，随机签名适合一次性的测试包。签名版本默认开 v1、v2、v3，需要时也可以勾选 v4。校验这一步很关键，它会明确告诉你“到底签没签上”，密钥格式不对时，只有这一步会给出清楚的结果。

怎么验证。打包完成后可以让程序自动装到手机或模拟器。程序会通过 adb 找到设备、安装、拉起启动页，再用系统状态复核前台应用是不是它。看三处：桌面名称是不是“记账助手 内测版”；图标在圆形和方形遮罩下有没有变形；冷启动能不能正常进首页。再进设置页看版本号，确认没有被顺手改掉。最后打开 pack.log，看四步是否都完成，签名校验是否通过。

这里补充一个安装失败的高频原因：手机里已经装了旧版，但新旧签名不一致。覆盖安装要求签名相同，解决方式有两种：用旧版同一套 keystore 打包；或者先备份应用数据，再卸载旧版安装新版。内部测试用默认签名没问题，但要做长期升级渠道，最好一开始就固定一套自己的签名证书，并把证书和口令保管好。

实例二：自家内部巡检工具改启动页和主题色

以前怎么做。启动页背景是一张图片加一个颜色值，主题色散落在多个资源里。每次换品牌色，都要全局搜索旧色值，逐个替换，生怕漏掉一个选中态；改完回编、签名、发到群里，同事装完反馈“按钮还是蓝的”，又得回去找漏网之鱼。启动页更麻烦，图片尺寸不对会拉伸，logo 位置不对会偏，改一次要试三四次。

现在怎么做。同样先导入 APK，进入详情页。选“界面美化”，分别搜“启动页”和“主题色”，各选一条填入，然后把两条合并成一段有边界的需求。不要分两次提交，因为这两件事都属于外观，且互相影响，一次改完更好验收。需求可以这样写：

这次不需要附件，直接在文字里写清颜色和范围即可。如果品牌方给了背景图，再把图片作为附件挂上，用途写明“启动页背景图，1080×1920，深蓝底，中央留出 logo 区域”。提交后等待 AI 完成，再打包安装。启动页的验收要冷启动，不要从后台切回来，否则看到的是缓存页面，容易误判。

怎么验证。第一步看启动页：背景色是否准确，logo 是否居中，有没有被拉伸。第二步进首页看主题色：主按钮、选中态、进度条、开关，是否都换成薄荷绿，是否还有旧蓝色残留。第三步看可读性：浅色文字配浅色按钮会看不清，必要时让按钮文字保持白色或深色。第四步走主流程：登录、列表、详情、提交，确认没有因为换色导致控件不可见。第五步看日志：pack.log 四步是否完整，apktool.log 有没有异常。

对比项	以前	现在	验证
换图标与名称	手工导图、逐密度替换、反复回编签名	搜模板、补四段式需求、挂附件、一次执行	桌面名称、遮罩效果、冷启动、版本号
启动页与主题色	全局搜色值、逐个替换、漏改后返工	两条模板合并、写明范围和边界、一次改完	冷启动画面、按钮与选中态、对比度、主流程

八、history 只留原话、附件怎么挂：把“当时怎么说的”留住

每个项目都有独立的目录，目录名是八位随机字符，里面有 source.apk、config.ini、history.ini，以及反编译工程和打包产物。history.ini 记录的是你在详情页说过的话：点“立刻修改”时，程序会把需求原文和日期写进去，最新的排在最上面，点右侧的“选择”可以把整段原文回填到输入框。这个设计看起来朴素，实际非常有用，因为它保留的是“意图”，而不是一堆中间文件。

history 只留用户原话，不保存附件内容。附件会随需求一起发给 AI 工作区，但不会写进 history.ini。原因不难理解：附件是文件，路径可能变、文件可能被移动或删除，如果历史里存的是路径，过几天再点“选择”，大概率会指向一个不存在的文件。只留原话，历史永远可读；需要附件时，重新挂一次即可。这也意味着，你写原话时要把关键信息写进文字里，不能只写“用那个图”。

因此，写需求时建议遵守一个原则：让这段话脱离上下文也能被看懂。应用叫什么、旧值是什么、新值是什么、附件是第几个、要改哪个页面，都写在句子里。比如不要写“把图标换成附件里的那个”，而要写“把桌面图标换成附件 1 的 logo，保留透明背景”。前者过一周你自己都记不清是哪个附件，后者谁看都明白。

附件本身也有一套规则。一次可以多选文件，但每个文件都要写用途，用途至少十个字；提交前程序会校验文件是否存在、是不是目录、是不是零字节、能不能读取。四项都通过，才会把“序号 + 路径 + 说明”拼进需求，随原文一起发出去。这套校验不是刁难，而是提前拦住“路径写错”“文件是空壳”“选了个文件夹”这类低级错误，避免执行到一半才发现附件不可用。

用途写法	示例	评价
过于笼统	图标	不满十个字，也说不清用在哪、什么规格
合格	用于替换桌面图标，1024×1024，透明背景，四周留白百分之八	用途、尺寸、格式、边距都说清了
容易出错	启动页图片，随便用	没说尺寸和裁切方式，容易被拉伸
合格	启动页背景图，1080×1920，深蓝底，中央留出 logo 区域	尺寸、底色、构图都明确，验收有依据

提交前的附件检查，按下面五项过一遍：

• □文件确实存在，不是快捷方式，也不是文件夹。
• □文件不是零字节，能正常打开预览。
• □每个附件的用途都超过十个字，写清了用在哪、规格是什么。
• □需求原话里提到了附件序号，不依赖记忆。
• □文件名有意义，例如“记账图标_1024_透明.png”，而不是“新建文件夹(2)”。

如果你从历史里点“选择”复用一段原话，记得做一件事：把当时用到的附件按同样的顺序重新挂上。原话里写了“附件 1”，但历史不保存附件，重新挂载后序号才对得上。这一步多花十秒，能省掉一次“附件找不到”的失败。

还有一点值得提醒：history.ini 里是完整的原话，可能包含内部地址、应用名、测试账号提示等信息。把整个项目目录打包发给别人之前，先看一眼历史记录，确认没有不适合外传的内容。项目目录本身可以整体备份，但对外分享时要有选择。

九、团队共享与版本备份：让模板库跟着项目走

当你的个人模板库积累到三五十条，价值就开始显现；当它变成团队资产，价值会再上一个台阶。但共享不是把 XML 文件扔进群里那么简单。没有命名规则，三个人会建出三个“改图标”；没有版本记录，改坏了不知道回哪一版；没有占位符约定，模板里全是某个项目的真实地址，换个人根本不能用。下面这套做法，目的是让模板库“可读、可合并、可回滚”。

先定命名规则。建议用“分类前缀 + 动作 + 版本”的格式，例如“界面-换图标-v2”“常规-改版本号-v1”“弹窗-启动公告-v1”。分类前缀和话术库的六大分类保持一致，排序和检索都方便。名字里不要写项目名，项目信息应该出现在正文的占位符里，而不是标题里。标题一旦绑定项目，复用率就会下降。

再定占位符规则。把可变信息统一写成尖括号形式，例如“把<应用名>的桌面图标替换为<图标文件>”“把版本号从<旧版本>改为<新版本>”。团队里所有人看到尖括号，就知道这里必须替换。不要用“某某”“那个”之类的模糊词，也不要留空。占位符统一，合并和审阅都会快很多。

合并的流程建议固定成五步：

1. 各自导出。每个人把自己新增或修改的条目整理成一个临时文件，不改公共主文件。
2. 去重比对。按“分类 + 标题”比对，重复的保留写法更清楚、范围更窄的那一条。
3. 合并到主文件。由一个人统一合并，保持 XML 结构完整，条目顺序按分类归位。
4. 本机验证。把主文件复制到一台机器的 Resources 目录，重开详情页，逐类搜索抽查。
5. 发布并备份。给这一版打上日期，写一条变更说明，再把上一版归档。

版本备份要像发版一样认真。最省事的做法是按日期命名，例如 话术库_20261021.xml，放在一个独立的备份目录里，保留最近三到五版。每次合并前备份一次，合并并验证后再备份一次。文件名里不要只写“最终版”“最终版2”，过两周就没人知道哪个是最终。

文件	用途	保留策略
话术库.xml	当前正在使用的文件	跟随程序目录，不直接放进共享盘编辑
话术库_日期.xml	每次合并后的归档	保留最近三到五版，按日期排序
变更说明.txt	记录日期、修改人、新增与调整条目	与归档文件放在一起，长期保留
团队模板说明.txt	命名规则、占位符约定、合并流程	随主文件一起分发，新人有据可依

共享模板库还要注意信息安全。模板是给团队复用的，不应该携带真实的内部接口地址、账号、密钥、客户名称。把这些敏感值改成占位符，例如“把接口地址从<测试地址>改为<正式地址>”，具体值在使用时由项目负责人填入。这样既保护信息，也让模板更通用。

回滚也不复杂：关掉程序，把归档文件复制回 Resources 目录并改名为“话术库.xml”，重新打开详情页，搜索一条确认版本。关键是养成“改前备份、改后验证”的节奏。只要备份在，改坏就不是事故，只是一次恢复。

团队发布前，用这张检查清单做最后一次确认：

• □所有条目都有统一的分类前缀和版本号。
• □所有可变信息都换成了尖括号占位符。
• □没有真实密钥、内部地址、客户名称等敏感信息。
• □XML 结构完整，能在本机正常加载和搜索。
• □重复条目已经合并，保留了写法更清楚的一条。
• □每个条目都能独立看懂，不依赖某个项目的上下文。
• □已经生成日期归档，并写了变更说明。
• □新同事拿到文件后，能按说明在十分钟内完成一次检索和填入。

十、用户评价与合规提醒

方法好不好用，最终要看它在真实工作里的表现。下面五位使用者来自不同岗位，他们的共同点不是技术背景，而是都在维护自家或已获授权的应用，并且都开始用模板库替代重复描述。

把 3000 条话术变成自己的模板库，本质上是一个从“找句子”到“建方法”的过程。刚开始你可能会慢一点，因为要判断分类、比较候选、补四段式；坚持十几条之后，你会发现自己写需求的速度反而更快，返工更少，交接也更轻松。模板库不是一次建完的，它跟着项目长，跟着团队长，每隔一段时间回头合并、删减、补验收，才会越来越好用。