HN 吵了 300 楼才达成共识：你还需要一个领域，只是不再是写代码
最近 Brent Horsting 的一篇文章在 HN 引发了激烈讨论。他的核心论点简单但锋利：
「Agentic AI 切断了一个维系整个软件行业几十年的链接——写代码和建立领域心智模型之间的链接。你现在可以在不构建领域理解的情况下产出软件。」
这篇文章在 HN 上拿了 400+ 分、300+ 条评论，正反双方都拿出了硬核的论据。我把原文和讨论一并消化，提炼出几个值得认真思考的结论。
原文的核心框架
Pre-agentic 时代，写软件从来不是难在"写"本身。难的是先在脑子里建立一个领域的工作模型——你不可能在理解什么是税前扣除、什么是工资期跨税率变更之前，就写出一套工资系统。
Agentic AI 改变了这个等式。Brent 用两个人的对比来说明：
领域专家 + AI：惊人的有效。 一个物流调度员不懂什么是哈希表，但他看一眼 AI 生成的排班表，立刻知道哪个司机的工作时长不合法。他知道"正确答案长什么样"，因为他在这个领域里泡了十年。AI 提供的是他缺的东西（产出代码的能力），他提供的是 AI 缺的东西（ground truth）。
通才工程师 + AI：危险的盲区。 一个架构能力极强的工程师被扔进临床编码领域。AI 可以生成通过所有测试的账单规则——但这个规则可能"微妙地、昂贵地错误"。工程师可以验证软件"构建得好不好"，但无法验证它"对不对"。因为这里的"对错"完全由他不掌握的领域知识定义。
Brent 的判断：
「Agentic 工具摧毁了两条路径中的一条，而不是两条。工程师的优势——把领域模型翻译成工作代码——现在变得便宜了。领域专家的优势——知道正确长什么样——没有变便宜。你无法通过 prompt 获得一个处理了上千次工资核算的人的隐性知识。」
HN 最精彩的几个反驳
任何简洁的论点都会在 HN 上被从各个角度撕裂。这次也不例外。但撕裂的过程本身很有价值。
反驳一：软件工程本身就是一种领域知识
这是讨论中最有力的一个方向。
用一个具体的例子拆解了问。他看过一个领域专家用 AI vibe-code 出来的应用——一个菜单管理系统。领域专家的实现方式是为每个菜品的每种可能配料设置独立的布尔标记：
技术上正确，测试也能过。但任何一个有经验的工程师都会用一个数组来建模。当新菜品需要新配料时，布尔标记方案需要改 schema、改 UI、改所有相关逻辑——这是一个设计故障，不是质量故障。领域专家不知道"对"长什么样，因为他不知道"软件设计"这个领域里什么是对的。
几个资深工程师在讨论中达成的一致结论：
「成功的软件来自两个领域专长的交集——应用领域，和软件工程本身。」
反驳二：AI 已经在编码领域知识
的反驳很直接：LLM 本身就在编码领域知识。你可以通过反复追问一个 LLM 来"学会"很多领域。相当多领域的壁垒只是"你不理解这个领域"，而 LLM 正在瓦解这个壁垒。
但
的一个长篇回复提供了更有力的反例——产权保险和托管服务。他在这个领域干了多年，带过大型团队，深度使用过前沿模型。结论是：
「我们从 LLM 那里没有得到真正的 ROI。它产生了大量可疑的输出，无法在深度领域问上给出准确答案而不产生幻觉，也无法理解在一个司法管辖区有效的东西在另一个司法管辖区可能完全错误。」
最有意思的是他的结论：我们发现构建最好产品的方式仍然是去现场，坐在产权和托管人员旁边，看他们工作，问他们问，为真实世界设计。
反驳三：真正的护城河是销售
-chisel 提供了另一个维度的思考：
「到目前为止，证据指向的是一个不同的格言：Sutton 的"惨痛教训"。它告诉我们，不要把人类专业知识带到可以被海量数据解决的问上。因为后者在历史上反复屠杀了前者。」
他认为，如果一定要找一个真正的、持久的护城河，它不是领域知识，而是销售——说服其他人类掏钱。
延伸：平台工程师的新角色
提出了一个正在浮现的新角色：
「我现在在做的基本上是平台工程师。工作内容是为领域专家使用编程 agent 创建护栏、验证流程、prompt 库，以及人工和自动审查机制。类似于内部 T2/T3 支持工程师——你在那里是为了抓住危险点和边缘案例，确保一切配置正确，而不是解决 100% 的常规问。」
真正的结论：不是二选一，是交集
Brent 的文章标叫"领域知识一直是真正的护城河"，但 HN 讨论把它修正成了更准确的表述：
领域知识是必要条件，但不是充分条件。
最安全的位置不在光谱的任何一端。它在两个人格的重叠处：
- 你能在 AI 生成的代码中识别出 has_milk = true 是个设计灾难
- 你能在工资单上识别出税前扣除的计算错误
- 你知道什么时候 agent 给的答案"听起来对但错得离谱"
-m 在评论里举了一个他自己的真实案例。他的公司做私募股权和风险投资的软件。他们的内部笑是："我们宁愿招一个资深基金会计来教他编程，也不愿意招一个工程师来教他基金会计。"——问是前者几乎不存在。
这就是 Brent 给工程师的建议最后落点的地方：
「如果你是一个有经验的工程师，在考虑接下来几年应该把时间投入到哪里，这就是你的赌注。你辛苦练习的机械技能——把清晰想法翻译成干净代码——已经大幅贬值。仍然稀缺的，是一个对真实世界的某个领域有深度、可验证的心智模型。去找一个领域。就像你曾经学习一门编程语言或框架那样，去学一个行业、一个工具、一个监管体系、一个物理过程。」
一句
「写代码的能力正在变成水。知道"对"长什么样的能力才是油。拥有两者的人，是 AI 时代最稀缺的资源。」
原文链接：https://brethorsting.com/blog/2026/05/domain-expertise-has-always-been-the-real-moat/
HN 讨论：https://news.ycombinator.com/item?id=48340411
@aigc1024
最近 Brent Horsting 的一篇文章在 HN 引发了激烈讨论。他的核心论点简单但锋利：
「Agentic AI 切断了一个维系整个软件行业几十年的链接——写代码和建立领域心智模型之间的链接。你现在可以在不构建领域理解的情况下产出软件。」
这篇文章在 HN 上拿了 400+ 分、300+ 条评论，正反双方都拿出了硬核的论据。我把原文和讨论一并消化，提炼出几个值得认真思考的结论。
原文的核心框架
Pre-agentic 时代，写软件从来不是难在"写"本身。难的是先在脑子里建立一个领域的工作模型——你不可能在理解什么是税前扣除、什么是工资期跨税率变更之前，就写出一套工资系统。
Agentic AI 改变了这个等式。Brent 用两个人的对比来说明：
领域专家 + AI：惊人的有效。 一个物流调度员不懂什么是哈希表，但他看一眼 AI 生成的排班表，立刻知道哪个司机的工作时长不合法。他知道"正确答案长什么样"，因为他在这个领域里泡了十年。AI 提供的是他缺的东西（产出代码的能力），他提供的是 AI 缺的东西（ground truth）。
通才工程师 + AI：危险的盲区。 一个架构能力极强的工程师被扔进临床编码领域。AI 可以生成通过所有测试的账单规则——但这个规则可能"微妙地、昂贵地错误"。工程师可以验证软件"构建得好不好"，但无法验证它"对不对"。因为这里的"对错"完全由他不掌握的领域知识定义。
Brent 的判断：
「Agentic 工具摧毁了两条路径中的一条，而不是两条。工程师的优势——把领域模型翻译成工作代码——现在变得便宜了。领域专家的优势——知道正确长什么样——没有变便宜。你无法通过 prompt 获得一个处理了上千次工资核算的人的隐性知识。」
HN 最精彩的几个反驳
任何简洁的论点都会在 HN 上被从各个角度撕裂。这次也不例外。但撕裂的过程本身很有价值。
反驳一：软件工程本身就是一种领域知识
这是讨论中最有力的一个方向。
用一个具体的例子拆解了问。他看过一个领域专家用 AI vibe-code 出来的应用——一个菜单管理系统。领域专家的实现方式是为每个菜品的每种可能配料设置独立的布尔标记：
技术上正确，测试也能过。但任何一个有经验的工程师都会用一个数组来建模。当新菜品需要新配料时，布尔标记方案需要改 schema、改 UI、改所有相关逻辑——这是一个设计故障，不是质量故障。领域专家不知道"对"长什么样，因为他不知道"软件设计"这个领域里什么是对的。
几个资深工程师在讨论中达成的一致结论：
「成功的软件来自两个领域专长的交集——应用领域，和软件工程本身。」
反驳二：AI 已经在编码领域知识
的反驳很直接：LLM 本身就在编码领域知识。你可以通过反复追问一个 LLM 来"学会"很多领域。相当多领域的壁垒只是"你不理解这个领域"，而 LLM 正在瓦解这个壁垒。
但
的一个长篇回复提供了更有力的反例——产权保险和托管服务。他在这个领域干了多年，带过大型团队，深度使用过前沿模型。结论是：
「我们从 LLM 那里没有得到真正的 ROI。它产生了大量可疑的输出，无法在深度领域问上给出准确答案而不产生幻觉，也无法理解在一个司法管辖区有效的东西在另一个司法管辖区可能完全错误。」
最有意思的是他的结论：我们发现构建最好产品的方式仍然是去现场，坐在产权和托管人员旁边，看他们工作，问他们问，为真实世界设计。
反驳三：真正的护城河是销售
-chisel 提供了另一个维度的思考：
「到目前为止，证据指向的是一个不同的格言：Sutton 的"惨痛教训"。它告诉我们，不要把人类专业知识带到可以被海量数据解决的问上。因为后者在历史上反复屠杀了前者。」
他认为，如果一定要找一个真正的、持久的护城河，它不是领域知识，而是销售——说服其他人类掏钱。
延伸：平台工程师的新角色
提出了一个正在浮现的新角色：
「我现在在做的基本上是平台工程师。工作内容是为领域专家使用编程 agent 创建护栏、验证流程、prompt 库，以及人工和自动审查机制。类似于内部 T2/T3 支持工程师——你在那里是为了抓住危险点和边缘案例，确保一切配置正确，而不是解决 100% 的常规问。」
真正的结论：不是二选一，是交集
Brent 的文章标叫"领域知识一直是真正的护城河"，但 HN 讨论把它修正成了更准确的表述：
领域知识是必要条件，但不是充分条件。
最安全的位置不在光谱的任何一端。它在两个人格的重叠处：
- 你能在 AI 生成的代码中识别出 has_milk = true 是个设计灾难
- 你能在工资单上识别出税前扣除的计算错误
- 你知道什么时候 agent 给的答案"听起来对但错得离谱"
-m 在评论里举了一个他自己的真实案例。他的公司做私募股权和风险投资的软件。他们的内部笑是："我们宁愿招一个资深基金会计来教他编程，也不愿意招一个工程师来教他基金会计。"——问是前者几乎不存在。
这就是 Brent 给工程师的建议最后落点的地方：
「如果你是一个有经验的工程师，在考虑接下来几年应该把时间投入到哪里，这就是你的赌注。你辛苦练习的机械技能——把清晰想法翻译成干净代码——已经大幅贬值。仍然稀缺的，是一个对真实世界的某个领域有深度、可验证的心智模型。去找一个领域。就像你曾经学习一门编程语言或框架那样，去学一个行业、一个工具、一个监管体系、一个物理过程。」
一句
「写代码的能力正在变成水。知道"对"长什么样的能力才是油。拥有两者的人，是 AI 时代最稀缺的资源。」
原文链接：https://brethorsting.com/blog/2026/05/domain-expertise-has-always-been-the-real-moat/
HN 讨论：https://news.ycombinator.com/item?id=48340411
@aigc1024
