一人公司：打造低成本无服务器框架

大道至简，衍化至繁。 —— 老子

题记：这是「一人技术公司」系列的第三篇。现在 OPC (One Person Company) 的概念很火，我也尝个鲜，看看真要严肃地使用周末来做点一家技术公司才能做起来得事情，到底能做成啥样。这并不意味着我要全职创业，我认为我自己是个一直在路上的创业者，朝九晚五从来不是我的束缚。我想通过这个过程，了解 AI 的边界，以及我自己的边界。

整个系列将记录我从零搭建一套完整技术体系的全过程 —— 从基础设施，到网络与运行时，到核心框架，再到应用服务。这不是一篇教程，而是一份带有思考过程的实战手记。

前两篇我们分别聊了用 IaC 搭建 AWS 访问控制和安全架构，以及服务架构的取舍。地基打好了，接下来得回答一个灵魂拷问：就你一个人，后端服务到底怎么跑？

答案几乎是唯一的：无服务器（Serverless）。

但问题是，市面上的无服务器框架过分追求通用，塞满了你用不上的抽象和无意义的灵活性。于是我干了一件看起来很离谱的事：自己用 Rust 撸了一个完整的无服务器框架，从运行时到 CLI 工具，从认证系统到基础设施模板，全家桶一步到位。

这篇文章，我把这一路上踩过的坑、做过的取舍、悟到的道理，掰开了揉碎了讲给大家听。

一、为什么一人公司必须拥抱无服务器

设身处地想想你的处境：你一个人，身兼产品经理、架构师、前端、后端、运维、客服六职。没有值班轮换表，凌晨三点服务器炸了只能自己爬起来救火。没有运维团队帮你打补丁、扩缩容、盯监控。

这种情况下，你真的还想去伺候 EC2 实例？去操心 Kubernetes 集群升级？去半夜处理某个节点磁盘爆了？

无服务器架构对一人公司的核心价值，不是「省钱」（虽然它确实省钱），而是「省心」。 它把运维的心智负担从你肩上卸掉，让你把有限的精力花在真正该花的地方：产品和用户。

具体来说，无服务器给一人公司带来三个无可替代的优势：

第一，零运维开销。 不用打补丁，不用升系统，不用规划容量。Lambda 函数跑完拍拍屁股就走，你只为实际算力付费。对于请求量忽高忽低的早期产品来说，这种弹性简直是续命神器。

第二，天然按需付费。 你的服务可能一天才被调用几百次，传统架构下你也得养着至少一台实例 7x24 小时空转。而无服务器架构下，没请求就不花钱。对于还在摸索 PMF（产品市场匹配）的阶段，这意味着你可以同时跑好几个实验性服务，账单看了也不心疼。

第三，对 AI 极度友好的调试闭环。 这一点尤其关键。无服务器架构天然产出大量结构化日志，而这些日志恰恰是 AI 编程助手最能吃透的信息。当你用 AI 驱动开发时，它可以直接翻 CloudWatch 日志，读懂错误上下文，修 bug，重新部署，整个闭环几分钟就能跑通。传统架构很难做到这么丝滑。

但无服务器也不是银弹。冷启动延迟、供应商锁定、有限的执行时间，这些都是实打实的限制。关键在于：对一人公司的场景，这些限制基本都能忍，而它带来的好处却是决定性的。

二、为什么要自己造轮子

市面上已经有 Serverless Framework、SST、SAM 这些成熟方案了，为啥还要自己造轮子？

好问题。让我从第一性原理拆解一下。

先说语言选择。 我选 Rust 做后端，理由很朴素：Lambda 按执行时间乘以内存收费。Rust 编译出来的二进制体积小、启动快、内存省、跑得猛，这直接体现在更低的 Lambda 账单上。同样功能的 API，Rust 的运行成本可能只有 Node.js 的五分之一甚至十分之一。当你追求极致省钱的时候，语言选择本身就是架构决策。

但 Rust 在无服务器领域的生态远不如 Node.js 和 Python 丰富。没有哪个框架能给你从路由到数据库操作到认证到部署的一条龙体验。你要么自己东拼西凑一堆库，要么……

再说框架贴合度以及跟基础设施的适配度。 通用框架为了兼容各种场景和服务商，不得不堆上一层又一层的抽象。然而，无服务和基础设施天然是深度耦合的，过度的抽象和通用化，使得框架无法将特定基础设施的特性发挥到极致。如果我想极致地使用 SSM / CloudFront / KVS / SQS / EventBridge 等 AWS 服务，我还是需要自己写大量的胶水代码，通用框架的价值大大缩水。

最后是 AI 的 buff 加成，这才是真正的降维打击。 2026 年造一个框架的成本，和两年前完全不是一回事。我用 Claude Code 作为核心开发工具，写一份详细的设计文档，直接在终端里让它去实现。整个框架核心代码，从设计到落地也就半天。

这里有个很多人没意识到的点：Rust + AI 是一对天生的黄金搭档。 Rust 的类型系统和编译器就像一位严厉的师父，AI 写出来的代码只要能过编译，质量下限就有保证。换成 Python 或 JavaScript，AI 生成的代码跑起来可能「看上去没问题」，但暗藏各种运行时 bug，而 Rust 的编译器会在代码落地之前就把这些坑拦住。类型即文档，编译即测试，这种「先验式」的质量保障让 AI 的产出可信度大幅提升。

当造轮子的成本足够低时，「自己造」就不再是奢侈品，而是理性选择。

三、架构全景：一个 Lambda 统治一切

先来看看整体架构，然后我们逐个拆解设计决策。

核心设计理念就是 一个 Lambda 打天下。所有 HTTP 路由都塞进同一个 Lambda 函数，内部用 axum 的 Router 做分发。听起来是不是有点反直觉？不是应该一个端点一个函数吗？

不，恰恰相反。

单函数模型有三个好处： 第一，冷启动的「品种」只有一个。十个端点分十个函数部署，每个函数都有各自的冷启动概率。合并成一个之后，热度集中，冷启动频率直线下降。第二，部署贼简单，就一个二进制文件，完事儿。第三，所有路由共享连接池、配置缓存等资源，不浪费。

框架（我管它叫 operon）用 workspace 结构组织，按职责拆成多个 crate：

operon/
├── core/           # 运行时、中间件、认证、错误处理
├── dynamo/         # DynamoDB 精简封装
├── s3/             # S3 操作 + 预签名 URL
├── webhook/        # Webhook 签名验证
├── facade/         # 统一门面，按需引入
└── cli/            # 脚手架、构建、部署工具

用户侧的代码极其简洁：