跳转至

How to kill your SaaS：我们用 AI agent 替掉一个 $43K/年的工具，学到了什么（Latent Space，2026-10-13）

  • 形式: ⚠️ 不是访谈，是一期自制的实验复盘（含对三位入围者的录播访谈片段）
  • 主讲: Latent Space 主播 一方（可确认为 swyx，见下）
  • 其他出场: Kelsey（AI Engineer 运营负责人 / head of ops）、 三位入围者 Marco Kramer（TrackStage）、Yazin（Conferencer）、Valentin de Matas（获胜者）
  • 来源: YouTube · 28 分钟
  • 转录稿: sources/latent-space/20261013-zlD-CkLVKtU

说话人说明：转录稿为自动字幕，无 SPEAKER 标签。但本期归属反而比多数访谈更清楚： 主讲自述"我经营两家生意，Latent Space 和 AI Engineer"（[00:00:00]），而 AI Engineer 是 swyx 的会议品牌，故主讲判定为 swyx；Kelsey 被主讲点名为 AI Engineer 的 head of ops （[00:09:12]）；三位入围者的发言段均由主讲在前一句指名引入（"Marco…"、"Yazin from Conferencer…"、"our third finalist Valentin…"），故这三人的引语归属有机械依据。

⚠️ 自动字幕的专名损坏，本页按上下文还原并声明一次：SAS → SaaS； the Inspace → Latent Space；session board / sessions board → Session Board（被替掉的那款软件）； cla → Claude；codeex / Codeex → Codex；cloud / claw / clod → Claude； x.js → Next.js；convex → Convex；net care → nice touches（按语境）； peacemeal / peacemaker → piecemeal；Zboarding / inboarding / boarding → onboarding； Kilmeas → Kill My SaaS；cash → cache。 ⚠️ 三处本页判为不可靠、因此不写定：① 所有三位入围者都用的那个模型（字幕作 "GPT soul"， 本页只记"同一款 GPT 系模型"，不写型号）；② 获胜项目名（字幕在 "Open Rostroom" 与 "open roster" 之间摇摆，本页写作"Valentin 的项目"）；③ 两处项目名 （"Cboard HQ"、"lectturn to curtain call"）按字面记录，可能有损坏。

概要

✅ 本页认为这是本库到目前为止唯一一份"把『AI 杀死 SaaS』这个论断真的拿去做了一次带人工验收的 实验"的材料，而且实验方自己是买方：主讲报价单上是 $43,000/年（四场活动）的会议管理软件， 他办了一场公开竞赛（Kill My SaaS）让人复刻它，最终验收交给自己不懂技术的运营团队， 72 个人/团队提交。

⚠️ 也正因为是自制内容，它没有任何外部声音——主讲既是出题人、奖金提供方， 也是结论的叙述者。本页据此把结论分成两类：可核验的过程数据（提交数、代码行数、 模型使用分布、AI 评委与人工评分的相关性）与他本人的判断（是否值得自建）。

✅ 本页认为最该被引用的三条： 1. ⚠️⚠️ AI 评委与人工验收的相关性很差，而且差得具体： AI 评委 top 10 里有 6 个被人类评为弱，最终获胜者在 AI 排行榜上排第 19（[00:09:12]）。 2. ⚠️⚠️ 他没有宣布 SaaS 已死，而是把账算完后把结论落在"所有权与责任的交换"上： 复刻约 $1,000 token + 约 $10,000 AI 工程专业度，⚠️ 但"从此你拥有它，也就意味着 你要负责维护它"（[00:25:23]–[00:26:23]）。 3. ⚠️ "三件所有人都栽的事，没有一件写在文档或原产品说明里——只有像真实用户那样用它才会 立刻发现"（[00:07:08]）。

