在一个业务里工作久了，会形成很多局部优势：知道历史接口的例外，知道哪段代码不能轻易动，也知道谁能最快回答问题。这些经验让交付更快，却不一定能被带到下一个环境。
离开熟悉的监控与可视化业务前，我尝试区分两类知识：一类属于具体系统，另一类属于解决系统问题的方法。
结果之外还要记录约束
复盘如果只写“完成了组件化”“优化了性能”，很难在未来复用。我更关心当时有哪些约束、有哪些候选方案、为什么放弃其中一些，以及什么证据说明选择有效。
例如一次图表性能优化，真正可迁移的不是某个参数，而是先测量渲染、数据转换和网络分别占用多少时间，再针对主要瓶颈行动。这套顺序可以用于完全不同的项目。
那次排查我留下的记录很简单，却比“优化 ECharts”更有用：
现象：切换到 24 小时范围后，页面约两秒不能操作
假设 A：接口返回慢
假设 B：数据转换阻塞主线程
假设 C：图表节点过多
证据：
- 请求约 180ms
- 数据转换约 90ms
- setOption 到 finished 事件约 1.4s
决定：先降低同屏点数，并保留缩放后的原始查询入口
未做：重写数据层；当前证据不支持这份记录没有绑定具体框架。换成另一个可视化库，仍然可以从同样的时间切片开始。它还保留了“为什么没重写”的理由，避免后来的人把克制误解为遗漏。
不把熟练误认为能力
对旧系统的熟练有时会制造错觉：问题刚出现就知道答案。但换一个技术栈或团队后，熟练不再存在，提问、阅读和验证的能力才显现出来。
我希望进入更接近互联网用户的产品，面对更大的流量、更快的迭代和更复杂的协作。变化意味着重新变慢，也意味着检验自己究竟学会了什么。
交接也是一次理解测试
准备交接时，最能暴露哪些知识只存在于个人脑中。若一个模块必须依赖口头提醒才能运行，说明它还没有真正成为团队资产。我把常见故障、环境差异和关键数据流补进文档，也清理只有自己理解的脚本入口。
交接时我按四层组织材料：
- 一张系统地图：入口、主要数据源和外部依赖。
- 三条关键路径：正常操作从哪里开始，经过哪些状态。
- 一份故障索引：现象对应先检查的日志、接口或配置。
- 一组未完成决定：为什么推迟，什么条件出现时要处理。
真正难写的是第四项。代码里的 TODO 只说明“没做”，无法说明“为什么现在不做”。把触发条件写出来，技术债才不会变成下一位同事的考古工作。
交接文档不需要解释每一行代码，而要帮助接手者建立地图：系统解决什么问题，主要边界在哪里，哪几处风险需要先关注，遇到异常从哪里开始看。能把这些讲清楚，也是在检验自己是否真的理解系统。
项目会结束，技术会替换。能够带走的，是看待约束的方式，以及在信息不完整时仍能推进问题的能力。
图：经验只有能被后来的人独立使用，才真正离开个人记忆。
离开项目前我会带走四份资产
我现在做交接，不只列仓库和联系人，而是留下系统地图、关键决策与反对意见、最近三类事故及恢复方式、未来三个月最可能出问题的边界。每份都指向实际仪表盘、Runbook 或 ADR。
这些材料既帮助接手者，也检验我是否真的理解系统。只能靠“有事问我”维持的知识，不算完成交接；能被后来的人独立使用，经验才从个人记忆变成团队资产。