面对一个大型编辑软件时，我最容易犯的错，是把“马上开始研究”理解成“马上下载、马上反编译、马上写代码”。看起来动作很多，进展也很具体：仓库在下载，二进制在分析，符号表在整理，脚本在增加。可过一段时间回头看，往往只得到一堆彼此没有关系的材料。
这次讨论让我重新看见了问题的另一面。目标软件并不是一个单一技术栈，它同时涉及 C++、Qt、Lynx 等多个框架。用户想找对应的开源代码，把符号和研究结果沉淀成可复用能力，还希望把下载、熟悉这类重复工作交给本地执行器。真正困难的地方，不是“有没有东西可以下载”，而是如何让这些东西最后形成一张能继续使用的地图。
复杂软件的研究起点不是代码数量，而是先知道每一块代码在整张地图上的位置。
从“想全部弄懂”退回到“先建立地图”
刚开始时，我会自然地把目标想成“把这个软件拆透”。这句话听起来有决心，实际上缺少边界。一个大型编辑软件背后可能有多个语言、多个 UI 框架、多个运行时和许多只在特定功能下才会出现的组件。若一上来就按“全部弄懂”的标准推进，研究范围会迅速膨胀，最后连第一阶段什么时候结束都说不清。
这件事表面上是逆向分析，实际上是在管理未知。先确认软件由哪些层组成，再判断哪些层直接影响当前的自动化目标，研究才有可能持续。我的第一步不会是给所有项目安排同样的优先级，而是画一张软件级框架地图：核心能力放在哪里，共享框架有哪些，暂时只需留名的部分有哪些。
如果不先分层，后面会导致两个问题。一个是研究者把时间花在暂时不影响主线的组件上，另一个是不同项目都被归到一个模糊的大名称下面，最终谁也说不清自己掌握的是哪一部分。名称越宽，能力边界反而越不清楚。
框架地图不是目录清单
一张有用的地图，不能只回答“有哪些框架”，还要回答“它们分别承担什么作用”。C++ 可能是核心逻辑和性能敏感部分的底座，Qt 可能关联桌面界面、事件和对象模型，Lynx 则可能出现在某些跨端或混合界面区域。这里不需要先断言每个组件的全部内部实现，但必须把已知、待确认和暂不处理区分开。
我会给每个框架留下几类最小信息：它在软件中的层级，是否有可参考的开源实现，当前是否已经有符号或调用证据，和主线能力的边界在哪里。这样做的价值不在于表格本身，而在于下一次遇到具体问题时，知道该回到哪一层查。
地图的作用不是假装已经理解全部，而是把已经确认的部分、仍然未知的部分和暂时不值得深挖的部分分开。
这一区分尤其重要。研究记录里写“未知”，并不等于研究失败；它说明下次遇到相关现象时，不能把猜测当成前提。相反，如果所有东西都被写成“待深入研究”，看似谨慎，实际上没有提供行动方向。地图必须能支持取舍：哪些内容今天就要确认，哪些可以等主线出现需求再研究。
符号索引把材料变成入口
仅有框架地图还不够。大型二进制最容易制造一种错觉：文件很大，符号很多，研究就一定很深入。实际上，如果符号、版本和来源没有被索引，下一次仍然只能从头搜索。
所以我会把符号索引当成地图的第二层。每个项目至少记录来源、版本、符号状态，以及它和其他层的调用边界。来源回答“这份材料从哪里来”，版本回答“它能不能和当前目标对应”，符号状态回答“现在能看到什么程度”，调用边界回答“它能不能支持实际判断”。
这里最容易误判的是，把“下载完成”当成“研究资产完成”。一个开源仓库可以下载成功，但版本对不上；一份二进制可以被打开，但符号残缺；一个函数名可以被搜到，但还没有证据证明它属于目标路径。若不记录这些状态，后面很容易把线索当结论，把一次成功的检索当成长期能力。
我更愿意把索引写成一种研究账本，而不是收藏夹。收藏夹只保存“我见过什么”，账本还要保存“我为什么相信它有用，以及下一步能用它验证什么”。这会让研究从材料堆积变成可回溯的判断链。
分层命名，防止能力互相覆盖
讨论中有一个很现实的担心：如果多个框架、多个项目最后都被叫作同一个软件技能，调用时就会发生名称冲突。表面看只是命名问题，实际上它会影响能力发现、边界控制和后续维护。
我会按层命名，而不是按“所有相关东西”设一个总名。软件级地图是总入口，核心能力是第一层，共享框架是第二层，按需研究的组件是第三层。每个子项目还要能独立说明自己的来源、版本、符号状态和适用范围。这样，当用户问一个具体问题时，系统先从总地图定位，再进入对应层，而不是把所有结果混在一起。
好的命名不是让人记住更多名称，而是让每个名称都对应一个稳定的能力边界。
这也解释了为什么我不赞成一开始创建一个“万能逆向技能”。万能入口看起来方便，实际会把不同证据等级、不同研究深度和不同维护周期揉成一团。今天为了查一个界面问题加入一份材料，明天为了查一个底层调用再加入另一份材料，最后入口越来越大，任何一次更新都可能影响不相关的使用者。
重活交给执行器，判断留在审核层
下载仓库、整理文件、生成初步索引、重复核对版本，这些工作可以交给本地执行器。用户也明确提出，希望把下载和熟悉工作交给执行器，这个方向是合理的，因为它能减少人工在重复动作上的消耗。
但执行器负责“做得快”，不等于它负责“判断什么值得保留”。它可以按规则下载多个来源，检查文件是否完整，汇总初始符号信息；审核线程则要决定哪些内容进入核心资产，哪些只保留为线索，哪些因为价值不足暂不处理。两者混在一起，就会出现一种危险：执行器下载了什么，研究范围就被动变成什么。
我选择把两者分开，是因为研究资产的成本不只在存储，还在维护。一个暂时用不到的巨型二进制，可能占用空间、增加索引时间，却没有改变当前判断。如果不设优先级，所有“以后可能有用”的材料都会挤进主线，真正重要的东西反而更难找到。
错误捷径是把所有二进制和开源仓库一次性全量下载，再期待以后慢慢整理。这个捷径的问题不在于下载本身，而在于它把取舍推迟了。等材料堆起来，整理成本会比一开始建立地图更高，而且人会倾向于为已经下载的东西寻找用途，形成沉没成本。
先处理能改变主线的框架
地图完成后，优先级不能只按“谁最底层”排序。更可行的判断方式是看某个框架是否直接影响当前核心能力，是否有足够公开资料，是否已经出现可验证的符号或调用线索，以及研究它的成本是否可控。
核心能力优先进入稳定资产；共享框架在多个能力都依赖它时优先；尚未建图的中型框架，则按需求和证据逐步收编。这里的“收编”不是把它们全部升级为正式能力，而是先补齐地图位置和最小索引，等真实任务证明它值得深入时再增加研究深度。
如果一个框架暂时没有公开代码、符号也很少，且当前任务不依赖它，我会把它标成待观察，而不是为了地图完整强行补齐。完整不是把每个空格都填满，而是知道哪些空格存在，为什么现在不填，以及什么信号出现后需要回来填。
这件事让我重新意识到，逆向研究的长期价值来自可重复的判断。一次性找到一个函数，可能解决今天的问题；知道它属于哪一层、来自哪个版本、和哪些边界相连，才会减少下一次的搜索成本。
下次我会怎么做
下次面对类似的大型软件，我会先做一张软件级框架地图，再进入具体代码。第一遍只确认层级和边界：核心能力、共享框架、按需研究分别放在哪里。第二遍建立符号索引，为每个项目留下来源、版本、符号状态和调用边界。第三遍才按当前目标决定研究深度。
执行器会负责重复下载、初步整理和机械核对；审核层负责优先级、命名和收口。遇到巨型二进制，我先问它是否能改变当前判断，而不是先问能不能下载。遇到名称冲突，我先拆能力边界，而不是给总入口继续加内容。
一个流程成熟的标志，不是它能把所有材料收进来，而是下一次面对新问题时，能迅速知道从哪一层开始、哪些证据可信、哪些工作可以暂缓。真正要沉淀的不是一堆代码和仓库，而是一张能让研究继续向前的地图。