一、被替掉的是什么，以及为什么他改了主意

  • 标的：会议/活动管理软件（原产品 Session Board），用于管理讲者； 报价 $43,000/年、四场活动。他的对照是"43K 可是很多 token"（[00:01:01]）。
  • ⚠️ 买方视角的两条具体不满：
  • 变更请求的交付周期："买现成软件、提变更请求，常常要 3 到 6 个月，或者永远不会 真的发出我们想用的东西"（[00:01:01]）。
  • ✅ SaaS 是一个捆绑包："我们大概只用了这家供应商卖给我们的三分之一， 而没用的那些部分没有折扣"（[00:02:01]）。
  • ⚠️⚠️ 本页认为这一段是全期最值得记的立场变化，因为它附带了一条制度证据： 他说多年来公司的创始合同里明文写着——没有他的明确批准，任何人不得自建内部软件， 理由是"太容易得 not invented here 综合症"、太容易被"造本来可以直接买的商品化软件"分散注意力。 "今年我改了主意。我认为 agent 终于好到可以让我们拥有个性化软件了，而我正押上真金白银来验证。" （[00:01:01]–[00:02:01]）
  • 他对标的类型的界定（本页认为这条限定很重要）：这是"例行的中档业务软件"—— "不是 Salesforce，也不是你一天就能 vibe code 出来的东西，是中间那一档"， 而那里"有数十亿美元规模的烂软件正被普通人每天使用"（[00:03:02]）。

⚠️ 为什么这类软件比看起来难复刻

  • 待办事项链条（他逐条列的）：讲者投稿 → 评审打分 → 委员会接收 → 需要讲者门户上传头像与幻灯片 → 未完成任务要发提醒 → 排进某个房间与档期 → 改档期 → 讲者改标题后要正确出现在公开议程上 → 加共同讲者 → 再对受邀讲者、赞助商、参会者各走一遍（[00:03:02]）。
  • ⚠️ 角色是多重且会临时发明的：一个人可能同时是讲者 + 赞助商 + 参会者， 或者组织者、志愿者、供应商——"有时候我们就因为某个特定情况当场编一个角色出来"（[00:04:03]）。
  • ✅ 为什么活动行业极度风险厌恶，他给了后果口径：软件把我们推过截止日一周， 就会有人出现在错误的地点，或者会议干脆开不起来——"这些我们都经历过"， 还要付加急费、工会费（[00:04:03]）。 配一句行业观察："我认识的人里没有一个喜欢自己的会议 app。"（[00:04:03]）

二、竞赛是怎么跑的

  • 给builders 的材料：他本人写的 brief + 真实产品的操作录屏 + brief 里附的 42 张截图； 冠军奖金 $10,000；并为认真参赛者提供最多 $500 的 token 报销 （"因为没人会在一个 $20 的套餐上造这个"）（[00:04:03]）。
  • 规模：最终 72 个人/团队提交；"大多数仍然在线且开源"，会全部给出链接（[00:02:01]）。
  • ⚠️ ✅ 验收设计是本页认为这次实验真正的方法论贡献： 最终决定权交给他的真实活动团队，而不是他本人—— "他们不懂技术，不在乎你用什么栈、什么 agent、什么模型，不在乎开源还是闭源。 他们只在乎自己到底会不会买、会不会用。"（[00:02:01]） 他把这叫做"半盲评测（semi-blind eval）"（[00:05:05]）。

