找到要改的那一处：搜文案、搜资源名、搜包名类名

一、改包的一半时间在找

回想一下你经历过的改包任务，时间都花在哪儿了。真正「改」的那个动作——替换一张图、改一句文案、调一个值——往往只要几秒钟；而前后围着它转的，全是「找」：找目标文件在哪、找同类的地方还有几处、找改完之后去哪验证。找得顺的任务半小时收工，找得拧巴的任务一下午耗在一个文件上。换句话说，改包的效率瓶颈不在改，在找。

「找」这件事没有门槛，但有章法。没有章法的人靠缘分：打开一个像的文件夹，凭感觉翻，翻到是运气，翻不到是命运。有章法的人靠路径：先判断要找的东西属于哪一类（文字、图片、还是代码入口），再用对应的搜索策略直奔目标。这一篇讲的「三板斧」，就是把这套章法显性化——三招，覆盖改包场景里九成的查找任务。

先说结论再展开：第一斧，搜文案——你要找一句显示的文字，就搜这句话的原文；第二斧，搜资源名——你要找图片等资源，就搜资源的命名关键词；第三斧，搜包名类名——你要找代码入口或某段逻辑，就搜包名和类名。三斧各有各的适用场景和读结果的学问，一斧一斧来。

二、第一斧：搜文案——跟着那句话走

第一斧是使用频率最高的一招。场景：界面上有一句「立即体验」，你要把它改成「马上开始」。绝大多数人面对这种任务会先猜文件——「文案应该在某个字符串文件里吧」——然后开始盲翻。正确姿势：直接搜「立即体验」这四个字的原文。命中处会告诉你它住在哪个文件、第几行——八九不离十就是字符串资源文件里的一个条目。改那一处，回编装机，完事。

搜文案的威力在于「零猜测成本」：你不需要懂结构、不需要知道文件叫什么，你手里本来就握着最精准的钥匙——那句话本身。这也解释了为什么改文案类需求是新手最容易上手的改包任务：输入（原文）和目标（新文）都是现成的，中间只隔一次搜索。把这个认知推广开：以后看到界面上任何想改的字，第一反应不是「这在哪定义的」，而是「搜它」。

读搜索结果也有讲究。命中一处，直接改，皆大欢喜。命中多处——比如「立即体验」出现了三次——先别急着全改：打开每一处看上下文，确认哪处是你要改的那个场景（首页按钮和设置页的提示可能用了同一句话），确认后只改目标，或按需求决定是否统一改。零命中怎么办？这是最值得展开的情况，下一节专门讲。

三、搜不到的三种情况与对策

搜原文零命中，先别怀疑工具，按三种情况排查。情况一：字没搜全。界面上看到的可能是一句话的截断，或者实际存储的文案带着前后缀——搜的时候换更短、更独特的片段再试。比如搜「立即体验」没中，试试只搜「体验」或「立即」。片段越短，命中率越高；但也越容易命中过多——所以选「独特片段」是门小手艺：避开常见词，选这句话里最特别的那几个字。

情况二：字不在资源层。有些应用的文案不在标准字符串文件里，而是写死在代码里、或来自服务端下发的数据、或内嵌的网页。这种情况搜索结果会告诉你一个重要事实：这句话在本地资源里不存在。对策：文案在代码层的，交给 AI 版处理（需求写清原句和新句，让它去代码层找）；来自服务端的，本地改包本来也管不着，需要从源头改。情况三：资源被混淆改名。经过混淆处理的包，字符串文件可能被改名或重组，原文搜索有时会失灵——这种包的查找要靠资源标识反查，属于进阶话题，遇到时最稳妥的路是把查找任务连同上下文一起交给 AI。

三种情况排完，你手里有了一份「查找失败诊断表」：换片段再搜（字没搜全）、转 AI 或改源头（不在资源层）、转进阶方法（被混淆）。这份诊断表的价值在于——搜不到不再等于死胡同，每种失败都有明确的下一步。查找的从容，不是来自每次都搜得到，而是来自搜不到时也知道路在哪。

四、第二斧：搜资源名——图片们的门牌号

