AI 正悄然重构职能边界，上下文决定论

我没做过后端，但线上跑着的一部分服务是我搭的，运维和 CI 也是。

三年前，这句话大概只有两种解释。要么我在吹牛，要么公司对工程质量不太上心。现在还有第三种，它就是一件已经发生的普通工作。

这让我开始重新看前端、后端、测试、产品经理这些边界。它们当然还在，也仍然有用，但未必还该像过去一样，把一个人能做什么划得那么死。

我并不认同“AI 让人人都能全栈”这种说法。真正变掉的，是支撑岗位边界的一个前提。很多过去只能靠个人慢慢积累的经验，正在被整理成可以交接的上下文。

一、我没有变成后端工程师

AI 出现前，我很少碰后端。它并不神秘，只是这笔时间账当时算不过来。

要做一个后端功能，我得先弄懂开发流程、技术栈和环境，再去撞那些“你不知道自己不知道”的坑。为了做成一件事，可能先花几个月变成另一个职业的人。对大多数具体需求来说，这笔投入并不划算。

现在的起点不一样了。我需要把需求、约束、现有系统和验收标准讲清楚，再和 AI 一起推实现方案。它能生成脚手架、补齐细节、解释报错，也能在我卡住时提供下一步。上线后的结果暂时符合预期，但我仍然需要看代码、补测试、确认风险。

这件事里，我没有突然获得后端工程师的全部经验。我得到的是一份足以完成当前任务的后端上下文。

这个区别，才是我想讨论的核心。

二、“跑通”不再那么稀缺

过去，“我能独立跑通一个后端项目”本身是有效的筛选信号。它不一定说明这个人更聪明，却说明他花过时间，读过文档，踩过坑，也承担过环境和线上问题带来的代价。

今天，更多人能在短时间里得到一个可运行的起点。可运行当然仍有价值，但它不再像以前那样稀缺。它不必然证明一个人能选对问题、守住边界，或者把系统长期维护下去。

筛选点因此开始上移。你能不能发现一件值得解决的事，能不能把它说清楚，能不能判断结果有没有偏离目标。

三、经验被拆成了两层

我最开始说过“经验不重要了”。现在回看，这句话很不严谨。东西做出来以后，怎么判断它对不对，依旧需要经验。

更准确的说法是，经验里有两种成分正在走向不同的命运。

一类经验的反馈很短。代码报错了，页面不对，少处理了一个分支，测试没有通过。这些问题通常能在几分钟到几天内看见结果。AI 很擅长加速这类试错，它把查资料、写样板代码和反复修改的成本压低了。

另一类经验的反馈很长。这个架构两年后会不会难以维护，这个需求上线三个月后有没有人留下来，这笔技术债会在什么时候找上门。这些事要按月甚至按年结算。AI 可以帮你列出风险，却不能替你把时间往前拨，也不能替你承担后果。

测试工作把这种差别看得很清楚。纯执行回归、补用例、重复点选的工作更容易被自动化覆盖；测试开发和质量工程则仍然要设计验证策略、维护测试体系、判断什么风险值得拦住。招聘里，这两类岗位的要求已经越来越不像同一件事。

这不等于“测试要消失”。它更像是测试内部的分工在变。重复执行被工具吃掉了一部分，定义质量、设计验证和对结果负责的工作更显眼了。前端、后端、产品、设计也可能沿着类似的线发生变化，只是速度和位置不会完全一样。

四、经验不能交接，上下文可以

经验长在人的脑子里，通常要靠时间和代价换来。它很难原封不动地交给另一个人，所以会成为简历、职级和招聘里很硬的信号。

上下文不一样。它可以被写下来、讲清楚、做成流程，交给同事，也能交给 AI。AI 不能凭空创造经验。它能把其中一部分拆出来，变成别人也能使用的上下文。

我做 CI 时，亲眼看过这个过程。第一版已经能跑，但每次都要去 GitHub 手动触发。后来构建环节多了，手工步骤跟着增多。我先用 AI 做了一个运维网页，把操作收进界面；再往后，我觉得连点网页都麻烦，于是把它收成 CLI 和 Skill。

到这一步，使用工具的人不需要了解每一个运维细节，也能完成原本很繁琐的构建部署。我脑子里那点零散知识，被整理成了团队可以调用的东西。

过去，岗位常常按“谁具备哪种经验”来切分。因为跨到另一个岗位，意味着重新积累一遍经验。现在，这个前提开始松动。组织边界不会因此立刻消失，但它们需要重新回答一个问题。哪些事情必须由特定角色承担，哪些事情应该尽快被沉淀下来，让更多人能安全地完成。

五、用上下文重新看岗位

“上下文”是个很容易说空的词。回头看我搭后端的过程，我觉得至少可以分成四层。

目标上下文回答的是。这件事为什么要做，做成什么样才算成功。

领域上下文包括业务规则、约束、行话和历史包袱。

实现上下文是技术上的可选方案，以及各自要付出的代价。

验证上下文则是。怎么知道它做对了，什么情况算错，出了问题由谁承担。

