人们已经谈论“SaaS已死”有一段时间了，这甚至算不上什么新颖的观点。既然你可以自己动手构建和维护你使用的工具，为什么还要花钱请别人来做呢？只需让你的AI代理去执行即可。对我而言，有一个鲜被提及的关键缺失环节：在那些一次性生成的软件与我真正愿意使用的软件之间存在着巨大的鸿沟。后者能带来愉悦感，打磨精良且体验良好。

我踏上了一段旅程，旨在用内部构建的工具替代Railway目前用于营销目的的一系列SaaS提供商。我最终打造了一个全功能工具，供我们内部使用。该工具允许我们管理Railway网站、更新日志和博客的内容；我们可以用它发送邮件，同时在所有社交平台上发帖，并管理网站的媒体资源。

甚至还有一个小型CRM系统，以便在与外部创作者合作时进行跟踪；包含任务追踪和发布计划功能，因为你需要协调多项事务及其发布时间。此外还有日历、评论以及实时编辑功能，而这一切都是利用AI代理构建的。我认为在GPT-6发布时迎来了突破点，且所有这一切都在Railway上运行。

一切都能自动部署。现在让我带你了解我用来确保新功能不仅打磨精良、与应用程序其余部分保持一致，而且你可以借鉴并应用于构建自己工具的原则。

因此，我决定不在枯燥的办公室里进行演讲，而是换个环境在户外进行。这里景色绝美。我现在位于苏格兰的爱丁堡，简直不可思议。我坐在一张长椅上，这就是我的视野。绝对是一张十分完美的长椅。这种演讲对我来说感觉有些不同寻常，因为我本质上将带你走过构建我们内部工具并阐述我所形成的观点的旅程。

但我同时也意识到，技术格局变化极快。所以我所说的任何内容可能在几个月内就会完全改变。谁知道呢？所以请将其视为我的免责声明：录制时间是2026年秋季，十月。好了，言归正传，让我们谈谈第一个观点：文本并不重要。

许多人说使用什么编程语言或框架无关紧要，你可以让代理为你构建任何东西，它也能做到。虽然我在某种程度上同意这一观点，但我发现当你构建一个自己真正会使用的工具时，如果你给代理提供一个具有坚实抽象结构的代码库，结果会有所不同。

当你开发新功能时，最终得到的结果会更加一致，与你之前构建的内容相似。原因很简单：代理不需要每次尝试添加新功能时都重新发明轮子，也不需要引入新的模式。它基本上只会遵循现有的模式。

关于技术选型，我觉得只要代码库结构合理，具体选择其实没那么重要。但在Web开发中，我目前的首选是TanStack库系列；如果是构建任何与内容相关的东西，我会强烈推荐Payload。体验扎实，抽象设计出色。

我曾深入比较过各种CMS系统，因为我不认为我应该从零开始构建它（尽管我有能力这样做）。但谁知道呢？也许未来会改变。这引出了我遇到的第二个主要问题：当你使用那些你每天喜爱并依赖的SaaS产品时，作为用户你可能注意不到许多细节。

但当你试图复制这种体验时，你会迅速发现不同的流程背后投入了多少关怀和思考。比如，“我想发送一封邮件或发布一些内容”，这很容易通过传统的服务器端渲染应用和表单提交来实现。

但如果要构建一个你每天频繁使用的工具，你会觉得“事情不应该是这样的”。我发现了一些代理通常不会主动实施的模式（除非你明确要求），这是我的清单，我们将逐一探讨。首先是自动保存功能。

我发现如果你构建某种文档编辑器，自动保存是一种基本必备特性。与其手动点击保存按钮，不如让代理在后台自动保存进度，并确保这是一个非阻塞操作。这样你在打字时就能继续输入，而它会自动保存。

更进一步的做法是防止浏览器标签页在有未保存更改时关闭。这两层保障确保了你正在处理的内容不会丢失。你还可以更进一步，添加实时协作功能以支持并发编辑。

我的代理在实现这个功能时毫无困难：询问它是如何工作的，审查方案，然后……在经过7亿次token运算后，我实现了实时协作。因此，我认为从产品体验角度来看，这是代理做得不够好的一件事。

另一个我发现代理完全忘记实现的模式是乐观更新（Optimistic Updates）。与其在用户执行任何操作时显示一堆加载动画，不如乐观地展示成功状态。然后在后台同步他们所做的更改。