第二斧管资源，最常见的是图片。场景：要换应用的图标或启动图。资源文件（图片）没有「文字内容」可以搜，但它们有名字——而且这些名字相当有规律：图标相关的常叫 icon 或 launcher，启动图常叫 splash，背景图常叫 bg 或 background，引导页常叫 guide。搜这些关键词，资源目录里的相关文件就成片浮出来了。

搜资源名的结果有个特点：命中常常是「一组」而不是「一个」——同一个名字在不同密度目录里各有一份（为不同清晰度的屏幕准备的）。这不是麻烦，是设计：换图时的正确操作就是同名全换，让每个屏幕密度都拿到新图。只在某一个密度目录里换了一张，装在高分屏手机上就还是旧图——这是「换了图标怎么没变」这类经典疑问的高发原因，上一篇盘点的身份项里专门记图标形态，就是为了这一刻。

资源名搜索的进阶用法是「顺藤摸瓜」：找到目标图片的名字后，再拿这个名字搜一遍引用——哪些文件提到了它，布局怎么用它、代码在哪调它。这一搜就把「一张图」升级成了「一条引用链」，改起来心里有全局。链条信息也是写需求的好材料：「把所有密度的 splash 系列图换成附件素材」——AI 拿到这样的需求，几乎不可能改错。

五、第三斧：搜包名类名——代码世界的坐标

第三斧面向代码层，关键词是包名和类名。场景：要定位启动逻辑、找到某个功能的入口、确认应用的主结构。包名是全局唯一的——搜包名能快速圈定「哪些文件属于这个应用自己的代码」（第三方库的文件在别的包名下，一眼可分）；类名则像街道门牌——启动页的类名在清单文件里写得明明白白，搜它就知道启动逻辑住在哪。

第三斧的典型用法有三个。用法一，定位入口：清单文件里写着应用从哪个类启动，搜这个类名，代码层的位置立现。用法二，区分自家与三方：搜包名前缀，自家的代码全在这一片，第三方的在另一片——改动时只动自家这一片，是对第三方逻辑最起码的尊重。用法三，交叉验证：反编译出的代码文件名和清单、资源引用相互印证，确认你找的类确实在用、没找错同名的东西。

第三斧是三板斧里最「代码味」的一招，但别被吓住——它要求的不是读懂代码，只是把包名类名当坐标用。就像在城市里找路不需要会盖楼：知道「这条路叫什么、通到哪」就够了。改包场景里九成的代码层定位，需要的都只是坐标级的查找，不是理解级的阅读。

六、三斧连招：真实任务的组合用法

真实的查找任务往往是三斧连用。举一个完整的例子：任务是把某自家应用的会员页横幅图换成新的，顺便把横幅上的口号改了。第一斧先动：搜横幅上的口号原文——命中，拿到字符串条目，顺带看到这个条目的名字（比如叫 banner_title）。第二斧跟上：横幅图不一定叫 banner，但刚才那个条目名给了线索——搜 banner，图片资源成片出来，对照尺寸和位置挑出目标组。第三斧验证：搜这个图的名字看引用，确认它确实用在会员页的布局里。三斧下来，改动的施工坐标全部锁定：文案一条、图片一组、引用无误。

这个例子展示了查找的真正心法：三类信息互相指路。文案的名字指向资源，资源的引用指向布局，布局的位置印证文案——整个包的信息是一张网，搜索就是沿着网走的动作。新手把搜索当「工具功能」，老手把搜索当「导航思维」：每次命中都不只回答了「在哪」，还常常送出「下一站去哪」的线索。

连招的顺序也有讲究：从最确定的信息下手。手里握着原文就先搜文案，握着图的名字就先搜资源名，知道类名就直接搜类名。三斧没有固定先后，原则只有一条——用你最有把握的钥匙开第一道门，剩下的门会越开越顺。

七、搜到之后：确认再动手

找到目标文件不等于可以动手了——动手前还有三十秒的「上下文确认」。以改文案为例：打开命中的条目，看两样东西。一看上下文：这个条目前后的条目是不是同一页面的（字符串文件里相邻的条目通常来自同一界面）——如果命中处的邻居都是会员页的文案，那这条八成就是你要的。二看名字：条目的标识名往往带着语义（比如 member_banner_title），名字和目标对得上，把握又添三分。

