我必须承认，看到 Garry Tan 分享的数据时，我愣住了。
60 天，60 万行代码，日均产出 1-2 万行可用代码。
作为 Y Combinator 的 CEO，在管理顶级孵化器的同时，还能保持如此惊人的编码输出。这让我不禁反思：我每天都在用 Claude 辅助编程，为什么效率差距这么大？问题显然不在于模型或工具，而在于工作方式。
我的旧模式 vs Garry Tan 的新范式
过去，我更多是把 AI 当作一个加强版的“结对编程”伙伴。想实现某个功能，就让 Claude 直接生成代码，然后自己审查、修改、提交。本质上，这仍然是“单打独斗”，AI 只是让这个过程快了一点。
而 Garry Tan 的做法截然不同。他将 Claude Code 武装成了一个分工明确的“虚拟团队”，通过一系列斜杠命令构建了完整的工作流：
/office-hours： 首席战略官，优先重构问题而非直接动手。/plan-ceo-review： CEO视角，评估产品方向与价值。/plan-eng-review： 工程经理，负责锁定技术架构与数据流。/review： 资深工程师，专门查找那些 CI 能通过但上线会出问题的隐蔽 Bug。/qa： QA 负责人，能自动打开浏览器进行端到端测试，发现问题后自行修复并生成回归测试用例。/ship： 发布工程师，一个命令完成测试、覆盖率检查、提交代码和创建 PR。
这套包含15个角色、6个核心工具的方法论，将 AI 从“高级助手”转变为遵循标准工作流的“高效员工”。
三个颠覆性的核心实践
1. /office-hours: 强制“先想清楚，再动手”
这个命令对我启发最大。当你提出“我想做一个日历每日简报 app”时，它不会立即开始编码，而是会像导师一样反问你：
- 你具体的痛点是什么？能举个实际例子吗？
- 你做这个功能的根本目的是什么？
- 你意识到这个需求实际意味着什么吗？
经过几轮对话，它可能会点醒你：“你所说的‘每日简报应用’，实际上描述的是一个‘个人首席助理 AI’（personal chief of staff AI）。”
这正是 Garry Tan 强调的 Think → Plan → Build → Review → Test → Ship 流程的起点。这个流程不是摆设，它强制你在写第一行代码之前，就对问题和目标进行深度思考与重构。这有效避免了“开发中途发现方向错误，被迫推倒重来”的常见窘境。
2. 流程化并行：解锁个人最大杠杆
Garry Tan 提到他可以同时管理 10-15 个 sprint。每个 sprint 大约30分钟，遵循上述完整流程，从头到尾交付一个小功能。
关键在于“并行”。不同的功能、不同的分支、不同的 Claude Code 会话可以同时推进，互不干扰。他对此的精辟总结是：“没有流程，十个智能体就是十份混乱；有了流程，十个智能体就是十名高效员工。”
我曾认为单人开发谈“并行”是自欺欺人，但 Garry Tan 改变了我的看法——是严谨的流程让高效的并行成为可能。这本质上是一种将软件工程中的敏捷开发方法论应用到人机协作中的实践。
3. /qa: 拥有“眼睛”的自动化测试
/qa 的能力最令我惊讶。它不仅仅是运行单元测试，而是能：
- 启动真实的浏览器。
- 访问你的应用预览环境。
- 模拟用户进行点击操作，测试完整业务流程。
- 发现 Bug 后自行修复。
- 生成防止问题复现的回归测试。
- 再次验证修复结果。
Garry Tan 说这个技能让他的“并行工作者”从6个扩展到12个，因为他不再需要亲自进行繁琐的手动测试。他说：“智能体现在有了眼睛（The agent has eyes now）。” 我深表认同。以往让 AI 修复 Bug，常陷入“修完一个又出现一个”的循环，因为它并未真正“看到”界面状态。/qa 赋予了 AI 视觉反馈能力，这是一个质的飞跃。
总结与启示
Garry Tan 有一句话令我印象深刻：“模型每周都在变强。我们正站在一场真实变革的黎明——一个人可以达到过去需要二十人团队才能实现的交付规模。”
“一人堪比二十人团队”，这正逐渐成为现实。我并非盲目崇拜 AI，但 Garry Tan 的实践证明了其可行性。他的方法论内核并不神秘，就是将成熟的软件工程最佳实践——清晰的职责分工、严格的流程管控、闭环的质量保障——系统地移植到 AI 驱动的开发工作流中。
掌握这套方法的人，实现效率的十倍提升并非奢望。我已经开始尝试按照这个范式调整我的工作方式。如果你也在探索如何更高效地利用 AI 编程，欢迎在云栈社区交流你的心得。
Garry Tan 开源项目地址：https://github.com/garrytan/gstack
发表于 1 小时前
|
查看: 8|
回复: 0
