AI Can Write Code. Why Isn’t Software Better?｜深度中文详解

播出信息

• 日期：2026-09-28
• 时长：2594 秒（43 分 14 秒）
• 节目：a16z Podcast
• 嘉宾与对谈者：TypeSafe AI 创始人 Diogo Almeida；a16z 的 Ben Horowitz、Martin Casado
• 英文转写来源：podscripts
• 音频：收听本集
• YouTube：观看本集
• Episode：节目页面

背景

当前常见的 AI 编程方式，是让模型替开发者生成或修改代码。Diogo 并不否认 Claude Code、Codex 等工具的价值，但他认为这主要改变了软件的生产过程：产物仍大体是原来那种需要预先写明规则的软件。TypeSafe AI 的 Jev 瞄准另一层问题：能否让开发者在程序中调用智能，将自然语言描述的意图转为程序可以使用的判断，而不必总把模型生成的文字交给人阅读、解释、再操作。

这也是标题中“软件为什么还没变得更好”的含义。讨论的重点不是代码能否更快写完，而是软件能否可靠地处理过去难以穷举的情境。

总结分析

本集从一个反差出发：AI 已能流畅回答复杂问题、编写代码，但企业里许多琐碎流程仍离不开人工。Diogo 认为，症结不只是模型不够聪明，也在于现有产品形态没有把智能变成软件可以放心调用的组成部分。聊天机器人把结果呈现给人，编码智能体加速生产传统代码；两者都不必然使运行中的程序获得理解意图、判断情境的能力。Jev 的设想是让开发者用自然语言描述任务，并把模型判断接入程序状态与后续动作。这使“软件更好”有了不同于“开发更快”的衡量标准：应用能否完成原先难以自动化、又值得自动化的工作。

对谈最有分量的部分是对可靠性的追问。若智能判断要在后台持续运行、访问资源，并供其他程序组合调用，一次漂亮的演示远远不够；它必须在输入稍有变化时仍保持相近的判断质量，也要让开发者知道何处可以信任、何处必须设限。Diogo 因而对宏大的自动化承诺保持谨慎，承认 Jev 尚不能保证适用于所有场景。

这一路线也改变了对既有 SaaS 的看法。若生成代码只会降低一部分开发成本，熟悉用户流程、已有产品与客户关系的公司并不会自动失去价值；它们反而可能最清楚哪些表单、分流与操作值得加入智能。不过，从辅助判断走向关键系统仍有很长距离：成本、延迟、错误后果，以及状态一致性和安全边界，都不能靠“模型看起来很聪明”解决。本集提出的是一种软件架构方向，而不是自动化已经完成的证明。

节目结构 / 议程

1. 自动化在哪里？ — 00:00 🎧 · ▶️
2. 编码智能体与“聪明的软件” — 03:43 🎧 · ▶️
3. Jev 如何进入程序：状态与概率判断 — 05:42 🎧 · ▶️
4. 创始人的路径与“打造产品，而非造神” — 09:12 🎧 · ▶️
5. 模型很强，为何实际工作仍难自动化？ — 17:47 🎧 · ▶️
6. 可靠性的真正含义 — 24:10 🎧 · ▶️
7. 编码智能体与 SaaS：替代，还是增强？ — 29:53 🎧 · ▶️
8. 概率式软件的边界与“按我的意思做” — 35:23 🎧 · ▶️

分节详解

1) 自动化在哪里？ — 00:00 🎧 · ▶️

💬 他们说了什么：开场以 Diogo 的问题定调：AI 如此聪明，“自动化都在哪里？”他喜欢聊天机器人和编码智能体，却认为它们尚未让大量日常任务自动完成。TypeSafe AI 希望做的是供软件使用的 AI，而不只是供人阅读回答的 AI；Jev 是这一路线的首个模型。

💡 为什么重要：这一问把评价标准从“模型能展示什么能力”转到“程序能稳定完成什么工作”。如果智能只能输出一段让人自行判断的文字，关键决策仍停留在人身上。

⚡ 争议点：“自动化不足”是观察，不是单一原因的诊断。任务的权限、异常情况、流程改造成本和错误责任，都可能阻碍部署；不能仅凭一个模型接口解释全部落差。

2) 编码智能体与“聪明的软件” — 03:43 🎧 · ▶️

💬 Diogo 借用“即时生成软件”的说法描述 Claude Code、Codex：它们能按自然语言写出软件，但产物的表达能力仍主要受传统代码方式约束。他想扩展的是软件本身能表达什么，例如让程序处理难以事先逐条列出的“意图”。对谈者进一步区分：Jev 不是又一个替人写代码的工具，而是人或编码智能体都可能写进代码的新能力。

