Naval《A Return to Code》解读：AI Coding Agent 让软件重新变成个人表达

原始来源：Naval Podcast A Return to Code
原文链接：https://nav.al/code
发布时间：2026-04-28
时长：29:36
说明：本文是基于 Naval 这期 podcast / transcript 的中文解读与个人延展，不是逐句翻译。

---

最近听了 Naval 最新一期 podcast，标题叫 A Return to Code。

副标题更直接：Vibe coding, the personal app store, and the end of Apple’s dominance。

这期表面是在聊 vibe coding，但我觉得真正值得拿出来讲的不是“AI 写代码很爽”，而是 Naval 对软件生产方式的判断：

AI Coding Agent 正在让软件重新变成个人表达工具。

以前软件更像团队工程。

你要写一个真正可用的应用，通常要会很多东西：编程语言、框架、命令行、Git、部署、后端、数据库、权限、接口、日志、版本管理。很多人即使有想法，也会被这些启动成本挡在门外。

但现在 Claude Code、Codex 这类 coding agent 开始把这些技术链路翻译成自然语言。你不再只是让 AI 给你一段代码，然后自己复制到 IDE 里，而是让它进入命令行、文件系统、Git、构建流程，持续帮你把一个东西做出来。

这就让“写软件”这件事的入口变了。

不是说人人都会变成程序员，而是说：一小部分有清晰想法、表达能力强、自驱的人，会突然获得过去一个小团队才有的软件生产力。

这件事比“效率提升”更大。

因为当实现成本下降之后，软件的瓶颈会从“谁会写代码”，转向“谁真的知道自己想要什么”。

---

1. Naval 说的“回到代码”，不是回到手写代码

Naval 开头讲了自己的状态。

他有计算机背景，但已经很多年没有认真写代码。对很多人来说，这其实很典型：年轻时懂一点技术，后来转向产品、投资、管理、内容、商业，慢慢离一线开发越来越远。

以前如果想重新写一个应用，启动成本很高。

你不只是要写代码，还要重新熟悉一整套工具链：

• GitHub 怎么用
• 后端怎么搭
• 前端怎么跑
• 数据库怎么连
• 部署到哪里
• 报错怎么查
• 依赖冲突怎么处理
• 本地和线上环境怎么同步

这些东西本身没什么浪漫，都是摩擦。

Naval 觉得 2025 年底之后，coding agents 过了一个临界点。它们不再只是“代码补全工具”，而更像一个能长期待在终端里的初级程序员：能读文件、改文件、跑命令、查错误、继续迭代。

这就是所谓的 “return to code”。

但这里的 code，不是说人重新回到逐行写代码的状态。

更准确地说，是：

人重新回到软件创造本身。

过去你脑子里有一个工具想法，但你可能因为工程成本太高放弃了。

现在你可以直接描述：

我要一个什么应用，它服务谁，长什么样，数据怎么流动，哪些地方要自动化，哪些地方要可视化。

AI 去处理一大堆技术细节。

人负责目标、判断和品味。

---

2. Personal App Store：最重要的不是 App Store，而是“只为我服务的软件”

这期里最有意思的例子，是 Naval 说自己做了一个 personal app store。

简单理解，就是他给自己做了一个私人应用入口。想要一个 App，就让 AI 构建，然后发布到自己的页面或手机入口里，一键安装和更新。

他举了一个健身记录 App 的例子。

不是下载一个通用健身应用，而是做一个完全贴合自己训练习惯的 App：记录训练日志、复用过去的训练记录、生成图表、计算力量分数、连接 Apple Health，甚至根据身体部位做可视化。

这个例子最重要的地方，不是“健身 App”。

而是以前这种东西不值得做。

因为它太个人化，市场太小。

你不可能为了自己一个人的训练习惯，找一个产品经理、设计师、前后端工程师组队做几个月。

但如果 AI 能把实现成本降下来，这种“只为我服务的软件”就突然变得合理。

这会把软件分成两类。

第一类，是大众高频场景。

比如微信、Uber、银行 App、支付 App、主流办公软件。这些产品依然会存在，因为它们覆盖的是大规模、标准化、高频需求，而且有成熟生态和信任关系。