⚠️⚠️ 三件所有人都栽的事——而且都不在规格里

  1. 多种门户：讲者、受邀讲者、赞助商各自需要自己的门户， 而"多数提交只造了一种门户，而且不太灵活"（[00:05:05]）。 ✅ 验收方 Kelsey 的原话给出了更精确的区分：她称赞某个提交是 "少数真的把 form 和 portal 的区别解析出来了的"，而最大的减分项是 缺少让管理员配置多个不同门户（CFP 门户、赞助商门户、受邀讲者门户）的能力—— "这也是我们在 Session Board 里有的功能"（[00:05:05]）。
  2. 拖放（drag and drop）：他称这是"UI 里更复杂的元素之一，模型很难做对"。 ⚠️ 测的不是能不能拖，而是三件事：放下时那个 section 是否真的移动了、 你能不能看出它是已确认还是已更新、歧义有没有被表达出来—— 因为"显然你不能让同一个人同时出现在两个 session，也不能把同一个房间同一时段 重复预订给多个 session"（[00:06:06]）。 ⚠️ Kelsey 给了一条很具体的"工具提示反而暴露问题"的观察： 提示告诉你"点这里加一个 session"，但它感觉像是一层覆盖层，而没有真的去做它正在教你做的事—— "我就想，我为什么不能直接点那个按钮在那里加一个 session？"（[00:06:06]） 她同时说明自己为什么把拖放列为判据：它能让她判断"他们到底有没有照着说明做"（[00:07:08]）。
  3. 不走 CFP 表单直接加一个 talk——受邀讲者或 VIP 需要这个（[00:07:08]）。
  4. ⚠️⚠️ ✅ 本页认为这是全期最该被引用的一句： "这三件没有一件在我们的文档或 Session Board 的说明里被好好写明—— 但只要你像一个真实的人那样去用这个产品，你会立刻发现它们。"（[00:07:08]）

三、⚠️⚠️ AI 评委 vs 人工验收：本页认为这是本期最有价值的数据

  • AI 评委的定位是他自己先声明的：公开发布、但不用来决定冠军， 只是让参赛者把应用跑起来的 sanity check—— ✅ "基本上是一个去掉了 RL 的 RL environment"，一个供人 hill climb 的环境（[00:07:08]）。
  • 实现：Claude 以每一种角色登录、点完他们写的 20 个正常用户流程场景， 再用 Claude 打分；这样"按钮叫什么、放在哪里，你有灵活度"（[00:07:08]）。
  • ✅ 他给其他人的操作建议：如果你要办这种竞赛， 把自己点完整个应用的过程录下来、转成场景、发布出去让人 hill climb（[00:08:09]）。
  • 覆盖与饱和：56 个应用跑过这套评测，其中 40 个覆盖度足够参与排名； ⚠️ 前七名彼此相差 2.3 分之内——"基本上就是饱和了"（[00:08:09]）。
  • ⚠️⚠️ 而人工验收与 AI 评委的相关性很差，这是本页认为最该被记的一组数字（[00:09:12]）：
  • AI 评委 top 10 里有 6 个被人类评为"弱"；
  • 最终获胜者在 AI 排行榜上排第 19；
  • 他自己的定性是"所以它挺弱的，有某种 R² 相关性但远不完美——而它本来也不打算是"。
  • ✅ 他明确说明一部分不相关是故意设计的：他们允许参赛者按自己的品味偏离规格， 而且是鼓励——因为"老实说这同时也是一次招聘练习，在找能带着品味写代码的人"。 目标是找理解待办事项本身、而不是机械克隆产品的人，能定义什么叫好的用户体验、 并代入真实测试者的角色（[00:09:12]）。
  • ⚠️ 他对这次竞赛客观性的自我定性非常直白： "所以这场竞赛其实并不客观。评分细则没有良好定义，规格也没有良好定义。" "如果真有一张清单，我们就能发布清单了"——他们确实发布了一张可克隆的清单， 但"品味才是我们真正想从那些操纵编码 agent 的人身上找的东西"（[00:09:12]–[00:10:12]）。
  • ⚠️⚠️ ✅ 一条来自参赛者的独立确认，本页认为它是上面那组数字的机制解释： 参赛者 Open Stash 告诉他们，他们最自豪塞进应用里的大部分东西，AI 评委完全没有覆盖到。 "而他们是对的。而我们之所以发现这一点，是因为我们让人类点过了每一个应用。"（[00:10:12]）