💡 这区分了两种收益——缩短开发时间，与增加运行中软件的功能。前者即使显著，也不保证应用能处理更多真实情境；后者才可能改变用户实际完成任务的方式。

⚡ 两条路线并不互斥。编码智能体也可以帮助开发者接入新的智能能力；反过来，把模型嵌入程序，并不会自动解决软件设计、测试和维护问题。

3) Jev 如何进入程序：状态与概率判断 — 05:42 🎧 · ▶️

💬 对谈中，Martin 用近似“库”的方式解释 Jev：开发者以自然语言描述想要的判断，提供程序状态，由模型选择后续动作并给出置信程度。Diogo 接受它在某种意义上是“分类器”，并认为分类器恰恰因能接入系统而有用。他还说，自己当前的优化北极星是“每美元获得的智能”，但承认短期内“每秒获得的智能”也可能更关键。

💡 分类或选择结果比开放式文本更容易成为程序下一步的输入。讨论由此进入工程层面：哪些判断适合概率式处理，哪些仍应由明确规则承担，以及成本和延迟如何决定调用位置。

⚡ 节目没有给出完整接口规范或基准结果。“像分类器”“接入状态机”有助于理解设计意图，却不能据此推断它已具备传统组件的确定性、性能或适用范围。

4) 创始人的路径与“打造产品，而非造神” — 09:12 🎧 · ▶️

💬 Diogo 回顾数学竞赛、Kaggle、创业公司、Google Brain 与 OpenAI 的经历，强调自己首先是喜欢构建系统的计算机科学工作者。随后 Ben 提到 TypeSafe 的一句自我定位：“We build prod, not God”（打造可用产品，而非造神）。Diogo 反对把 AI 的未来只叙述成由一个巨大模型主导，也期待开发者因此能创造新的工作方式。

💡 经历解释了他为何把焦点放在工程可用性，而非只追求面向人的惊艳回答。“prod”所指向的，是软件能否在实际流程里被部署、调用和信任。

⚡ 积极的工作前景是一种愿景，不是本集已经验证的就业预测。反对“单一大脑”的叙事，也不等于大模型能力与这类软件组件之间没有依赖关系。

5) 模型很强，为何实际工作仍难自动化？ — 17:47 🎧 · ▶️

💬 Diogo 回忆，约在 2021 年第四季度，他对经人类反馈训练后模型的泛化能力感到惊喜；但能力展示没有如他预期般转化为广泛自动化，促使他重新思考产品方向。他认为，以人对回答的评价为中心优化模型，与让模型可靠执行实际任务，不是同一个目标。Martin 则提出反驳：现实任务有长尾例外，数据分布也不同于数学和代码。Diogo 不否认长尾存在，但主张先挑选值得投入、能够自动化的高回报部分。

💡 分歧不在于 AI 是否“聪明”，而在于怎样衡量聪明。能回答一道难题，与能在受约束、有异常、有后果的流程中持续工作，中间隔着产品和系统工程。

⚡ Diogo 提及 OpenAI 自 2020 年起尝试自动化客服，意在说明困难持续已久；节目并未提供这些项目的范围和成效数据。现实世界缺数据，还是缺可靠的程序接口，也不能由此次对谈一锤定音。

6) 可靠性的真正含义 — 24:10 🎧 · ▶️

💬 讨论先以客服为例：声称处理了大量请求，可能只是因为高频请求高度重复；按不同问题种类计算，覆盖程度会是另一回事。接着 Diogo 将可靠性与服务在线率区分开，也不把它简化为每次输出完全相同。他更看重输入发生无关紧要的变化时，模型是否仍表现出相近的判断能力，能否让开发者把它放进后台流程而无需时时查看示例结果。

💡 真正的自动化要求程序能够基于判断继续行动，并让其他程序在其上构建。此时可靠性不只是用户体验指标，更决定了可以授予系统多少权限、允许它处理多高风险的任务。

⚡ “每次都足够聪明”仍需要转成可测量的标准：测试集如何覆盖异常输入？失败怎样被发现和回退？错误率对不同业务后果是否可接受？对谈强调方向，但没有给出统一的验收门槛。

7) 编码智能体与 SaaS：替代，还是增强？ — 29:53 🎧 · ▶️

💬 Diogo 认为编码智能体擅长处理语法，却未必擅长决定软件架构；两者今后可以协作，而非必然替代。谈到“SaaSpocalypse”（AI 使 SaaS 失去价值的说法），他区分“写软件可能更便宜”与“复制一家公司的产品和价值也很容易”。他看好了解客户问题、拥有现成工作流的 SaaS 公司用新能力改造产品，而不仅是在界面旁加一个聊天框。