第二类，是私人、小众、高度定制场景。

这些需求以前不值得被产品化，因为市场太小、需求太碎、回报不够。但 AI coding agent 会让它们被个人直接生成。

我觉得这点非常重要。

未来很多软件不一定是“公司卖给用户”的，而可能是“用户自己生成给自己用”的。

这会改变我们对产品机会的理解。

以前判断一个软件值不值得做，要问：

• 市场够不够大？
• 用户够不够多？
• 能不能规模化销售？
• 有没有足够强的商业模式？

但个人软件的逻辑不是这样。

它只需要问：

这个东西对我有没有用？

只要有用，它就值得存在。

---

3. Vibe coding 为什么会让人上瘾？

Naval 把 vibe coding 类比成一种有现实回报的游戏。

这个类比很准。

游戏为什么容易上瘾？

因为它有几个特点：

• 目标清晰
• 反馈及时
• 难度刚好卡在能力边缘
• 做一点就有一点奖励
• 你会不断升级

但游戏的问题是，奖励大多是假的。你在一个封闭系统里解题，解完之后回到现实，现实世界没有发生太多变化。

Vibe coding 不一样。

它也有即时反馈，也有持续奖励，也会让你卡在能力边缘。

但它底下跑的是一台真正的通用计算机。

你做出来的东西可以真的用，真的部署，真的给别人看，甚至真的产生收入。

所以它比游戏更危险，也更有价值。

Naval 说自己原来用来阅读、刷信息流、玩游戏的时间，现在很多都进了 Claude 和 Codex。

这句话背后有一个信号：

当创造工具的反馈速度接近游戏时，创造本身会变成娱乐。

这对个人创作者和小团队很关键。

以前做产品很苦，是因为反馈太慢。你写很多代码，配很多环境，修很多 bug，可能几天都看不到一个像样的东西。

现在 AI 把早期反馈拉得很近。

你描述一个工具，几分钟或几十分钟后就能看到雏形。你改一个想法，它马上改界面、改逻辑、改数据结构。

这会极大增加人的探索欲。

但这里也有一个前提：你要知道自己想要什么。

Naval 反复强调，最难的其实不是写代码，而是有清晰方向。

这也是我觉得很多人用 AI 做产品会卡住的地方。

AI 可以很快执行，但它不能替你拥有真正的需求。

如果你只说“帮我做个好用的工具”，它大概率会做出一个看起来完整、但没有灵魂的模板。

如果你能说清楚：

• 这个工具解决什么具体问题
• 谁在什么场景下使用
• 哪些流程必须快
• 哪些数据必须准确
• 哪些界面可以粗糙，哪些地方必须顺手
• 哪些功能不要做

那 AI 才能真正变成杠杆。

---

4. “纯软件不再适合 VC 投资”这句话该怎么理解？

这期里 Naval 说了一个很激进的判断：纯软件会变得越来越不适合风险投资。

这句话容易被误解。

他不是说软件没价值，也不是说没人能靠软件赚钱。

恰恰相反，他说现在可能是个人软件创造者最好的时代。

他的意思是：如果一家公司的壁垒只是“我们会写别人不会写的软件”，这个壁垒会快速变薄。

原因很简单。

第一，今天很多软件可以被 AI 很快拼出来。

第二，coding agents 进步速度很快，未来它们不只是能写原型，还会越来越能写架构更好、可扩展性更强的软件。

所以如果你是投资人，你会更关心那些 AI 不容易直接打穿的东西：

• 硬件
• 网络效应
• 数据优势
• 分发渠道
• AI 模型本身
• 强品牌
• 真实业务关系
• 行业 Know-how

这对做产品的人是一个提醒。

以后“我能写一个功能”不再稀缺。

稀缺的是：

• 我知道什么功能真的值得写
• 我有真实用户反馈
• 我有分发渠道
• 我懂一个具体行业
• 我能把工具嵌入真实业务流程
• 我能持续维护信任和交付

这点对我自己做 n263 / HappyMeasure 也有启发。