改资源的确认更直接：打开图片看一眼——是不是你界面上看到的那个横幅，图片自己会说话。尺寸也是个确认维度：横幅图是宽的，图标是方的，尺寸不对说明找错了文件。确认这个环节看似多余，实际上是最划算的保险——三十秒确认挡住的错改，每一单都价值一轮返工。

确认还应该包括「改完之后怎么验」的预案。改文案的，记下这个条目名，改完装机后直接去对应界面看那句新话；换图的，记下这组图的名字和密度档数，装完在目标机型上核对。把验证点在动手前就写下来——这是把「改完随手一验」升级成「改完定点核验」的小纪律，也是整个改包流程里性价比名列前茅的一个。

八、查找结果喂给 AI：人机分工的最优解

三板斧的成果有个重要去处：写进给 AI 的需求。对比两种需求写法。普通版：「把会员页横幅的图和字换掉」。喂料版：「会员页横幅图是 banner 系列资源、共五档密度，换成附件素材；横幅口号在字符串文件里、条目名叫 banner_title，原文是 XX，改成 YY」。AI 执行后者的准确率是碾压级的——它不用再猜「横幅是哪个资源」「口号是哪条字符串」，施工坐标你都替它标好了。

这就是「经典版查找 + AI 版施工」的完整分工：人做导航，AI 做驾驶。查找是信息密集型任务，人拿着三斧搜出来的坐标质量最高；修改是操作密集型任务，AI 执行得又快又稳。很多团队抱怨「AI 改包总是改不到位」，症结多半不在 AI 的能力，而在需求里没有坐标——导航都没做好，再好的司机也只能绕圈。

给这个组合起个名字：「带坐标的需求」。从今天起养成习惯——每次在经典版里搜到目标，顺手把「文件位置、条目名、密度档数」抄进需求草稿。这个动作十秒钟，但它把 AI 从「猜测模式」切到「执行模式」，一轮顶过去三轮。

九、实战例一：三分钟定位一句文案

来两个实战。例一：自家工具应用设置页里有句「清理缓存将删除临时文件」，产品要求改成更友好的说法。定位过程：第一斧，搜「清理缓存」——命中两处；打开看上下文，一处是设置页的说明文案（就是目标），另一处是弹窗里的提示（暂时不动）。确认目标条目名，抄下新文案。前后三分钟，施工坐标齐了：如果自己动手，直接在经典版里改那一处；如果交给 AI 版，把条目名和原句新句写进需求，一句话的事。

这个例子还演示了「多处命中怎么挑」的标准动作：逐处看上下文，按场景对号。别嫌这一步啰嗦——命中两处就全改的偷懒做法，改对了是运气，改错了就是把弹窗文案也悄悄换掉，两周后有人发现弹窗「话不对题」，又是一轮排查。

十、实战例二：换一组启动图的全流程

例二：公司周年庆，自家应用的启动图要换成庆典版。定位过程：第二斧，搜 splash——命中一组五档密度的启动图，打开最大的一档确认就是当前启动画面。顺藤摸瓜，拿图片名再搜引用，确认布局里引用的就是这组。顺手第三斧：从清单文件确认启动入口类名，为的是万一「换图后启动页尺寸不对」能快速找到布局调整的位置。定位完成，产出一份完整坐标：五档图名、引用位置、入口类名。接下来的活分两种：自己动手——五张新图按原名覆盖，回编打包；交给 AI——需求写「splash 系列五档全换，附件是最高清版素材，其余密度由它缩放」。两条路都通，坐标已经把路铺平了。

两个例子合看，查找三板斧的产出始终是同一种东西：施工坐标——文件在哪、叫什么、有几处、引用谁。坐标在手，无论接下来是手动改还是 AI 改，都是快而准的执行问题。这就是「找」对「改」的全部意义。

十一、问答四连

问一：搜索大小写敏感吗？资源名和代码类名的搜索通常区分大小写——搜 icon 和搜 Icon 可能是两种结果。拿不准时两种都试，或者用更短的关键词。这也是选关键词的小窍门：越短越不容易踩大小写的坑。

问二：中文文案搜不到，是不是编码问题？多数情况不是——反编译产物里的中文通常是正常可搜的。搜不到优先按第三节的「三种情况」排查：换片段、判断是否在资源层、留意混淆。都排除了再考虑编码类疑难，那种情况交给 AI 或求助更高效。