如果由于任何原因同步或操作失败，只需回滚并告知用户“操作未成功”。当然，你不应该对所有内容盲目使用乐观更新。有些场景下你需要显示加载动画并等待确认一切正常。

但在一般情况下，使用乐观更新会使整体体验感觉显著更快、更灵敏，更加即时。所以我很确定你可以直接告诉代理：“嘿，我希望……”

比如，在合适的地方实现乐观更新。制定一个计划。”它会告诉你所有适合这样做的位置。同样地，让智能体构建这些功能并不难，你只需要知道确切该问什么并提出来。在我看来，乐观更新的延伸是赋予用户撤销某些操作的能力。例如，如果你要求智能体实现删除记录的功能，它通常会给你一个删除按钮。你点击后可能会弹出一个确认对话框，确认后才会真正执行删除操作。

但更好的体验是允许用户撤销该动作。因此，当用户点击“删除”时，立即从界面移除该项，并提示他们有几秒钟的时间可以改变主意。如果他们没有操作，则说明确实想要删除；否则若点击“撤销”，就恢复之前的更改。这就像在后台执行操作一样，是一种延迟动作，这也引出了下一个要点：归档功能。

你应该告诉智能体需要能够归档和取消归档记录，因为有时你想从界面或搜索结果中完全隐藏某些内容，而归档正是实现这一目的的方式。你不应该强迫用户认为如果不希望看到某项就必须删除它，更好的体验是提供归档功能。我认为这绝对应该成为一种标准模式。

对我而言另一个重点是 URL 状态管理。你应该要求智能体在合适时将数据持久化到 URL 中，这非常有用。例如，当你有一组记录列表并希望具备筛选或排序功能时，只需设置一些条件。将这些信息保存在 URL 中使得分享给他人变得轻而易举；比如另一位团队成员可以直接看到你希望他们看到的内容。

智能体默认未实现的一个小细节是无限滚动。我不愿反复点击“加载更多”或翻页按钮，我希望直接获取数据，无需手动翻页直至到达末尾。虽然这是小事，但日常使用时影响巨大。我发现另一个能显著提升输出质量的方法是明确指示智能体参考现有页面，包括 UI 设计、数据获取方式及整体结构。

这使我能够一次性定义“什么是好的”，并在后续功能开发中复用这一标准。老实说，即使你指示智能体参考某页面（如“使用 X 页作为参照”），有时它也不会遵循。我不确定模型是否有时会变笨，但这确实会发生。不过总体而言，当我指示智能体参考现有页面时成功率更高，因为最终体验更加一致。

当你在应用中使用功能时会发现：如果两个部分共享相同概念，它们看起来应该一致。例如，应用中两处都是可增删改查的记录列表，那么这两部分在体验上应基本相同。这引出了我的下一个观点：当你有关于某事的特定要求时，应将它们封装为“智能体技能”。这样，当智能体构建功能时会严格遵循这些规范。

在开发内部工具时我发现自己经常用到三类技能。其中两类与设计和工程相关：第一类有助于提升 UI、排版、布局及错误提示的质量；第二类则专注于更好的动画效果及其他细节。最后但同样重要的是 Railway 的技能集，因为我们在内部构建的所有内容都运行在 Railway 上。

无论是存储桶、数据库还是应用本身及实时服务器，所有基础设施均依托于 Railway。为了让智能体有效工作并部署一切，只需赋予它相应的技能即可轻松完成。一旦拥有所有技能和规范，我认为最后一步也是最关键的一步是验证环节。通常当你要求智能体构建某功能时它会反馈：“已实现，测试通过。”

但实际试用时常发现体验存在严重问题。一旦建立验证循环，效果便有天壤之别：你能看到智能体自我修正的过程——“我构建了它，尝试后发现失败，现在修复。”如此循环直至完全测试通过。随着计算机使用能力的提升，我感受到了这一突破。

现在每次添加新功能时我都会强调：必须端到端验证功能是否正常工作，并通过实际运行基础设施来测试。智能体完全具备这种能力，只需明确告知即可。集齐所有要素后你将构建出快速、稳定且体验一致的高质量内部工具。以上就是我构建任何内部工具时遵循的原则清单。

希望这些内容对你有用，更重要的是激发你打造出色、精致且令人愉悦的内部工具的灵感。也希望你能成为公司的 SaaS 层构建者。非常感谢观看，我们下次再见。