Railway：面向代理原生的云平台——Jake Cooper

参与 2026 年 AI 工程调查，可获得超过 $2k 的信用额度和 AIE WF 门票！

Railway 于 5 月 19 日遭遇重大 GCP 故障，尽管其基础设施是跨可用区、跨区域的网状架构，且通过专用光纤连接了 Metal <> GCP <> AWS，但因工作负载可发现性仍意外依赖 GCP 而受到影响。事后已通过事后分析完成修复。

Railway 最初并非一家 AI 基础设施公司。

它成立于 2020 年——在代理成为软件部署默认模式之前。创始人 Jake Cooper（前 Bloomberg 和 Uber 工程师）创立 Railway 时怀有一个简单信念：将代码部署到生产环境所需的激活能应接近于零。只需推送代码、获取 URL、快速迭代。无需 Dockerfile、Kubernetes 清单或堆叠的 Ansible 脚本。

视频 3

数年间，这是一场漫长的征程。Railway 前 18 个月手动获取首批 100 名用户，Jake 甚至亲自在第二台显示器上迎接每位 Discord 新注册用户。

如今，Railway 已融资 $1.24 亿并实现快速增长。35 人团队支持 300 万用户，每周新增约 10 万注册用户。其自建裸金属数据中心的回本周期仅为 3 个月，远超云租赁方案，70% 的利润率为必要时的云爆发提供资金保障。随着内存价格飙升，他们自有的服务器资产价值已超过公司所获融资，形成独特优势。