四、他们到底怎么造的：过程数据

  • 规模数据：公开 repo 的中位数是 91,000 行代码，"人们连着好几天跑 agent"（[00:10:12]）。
  • ⚠️ ✅ 模型使用分布，以及他自己给出的"没有 alpha"结论（[00:10:12]）：
  • Claude Code 与 Codex 基本打平；
  • 66 份提交里有 40 份同时用了两者；
  • "几乎所有人都混用了不同模型家族"；
  • 三位入围者都用了同一款 GPT 系模型，但另外 66 份里也有 50 份用了—— "所以这里没有 alpha。" ⚠️ 型号在字幕里损坏，本页不写定。
  • ⚠️ 他主动对照了自己的做法，而且是反过来的： "我自己通常一个项目只用一个模型，这样所有 context 都留在一个地方"—— 他要一条 Codex 线程覆盖全部、也要一条 Claude Code 线程对它最擅长的任务做同样的事。 "结果很多这些 builder 不这么干。他们会切换角色。"（[00:11:13]） ✅ 本页标注这是一条难得的"主讲自己的实践被自己的实验数据反驳"的记录。
  • 材料可查：他们让 builders 自愿把 prompt 与过程文档提交到 GitHub， "所以你可以真的读到他们到底怎么做的"（[00:11:13]）。

⚠️ 他从提交物里挖出的三种多模型协作模式

  1. 聪明模型决定做什么，便宜模型当"slot cannon"去写被指定的东西。 例子：Cboard HQ——Claude 做计划与评审，Codex 写大部分代码（[00:11:13]）。
  2. 一个模型造、另一个模型检查，而且通常由"更擅长驱动浏览器或做测试"的那个来检查； 他说"我认为现在那个是 GPT Codex"（[00:11:13]–[00:12:14]）。
  3. ⚠️⚠️ ✅ 没有模型批准自己的工作——本页认为这条是三者里最有机制含量的： Green Room HQ 让一个 Claude 团队和一个 Codex 团队在各自的 worktree 里跑， 在对方验证之前谁都不能 merge。 他给的原理是"on-policy 与 off-policy 验证"： "agent 对自己的工作往往比对别人的工作更宽松。而我认为这也反映了人类的行为。"（[00:12:14]）

五、三位入围者的共同做法：代码之前的工作

✅ 主讲自己总结的共同点是"在任何代码被 prompt 出来之前他们做了多少工作"（[00:12:14]）。

  • Marco（TrackStage，第二名）——先把一切计划完。他此前给客户做过克隆应用，规则是先规划： "如果 UX/UI 已经定了，我唯一做的事就是坐下来 8、9 个小时，以最细的粒度规划出整个 数据 schema、业务逻辑，以及字面意义上的伪代码。" ⚠️ 他紧接着那句对照本页认为很有分量："有点好笑，因为如果你把我四五年前做的这些任务、 加上设计，字面上塞进一个 LLM，然后走开两三个小时，你就能拿到整个东西、像素级完成。" （[00:13:14]） 他的具体做法是把主讲给的操作录屏 + Session Board 的 API 文档直接喂给 Claude， 并指定自己偏好的栈（Convex + Next.js），理由是速度很重要—— Convex"给你一个实时数据库，不用太多功夫就能得到高性能、手感好的东西"（[00:16:17]）。
  • Yazin（Conferencer，第一名亚军）——从研究开始。 他先把 Google Doc 转成 markdown，然后用 firecrawl 爬完了 Session Board 的整个帮助门户， 以及搜索结果里几个类似站点，"就是想尽可能多拿信息"（[00:13:14]–[00:14:16]）。
  • Valentin（获胜者）——把力气花在护栏上，并把它变成可复用模板。 "我把它做成了一个模板而不是形式化文档……很多项目我都得重做这套老活， 而这个项目就是个完美例子……如果有人要接手这个项目，你希望他能在上面写代码， 所以我花了很多时间放那些 link、那些 code review 之类的东西，现在我直接把它做成了一个 GitHub 模板"，每个新仓库从它克隆，"而不是有一个 Google Doc 写着我做过什么"； 完全开源（[00:14:16]–[00:15:17]）。
  • ⚠️⚠️ ✅ Valentin 的探索方法本页认为是本期最具体的一段 agent 使用记录（[00:15:17]）： 他让 Codex"给我画出这个 app 每一个功能的每一条流程"。 令人意外的是 agent 用的是一堆 YouTube 视频——逐帧截图去判断"哦，这里发生了什么"。 产出是一大堆 markdown 文件夹，每个功能都写明预期； 然后才是规划：把它切成可以并发做的部分（有些功能会重叠所以必须串行）， "为每一步定出能并发多少个 agent，然后全部跑起来"。 ⚠️ ✅ 而他接下来发现的那个问题，本页认为是这段的真正落点： 跑完之后他手工走了一遍，发现"不完美。为什么？因为我看到他其实从来没有在本地把 app 跑起来。" 于是下一步是把整个流程重做一遍，但这次 app 在本地跑着。
  • ⚠️⚠️ ✅ 主讲对这一节的收束，本页认为应当完整保留： "所以如果你看这些片段，注意没有一个人说自己打了一条 prompt 然后走开。 真正的情况是，那条 prompt 几乎是最后一步——你是在建立起对问题的完整认知、以及 mock、 文档、规格这些东西之后才走到它。大部分工作是搞清楚这个软件到底在做什么， 然后他们才能从那里偏离出去。"（[00:16:17]）

