一人公司：当地基打好后，如何快速盖楼？
九层之台，起于垒土；千里之行，始于足下。 ——《道德经》
题记：这是「一人技术公司」系列的第五篇。现在 OPC (One Person Company) 的概念很火，我也尝个鲜，看看真要严肃地使用周末来做点一家技术公司才能做起来得事情，到底能做成啥样。这并不意味着我要全职创业，我认为我自己是个一直在路上的创业者，朝九晚五从来不是我的束缚。我想通过这个过程，了解 AI 的边界，以及我自己的边界。
整个系列将记录我从零搭建一套完整技术体系的全过程 —— 从基础设施，到网络与运行时，到核心框架，再到应用服务。这不是一篇教程，而是一份带有思考过程的实战手记。
前四篇我们一路肝过来：从网络与安全边界的构筑，到云基础设施的搭建，到 serverless 应用框架的打造，再到内部工具链的完善。每一层都在给上层铺路。
如果说前四篇是在打地基、立钢架、埋管线，那今天这篇，终于要开始「盖楼」了。
本文的核心问题是：当你一个人单干，手握一套精心设计的基础设施，从一个产品灵感到部署上线，到底能有多快？ 答案可能超乎你的想象。
一个周末，真的只需一个周末。
一、从想法到产品：一个人的速度
我想做的是个 AI 时代的幻灯片应用。
这个应用最初是我在极客时间 AI 训练营中的一个项目。当时某天深夜，我在摸鱼试各种 AI 生成 PPT 的工具时，脑子里突然蹦出一个念头：如果我能让 AI 给每张幻灯片单独生成配图，统一视觉风格，再配合文字内容，搞出一套纯 AI 驱动的图文演示稿，会是什么效果？NotebookLM 生成幻灯片虽然能部分满足这个需求，但它无法精细控制。
从冒出这个想法到撸出第一个能跑的原型，我用 Python + FastAPI + React 花了一两个小时。速度是够快，但代码质量嘛… 只能说「又不是不能用」，典型的原型代码：热数据全塞内存里，冷数据放文件，没认证，没持久化，没部署。后来我自己经常用它来生成各种演示稿，用着用着就萌生了把它放到线上、方便随时随地访问的想法。既然要上线，那就不能再是个「能跑就行」的原型了，得是个正经的生产级应用。
想想看：要把这种原型变成生产级产品，你得搞定认证授权、持久化存储、CDN 缓存、密钥管理、多环境部署、域名证书、日志监控… 搁传统团队里，光这些「非功能性需求」就能吃掉几周甚至一个月。但当你手里有一套趁手的基础设施，一套已经完成大部分工作的无服务框架，再加上 Claude Code 这样的 AI 编程利器，画风就完全不一样了。
实际操刀下来，从原型到生产级应用的重写，包括完整的认证、数据持久化、AI 集成、CDN 配置和多环境部署，前后不到一天。 这一天里，Claude Code 承担了大量的重活：根据设计文档生成后端模块、编写前端组件、排查部署问题、优化数据模型。而这一切之所以丝滑得像在流水线上作业，根本原因在于：基础设施足够清晰，有自己写的 operon 无服务器框架打底，Claude Code 才有章可循、有框架可依。
这就引出一个核心洞察：基础设施投资和 AI 编程工具之间存在乘数效应。 基础设施让项目结构一目了然，AI 编程工具就能高效产出；AI 的高效产出又让你有余裕把基础设施打磨得更精良。两者形成飞轮，越转越快。单有好的基础设施而没有 AI，你还是得一行行码；单有 AI 而没有好的基础设施，AI 也只能产出零散的、难以集成的代码片段。两者叠加，才是一人公司真正的杀手锏。
二、Workspace 架构：让应用像细胞一样分裂
回到最根本的问题：基础设施框架到位了，应用代码该怎么组织？
为什么需要 Workspace？
如果每个应用都开一个独立仓库，你很快就会被代码重复搞到崩溃。AI 图片生成的逻辑，幻灯片应用要用，未来的文档应用也得用；边缘认证的逻辑，所有面向用户的应用都逃不掉；分页、用户身份这些通用类型，更是满天飞。
答案是 Rust 的 Workspace 机制。把多个应用塞进一个工作空间，通过共享 crate 来干掉重复：
workspace/
├── crates/ # 共享库
│ ├── golgi-core/ # 通用类型：分页、用户身份、订阅等级
│ ├── golgi-ai/ # AI 能力：图片生成 trait + 多个 provider
│ └── golgi-auth-edge/ # 边缘认证：CloudFront Function 生成
│
├── apps/ # 应用
│ ├── slides/ # 幻灯片 API（Lambda Function URL）
│ └── slides-worker/ # 异步图片生成（SQS Worker Lambda）
│
└── Cargo.toml # Workspace 根配置这个结构妙就妙在：每新增一个应用的成本趋近于零。 共享 crate 提供公共能力，应用框架（operon）提供运行时和部署流水线，你只管专注应用本身的业务逻辑就好。更妙的是，这种规整的目录结构对 Claude Code 来说简直是如鱼得水，它一眼就能看清哪些是共享能力、哪些是应用代码、新应用该往哪儿放。当我让 Claude Code 新建一个应用时，它自动参照已有应用的结构来搭建。
Workspace 依赖管理的门道
在 Workspace 根 Cargo.toml 中集中管理所有依赖版本，看着简单，实则至关重要：
[workspace.dependencies]
# 内部 crate
golgi-core = { path = "crates/golgi-core" }
golgi-ai = { path = "crates/golgi-ai" }
# 应用框架（引用私有注册仓库）
operon = { version = "0.3.1", registry = "chromatin", features = ["dynamodb", "s3", "sqs", "oidc"] }
# 外部依赖统一版本
axum = "0.8"
serde = { version = "1.0", features = ["derive"] }
tokio = { version = "1.49", features = ["rt", "rt-multi-thread", "macros"] }这么做图什么？
第一，版本一致性。 所有 crate 用同一版本的 axum、tokio、serde，依赖冲突？不存在的。
第二，升级原子性。 升级依赖只改一处，全部 crate 同步跟进，不用挨个翻文件。
第三，也是最容易被忽视的一点：给 AI 划好跑道。 当我在 Claude Code 里说「帮我新建一个应用」，它直接查 Workspace 根配置就知道该用什么依赖、什么版本、什么项目结构，甚至连 operon 的 feature flags 怎么开都一清二楚。我不需要反复交代上下文，Claude Code 自己就能从项目结构里推断出一切。
这就引出一个更深层的认知：好的架构不光是给人设计的，更是给 AI 设计的。
仔细想想，AI 编程工具理解你代码的方式跟人其实很像，都是先看目录结构，再看配置文件，然后才深入具体代码。区别在于，人可以靠经验脑补缺失的上下文，而 AI 更依赖显式的、结构化的信息。所以，项目结构越规整、约定越明确、配置越集中，AI 的产出质量就越高。
换句话说，你为 AI 设计的好架构，恰恰也是对人最友好的架构。 这不是巧合，清晰和一致性本身就是好架构的核心特征。AI 只是把「架构是否清晰」这件事的反馈回路缩短到了实时：结构不清晰，AI 马上就给你产出一堆牛头不对马嘴的代码；结构清晰，AI 的产出直接就能用。
三、共享 Crate：把能力变成积木
来看看那些共享 crate 是怎么设计的，以及为什么这种设计对一人公司来说是刚需。
通用类型层
最底层的共享 crate 提供跨应用的通用类型。这些类型看着不起眼，但它们定义了所有应用的「共同语言」：
/// 分页参数 —— 所有列表接口都会用到
pub struct PaginationParams {
pub limit: Option<u32>,
pub cursor: Option<String>, // 基于游标的分页，适合 DynamoDB
}
pub struct PaginatedResponse<T> {
pub items: Vec<T>,
pub next_cursor: Option<String>,
}
/// 用户身份 —— 从 JWT 中提取，所有应用共享
pub struct UserIdentity {
pub user_id: String,
pub email: String,
pub name: String,
pub picture: Option<String>,
pub subscription_tier: SubscriptionTier,
}
/// 订阅等级 —— 为未来的付费系统预留
#[derive(Default)]
pub enum SubscriptionTier {
#[default]
Free,
Pro,
Team,
}注意到 SubscriptionTier 这个枚举了吗？v1 里所有用户都是 Free 等级，付费功能压根还没做。但这个类型已经埋在数据模型和 JWT 声明里了。