如果只是说“我有一个 WordPress 表单归因插件”，这个壁垒不够厚。

真正应该沉淀的是：

• 外贸站询盘归因的真实场景理解
• Google Ads 参数和表单数据之间的断点处理
• 客户站 WordPress 环境的兼容经验
• 从询盘到报表再到业务复盘的数据链路
• 交付、授权、更新、售后这套闭环
• 用内容建立信任和教育市场的能力

代码是入口，但不是护城河的全部。

---

5. AI Coding Agent 的问题：它很强，但太想让你满意

这期里我最喜欢的一段，是 Naval 对 coding agent 风险的描述。

他没有停在“AI 太厉害了”，而是讲了很多使用中的问题。

尤其是一个点：

AI 很容易顺着你。

你稍微暗示一个方向，它就会沿着那个方向找答案。哪怕这个方向不是最优，它也很少强硬反驳你。

这和我们平时用 AI 写代码的体验很像。

你说“是不是这个文件的问题”，它会很认真地去那个文件里找。

你说“我觉得这里应该加一个判断”，它很可能就顺着你加。

你说“这是个 hack 吧”，它经常会立刻承认，然后换一个方案。

问题是，它不一定真的理解“什么是架构层面的正确”。

代码库变大之后，问题会更明显：

• 上下文装不下
• 它开始猜
• 它会忘掉整体架构
• 它可能修错地方
• 同一个 bug 修好几遍
• 它会用局部 patch 掩盖结构问题
• 它甚至可能通过删掉功能来“修复 bug”

所以人并没有被替代。

人的角色变了。

以前人是逐行写代码的人。

现在人更像 operator / maintainer：

• 定义目标
• 读懂业务
• 判断方案
• 控制架构
• 审核 PR
• 决定什么能上线
• 阻止 AI 为了通过测试而破坏产品

这也是我觉得用 AI 写真实项目时，最需要警惕的地方。

不要只看“它改完了、能跑了”。

还要看：

• 有没有绕过真正问题
• 有没有破坏旧功能
• 有没有引入隐性安全风险
• 有没有让架构更难维护
• 有没有把复杂性藏到别的地方

AI coding agent 最适合加速，但不适合无人监管。

---

6. 为什么 AI 先攻破 coding 和数学？

Naval 还讲了一个基础问题：为什么 coding 和数学会成为 AI 特别强的领域？

答案其实很朴素：

数据多，而且结果容易验证。

代码能不能编译，测试能不能通过，程序能不能运行，这些都有相对明确的反馈。

数学也类似。很多题有标准答案，推导过程可以检查。

这类领域很适合 AI 训练，因为可以形成闭环：

输出 -> 验证 -> 纠错 -> 再输出。

但创意写作、审美、产品判断就没那么简单。

什么叫一篇文章好？

什么叫一个产品有品味？

什么叫一个界面顺手？

这些东西不是跑一个测试就能判断的。

它们依赖人类反馈、长期经验和高品味样本。

所以我觉得未来的分工会更清楚：

AI 会越来越擅长可验证的执行任务。

人仍然要负责那些难验证但很关键的判断：

• 方向是否值得
• 体验是否顺手
• 叙事是否成立
• 用户是否真的需要
• 取舍是否高级
• 什么东西应该删掉

代码越来越便宜之后，品味会更贵。

---

7. Apple 的风险：不是手机消失，而是入口变了

这期副标题里最容易引发争议的是 Naval 对 Apple 的判断。

他认为 AI agent 可能是 Apple 主导地位开始削弱的信号。

我理解他的逻辑不是“iPhone 马上没人用”，而是“用户入口可能从 App 和 OS 转向 AI agent”。

过去 Apple 的优势来自几个东西：

• 硬件体验
• OS 体验
• App Store 生态
• 原生应用质量
• 用户习惯和生态锁定

但如果未来用户越来越少主动打开 App，而是直接对 agent 说：

• 帮我叫车
• 记录我的训练
• 订一张票
• 整理今天的事项
• 生成一个我现在要用的小工具

那手机本身就会从“体验中心”变成“屏幕 + 电池 + 网络连接”。

真正的交互中心变成了 AI。