在那次后端工作里，AI 能承担很多实现上下文，也能帮我查一部分领域资料。但目标和验证始终要我来给。AI 不知道我们为什么做这件事，也不知道“可以上线”在这个团队里究竟意味着什么。

这提供了一把不那么舒服、但挺实用的尺子。一个岗位越依赖实现上下文，越容易被工具重新分配；越靠近目标、验证和责任，变化就越慢，也越需要人来承担。

这不是说实现不重要。实现仍然决定系统是否可靠，只是过去由一个角色独占的实现能力，正在更容易被拆开、复用和协作。

上下文也不等于新的个人护城河。它一旦被整理出来，别人同样可以获得。可这恰好让它有机会成为组织资产。与此同时，一个人能真正持有的上下文仍然有限，更多取决于注意力、判断力和愿意为结果承担多少责任。

六、组织可能会怎么变

下面都是推演，不是预言。我还没见过一个完全按上下文运转的成熟组织，只能从眼前的变化往外想。

第一，边界可能更常跟着业务问题走，而不是技术层走。

今天，一个支付功能往往要穿过前端、后端、测试几层，再经过几次交接。但支付的上下文本来是一块。为什么这样设计，哪些地方不能错，失败时用户和商家分别会遇到什么。把它横向拆开以后，团队再靠会议和文档把它拼回去，交接处很容易损失信息。

当实现不再是唯一瓶颈，一个人或一小组端到端负责一个问题域会更自然。支付从需求到界面、服务和监控，未必由一个“全能的人”完成，但最好有人持续持有这块问题的上下文。康威定律提醒我们，组织结构和系统结构始终互相塑形。以后，问题本身的结构可能会更直接地影响团队怎么切分。

第二，会有更多人专门把上下文做成工具。

我私下把这件事叫作“勤于偷懒”。开发里总有重复、别扭、用起来不顺手的地方。以前不少人会忍过去，因为改造它的成本比忍受它还高。AI 把改造的门槛压下来以后，这笔账开始变化。

但把手工操作做成网页、CLI 或 Skill，不只是少点几下鼠标。它是在把某个人脑子里的做法，搬到团队可以重复使用的地方。平台工程、开发者体验、内部工具这些工作，可能会更接近这个角色，只是它还没有一个很稳定的名字。

第三，招聘和个人的职业动作都会调整。

“你会什么技术栈”“做过几年”不会马上退出面试，但问题也许会慢慢变成。你熟悉哪些问题域？面对陌生领域时，你多久能建立起足够的上下文？你怎样验证自己没有理解错？

对个人来说，单纯把一个技能栈挖得更深，未必像过去那么安全。更值得投资的方向，要么是靠近目标，能定义问题；要么是在一个领域里待得足够深，知道那些文档里没有写的约束。前者决定往哪里走，后者决定路会不会走偏。

最后，责任仍然会是一条硬边界。

上下文可以共享、流动，也能被调用。责任不能。人人都能把东西做出来时，组织还是要有人回答。这件事出了问题，谁负责判断，谁负责收场。执行边界可能变得模糊，责任边界反而会更清楚。

七、这套说法哪里站不住

我看到的变化来自创业公司，这本身就有偏差。创业公司人少，一人多岗本来就是常态。边界模糊里，有多少来自 AI，有多少只是因为没有足够的人手，我分不干净。

大公司的情况也未必一样。责任划分越严格，故障越需要明确归属，岗位边界可能越硬。跨界做事出了问题算谁的，在大公司里比在小团队里难回答得多。所以这种变化更可能先在小团队里出现，再慢慢渗透到更复杂的组织。

我也还没真正翻过车。我用 AI 搭的那些东西上线后暂时符合预期，没出过大的问题。但这也可能只是时间不够长、规模不够大。长反馈周期的账，只能等它真的来结。

“上下文决定论”也有够不到的地方。有些能力更接近品味，例如设计师一眼看出 AI 生成内容哪里别扭，这类判断很难完整写成规则。还有很多重要的上下文是隐性的。谁真正拍板，上次方案为什么没过，客户嘴上说的和实际在意的差多少。这些东西不在文档里，只能靠在场和时间慢慢知道。

最后，制度通常比能力变化得慢。即使工作已经融合，招聘、职级、薪酬、绩效和法律责任也不会同步重写。短期里更常见的画面，可能是岗位名称没变，JD 已经膨胀，一个人做的事更多，评价和回报却还是旧标准。

最后

回到开头那句话。我没做过后端，但线上跑着一部分我搭的后端。

这不说明后端经验已经作废，也不说明跨界天然是好事。它只说明，一部分过去必须个人背着走的东西，现在可以被写成上下文、做成工具，再交给别人使用。

职业上的问题也随之变了。以前更常问“你会不会做”。以后也许更常要回答“这件事为什么该做，怎样才算做对，以及出了问题谁愿意负责”。

AI 能帮人越过不少实现上的门槛。门槛后面那部分判断，暂时还得自己长出来。