先说一个我自己实习时候的真实观察。

同一批进去的实习生，半年后水平拉开的差距远比想象中大。但拉开差距的，往往不是谁拿到的需求更"高大上"，而是谁更愿意在边缘活里多问一句"为什么"。

那些拿到核心需求的人，大概率会做得不错，因为有人带、有压力、有反馈，不进步都难。真正决定上限的，反而是中间夹着的那些"杂活"——一个权限模块的小改造、一段 session 逻辑的兜底、一次老接口的迁移、一个临时的脚本任务。这些东西没人盯着你做得多好，做完就过了，做砸了也没人记得。

但恰恰因为没人盯，反而是最适合你"夹带私货"地思考的时机。

我自己几段实习里大部分时间都在做 core work——AI 应用、RAG、Agent 链路这类听起来比较"光鲜"的内容。但中间也穿插过不少 dirty work，权限改造、session 隔离、老接口适配、给传统模块判断要不要 AI 化等等。事后回看，那些 dirty work 给我的认知增量，反而比单纯堆 RAG 多得多。

这篇文章想聊三件事：第一，为什么 dirty work 反而是成长红利；第二，怎么从 dirty work 里挖出真正有价值的思考；第三，怎么把这些思考体面地放到简历和面试里。

一、先纠正一个认知偏差：Dirty Work 不是"低价值工作"

很多人一听到"杂活""边缘工作"，下意识反应就是"这不是我该做的""学不到东西""浪费时间"。

这个判断本身就是错的。

Dirty work 之所以叫 dirty work，不是因为它价值低，而是因为它的价值不显性。

核心需求的价值是显性的——做完一个新功能、上线一个新模块，PM 看得到、leader 看得到、绩效评估看得到。所以核心需求是"自带光环"的工作，你做得好不好，市场会自动给你定价。

但 dirty work 的价值是隐性的。一个权限模块改得干不干净、一段 session 逻辑兜得严不严、一次部署脚本写得鲁不鲁棒，这些东西大部分时候没人会专门夸你，但它们直接决定了系统的健壮性。显性价值靠产出衡量，隐性价值靠"不出事"衡量——而后者的门槛其实更高。

更关键的一点是，dirty work 几乎都处在系统的"接缝处"。

什么叫接缝处？就是两个模块、两套逻辑、两种角色之间衔接的地方。权限是用户和资源之间的接缝，session 是请求和状态之间的接缝，部署是代码和环境之间的接缝，数据迁移是新老系统之间的接缝。真正复杂的工程问题，大部分都发生在接缝处，而不是模块内部。

而你在 core work 里做的事情，往往是在某个模块"内部"——把一个功能写好、把一个链路跑通。这当然有价值，但它训练的是"局部能力"。Dirty work 训练的是"全局视角"，因为你必须搞清楚两边发生了什么，才能把接缝处理好。

这也是为什么我反复强调：Core work 决定你的下限，dirty work 决定你的上限。

二、Dirty Work 的真正价值：让你被动接触系统全貌

讲一个我自己的经历，脱敏处理过。

某次实习中间有一周需求比较空，leader 让我顺手处理一个权限相关的小改造——大概是某类用户在某些场景下要看到不同的资源，原本的权限判断逻辑要加一个维度。听起来就是一个 if 加几行代码的事。

我一开始也是这么以为的。但真要动手的时候才发现，事情没这么简单。

这个系统里"权限"不是一个集中的概念，而是散落在好几个地方：网关层有一层粗粒度的鉴权，业务层有基于角色的判断，数据层还有行级别的过滤。我要加的这个维度，到底应该加在哪一层？加在网关层最简单，但会污染网关的通用性；加在业务层最贴近场景，但容易和已有的角色逻辑耦合；加在数据层最干净，但性能上要付代价。

为了搞清楚怎么加最合理，我被迫把整个系统的权限模型梳理了一遍。而梳理这一遍带来的收益，远远超过这个小需求本身。