问三：有没有搜出来几百条结果的时候？有，说明关键词太大众（比如搜 bg 会命中所有背景图）。两个办法：加限定词再搜（bg_login 比 bg 精确得多），或者按文件分组浏览结果——先看命中在哪些文件，再挑文件细看。搜索词的精度，就是查找的速度。

问四：这些查找经验能迁移到 AI 版吗？能且应该。AI 版的「浏览项目文件」同样是一棵树，你搜出来的坐标（文件、条目、密度档）在两个版本里通用。经典版练出的查找直觉，到 AI 版里就是写出精准需求的能力——基本功永远是跨版本的。

十四、关键词的兵法：选词即选速

三板斧的效率，一半取决于斧头，一半取决于你怎么握——关键词的选择就是握法。给四条选词兵法。第一条，独特优先：选目标里最「与众不同」的片段。搜「确定」会命中几十条，搜「立即体验」可能只有一条——同样一次搜索，词选对了就是一次定位，选错了就是一次考古。

第二条，宁短勿错：拿不准原文的完整写法时，用短片段试水。界面上显示的文案可能被截断、可能带省略号、可能前后还有别的字——搜你百分之百确定的那几个字，比赌整句靠谱。第三条，组合收窄：资源搜索命中过多时，用「场景词＋类型词」组合——bg_login、icon_member，两个词一叠，结果立刻从一片变成一点。第四条，换位命名：找资源名时想一下「如果我是当初的开发，我会给这文件起什么名」——启动相关的会带 splash 或 launch，引导会带 guide，会员会带 vip 或 member。开发圈的命名习惯高度趋同，顺着这个习惯搜，常常一击即中。

四条兵法背后是一个统一的道理：搜索词是你对目标的描述，描述越准，搜索越像导航。花十秒钟斟酌一下用词，比搜完五百条结果再逐条看快十倍——选词的十秒，是整个查找动作里回报率最高的十秒。

十五、命中列表的阅读姿势

关键词选好了，命中结果怎么读也有讲究。结果少（一两条）直接看，无需技巧；结果多时，用「三步分层读」。第一步，按文件分组扫一眼：命中集中在哪几个文件？字符串类的命中如果集中在一个字符串文件里，说明文案管理规范，目标大概率就在其中；散在十几个文件里，说明文案散落，要有耐心逐个看。

第二步，按名字语义排序挑重点：命中条目的名字本身是筛选器——名字和你的目标场景对得上的先看。找会员页的文案，命中里名字带 member 的优先；找登录按钮，名字带 login 的优先。名字语义这一步，常常能把几十条命中直接砍到三五条。第三步，按上下文确认：剩下的候选逐个打开，看前后文对不对得上——第七节讲的确认动作就落在这一步。

三步分层读的本质是「先粗后细」：文件层粗筛、名字层中筛、上下文层精筛。每一层都在缩小范围，到最后打开看的往往就只剩一两处。养成这个阅读姿势的人，面对几百条命中也不会皱眉——因为他知道真正需要细看的，从始至终就那么几条。

十六、一周成手：查找的速度训练

查找是可以练的，而且见效极快。给一份一周训练计划，每天十分钟。第一天，练第一斧：找一个包，挑十句界面文案逐个搜原文，体会「独特片段」的选法，记录平均几秒命中。第二天，练搜不到：故意搜一些界面上不存在的话（比如别的应用的文案），观察零命中的样子，练习换片段再试的反射。

第三天，练第二斧：搜 icon、splash、bg、guide 四个词，观察各命中多少、分布在哪些密度目录，任选一组图看清「同名多档」的结构。第四天，练第三斧：打开清单文件找到启动类的名字，搜它；再搜包名，看自家代码和第三方代码的分野长什么样。第五天，练连招：挑一个真实小任务（一句文案加一张图），走一遍第六节的三斧连招，产出完整施工坐标。

第六天，练喂料：把前一天的坐标写成一份「带坐标的需求」，交给 AI 版执行，观察一次改对的体验。第七天，复习加总结：把这一周的体会写三行——哪斧最顺、哪斧最生、明天先用哪斧。一周之后，你会发现自己看包的眼神都变了——那是一种「万物皆可搜」的笃定。查找的功夫，就像打字的盲打：练之前是技能，练之后是本能。

十七、混淆包进阶：当门牌被摘掉之后

