导语：这几天我把自己的“一人公司”从一个想法，推进成了一个可以运行、可以追踪、可以发布、可以公开访问的 AI 操作系统雏形。
它不是一个简单的 Todo，也不是一个 AI 聊天壳子，而是一套围绕 WorkOrder、AgentState、Risk、Report、RuntimeEvent、Snapshot 组成的最小运行时闭环。
这篇文章记录了我如何把 Solo Company OS 从内部任务系统，推进到 Cloudflare Pages 公网发布、自定义域名、文章入口和传播资产包的完整过程。
核心不是炫技，而是验证一件事：
一个人，能不能用 AI Agent 和工程纪律，维护一套真正为自己服务的软件公司操作系统。
一人公司不等于简单。当你同时是开发者、产品经理、QA、安全审计、DevOps，你需要的不是又一个 Todo 工具，而是一个真正的运行时。
1. 为什么我要做 Solo Company OS
跑一人公司的第三年，我发现自己花在"管理上下文"上的时间，比写代码还多。
Notion 里有规划，GitHub Issues 里有任务，电子表格里有状态，十几个 AI 聊天窗口里有"辅助"。结果呢？上下文散落在 10 个工具里，没有单一事实来源。
有一天我问自己：上周到底完成了什么？
不是计划了什么，不是 commit message 写了什么，而是实际交付了什么、验证了什么、有什么证据。
答不上来。
2. 它不是普通 Todo，也不是 AI 聊天壳子
我决定搭建 Solo Company OS —— 不是又一个项目管理工具，而是一个真正的一人公司操作系统。
核心思路来自分布式系统：在一个良好运行的微服务架构里，每个操作都有：
- Work Order（工作单：做什么）
- Agent State（智能体状态：谁在做）
- Event（事件：发生了什么）
- Report（报告：验证证据）
- Snapshot（快照：时间点真相）
一人公司为什么不能一样？
3. Runtime Core v0.3：任务、智能体、风险、报告、事件流
Solo Company OS 的技术栈：
- Markdown = 事实来源（所有操作记录为 Markdown 文件）
- Rust = 运行时（5 个 crate，7 秒全量测试）
- SQLite = 状态存储（9 张表：work_orders、agent_states、risks、reports、runtime_events、next_actions、notifications、kv_store、schema_migrations）
- AI Agent = 有追踪的劳动力（planner、architect、QA、security、reviewer）
关键设计：每次写操作自动生成运行时事件。
创建工作单？work_order.created 事件记录。更新智能体状态？agent_state.upserted 事件记录。关闭报告？report.created 事件记录。
无需手动日志。系统自动记录自己。
# 创建工作单
solo-db work-order create --title "Fix login bug"
# 系统自动记录：work_order.created
# 更新智能体状态
solo-db agent-state upsert --agent qa --state PASS --work-order-id "Phase 28"
# 系统自动记录：agent_state.upserted
4. 第一次真实操作：Public Proof Stabilization
Phase 28 是 Runtime Core v0.3 的第一次真实操作。
目标：验证整个运行时能否完整跑通一个真实工作单生命周期。
结果：
| 维度 | 数量 |
|---|---|
| Work Orders | 1 |
| Agent States | 4（planner、architect、QA、security） |
| Risks | 2（均为低风险） |
| Next Actions | 3 |
| Reports | 1 |
| Runtime Events | 14 |
健康判定：PASS。
不是因为我说它通过了。是因为系统计算出来的：没有高级别未关闭风险，没有被阻塞的工作单，所有智能体完成成功。
5. 第一次真实业务产出：公开文章
Phase 29 是第一次真实业务操作：写一篇可发布的文章。
文章内容是关于 Solo Company OS 本身的工程复盘。全程用 Runtime Core v0.3 记录：
- 创建工作单
- 5 个智能体状态流转（planner → architect → security → reporter → reviewer）
- 风险评估（内容准确性、路径泄露）
- 生成快照证据
产出：solo-company-os-one-person-ai-operating-system.md，162 行，23 个章节。
6. Cloudflare Pages 与自定义域名上线
Phase 30-31 把文章发布到公网：
- 部署到 Cloudflare Pages（
solo-company-os.pages.dev） - 自定义域名
elvinx.dpdns.org通过 CNAME 指向 Cloudflare - 落地页集成文章链接
- 路径泄露扫描、secret 扫描、HTML 链接检查全部 PASS
过程中踩了一个坑：Cloudflare Pages 部署需要用绝对路径，否则 preview URL 会 404。
另一个坑：DNS A 记录指向了 bogon IP（198.18.2.128），导致自定义域名 404。改为 CNAME 后解决。
7. 这套系统目前解决了什么问题
已解决：
- 单一事实来源：所有操作记录在 SQLite 数据库，可查询、可导出
- 自动事件流：无需手动日志，系统自己记录自己
- 健康判定：基于数据的 PASS/BLOCK，消除主观判断偏差
- 快照导出：任意时间点的运行时状态，JSON 格式
- 公网发布闭环：从写文章到部署上线，全程 Runtime 追踪
量化证据：
- 46 个集成测试全通过
- 7 秒全量测试
- 14 个运行时事件自动记录
- 5 个智能体状态完整流转
8. 还没有解决什么问题
诚实地说：
- 还没有真实收入：目前是技术验证阶段，没有商业变现
- 还没有外部用户：只有我自己在用
- 还没有解决"记忆"问题：当前 Runtime Core 不包含长期记忆，每次对话从零开始
- 还没有解决"自动化"问题：智能体状态需要手动更新，不是全自动
- 还没有解决"协作"问题：目前只支持单人，没有多人协作能力
这些是下一步要解决的问题。
9. 下一步：从公开证明到真实分发
Phase 32-33 完成了落地页导航集成和社交传播资产包生成。
下一步：
- 把文章发到掘金、V2EX、少数派等中文开发者社区
- 收集真实读者反馈
- 根据反馈迭代产品
- 探索商业化可能性
不是"已经赚钱"，不是"彻底自动化公司"，而是：先让系统服务自己，再考虑服务别人。
10. 结尾：软件先服务自己，再考虑商业化
Solo Company OS 的核心理念：
一人公司不等于简单。你需要的不是又一个 Todo 工具，而是一个真正的运行时。
如果你也是一个被上下文散落困扰的独立开发者，欢迎看看这个项目。
项目地址：github.com/1lvinx/solo… 文章原文：elvinx.dpdns.org/public/arti…
技术栈：Rust + SQLite + Markdown + AI Agent 当前版本：Runtime Core v0.3 测试覆盖：46 个集成测试，7 秒全量通过 部署平台：Cloudflare Pages Schema 版本：0002_runtime_core_v0.3