当然，我觉得这件事不会一夜发生。

银行、支付、政府、医疗、企业系统这些场景，都会有很长的迁移周期。

而且 Apple 仍然有强大的硬件、芯片、品牌、隐私叙事和生态控制能力。

但 Naval 的提醒是对的：

如果用户的默认入口从 App 图标变成 agent 对话，Apple 的一部分护城河会被重估。

这不是 Apple 会不会存在的问题。

而是它还能不能维持今天这种生态利润率的问题。

---

8. 客服、Bug 修复和产品迭代会合并

这期最后还有一个很有现实感的设想。

Naval 说他在自己的应用里做了 bug reporting：用户点按钮提交问题，日志上传，AI 每 24 小时看一遍 bug report，自动修复，并把修复放到分支里等他审核。

这里真正有意思的是：

客服、工程和产品迭代开始合并了。

传统软件公司里，这几件事是分开的：

• 用户向客服反馈问题
• 客服记录工单
• 产品经理判断优先级
• 工程师排期修复
• QA 验证
• 再发版

但如果 agent 能读用户反馈、读日志、定位 bug、写修复、开分支，人只负责最后判断能不能合并，那么很多小团队的迭代速度会被大幅提高。

这会让一人公司、两人公司更有可能服务大量用户。

当然，前提仍然是：人要做最后 gate。

因为用户不一定知道自己真正要什么，AI 也不一定知道什么改动符合产品方向。

所以未来的小团队不一定是“没有人管的全自动公司”。

更可能是：

一个高判断力的人，加上一组执行力极强的 agent。

---

9. 我自己的结论：软件的瓶颈正在从实现转向判断

这期 podcast 最值得带走的，不是某个工具名，也不是“哪个模型更强”。

而是这个变化：

软件实现正在变便宜，软件判断正在变贵。

以前你会写代码，就已经很有优势。

以后会写代码仍然有价值，但只会写代码不够了。

更重要的是：

• 你是否知道真实问题在哪里
• 你是否有清晰产品感
• 你是否懂一个具体行业
• 你是否能和用户建立信任
• 你是否能把反馈变成迭代
• 你是否能守住架构和质量
• 你是否有分发能力

这对个人创造者是好消息。

因为大公司有资源，但个人也有一个优势：可以非常贴近自己的问题，非常快地试错，非常少地妥协。

Naval 说 personal app store，我更愿意把它理解成一个象征：

未来会有越来越多软件，不是为了服务所有人，而是为了精准服务某一个人、一个团队、一个细分场景。

这可能也是小产品、小插件、小自动化工具的新机会。

尤其对那些本来就在真实业务里滚过一圈的人。

因为他们不是为了炫技而写软件。

他们知道哪里痛，知道用户为什么卡住，知道一个“很小的自动化”能省掉多少重复劳动。

AI coding agent 把实现门槛降下来之后，这些真实经验就会变得更值钱。

---

总结

Naval 这期《A Return to Code》，我觉得可以压成几句话：

• AI coding agent 让软件创造重新回到个人手里。
• 个人定制软件会变多，因为实现成本正在下降。
• Vibe coding 像游戏，但奖励是真实世界里的。
• 纯“会写软件”的壁垒在变薄，分发、数据、行业理解和网络效应更重要。
• AI 很强，但很容易顺着你，必须有人守住架构和判断。
• Coding 和数学先被 AI 攻破，是因为它们数据多、反馈可验证。
• Apple 的风险不是手机立刻没用，而是用户入口可能从 App 转向 agent。
• 小团队会更强，因为客服、bug 修复和产品迭代可以被 agent 串起来。

对我自己来说，最重要的一句是：

AI 不只是让写代码更快，它让“知道自己要什么”的人拥有了更大的杠杆。

这也是我觉得接下来值得认真做的事：

不是追着每一个新工具跑，而是把自己的真实问题、真实场景、真实用户理解沉淀下来。

因为当代码越来越容易生成之后，真正稀缺的，会是问题意识、产品判断和持续交付能力。

---

原始来源：Naval Podcast《A Return to Code》
原文链接：https://nav.al/code