最近，我经常在时间线上看到"外包开发已死"这句话。讨论的背景通常是：AI 让软件开发变得更快、更便宜，因此"按客户要求构建并交付"的传统模式正在迅速失去价值。
起初，我确实以为："这不过是又一个'X 已死'的炒作周期吧？"
毕竟，几十年来一直有人喊"外包开发已死"，甚至在 AI 出现之前也是如此。自研开发、云计算、多层分包、离岸外包——每次都说"这次真的要死了"，可外包开发却像僵尸一样活了下来。
其实，我长期在产品公司工作，所以以前只是旁观这些话题。我记得当时觉得外包开发看起来很难，是我避之不及的东西。
然后，三年前我加入了 Hololab Inc.，现在正身处客户工作的一线，包括外包开发。老实说，入职时，"外包开发"这个词让我犹豫过。不过，新技术带来的变革挑战和公司本身的吸引力最终还是占了上风。我想，没亲自试过就抱怨"外包开发"也太没意思了。
从那以后，三年过去了。我进入了管理层，直面了外包开发。所以这次，我想直面"外包开发已死"这句话，不再逃避。
"外包开发已死"是真的吗？
是真的。
即使在 AI 出现之前，DX（数字化转型）背景下就出现了无代码运动，以及自研开发的趋势。然后 AI（尤其是 AI Agent）浪潮来了，这个趋势瞬间加剧。现在连非工程师也能创建软件了。
每当这个话题出现，以此为生的工程师往往会拿"质量"或"安全"说事，争辩说"软件开发没那么简单"。
然而，软件所需的质量因用途和使用场景而异。面向客户或生产环境的软件需要一定的服务水平。而内部工具或 PoC（概念验证）所需的质量通常较低。而这正是容易被 AI Agent 替代的领域——或者说，替代已经开始。
关于安全性和质量，我觉得随着模型演进和人类对 AI 运用知识的积累，差距每年都在缩小。就在两三年前，主流观点还是"AI 可以辅助，但让 AI 写代码为时过早"，而现在 AI 写代码已经成了常态。看看这个变化速度，即使在目前完全委托还有困难的领域，不久的将来也很可能出现"AI 比人类更可靠"的情况。
老实说，作为工程师，我自己也不愿相信我所做的工作能这么容易被替代。但我能清楚地看到眼前正在消亡的东西。这不是炒作，也不是立场之争，而是真实发生的变化。
不过，这并不意味着"整个外包开发都在消亡"。消亡的不是外包开发，而是"只是构建"的软件开发。下面我会解释为什么这么想。
1. 不能把所有"外包开发"混为一谈
即使说"外包开发"，内容也五花八门：有单纯卖人月的外包公司、系统集成商、咨询公司、产品合作伙伴、PMO、DX 支持等等。所以问题不是"外包开发死了吗？"，而是"具体什么死了？"
仔细分析，AI 导致的价值下降并非一蹴而就，而是分阶段推进的。第一波冲击的是"写代码"这个行为的价值。事实上，开发生产力正在提高，项目的利润结构也开始变化。
而且这股浪潮不会止步于写代码。它会逐渐蔓延到设计、需求定义，以及更早的概念化阶段。所以我想区分哪些价值会先下降，哪些会保留。
那么，消亡的是"按指示写代码"的工作。不管是外包开发还是自研，都一样。而且这个领域已经在萎缩。
不过，萎缩并不均匀。中小型外包开发和小型自研开发正承受着自研和生成式 AI 浪潮的全部冲击，项目开始消失。另一方面，我经常听说大型企业的复杂系统还没遇到大麻烦，因为仅靠内部团队无法处理。影响因规模和客户群而异，所以混为一谈会把问题搞模糊。
2. 客户买的根本不是"代码"
想想看，客户外包是因为他们想让人写代码吗？答案是否定的。
客户期望的是解决问题：梳理业务战略、一起思考需求、获得决策帮助、协助内部协调、降低风险。代码只是实现这一目的的手段之一。
这样一想，"代码变便宜 = 外包开发已死"的逻辑就相当短视了。手段变便宜了，但预期价值并没有消失。
这与我同时在产品公司和外包开发工作的经历相符。有些外包开发团队深入业务，而有些自研开发团队则像内部承包商，只按业务部门的要求构建。用"产品公司 vs 外包开发"来划线已经无法反映现实。
而且，这不仅限于外包开发。开发与咨询的边界也在消融。咨询公司越来越多地组建开发团队，系统集成商也开始提供业务支持。"SaaS 已死"也是同样的结构：单纯卖软件的公司完了，而深入 BPO、运营、合作、绩效保障的公司却在增长。咨询、系统集成商、SaaS、产品公司之间的重叠越来越多。终点是客户的"价值"。
3. "思考"与"构建"正在拉近
长期以来，构建软件的成本太高了。因此，"思考"和"构建"不可避免地分离了。角色被划分，职位被划分，组织被划分，甚至公司也倾向于划分。
AI 降低了"构建"的成本。结果，"思考"和"构建"自然开始融合。角色、职位、组织、公司都在拉近。这就是正在发生的变化。
而敏捷开发想要实现的正是这一点：让"思考"和"构建"更接近。我们终于接近了那个当年因为构建成本太高而无法完全实现的理想。
事实上，在我们自己的客户工作中，不局限于单纯开发的案例越来越多。起初是普通的开发，后来往往变成"我们想咨询业务如何推进"，扩展到 PMO、商业模式设计、项目推进和决策支持。现在有些现场，我们花在"构建业务"上的时间比"构建系统"还多。起初我怀疑这还算不算外包开发，但现在已经不在乎边界了。
最近我经常听到 FDE（现场部署工程师）这个词，很可能也是同一趋势。进入客户现场，一起思考问题，必要时写代码。不是"思考者"和"构建者"，而是"边思考边构建的人"。这里有一个常见误解：本质是"在现场"或"物理上接近客户"。不是的。本质是"接近问题解决"。
然而，这个变化是一把双刃剑。最近我在一家大公司听到一个故事：从业务战略开始。系统开发启动。中途，构建成了唯一目标。战略消失了。然后留下了大量未使用的系统。这个现实在 AI 之前就存在了。但随着 AI 降低构建成本，这种悲剧会更轻易、更大量地发生。构建越容易，"构建什么"的分量就越重。
因此，对于深入问题解决的外包开发来说，AI 是顺风，不是逆风。远非"已死"。但一旦你远离问题解决，这股顺风就会变成"无用东西的批量生产机器"。
4. 最终，价值的源泉是"人"
说到这里，似乎外包开发、咨询、SaaS 的价值源泉是一样的。不是软件本身。而是人。
任何公司都能解决的工作会被替代。AI 能解决的工作也会被替代。但"必须由这些人来解决"这一点会保留。"我想和这些人一起工作"这一点也会保留。
所以目标不是交付产品，而是成为客户实现价值的伙伴。让人感受到价值在于人，而不是物。
决策就是最好的例子。AI 可以生成无数个候选方案。但决策的是人。而且只有通过做决策，才能提高决策能力。
我们如何培养人也在变化。在我的部门，我们正在转向"思考 + 构建"，当然有挣扎。但这不是通过培训学到的。它只会在工作中成长。
简单提一下招聘。最近，有些公司因为 AI 减少了初级员工的招聘。理由是："如果 AI 会写代码，我们就不需要初级员工了。"但我相信相反的方向。AI 原生的初级员工，因为没有固定思维，有潜力想出我们永远想不到的使用方法。即使短期内招聘受到限制，如果不能创造一个让人成长的环境，那个行业只会衰退。那不是 AI 的错，只是没能适应 AI 带来的变化。
工程师这个职业不会消失。消失的是"只构建"的工程师的工作。
所有软件开发都在接近"价值"
"外包开发已死"是真的。但是，消亡的不是外包开发，而是"只是构建"的软件开发。消失的不是工程师这个职业，而是"只构建"的工程师的工作。而且这已经开始。外包开发只是恰好处于一线。
如果退一步看这些变化，会看到更大的图景。深入业务的外包开发。拥有开发团队的咨询公司。涉足绩效保障的 SaaS。进入客户现场的 FDE。立场和形式各不相同，但方向一致。所有软件开发都在以自己的方式接近"价值"。
而且，这并不是新趋势。工程师们早就知道"只构建是不够的"，并试图更接近客户、用户和价值。典型的例子是敏捷开发。敏捷诞生已经 25 年了。那个"思考"与"构建"拉近的理想，在这几年被 AI 一下子加速了。这就是我所看到的。
所以，我们不应该再执着于软件开发的形式。外包开发还是产品公司？系统集成商还是咨询公司？与其在那里浪费精力，不如问自己："你能深入到价值多深的地方？"
7 月 24 日，我将围绕"外包开发已死"主题直播讨论到天亮
7 月 24 日，我将在 Creationline 主办的活动中发表演讲，主题是"AI 时代外包开发的未来——超越'外包开发已死'"。
https://creationline.connpass.com/event/398146/
2026 年 7 月 24 日（周五）19:00–20:30，通过 Zoom 举行，免费参加。
我将与 @samuraiRed 和 @sasakendayo 围绕"外包开发已死"这一主题进行深入、坦诚的讨论。
我们三个人可能会聊到不该聊的东西，所以我在筹备会议上跟主办方说："如果失控了，请打断我们。"肯定会有只有实时才能感受到的临场感。
我们聊些什么呢？
答案是……Tranquilo！别急！
当天等你来。
博客在这里：