三板斧在标准包上畅通无阻，但有一种包会给你制造麻烦：混淆过的包。混淆做的事，通俗讲就是「摘门牌」——类名从有语义的名字变成单字母，资源名从 banner 变成一串代号。门牌一摘，第二斧和第三斧的效力大打折扣：你搜 banner，它早就不叫 banner 了；你搜类名，满眼都是 a、b、c。

对付混淆包，思路要换：从「搜名字」切换到「追关系」。资源有稳定的内部编号，代码有稳定的调用关系——名字可以改，关系改不掉。实践中更省力的路径是把定位任务交给 AI：混淆包里「找到某个界面对应的代码」这种活，AI 拿着语义线索去追，比人眼在一堆单字母文件里翻快得多。你的角色退回到「提供线索」：描述目标界面的样子、它上面的文案、它的行为——线索够足，AI 的定位就够准。

还要给混淆包一个实事求是的定位：混淆是一种态度，它说明包的主人不欢迎修改。对自家混淆过的包（比如自家正式包做了混淆处理），改起来天经地义、方法如上；对他人 heavily 混淆的商业包，任何深挖都应止步于合规边界——这不只是法律问题，也是这份工具一贯的立场。

十八、查找与安全网：动手前的最后检查

定位完成、即将动手之际，还有一道和查找直接相关的保险：备份确认。经典版的反编译产物来自原包，而原包在你建项目时就完好地备份在项目里——它是你所有大胆查找和修改的退路。动手前花十秒确认两件事：其一，原包备份还在项目目录里（它名字就叫 source.apk，翻一眼即可）；其二，你改的是反编译产物里的文件，不是别的什么。

这道检查防的是一类低级但后果惨重的事故：没有退路的修改。改坏了不可怕——有原包，大不了重新反编译一遍，损失几分钟；没有原包的改坏才是灾难。工具已经把退路焊死在流程里（每次建项目必然备份原包），你的任务只是「知道它在、别去动它」。

再送一条与查找配套的好习惯：改任何文件之前，先看一眼它的「邻居」——同一目录下的其他文件。这一眼有两个作用：确认自己确实在对的目录里（邻居都眼熟说明没走错），并且对这一片的「氛围」有个印象（万一改出问题回滚，你知道这一片原来大概什么样）。查找带你到门口，这一眼帮你进对门。

十九、实战例三：排查「改了没生效」

第三个实战例子换个方向——查找不只服务「改」，也服务「排查」。场景：AI 把开屏广告去掉了，装机后开屏广告还在。这时候三板斧变身「排查三问」。第一斧问文案：把广告页上的一句文案搜出来，看它住在哪个文件——文件存在，说明广告的资源还在包里；顺藤摸瓜找到引用它的布局和逻辑。

第二斧问资源：广告的图片资源搜出来，确认资源在不在、被谁引用。第三斧问类名：找到启动入口的类名，看启动流程里是否还挂着广告页的跳转。三问下来，答案通常落在三种之一：资源在、逻辑也在（AI 根本没删对地方）；资源删了、逻辑还在（逻辑还在等一个不存在的页面）；都在别的层（比如广告来自服务端，本地删了也会再拉回来）。三种答案对应三种下一步——让 AI 重删并附上你搜到的坐标、让 AI 清理逻辑、或者承认这是服务端的事本地管不着。

这个例子的价值在于展示：查找三板斧是双向的——改之前用它定位目标，改之后用它定位问题。「搜得到的放心、搜不到的警惕」，这句话可以当排查工作的座右铭。

二十、问答再四连

问五：搜索结果里的路径都好长，怎么快速看懂？路径是「邮编+地址」：前半段是目录结构（住在哪个区），最后一段才是文件名（门牌号）。快速读法：先只看最后一段判断是不是目标，是目标再回头看路径确认在哪个区。别从第一个字符开始逐字读——那是给邮递员的方式，不是给收件人的。

问六：同一个词反复搜是不是效率低？恰恰相反。改包老手的工作流里，同一个关键词搜两三遍很正常——第一遍定位、改完后再搜一遍确认改动落地、装机验证后还可能搜一遍对照。搜索便宜，肉眼验证贵，用便宜的搜索代替昂贵的翻找，正是效率所在。

