我一开始面对的，不是“怎么再做一条地图动画”，而是一个更容易被忽略的问题：上一次项目里已经用过的前端技术，下一次还能不能被真正找回来。
当时一个视频任务已经把地图、图表、矢量水墨层、配音和渲染流程串了起来。画面做出来以后，最自然的做法是把项目目录留在那里。下次遇到类似题材，再复制一份，改几处文字和素材，事情看起来就能继续往前走。但我很快意识到，这种“能复制”并不等于“能复用”。目录里混着题材内容、临时参数、已经验证过的组件和还没用上的依赖，真正有价值的判断反而藏在项目过程里。
这件事让我重新意识到，项目成功只是一次结果，能力库才是下一次工作的起点。真正要沉淀的不是某个项目的成品，而是从环境到组件、从坑点到验证方式的一条判断链。
一次做成，不代表下一次会快
这次复盘的起点很具体。用户希望把现场盘点清楚：本地前端技术栈已经搭好了什么，哪些基础能力可以直接调用，怎样快速找到已有资料，还有哪些方向可以继续做，而且不要把它做成一个复杂系统。
表面上，这像是在整理一份技术清单。实际上，它在问的是：如果下次只说一句“用前端做一条某主题的地图视频”，执行者能不能马上知道从哪里开始？如果不能，说明上一次只是完成了一个案例，并没有完成能力转移。
如果不处理这个问题，后果并不只是多花一点搜索时间。每次新项目都要重新翻旧源码，重新猜哪些库已经装好，重新判断某个组件是不是稳定，最后还可能把曾经踩过的坑再踩一遍。项目越多，目录越像仓库，信息越多，真正能被调用的能力却越少。
我一开始以为，最省事的办法是保留一个完整起手模板，把旧项目原样复制出来。后来发现，这个错误捷径只保存了文件，没有保存边界。旧项目里有题材相关的内容，有只为某个镜头服务的参数，也有安装了却没有在成片中用到的库。复制得越完整，下一次越难判断哪些东西真的应该留下。
我没有先做大框架
这里有一个很关键的取舍：到底要不要把所有前端能力都做成一套完整平台？我选择不这么做，是因为当前真正缺的不是更多抽象，而是4个最小入口：先检查环境，能新建工程，能按关键词找到资料，还能看到现阶段适合做什么。
我把它们理解成4扇门。第1扇门回答“现在能不能开工”，第2扇门回答“怎样起一个干净的新项目”，第3扇门回答“以前遇到的组件和坑在哪里”，第4扇门回答“这套能力还可以延伸到哪些题材”。它们并不试图替未来设计完所有工作，只负责把最容易卡住的4个瞬间接住。
这个选择看起来保守，却比做一个大而全的模板更符合现场。能力库的第1版不需要替人完成所有事情，只需要把从陌生到可行动的距离缩短。
环境检查尤其重要。前端视频项目往往不是“有代码就能跑”，还涉及渲染内核、字体、音频、地图资料和依赖版本。新建工程也不能只生成目录，因为目录存在不等于工程可用。这次的做法是，新建后顺手渲出一帧检查画面，让“工程已经创建”和“工程至少能渲染”成为两个可区分的结果。
把成功项目拆成稳定能力
接下来我不再按旧项目的文件结构整理，而是按“以后会问什么”整理。地图能力不属于某一段历史故事，图表也不属于某一个数据主题，矢量水墨层更不应该绑定某张地图。它们应该被记录为可迁移的组件和使用条件。
这一步需要把项目里的内容分成几类。第1类是已经实际用过、并且有明确效果的能力，比如地图展示、数据图表、矢量水墨叠层和配音驱动。第2类是已经准备好但还没有在成片中验证的能力，比如某些动画库、粒子或更复杂的地图方案。第3类是坑点，包括地图范围画错、竖排字序异常、字体加载导致渲染失败，以及渲染时找不到音频等问题。第4类是还可以继续尝试的方向，例如数据短片、城市飞线、粒子光效和弹性标题。
这几类不能混在一起。已经用过的东西可以作为稳定能力；只安装过但没用过的东西只能标成候选，不能写成“已经支持”。否则，能力库会把“装好了”误报成“做成了”，下一次项目才会暴露问题。
“已安装”“已用过”和“已验证”是3种不同状态，能力库必须把它们分开。 这不是文档上的讲究，而是对下一次决策的保护。若把候选库当成稳定组件，项目启动时可能看似选择更多，真正渲染时却要临时补坑，速度反而更慢。
用最小画面证明它不是清单
能力库最容易失败的地方，是变成一份漂亮的说明文档。里面写了很多组件和想法，却没有任何证据证明入口真的能用。为了避免这一点，我把验证压缩到一个很小的动作：新建一个工程，渲出一帧画面，再做规范检查。
这次实测从建立工程到看到检查帧，大约用了10秒。这个数字的意义不在于追求每次都正好10秒，而在于它把“以后可以直接开始”变成了一个可观察的事实。检查帧也不需要是一条完整视频，只要能证明纸张质感、版图、标题或基础图形能够被渲染出来，就足以提前发现环境问题。
如果不做这一步，能力库很可能只在文字层面成立。等到真正需要出片时，字体、音频、依赖或渲染配置中的一个小问题，就会把前面的整理全部拖回临时排障。最小画面相当于给能力库留了一个回归入口：以后新增一个项目，只要先完成同样的检查，就知道基础能力有没有漂移。
这里也有一个失败边界。一次检查帧通过，不代表复杂长片已经完成，更不代表每个候选组件都适合生产。它只能证明启动路径和最小渲染链条成立。我判断仍然值得做，是因为这个证据成本低，却能挡住一大批最早期的问题。对于还没有实际使用的库，则继续保持“待验证”状态，不因为它出现在依赖里就提前承诺。
从单一题材走向可迁移方法
复盘继续往前推进时，范围发生了一次重要变化。原来的能力是从一个历史地图项目里提取出来的，但下一步并不应该继续围着原题材打转。用户提出了新的历史主题：可以讲秦国完成对六国的统一，也可以讲美国从建国到现在的版图变化和迁徙过程。它们的历史内容、资料来源和叙事节奏都不同，却都可能使用地图、时间轴、数据层和配音驱动的前端视频方法。
这说明能力库的边界不能写成“某项目模板”。如果写成模板，下一次遇到新题材，使用者首先会问“这个模板能不能套”，而不是问“这个题材需要哪些可复用能力”。真正合理的边界应该是：先研究内容，再写文案，然后选择地图、数据、图形和声音的组合，最后用最小画面和规范检查确认工程可用。
我更愿意把它看成一种工作习惯，而不是一个技巧。每完成一个新项目，就登记它带来的可复用组件、实际踩过的坑和仍然没有验证的尝试。这样能力库的增长不是依赖一次性总结，而是依赖每次项目留下少量、可信的增量。
一个流程成熟的标志，不是它能把同一个项目复制得更快，而是它能把不同题材重新组合得更稳。 地图动画只是第1个例子，迁徙史、战争史、城市发展和数据叙事，都可以用同一套判断入口重新开始。
下次我会怎么做
下次遇到一个新的前端视频题材，我会先问4个问题：环境是否健康，应该从哪个最小工程开始，已有能力和坑点在哪里，这个题材适合哪些已验证方向。只有这4个问题得到回答，我才进入具体镜头设计。
我不会再把旧项目整体复制过来当作起点。先建立干净工程，再按关键词查找相关组件，查到的内容还要区分“用过”“只安装过”和“已验证”。如果遇到新问题，就把它写入能力库，但只记录能影响下一次判断的内容，不把过程日志全部堆进去。
我也会保留最小渲染帧。它不是为了证明成片已经完成，而是为了证明这次新增的能力没有让启动路径失效。等到项目真正做完，再把新组件、坑点和适用范围补回去。这样下一次调用时，面对的不是一堆旧代码，而是一组更清楚的选择。
这件事表面上是在整理前端技术，实际上是在整理人的记忆。工具真正改变的不是速度，而是我们愿不愿意把判断过程留下来，让下一次不用从零开始。对我来说，前端视频栈变成能力库的那一刻，不是入口写完，也不是检查帧出现，而是一个新题材到来时，我能少依赖临场记忆，却仍然知道哪些地方必须亲自验证。