⚠️ 自己当真实用户，反复用

  • ✅ 主讲转述的一条诊断：有人写道"agent 非常擅长构建，但相当不擅长注意 UX 问题"。 具体例子：头像上传功能把照片存到了某处，但公开讲者页面根本不从同一个地方读取， 因为那是独立编码出来的（[00:17:17]）。
  • ✅ Valentin 的"五分钟测试"： "我就把自己放在你的位置上想：如果我只有五分钟测这个产品，那会是什么样？ 而只要那五分钟不顺，我就会把整个流程重做一遍。"（[00:17:17]）
  • ⚠️⚠️ ✅ 而他的归因方式是本页认为这一节最该被引用的部分（[00:18:18]）： "我的目标从来不是手工去做任何'我不喜欢这个、我不喜欢那个'的事。" 他的做法是让 agent 去查自己的 trace 来理解根因。 他举的例子是 onboarding：agent 回他的话大意是—— "这只是一个关于 onboarding 的标题，而 onboarding 就是要 onboard， 但我们根本不知道什么才叫好的 onboarding。" "所以我就知道，这个流程里要解决的不只是'做一个 onboarding'， 而是'什么定义了好的 onboarding 路径、什么定义了坏的'。 于是我让他重做整个流程，但加入一步：去研究什么才定义了好的 onboarding。" ✅ 即把一次 UX 失败转化成一条缺失的规格研究步骤，而不是一次手工修补。
  • Yazin 的版本是"点着走、记一张待修清单"：agent 做完会把视频发回给他， 他点着走才意识到"在不同视图之间切换真的很烦"—— 实际上你得先登出再登入，于是他发现自己还没加用户名密码， 补上了登录、门户切换、resend 支持，以及其他"很明显的"UX 问题（[00:18:18]–[00:19:19]）。
  • ✅ 一条来自验收方的正面意外：Kelsey 谈 Conferencer 的 deliverables 页面—— "你的调整很棒。我给我们的内容经理看，她说'什么？这全在一页上？ 你不需要点进单个表单就能看到状态？'她就说那太惊人了。"（[00:19:19]） Yazin 的自述是结构做完"看起来还行"，但他觉得菜单重组、加图标、让东西在逻辑上聚起来会合理得多， 于是对 deliverables 页和 abstracts 页做了大改—— 因为那个页面"看起来非常像个表格，而你是想让它像一个真正的 UI"（[00:19:19]–[00:20:19]）。

六、⚠️⚠️ 他自己给出的反方：为什么这还不叫"杀死 SaaS"