我第一次真正理解了：为什么很多系统的权限会越改越烂。不是因为开发能力差，而是因为权限这个东西天然处在多个抽象层级之间，每一层都有自己的判断逻辑，如果没有一个统一的视角去管它，每次加新需求都会就近找一个地方塞进去，久而久之就成了一团乱麻。

我也第一次意识到：**权限的本质是"解耦"，不是"判断"。**好的权限设计不是写一堆复杂的 if-else，而是把"谁""能做什么""对哪些资源"这三件事拆得足够清晰，让它们可以独立演化。RBAC、ABAC 这些模型为什么会演化出来，不是为了好看，是为了在不同的解耦诉求下提供不同的抽象。

最后我提交的方案是把这个新维度抽象成一个独立的策略对象，挂在业务层的权限判断器上，不污染网关，也不下沉到数据层。代码改动不多，但 leader 在 review 的时候多看了两眼，说了一句"这个抽象不错"。

这件事对我的真正价值，不是改完了这个小需求，而是让我从一个"功能开发者"的视角，被动地切换到了"系统设计者"的视角。这种视角的切换，是 core work 给不了的——因为 core work 里你的注意力都在"把功能做出来"上，没空抬头看全局。

类似的事情还发生在 session 隔离上。

某个项目里有一段时间出现了诡异的 bug——某些用户偶发地拿到了别人的上下文。线上不严重，但确实存在。leader 让我去看一下。

这种问题就是典型的 dirty work：没成就感、不出新功能、查起来全靠耐心。但我接下来花了两天时间排查，过程中真正吃透了一件事：session 隔离不是一个点，是一条链。

从前端的 token、网关的请求标识、服务内部的 ThreadLocal、异步任务里的上下文传递、缓存键的设计、数据库连接池的复用，每一个环节都可能成为隔离的破口。这条链上但凡有一个地方写错——比如异步任务里没把 traceId 透传过去、缓存键没带租户维度——隔离就会出问题。

最后定位到的根因是一个异步线程池里的上下文没有正确传递。修复本身只是几行代码，但我借这个机会把整条链路画了一遍，记在了自己的笔记里。后来面试被问到"分布式系统里怎么保证多租户隔离"，我能从前到后讲一整条链，面试官明显愿意往下问。

这就是 dirty work 的隐藏红利：它逼着你接触系统的全貌，而不是只盯着某个模块。

三、方法论：怎么从 Dirty Work 里挖出真正的价值

讲完两个例子，回到方法论本身。Dirty work 不会自动产生价值，它需要你主动"加工"。我总结下来有四个动作。

第一个动作：每个 dirty work 都先问"这件事在更大的系统里是什么位置"。

接到一个杂活，先别急着动手。花十分钟搞清楚两件事——这个改动会影响什么，以及它为什么存在。

以权限改造为例，"影响什么"会让你意识到这个改动会触及哪些模块，从而被动去看那些模块的设计。"为什么存在"会让你理解这个需求背后的真实业务诉求，而不是表面上的"加一个判断"。前者训练系统视野，后者训练业务理解，两个加起来就是 senior 工程师和 junior 工程师的核心区别。

第二个动作：在 dirty work 里强行加一个"思考维度"。

什么意思？就是哪怕你做的是 CRUD，也要在做的过程中给自己加一个超出 CRUD 本身的问题。

比如做一个权限相关的 CRUD，可以问：如果用户量翻一百倍，这个判断逻辑会成为瓶颈吗？如果加缓存，应该缓存什么粒度？缓存失效策略怎么设计？

比如做一个 session 相关的小改动，可以问：如果这个服务部署成多实例，session 怎么共享？如果某天要做灰度发布，session 会不会跨版本错乱？

比如做一次部署或者环境配置（即使你不是专职运维），可以问：这个配置如果错了，最快多久能发现？回滚成本是多少？有没有更稳的发布方式？

这些问题不一定要在当下解决，但在做 dirty work 的时候顺手想一遍，等于免费给自己上了一节系统课。后面遇到真正大流量、真正复杂的项目，这些问题会反复出现，你已经提前想过的部分，就是你的护城河。

