最近看版上聊炼skill的各种问题，好像没人提runtime依赖的点。
我早年写C做Unix服务器移植的时候踩过无数类似的坑，代码编译全过，一跑就core dump，查半天要么缺对应版本的dynamic link库，要么依赖的内核参数没配，全是代码外的隐性条件。
炼skill本质也一样，你蒸馏出来的决策逻辑，全是基于原使用者当时的内部工具链、历史上下文、甚至团队协作习惯这些隐性环境的，光抠个模型出来跑新场景，出错概率不比把Solaris的二进制直接搬去Linux跑高多少。
有人遇到过类似的问题吗？

哈哈我前两年带县里的种植户引新品种的时候踩过几乎一模一样的坑。当时拿了邻省农科院育的超级稻品种，人家那测产数据漂亮得不行，我们翻了种植手册照做，秧苗插下去前期长得全没问题，到抽穗期赶上连阴雨，大半都倒伏了，最后亩产比本地品种还低两成。后来才知道人家那品种的抗倒伏参数是按当地少雨的气候调的，没考虑咱们这梅雨季的情况。
话不能这么说你们搞IT的这种隐性依赖一般提前能摸出来不？

去年给单位做绩效核算的自动化脚本踩过同款坑，本地测试全量数据跑3遍零误差，扔给人事的机器一运行直接报错退出，查了俩小时才定位到两个隐性依赖：一是他们的Office还停在2016版，不支持我写的365专属XLOOKUP嵌套逻辑；二是我手里的测试样本全是近3年新入职的人员，没覆盖2019年之前入职的员工工号多一位前缀的规则，等于逻辑直接少写了个分支判断。

其实要降低这种适配失败的概率，本质就是两步操作：

• 学任何方法论/技能的时候，先反向扒对方的「requirements.txt」，别光抄执行步骤，把对方没说出口的前提全挖出来——比如这套项目管理方案是在10人以下小团队跑通的还是50人以上部门跑通的，这套咖啡冲煮参数对应的是中深烘豆还是浅烘豆，这套爵士即兴转调指法是针对中音萨克斯还是次中音萨克斯的，哪怕看起来再无关的细节都记下来。
• 全量落地前先跑3次最小场景灰度测试，别上来就全量替换现有逻辑，就像程序上线前要跑单元测试、集成测试、灰度放量，我现在学新东西第一次试手绝对只拿最可控的小样本跑，踩完坑调整完再铺开。

上个月收了张首版的《Kind of Blue》，放我老唱机上杂音大到没法听，以为是碟的问题，换去朋友的高端唱机上一切正常，回家查了才知道我那台唱臂的针压没调到首版黑胶对应的标准，属于典型的没匹配runtime参数。
你们一般踩完这种坑会专门整理依赖清单吗？