✅ 本页认为这一节是本期最重要的部分，因为它是出题人自己在给自己的结论设限。

  • ⚠️ 起手句："克隆一个看起来能用的东西，才真的是容易的那部分。 而我们用这么多提交证明了这一点——它们都是相当不错的第一版克隆。 但还是得有人让它一直跑着。接 bug 报告，凌晨两点去修。"（[00:20:19]）
  • 他给的现场证据来自自己团队："就在昨晚，我团队的 Flo 在一场 AI Engineer 会议 已经在进行的情况下，往我们的 token billionaires 项目上扔了十几个 Codex agent"（[00:20:19]）。
  • ✅ 他把这条取舍压成一句对称的话： "你搞坏了它，它就是你的。而很多人也在说反过来的那一面：你拥有了它，你就能搞坏它。"（[00:20:19]）
  • ⚠️ Kelsey 从运营侧给的"拼凑效应"诊断（他说她讲得比自己好）： 现在是"多个东西用某些 API 彼此拼凑（hodge-podge）在一起，有的能跟另一个说话"， 而他们想要的是一个一体化系统——"登记数据进赞助商门户，赞助商门户立刻能进我们的排期"。 ⚠️ 她的限定条件给得很实："我们正受困于这个拼凑效应，而我们懂得足够多， 能说出'我们想要更好的、我们能做得更好、我们需要更好的'。但我们没有时间。 所以我们不能 prompt 那些 agent……一旦有什么坏了，我们需要有人能进去修。"（[00:21:19]）
  • ⚠️⚠️ ✅ "刷新缓存"那个故事，本页认为是全期最有说服力的一段买方论证（[00:21:19]–[00:22:19]）： 赞助商来报 bug（"我没法取消分配这些票"）→ 她找供应商的聊天客服 → 客服找他们的工程师 → 工程师回给客服 → 客服回给她，答复是"你能试试刷新缓存吗？"
  • 她的回应："我不会让我们的赞助商为了修一个离他两步远的 bug 去刷新缓存。 我不能要求一个在数千万美元公司里的人，因为我们这边搞坏了什么，而去刷新他的缓存。"
  • ✅ 而她把它归结成一条本页认为可直接引用的判据： "所以这里有一个问责（accountability）的层次：我不在乎你怎么修。我需要它不坏。"
  • 主讲由此给出他建团队的优先级：他告诉 Yazin，新的内部软件工具团队 "应该先替掉我们自己的软件，因为那是会让所有人都高兴的事"，然后再谈别的（[00:22:19]）。 Yazin 的呼应是："深入进去，然后造那种不是整块里的一小片、而是整个东西的软件"—— 看看"如果你把整个愿景造出来、以任何拼凑式软件都无法做到的方式，体验会是什么样"（[00:23:21]）。