问七：查找能发现隐藏功能或彩蛋吗？技术上可能——字符串里常常躺着未启用的文案。但请注意边界：对自家包，翻出未上线的功能文案是正常的项目工作；对他人的包，这类探索应当止步于好奇心，不做修改和传播。好奇心没有错，边界感是成熟的代价。

问八：三板斧要练多久算过关？一个简单的自测：拿到一句要改的文案，你能在两分钟内给出「文件、条目名、是否多处命中」三项答案，第一斧过关；换图任务五分钟内报出资源组名和密度档数，第二斧过关；能从清单文件读出启动类并搜到代码位置，第三斧过关。三项全过，你的查找功力已经超过绝大多数改包者。

二十一、第四斧的雏形：让 AI 替你搜

诚实的展望：三板斧之外，「第四斧」正在成型——直接把定位需求交给 AI。「帮我找到会员页横幅图是哪个资源、那句话在哪条字符串」，AI 能给出答案，而且往往还附带你没问到的引用关系。它不完美（答案需要抽查验证），但在混淆包、巨型包这类人眼吃力的场景里，已经是可靠的战友。

那三板斧会被第四斧取代吗？短期内不会，原因有三。第一，验证 AI 定位结果，靠的还是你自己的三斧——抽查本身就是搜索。第二，高频小查找（改一句话）里，自己搜十秒，写描述给 AI 反而三十秒。第三，也是最根本的：查找的过程在给你积累结构直觉，全托出去，手感永远长在别人身上。所以现实的格局是四斧并存——小事自己搜，难事一起搜，搜完必抽查。工具越聪明，人的基本功越显得值钱。

二十二、收藏卡片：本篇带走三样

第一样，三斧口诀：找字搜原文、找图搜名字、找码搜包名类名——九个字，覆盖九成查找。第二样，选词四法：独特优先、宁短勿错、组合收窄、换位命名。第三样，带坐标的需求：把搜到的文件、条目名、密度档抄进需求，AI 从猜测模式切换到执行模式。

本周行动：拿一篇界面上你早就想改的自家应用文案，用第一斧走一遍完整流程——搜原文、读命中、确认上下文、写下坐标。五分钟的实操，胜过这篇万字的一半。查找这件事，读十遍不如走一遍。

新手上路十篇至此收官。下一批文章我们换到「反编译研究」栏目，聊更进阶也更好玩的话题：循环发布的文件名引擎、把包变成教学工程、手机里的小 Linux……。路已经铺好，咱们换个栏目继续走。

二十三、多语言包里的搜索变数

三板斧讲的是标准战场，但有一类项目会给查找加点料：带多语言资源的应用。这类应用的反编译树里，字符串不只有一个家——res 目录下会出现一排长得像兄弟的目录：默认的 values 之外，还有带语言后缀的 values 目录，比如面向中文的、面向英文的，各存一份文案。同一句「立即体验」，可能在几个目录里各躺一条。

这带来两个变化。第一，搜出来的命中会翻倍——你在界面上看到的是中文，但同名条目在其他语言目录里还有亲戚。第二，改一处不等于改全部——只改了默认目录的那条，切换到其他语言的设备上，老文案可能还在岗。多语言包的修改纪律是：定位一次，把同名条目的所有语言版本都记进坐标，改的时候一起处理。

查找层面的应对办法很朴素：搜到目标后，看一眼命中所在目录的名字。命中落在默认目录，留意有没有带后缀的兄弟目录也要同步；命中本来就散在多个语言目录，更要列全清单再动手。多语言不是查找的障碍，只是提醒你——坐标要记完整，别只记了半张地图。

二十四、多档资源里的搜索纪律

比多语言更常见的变数，是第九节提过的多密度档位，这里把它放到查找的视角再讲透。同一张图标、同一张启动图，在 res 的 drawable 与 mipmap 目录里往往不是一张，而是一组——不同屏幕密度各一份，名字相同、目录不同。搜索资源名时，命中的常常是「一组」而不是「一个」。

这时候坐标怎么记？答案是按组记，不按张记：条目名写一次，后面标注档位数和所在目录。比如换图标，坐标就该是「这个名字共命中五处，分列于五个密度目录」。改的时候整组同名覆盖，缺一档就可能出现「有的手机上换了、有的手机上没换」的经典怪象。