第三个动作：把 dirty work 的思考记下来，越细越好。

这一条听起来很俗，但太多人没做。

我自己的习惯是每完成一个 dirty work，花十五分钟写一段笔记，结构很简单：原始需求是什么、我做了什么、过程中遇到了哪些超出原始需求的问题、我当时怎么权衡的、如果重来会怎么改。

这些笔记的价值不在当下，而在三个月后写简历、半年后面试的时候。人的记忆是不可靠的，三个月前你做的那个权限改造，到了面试现场你只能讲出"加了个判断"，但你的笔记可以让你讲出"我意识到权限本质是解耦问题，所以我把新维度抽象成了独立策略对象"——这两个表达的差距，就是 offer 和拒信的差距。

第四个动作：主动找 dirty work 之间的"共性"。

做得多了你会发现，看似不相关的 dirty work 之间其实有底层共性。

权限和 session 都是"上下文管理"问题；部署和数据迁移都是"状态切换"问题；缓存和异步都是"一致性"问题。当你能从十几个具体的 dirty work 里抽象出三五个底层主题，你就从"做过很多杂事"升级成了"理解系统的工程师"。

这种抽象能力是面试官非常看重的，因为它意味着你下次遇到一个新问题，能快速类比已有的解法，而不是从零开始摸。

四、一个进阶视角：用 dirty work 训练你的"AI 化判断力"

这个话题我单独拎出来讲，因为它特别适合现在这个阶段的 AI 应用开发岗。

现在很多公司都在喊"传统业务 AI 化"，这件事听起来很美好，但实际落地的时候坑非常多。而真正能判断"哪些场景适合 AI 化、哪些不适合"的人，往往就是那些做过足够多 dirty work、对系统全貌足够熟悉的人。

为什么？因为判断一个场景适不适合 AI 化，本质上要回答几个问题：

这个场景的核心痛点是不是"自然语言理解"或者"生成"？如果不是，AI 化大概率是为了用 AI 而用 AI。比如一个内部财务对账系统，痛点是规则复杂、容易错算，这种场景上 LLM 反而引入了幻觉风险，远不如把规则引擎做扎实。

这个场景能不能容忍 AI 的不确定性？如果场景对结果的确定性要求极高——比如计费、对账、合规审核——那 LLM 的幻觉就是致命缺陷。这种场景要么不上 AI，要么必须配一套严格的校验和兜底机制，而且整体的 ROI 大概率不划算。

这个场景的数据敏感度有多高？医疗核心数据、金融交易明细、企业内部 IP 类信息，这些场景如果要 AI 化，意味着要么自己部署私有模型（成本极高），要么走严格的脱敏链路（信息损耗大）。很多公司喊着要 AI 化，真到了数据合规这关就走不下去。

这个场景的实时性要求和成本结构对得上吗？LLM 推理是有延迟和成本的。如果一个接口要求 50ms 内返回、QPS 上千，你硬塞一个 LLM 进去，要么响应崩、要么账单崩。这种场景下传统方案 + AI 离线增强可能才是合理路径。

我自己在实习里遇到过一个小例子，脱敏讲一下。某个模块原本是基于规则的，业务方希望"AI 化"。我接到的任务其实只是一个很小的接口调整，但我顺手把这个模块的调用量、响应时间、规则复杂度梳理了一遍，发现规则其实只有几十条、调用量极高、对延迟敏感。我把这个观察反馈给了 leader，最后这个模块没有 AI 化，而是做了规则引擎优化。

这件事让我意识到："判断不该 AI 化"和"判断该 AI 化"，是同一种能力的两面。而这种能力，在面试 AI 应用开发岗的时候非常稀缺——大部分候选人只会喊"用 LLM 解决一切"，而能冷静说出"这个场景不适合 AI"的人，反而显得更可信。

所以如果你正在做的 dirty work 涉及到老业务、老模块、老接口，不要嫌弃它"传统"——它正是训练你 AI 化判断力的最佳素材。

五、怎么把 Dirty Work 体面地放到简历和面试里

