我为什么开始「一人交付笔记」

在最近这个项目里，有一个瞬间让我意识到，自己对「一个人能交付多少软件」的判断已经过时了。

那天晚上，我在微信开发者工具里点下预览：老师端、家长端、管理后台同时亮起来，接口、权限、通知、接送记录都按预期工作。就在几个小时前，这些切片还只是计划文件里的几行任务。它们由一个主会话拆解，被不同的 agent 实现，再由一个全新上下文的 agent 逐项评审、在真机上验证，最后回到我这里做取舍。

那一刻我没有觉得「AI 替我写完了代码」。我想到的是另一件事：一个人也可以设计一条交付流水线，让 agent 在里面干活，而人只负责判断、边界和证据。

这就是「一人交付笔记」的起点。

一人 + agent 的交付流水线

十一年，三个转折

过去十一年，我主要做后端与分布式系统。那段时间里，我关心的东西很具体：接口契约、数据一致性、并发、可观测性、故障恢复。今天回头看，那几年真正留下来的不是某个框架的用法，而是一种习惯：先把边界画清楚，再谈实现。

后来有四年半时间，我带着一个小团队做数据分析。工作从「把代码写对」变成了「对交付结果负责」：需求是否值得做、模型是否真的有用、上线之后谁来维护。带团队和写代码最大的区别，是你不能再用「我本地跑通了」作为完成标准；你要面对的是别人的时间、客户的环境和长期的维护成本。

再往后，我把重心放到 AI 模型服务与 LLM 应用上：把 YOLOv5、PaddleOCR 这类模型导出成 ONNX，部署到 Triton Inference Server；用 LLM 做意图识别和工具编排；在客户环境里做私有化部署，让数据不出门。这一段经历让我第一次认真面对「模型不是全部」：前后处理、批处理、CPU/GPU 降级、权限、审计、回滚，任何一项没做好，demo 都变不成产品。

这三个阶段看起来跨度很大，但有一条线一直没变：我关心的不是某个技术名词，而是一个东西能不能被稳定地交付出去。

真正的转折点：把 agent 放进流水线

很多人对 AI 编程的想象是「补全更快」：写一行，AI 接下半行；写一个函数，AI 补一个测试。那当然有用，但它改变的是手感，不是交付方式。

真正改变交付方式的，是把 agent 放进一条完整的流水线里：

主会话只做编排，不读源码，只读计划和评审结论；
每个切片交给一个 worker 实现，切片足够小，失败可以回滚；
再由一个全新上下文的 supervisor 做对抗式评审，并在真实环境里验证；
检查点、validator、密钥扫描和进度文件把过程留下来，而不是只留下「我觉得写完了」。

这套流程并不神秘，也不轻松。它要求你把「怎么做」拆成「怎么验收」，要求你接受 agent 会在某些任务上反复失败，也要求你承认：人最有价值的部分，不是敲代码的速度，而是定义边界和判断取舍。

一个切片长什么样

「切片」听起来抽象，其实可以很具体。

比如「通知已读状态」这个需求。它不是一个「把通知模块写出来」的大任务，而是一个可以被单独验收的切片：数据库里增加已读记录；接口返回当前用户的已读状态；老师端显示已读人数；家长端在打开通知后标记已读；管理员能看到未读名单；权限上，家长只能标记自己的记录。

这个切片有明确的输入、输出和验收标准。worker 拿到的是契约、相关文件范围和验收条件，而不是「你看着办」。supervisor 评审时也不需要理解整个系统，只需要确认：契约有没有被遵守、权限有没有越界、已读状态在并发下会不会重复、真机上打开通知后状态有没有变化。

切片足够小，失败就可以回滚；切片足够完整，评审就能在真实行为上做判断。这两件事同时成立，agent 才不会变成「写得很快、返工更多」的工具。

一人交付，不是「AI 取代团队」

我不想把这件事写成「一个人干掉一个团队」的故事。真实情况更朴素：

agent 可以承担大量实现、测试补齐、重复修改和文档整理；
但需求是否成立、架构是否过度、风险是否可接受，仍然要人判断；
评审必须独立，最好由没有参与实现的上下文来做；
交付的证据要能复核：测试、日志、检查点、回滚路径。