💡 若竞争优势包含用户理解、流程积累和交付渠道，代码生成成本下降不一定抹平这些优势。智能组件的收益，也可能首先体现在既有产品更准确地理解用户请求、减少繁琐表单和人工分流。

⚡ 这是能力与产品战略判断，不是 SaaS 估值预测。既有公司能否受益，还取决于数据权限、集成难度、错误成本及组织是否愿意改造工作流；新进入者同样可能利用新能力竞争。

8) 概率式软件的边界与“按我的意思做” — 35:23 🎧 · ▶️

💬 对谈把视线从应用表层移向系统内部：未来或许存在不同成本、速度和准确度的智能组件，供程序在不同环节选择。Martin 随即指出，日志、邮件或界面判断，与要求状态一致性、持久性和强保证的底层系统不是一回事。Diogo 承认不能宣称 Jev 已适合所有用途，也说团队本可以更早发布，却选择继续投入可靠性。收尾时，他用“do what I mean”概括希望达成的体验：技术能可靠地按用户本意工作。

💡 智能进入软件越深，价值越可能超出聊天界面；同时，判断错误也越可能沿程序链条放大。概率式判断需要与确定性规则、权限控制和失败处理共同设计，而不是取代它们。

⚡ 从辅助理解请求走向关键基础设施，是不同级别的承诺。节目以航空管制等场景说明想象空间，也表现出谨慎；不能把这种讨论理解为现有产品已满足安全关键系统要求。

人物与机构

• Diogo Almeida：TypeSafe AI 创始人。本集主要观点的提出者，曾谈及在 Google Brain、OpenAI 等机构的经历。
• Ben Horowitz：a16z 对谈者，着重追问产品愿景、自动化及其对既有软件公司的意义。
• Martin Casado：a16z 对谈者，着重追问编程接口、现实任务的长尾，以及系统级可靠性边界。
• TypeSafe AI／Jev：本集讨论的公司及其模型；目标是为软件开发者提供可嵌入程序的智能判断能力。
• a16z：本集节目出品方；其披露声明提示，关联方可能持有节目所讨论公司的投资。

金句

“Where the fuck is all the automation?” 自动化到底在哪里？——Diogo Almeida，以此提出全片核心问题。

“We build prod, not God.” 我们打造可投入使用的产品，而不是造神。——Ben Horowitz 在节目中引述的 TypeSafe 表述。

“Do what I mean.” 按我的意思做。——Diogo Almeida 对理想技术体验的概括。

洞见与延伸背景

• 把“模型回答”改写为“程序判断”：开放式回答适合人阅读；程序则需要知道如何依据回答进入下一状态。两者之间的接口，是本集最核心的工程问题。
• 概率判断不必覆盖全部流程：更可行的设计是划清边界——让智能处理难以枚举的理解与分流，让明确规则处理权限、交易约束和不可违反的条件。
• 评估单位可以从单次回答变成整个流程：一个模型在孤立问题上表现不错，不代表系统能发现错误、升级给人或在失败后恢复。自动化的实际收益应放在端到端任务中检验。
• “智能进入软件内部”会改变成本问题：若一次用户操作触发多层判断，调用价格与延迟便不再是附带指标，而是决定架构的约束。

争议与需核实

• Jev 的效果范围：节目提出可靠性目标与使用设想，但没有提供足以独立比较不同任务表现的完整基准、失败率或生产案例数据。
• 客服等场景的历史判断：嘉宾关于行业尝试已久、自动化仍有限的说法，需要结合具体项目的任务定义与部署结果核实。
• SaaS 将成为 AI 大赢家：这是 Diogo 的战略判断；不同产品类别、客户群和成本结构可能得出不同结论。
• 高风险系统的适用性：谈及底层系统和关键基础设施时，对谈者明确提出保证问题；不应从未来愿景推断现阶段已可安全部署。

行动建议

1. 选一个边界清楚的流程试点：优先挑选高频、有人复核记录、错误可回退的分类或分流任务，而非直接交付不可逆操作。
2. 分开记录两类指标：一类衡量开发是否更快；另一类衡量软件上线后是否减少人工步骤、提高任务完成质量。
3. 按错误后果设权限：让模型先提出判断，再依据置信程度、业务规则和风险级别决定自动执行、请求确认或转交人工。
4. 测试无关输入变化与异常情况：除了典型样例，也检查格式变化、额外信息、模糊意图和新出现的例外，并保留回退路径。

来源

• a16z 本集页面
• 本集音频
• 本集 YouTube 视频
• 英文转写：podscripts；文中分节时间依据所提供转写的时间标记。