Newshot 
AI agents 现在可以完成我过去构建 DocSpring 时所做的许多工作。当我看着自己的待办事项列表时，这令人兴奋；但当我想到别人用同样的工具构建竞争产品时，就没那么舒服了。
Nico Jeannen 在 X 上写过这件事：AI 让基础 SaaS 产品变得更容易构建和复制。他是在回应 Olly 的一篇帖子，那篇帖子讲的是创始人的疲惫，以及担心 AI 可能让他们的业务变得多余。这两种反应我都能理解。
DocSpring 用于填写和生成 PDF 与 Word 文档，并收集电子签名。我创立它时叫 FormAPI，我们的团队现在在开发和运营中全程使用 AI agents。我自己写代码的时间少了很多。但我也比以往任何时候都更努力。
我终于在处理那些在待办列表里积压了多年的功能想法和 bug。但即使 agents 承担了大部分实现工作，经营业务仍然需要大量精力。客户一直在使用我们已经发布的东西，而我们则在决定接下来要改什么。每一处改动都必须契合他们所依赖的产品。
构建我当初设想的文档平台
Agents 为我节省了大量时间，以至于它不断改变我认为我们能构建什么。
我把 FormAPI 改名为 DocSpring 的主要原因之一，是我想要构建一个更广泛的文档自动化平台。填写 PDF 表单是起点。我希望人们也能创建和自动化其他类型的文档，但我们已有的产品总有更多工作要做。
我们现在已经发布了 Word 模板和 Page Designer。你可以上传带有占位符的 Word 文档并用数据填充它，也可以直接在浏览器中设计文档，而不必从现有文件开始。这两个功能我曾不确定自己是否会有时间去做。在产品中看到它们，让 DocSpring 这个名字感觉更接近我选择它时所设想的样子。
我们的发布说明展示了过去几个月里还有多少其他变化。除了这些新的模板类型，我们还重新设计了网站和应用，并发布了 API v2。电子签名方面也做了大量工作，包括签名者角色，以及用于发送签名链接、提醒和已完成文档的电子邮件。
有一个电子签名问题卡了特别久：弄清楚如何用通过 Adobe Approved Trust List 信任的证书来密封 PDF。我们终于确定了方案，尽管我们仍在等待证书签发。这项工作涉及研究证书提供商及其要求，以及编写密封代码。让 agent 协助这项研究，使我们能够在我多年来一直难以弄明白的事情上取得进展。几年前我自己研究这个时，对一家小型初创公司来说成本高得令人望而却步，合同起价每年 $50k。AI agents 帮助我研究并联系了我们能找到的每一家供应商，我们终于找到了一家每年只需几千美元就能提供证书的供应商。我们还可以自带云 HSM。（其他供应商只会把证书放在 USB 盘上寄给你，你必须把它插到物理服务器上。）
我们也触及了待办列表中更靠后的项目。并排预览现在适用于所有模板类型，因此你可以在编辑时保持已填写文档可见。一位客户多年前就要求过这个功能，但随着新的、更紧急的工单不断堆积，它一直被推到待办列表更靠后的位置。当我必须自己写所有代码并修复所有 bug 时，我根本抽不出时间来做它。我们还用 react-jsonschema-form 重建了 Alpaca.js 网页表单，它可以从 JSON schema 生成 React 表单，并添加了表单分区，以便长表单可以拆分成多个步骤。
这些项目过去只能由我一个接一个地处理，每一个都要花上几周甚至几个月。现在，一个 AI 会话可以处理 Word 文档的渲染方式，另一个会话则处理长表单如何拆分成多个部分。当它们需要决策时，我在它们之间切换，而实现和审查在其他会话中继续进行。
让这一切持续运转
这段时间让我想起构建 FormAPI 的最初几个月，那时我不停地工作。工作、吃饭、睡觉、重复。现在，一个棘手的依赖或基础设施问题不一定意味着要把所有产品工作搁置一旁。一个 agent 可以调查它，并在我与另一个会话协作时，给我带来复现步骤或建议的修复方案。我目前使用 Herdr 管理 49 个不同的 Claude Code 会话，每个会话专注于不同的任务或产品领域。其中 26 个会话目前处于“活跃”状态，而真正并行工作的只有十几个左右。我经常有一长串会话在等待我阅读某些内容并做出决定，所以我整天都在会话之间跳转，主要是阅读更新和回答问题。这种快速的上下文切换一开始很困难，我每天结束时都筋疲力尽。但我已经逐渐习惯这种工作流程，不再觉得那么有挑战性了。
其中一些 Claude Code 会话有持续性的工作。我有一个会话负责处理大批量的 bug 修复，将一系列较小的问题从调查、实现到审查逐一处理。另一个会话专门负责 Sentry，即报告我们应用程序错误的服务。它调查错误、进行修复，并分辨哪些报告是可以忽略的噪音。当其他 agent 开发新功能时，bug 积压和运行中产品出现的错误都能得到处理。
我有一个单独的会话负责性能。它的工作是调查缓慢的页面，确保应用使用起来感觉快速。最近的工作包括追踪缓慢的数据库查询、更改索引和记录获取方式，以及在部署后测量结果。另一个 agent 负责我们的 CI 流水线（我们推送代码时运行的自动化检查）。由于有如此多的分支在被处理，我既关心这些检查完成的速度，也关心它们的成本。我们已经将许多任务迁移到我的家庭服务器上，同时保留在 CircleCI 云中运行它们的选项。该 agent 负责流水线本身的工作，以便其他会话可以持续测试它们的更改。
这些工作过去与功能开发更直接地争夺我的时间。现在我可以让 agent 处理可靠性和性能方面的工作，同时其他会话构建我想要发布的更大项目。我仍然需要设定优先级并审查它们提出的方案，但选择开发新功能并不意味着所有这些维护工作都必须等待。产品变更在进入生产环境之前仍然要经过自动化检查、代码审查和预发布环境 QA。进行中的工作越多，这个过程就越重要，而 agent 承担了运行检查、审查变更和修复发现的问题的大部分工作。
在我开始使用 AI agent 之前，我们的 Sorbet 工作很难让我觉得合理。Sorbet 是 Ruby 的类型检查器。Agent 帮助我们为应用程序添加类型，然后我们构建了自己的插件，使其能够理解更多的 Rails 代码和模板。维护一个定制的类型检查器，是我过去认为在完成其他所有必要工作之外无法企及的项目类型。
完成这些项目仍然需要我们的团队审查结果并发布。我们构建了 Rack Gateway，以便 agent 可以准备服务器命令和部署，并将实际的代码或提交交给我审批。这省去了我自己组装每个操作的麻烦。它也让我在还能阻止变更的时候，将提议的更改呈现在我面前。
现在工作到来得也更快了。多个会话可以各自独立推进，然后同时需要我做决定。一个补丁可能已经准备好审查，而与此同时，一段客户对话又对同一个功能提出了新的问题。我必须在发布之前把客户的上下文带回实现中。有时候我们的部署队列里会有五个 agent，它们都在等待部署各自的分支、在 staging 上运行 QA，然后部署到生产环境。
收件箱不断改变着需要做的事
很多工作始于代码仓库之外。客户提出某个需求，上游维护者回复某个补丁，或者收到一条合规提醒。每一件事都可能改变我接下来需要 agent 处理的内容。我在 Claude Code 中使用一个邮件分诊 skill 来完成这件事。它是一组保存好的指令，告诉 agent 如何阅读我的邮件线程、总结需要注意的事项，并提出行动建议。在它采取行动之前，我会审查这些建议。
它还可以把一封邮件转发给已经在处理该主题的 agent 会话。维护者的反馈可以发给正在处理上游补丁的会话。合规问题可以发给正在协助我们 SOC 2 工作的会话。这些 agent 拥有上下文，可以展开调查或准备回复，而我可以继续去做别的事情。
这比我自己完成所有调研和通信工作是一个实质性的改进。AI 也在业务工作上提供帮助，包括支持、合规以及与我们的会计师协作。不过，我仍然参与决定这些消息对业务意味着什么。一个客户请求可能是一个 bug、一个有用的功能，或者是我们应该拒绝的事情。agent 可以调查各种选项并推荐一个。我需要决定我们要承诺什么，然后确保工作和回复保持一致。
甚至分诊工作流也需要引导。我必须给它一个明确的边界：分诊并路由工作，然后让相关的会话处理调查。否则它会主动提出自己接手后续任务，从而失去焦点。给 agent 一份有用的工作，涉及到弄清楚这份工作应该在哪里结束。
在我写这篇文章时，我所有的邮箱都是空的，Intercom 里没有任何等待处理的事项，我们的 Sentry 项目也没有未解决的错误。过去我偶尔也能达到这种状态，但消息和问题总是会立刻重新堆积起来，我只会因为试图掌控一切而精疲力尽。大约一个月以来，在 AI 帮助我处理所有事情的情况下，我终于能够跟上了。
这感觉像是一个巨大的变化。我在发布更多东西的同时，还能跟上支持工作以及发布后出现的任何问题。生产环境中的问题也没有那么多。我们掌控着所有的日志和错误，AI agent 在代码部署前的审查方面做得非常出色，DocSpring 运行得非常顺畅。
我是一名独立创始人，DocSpring 是一家相对较小的初创公司，所以把“CEO”作为正式头衔总让我觉得奇怪。但现在我确实觉得这个头衔比以往任何时候都更适合我。我一直在把大量工作委托给 AI agent，而自己主要做高层决策。我仍然觉得自己是一名构建者，仍在为代码和架构做出贡献，但我也花了更多时间“在”业务之上工作，而不是“在”业务之中工作。
一个日历修复如何变成了日期解析器项目
不过，让所有这些会话保持一致也可能出问题。最近一次对日期计算的修复很好地说明了仍然会落到我桌上的工作是什么样。我们的一个计算日期差值的功能有一个 bug。最初的版本使用平均年份长度来计算某人的年龄，这在生日前后可能给出错误答案。修复方法是正确地按日历年计数。
文章标题：当 AI agent 编写所有代码时，运营一家 SaaS 需要什么
在 AI 代码审查期间，一个 agent 在附近发现了另一个问题：一个两位数年份的日期在浏览器中可能表示一种含义，而在生成的 PDF 中可能表示不同的含义。让两者保持一致听起来合理，于是该 agent 添加了一个修复，然后将更改送去进行更多审查。
经过连续几轮，支持的格式从带两位数年份的数字日期扩展到了月份名称。最终，该 agent 正在为 07MAY24 和 7th May 24 这样的值添加特殊处理，并为新行为编写测试。
我之前已经在几个不同的 AI 会话中讨论过这件事。API v2 有意严格验证日期。我们曾计划在 API v1 中为两位数年份做出一个狭窄的兼容性让步。让共享解析器和表单解释更多有歧义的日期，违背了那个决定。该 agent 没有检查那些早先的讨论。每一轮审查都发现了另一处不一致，而每一次修复都让这个越来越宽松的解析器更加一致。最初的任务只是正确计算年龄。
沿途，我曾批准过一些提议修复的列表，但说实话，我并没有密切关注每一条建议。日期更改在这些列表中以“待修复的 bug”形式出现，却没有明确说明它们改变了产品的预期行为。等到我质疑我们为什么要支持 07MAY24 时，该分支已经部署到 staging 了。我们在它进入生产环境之前移除了额外的解析，并保留了简单的日历修复。
这是一种令人不安的错误，因为审查已经足够多。这些 agent 确实在发现行为上的真实差异，并编写测试来覆盖它们。但它们已经搞不清我们实际想要的是哪种行为，并陷入了一个反馈循环，不断钻牛角尖，处理越来越多的边缘情况。更多轮同样的审查不断把工作推向错误的方向。当我使用 Codex 进行代码审查时，GPT-6 Astra 在这方面尤其糟糕。所有发现的问题在某种程度上都是“真实的”，但它经常会提出极其小众的边缘情况，而这些情况在生产环境中几乎永远不会发生。
仍然回到我身上的事
这一切都不能证明 DocSpring 免受竞争。我非常努力地工作，但我们都能访问相同的前沿 AI 模型和编码工具。忙碌并不能证明客户会继续选择我们，而新的竞争对手不仅可以将 agent 用于代码，还可以用于运营。我们仍然必须构建人们愿意付费的东西。
我也不知道这种分工能持续多久。更好的上下文共享可以减少我在会话之间所做的协调。而模型在我目前自己做出的判断上可能会变得好得多。我通常会接受它们提出的默认建议中大约 90%，但最后那 10% 仍然很重要，可以防止它们陷入反馈循环并偏离正轨。而且时不时地，我仍然会发现 Opus 5.5 做出会损害性能的糟糕决策，或者以完全错误的方式设计系统。
目前，我仍然有一项业务要经营。我可以把更多那类工作交给 AI agent，但我仍然会跟进，决定我们要向客户承诺什么，有时还要阻止一个 agent 钻太多牛角尖。不过，我很享受这个过程，而且我并不太怀念编程这个行为本身。我仍然热爱编程，但我认为我更热爱构建东西。我的待办事项终于感觉可以完成了，我期待看到我们能走多远。
- 软件开发
更多文章
- 2026 年 11 月 11 日 · 14 分钟阅读 全力投入 Sorbet Sorbet 在我们的 Rails 应用中放了 18 个月，只有十分之一的代码有类型标注。然后 AI agent 在四天内为其余代码加上了类型，而我们继续推进。
2026年11月11日 · 14 分钟阅读
全面采用 Sorbet
Sorbet 在我们的 Rails 应用中搁置了 18 个月，只有十分之一的代码带有类型标注。随后 AI agents 在四天内为其余代码加上了类型，而我们继续推进。
- 2026年11月11日 · 4 分钟阅读 PDF 表单填写 SDK 与 API 当 PDF 库足以填写你的表单时，以及托管 API 在何时能为你省去这些工作。
2026年11月11日 · 4 分钟阅读
PDF 表单填写 SDK 与 API
当 PDF 库足以填写你的表单时，以及托管 API 在何时能为你省去这些工作。
- 2026年11月11日 · 5 分钟阅读 最佳 PDF 表单填写 API（2026） DocSpring、Anvil、PDF.co、Adobe PDF Services 和 Nutrient 在填写可填写 PDF 与扁平 PDF 方面的比较。
2026年11月11日 · 5 分钟阅读
最佳 PDF 表单填写 API（2026）
DocSpring、Anvil、PDF.co、Adobe PDF Services 和 Nutrient 在填写可填写 PDF 与扁平 PDF 方面的比较。
用你自己的文档试用 DocSpring
上传一份 PDF 或 Word 文档，或创建一个 HTML 模板，然后发送一个测试请求。无需信用卡。