几周前，我写过一篇关于 human in the loop（人类在环） 的文章，讨论为什么如今在软件开发中，审查（review） 正在成为新的瓶颈。随后，我又写了一篇，探讨这对职业发展，以及对那些正准备进入这个行业的学生来说意味着什么。
但在后续交流中，有一个问题反复被提起：这对组织意味着什么？ 不是创业公司。不是科技公司。是企业。那些依赖软件运转、却并不把自己视为软件公司的银行、保险公司、制造企业和零售企业。
旧模式正在失效
一家区域性大型银行曾花了数月时间权衡：是自建一个新的支付对账系统，还是采购现成方案。利益相关方反复摇摆，始终无法做出明确决策。与此同时，一次处理错误迟迟未被发现，导致数千笔企业交易延误，引发了 200 万美元的监管罚款，并带来了持续数周的负面新闻。把这种决策做错，代价绝不仅仅是“在供应商身上多花钱”这么简单；它关乎风险、声誉，以及真实的运营痛点。
几十年来，企业在构建软件时基本只有两种选择：
自己做。 招一支团队，管理他们，还要祈祷他们别离职。成本高、速度慢、风险大。通常只适用于核心系统。
购买或外包。 通用需求用 SaaS；定制需求交给埃森哲（Accenture）或德勤（Deloitte）这类咨询公司。你签下一份大合同，对方派来一批人，十八个月之后，你会拿到一个“差不多能用”的东西。
这两种方式其实都谈不上理想。自建对大多数需求来说都太贵。采购则意味着你不得不围着那些并不完全匹配的软件来调整流程。外包则意味着你按高级工程师的费率付钱，却常常得到初级开发者的产出；而项目一结束，那些知识也随之流失。
AI 正在打破这个模型。
但方式并不是你想的那样。
AI 真正改变了什么
现在的讨论焦点往往是： “AI 现在会写代码了。”
这没错，但这并不完整。
Gergely Orosz 最近写过一篇文章，讨论当 AI 几乎写了所有代码之后会发生什么。他的结论是：软件工程师的价值不会降低，反而会更高。 但工作的性质会改变。Tech Lead 的特质会变得更抢手。在创业公司里，“具备产品思维”会从加分项变成基本要求。市场真正更需要的，将不是单纯的“coder（写代码的人）”，而是扎实的软件工程师。
AI 真正改变的是：实现的经济性。
把一个定义清晰的需求转化成可运行代码，这件事的成本已经断崖式下降。正如 Vercel CTO Malte Ubl 所说： “软件生产的成本正在趋近于零。” 过去需要一整个开发团队花几周完成的事情，现在可能几小时就够了。
但有一件事并没有改变：
仍然需要有人判断实现是否正确。
仍然需要有人足够理解业务问题，才能把需求定义清楚。
仍然需要有人在业务演进时继续维护这个系统。
瓶颈已经从编码，转移到了判断。
新的格局
我看到市场正在分化为三个层级，每个层级都有完全不同的需求。
这与 Gergely Orosz 关于科技行业三模态薪酬结构（trimodal nature of tech compensation）的研究相呼应。他指出，软件工程薪酬并不是一条单峰钟形曲线，而是三个彼此区隔的市场：顶部是大厂和顶级 scaleup，中间是那些在全球范围争夺人才的公司，底部则是所有主要在本地市场竞争的企业。每个层级都有不同的薪酬水平、不同的期望值，以及不同的工作方式。
但真正发生变化的是：这三个层级虽然以前就存在，但它们做的工作在本质上是相似的。你可以先在一家区域性银行担任 Software Engineer（SWE），然后去应聘科技巨头的岗位，而且真的有机会拿到 offer。因为在这两类公司里，你做的事情都差不多：写代码、Review PR、排查线上问题。技能是可迁移的。你可以在不同层级之间流动：先在本地公司积累几年经验，再跳去科技公司，之后也许为了工作生活平衡再回到企业。那条职业阶梯是可以往上爬的。
AI 正在打破这一点。
当实现成本变得极低，而判断变成瓶颈之后，这三个层级之间的差异就不再只是薪酬差异，而是工作的本质本身开始分化。每个层级真正需要的技能，正在变得越来越不同。这将直接影响职业流动性、人才供给管道，以及组织如何思考“该怎样构建软件”。
未来，这三个层级的区别将不只是收入高低。
它们会在软件如何被构建、由谁构建，以及什么技能最重要这几个方面，彻底走向不同。
第一层：科技公司与数字原生巨头
在这类组织里，软件本身就是产品。它们拥有平台工程团队、SRE 团队，以及深厚的内部技术积累。它们在超大规模上构建系统，并引领整个行业的实践方式。它们直接与上游供应商和开源项目协作，有时甚至会雇佣核心维护者，或者资助它们所依赖工具的开发。对于那些自己不想亲自构建或维护的关键基础设施，它们通常会与最懂这项技术的专业厂商签订支持合同和许可证协议。
这类组织需要的是：能够审查 AI 生成代码、并发现那些“测试能过、但在大规模场景下会出问题”的微妙 bug 的资深工程师。 在这里，AI 是生产力放大器，而不是替代品。同一支团队能交付得更多，但团队依然是人类主导、依然资深、依然承担责任。
例子：
Maria 是一家大型电商平台的高级 SWE。她所在团队负责运行结账系统，这个系统每天要处理数百万笔交易。当她需要优化支付流程时，她会让 Claude Code 生成实现代码，但她大部分时间其实花在审查这些改动是否能撑住“黑色星期五”的流量冲击。她理解分布式系统、延迟要求以及各种故障模式。当她在某个核心库上遇到性能瓶颈时，她会直接去上游提 issue，甚至亲自提交修复。对于技术栈中那些团队不想亲自持有的部分，他们会与供应商签订企业级支持合同。AI 写代码，Maria 决定这是不是“正确的代码”。
第二层：大型企业
比如银行、保险公司、大型零售商、电信公司。对它们来说，软件对业务至关重要，但软件并不是它们的核心产品。它们拥有不小的工程组织，但在争夺人才时，它们是在和第一层公司竞争，而且往往处于下风。
这类组织无法像科技公司那样构建同等水准的内部平台。它们也招不到足够多的资深工程师来覆盖所有需求。但它们依然需要安全地交付软件，也依然需要判断力。
这恰恰是变化最剧烈的地方。
这类组织将越来越依赖那些能提供合理默认值和内建防护栏（guardrails）的平台。与此同时，当它们内部缺乏某种关键判断能力时，它们会引入分数式的资深外部专家。
例子：
James 在一家大型保险公司工作。他属于一个大约 200 人规模的 IT 组织，但他们不是 Stripe。他们正在用 AI 辅助开发一个新的理赔处理系统，代码产出速度非常快。他们选用的平台负责部署、可观测性和性能监控，为他们提供了自己无力构建的防护栏。当他们在“是否用事件溯源来满足审计追踪”这件事上要做架构决策时，他们会请来一位fractional consultant（分数式顾问） ，用几天时间帮他们审查方案，并指出那些他们尚未意识到的风险点。
第三层：中型市场与小型企业
本地制造企业需要生产追踪系统。
餐厅需要预订系统。
会计事务所需要客户门户。
这些企业过去根本负担不起定制软件。现在，它们负担得起了。
但它们不会去买企业级平台，也不会去请大型咨询公司。它们会去找本地的软件开发者，就像找水管工一样。
这是一个完全不同的市场，我后面还会再回来讲。
例子：
Sofia 经营着一家小型软件咨询公司。她的客户都是本地企业：一家制造企业需要生产质量追踪系统；一组牙科诊所希望有共享的患者排班系统；一家葡萄酒分销商需要真正符合其业务流程的库存管理系统。这些企业在五年前根本无力承担定制软件的成本。而现在，借助 AI 辅助开发，Sofia 可以在几天内交付一套刚好符合需求的系统。她未必是分布式系统专家，但她非常擅长理解客户真正需要什么，并交付能解决问题的可运行软件。
企业现在应该怎么做
如果你在第一层或第二层组织里负责工程，我认为你需要认真考虑以下几点：
平台工程比以往任何时候都更重要
当 AI 生成代码的速度快到超过人类的理解速度时，平台就成了你的安全网。
现代平台的原则应该是：guardrails over gates（用防护栏替代人为关卡） 。
平台应当自动强制执行标准，并提供可观测性，让你知道生产环境中正在发生什么。它应该让“做对的事”变得容易，让“做错的事”变得困难。
如果你现在还没有平台工程职能，那你需要建立一个。
如果你的规模太小，无法自己搭平台，那你就需要买一个。
SRE 不是不重要了，而是更重要了
更多代码、更快上线，意味着生产环境中可能出错的地方也更多。你的 SRE 会成为最后一道防线，去拦住那些通过 Review 却在生产环境中翻车的 AI 生成代码。
SRE 的角色也会演变：从“维持系统运行”，变成“发现 Review 漏掉的问题”。他们不仅要懂运维，还要理解代码背后的业务逻辑。
人才管道问题是真实存在的
如果那种“Jira 工单做到下班”的开发者角色已经消失了，那你未来的资深工程师从哪里来？
我们来简单算一笔账：假设你有一个 200 人的工程团队，每年流失 5 名资深工程师，却只能内部晋升出 3 名。如果你彻底停止招初级工程师，那每年就会净缺口 2 名资深工程师，而且未来也没有新鲜血液可以补上。这个缺口持续几年之后，组织的专业能力流失速度就会远远快于补充速度。
你不能简单地停止招聘初级工程师。
从长期来看，数学上就不成立。
但你也不能继续像过去那样招初级工程师，然后指望他们通过做那些现在已经被 AI 接管的 ticket 来学会判断。
实习变得至关重要。
必须让他们真正接触真实系统、真实后果。
必须让他们跟资深工程师一起做 Review，而不仅仅是做实现。
必须训练他们去问： “这样做对吗？” 而不只是 “这样能跑吗？”
有些组织会选择从科技公司高价挖资深工程师。这很贵，而且还会带来新的文化问题。另一些组织则会与外部公司合作，由后者提供资深判断力。关键在于：你必须认识到，判断力总得有来源。
咨询模式正在改变
旧的咨询模式，本质上就是“人头外包”。你为实现工时付费，计费标准按资深专家算，但最终交付出来的往往只是初级开发者水平的工作。
这个模式正在消亡。
因为 AI 现在已经可以完成“实现”这部分工作了。
新的模式将变成：分数式的资深判断力。
你不再需要二十个开发者持续干十八个月。你需要的是一位资深架构师，每周两天，专门提供判断力，审查你内部团队和 AI 一起产出的东西，并帮助你避开架构性错误。
价值主张已经反过来了。
你付费不再是为了“实现所花的时间”，而是为了“判断的质量”。
重新思考：什么该定制，什么该商品化
这正是 AI 改变 buy-vs-build 计算方式的地方。
过去，定制软件太贵，所以你只会为真正的业务差异化能力去做自建。其余一切，你都买 SaaS，然后围绕其局限去妥协。
而现在，定制软件的构建成本已经大幅下降。
很多以前“不值得做”的东西，现在开始变得可行：
那些原本需要专门咨询项目才能做的集成；
那些从来排不上优先级的内部工具；
以及那些真正符合你组织独特工作方式的流程自动化。
当然，“更便宜”并不意味着每个想法都值得定制。这里有一个快速判断清单，用来检验一个项目是否真的“值得做定制”：
这个流程是否能给你的组织带来竞争优势，或者它是否是你交付价值的核心？
现成的 SaaS 或通用产品，是否无法在不产生不可接受妥协的情况下满足你的独特需求？
这个工具是否需要随着你的业务变化而持续演进，或者它是否能帮助你长期保持灵活性？
如果这三条里有两条以上回答是“是”，那它大概率就是一个不错的定制软件候选项。
否则，你就应该认真想想：一个经过适配的现成方案，是否已经能满足你 80% 的需求，而不必投入额外成本。
但“更便宜”不等于“免费”。
你仍然需要判断力，来决定该构建什么；
仍然需要 Review，来确保它被正确构建；
仍然需要维护，当需求变化时继续演化它。
问题已经从：
“我们是否负担得起去构建它？”
变成了：
“我们是否拥有足够的判断力，能把它构建好，并长期维护好？”
而要真正提升决策水平，这不仅仅是成本或能力问题，而是要识别：定制软件究竟在哪些地方能为你的业务创造不公平优势。 最有战略眼光的领导者会问的是：
“在哪些环节，定制软件能让我们做到竞争对手做不到的事情？”
第三层机会
小企业市场是完全不同的，但它非常重要。
几十年来，定制软件一直是大公司的专属。小企业只能使用现成产品，并围绕它们的限制打补丁。或者干脆什么都不用。
AI 改变了这一点。
一个技术过硬的开发者，加上 AI 辅助，现在已经可以在一个小企业能够接受的价格区间内，构建定制软件。
想想过去那些小企业高度依赖的 WordPress、Joomla 定制化工作。现在，把这件事扩展到真正的定制应用上。扩展到那些没有任何 SaaS 会去解决的问题上——因为市场太小，不值得有人专门做一个产品。
这催生出了一种新角色：software plumber（软件水管工） 。
他们是服务本地企业的本地开发者。
他们理解具体业务环境，能够把需求翻译成软件要求，并且当系统出问题时，他们就在附近、能马上处理。
这套技能和企业级工程并不相同。
它更少要求你懂分布式系统和超大规模架构，更多要求你懂业务问题，并能快速交付可运行的解决方案。
但这依然是真正的软件工作，而且它会成为一个不断增长的市场。
这对你的组织意味着什么
软件工程的未来，并不是“AI 取代开发者”。
事情远比这更微妙。
企业现在必须把重点放在以下几件事上：
- 培养有经验的工程人才；
- 优先建设适合 AI 辅助开发的稳健平台与防护栏；
- 将咨询模式从传统“人头外包”转向“分数式资深判断力”。
成功将取决于：
你是否能在团队中建立可靠的判断力；
是否能让 SRE 补上 AI 生成代码中的缺口；
以及是否能有意识地培养下一代资深工程师。
如果你正在领导一家企业的工程团队，你现在应该问自己的问题是：
我们是否还在为那些其实已经可以自己定制构建的东西继续购买 SaaS？
我们是否拥有足够的平台和防护栏，来安全地交付 AI 辅助生成的代码？
当我们需要外部帮助时，我们到底是在为“实现”付费，还是在为“判断”付费？
我们是否拥有足够的资深能力，来审查 AI 生成的内容？
我们未来的资深工程师，将从哪里来？
human in the loop（人类在环）并不会消失。
恰恰相反，工具越强大，人类就越重要。
但问题在于：
哪些人，做什么样的工作，在什么支持体系下工作？
这才是真正发生变化的地方。
而这，也是企业现在必须想明白的事。
