从小厂到大厂：技术人转型进阶指南之七

第 11 章 陈曦的模型困境：小厂 “大神” 遇上大厂中台规范​

陈曦抱着笔记本电脑，在 T 厂 AI 中台的调试间里坐了整整一下午，屏幕上 “模型格式不兼容” 的报错弹窗，像根刺扎在她眼里。​

作为小厂的 “算法大神”，她曾靠一己之力把推荐模型准确率从 82% 提到 91%，老板逢人就夸 “陈曦写的模型，不用管就能跑”。可到了 T 厂，她精心调优的 ResNet 推荐模型，连中台的 “准入门槛” 都没迈过去 —— 中台文档里的规范要求，光 “模型交付清单” 就列了 18 条，比她过去三年写的所有代码注释加起来还多。​

“模型必须用 ONNX 格式打包，还得附带‘模型卡片’，写清输入输出维度、特征含义、训练数据来源，甚至要标注‘是否含敏感特征’。” 陈曦翻着中台规范，手指都在发紧。小厂做模型，她从来都是用 PyTorch 原生格式保存，输入输出全靠自己记，哪需要什么 “模型卡片”？更别提中台还要求 “每一层网络都要加日志埋点，推理时要输出特征重要性分数”—— 这些在小厂看来 “多余” 的要求，在 T 厂却是 “必须项”。​

更让她崩溃的是 “权限校验”。小厂的模型跑在单机上，她随时能调参数、改结构；可 T 厂的 AI 中台，模型推理要走 “权限申请→资源调度→结果回传” 的流程，她昨天申请的 “推理资源配额”，到现在还在 “安全部门审核” 环节卡住。​

“为什么跑个模型要这么复杂？” 陈曦忍不住找导师老吴吐槽。老吴指着中台监控大屏，上面密密麻麻显示着 200 多个在线模型：“小厂是‘单机跑模型’，出问题只影响自己；T 厂是‘万人用中台’，一个模型格式错了，可能导致整个推理集群崩溃，一条权限没设对，就可能泄露用户数据 —— 规范不是‘束缚’，是‘保护千万人协同的安全线’。”​

那天晚上，陈曦熬夜按中台规范改造模型：把 PyTorch 模型转成 ONNX 格式，补全 18 项 “模型卡片” 信息，给每一层网络加日志埋点，甚至还写了 “模型失效应急预案”。凌晨三点，她终于在中台成功跑通推理，看着屏幕上 “推理成功，结果已回传” 的提示，突然懂了：小厂的 “算法自由”，是 “小范围可控的随意”；大厂的 “中台规范”，是 “大规模协同的必然”—— 要在大厂做算法，先得学会 “在规范里把事做对”。​

第 12 章 万人协同现场：改一行代码为何要 13 人审批？​

林默在 Z 厂参与的第一个跨部门项目，就被 “审批流程” 惊掉了下巴 —— 他要改支付模块里一行 “订单状态判断逻辑” 的代码，居然要找 13 个人签字审批。​

“不就是改个 if-else 吗？在小厂我五分钟就能上线！” 林默拿着 “代码变更审批单”，看着上面列的 “业务负责人、架构师、安全工程师、合规专员、运维经理” 等 13 个审批角色，忍不住跟老周抱怨。​

老周没直接解释，而是拉着他参加了 “变更评审会”。会上，业务负责人先问：“这行代码改了，会不会影响历史订单的状态查询？” 架构师跟着补充：“支付模块是核心链路，改逻辑要做全链路压测，你压测方案过了吗？” 安全工程师更细致：“判断逻辑里有没有用户 ID 明文？会不会有数据泄露风险？”​

林默站在会议室里，冷汗慢慢冒了出来 —— 他只想着 “改对逻辑”，根本没考虑 “业务影响”“性能风险”“安全合规”。直到合规专员指出 “订单状态变更要符合《支付业务管理办法》第 12 条，需留存变更日志至少 3 年”，他才明白：这一行代码背后，牵动着 “业务正确性、系统稳定性、数据安全性、合规合法性” 四条线。​

“小厂改代码是‘一人拍板’，因为影响范围小；大厂改代码是‘万人协同’，牵一发而动全身。” 散会后，老周跟林默解释，“你改的这行代码，会影响日均 2000 万笔订单的处理，涉及用户资金安全，所以业务要确认、架构要把关、安全要审核、合规要监督 ——13 个人审批，不是‘官僚主义’，是把‘风险责任’分摊到每个环节，确保没人掉链子。”​

后来林默花了三天，补完压测方案、安全评估报告、合规说明，才集齐 13 个人的签字。当代码终于合并到主干时，他在笔记本上写：“小厂的‘快’，是‘牺牲风险换效率’；大厂的‘慢’，是‘控制风险保稳定’—— 在万人协同的场景里，‘慢即是快’，因为一次线上故障的代价，可能比审批流程的成本高 100 倍。”