设想这样一个场景：你是信息科的一名工程师，明天就要离职，只给你一天时间做交接。手上管理着多个项目，其中的文档、代码逻辑、系统配置，是否足以支撑下一个工程师接手维护？

大多数工程师心里都清楚。以项目制交付的系统，验收文档或许完整，专家评审也能通过。但在那之后——无穷无尽的需求变更、跨厂商的协调记录、某个接口字段被悄悄改过多次的历史——谁又会去持续的更新文档呢？真正撑起系统运转的知识，大半沉在工程师自己脑子里，从来没有被系统地写下来过。

AI大规模进入这个行业，恰恰把这个问题推到了台面上。理论上，文档和代码都可以被大模型蒸馏成知识库——但前提是有人把事情写下来、讲清楚。那些从来没有被记录过的判断、没有被解释过的决策，模型也无从提取。这意味着，在AI时代，"能不能把自己的经验说清楚"，正在成为比"会不会做"更稀缺的能力。

IT行业的技能市场，正在重新定义

2023年以前，IT从业者属于"信息差"持有者。写出一段好用的SQL、拼出一段无bug的脚本，就可以将自己与一个非技术背景的同事拉开差距。但这层"信息差"在AI模型普及后已经逐渐消失。

GitHub Copilot、Cursor、各家大模型的代码功能，让"能写代码"这件事的门槛彻底降低。以前需要两小时搞定的需求，现在平均下降到二十分钟。这不是工程师被取代，而是一个更隐性的风险正在积累：低层技能的门槛下降，让工程师容易错觉自己依然有价值，却不知不觉地废掉了更重要的能力建设。

目前呼声更高的对象，不是"会写代码的人"，而是能判断"这个需求应不应该做、怎么做、带来什么风险"的人。技术实现变得越来越容易，工程师的判断力反而越来越稀缺。

还有一个更隐蔽的问题：AI接管了基础任务之后，初中级工程师就失去了"在重复劳动中慢慢成长出直觉"的机会。以前靠写一百个接口积累的系统感，现在可能根本没有机会积累了。能力断层正在悄悄形成，只是还没有完全显现出来。

【会做】正在失去价值，【懂为什么这么做】才是前途。

工程师应该主动做的三件事

第一，把自己的技能图谱摸清楚

医信工程师手上的技能通常多而杂：接口调用、SQL维护、系统管理、实施沟通……面对每一项，值得问自己两个问题："这个工具能帮我做了吗？"和"如果工具做不了这个，我别的方法是什么？"前者在事、后者在人。前者的门槛已经下降，后者需要主动加固。

第二，把"只有我知道"的东西系统地记录下来

模型能生成代码，但它不带医院厂商层层封装的数据字典。它可以写出HL7标准消息，但它不知道某家医院HIS系统在某个字段上有一个十年前留下的隐式约束。更关键的是：要被蒸馏，就必须先被写下来。能不能把一个字段约束的来龙去脉写清楚，能不能把多次跨厂商协调的决策逻辑记录在案，本身就是工程师价值的一部分。更值得警惕的是：市面上已经出现了能扫描工程师提交记录、决策文档和沟通记录、并打包成可调用 AI Skill Pack 的工具。AI 不只是"不知道"你的经验，它正在主动学习并提炼它。这意味着，系统地积累、标注、外化自己的隐性知识，已经不只是一种好习惯，而是一种主权守护。

第三，把AI当作练习场，而不是拐杖

用AI解决问题效率很高，但如果每次处理完就直接封档，就错过了建构判断直觉的机会。比较好的习惯分两步：在用AI之前，先自己拆解问题、判断方向；在拿到AI输出之后，主动质疑它——识别逻辑是否有漏洞、映射是否有偏差。在医疗系统里，质疑 AI 输出，是医信工程师比其他行业更需要养成的习惯。

医信工程师的特殊优势

和互联网公司不同，医疗信息化有一个天然的低容错层：业务系统的故障不是指标跌零，而是直接影响到患者病历录入、收费结算、护士执行医嘱。这种特殊性意味着：工程师的判断不能只停留在技术层面，还必须包含对业务的保护意识。

明白医师开一张医嘱的逻辑如何映射到数据库表里，知道医保结算时按年度统计还是实报分开的差异是什么，了解手术室排班逻辑已经被定制重写了三个版本但从未有人整理成文档——这些东西不会出现在任何交接手册里，只会叠加在一个工程师多年维护的经历里。

深耕业务的工程师，能在准确描述需求的同时评估它的可行性和风险。AI可以提高实现速度，但它无法替代工程师夹在医疗公司和医院信息科之间，判断一个方案到底能不能上线。这种判断力，是真正难以复刻的东西。

结语

回到开头那个问题。AI时代，文档和代码本身可以被蒸馏复现——但前提是有人把事情写清楚过。真正难以复刻的，是那些从未被记录过的判断和现场经验。AI时代不缺能做事的人，缺的是能把"为什么这么做"说清楚的人。

各位同事，你们手上有多少可以被“蒸馏”的文档和代码呢？