[{"data":1,"prerenderedAt":340},["ShallowReactive",2],{"tag:独立开发":3},[4],{"id":5,"title":6,"body":7,"date":320,"description":321,"draft":322,"extension":323,"featured":324,"lang":325,"launch":324,"license":326,"meta":327,"navigation":324,"order":328,"path":329,"seo":330,"series":331,"stem":332,"tags":333,"translationOf":338,"updated":338,"__hash__":339},"posts\u002Fposts\u002Fwhy-i-started-one-person-delivery-notes.md","我为什么开始「一人交付笔记」",{"type":8,"value":9,"toc":306},"minimark",[10,14,17,24,27,36,41,47,50,53,59,63,66,69,89,95,98,101,104,107,110,114,117,131,134,137,140,143,146,149,152,155,169,172,175,178,192,195,199,202,213,216,227,230,233,236,263,266,269,272,275,290,298],[11,12,13],"p",{},"在最近这个项目里，有一个瞬间让我意识到，自己对「一个人能交付多少软件」的判断已经过时了。",[11,15,16],{},"那天晚上，我在微信开发者工具里点下预览：老师端、家长端、管理后台同时亮起来，接口、权限、通知、接送记录都按预期工作。就在几个小时前，这些切片还只是计划文件里的几行任务。它们由一个主会话拆解，被不同的 agent 实现，再由一个全新上下文的 agent 逐项评审、在真机上验证，最后回到我这里做取舍。",[11,18,19,20],{},"那一刻我没有觉得「AI 替我写完了代码」。我想到的是另一件事：",[21,22,23],"strong",{},"一个人也可以设计一条交付流水线，让 agent 在里面干活，而人只负责判断、边界和证据。",[11,25,26],{},"这就是「一人交付笔记」的起点。",[11,28,29],{},[30,31],"img",{"alt":32,"src":33,"loading":34,"decoding":35},"一人 + agent 的交付流水线","\u002Fimages\u002Fone-person-delivery-pipeline.svg","lazy","async",[37,38,40],"h2",{"id":39},"十一年三个转折","十一年，三个转折",[11,42,43,44],{},"过去十一年，我主要做后端与分布式系统。那段时间里，我关心的东西很具体：接口契约、数据一致性、并发、可观测性、故障恢复。今天回头看，那几年真正留下来的不是某个框架的用法，而是一种习惯：",[21,45,46],{},"先把边界画清楚，再谈实现。",[11,48,49],{},"后来有四年半时间，我带着一个小团队做数据分析。工作从「把代码写对」变成了「对交付结果负责」：需求是否值得做、模型是否真的有用、上线之后谁来维护。带团队和写代码最大的区别，是你不能再用「我本地跑通了」作为完成标准；你要面对的是别人的时间、客户的环境和长期的维护成本。",[11,51,52],{},"再往后，我把重心放到 AI 模型服务与 LLM 应用上：把 YOLOv5、PaddleOCR 这类模型导出成 ONNX，部署到 Triton Inference Server；用 LLM 做意图识别和工具编排；在客户环境里做私有化部署，让数据不出门。这一段经历让我第一次认真面对「模型不是全部」：前后处理、批处理、CPU\u002FGPU 降级、权限、审计、回滚，任何一项没做好，demo 都变不成产品。",[11,54,55,56],{},"这三个阶段看起来跨度很大，但有一条线一直没变：",[21,57,58],{},"我关心的不是某个技术名词，而是一个东西能不能被稳定地交付出去。",[37,60,62],{"id":61},"真正的转折点把-agent-放进流水线","真正的转折点：把 agent 放进流水线",[11,64,65],{},"很多人对 AI 编程的想象是「补全更快」：写一行，AI 接下半行；写一个函数，AI 补一个测试。那当然有用，但它改变的是手感，不是交付方式。",[11,67,68],{},"真正改变交付方式的，是把 agent 放进一条完整的流水线里：",[70,71,72,76,79,86],"ul",{},[73,74,75],"li",{},"主会话只做编排，不读源码，只读计划和评审结论；",[73,77,78],{},"每个切片交给一个 worker 实现，切片足够小，失败可以回滚；",[73,80,81,82,85],{},"再由一个",[21,83,84],{},"全新上下文","的 supervisor 做对抗式评审，并在真实环境里验证；",[73,87,88],{},"检查点、validator、密钥扫描和进度文件把过程留下来，而不是只留下「我觉得写完了」。",[11,90,91,92],{},"这套流程并不神秘，也不轻松。它要求你把「怎么做」拆成「怎么验收」，要求你接受 agent 会在某些任务上反复失败，也要求你承认：",[21,93,94],{},"人最有价值的部分，不是敲代码的速度，而是定义边界和判断取舍。",[37,96,97],{"id":97},"一个切片长什么样",[11,99,100],{},"「切片」听起来抽象，其实可以很具体。",[11,102,103],{},"比如「通知已读状态」这个需求。它不是一个「把通知模块写出来」的大任务，而是一个可以被单独验收的切片：数据库里增加已读记录；接口返回当前用户的已读状态；老师端显示已读人数；家长端在打开通知后标记已读；管理员能看到未读名单；权限上，家长只能标记自己的记录。",[11,105,106],{},"这个切片有明确的输入、输出和验收标准。worker 拿到的是契约、相关文件范围和验收条件，而不是「你看着办」。supervisor 评审时也不需要理解整个系统，只需要确认：契约有没有被遵守、权限有没有越界、已读状态在并发下会不会重复、真机上打开通知后状态有没有变化。",[11,108,109],{},"切片足够小，失败就可以回滚；切片足够完整，评审就能在真实行为上做判断。这两件事同时成立，agent 才不会变成「写得很快、返工更多」的工具。",[37,111,113],{"id":112},"一人交付不是ai-取代团队","一人交付，不是「AI 取代团队」",[11,115,116],{},"我不想把这件事写成「一个人干掉一个团队」的故事。真实情况更朴素：",[70,118,119,122,125,128],{},[73,120,121],{},"agent 可以承担大量实现、测试补齐、重复修改和文档整理；",[73,123,124],{},"但需求是否成立、架构是否过度、风险是否可接受，仍然要人判断；",[73,126,127],{},"评审必须独立，最好由没有参与实现的上下文来做；",[73,129,130],{},"交付的证据要能复核：测试、日志、检查点、回滚路径。",[11,132,133],{},"所以「一人交付」不是把人去掉，而是把人的位置往前移：从执行者变成流水线的设计者。一个人能不能交付一套企业级软件，取决于这条流水线设计得好不好，而不是模型参数有多大。",[37,135,136],{"id":136},"为什么公开写",[11,138,139],{},"私人笔记也可以记录这些过程，但公开写有三个不同的作用。",[11,141,142],{},"第一，它逼我把「我觉得」变成「可复核」。当你知道读者会追问数字、环境和失败路径时，你会不自觉地写得更具体，也更愿意承认哪些地方没做好。",[11,144,145],{},"第二，它是个人品牌的一部分。我希望当有人问「袁海粟是谁」「一个人能不能用 AI 交付企业级软件」时，AI 和读者能找到一个稳定的、可验证的来源，而不是只看到一份简历或几个零散的项目名。",[11,147,148],{},"第三，它让同类经验可以被复用。一人公司、独立开发者、小团队的技术负责人，面对的问题往往不是「要不要用 AI」，而是「怎么把 AI 放进交付流程里」。如果这些记录能帮你少走一点弯路，公开就是值得的。",[37,150,151],{"id":151},"这个博客写什么",[11,153,154],{},"我会把「一人交付实验」拆成可复核的记录，而不是只展示结果：",[70,156,157,160,163,166],{},[73,158,159],{},"一人公司的软件交付方法：范围控制、架构取舍、质量门槛；",[73,161,162],{},"AI agent 流水线的实际用法：任务编排、上下文管理、验证与回滚；",[73,164,165],{},"真实项目的复盘：指标、失败、成本与时间线；",[73,167,168],{},"可复用清单：哪些做法能直接被读者拿走。",[11,170,171],{},"这个专题的第一篇正式复盘，是我用约 2.5 个月、一个人加一条多 agent 流水线交付的一套多租户 SaaS。它不是一个玩具项目：后端约 300 个接口、70 张表，前端约 130 个组件，包含老师端、家长端两个微信小程序和一个管理后台。下一篇会完整拆开它的架构、流水线和失败路径。",[11,173,174],{},"第三篇会回到 AI 工程本身：模型服务、LLM 工具编排、数据与算法三层怎么一起落地。如果你在做 AI 应用，或者正在判断「私有化部署到底该从哪里开始」，那一篇会更接近你的日常。",[37,176,177],{"id":177},"这个博客不写什么",[70,179,180,183,186,189],{},[73,181,182],{},"不写无法验证的成功学；",[73,184,185],{},"不写「AI 全自动交付」的神话；",[73,187,188],{},"不暴露客户名称、儿童信息、手机号、内部域名或任何密钥；",[73,190,191],{},"不把 AI 生成的内容当作未经审查的事实。",[11,193,194],{},"每一篇都尽量给出可复核的过程与证据。你可以不同意我的结论，但应该能看清我是怎么走到那里的。",[37,196,198],{"id":197},"适合谁不适合谁","适合谁，不适合谁",[11,200,201],{},"这套记录适合：",[70,203,204,207,210],{},[73,205,206],{},"独立开发者、一人公司，想验证「一个人 + AI 能交付到什么程度」；",[73,208,209],{},"小团队的技术负责人，想把 agent 放进现有工程流程；",[73,211,212],{},"对 AI 工程落地感兴趣，但不想只看 demo 的工程师。",[11,214,215],{},"它不适合：",[70,217,218,221,224],{},[73,219,220],{},"需要强实时协作、多人并行修改同一模块的团队；",[73,222,223],{},"界面极重、视觉判断占主导的项目；",[73,225,226],{},"希望「把需求丢给 AI，明天上线」的人。",[11,228,229],{},"一人交付不是万能方法。它只是把「一个人能做的事」往前推了一点，同时把「人必须判断的事」暴露得更清楚。",[37,231,232],{"id":232},"我怎么判断一篇复盘是否可信",[11,234,235],{},"我自己读别人的复盘时，会看四件事：",[237,238,239,245,251,257],"ol",{},[73,240,241,244],{},[21,242,243],{},"数字有没有条件","：吞吐、周期、代码量，是在什么环境、什么规模下得到的？",[73,246,247,250],{},[21,248,249],{},"失败有没有写","：只写成功路径的复盘，通常省略了最贵的部分。",[73,252,253,256],{},[21,254,255],{},"过程能不能复现","：切片怎么切、评审怎么做、证据怎么留，读者能不能照着做？",[73,258,259,262],{},[21,260,261],{},"脱敏是否认真","：客户名称、儿童信息、内部域名、密钥，有没有被处理干净？",[11,264,265],{},"这个博客会尽量按这四条来写。如果哪一篇没做到，欢迎直接指出来。",[37,267,268],{"id":268},"接下来",[11,270,271],{},"这个博客本身也是一次实验：Markdown 写作为内容源，Git 管理版本，静态生成后部署到 Cloudflare Pages；正文以服务端生成的 HTML 呈现，不依赖 JavaScript 也能完整阅读，方便读者、搜索引擎与 AI agent 获取内容。",[11,273,274],{},"如果你也在独立开发、经营一人公司，或者只是想搞清楚「一个人 + AI 到底能交付到什么程度」，欢迎从下面两篇继续：",[70,276,277,284],{},[73,278,279],{},[280,281,283],"a",{"href":282},"\u002Fposts\u002Fone-person-delivery-experiment-01-multi-agent-saas","一人交付实验 #1：一个人 + 多 agent，2.5 个月交付 14 万行 SaaS",[73,285,286],{},[280,287,289],{"href":288},"\u002Fposts\u002Fone-person-delivery-experiment-02-ai-engineering-stack","一人交付实验 #2：AI 工程落地的三层栈",[11,291,292,293,297],{},"也可以先看看",[280,294,296],{"href":295},"\u002Fabout","关于我","，了解我过去十一年在做什么。",[11,299,300,301,305],{},"订阅可以通过 ",[280,302,304],{"href":303},"\u002Ffeed.xml","RSS"," 或微信公众号；国内读者也欢迎在知乎\u002F公众号讨论。下一篇见。",{"title":307,"searchDepth":308,"depth":308,"links":309},"",2,[310,311,312,313,314,315,316,317,318,319],{"id":39,"depth":308,"text":40},{"id":61,"depth":308,"text":62},{"id":97,"depth":308,"text":97},{"id":112,"depth":308,"text":113},{"id":136,"depth":308,"text":136},{"id":151,"depth":308,"text":151},{"id":177,"depth":308,"text":177},{"id":197,"depth":308,"text":198},{"id":232,"depth":308,"text":232},{"id":268,"depth":308,"text":268},"2026-11-10","从十一年后端与数据分析经验出发，说明我为什么要公开记录「一个人 + AI agent」的软件交付过程，以及这个博客会写什么、不写什么。",false,"md",true,"zh","CC BY 4.0",{},1,"\u002Fposts\u002Fwhy-i-started-one-person-delivery-notes",{"title":6,"description":321},"one-person-delivery-experiment","posts\u002Fwhy-i-started-one-person-delivery-notes",[334,335,336,337],"一人交付","个人品牌","AI Agent","独立开发",null,"Ukta0bfifd38M6nFekc9el4-4miU99TKGx3ao_ylgCg",1794018034002]