这条纪律同样适用于交给 AI 的需求：与其说「把启动图换掉」，不如把整组坐标贴进去——名字、档位数、密度目录。AI 拿到的信息越完整，一次过的概率越高。多档资源是查找三板斧最容易漏记的地方，也是最值得多花三十秒核对的地方。

二十五、什么时候不搜：把描述交给 AI

讲了这么多「怎么搜」，最后说说什么时候不用搜。查找三板斧的适用场景是：目标明确、关键词好取、你自己能确认。但有几种情况，硬搜不如换个打法。第一种，目标说不清关键词——「那个转圈的动画太快了」这种描述，你很难从界面上抠出可搜的文案或资源名，与其大海捞针，不如把整段描述交给 AI 版，让它顺着项目结构去定位。AI 版的长处正是理解这种自然语言式的目标。

第二种，改动横跨多个文件——比如「把整套会员界面的配色换成绿色」，涉及布局、颜色定义、图标一大串。逐个搜、逐个记坐标，人工成本高得离谱。这类批量改动写清需求交给 AI，效率高一个量级；经典版练出的结构直觉，在这里变成你写需求的底气——你知道它大概会动哪几类文件，验收时心里有数。

第三种，搜索屡屡碰壁——换片段、辨层级、防混淆三条路都试过还是找不到，说明目标藏在你看不见的地方（比如代码动态生成、或被拆得很碎）。这时候别跟搜索较劲，把「我搜了什么、结果如何」原样告诉 AI，往往它一眼就能指出盲区。会用工具的更高境界，是知道什么时候换工具。

二十六、把查找结果记下来：项目查找笔记

三板斧挥得多了，你会发现同一类应用的长相高度相似：登录相关的东西总在那几个位置，启动图总叫那几个名字，会员文案总带那几个词。这些经验如果不记，每次都从零开始挥斧；记下来，就是你的查找笔记。

笔记不用复杂，三条字段就够：应用类型、目标、坐标。比如「电商类 App —— 首页弹窗文案 —— 命中于字符串文件，条目名带 home_dialog」。下次接到同类型项目，先翻笔记再开工，别人在搜「确定」，你直接搜上一次记下的条目名模式。

笔记对团队的价值更大。把个人的查找笔记汇总成一张项目查找地图，新人上手时先读地图再碰项目，等于把老手几周攒下的定位直觉一次性继承。改包这件事，个人靠手感，团队靠沉淀——三板斧是手感，笔记是沉淀。

笔记还有一层隐藏价值：它是给 AI 的需求素材库。翻翻你的历史笔记，会发现很多需求的写法是可以复用的——「把某某类条目整组替换」的句式、「按密度档全量覆盖」的叮嘱、「混淆包先报映射再动手」的提醒，这些从实战里长出来的措辞，比凭空想的描述精确得多。写需求时直接从笔记里搬，改一次成的概率自然往上走。

写到这里，三板斧的故事才算完整：挥斧找坐标是手上功夫，记笔记攒地图是脑中积累，把坐标写进需求交给 AI 是人与工具的接力。三件事连起来，就是一个改包新手成长为熟手的完整路径——从这一篇开始，把你的第一页查找笔记写起来吧——坐标在手，改包不愁，经验越攒越厚。

二十七、用户怎么说

反馈里被引用最多的是「搜原文别猜文件」这一句——最简单的道理，最常被违反。查找三板斧的全部精髓，说到底就是把「猜」字从工作流里赶出去：猜文件、猜位置、猜改动点，每猜一次都在给返工充值。

二十八、写在最后

搜文案、搜资源名、搜包名类名——三板斧没有一招高深，但合起来就是改包世界里最实用的导航系统。新手上路栏目写到这一篇就满了，回头看这十篇：从需求写法到打包链路，从签名到设备，从盘点到查找——它们共同拼出了一张「改包基本功」的地图。地图在手，剩下的路，靠一次次实走去熟悉。

安卓修改大师智改工坊家族还有两位成员：智能修改电脑版跑在 Windows 桌面上，一句话改包、自动打包；智能修改安卓版装在手机和平板上，走到哪儿改到哪儿。产品介绍页：https://www.apkeditor.cn/ai-version.aspx。只需说话，就能让应用变成你想要的样子。