工程师的两条上行路：从 Software Engineer 到 Business Builder 和 Harness Engineer
Naval 上周在他的播客里说了一句话：纯软件已经不可投资。
这句话被广泛转发的版本是”rapidly becoming uninvestable”——正在加速失去可投资性。但他在播客里特意说，那是被稀释过的说法，他真正想说的是：”Pure software is uninvestable. Full stop.”
转发的人很多，反驳的人也很多。我看完那期播客，没觉得震惊，也没觉得他危言耸听。我只是想起几天前我自己做的一件小事。
一个根据票据自动计算的小程序——抓扫描件、提金额、按规则汇总、出结果。换在三年前，这是一周的活：UI 写一遍、OCR 调一遍、规则跑一遍、边界情况补几遍。我那天用 AI 编程，从想法到能跑，几个小时。
跑通的那一刻我心里有两个反应。第一个是：真的很爽。第二个几乎是同时冒出来的：然后呢？
这个”然后呢”，才是 Naval 那句话真正的杀伤力。
一、AI 时代真正的陷阱，不在”学不会”
很多开发者把 AI 时代的焦虑放在”会不会用 Cursor、Claude Code、Codex”这一层。
我跑过这些工具，也跑过国内几乎所有能用的 agent。说一句不太悦耳的话：这一层的差距，三个月就能补齐。再笨的人，给三个月、一台能联网的机器、几篇靠谱的教程，AI 编程的基础动作都能做下来。
Naval 在播客里描述了一个画面：他在自己手机上搭了一个”个人应用商店”。想要什么 app，对着 Claude 说一段话——他举的例子是健身追踪 app，要参考 Tonal 和 Ladder 的功能、要符合 Apple 设计规范、要接 Apple Health——几分钟之后那个 app 就出现在他手机上。在饭桌上跟人聊天，对方描述一个想要的 app，五分钟后他可以直接掏出手机给对方看。
这就是今天 AI 编程能做到的事。
但这件事的另一面是：当所有人都能五分钟做出一个 app 的时候，”做出来”这件事本身就不再是一个差异化能力。
真正的陷阱不在”会不会用工具”这一层。真正的陷阱是：你学会了之后，发现自己不知道拿它做什么。
你能一晚上写一个 SaaS 雏形，但你不知道有没有人会用。你能复刻一个 Notion 替代品，但你卖不出去。你能造出一个工具，但它在你的硬盘上躺着，没有用户、没有收入、没有反馈。
这是 AI 编程之后大多数开发者会真正面对的处境。技术能力第一次真的不是瓶颈，但能力解锁之后，绝大多数人发现自己手里只有半盘棋。
二、软件从来只是这盘生意的一个环节
把一盘完整的生意拆开看，软件开发——也就是”把这个东西做出来”——只是其中一个环节。而且通常不是最难、也不是最稀缺的那个环节。
剩下的几件事是：
- 做什么有人要 —— 产品定义和需求验证。这一步走错，后面再快都是白干。
- 怎么让人知道 —— 分发和触达。一个再好的产品，没有渠道就是 0 用户。
- 怎么让他用起来 —— 转化路径和首次体验。人来了留不住，也是 0。
- 用了之后怎么不走 —— 留存和粘性。
- 到期了怎么续费 —— 商业化和复购。
这五件事，AI 能给你工具，但没法替你做决定。不是 AI 不够强，是这五件事的核心都不是技术。它们的核心是判断、是信任、是关系、是分发、是真实用户行为的反馈。这些东西不在仓库里，不在 prompt 里。它们必须由一个愿意走出去和真实世界打交道的人来一点点攒。
回到 Naval 那段判断的内核——他说投资人现在该看什么？硬件、网络效应、AI 模型。注意这三样的共同点：没有一样是单纯的”软件实现”。硬件靠制造，网络效应靠用户之间的关系沉淀，AI 模型靠数据和训练闭环。它们都是关于”做出来”之后那 3/4 的事。
AI 把”做出来”的成本压到了几乎为零。但它没有压低、也压不低剩下的 3/4。
如果你之前是因为”做不出来”卡住，AI 解放了你。如果你之前是因为”做出来之后不知道怎么办”卡住，AI 帮不了你——它只是让你更快地撞上同一面墙。
三、AI 不会反对你——而能听见警报的，仍然是工程师
播客里有一段我反复想了几天。
Naval 说他经常会停下来对着模型说：”这是 hack，去架构层修。”模型每次都立刻回答：”你是对的，这是 hack。”哪怕原本不是 hack。
他说得很轻，像在讲一个段子。但这一段是整期播客里最值得一线工程师重视的内容。
AI agent 在结构上不会反对你——它的训练目标就是让你满意。你越倾向某个答案，它越快”找到”那个答案。Naval 自己尝试过把多个模型配成一个互审的 council，他的结论是：没什么用，因为本质是”同一个大脑跑十遍”。
但这件事还有另一面。
既然 AI 不会自己反对自己，那必须有人来反对它——更准确地说，必须有人来定义它应该在哪里被打断、在哪里不该被信任、在哪里需要人接管。这件事不是任何人都能做的。
AI 在出错的时候，给出的不是一个明显的”错误”——是一个看起来在解决问题的方案。它会说”我加了一个 try-catch 把这个异常处理掉了”，而真正的问题是上游数据为什么会到这个异常状态。它会说”我把这个测试 case 跳过了，因为它和当前修复无关”，而那个测试 case 恰恰是在保护你不犯一个更大的错。它会说”你是对的，这是 hack”——然后给你另一个看起来不那么 hack 的 hack。
工程师和架构师有一种长出来的肌肉记忆：一眼看出哪里开始烂，立刻止损。这种本能是十年间被代码反复教出来的——一个变量名让你不舒服、一个函数签名让你警觉、一段逻辑让你想”等一下，这里不对”——这些反应几乎是自动的，发生在意识介入之前。
没有这种背景的人，没有这套肌肉记忆。他不是不会用 AI，是不知道什么时候该停。AI 给一个把症状掩盖的 patch，他以为修好了；AI 在错误前提下越修越复杂，他以为是工程本来就这么难；AI 把一个本该重写的模块修补到第十轮，他以为再补一轮就稳定了。然后整个东西滑进一种没人能救的状态——不是代码烂尾，是判断烂尾。
Naval 自己在播客里说过一句很重要的话：他能停下来对模型说”这是 hack，去架构层修”，是因为他有 CS 学位、懂计算机架构和网络。他自己强调过这一点。一个没有这个背景的人，听到模型说”你是对的，这是 hack”，会以为问题被识别和修复了——他听不到那个本该响起来的警报。
这个能力——听见警报的能力——是工程师的护城河。
不是”会写代码”。会写代码这件事 AI 已经做得比你快了。是”会识别一个东西什么时候开始烂”。这件事 AI 做不到，因为 AI 自己就是那个开始烂的东西。
四、给 AI 套上缰绳：一门正在成型的工程
这就是为什么过去一年里，硅谷有一个词在快速成型——harness engineering。
Harness 这个词本来是马具——缰绳、马鞍、嚼子——一整套用来引导一匹强大但不可预测的动物的装备。AI 模型就是那匹马。Harness engineer，是给它套上缰绳的人。
这门工程的核心不是会调用 Claude API，是知道 Claude 在什么场景下会开始烂——会幻觉、会顺着用户的错误前提一路滑下去、会用一个看起来正确但其实掩盖了 bug 的 patch 来”解决”问题。然后在这些场景里设计兜底、设计中断、设计回滚、设计可观测性——把一匹会乱跑的马，关进一个能让它跑出价值、又跑不出边界的笼子。
而识别”什么时候开始烂”，是工程师的肌肉记忆。
不是产品经理的——产品经理的训练里没有”边界 case 优先于 happy path”这条铁律。不是设计师的——设计师的关注点是用户感知，不是系统失败模式。也不是纯粹的 Builder 的——Builder 没有过那种凌晨三点被一个 race condition 折磨过的痛感。
只有工程师看得到这一层。因为工程师是被代码反对过最多次的那群人。
所以工程师之后，下一条路其实有两条——
一条路是 Software Engineer 升到 Business Builder。
面向市场，重新学习”该不该做”。第一个问题从”这个功能怎么实现”换成”有没有人愿意为这件事付钱”。这是把”做出来”之外的那 3/4 收回来——产品定义、分发、转化、留存、复购。这条路上 AI 是杠杆，是放大镜，但真实世界的反对者必须由你自己去找——客户、市场、监管、用户的沉默。
另一条路是 Software Engineer 升到 Harness Engineer。
面向 AI 系统本身，把”识别什么时候开始烂”这件十年磨出来的肌肉记忆，从 review 同事的代码挪到 review AI 的输出。把 AI 关进一个不会越界的笼子——在合规、在可溯源、在审计链路、在生产事故时能查到根因。这是 Builder 看不到的工程深度。
两条路都开放。共同点是：都不再以”把代码写出来”为核心产出。
第一条以”判断该不该做”为产出。第二条以”判断 AI 在哪里会烂”为产出。
这两条路上，工程师都有别人没有的位置。
而留在中间——既不去面对市场、又不去约束 AI，只是继续用 AI 把代码写得更快——是这一代工程师真正最危险的处境。
五、对一个架构师而言，意味着什么
我做架构这么多年，处理的核心一直是工程问题。但在保险这个行业里看了几年 AI 落地，我越来越清楚一件事：没有领域深度的那部分工程，正在加速变成商品。
模型层在商品化。推理层在商品化。Agent 编排层在商品化。连”用 AI 写代码”这件事本身，也在快速变成水电。
而水电厂赚钱的，从来不是会拧水龙头的人。
Naval 在播客最后讲了一个画面：他在自己 app 里搭了 bug reporting，Claude 每 24 小时跑一遍所有 bug 报告，自动修完放到 side branch，他只做最后的 review gate。他的预测是：未来软件开发会变成 user → agent → maintainer 的协作模式，一两个人的公司能 scale 到百万用户、做到几十亿美金。
这个画面里有一个被忽略的细节：那”一两个人”，做的不是写代码的工作。他们做的是——review 哪些 bug 真的是 bug、哪些功能值得做、哪些用户是对的、哪些用户是错的——全部是判断的工作。
这个画面里没有 Software Engineer 的位置。它从头到尾只有 Builder 的位置和 Harness Engineer 的位置——那”一两个人”必须同时是这两种身份。
所以工程师的护城河必须从”能不能做出来”，挪到”做的这件事在生意里的位置，以及在系统里的边界”。再具体一点——
作为 Business Builder 的判断力：
- 能不能识别什么值得做：在一堆需求里挑出 ROI 真正成立的那一个。
- 能不能识别什么不值得做：在一堆漂亮的 demo 里看出哪个根本撑不起一盘生意。
- 能不能识别判断本身有多贵：用更便宜的方式，更快地知道一件事到底值不值。
作为 Harness Engineer 的判断力：
- 能不能识别 AI 在哪里会烂：在一连串看起来都对的 patch 里，听见那个本该响起来的警报。
这四件事，AI 都帮不上你。它们的输入不在代码里，在你的判断里。判断的源头是经验、是行业知识、是对真实用户行为的观察、是对失败案例的积累——这些只能由一个真的在场的人慢慢长出来。
这才是接下来 5-10 年工程师真正的位置。
所以我现在怎么想
回到 Naval 那句话——纯软件已经不可投资。
我不太同意”已死”这种说法。更准确的说法是：
软件作为护城河，已死。软件作为杠杆，刚刚出生。
如果你把软件当作护城河——以为”我做出来了别人复制不了”——那你已经站在了历史趋势的反面。
如果你把软件当作杠杆——它放大的是你对生意、对用户、对市场、对系统失败模式的判断——那 AI 编程对你不是威胁，是放大镜。
我做那个票据程序的时候，技术上它是个几小时的活。但能不能把它变成有人付费的产品，是另一个三个月、甚至三年的问题。那个”三年的问题”——以及它身边的另一个问题：怎么让一个会出错的 AI 在生产环境里安全地跑——才是这个时代真正稀缺的能力。
工程师仍然站在杠杆的那一头。只是握住的不再是键盘，是缰绳——一根能在 AI 开始走偏的瞬间、不需要思考就先收紧的缰绳。
这种”先收紧的本能”，是这一代工程师过去十年被代码反复教出来的。它不在 AI 的训练数据里。它只在你身上。
「模型之外的事」系列。在 AI 的喧嚣里，替你找到真正能用的东西。不搬运新闻，不贩卖焦虑。