技术部新员工入职培训要讲清规范背后的取舍

技术部新员工入职培训通常从阅读代码仓库说明、架构文档和发布规范开始。这些资料多数存在，却分散、过时，且只记录了最终做法。新人读得完，却接不上手：他知道分支怎么提、评审走几步，却不清楚这些约定当初为避开什么而定。能回答这类问题的是团队里的资深工程师，每次答疑都要中断他们手上的开发。技术负责人要判断的，是新人多久能独立提交一次改动，又要占用多少资深工程师的时间。

UMU 解决方案预约 Demo

技术部入职内容按能否查到分两类

两类内容，两种交付方式

技术部入职要交付的内容，可以按能否从现有资料中查到划分。第一类是环境搭建、分支与评审规范、测试与发布流程、值班响应约定，步骤明确，写进文档就能查到，新人照着执行即可。第二类是这些规范当初为什么这样定、系统为什么拆成现在的结构、哪些做法在历史上出过问题。第二类内容决定新人遇到规范没覆盖的情况时能否自行判断，却通常没有写下来，只留在参与过设计的工程师记忆里。

用两个问题判断方案是否成立

技术负责人评估入职培训方案，可以只看两个问题：新人从到岗到独立完成一次完整提交需要多长时间，这段时间里资深工程师被答疑占用了多少。前一个问题衡量新人是否接上了手，后一个衡量这次入职消耗了团队多少产能。两个问题都不看资料是否齐备，也不看课程是否完成，这两项只说明内容已经交付。方案要改进的位置就在两者之间：把第二类内容交付出去，并让新人的追问不必每次落到工程师身上。

技术部新人接手系统的核心瓶颈

文档只留结论，不留取舍

架构说明和流程规范记录了最终做法，很少写下当初排除了哪些方案、为什么排除。新人照做能得到结果，一旦遇到规范没有覆盖的情况，就缺少判断依据。

追问只能落到身边的人

文档不会回应具体问题，新人只能转身求助。每次提问都会中断对方手上的开发，团队里最熟悉系统的那几个人，时间被切成零散片段。

能不能独立动手，只能猜

负责人掌握的只有资料是否发出、任务是否领走，看不出新人在哪些环节没有把握。盲区往往要等改动被打回或线上出现问题时才显现，代价由团队承担。

入职培训要覆盖当初的取舍过程

对话中取出没有写下的依据

交付第二类内容，前提是有人先说出来。UMU AI Generated Learning（AGL）用 AI 将企业文档整理成互动式课程，并支撑员工的学习过程。资深工程师不必另学教学设计，只需按提示回答：这条规范当初避开什么，哪些情况例外。AGL 把回答与原有文档编排成课程大纲，取舍依据由此可反复调用。

追问在课程内解决，不必打断同事

随时提问，当场得到回答

课程本身能回应提问，追问才不会落到工程师身上。在 AGL 的课程里，AI 同时承担三种角色：讲解时是讲师，提问时是导师，练习时是教练。新人读到一条发布约定，可直接追问它适用哪些情况，AI 依据课程引用的文档回应，再回到讲解主线。个性化讲解不再依赖某个人的时间，资深工程师的开发节奏不必为每次提问让路。

按学习表现判断先交什么任务

负责人看得到薄弱环节

新人是否理解关键约定，此前要等改动被打回才知道。AGL 记录知识点级别的学习表现：哪些小节被跳过、哪些内容被反复追问、间隔重测正确率如何。负责人据此在交出第一个独立任务前确认新人还不熟悉哪些环节，先补一次讲解。三项方式合起来构成完整方案：取舍依据被取出，追问当场得到回答，学习表现为后续安排提供依据。