三年前我校招进公司，做大模型算法。而这个月底离职，换了公司，甚至换了城市。这篇聊聊三年里我对“工作”这件事的理解怎么变的。
第一年：预期落空，是件好事
入职前我对这份工作的想象挺具体的：公司里有一个已经在跑的项目，它有一些问题；问题由老板指出来；我去想办法、跟同事一起把它优化掉；优化完上线，对很多用户产生正面（或负面）的影响。一条标准的迭代式路径。
但实际情况是，我入职正赶上大模型技术爆发。没有那么一个“已有项目”等着我去迭代，更多的是每天都有新东西需要跟进——评测怎么做、训练怎么做、推理怎么加速。这些事在有的团队里会拆给不同的人，一人一块。但当时大家对于大模型的认知还很模糊，落到我手上的工作很泛，所以从头到尾我基本都做了。
这跟我入职前从网上得到的信息是反的。那会儿帖子里都在说“进厂就是螺丝钉”，只做某一类很小的工作。真干起来发现，至少在技术爆发期、至少在我们这种组里，情况正好相反：边界模糊，活很杂，什么都得碰。
我个人是喜欢这种状态的。所以这一年我拿到的东西，回头看并不是某项具体技术——那些东西迭代得太快，大部分已经没用了。真正留下来的是：
- 怎么跟同事做一次有效的技术讨论：学会把分歧收敛到“我们在哪一点上判断不同”。
- 怎么从别人身上取想法：同一个问题，资深的同事切入的角度经常跟我不一样，这个差异本身就是可学的东西。
- 怎么用工程视角想问题：比如对模型进行推理加速这件事，服务的是很多条业务线，哪怕不直接对接业务，也得知道业务在意什么、我的优化对它们意味着什么。
另外一件事是：我的工作内容一直在变，并不是我主动换的。我自己想做的在提出来之后大多会被按下去。我提过“论文都在聊 prefix cache，但当时工程上依旧没人实现，我们要不要做做看”，看起来是一个很有价值的想法，但这个想法有两个变量：
- 它本身的价值对于团队来说有多大。
- 开源将来会不会做同样的事。如果开源将来会做同样的事，那这个想法的价值就会大打折扣。
这一年我在团队里的贡献更多在于接得住：我能比较快地接受新东西和老项目，把它跑起来。这一年最享受的是纯粹。那时候做的事大多是从零到一，只要做了就有收益，不需要关注业务指标怎么波动。要看的问题很技术：怎么让这个模型训得更快，这次推理的瓶颈卡在哪里。问题本身是清晰的，答案是可验证的。
现在我知道，这种清晰是阶段性的红利，不是常态。
第二年：一个人从头到尾
第二年任务开始变细，我被对到一条具体的业务上。
本质上做的还是技术，而且是要用很深的技术思考才能给业务带来价值的那种。但形态完全变了。业务上有各种各样的问题，得在业务和技术的平衡中做取舍，同时还得把效果提上去。这两件事经常是反的。
于是很多时间花在了周旋上：跟业务聊，跟研发聊，跟老板聊——问题在哪里、卡点在哪里、下一步优化的方向在哪里、这个方向有多大信心能拿到收益、跟外部对比我们凭什么觉得会更好。
这里面最关键的一点是：这些东西没有人会替你总结。我记得有一次，关于并发请求响应时间的问题，我需要把我的理解，讲给业务听——不提任何 GPU 算法名词，只讲基本原理；回到工位又讲给同事听——简化业务环环相扣的链路，只讲瓶颈在哪一环。聊这些事情的时候，你得自己把散落在各处的信息收拢，自己判断下一步该往哪走，自己给自己定目标，然后拿着这个判断去跟各方对齐。
第一年是我等着问题被指出来，第二年是我得先把问题描述清楚。
还有一件事，当时我以为是临时状态，后来发现是结构性的：在大模型项目里，很多时候只能由算法来当那个实际上的 owner。
原因不在于职级，在于不确定性。产品同学很难判断一件事该怎么推进、该推进到什么程度，因为他没办法知道模型的上限在哪——这不是他的能力问题，这个信息只有“触摸”过模型的人才有。更麻烦的是，同一个 case，今天是对的，下一次可能就是错的，而我也解释不了为什么。有业务会问“为什么这道题昨天做对了，今天做错了？”，你没法拿着一个会自己变的东西去跟人对齐标准。
所以很多判断最后都落回到我身上：这件事到底能不能做、能做到什么程度、值不值得投。名义上我是这条链路上的算法，实际上承担的是项目 owner 的角色——判断做什么，以及判断什么时候算做完了。
这件事对能力的要求跟写代码完全是两回事，而且它不会出现在任何一份 JD 里，即短期来看对于职业发展没什么帮助。
另一个变化是职责范围。在我们这边，模型的训练、推理、部署，往往是我一个人推，或者跟一两位同学一起推，上下游全在自己手里。别的地方可能分得很细——训练工程师把数据准备好、脚本跑起来就算完，推理加速有专门的同事，成本核算又是另一批人。
两种模式各有各的合理性，我的收获是：整条链路的每一环我都清楚它为什么是这样，以及它在哪里会坏。但是它很难让我专注在某个具体问题上，因为每个问题都像是一个拼图块，而我得不断在各个拼图块之间切换。
这条路走完之后留下了一样东西，是我这三年里最认的产出：一套规范。
起点是线上的问题。很多东西不出事的时候你根本想不到要测，出了事之后才知道那一环是脆的。所以每次线上有问题，我们的复盘不只是修好它，而是往外推一层：同样的隐患，在别的服务上是不是也存在？于是就有了一串具体的问题：
- 服务被打爆的时候容灾策略是什么？
- 稳定性除了压测还能怎么验？
- 请求侧、业务侧的代码要怎么写才不会在高压下把自己拖死？
- ...
这些问题一个个被答完之后，就沉淀成了一套写法和一套检查项。然后关键的一步是：它得能被别人快速用起来，而不是只活在我脑子里。后来它确实成了团队沿用的做法，也被其他团队拿去复用。
我觉得这件事比我训过的任何一个模型都更耐久。模型会被开源替换掉，这套东西不会。
这也是我现在看“端到端”这件事最大的价值：不是我什么都会干，而是只有把上下游都握在手里的人，才有资格定这种跨环节的规范。分工很细的话，每个人都只看得见自己那一段，没人有那个全局视角。
那一年在这件事上做了很多迭代，而且大家都或多或少有收益。原因现在看得很清楚：那时候开源模型都还不够强，基线低，你往哪个方向使劲都能捞到一些正向。收益是真的，但它有一部分来自时代，不完全来自我。
而现在链路打通、坑踩完、规范立完，剩下的就是最难啃的骨头——怎么训出一个效果更好、更符合业务预期的模型。
第二年半：那些理性的、但你不喜欢的决定
好摘的果子摘完之后，边际收益开始变小。
做相对前沿的事，技术不确定，各家有各家的想法和探索路径，失败本来就难免。但除了“做不出来”之外还有另一种失败：你做出来了，它是有效的，然后几个月后开源一个东西，比你做的更好或者更省，于是你那套就被替换掉了。
它不是某一天发生的一件事，而是一个持续的过程——每次新模型出来的时候，我们都会尽快进行评测。你的指标相对开源的领先幅度，每个月都在缩小。你还在推进，方向也没错，但你和开源之间的那个差值一直在被压薄。到某个时候，自己做这件事就不再成立了。
这件事里最难的部分不是技术，是它会动摇你对“什么叫有价值的工作”的判断。一件事你做成了、上线了、也确实起作用了，半年后它被一个免费的东西取代——那这半年算什么？
我现在的答案是：算在你身上，不算在那个模块上。被替换掉的是产出，留下来的是你在做这件事过程中形成的判断力。这个答案不算很有说服力，但目前我只有这个。
也是在这个阶段，我撞上了第一个真正让我困惑的东西，而且它不是技术问题。
说回到团队内部，我们团队接受结果不是最顶那一档，而是要求它可复现——不能是“我做出了一个很高的数字，但不知道它怎么来的”；也要求成本可控——不能等一个开源模型放出来，我要花一两个月才能复现自己之前的结果。
这套标准的代价是，你得主动丢掉不少能冲更高上限的做法。
- 站在老板的位置，这是理性的、负责的选择：一个不可复现的高分，对团队来说等于没有；一个复现成本极高的结果，在快速迭代里也是负资产。
- 从执行的个人视角看，这会限制你能做的事情：不能做那种不确定很高、但可能带来巨大收益的事。因为这些事情的收益很难量化，而且在快速迭代里很容易被开源追平。
大家都很理性，决策也是对的，而你是那个在账面上吃亏的人——这两件事同时成立。
我后来想明白的是：这里根本没有一个客观正确答案，它纯粹取决于你坐在哪个位置。你是执行者、是大头兵，你一定会想追求技术深度，因为那是你的手艺，也是你能带走的东西。你是老板，你一定会去取那个期望收益最高的点，因为你要对整体的产出负责。这两种倾向都对，它们只是从不同的位置看同一件事。
所以我大体是认同那个决定的。但有一个我认为有歧义的地方，是对“失败”的处理方式。
比如有一件事由 A 同学做过了，不管成还是败，其他人就基于这个经验往下走，如果没有特别的理由，不会再让 B 同学做第二遍。这在成本上很干净。
但我认为，如果是失败了，我会愿意再找一到两位同学重做一遍。因为在这个领域，一次失败能证明的东西太少了——它可能是方向不对，也可能只是这个人在这个时间点的一次没调出来。把这两种情况按同一种结论处理，风险其实不小。
这背后是老板“激进还是保守”的差别，而激进的底气来自技术判断力。我承认在成本这件事上，我会比我们当时的做法放得更开一点。
如果要说这一段我真正学到的，是别把个人收益和组织决策的合理性绑在一起判断。它们是两套坐标系。一个决定可以对组织完全正确，同时对你个人完全不划算。承认这一点，比说服自己“其实我也赚了”要诚实，也更省力。
第三年：一次失败的训练，和它教我的事
第三年，性价比高的产出基本挖完了。业务侧的效果优化推不动，难的地方太难，容易的地方没了。
这种时候，团队自然会去找新方向。我手上开始做一些偏工程的杂活——训练、推理加速之类，有技术难度，但说实话是按部就班的事，能做多久、可以出多少东西都是可以被预估的。同时，一个新方向被立起来：训一个我们从来没碰过的架构的模型。
结果是失败的。
一开始我信心很足。但某个时刻突然觉得不对劲，我没有办法说具体是在哪个时刻觉得不对劲。大概是某次把所有已知的 bug 修了之后，loss 正常，grad 正常，输出正常...但模型效果就是不行。
于是我遇到了做大模型最难解释的那类问题：我准备了一份数据，这份数据质量足够高，按常理它应该能训好——这个判断是客观的。可它在这个架构上就是训糟了。架构是定的，超参调了，该试的都试了，结果就是变差。你要怎么解释？“数据质量高，模型效果变差”——这两个半句放在同一句话里，语法都对，但谁看都觉得哪里不对。
我后来发现这不是我的能力问题，是这个领域的共同处境。无论是开源技术报告还是同行交流，大家都很难真正解释清楚：我这份数据到底有没有信号，某个改动为什么让它变差。这种不可解释性是这份工作的底色，不是偶发的意外。想明白这点，我稍微安心了一些，也更绝望了一些。
“直觉”攒到差不多的时候，我去找了老板。我说：我觉得可以停了，达不到预期。他问我的依据是什么。我说了数据情况、排除过的方向、现在的指标，但没有一条是“确实不行了”的证据。老板给的结论是：这块硬骨头得继续啃，他甚至能接受一个月后还是失败，但他不关心，他要的是这个方向被挖到底。
作为底下的员工，你会跟进老板的意图，继续投入。他买的不是这一件事的成败，是这条选项的穷尽。
这件事我至今没有一个漂亮的结论。我唯一确定的是：如果在那次对话之前，我能把已经排除的假设、各是哪次实验排除的、还剩哪些没验证，写成规范化文档——决策未必会变，但那场对话的质量会高很多。分歧可能依然存在，但它至少会是一次关于证据的分歧，而不是关于信心的分歧。
这是我从那次失败里真正拿走的东西。不是“该早点放弃”，而是“该更早地把感觉变成可讨论的东西”。
同一个毛病，在另一类场合也出现过。偶尔——一年大概一两次——我会提出一个我觉得该做的事，但没被采纳。比如长文本场景下的推理速度：做并发够不够，还是必须上加速。我记得一次会上我说“这块可能有问题”，老板问“大概多大，解决了能拿多少”，我说不上来。说不清楚的代价表面上只有那三十秒的尴尬，实际上是一个被埋掉半年的信号。
这种提法是推不动的，老板每天要处理的判断很多，他没有义务为一个说不清楚的直觉分配资源。后来这些事情里有一部分被验证了——通常是另一个同事也撞上了同一个问题，两个人的观察对上了，它才开始被推进。
我一开始把这理解成“要有人替你背书”。现在我觉得那是表象。两个独立的观察撞在一起，这个信号的强度本身就比一个人的直觉高一个量级。它被采纳不是因为人多，是因为证据变结实了。
所以结论跟前面是同一条：判断正确不足以让它被采纳。你得把它做成一个别人能检验的东西。我这三年在技术上进步不小，这件事上进步得最慢。
方向一直在变：文本、图片、语音
这三年我的工作内容一直在换，而且不是我换的。
最早做文本。第二年开始转图片，做了一年多。训练失败那段之后，团队转向语音，我也跟着做语音。语音这块我的工作，大概是从清洗通用语音数据，慢慢转到业务指定数据上——就是那条从“通用”走向“具体”的路，又走了一遍。
有意思的是，每次换方向，那条规律都成立：你在一个新领域刚开始做的时候，一定能拿到最大的红利，然后再慢慢迭代，收益递减。文本是这样，图片是这样，语音也是这样。
我一开始把这看成运气——赶上了红利期。后来觉得这么想不太对。红利期能不能吃到，取决于你进入一个新领域时能多快把它跑通，而这个能力恰恰来自前面那些端到端的经验：数据怎么洗、训练怎么起、推理怎么部署、成本怎么算。换了模态，这套骨架大体是通用的。
我做的事情很多是在更抽象的那一层，它不怎么取决于模态，甚至不怎么取决于具体业务。真正难的一直是同一件事：你怎么认知模型，以及你怎么判断一份数据。
模型为什么在这里变好、在那里变差；一份数据里到底有没有有效信号，还是只是看起来干净；当指标动了，是数据起了作用，还是只是噪声。这些问题在文本上是这样，换到图片、换到语音，还是这样。模态换了，难点没换。
所以这三年下来，我手上具体的技术知识折旧得很厉害，但对模型和数据的判断力是在增值的。这可能是我最愿意带走的资产。
做语音的同时，我已经在看机会了。所以这段经历跟我下一份工作的关联没那么强，它更像是这三年的一个终点。
一年没手写代码
AI 变强的速度太快了。有一次我忽然意识到，自己已经快一年没自己写过代码了，更多的是“发号施令”。
从开始学习写代码的时候，是开心的。现在这份开心少了很多。这不是抱怨工具——能力上我确实变强了，同样的时间能做更多事情。但当你的主要动作从“写”变成“指挥”，那种手感的丧失是真实的，它会让你对自己的位置产生一些疑问。
我没有想清楚这件事。我不知道这是一次性的适应期，还是整个职业形态的永久改变；也不知道几年后“算法工程师”这个岗位的核心能力会被重新定义成什么。
我只能说一个观察：这一年里，我的判断力比我的执行力更值钱了。什么方向值得做、什么信号是假的、什么结果不可信——这些东西 AI 目前替不了我，而且它越强，这部分的权重越大。如果非要下注，我会下在这里。
如果你刚毕业
这节是写给刚入行的人的。我不觉得自己有多少资格给建议，所以只写四条我确实验证过的。
先接受，再发挥。
到一个新环境，我的做法是先接受一段时间：观察团队里同事和老板各自的工作风格，把交代给我的事情做好。这不是让你藏起来，是承认一件事——你刚来的时候，对这里为什么这样运作几乎一无所知。很多看起来很蠢的做法背后有它的理由，你得先知道理由是什么，再谈改不改。
先做好被交代的事，是校招生入职最该做的一件事。发挥的空间会在你站稳之后自然出现。
敢问愚蠢的问题。
在这个过程中你可以提一些很愚蠢的问题。有些事情你确实不知道、确实没遇到过，那就问。愚蠢的问题带来的尴尬是几秒钟的，不问带来的误解可能要几周才暴露出来。
而且在大模型这个领域，“愚蠢的问题”常常不蠢——很多东西本来就没有人真正说得清。
ego 别太重，对事不对人。
这条我觉得比前两条更重要。
工作里会有分歧，会有人否掉你的方案，会有人觉得你想错了。你需要把工作中的情绪和生活中的情绪分开——对一个同事在某件事上的看法，不该延伸成对这个人的看法。他否你的方案，大多数时候是纯对事不对人的。
这两者要能区分开。分不开的人会很累，而且会慢慢失去愿意跟他直说的同事。
自己建立技术判断，不要等工作喂给你。
你手上的活不会覆盖你该懂的全部。所以哪怕某个方向跟你当前的工作没关系，也值得自己去读报告、跟同行交流，先形成一份属于你自己的独立判断。
这件事的回报不是显性的，但它决定了前面所有的东西：你能不能识别出方向不对，能不能在老板问你“这个能做到什么程度”时给出一个不是猜的答案。等着工作把知识喂到嘴边的人，永远只能在被分配的范围里做判断。
三年之后
写到这里，我想把前面这些拧成几条我确实认下来的东西。
第一，预期落空未必是坏事，但你得知道它落空了。 我入职前想象的是迭代式工作，拿到的是开拓式工作。如果我一直拿着旧的期待去衡量新的处境，这一年会过得很别扭。
第二，一个组织的正确决定，可以对你个人不划算。 别在这两件事之间找统一，承认它们分属两套坐标系，反而更好过。
第三，判断力要变成证据才有用。 我在那次失败里最大的损失不是时间，是我有一个正确的直觉却没能把它说清楚。
第四，不可解释性是这份工作的底色。 数据很好但训崩了，一个 case 今天对明天错，产品同学根本无从判断模型的上限在哪——这些不是异常，是常态。能在这种状态下继续做决策、继续交付，是这行的核心能力。
第五，具体的技术在折旧，对模型和数据的判断力在增值。 三年三个模态，能跟着我走的是后者。
第六，立规范比出结果更耐久。 我训过的模型大多已经被替换掉了，但那套从事故里长出来的稳定性规范还在被用。
现在我到了新的城市、新的公司、新的业务。我没有什么宏大的计划。眼下就是先把新环境的业务优先级看清楚，搞明白这里真正在意什么，然后再谈别的。三年前我以为职业发展是一条能规划的曲线，现在我更倾向于认为，它是一连串“在信息不全的时候做出选择，然后为这个选择负责”的过程。
这三年我有做成的事：一套还在用的工程规范、一条我从训练走到部署的链路、三次从零进入一个新模态并吃到红利。也有没做成的：一个训了很久最后失败的架构，一些我判断对了但没能说服别人的时刻，还有那些被开源追上、然后被替换掉的工作。
这两类事现在我放在一起看，不怎么分高下。因为它们指向同一个能力：在没有人能给你确定答案的领域里，继续做判断，继续交付。