这一节是最实操的部分。前面讲了那么多，最终都要落到"怎么让别人看到你的成长"上。

第一个原则：永远不要直接写你做了什么 dirty work，要写你从 dirty work 里抽象出了什么。

举个反面例子。如果你简历上写"参与权限模块改造，新增了 XX 维度的判断逻辑"，HR 和面试官看完的第一反应是"哦，CRUD"，下一秒就翻页了。

正面写法是："基于业务对多维度权限的诉求，重构了原有权限判断链路，将判断维度从硬编码改为可扩展的策略对象，降低了后续新增维度的耦合成本。"

注意这两种写法描述的是同一件事，但传递的信号完全不同。前者是"我执行了一个需求"，后者是"我识别了一个系统问题并给出了设计方案"。简历的本质是信号传递，同一件事可以传递不同的信号，取决于你怎么讲。

第二个原则：用"问题—权衡—方案"的结构讲，而不是用"做了什么"的结构讲。

junior 选手的简历常见结构是："做了 A，做了 B，做了 C。"

senior 选手的简历结构是："识别了 X 问题，权衡了 Y 和 Z 两种方案，最终选择了 Y，因为它在 P 上更好，代价是 Q。"

后者贵的不是字数，是思考密度。面试官看一个候选人，本质上是在判断"这个人遇到新问题能不能想清楚"，而你简历上展示的思考结构，就是最直接的证据。

以 session 隔离那个例子来说，可以写成："排查多租户场景下偶发的上下文串扰问题，定位到异步任务上下文传递缺失的根因。考虑到全量改造成本高，最终采用了在线程池包装层透传上下文的方案，将影响范围控制在框架层，未侵入业务代码。"

这一句话里包含了"问题—根因—权衡—方案—范围控制"五个要素，但读起来并不长。这就是密度。

第三个原则：dirty work 的最大价值是"系统视角"，简历上要主动展示这一点。

如果一段实习里你接触过权限、session、部署、迁移等好几类 dirty work，可以在简历上专门加一句类似"在参与核心业务开发的同时，深入梳理了 XX 系统的权限模型、上下文隔离链路、部署流程，对系统整体设计有完整理解"的概括性表达。

这句话单看很虚，但配合下面几个具体例子的支撑，效果会非常好——它告诉面试官：这个人不是只懂自己那一亩三分地，他能看到全局。

第四个原则：面试讲 dirty work 时，主动"升维"。

面试官问你"你在实习里做过什么"，你直接讲那个权限改造，他大概率不会追问。但如果你这样讲：

"我做过一个看起来是 CRUD 的权限改造，但做的过程中我意识到权限本质是个解耦问题，所以我把整个系统的权限模型梳理了一遍，重新设计了判断链路……"

面试官会立刻坐直，因为他听到了两个关键信号：第一你有抽象能力，第二你愿意超出需求本身去思考。这种信号在 junior 候选人里极其稀缺，稀缺到只要你展示出来，offer 的概率就会显著上升。

讲 dirty work 的时候，主动从"我做了什么"升维到"我看到了什么""我想到了什么""我学到了什么"，是最划算的面试技巧之一。

六、最后

回到标题——Dirty work 也能发光。

但我要把这句话补完整：Dirty work 不会自己发光，是带着思考的人让它发光。

同样一个权限 CRUD，有人做完就忘了，有人借它理解了整个系统的解耦哲学；同样一次部署配置，有人改完就过了，有人借它想清楚了高可用的边界条件；同样一段老接口适配，有人当成苦活，有人当成判断"该不该 AI 化"的真实样本。

差别从来不在工作本身，而在做工作的人有没有意识——意识到每一个边缘活其实都是窥探系统全貌的一扇小窗，意识到每一次"杂事"都是一次免费的认知升级机会，意识到你今天多想的那一层，三个月后就是简历上多一行有分量的描述。

最后一句话送给现在还在做着 dirty work、又有点不甘心的你：

别嫌它脏，它是你目前为止性价比最高的成长入口。

共勉。