所以「一人交付」不是把人去掉，而是把人的位置往前移：从执行者变成流水线的设计者。一个人能不能交付一套企业级软件，取决于这条流水线设计得好不好，而不是模型参数有多大。

为什么公开写

私人笔记也可以记录这些过程，但公开写有三个不同的作用。

第一，它逼我把「我觉得」变成「可复核」。当你知道读者会追问数字、环境和失败路径时，你会不自觉地写得更具体，也更愿意承认哪些地方没做好。

第二，它是个人品牌的一部分。我希望当有人问「袁海粟是谁」「一个人能不能用 AI 交付企业级软件」时，AI 和读者能找到一个稳定的、可验证的来源，而不是只看到一份简历或几个零散的项目名。

第三，它让同类经验可以被复用。一人公司、独立开发者、小团队的技术负责人，面对的问题往往不是「要不要用 AI」，而是「怎么把 AI 放进交付流程里」。如果这些记录能帮你少走一点弯路，公开就是值得的。

这个博客写什么

我会把「一人交付实验」拆成可复核的记录，而不是只展示结果：

一人公司的软件交付方法：范围控制、架构取舍、质量门槛；
AI agent 流水线的实际用法：任务编排、上下文管理、验证与回滚；
真实项目的复盘：指标、失败、成本与时间线；
可复用清单：哪些做法能直接被读者拿走。

这个专题的第一篇正式复盘，是我用约 2.5 个月、一个人加一条多 agent 流水线交付的一套多租户 SaaS。它不是一个玩具项目：后端约 300 个接口、70 张表，前端约 130 个组件，包含老师端、家长端两个微信小程序和一个管理后台。下一篇会完整拆开它的架构、流水线和失败路径。

第三篇会回到 AI 工程本身：模型服务、LLM 工具编排、数据与算法三层怎么一起落地。如果你在做 AI 应用，或者正在判断「私有化部署到底该从哪里开始」，那一篇会更接近你的日常。

这个博客不写什么

不写无法验证的成功学；
不写「AI 全自动交付」的神话；
不暴露客户名称、儿童信息、手机号、内部域名或任何密钥；
不把 AI 生成的内容当作未经审查的事实。

每一篇都尽量给出可复核的过程与证据。你可以不同意我的结论，但应该能看清我是怎么走到那里的。

适合谁，不适合谁

这套记录适合：

独立开发者、一人公司，想验证「一个人 + AI 能交付到什么程度」；
小团队的技术负责人，想把 agent 放进现有工程流程；
对 AI 工程落地感兴趣，但不想只看 demo 的工程师。

它不适合：

需要强实时协作、多人并行修改同一模块的团队；
界面极重、视觉判断占主导的项目；
希望「把需求丢给 AI，明天上线」的人。

一人交付不是万能方法。它只是把「一个人能做的事」往前推了一点，同时把「人必须判断的事」暴露得更清楚。

我怎么判断一篇复盘是否可信

我自己读别人的复盘时，会看四件事：

数字有没有条件：吞吐、周期、代码量，是在什么环境、什么规模下得到的？
失败有没有写：只写成功路径的复盘，通常省略了最贵的部分。
过程能不能复现：切片怎么切、评审怎么做、证据怎么留，读者能不能照着做？
脱敏是否认真：客户名称、儿童信息、内部域名、密钥，有没有被处理干净？

这个博客会尽量按这四条来写。如果哪一篇没做到，欢迎直接指出来。

接下来

这个博客本身也是一次实验：Markdown 写作为内容源，Git 管理版本，静态生成后部署到 Cloudflare Pages；正文以服务端生成的 HTML 呈现，不依赖 JavaScript 也能完整阅读，方便读者、搜索引擎与 AI agent 获取内容。

如果你也在独立开发、经营一人公司，或者只是想搞清楚「一个人 + AI 到底能交付到什么程度」，欢迎从下面两篇继续：

也可以先看看关于我，了解我过去十一年在做什么。

订阅可以通过 RSS 或微信公众号；国内读者也欢迎在知乎/公众号讨论。下一篇见。

评论