Loading... # 27天交付一个商用Agent系统经验之谈 # 一、概述 ## 1. 背景 2024 年 1 月，作者在研究开源项目 OpenClaw 时，发现其创始人 Peter 在 66 天内一人提交了 7178 次代码，日均 127 次，其中最多的一天达到 349 次——平均每 4 分钟一次提交。这种惊人的开发速度下项目没有失控，反而获得了 23 万多个 GitHub stars。 ## 2. 项目介绍 作者受此启发，在 2025 年 2 月使用类似方法论，用 27 天时间完成了 AgentWay（https://agentway.dev/zh）的开发。这是一个帮助开发者从 Agent 使用者转型为 Agent 开发者的渐进式学习平台。项目最终实现了 1038 次 commit，15 个版本发布，并上线开始收费。 ## 3. 核心问题 一个人加一个 Coding Agent，能不能从零交付一个可收费的商用系统？这种工作模式真正的瓶颈在哪里？ # 二、方法论解析 ## 1. 原子化提交 ### A. Peter 的实践 翻看 Peter 的 git 历史，第一个印象是 commit message 极其规整： - fix: honor state dir override in config resolution - fix: migrate legacy state/config paths - feat: add gateway websocket control 每个 commit 只做一件事。在 8297 次提交中，fix 占 31%，feat 仅占 10%。大量提交是修正而非构建，说明他的策略并非一次做对，而是快速试错加高频修正。Peter 自己说：我不再读代码，我看代码流动。 ### B. 作者的实践 开发 AgentWay 时，作者刻意练习了这个习惯。27 天 1038 次 commit，如果只看周末，日均也达到了 100+ 次，和 Peter 的 127 次旗鼓相当。关键是粒度：一个 API 路由一次 commit，一个样式调整一次 commit，不再攒到差不多了才提交。 ```mermaid graph LR A[开发任务] --> B[拆解为最小单元] B --> C[立即提交] C --> D[发现问题] D --> E[快速修正] E --> F[再次提交] F --> C ```  ### C. 效果验证 一个例子，当 OAuth 回调在语言切换时丢失 locale 参数，能通过 git log 在五分钟内定位到是哪次提交引入的问题。要是以前的大粒度提交，这种 bug 够排查一下午。 ## 2. Commit 类型分析 ### A. Peter 的分布 Peter 的提交分类分布是：fix 31%、docs 14%、feat 10%、chore 9%。fix 远超 feat，docs 比 feat 还多。初看反直觉——一个高速推进的项目，修 bug 的时间比写功能的时间多？ ### B. 作者的分阶段数据 当把自己 AgentWay 的 commit 按阶段拆开看，发现了一模一样的规律，只是更极端： ```mermaid graph TD A[原型期] --> B[feat 79%] B --> C[fix 3%] D[商业化期] --> E[feat 30%] E --> F[fix 42%] C --> G[日均59次commit] F --> H[日均23次commit] ```  原型期 Agent 几乎不犯错，描述页面结构它就能给出可运行的骨架——79% 都是 feat，日均 59 次，两天搭完设计系统和 17 个页面模板。但到了商业化期，彻底反转：feat 只剩 30%，fix 飙到 42%，日均降到 23 次。 越往后期，修的比建的多，速度越来越慢。Peter 66 天的全局数据把这个曲线抹平了，但分阶段看一定是同样的趋势——他的 fix 占 31%，是因为 OpenClaw 在 1 月已经进入成熟期，整体数据被后期拉高。 ## 3. CLAUDE.md 的作用 ### A. 基础设施定位 Peter 特别强调 CLI 优先的工具选择：vercel、psql、gh、axiom 这些都有 CLI。Agent 可以直接使用它们，只需要在 CLAUDE.md 里写一行就够了。他把 CLAUDE.md 当作 Agent 操作手册——告诉 AI 可以用什么工具、项目结构是什么、有哪些约束。 ### B. AgentWay 的 CLAUDE.md 演化 AgentWay 的 CLAUDE.md 在 27 天里从一个简单的技术栈说明，长到了 3.30 版本的完整工程规范，包含： 1. 技术栈表（Next.js 16 + Supabase + Tailwind CSS 4 + Claude Agent SDK） 2. 关键约束（Async Params 必须 await、i18n 导航必须用项目组件而非 next/link） 3. 5 个已知修复方案（Dark Mode 对比度、Flex 容器子元素被压缩等） 4. 4 份 Checklist（新页面、API Routes、组件、Gamification UI） 5. 详细参考文件索引表（13 个 reference 文件按场景索引） ### C. 经验累积机制 每次踩一个坑——比如 flex 布局子元素被压缩而不触发滚动——修完就把修复方案写进 CLAUDE.md。下次遇到同类问题，Agent 可以直接参照，相当于给 Agent 的累积经验值。 ```mermaid graph LR A[发现Bug] --> B[定位问题] B --> C[修复Bug] C --> D[写入CLAUDE.md] D --> E[Agent学习修复方案] E --> F[未来同类问题自动解决] ```  ## 4. Agent 的 ROI 分界线 ### A. 分界线之上（Agent ROI 极高） 确定性任务。搭监控栈时把已有项目的配置作为参考喂给 Agent，描述需要调整的部分，它一次交付了完整的 docker-compose 编排（10 个容器）、Telegraf 采集配置、Grafana 数据源和仪表盘。Caddy 反向代理、CI/CD 流水线、Cloudflare Tunnel 零信任访问，都是这个模式——有参考、需求明确、配置驱动。 ### B. 分界线之下（Agent 几乎无用） 需要商业判断的决策。定价选了一次性买断而非订阅，不只是因为 2026 年订阅疲劳明显，更因为一次性付费和产品的极简主义设计哲学一致——不想让用户每个月想一次要不要续。免费和付费的切分花了大量时间：基础课程完全免费约 10 小时内容，给够价值让用户自己判断质量；刻意不卖任何进度——XP、等级、徽章只能通过学习获得，一旦进度可购买，Gamification 激励就失效了。 ```mermaid graph TD A[Agent能力边界] --> B[ROI极高] A --> C[ROI极低] B --> B1[确定性任务] B --> B2[配置驱动] B --> B3[有参考] C --> C1[商业判断] C --> C2[产品决策] C --> C3[用户体验] ```  # 三、开发模式转变 ## 1. 从不读代码到定义问题 ### A. 工作循环 Peter 说我不再读代码，我看代码流动。实践之后才明白——当 Agent 能处理大部分实现细节时，工作从写代码变成了一个持续循环： 1. 把模糊的想法拆解成明确的指令 2. 让 Agent 交付 3. 在真实环境里验证 4. 发现问题后重新拆解 越往后期走，第 1 步和第 4 步的权重越大，第 2 步的权重越小。这也解释了为什么日均 commit 从框架期的 67 次降到商业化期的 23 次——每次 commit 前的定义问题时间变长了。 ### B. 信任校准 OAuth 回调在语言切换时丢失 locale、Flex 布局子元素被压缩而不触发滚动、Dark Mode 下强调色背景与白色文本对比度不足——这类问题 Agent 第一次写不对。需要在真实环境里发现它，然后把感觉有问题转化成 Agent 能执行的精确指令。 Peter 用信任校准解决这个问题：Codex 95% 信任度可直接合并，Claude Code 80% 需要快速 review，其他低于 70% 仔细检查。作者的做法更简单粗暴：原型期基本全信，商业化期每次都 review。因为到了后期，Agent 犯的错更微妙——逻辑上总是差一点。 ```mermaid graph LR A[模糊想法] --> B[拆解为明确指令] B --> C[Agent交付] C --> D[真实环境验证] D --> E{发现问题?} E -->|是| F[重新拆解] F --> B E -->|否| G[完成] ```  ## 2. 产品演化而非规划 ### A. OpenClaw 的渐进式演化 OpenClaw 的产品路径是教科书级别的渐进式演化： - Phase 1：WhatsApp 消息中继器 - Phase 2：加上 AI Auto-Reply - Phase 3：变成 Multi-Agent 架构 - Phase 4：跃升 macOS 原生桌面 - Phase 5：统一为多渠道 Gateway - Phase 6：进入成熟期 每个阶段都是前一阶段的自然延伸，从未出现过大规模重写。 ### B. AgentWay 的演化路径 AgentWay 的路径类似，但压缩了： - 第 1-2 天：HTML 原型，纯静态页面验证设计系统 - 第 3-7 天：迁移到 Next.js，加认证、课程体系、闪卡 - 第 8-14 天：Gamification、Discord Bot、AI Agent 对话、完整 API - 第 15-27 天：Stripe 支付、PostHog 埋点、安全加固、Docker 部署 ```mermaid gantt title AgentWay 27天开发计划 dateFormat D axisFormat %d section 原型期 HTML原型设计系统 :a1, 1, 2 section 框架期 迁移Next.js认证课程 :a2, 3, 7 section 功能期 Gamification Discord Bot :a3, 8, 14 section 商业化期 Stripe支付 PostHog埋点 :a4, 15, 27 ```  ### C. 关键决策 关键决策是第 2 天做的：不直接上 Next.js，先用 HTML 出一个完整的设计系统。17 个页面模板在浏览器里跑起来之后，设计语言、组件库、色彩体系全部确定。迁移到 Next.js 时只是把这些静态页面活化，而非边搭框架边设计 UI——这比 Peter 的做法多了一步，但省掉了后期大量的样式返工。 # 四、核心洞察 ## 1. AI 只是放大器 从 Peter 身上学到的最重要的一课，在他那句 AI 工具只是放大器，真正的驱动力是经验积累带来的判断力。 Peter 有 PSPDFKit 服务财富 100 强企业超过十年的经验，有 Insight Partners 1.16 亿美元战略投资带来的财务自由。他能以一人之力推进 OpenClaw，更重要的是他知道每一步该做什么、不该做什么。AI 把他的判断力放大了 100 倍。 ## 2. 经验的重要性 AgentWay 能在 27 天交付，前提是已经有足够的全栈开发经验来判断：什么时候该用 Server Component，什么时候该加 use client；RLS 策略怎么设计才能不留安全漏洞；Gamification 的 XP 公式怎么定才能激励而不通货膨胀。Agent 能写出所有这些的实现代码，但该不该这么做的判断来自经验。 这也是为什么 feat 从 79% 跌到 30% 而 fix 从 3% 涨到 42%——问题变难了。早期的问题是搭一个登录页面，Agent 一次做对；后期的问题是为什么用户在第三步流失了，Agent 甚至不知道这是个问题。 ```mermaid graph TD A[早期问题] --> B[搭一个登录页面] B --> C[Agent一次做对] D[后期问题] --> E[为什么用户在第三步流失] E --> F[Agent甚至不知道这是个问题] C --> G[feat 79%, fix 3%] F --> H[feat 30%, fix 42%] ```  # 五、结论 一个人加一个 Agent 能交付一个商用系统，前提是那个人本来就能交付，只是以前需要更多时间。Agent 改变的是速度，能力边界还是需要依靠人的主观能动性。 Vibe Coding 真正的瓶颈不是 AI 工具的能力，而是开发者自身的经验积累和判断力。AI 把这种判断力放大了，但无法替代它。 *** ## 参考资料 1. [27天交付一个商用Agent系统经验之谈](https://x.com/wquguru/status/2027716143625187748) 2. [AgentWay - 渐进式学习平台](https://agentway.dev/zh) 最后修改：2026 年 03 月 01 日 © 允许规范转载 赞 如果觉得我的文章对你有用，请随意赞赏