loading image

从“vibe coding”到可交付:把 AI 焦虑变成 7 天的行动

Posted by Enovace on February 20, 2026

从“vibe coding”到可交付:把 AI 焦虑变成 7 天的行动

Banner

开场:这期最有用的地方在“做事方法”

Naval Ravikant 和 Nivi 这期 The Naval Podcast,我听完的感觉很明确:他们聊 AI 的方式更像在教“怎么动手”,而不是在押注某个预测。

很多人对 AI 的不安,根源常常是启动困难:工具一大堆,第一步不知道怎么迈。播客给的解法很朴素:做一次小交付,让现实给反馈。

播客文字稿:http://nav.al/ai

x.com/naval/status/2024700227111047581?s=20


1)学习的单位是交付(0:00)

播客开头那句 “If you want to learn, do”,翻译成实践语言就是:别用“看懂了”当进度条,用“交付了”当进度条。

我现在衡量自己有没有真正学会一个能力,会看它能不能解决一个真实麻烦。交付物越小越好,小到 48 小时能做完,反馈也更快。

举三个最容易立刻开跑的小结果:

  • 把一份混乱的会议记录压成一页“决策清单”
  • 把一张报表截图压成“今天该改的 3 个动作”
  • 把一段客户语音压成“可执行的规格说明”

Image


2)vibe coding 把产品推进方式改写了(2:13)

他们把 vibe coding 描述得很具体:用自然语言推动一个应用从无到有。

这里最关键的变化是:推进产品越来越像推进“可交付输出”。模型能写很多代码,但前提是目标和验收写得清楚。

我更倾向把需求压成三句话:
输入是什么,输出长什么样,怎么算做对了。

一个很具体的小例子:
“输入:广告报表 CSV。输出:一页行动清单。每条建议必须包含原因、动作、阈值、验证方式。做对的标准:运营同事照着清单能在 30 分钟内改完并开始跑验证。”

写清楚这三句,后面让模型做也好,让工程做也好,都在同一条轨道上。

Image


3)底座会普及,稀缺会转移到技能包(6:49)

播客里提到 “Training and tuning models is the new coding”。对大多数独立开发者来说,这更像背景趋势:底座能力会越来越像水电煤,获取成本持续下降。

差距会转移到另一层:把通用能力变成稳定交付的那层。

我会把“能卖的东西”刻意做成技能包形态:

  • 输入固定
  • 输出固定
  • SOP 固定
    用户拿到的是一个能复用的流程,不用反复调教。

例子可以很朴素:同样是“分析报表”,产品交付的重点放在“下一步做什么”,并把格式锁死,让输出每次都可读、可执行、可复盘。

Image


4)平庸会被海量应用吞没(13:07)

“No demand for average” 这句很扎实,用在选题上特别省命。

当做应用变便宜,供给会爆炸。最后能被记住的常常是“窄而准”,准到能减少一次会议、减少半天纠结、减少一次重复劳动。

我筛选选题会问一个问题:
做完这个轻工具,能不能直接降低一次沟通成本或试错成本。
答案如果含糊,项目很容易滑向“演示很强、用完就忘”。

Image


5)最热的编程语言是英语,长期有效的是验收(14:12)

他们对各种提示词技巧的态度很清醒:模型会越来越适配人的表达,技巧迭代速度快到很难追。

但有一件事不会过期:验收标准。

所以我给模型任务时更像在写交付说明:
输出必须包含哪些字段,每个字段多长,给一个示例,不确定就先提问再继续。

这套写法换模型也能跑,换人也能交接,最重要的是它能把“好看输出”推向“可用输出”。

Image


6)AI 会在当前水平接住人,机会在“扶上来”(39:37)

播客里提到 AI 能在当前水平耐心解释,直到真正理解。

换成产品语言:很多用户并非拒绝付费,卡点常常是启动困难。能把人从“启动不了”扶到“能做一次”的工具,会更容易被留下。

所以做轻工具时,我会偏向两步走:
先产出一个可用雏形,再用几个问题把输入引导到正确范围。

比如“内容生产”类工具,第一版就锁一个输入源:一段长文本。输出锁成固定结构:标题候选、要点、发布队列。先让流程跑通,再逐步放开输入类型。


7)焦虑的解法是行动,把行动压成 7 天(49:37)

“The solution to AI anxiety is action” 这句听起来像鸡汤,但对创业者很硬核:不确定来自想象,确定来自一次验证。

Image

我更喜欢把它压成 7 天节奏,目标只有一个:跑通一次可交付闭环。

  • D1 选场景:每天重复,动作明确
  • D2 写三句规格:输入、输出、验收
  • D3 做样稿:先让输出长相成型
  • D4 接真数据:只支持一种格式
  • D5 把建议写成原因 + 阈值 + 验证
  • D6 找 3 个真实用户试跑,看能否立刻执行一条
  • D7 把交付物打包成套餐:行动清单 / 发布队列 / 审批包

项目早期追求“跑通一次”,比追求“做大全功能”更接近答案。


结尾:这期播客给了一种更稳的节奏

听完后最大的变化是:注意力从模型更新转向可交付结果。
模型进步是背景,能把目标写清楚、把验收写清楚、把验证做完的人,会越来越像一个能独立交付的小团队。