七、结果与他的成本账

  • 验收结论：5 个应用达到了"我们会真的采用、或认真考虑购买"的门槛（三位入围者 + 另外两个）； 另有 12 个项目里有他们"大概会偷来用"的想法，即便不会用整个应用；全部开源（[00:23:21]）。
  • 名次与理由：
  • 第二名亚军 $1,000 — Marco Kramer / TrackStage： 全场最干净的拖放 + 复杂排期 UI 体验，以及一个文档做得很好的 repo—— "想学怎么跑一支 agent 舰队，去读它"（[00:23:21]）。
  • 第一名亚军 $5,000 — Yazin / Conferencer： 点击通过整个应用的直觉体验遥遥领先、每个 deliverable 都显示在一页上 （即 Kelsey 兴奋的那条），以及讲者生命周期每一步都有真实邮件—— "它让事务性邮件变得享受，而那是件很难的事，我们有经验"（[00:24:22]）。
  • ⚠️ ✅ 冠军 $10,000 — Valentin de Matas： 评语本页认为值得完整记——"他造了一座软件工厂，调试了那座工厂， 交付了多个门户，以及一个我们团队真的想用的排期表"， 并且大概会被交付给 2027 年的 AI Engineer 会议使用（[00:24:22]）。
  • 他们打算怎么用：2027 跑的大概是获胜项目 + Conferencer 的混合， 再加上另外 12 个里的想法（[00:24:22]–[00:25:23]）。
  • ⚠️⚠️ ✅ 本页认为这条关于"谁在写代码"的观察最值得被引用： "我团队里写代码最多的人不是工程师。他们是设计师、是领域专家、是运营人员—— 就是真正在做这件事、在报告一切的那些人，而且他们的 bug 报告和功能请求能拿到分钟级的周转。" （[00:25:23]） 他对团队感受的描述是：现在他们知道"2026 年造的活动软件可以是什么样， 而不是 2006 年造的软件"（[00:25:23]）。
  • ⚠️⚠️ ✅ 成本账与那条取舍（本页认为这是全期的结论句）（[00:25:23]–[00:26:23]）：
  • "如果你在租一个你并不喜爱、也永远不会拥有的软件，现在自建是一件合理的事了"， 而且他们已经把路线图发布出来了。
  • 复刻一块中档软件的成本：token 大约 $1,000（按订阅算）， 再加大约 $10,000 的 AI 工程专业度——"而这些提交者里你大概可以雇到一些人"。 ⚠️ 对照是他原本要付的 $43,000/年。
  • ⚠️⚠️ 但取舍他说得很清楚："然后代价是，从此你拥有它——这也意味着你要负责维护它。 这不是一笔不重要的交换。但严格意义上它也不是负面的， 因为 agent 让为你自己团队维护和定制软件，比 12 个月前可行得多。"
  • ⚠️ 一条诚实的过程自白：他为拖了很久道歉—— "事实证明，evals 很难。" 当时他们在同时跑两场会议、还有各自的本职工作， "第一次跑是个非常混乱的过程"，下次会规划得好得多、不再一个人干（[00:26:23]）。
  • ⚠️ ✅ 最后一条立场变化，以及他明确否掉的那个理由（[00:26:23]–[00:27:23]）： 团队从怀疑 AI vibe code 出来的应用，变成现在主动要求， "而且兴奋的不是省钱。省钱是其中一部分，但真正的点是拿省下来的钱去资助 那些我们从来付不起的实际软件改进。" 他的原话落点是："我宁愿付 token 钱，然后把我的时间用来造那种我的参会者、赞助商、 讲者真的会享受、也值得拥有的软件。"

⚠️ 本页的四条克制标注

  1. ⚠️⚠️ 这是自制内容，主讲同时是出题人、奖金提供方、买方和结论叙述者，全期没有任何外部声音。 ✅ 但本页认为它的证据结构好于一般的自说自话，理由有三条可查： 验收交给了不懂技术的运营团队、AI 评委与人工评分的背离被主动公布（而且对他不利）、 参赛者的 prompt 与过程文档公开在 GitHub。
  2. ⚠️ "杀死 SaaS"这个标题与内容不符，而不符的方向是内容更保守。 他明确说克隆是容易的部分、维护责任是真代价，并且没有宣布 SaaS 已死。 本页按内容收录，不按标题。
  3. ⚠️ 成本数字（$1,000 token + $10,000 专业度 vs $43,000/年）是他的口头估算， 期内无明细、无口径说明，且不含他自己点出的维护成本。本库记为量级示意，不作为核算。
  4. ⚠️ 自动字幕的专名损坏见页首声明；三处判为不可靠而未写定： 三位入围者共用的那款 GPT 系模型型号、获胜项目名、两处项目名。

交叉链接

  • Latent Space 主播 — 主讲页（含本期可确认为 swyx 的依据）
  • AI 商业与价值捕获 — ⚠️ 本期是对 DHH"各自造自己的 5%" 那条论断的第一次带人工验收的经验检验，并给出了它的边界条件（维护责任、问责层次）
  • 在实践中使用 LLM — 多模型协作三模式、"prompt 几乎是最后一步"、五分钟测试、"让 agent 查自己的 trace 找根因"
  • 评估与基准 — ⚠️⚠️ AI 评委 top 10 中 6 个被人类评为弱、获胜者在 AI 榜上第 19； "去掉 RL 的 RL environment"作为 hill climbing 脚手架；前七名 2.3 分内的饱和