我原本只想复制一份目录
这次的起点很简单：我想把一套已经在使用的自动化技能同步到外置存储里。以后换一台电脑，或者把其中一部分交给其他人使用，不必重新从头整理。最直接的做法，就是把技能目录整体复制过去。
这个念头看起来没有什么问题。目录里既然都是围绕技能留下的文件，那就一起带走，到了新环境再慢慢处理。可是当我进一步想到“给其他用户用”这件事，直觉就开始不可靠了。当前机器上的素材、缓存、测试记录和开发文件，可能确实帮助过我，却不一定是别人运行这个技能所必需的东西。
复制得完整，不等于交付得完整；一个包真正的完整，是拿到它的人能知道该从哪里开始，并且能够跑通核心动作。
这件事让我停下来重新看待“同步”。它表面上是搬运文件，实际上是在定义一套能力的边界：哪些东西属于技能本身，哪些只是我这台机器为了开发和试错留下的痕迹。
目录越全，边界越容易消失
一个长期使用的技能目录，往往会自然长出很多层内容。最里面可能有真正的入口文件和运行逻辑，旁边是说明文档、示例、测试样本，再往外还有临时素材、生成结果、缓存和本机配置。它们都曾经出现在工作过程中，于是很容易被一视同仁地称为“技能文件”。
但“曾经用过”和“交付时必须存在”是两种不同的判断。某个素材可能只是为了演示一次效果，某份缓存可能只是为了节省本机下一次等待时间，开发文件则可能服务于修改技能的人，而不是使用技能的人。如果把这些内容原样打包，接收者拿到的不是一个清楚的工具，而是一段没有整理过的工作现场。
如果不处理这个边界，后面会出现的问题不只是包变大。别人可能误以为某份素材是运行依赖，修改时不敢删；也可能把本机状态当成默认配置，换环境后才发现根本跑不起来。更麻烦的是，私有状态和无关文件混在一起，会让一次普通复制变成不必要的信息暴露。
所以我判断，第一步不应该是问“整个目录能不能复制”，而应该问“这个技能最小需要什么才能成立”。只有问题换了，过滤才不再是凭感觉删文件。
先把文件分成几种角色
我后来采用的分法很朴素：先看入口，再看运行时依赖，然后区分文档、测试和本机产物。
入口是别人拿到包以后应该找到的起点。它可能是一个明确的操作说明，也可能是一个负责启动流程的文件。运行时依赖则是入口真正调用的内容，包括必要的配置模板、固定的资源和不可缺少的辅助模块。它们缺了，技能就不能完成自己的核心动作。
文档和测试不一定参与每次运行，却有另一种价值。文档让使用者知道边界和预期，测试让交付者确认过滤没有误删。它们不该因为“不参与运行”就全部清掉，也不该因为“看起来有用”就把所有历史样本都带上。
最后是本机产物。这一类最容易混入导出包：缓存、临时结果、开发过程中的中间文件、只对当前环境有效的素材和个人状态。它们可能让当前机器上的流程显得顺滑，却不能证明它们属于可移植能力。判断它们时，我会追问一句：换一台没有这份历史的电脑，技能是否仍然应该能按说明工作？如果答案是否定的，就要进一步查它到底是必要依赖，还是本机便利。
过滤的目标不是让目录尽可能小，而是让每一个留下来的文件都能回答“我为什么必须在这里”。
这种分类还有一个好处：它把“删不删”从审美问题变成了依赖问题。一个文件看起来很杂，不代表它一定应该删；一个文件放在目录里很久，也不代表它一定应该保留。
最容易走的错误捷径
最容易误判的错误捷径，就是直接复制整个技能目录，默认所有文件都对运行有用。这种做法省掉了当下的判断，却把判断推迟到新电脑或交接对象那里。对自己来说，可能只是多占一些空间；对别人来说，却是要从一堆没有角色说明的文件中猜出哪些能动、哪些不能动。
还有一种看似更专业的捷径：根据后缀、文件大小或目录层级做机械过滤。缓存目录全部删掉、素材目录全部保留，或者只留下几个“看起来像入口”的文件，确实很快，但它没有回答依赖关系。某个小配置也许决定技能能否启动，某个大素材也许只是一次测试留下的结果。
我没有选择这种一刀切的方式，是因为这次的目标不是得到一个漂亮的压缩包，而是让包在另一个环境里仍然有解释力和可验证性。如果一个过滤规则只能说明删掉了什么，却不能说明留下的内容如何支撑核心动作，它就还不是可移植方案。
这里也有一个需要接受的现实：第一次过滤不可能靠猜测达到完美。真正可靠的办法不是追求一次删净，而是允许在目标环境中暴露缺口，再补回经过确认的必要依赖。这个过程比全量复制多一步判断，却比交付后才发现入口失效更可控。
用最小可运行样本验证边界
我最后形成的流程，是先按角色筛出一个最小样本，再把它当成一次真实交付来检查。这个样本至少应包含明确入口、运行所需依赖和足够的使用说明；测试材料可以保留一小份，用于证明关键路径，而不是把所有历史结果都带走。
导出前，我会逐项问 3 个问题。第一，使用者能否从入口知道下一步做什么？第二，入口引用的依赖是否都在包内，或者已经清楚标明需要由目标环境提供？第三，包里是否混入了当前机器才有意义的状态？这 3 个问题分别检查可开始、可运行和可交付。
导出后，不能只看目标目录是否生成。要在一个相对干净的目标环境里按说明走一遍核心动作，记录第一个真正缺失的东西。如果缺的是运行依赖，就补回并更新说明；如果缺的是缓存、历史结果或本机素材，就不应因为流程暂时不顺而把整套现场重新塞回去。每一次补回，都应该有一个具体的失败证据。
这种验证方式有一个重要区别：它检查的是“拿到包的人能否使用”，而不是“原机器上的我还能否继续工作”。后者往往会被缓存和个人配置掩盖，前者才真正检验了可移植性。
可复用的最小导出规则
把这次经验压缩成规则，可以记成一条从内到外的顺序：先确定核心动作，再找入口；从入口追运行时依赖；保留能帮助理解和验收的文档、测试；最后主动排查缓存、临时结果和本机状态。不要先从“哪些文件方便复制”出发，而要从“别人最少需要什么”出发。
我会把导出结果看成一个承诺。它承诺的不是“这里包含我所有做过的东西”，而是“这里包含了完成这件事所需的最小边界”。承诺越清楚，后续维护越容易。技能升级时，只需要判断入口和依赖是否变化；新环境出问题时，也能定位是缺入口、缺依赖，还是目标环境本身没有满足条件。
真正可移植的技能包，不是原目录的缩小版，而是经过依赖判断、环境验证和边界说明之后的一份最小交付物。
这件事让我重新意识到，整理并不是把东西收拾得更整齐，而是把隐含在熟悉环境里的知识显露出来。当前机器可以替我记住很多细节，别人却没有义务拥有同样的记忆。能被复制的，应该是清楚的入口和可复现的判断，而不是一整套只有原作者自己认得的现场。
下次我会怎么做
下次再准备同步一套技能，我会先建立一个与原目录分开的导出区，不直接把源目录当成成品。随后为每个文件标注角色：入口、运行依赖、说明、测试或本机产物。没有角色、无法解释用途的文件，先放到待确认区，而不是默认打包。
接着我会用一个最小任务验证导出结果。在目标环境按说明完成一次核心动作，遇到缺失就记录具体依赖，再决定补回什么。验证通过后，再检查包里有没有缓存、临时结果和个人状态，避免因为“它以前有用过”就把它们留在成品里。
如果必须在完整复制和最小导出之间做选择，我会优先选择后者，并接受它需要一次补依赖的成本。因为真正要节省的不是这一次复制的几分钟，而是未来每次交接时都要重新解释一遍目录的时间。一个流程成熟的标志，不是它能把所有东西搬走，而是它能在换了环境以后，仍然让别人知道什么是必要的、什么只是过去留下的痕迹。