从周末重构网络覆盖层到将绝大多数工作负载迁移至自建[裸金属数据中心](https://blog.railway.com/p/data-center-build-part-one)，Jake Cooper 正致力于打造面向代理原生时代的新型云平台。本集访谈中，Railway 创始人兼“指挥官”将与 swyx 和 Alessio 探讨为何下一代软件基础设施不仅仅是“更新版 Heroku”，代理需要哪些人类开发者不需要的功能，以及 Git、PR、CI/CD 和静态云资源的传统部署循环可能面临重构。

我们深入探讨 Railway 的基础设施栈：自建裸金属数据中心、3 个月云回本周期、云爆发、数据中心债务、Railpack、Nixpacks、Temporal、功能标记、Central Station、内容寻址文件系统、代理安全生产分支，以及为何在代理世界中 CLI 可能比画布更重要。Jake 还分享了 Railway 的创始人历程——如何熬过每月亏损 $500k 的阶段，为何如今仅用 35 人服务百万用户，以及为何他认为拉取请求正在消亡。

讨论要点：

• Railway 如何从六年缓慢增长转型至每周新增 10 万用户
• 将代理视为下一代主导型软件物种的思维
• 为何代理需要在千倍规模下实现版本控制、可观测性、计算、存储和编排
• Railway 自建裸金属数据中心的经济模型与 3 个月回本周期
• 自建基础设施扩展时如何结合云爆发
• 为何数据中心债务比风投债务更适合基础设施初创公司
• Railway 内部系统Central Station：用户反馈与事件聚类
• 负责任披露与过度沟通为何对平台至关重要
• 功能标记、渐进式发布和影子流量对代理的必要性
• Temporal 的优势、痛点及工作流对代理的意义
• Railpack、Nixpacks、Nix 和惰性加载内容寻址文件系统
• 若能克隆“宠物服务器”，“畜养而非宠养”范式会如何变化
• 为何 Railway 选择从零构建新云而非复制超大规模云服务商
• 单创始人路径、专注力、写作与公司建设方法论

Railway：

• 官网：https://railway.com/
• X：https://x.com/Railway

Jake Cooper：

• LinkedIn：https://www.linkedin.com/in/thejakecooper/
• X：https://x.com/JustJake

00:00:00 引言：Railway 是什么？

00:02:07 Jake 的创业之路

00:06:13 Railway 六年增长历程

00:08:52 免费层后的业务重建

00:11:17 代理：下一代软件平台

00:13:29 Railway 的基础设施哲学

00:15:42 裸金属、云经济与算力瓶颈

00:17:22 云爆发与五云网络

00:20:20 数据中心债务与基础设施融资

00:23:31 太空数据中心

00:25:24 基础设施需为代理提供的能力

00:28:24 CLI、画布与代理原生 UX

00:35:15 Central Station、事件处理与负责任披露

00:40:30 安全发布、代理 SRE 与生产分支

00:45:00 AI SRE、规格、代码与测试

00:48:24 自我复制基础设施与新无服务器范式

00:53:18 Heroku、Temporal 与工作流引擎

01:04:07 Railpack、Nixpacks 与惰性加载文件系统

01:06:01 代理开发、代币支出与路线图加速

01:10:56 拉取请求正在消亡

01:12:28 功能标记与代理时代 SDLC

01:16:15 服务器：畜养还是宠养？

01:19:29 单创始人经验谈

01:24:12 专注力、GPU 与新云构建

01:28:20 结语

Alessio [00:00:00]: 大家好。欢迎来到《Latent Space 播客》。我是 Alessio，Kernel Labs 的创始人，今天与我一起的是 Latent Space 的主编 Swyx。

Swyx [00:00:10]: 嘿，嘿，嘿。今天我们邀请到了 Railway 的 Jake Cooper。

Alessio [00:00:14]: Railway 的 Conductor。

Swyx [00:00:15]: Railway 的 Conductor。没错。

Alessio [00:00:16]: 呜呜呜。

Swyx [00:00:17]: 你真的把这个头衔印在名片上了吗？

Jake [00:00:20]: 我们称一些志愿者版主为 Conductor。我自己没有名片，公司还没到那个规模。不过以后可能会有。Supermicro 的同事给我一张名片，我心想：“天哪，这也太正式了。”

Swyx [00:00:30]: 名片又流行起来了。

Jake [00:00:32]: 名片确实很酷，很时尚。Conductor 这个称呼不错。我们还在琢磨内部怎么称呼彼此。有人觉得这很尴尬，说“内部不需要称呼”，但有些人想有个名字。目前还没找到特别合适的。

Jake [00:00:55]: 我们试过 New Railcrews、Trainiacs，但都没能流行起来。

Swyx [00:01:00]: 我挺喜欢 Trainiac 这个称呼，听起来不错。Railwayians 也行。对还不了解 Railway 的人来说，先给个清晰的定义吧。

Jake [00:01:09]: Railway 是部署一切的最简单方式。你可以通过画布界面，或与 Claude 对话，输入“部署 Postgres 实例、部署我的 GitHub 仓库、运行这段代码”，然后立刻开始执行。

Swyx [00:01:22]: 你们首页的动画效果不错。

Jake [00:01:24]: 谢谢。顺便说，这可不是我的功劳。现在他们不让我碰设计相关的工作了。

Jake [00:01:25]: 我们希望不仅让部署变得简单，还要让应用随时间迭代也轻松。目前大多数工具堆砌了复杂性：Docker、Kubernetes、Ansible 脚本等等。如果我们能为所有软件版本化并跟踪变更，就能轻松克隆环境、分叉到平行宇宙、复制生产数据、复制任意服务，进行修改、验证，最后无缝合并，而无需在预发布环境重复搭建所有内容。

Swyx [00:02:07]: 看你的背景：Bloomberg、Uber。这些经历似乎和“创建下一代平台即服务”没什么直接关联。是什么让你为 Railway 做好准备的？

Jake [00:02:21]: 是出于不断深入探索的好奇心。我最初做前端开发，参与过 Wolfram Mathematica 的移植工作。后来短暂加入 Bloomberg，接着转向 Uber 的分布式系统，将 Jump Bikes 系统迁移到基于 Cadence（也就是 Temporal 的前身）的分布式架构上。

Swyx [00:02:44]: 顺便说，我很想聊聊 Cadence 的优缺点。

Jake [00:02:48]: 当然可以。

Swyx [00:02:51]: 不过还是先说说 Railway 的故事吧。

Jake [00:02:52]: 我们始终围绕体验展开。无论是扫码解锁自行车的无摩擦操作，还是其他任何场景，实现这种体验需要深入底层。团队愿意为体验做任何事。我们甚至会潜入技术的最底层——上周我直接给内核打补丁，因为我知道这样能让体验更好。

Jake [00:03:17]: 我没有物理博士学位，但读的是电子工程与计算机科学专业。一直以来，我都在思考如何一步步实现目标。正是这种追求让我创立了 Railway，并一路深入到裸金属数据中心。上周我甚至给内核打补丁，因为我知道这样能让体验更好。

Swyx [00:03:49]: 这周还有给 Linux 内核打其他补丁吗？

Jake [00:03:51]: 是的，不过没提交到上游，只是我们自己的分支。

Swyx [00:03:52]: 这很厉害啊。是 Railpack 吗？不，这不一样。这是 Railpack 之上的操作系统？

Jake [00:03:57]: 不，这只是个内核补丁。我们始终在思考：要实现这种体验需要什么？然后想办法解决。任何问题都能解决。

Swyx [00:04:10]: 你们会把补丁提交到上游吗？还是说它不符合其他用例？

Jake [00:04:13]: 也许吧。但我们得先内部验证体验。这和我们正在构建的代理功能存储层有关。或许对上游有帮助，但对我们内部来说已经非常实用。

Swyx [00:04:29]: 你之前提到过开源。你们是怎么看待从开源起步，然后通过代理代码让分支功能更强大的？

Jake [00:04:38]: GitHub 的原罪在于，它几乎成了断链的集合。你克隆了一个项目，就失去了与上游的联系。我们如何让人们轻松修改其中的微小部分？

Jake [00:04:51]: 我们习惯用 Git 的离散方式：要么提交修改并合并到上游，要么不。如果采用百分比渐进的方式，让变更像流一样逐步推进，用户按比例体验，最后全部合并，会怎样？

Jake [00:05:13]: 我们有开源回扣计划和模板部署功能，让人们能轻松为这些碎片化模块版本化。这解决了身份验证、授权和安全方面的难题。就像 NPM 可以定义“不接受新包”一样。理想状态是逐步向用户推出，最小化影响范围，最后再合并。JPMorgan 这类机构应该最后应用补丁，毕竟我们的资金和生计都系于其上。

Jake [00:05:53]: 即使 Johnny Vibe Coder 的补丁出现故障也没关系，因为系统中存在太多不确定性，最终必须落地实施。你必须在不同层级进行测试。

Swyx [00:06:13]: 我想调出这张精彩的图表，是展示用户使用量还是每日新增注册数？

Jake [00:06:22]: 我觉得是每日新增用户数。

Swyx [00:06:24]: 你们六年前起步，经历了漫长积累，现在正乘火箭上升。你说“不要怀疑自己的坚持，不要放弃”。或许可以挑选公司发展的关键转折点？

Jake [00:06:40]: 初创阶段的核心是无论如何都要获取前100名用户。我们当时有个网站和客服链接，客服链接就是 Discord 频道。我开着两台显示器：一台用于工作，另一台显示 Discord。只要有人加入，我立刻打招呼“嗨，最近怎么样？”。用户很少，所以让这前100名用户持续留存是关键起点。

Jake [00:07:14]: 接着要打造“咨询服务工厂”，因为用户会不断提出各种需求。你必须回到画布上重新思考：“我到底想在这个基础上构建怎样的产品？”

Jake [00:07:28]: 风投希望看到持续增长的图表，但现实中未必需要这样。对我们而言，存在扩张期——添加功能测试用例，也有收缩期——思考“如果现有体验不错，如何大幅优化？”可能需要剥离不再符合 ICP（理想客户画像）的功能。

Jake [00:07:57]: 2022到2023年的爆发式增长来自免费层级。所有人都在使用它。

Swyx [00:08:09]: 包括 Reddit 机器人和 Discord 机器人？

Jake [00:08:12]: 还有加密矿工。当你在互联网上构建开放产品允许任何人注册时，网络环境很糟糕。你会经历“如何触达更多人”的阶段，然后转向“如何精准满足真正兴奋的核心用户的需求”。

Jake [00:08:39]: 接下来是两年的商业化攻坚期。在免费层级阶段，我们每月亏损约50万美元。

Swyx [00:08:59]: 当时银行账户有2000万美元？

Jake [00:09:02]: 是的。2000万美元存款但每月仅5万美元收入，这简直是糟糕的生意。我不知道投资人怎么想的。但必须经历这个阶段——“我们有用户喜爱的产品，但商业模式必须成立”。

Jake [00:09:17]: 有两种思路：要么继续用低利润率烧钱扩张，要么回头解决问题。我们始终追求极简团队。现在只有35人，规模很小。

Swyx [00:09:36]: 已经支撑300万用户了？

Jake [000:09:38]: 是的。当前每周新增10万用户，增长很快。我们不为扩张而盲目扩招，而是构建系统。但扩张期很难建系统，因为用户不断提出新需求或系统出现故障。

Jake [00:10:00]: 我们曾暂停免费用户服务，重建商业模式。我们希望触达尽可能多的人，因为软件至关重要。在物理世界创造事物变得困难，所以必须让虚拟世界创造更简单。但这条道路有阶段性目标。

Jake [00:10:30]: 图表中的波动可见。观察2025到2026年数据，夏季和冬季会有明显低谷。

Swyx [00:10:50]: 影响这么大？

Jake [00:10:51]: 是的。我们兼具B2C和B2B属性。用户持续活跃后突然停滞。现在的激活曲线显示更多用户在工作日活跃，因为企业用户增多，整体趋势逐渐平稳。

Swyx [00:11:17]: 你们何时开始优先发展AI或代理开发？

Jake [00:11:24]: 我们将智能代理（agentic）作为获客入口。过去半年深度聚焦代理机制，因为相信其学习曲线陡峭，这将是未来构建和部署软件的方式。

Jake [00:11:42]: 是否属于“dot-com”模式其实不重要，因为我们本就在互联网中。当代理并行运行数千个实例时，推理成本、计算成本如何优化？如何协调这些代理？人类协作尚且困难，工具还不完善。现在必须解决代理间的协作、安全版本控制，以及何时需要人工干预。否则会变成不断中断的工厂。

Swyx [00:12:13]: 你说“dot-com”是指注册域名，还是泛指互联网公司？

Jake [00:12:17]: 指互联网泡沫时期。当时公司因认识到互联网重要性而暴涨，但随后遭遇物理限制、数学模型失效，最终回归现实。但互联网最终产生了深远影响。若时间跨度足够长，就应该坚持建设，因为能预见未来方向。

Jake [00:12:45]: 这正是代理技术的现状。当并行运行数千个代理时，如何处理推理成本、计算效率？如何协调所有组件？人类协作工具尚不完善，现在必须解决代理间的协作、安全迭代，以及何时需要人工介入。否则会变成不断中断的系统。

Swyx [00:13:19]: 我们直接切入技术层面。Railway的核心基础设施或架构理念是什么，让你们能实现这些目标？

Jake [00:13:29]: 基础组件对我们至关重要。我们需要网络、计算、存储，以及围绕这些的编排能力。你必须掌控这些要素。我们之前讨论过为何不使用Kubernetes——因为我们想要更高阶的控制权，将工作负载部署到非常具体的位置。

Jake [00:13:48]: 原因在于必须高效利用代理：内存复用等优化，否则成本结构会失控。能够自行搭建服务器和金属裸机（bare metal）能提升性能并降低成本。同时运行1000个代理实例也不会造成巨大的成本压力。

Jake [00:14:13]: 代币使用和计算需求正在爆炸式增长。长期来看这些必须变得更高效。通过自建硬件获得的利润空间，能让你提供更稳定的服务。这最终是为了让更多人获得差异化的体验。

Swyx [00:14:51]: 你们在新加坡有数据中心。

Jake [00:14:53]: 是的。现在每个区域都有两个数据中心。新加坡的第二个将在第三季度上线。

Swyx [00:14:58]: 这是什么体验？我从未建过数据中心。你是去Equinix说“我要几个机位”吗？

Jake [00:15:05]: 对，就是Equinix。你去说“我要电力和机笼”，他们会说“好的，这是方案”。然后租用机笼一段时间，填满服务器机架，连上网络就完成了。就这么简单。

Swyx [00:15:36]: 其他事情都由你自己处理？

Jake [00:15:37]: 是的，其他都由自己处理。

Swyx [00:15:39]: 自建硬件和云服务的成本对比如何？

Jake [00:15:43]: 如果我们用云租赁，回本周期在转用金属裸机后仅需三个月。

Swyx [00:15:50]: 这太疯狂了。

Jake [00:15:51]: 确实疯狂。这相当于四年的硬件折旧成本。你会看到计算资源短缺加剧，因为超大规模云服务商正在大量采购设备。我们直接与OEM厂商和经销商合作，比如Supermicro、戴尔等生产机器。

Jake [00:16:11]: 上游供应链压力很大。上一轮融资时，服务器部署的资本支出加上现有资金，服务器因内存涨价带来的增值，现在账面资金甚至超过了融资金额。硬件价值飙升的程度令人惊讶。

Jake [00:16:50]: 看看超大规模云服务商，他们今年资本支出约800亿美元，明年还会增加。这是巨大的基础设施扩张。这支出甚至超过曼哈顿计划的规模。但若每个人都要并行运行几十甚至上百个代理，你根本无法想象需要多少计算资源——即使高度优化资源利用率，这还不包括推理计算。

Swyx [00:17:22]: 如何规划扩张？增长曲线如此陡峭。机架上线后是否立即达到100%利用率？你们提前多久规划？

Jake [00:17:33]: 我们仍保留云服务用于弹性扩容，与AWS、GCP等云服务商合作。需要时可以租用，一旦有空闲机位或电力资源，就将工作负载迁回自建硬件。我们最初从云起步，后开发迁移系统到自建金属。这种模式可无限重复，这就是我们的方式。我们绝不能让计算资源成为瓶颈。

Jake [00:18:09]: 年初时我们确实遭遇计算瓶颈，因上游供应商无法按需提供配额，硬件交付也延迟。我花了一周末重构整个网络覆盖层，让系统能跨Oracle、AWS、自建、GCP和其他云服务商运行。现在我们能做得更多。

Jake [00:18:38]: 我们曾因无法获得足够算力而被迫紧密堆叠实例，导致一些可靠性问题，但已解决。我发推指出，随着模型对算力需求激增，获取算力正变得越来越难。我们确实吃过这方面的亏。

Swyx [00:19:15]: 知道可能无法随时使用自建硬件时，你们如何定价？是否假设需要云服务时预留额外利润空间？

Jake [00:19:26]: 因为自建数据中心的利润率约70%，我们可以用这部分利润补贴云业务，实现合理增速。我们有多个杠杆：金属裸机（盈利核心）、云扩容、服务器债务融资、风险投资。这涉及复杂运营决策：手头现金多少？该融资多少？部署速度如何？能否让营收增速匹配算力扩张？

Jake [00:20:05]: 若持续降低开发部署门槛，我们就能越快闭环运营，越高效地管理资本，业务就能线性增长。

Swyx [00:20:20]: 我觉得基础设施初创公司用债务融资的工具未被充分使用。能谈谈你们的经验吗？债务是否以CPU作抵押？

Jake [00:20:32]: 是以硬件作抵押。

Swyx [00:20:37]: 利率如何？哪些机构提供贷款？

Jake [00:20:39]: 我们支付基准利率加利差，并且利率下降时可以对任何债务进行再融资。条款相当不错。不幸的是，Twitter上没有细微差别，所以人们会说“风险债务不好”。但就像所有事情一样，有特定的工具和领域可以有针对性地使用，而不是用一种工具当万能锤。风险投资并不是万能工具。必须探索并找出什么行得通。

Swyx [00:21:12]: 风险投资通常是你能获得的最昂贵的融资方式。

Jake [00:21:15]: 是的。我也认为人们从融资角度看待风险投资的方式有误。大多数人认为“如何尽可能多地从当时能拿到的最好的渠道融资？”这接近正确，但我们试图做的是找出用这些股权能买到的不公平优势。

Jake [00:21:34]: 在那个时间点，这是你将要给出的最昂贵的股权。假设公司会越来越好，如何利用它与能互补的顶尖人才合作？在种子阶段，我从未创办过公司。Ray Tonsing给了我很好的建议，我可以随时给他发短信。他反应很快。太棒了。

Jake [00:22:01]: 然后是John和Erica在Unusual，他们说：“你大致知道如何构建产品。我们会基本不干涉，但随时提供建议。”太棒了。到了A轮融资时，业务成了运营上的灾难，因为我们不知道如何扩展业务。与Erica合作，Jordan在红杉那边，所以是额外的好处。

Jake [00:22:28]: 现在我们从TQ和FPV融资，进军企业领域。每一步我们都问：在特定时间能与谁合作来解锁下一阶段的旅程？我不懂企业销售。作为工程师，我可以大致看出我们需要哪些功能，我们内部有很棒的人可以帮忙。但你想要董事会的动态是所有人目标一致，问“我们如何赢得这场竞争？”而不是为战略争吵。

Swyx [00:23:31]: 你发过关于太空数据中⼼的推文。为什么没有太空数据中⼼？

Jake [00:23:37]: 这不是“没有太空数据中⼼”。我的观点是这可以解决，只是没人解决过。

Swyx [00:23:49]: 你说“你怎么在真空中散去那么多热量？”这是物理问题。

Jake [00:23:55]: 我没见过有人证明如何在真空中散去那么多热量。这不代表不可能，只是还没人提出过。

Swyx [00:24:05]: astrophage。

Jake [00:24:06]: 我不知道那是什么。

Swyx [00:24:07]: 火星人相关的东西。好吧，你很理性。

Jake [00:24:09]: 可能有效。很多人本末倒置。他们说“我们要把数据中⼼建在太空。”好啊，但怎么实现？“我们有时间解决。”就像《火星救援》里他们问如何拦截某物，然后说“我们能解决。”

Swyx [00:24:36]: 押注人类发明很奇怪，因为盲目相信问题能解决。但物理有第一性原理的边界。也许不是，也许你要求的是突破时间旅行或热力学基本定律。

Jake [00:24:57]: 我也不懂风投怎么操作。如何判断什么是不可能的骗局，什么是看似疯狂但可能实现的？“我们要把数据中⼼建在太空。”这就像抛硬币决定，可能10年后就知道答案。一个周期。

Swyx [00:25:23]: 回到代理话题。你们做的分支、快速启动和编排像是代理需要的预工作。代理的需求与人类有何不同？

Jake [00:25:37]: 他们需要版本控制能力。差别不大，但实现方式稍有不同。代理需要逐步测试变更的方式。工程师用功能标记，代理不能用吗？我觉得可以。

Jake [00:25:54]: 他们需要版本控制。用Git还是不用？这还在讨论中。我认为随着时间推移，会有一种不同于Git的版本控制方式出现。他们需要可观测性。需要查询发生了什么、何时发生、哪些步骤失败、追踪、日志、指标等。他们需要网络、计算和存储。需要写文件、保存文件、迭代文件、快照文件系统。

Jake [00:26:25]: 人类需要的很多东西与代理需求一致。分支和分叉没有不同，只是速度快了1000倍。看起来需要完全不同的东西，但实际需要比现有技术好得多的东西。需要比Kubernetes更强大的编排，可能比Envoy更好的网络。整个技术栈都需要升级。

Jake [00:26:55]: 如果工作负载的配置文件没有变化，只是被极大压缩，因为需要成千上万个实例，那么哪些假设会改变？etcd会崩溃。需要替换它。你可以从技术栈底层开始，说“这部分必须改变，那部分必须改变”。

Jake [00:27:19]: 指数级增长曲线带来的有趣之处在于，必须构建可在任何时间替换组件的系统，因为新的瓶颈可能出现。擅长并行代理后，系统另一部分又出问题。所以和人类需求类似，但规模扩大了1000倍。

Jake [00:27:55]: 代理时代如何进行代码审查？

Swyx [00:28:00]: 用更多代理。

Jake [00:28:01]: 不行。那谁来审查CVE漏洞和其他问题？

Swyx [00:28:07]: 更多代理。

Jake [00:28:08]: 这就是我们撞上推理瓶颈的原因。你可以不断投入智能体解决问题，但我认为能投入的智能体数量是有极限的。

Swyx [00:28:24]: 你们在CLI流行之前就有了。你们暴露的功能形态在发生变化吗？

Jake [00:28:28]: CLI一直都很酷。我们改进CLI的方式是思考如何为Claude、Codex、ChatGPT或其他模型提供操作切入点。

Jake [00:28:50]: CLI是一个单一命令：部署、获取日志等等。对人类来说极其麻烦的事，对智能体来说却很友好。如果给你一个带40个参数和600个标志的CLI，你会觉得“我永远用不完这些功能”。但交给智能体，它会说“太棒了，我有这么多操作点可用”。

Jake [00:29:24]: 如果要向智能体开放功能，你需要尽可能多的接口，让它们能获取信息、查询动态数据并快速闭环。当前大部分问题都围绕如何快速闭环。智能体卡在哪个环节？如何消除障碍？

Jake [00:29:49]: 遥测数据很重要。如果通过CLI发现12%的用户因某个问题偏离正常路径，然后新增一个参数将比例降至2%，就能极大提升闭环速度。

Jake [00:30:03]: 我们不仅从CLI角度，也从整个仪表盘的每个交互点思考问题。这是一个用户旅程：听说Railway → 部署应用 → 获得首次绿色构建或顿悟时刻 → 查看端点、日志等 → 迭代。迭代循环是无限的。用户想部署新服务、修改代码，然后持续迭代。

Jake [00:30:36]: 如果聚焦于阻碍快速闭环的障碍，我们内部常说：永远不要让用户等待计算资源，而要让用户等待智能决策。如果用户在等待计算资源，说明存在瓶颈需要消除——否则瓶颈会变得如此严重，最终催生新的工作流来解决它。

Jake [00:31:04]: 我们的产品支持推送代码、构建等流程。但我坚信“推送-拉取”循环终将消失。未来你只需在生产环境做微小改动，该改动会跨基础设施版本化，你可以在数据库和基础设施的写时复制版本上协作，然后即时合并上线。这才是闭环的圣杯。传统的推送-拉取-重建流程是摩擦，我们正在彻底消除它。

Swyx [00:31:43]: 这速度太快了。如果还没试过Railway，这种即时反馈真的很棒。我的观点是，Railway曾因可视化画布闻名，它让基础设施操作直观化，但那是为人类设计的。下一阶段增长中，CLI比画布更重要。

Jake [00:32:05]: 画布有趣之处在于它能展示变化历程。你说得对，过去我们常将其作为输入工具。未来它的定位更偏向输出：用户在画布上查看变更、观察基础设施演进。而智能体通过CLI直接操作。因此画布成为人类决策的输出：此刻我需要哪些信息来判断是否批准某个操作？

Jake [00:32:57]: 它还需要成为上下文的锚点，在混乱中提供稳定参考。想象文件系统的层级结构：从项目开始，逐层深入服务、函数或代码。这意味着整个系统不仅存在于脑中，也具象化在画布上。其他人可共享此视图，同步思路，快速行动。

Jake [00:33:33]: 许多组织扩张时陷入困境，因为所有上下文都存在于某人脑中。“这个微服务如何工作？”“不清楚，去问那个人。”于是诞生了大量上下文发现工具。如果拥有稳固的层级结构，能无限嵌套服务、代码、上下文等，这类问题就迎刃而解。这正是构建复杂结构的基础。

Jake [00:34:18]: 这也是我们构建“超结构”的关键——规模远超常规的系统。比如金门大桥，人们会问“我们如何建成它？”有种说法是“我们已失去这项技术”。某种程度上确实如此，因为当年的协作方式已进化改变。随着一切被塞进Slack，我们失去了构建复杂结构的艺术。

Swyx [00:34:52]: 但你们把一切塞进Discord？

Jake [00:34:53]: 同一问题。无关具体工具，只是消息传递和中断的循环。

Swyx [00:35:00]: 所以你认为需要比Slack更结构化的东西？

Jake [00:35:04]: 绝对。我认为Slack和Discord都很糟糕。

Swyx [00:35:09]: 这是“我妈测试”——你们做了什么解决方案？

Jake [00:35:15]: 我们内部开发了名为Central Station的工具，聚合所有用户反馈、客服工单等数据，形成聚类。若潜在问题浮现，可快速评估影响用户数量并启动针对性讨论。

Jake [00:35:40]: 这比长期运行的频道更有帮助，因为你们总在纠结该把内容放在哪个频道。如果能根据上下文动态聚合信息并精准推送给相关人，效果会更好。我们知道内部有四个人与网络相关，如果遇到网络问题，可以直接定向推送给他们。如果是某个模块的问题，我们还能查看提交记录。这已经不再是手动流程了。

Jake [00:36:13]: 如果你访问 station 或 help.railway.com，这就是我们开发它的原因。我们希望通过聚合反馈实现大规模杠杆效应来扩展业务。

Swyx [00:36:27]: 这是内部开发的吗？

Jake [00:36:28]: 是的。

Swyx [000:36:29]: 我记得2023年和Angelo一起帮忙处理过这个。你们用很小的团队实现了很大规模的扩展。

Jake [00:36:38]: 对，现在我们规模扩大了约10倍。

Swyx [00:36:40]: 你们在这里公开了完整的开发者文档？很酷。

Jake [00:36:44]: 如果访问 railway.com/stats，这些数据可以作为Pub/Sub事件公开。所有指标都是实时的。如果你需要JSON格式，某个接口也能获取。

Jake [00:37:01]: 我们坚持公开透明地构建一切，分享正在开发的内容。过去遇到问题时，我们会公开说明解决进展。虽然会收到表扬和批评，但我们始终致力于改进并和用户沟通。

Swyx [00:37:20]: 你们最近遇到一个大问题，我记得影响了3000用户。你们应该用了Central Station？能聊聊具体情况和团队内部的处理方式吗？

Jake [00:37:38]: 这个问题真的很棘手。起因是上游供应商的行为与文档描述不符，这很讽刺因为他们还制定了相关RFC标准。我们部署后，Central Station通过少数用户反馈缓存未失效的问题首次发现异常，立即关闭了该功能。

Jake [00:38:03]: 当向三百万用户推出新功能时，会出现各种边缘情况。虽然我们做了测试环境验证和单元测试，但还是遇到了极端案例。现在我们强化了系统，未来能更好地处理这类问题。不过这次确实很艰难。

Swyx [00:38:39]: 如果用户发现漏洞，私下联系你们是否合适？作为平台方，如何在问题扩大前通过合适渠道解决？

Jake [00:38:59]: 我们遵循负责任披露原则，但倾向于过度披露而非让供应商误导用户。即使影响小部分用户，我们也会公开相关信息。这是公司价值观之一——荣誉感。应该最大限度通知受影响用户，直面问题：为什么会发生？如何改进？

Swyx [00:39:45]: 这不是全量用户，是因为渐进式发布？

Jake [00:39:50]: 对，就是渐进式发布。

Swyx [00:39:54]: 这应该是所有大型平台的常规做法。

Jake [00:39:58]: 确实。很多公司都在这么做。有句名言说Meta同时运行着1万个不同版本。就像我们之前讨论的代理系统，需要影子流量等机制。我们过于重视生产环境的"神圣性"，反而应该让安全测试环境更易用。这样可以在可控环境中试错。

Alessio [00:40:30]: 未来是否可能通过客户方的代理自动检测问题？比如缓存失效这类问题，如果知道检查点应该很容易发现。

Jake [00:40:44]: 这需要接入用户的可观测性基础设施。这也是我们设计平台渐进发布流程的原因：你可以先推送给"Johnny Vibe Coder"这类早期用户，或分片逐步发布。也可以用0.1%、1%、早期采用者等阶段逐步推广。这就是我们之前提到的非确定性版本控制。

Jake [00:41:30]: 我认为大多数系统都应该这样设计，因为很多公司都在重复开发内部的灰度发布系统。这正是开发者债务需要整合的领域。

Alessio [00:41:45]: 你们可以提供免费层级，比如让模型提供商通过数据使用换取免费计算资源？

Jake [00:41:55]: 我们确实这样做了。之前影响3000人的案例就是从低影响用户开始测试。平台上的大客户会最后收到更新，确保版本足够稳定。

Alessio [00:42:16]: 我有三个服务，估计会首批收到更新。你们随时可以重置我的环境。现在有各种SRE代理公司，可观测性工具也想解决上游问题。你们的代理系统如何与这些工具协作？

Jake [00:42:39]: 这涉及熵增问题。如果没有安全迭代生产环境的基础架构，问题会越来越复杂。当可观测性工具建议修复某个错误时，80%的情况确实有效。但在最后20%的复杂场景中，盲目应用修复反而可能引发新事故。

Jake [00:43:08]: 这就是分叉环境重要的原因。人们虽然有 staging 环境，但它总会与生产环境产生偏差。你需要在平台上原生构建基础组件、工作流和经验，这样才能在任意时间点分叉任意服务。

Jake [00:43:33]: 我把画布想象成一张透明胶片。代理就像是被推入画布的小家伙。它应该说：“我需要复制这个服务和那个服务，这样才能测试这两项功能。” 它会获得生产环境的只读副本。在克隆数据库时，任何涉及 PII 的数据都会被标记为转换，或者创建写时复制版本进行读取。然后代理进行修改并询问：“这真的有效吗？” 尽可能贴近生产环境进行验证。

Jake [00:44:22]: 你必须做到这种程度，否则系统会变得严重漂移。系统会变得不稳定。你会看到这种情况：本地用 Docker、生产用 Kubernetes，其他地方用特定方案——这种复杂性会拖慢开发者速度，规模扩大后更不稳定，难以迭代。我们想压缩这种复杂性，坚持“尽可能贴近生产环境才是目标”。

Swyx [00:45:00]: 我之前给 Erica 发消息询问问题，她说你最初并不相信 AISRE。现在改变看法了吗？

Jake [00:45:10]: 我确实转变了，但我仍然不相信没有安全基础的 AISRE。如果你在生产基础设施上随意释放 AISRE，又没有安全复制卷、确保系统稳定的原语，生产数据库迟早会被毁掉。我坚信必须先让这些操作安全可控。

Jake [00:45:33]: 我是深度的 AI 怀疑论者，直到 2023 年。2024 年我心想“或许勉强能实现”。2025 年觉得“现在可以掌控了”。但寒假后大家回来都说：“根本无法掌控。”

Swyx [00:46:01]: 你看过 Claude 文档里的 CloudBot 或 OpenCloud 吗？

Jake [00:46:06]: 现在的情况是，用错方式比用对方式更难。就像《复仇者联盟》里 Vision 拿起雷神之锤说它平衡感极佳——它能自我平衡，运作良好。我现在坚信：组合、C、C++、JavaScript、自然语言，这些会成为主导范式。

Swyx [00:46:35]: 这感觉是个巨大跳跃。

Jake [00:46:37]: 是的。但不是抛弃基于 CPU 的离散逻辑直接转向模糊逻辑。你需要两者结合。你的技能应该调用代码或应用，或某种静态结构。可以用技能提炼流程应该如何，或代码应该如何行为。

Jake [00:47:02]: 我逐渐形成一个观点：需要三个支点。系统需要清晰的规范定义、代码和测试。说出来可能觉得老生常谈——“当然，这就是 RFC、测试和代码。” 但它们缺一不可。三者结合能互相强化：当规范和测试一致但代码不匹配时，就去协调；当测试和代码一致但规范不符，同样需要调整。这就是迭代循环的核心。

Jake [00:47:41]: 这就是为什么人们谈论软件工厂、文档和协调机制。如果只是停留在架构设计层面而不落地，这些就是空中楼阁，但最终大部分系统都会走向这个循环。

Swyx [00:48:07]: 对听众来说，我们在这档播客讨论这个话题已有三年：规范与测试的三位一体。如果想深入，可以参考 Qodo 的 Itamar Friedman。

Swyx [00:48:18]: 关于 OpenCloud 概念，我想提自我修改能力。我不确定 Railway 如何支持，但我的 OpenClaw 已内置 Railway CLI，可以自由操作。理论上，无论需要什么新基础设施，它都能调用 CLI 部署并整合到自身。代理可以修改自己的基础设施。

Jake [00:48:45]: 这太疯狂了。我搭建了一个循环：在 Railway 运行的某个实例上部署 Railway CLI。当前环境已认证，可以进行任意修改。然后执行 Railway deploy 自我部署。

Jake [00:49:04]: 这就像：“我需要启动这个环境实例。当前环境已存在，太棒了，现在我获得了数据库访问权限。” 这正是我们想要的代理化、自我复制基础设施的方向。循环逻辑是：在生产环境迭代。持续修改，如果有效就合并上游，无效就丢弃。

Jake [00:49:37]: 如何让临时副本的创建变得简单且成本极低？传统“四核 CPU、16G 内存的 AWS 实例”模式会被淘汰。如果为代理部署这样的机器，需要上千台——成本过高。相比之下，我们投入大量精力研究的部署原子单元（无论是叫 isolates 还是沙箱）更优：按需付费、瞬时启动、快速闭环。

Jake [00:50:15]: 如果系统能安全自我复制并声明：“这是我的环境，我做了这些修改”，它能返回：“看起来如何？这是根据提示生成的新基础设施状态，我认为解决了问题。” 然后你检查说：“实际效果不同。” 它重新循环，直到你说：“好，应用。”

Swyx [00:50:38]: 这是事后看来显而易见的方案，但正是最有用的类型。关于 Railway 上的代理部署，还有其他建议吗？

Jake [00:50:51]: 每天都在改进。我在 X 或 Twitter 上活跃。如果某些功能不如预期，随时可以吐槽，因为确实还有很多需要优化的地方。

Swyx [00:51:04]: 目前当人们需要大规模或尴尬的并行计算时，通常会讨论无服务器架构。我觉得现在的无服务器和五年前的无服务器已经不同了。你们属于新一代。你们有对比或哲学上的差异需要强调吗？

Jake [00:51:31]: 这介于两者之间。它能够运行有状态的、长时间运行的工作流或执行流程。

Swyx [00:51:42]: Vercel 有 Fluid Compute，Cloudflare 有容器相关服务，Google 有 App Runner 等。

Jake [00:51:55]: 这就是所有技术发展的方向，这也是我们过去六年专注此领域的原因。我们相信用户需要访问一台计算机：一台能运行 Linux 的“盒子”。他们需要部署自己想要的内容。其他系统会限制你能构建的范畴。对我们来说，用户需要一台计算机，并能部署他们真正想要的任何东西。这就是我们为何专注于基础组件：网络、计算、存储。如果我们提供这些并开放它们，让用户能无限期运行程序，这就是我们认为的未来方向。

Jake [00:52:43]: Twitter 上的讨论缺乏细节，所以大家常说“服务器”或“无服务器”。其实总是在中间地带：我希望长时间运行它，但不想静态预配资源或为未使用的资源付费。这一直是我们的核心理念：按需付费、无限期运行，并且是完整的 Linux 环境。

Swyx [00:53:12]: 这就是我喜欢 Fluid 这个命名的原因。它灵活且可变。

Swyx [00:53:18]: 另一个里程碑是 Heroku 的官方弃用。你们是新一代 Heroku 的候选之一。“新 Heroku”这一类别在我参与开发者工具领域时就一直存在。现在终于发生了。这背后有什么故事吗？“这就是时刻”的感觉如何？

Jake [00:53:42]: 你会遇到这样的情况：“你们是在这里运行东西？作为这家公司？” 很疯狂的是，一些知名公司都在使用 Heroku，现在他们来找我们说“想把大量服务迁移走”。

Swyx [00:54:00]: Salesforce 让 Heroku 停滞不前背后有什么原因？

Jake [00:54:05]: 我只能猜测。毕竟这不是他们的核心业务。Salesforce 的业务是打造优秀的 CRM。收购计算业务只是旁支。很多早期 Meta 人讨论专注的重要性。Boz 曾写过 Meta 初创时期因资金不足被迫专注的故事。后来资金充足后，他们就失去了专注的动力。

Jake [00:54:52]: 这会稀释产品。你会产生分支并问：“这是否是业务的核心？” 如果不是核心，就会被搁置。许多公司因分散注意力而陷入困境，不仅外部竞争，内部也难以统一方向。我们到底要往哪里去？做什么？我们的使命是什么？

Jake [00:55:24]: 如果你是 Salesforce 的员工且以使命驱动，你会想专注在 Salesforce。Heroku 是旁支业务。它不关乎核心业务。获取资源、预算、专注力和内部对齐变得困难。它的衰落只是时间问题。

Swyx [00:56:06]: 至少他们公开说明问题，而不是含糊其辞。

Jake [00:56:12]: 他们的公告有些奇怪。他们公开了问题，但没说要关闭 Heroku。背后他们可能向用户发送消息，建议关闭账户，并逐步弃用相关服务。

Jake [00:56:30]: 很疯狂的是，我早期的部署经历始于 Heroku。从拖拽文件到 FTP 服务器，到尝试部署，再到 Heroku。它是我们的入门跳板。但时代在变迁，新事物不断涌现。我们很荣幸能延续这份火炬。但我们不想成为新的 Heroku。我们希望成为人们构建和部署软件的方式，最终成为他们长期变现软件的方式。

Swyx [00:57:19]: 成为新 Heroku 仍是一项巨大成就。过去有50家公司争夺这个位置。

Jake [00:57:23]: 每个公司都占据了一部分市场。我们很高兴能支持开发者和企业。平台模式不同，但底层逻辑相似。我们对发展方向非常坚定：基础组件、代理、扇出模型。有些场景适用，有些需要调整工作流。我们通过环境系统模拟了 Heroku 的管道功能。这令人兴奋，我们能支持大量用户，且增长迅速。

Swyx [00:58:12]: 我最后有个关于 Temporal 的技术问题。我已出售股份。你是核心用户，也是我们最早的客户之一。我通过 Temporal 认识你。你们基于 Temporal 构建系统。有什么抱怨吗？这可能是最中立、最权威的 Temporal 讨论，因为没人来自公司内部。

Jake [00:58:39]: 这很公平。我因 Uber 的 Cadence 项目使用 Temporal 近十年。

Swyx [00:58:52]: 给大家简单介绍下 Uber 的 Cadence 是什么。

Jake [00:58:57]: Cadence 是 Temporal 的前身。它支撑了行程操作、乘车服务，当你租用 Jump 自行车、滑板车或汽车时，这些长期运行的流程（如“这次行程将持续到结束”）会附加信息：比如在某个区域暂停则增加费用。行程结束后工作流结束。当时这些体验由 Cadence 驱动。

Swyx [00:59:34]: 我以前说它像自顶向下将整个用户旅程编写为一个函数。

Jake [00:59:39]: 这是个强大的概念，对代理化旅程的下一阶段也很重要。你希望代理完成特定任务，无论任务是否完成，都能继续下一步。需要动态管理工作流的方式。

Jake [00:59:59]: Temporal在理论上一直很棒，当它在生产环境中按你期望的方式运行时也是如此。但它要求你必须在脑海中构建整个流程。如果你做不到，可能会引发问题——比如工作流状态的重放会导致非确定性。

Swyx [01:00:25]: 因为它基于确定性工作流历史记录运行。

Jake [01:00:28]: 确切如此。我把它比作喷气发动机。如果你知道如何操作和运行它，效果很好。但你不能把它交给那些没有完整状态图的人去处理复杂任务。

Jake [01:00:48]: 我们整个部署管道都是基于它构建的。这是一个相当复杂的流程：预提交钩子、信号传递、队列管理等等。我们在Uber时也遇到过同样的问题。当你定义一个大型工作流时，状态机中的状态会越来越多，需要不断映射回工作流本身。

Swyx [01:01:15]: 这就是太多条件判断。

Jake [01:01:16]: 确实。在Uber，我们开发了一个系统来处理状态机和测试。现在我们也开始构建类似工具，因为需求增长很快。这并非纯粹的爱恨分明——当它正常工作时，效果超棒。但如果缺乏上下文的人往系统中添加了破坏状态或引发非确定性的逻辑，或者触发了大量活动，就需要跟踪底层SRE参数，比如活动插槽。这些参数需要与内存、vCPU等资源同步扩展。到了一定规模后，管理起来会变得非常棘手。

Swyx [01:02:10]: 你得有称职的系统管理员在背后支撑。如果换掉它，你们会怎么做？

Jake [01:02:19]: 我们会自己开发工作流引擎。公司内部已经有几个实验性项目。

Swyx [01:02:27]: 这类系统通常不会用“即兴编码”（vibe code）实现，但我想知道是否可行。

Jake [01:02:33]: 我仍然认为不应即兴编码。你仍需要编写合理测试来验证功能。

Swyx [01:02:39]: Timo也不是从零开始写的。你可以借助库，本质上只是需要将指令映射到状态机。

Jake [01:03:00]: 完全可行。工作流技术很有趣，Restate正在做些有意思的事。

Swyx [01:03:10]: 你们绑定在JavaScript上？是JavaScript全栈吗？

Jake [01:03:13]: 内部使用TypeScript、Rust和Go。我们不再引入新语言。其实还有少量C语言，用于编写BPF代码和钩子。但主要就是这些语言。

Swyx [01:03:28]: 是用于sidecar组件吗？

Jake [01:03:32]: 不是。主要用于网络堆栈、卷管理等。我们大量使用TypeScript驱动仪表盘，但现在正将大量工作流逻辑从仪表盘栈迁移至基础设施栈。

Swyx [01:04:00]: 其他技术基础设施？Railpacks？

Jake [01:04:07]: 我们开发了一个基于源代码确定依赖关系的引擎，名为Railpack。最初版本Nixpacks是基于Nix构建的，后来我们进行了迁移。

Swyx [01:04:17]: 人们四年都在劝我用Nix和NixOS。它会成为主流吗？

Jake [01:04:23]: 我不确定。我们对其很兴奋，但存在痛点。可以想象成按时间切片存储的版本化二进制堆栈。如果需要同时支持版本X和Y，包空间会膨胀，导致镜像体积暴增，给实际负载带来困难。

Swyx [01:04:53]: 但你可以通过内容寻址和缓存优化。

Jake [01:05:00]: 理论上可行。但当用户基数足够大且机器差异显著时，就会遇到Meta在XFAAS论文中描述的内部无服务器系统问题——除非单独拆分运行时，否则难以扩展。

Jake [01:05:24]: 我们不想这么做，因为希望真正支持部署任何内容。最初尝试Nix时是这样。但现在转向研究内容可寻址文件系统，可以按需从任意时间点加载内容并分页到内存。

Swyx [01:05:48]: 太棒了。

Jake [01:05:49]: 未来充满光明，虽然疯狂，但前景令人兴奋。

Swyx [01:05:54]: 创始人经历相关？

Alessio [01:05:56]: 你们的云支出：你发推说这个月要花30万美元？

Jake [01:06:01]: 我觉得是20万美元左右。

Alessio [01:06:02]: 编码代理？

Jake [01:06:03]: 是的。

Swyx [01:06:04]: 公司整体？

Alessio [01:06:05]: 公司只有35人，应该没人月花1万美元吧？分布情况如何？

Jake [01:06:10]: 我个人大概2.5万美元。我们有很多重度用户。假期结束后，我基本说：“如果还在手动写代码，那就是做错了。” 现有工具足够成熟，能让你快速推进。虽然存在痛点，但你应该审查生成的代码，而不是自己编写。

Jake [01:06:40]: 架构模式比以往更重要，但你不该花时间去生成自己本可以写出的代码。如果你知道如何编写，就让代理生成代码并调整，直到它看起来像你自己写的。

Jake [01:06:58]: 人们误以为我推动代理使用与公司增长和可靠性问题有关。其实两者未必直接关联。工具已经足够好，能让你快速构建比以往大得多的系统。

Jake [01:07:19]: 关于之前提到的在太空冷却数据中心的问题：我不确定。但就软件而言，你可以问，“如何从头构建块存储？如何实现这些功能？”我有一些想法，因为我有相关经验并阅读过相关论文。让我通过搭建大规模测试平台并编写数千个测试用例来验证这些想法，因为现在这些工作成本已经大幅降低。如果你不利用AI系统加速路线图推进并将其现有系统与未来规划对齐，你就会错过当前技术变革的核心价值。

Alessio [01:08:12]: 每月花费300万美元的路径是什么？是否受限于创意或客户吸收能力？

Jake [01:08:19]: 对大多数公司而言，当前的瓶颈在于部署。这就是为什么我们看到从财富50强到小型企业都在询问如何让开发者更快推进项目。你可能在触达CFO的预算限制前就会遇到技术瓶颈，因为他们会盯着令人咋舌的代币支出金额。推理成本必须下降，但我们现在正受限于推理能力。组织将通过价格发现机制来判断采用AI的合理性。

Jake [01:09:06]: 我认为会形成F1车手模式。如果有人特别擅长这些技术，给他们配备价值300万美元的赛车是有意义的。如果不行，就不该这么做。我们会挑选少数人说：“你们可以驾驶F1赛车。我们需要朝这个方向前进，想办法验证可行性并进行原型开发。”

Jake [01:09:33]: 我们已经在这样做并极大加速了路线图。原本预计需要几年完成的项目，现在可能几个月就能交付，因为我们通过验证跳过了增量开发阶段，直接向愿景推进。

Alessio [01:09:58]: 很多人意识到路线图未必带来商业影响，于是抱怨代币成本过高。但如果路线图能确保建成后带来更多收入，你就会为代币定价，就像对待销售投入一样。如果知道能带来20亿美元收入，花10亿美元做销售也是合理的。

Jake [01:10:19]: 没错。一个简单的衡量指标是代币最终在生产环境中的使用比例。如果能通过生产环境验证影响，那很棒。但证明价值的门槛会提高。内部我们有大量未合并的拉取请求。关键问题是：如何将这些成果投入生产？这取决于软件构建和部署速度，而这正是我们的核心优势所在。

Swyx [01:10:56]: 软件开发生命周期（SDLC）正在改变。一个观点是拉取请求正在消亡，将被提示请求取代。除此之外，如果其他系统完善，代码审查也会逐渐消失。SDLC还有哪些变化？

Jake [01:11:19]: 需要构建AISRE（AI驱动的软件工程）及相关工具。AISRE是远大目标。要实现它需要哪些工具？

Swyx [01:11:32]: 你们应该将工具开放给客户，比如中央站指挥中心。

Jake [01:11:39]: 我们已为模板维护者提供该功能。他们可以部署和维护模板并获得反馈，会逐步开放更多功能。

Swyx [01:11:51]: 关于事件集群处理。大家都在尝试，但没人真正解决。

Jake [01:11:56]: 我不认为我们内部已完全解决，但已能快速识别事件苗头。未来这些功能要么由他人开发，要么由我们开发。我们始终针对自身需求定制工具。如果能让用户受益、实现盈利或将其从成本中心转为利润中心，就会推进。

Jake [01:12:28]: 拉取请求确实正在消亡。

Swyx [01:12:29]: 你们是否使用第一方功能标记和渐进式发布？

Jake [01:12:34]: 我们内部已构建功能标记引擎，后续会逐步推出。

Swyx [01:12:38]: 作为用户我还没看到。为什么不直接开放你们的方案？

Jake [01:12:43]: 需要经过beta测试。我们非常重视产品质量。很多内部工具因无法跨服务扩展而未通过验证。可能对某个服务有效，但多服务场景会失败。要确保发布后无需重复开发，有些功能值得投入，但多数只是路线图参考。

Jake [01:13:18]: 我们不想因承诺不完整的功能而稀释用户体验，除非是核心项目。未来几个月会先推出单服务方案，再扩展到多服务，最后覆盖全环境。必须循序渐进，否则会因碎片化体验和支持压力而失败。

Jake [01:13:52]: 这是公司扩张与收敛的典型模式。先扩张获取功能，再收敛优化，确保体验卓越。你之前在走廊里说“现在好太多了”，而内部我们仍在说“这部分体验糟糕，必须大幅改进”。

Swyx [01:14:11]: 我作为Railway见证者可以证明。对听众来说，功能标记是Uber文化的重要部分，他们甚至需要工具来清理过多标记。Facebook有Gatekeeper系统。代理需要这类功能，它是渐进式发布的基石。OpenAI收购Statsig，GPT-5通过不同模型路由和标记实现功能分流。

Jake [01:14:56]: 这至关重要。如果软件开发生命周期因我们以千倍速度和千倍并发性完成任务而改变，那么在规模化过程中什么会变得重要？

Jake [01:15:16]: 在创办Railway之前，我开发了一个功能标记产品并尝试推广它。它是一个比LaunchDarkly更简化的版本。我遇到了一个问题：规模太小而采用这项技术的公司并不在乎功能标记，而真正需要功能标记的大型企业需要如此高的规模，你必须搭建完整的基础架构。最终我放弃了这个项目。

Jake [01:15:42]: 但老事物正在卷土重来。公司都想快速推进，但你不能直接把即兴编写的代码（YOLO）投入生产环境。你需要说：“这是我的影响范围，我需要为这些用户进行影子测试。”功能标记。你们需要大型企业构建的工具来维持系统结构。一切都在被压缩千倍，这样每个人都能快速搭建这些结构。

Jake [01:16:07]: 这正是我们现在所处的阶段：压缩软件开发生命周期，再扩展并添加新事物。

Swyx [01:16:15]: 对于新开发者来说，另一个相关术语是“像牲畜而非宠物（cattle, not pets）”。人们把生产环境当宠物对待。给它起名字，精心呵护，让它永不停机。而牲畜可以批量养殖、部署、拆分和销毁。

Jake [01:16:37]: 我认为这可能改变。只要能克隆你的“宠物”，你甚至可以继续拥有宠物。

Swyx [01:16:52]: 对。

Jake [01:16:52]: 如果能为每个时间点的系统状态做快照，即使某部分被摧毁也没关系，因为你有它的快照。我们现在构建的系统正是为了打破这种与生俱来的DevOps隔离。你必须编写Dockerfile，因为需要特定的文件系统切片。

Jake [01:17:14]: 如果拥有整个文件系统会怎样？如果能快照并按需加载整个文件系统？这样就能彻底解决这个问题。你不需要Dockerfile、Ansible脚本等繁琐流程。可以迭代、快照、验证状态是否正确，然后直接合并到生产环境。合并文件系统。

Swyx [01:17:45]: 为什么不呢？

Jake [01:17:46]: 这会很有趣。

Swyx [01:17:47]: 这又打开了潘多拉魔盒。但如果给虚拟机的状态做目录索引并针对每个问题开发专用解决方案，就能大幅缩小问题范围。人们之前没尝试过这点令人惊讶。

Jake [01:18:04]: 这一直让我困惑，因为这些正是我们一直在研究的方向。这太显而易见了。

Swyx [01:18:11]: 从第一性原理来看，这些是必须的。理论上每个人都需要，但大型云服务商没做，于是大家假设这不可能。

Jake [01:18:18]: 确切如此。你会想：“Meta有团队在写eBPF代码，他们肯定在做些什么。”但要解决这些问题，就需要这类工作。无论需要什么，无论要深入到什么程度，我们都会一直往下挖——如果需要修改内核的TCP/IP栈来适配未来世界观的模型，我们就去做。

Swyx [01:18:52]: 听起来很有趣。

Jake [01:18:53]: 太有趣了。我不得不从这些有趣的问题中抽身，确保公司能以正确方式扩展。有太多有趣的问题：将客户反馈传递给内部开发者、安全迭代、从仪表盘向用户传递上下文、穿透到基础设施层、将编排系统视为实时操作系统而非反馈控制系统……一切都太有趣了。

Swyx [01:19:29]: 说回创始人视角，你完全违背YC/硅谷共识。通常YC模式是找联合创始人、按部就班，但你完全没走这条路。

Jake [01:19:40]: 一个都没。

Swyx [01:19:45]: 你提到过，如果一个人负责技术、另一个负责业务开发，联合创始人有意义。但作为单打独斗的创始人，你如何兼顾？

Jake [01:19:58]: 我尽量保证每天睡8小时。

Swyx [01:20:11]: 是否有平衡比例？50/50？30/30/30？单人创始人的思维模型是什么？

Jake [01:20:17]: 没有平衡。你必须关注所有层面并为之着迷。痴迷于从市场角度思考用户如何看待产品，痴迷于内核级改动——比如让用户的SSH连接永不中断。我希望构建一个能快照一切、像在虚拟机上迭代般顺畅的宇宙。

Jake [01:20:47]: 你必须对技术栈的每一层都保持痴迷。这让我更容易坚持。有些人专注于公司旅程的不同部分，如果你能清晰划分责任并明确所有权，就能享受这个过程。

Jake [01:21:12]: 我认为两位创始人是最糟糕的配置，因为无法决断。一旦意见不合，如何解决？

Swyx [01:21:38]: 通常CEO有最终决定权。

Jake [01:21:43]: 完全正确。无论选择哪种方式都会困难。无论是寻求帮助还是单干，运营公司都很艰难，但回报和乐趣同样巨大。

Swyx [01:21:56]: 你发现什么方法最有帮助？教练？有什么建议对你影响深远？

Jake [01:22:01]: 我喜欢大量写作。我常因推文惹麻烦。曾说过“周末加班说明你的规划有问题”。现在我有所保留，因为当前确实需要阶段性冲刺。但目标必须清晰——如果你有愿景并知道方向，就该更努力地提炼愿景、推进目标。

Jake [01:22:33]: 如果你感到迷茫需要厘清思路，就断开连接，认真对待周末。写下你当前的位置、想做的事、想去的方向，以及你正在解决的问题。

Jake [01:22:56]: 写作很重要。我不太喜欢“冥想”这个词，但无论用什么方式，当你试图说“我们在此处且必须在此处立足”或“我们在此处且需要在这个领域深耕以取得成功”时，保持思维清晰至关重要。

Jake [01:23:22]: 断开连接，与你爱的人相处，工作时全力以赴。我尽量周一到周五从日出到日落全身心投入工作，周末彻底断联。周日下午回来写作、规划下周，处理其他事务。这套节奏对我很有效。

Jake [01:23:43]: 另一个犀利观点：大多数建议应消化后弃之不用。有用的会自然回归。你会通过经验学习到它们。社会让“失败”代价高昂，这让人难以偏离既定路径。

Swyx [01:24:03]: 有没有什么未在推特引发争议的观点想提前剧透给观众？

Jake [01:24:12]: 代理技术（agent stuff）很疯狂。只要能解决所需的推理需求，它将成为人们完成几乎所有事务的主导方式。未来十年，人们将彻底改变对“如何将脑中逻辑具象化”的认知。

Swyx [01:24:36]: 可以这么表述吗：如果Allbirds能成为GPU供应商，Railway也能。

Jake [01:24:44]: 我认为“人人成为GPU供应商”更多是表面现象。你更应被“不做之事”定义，而非“所做之事”，因为说“是”很容易。

Jake [01:24:56]: Anthropic很厉害，正在开拓新领域。他们正在开发类似Figma的产品。

Swyx [01:25:09]: 录制时，Mike Krieger刚从Figma董事会卸任，周一被除名，今天他们就发布了新产品。

Jake [01:25:18]: 现在变化太快了。但代理技术终将成为人们的核心操作方式。

Swyx [01:25:25]: 所以你的答案是专注：现在不碰GPU，但未来不排除？

Jake [01:25:27]: 专注。我们现在不会涉足GPU领域，但未来某个阶段100%会进军这一领域。这并非泄露路线图（因为我们目前并无GPU计划），而是因为当需要算力时，若想让开发、部署变得唾手可得，必须掌控这一核心能力。

Swyx [01:25:57]: 目前你自己的数据中心流量占工作负载的少数，但未来会成为主流，甚至彻底弃用公有云吗？

Jake [01:26:10]: 我们曾实现100%自建数据中心：完全由我们自主运营。目前平台上绝大多数服务都部署在自有的裸金属数据中心。

Swyx [01:26:21]: 你们已经实现了。

Jake [01:26:23]: 是的。我们曾完全过渡到自建数据中心，但增长速度太快，不得不回退到90%左右，因为需要扩容。

Swyx [01:26:45]: 你们实际上在构建全新的独立云服务，人们以为AWS之后这不可能了。

Jake [01:26:53]: 这很难。我们必须确保平台高度可靠。但若要从零构建云服务而非复制超大规模厂商，就必须开拓新路径。

Jake [01:27:10]: 我们从零构建基础设施，大量研读论文，但承诺不抄袭他人成果。若抄袭，终将变成他们。企业存在必须有核心使命。

Jake [01:27:33]: 在超大规模云厂商部署生产环境的启动成本过高。我们认为应即时完成部署，消除从想法到可分享成果之间的摩擦。这是我们从底层到上层堆栈的终极目标。若需要深入能源层，我们也会这么做。

Jake [01:27:58]: 这对工具的普及至关重要。这不仅关乎“公民开发者”（非专业开发者）的代码体验。我们需要消除公民开发者、前端、后端、DevOps等角色间的层级壁垒，让人们能直接交付成果。

Swyx [01:28:20]: 太棒了。这就是云的未来。

Jake [01:28:22]: 非常感谢你参与。感谢邀请，对话很愉快。