全文约 3500 字，如果你现在没有时间，试试转成播客稍后再听 “我们正处在一个全新的构建软件时代，agent 时代。
我们每天为你更新硅谷最新的 AI 创业与科技播客总结，让你与前沿保持同频。全文约 3900 字，如果你现在没有时间，试试转成播客稍后再听晚点再听LaterCast
“我们正处在一个全新的构建软件时代，agent 时代。”
“让 agent 做真正工作的方式，和人类作为团队工作的方式一样：角色、流程和评审。”
“瓶颈不是模型的智能。只要把模型设置对，它们已经足够聪明。”
这一期主讲人是 YC 总裁兼 CEO Gary Tan。按照他的自我介绍，他学的是计算机系统工程，早年在 Palantir 做过工程师、设计师和产品经理，后来联合创办 Posterous，也写过 YC 内部社交平台和知识库 Bookface 的第一版。换句话说，这不是一场“AI 会改变软件开发”的泛泛演讲，而是一个长期写代码、带团队、看创业公司的操盘手，试图回答一个更具体的问题：当 Claude Code 这类 agent 已经能写大量代码时，人应该怎样组织它，才不只是得到一堆看起来合理、实际会坏掉的代码？Gary 还补充了一个很有冲击力的体感：过去两个月，他写的代码比 2013 年一整年还多；而 Posterous 当年花了两年、上千万美元和十人团队才做出来的东西，如今他已经能用 agent 复刻出很大一部分。
别把模型当实习生，要先给它团队结构
Gary 的核心判断很直接：今天的问题不是模型不够聪明，而是我们经常把模型丢进代码库，然后期待它自己知道该怎么工作。默认状态下，模型会游荡，会补全，会猜测；在一个真实项目里，这种“看起来很像”的产出最危险，因为它可能静悄悄破坏已有逻辑。他把 Claude Code 的正确用法，从“更强的单个助手”改写成“需要角色、流程和评审的工程团队”。GStack 就是他为此写的一套薄脚手架，把复杂度放在 skills 里，而不是堆一个笨重外壳。
“开箱即用时，模型会到处游荡。它不了解你的数据，所以会猜。”
这句话对工程团队尤其刺耳。过去我们担心 AI 不会写代码，现在更现实的问题是：它写得太快，快到人类 review 跟不上。Gary 说，只要把模型设置对，它们已经足够在代码库里做出非凡的工作。真正稀缺的不是“再多一个提示词”，而是一套能让 agent 明确任务边界、知道何时停下、知道如何自检的生产流程。Gary 反复强调的 thin harness、fat skills，本质上也是这个意思：外层框架应该尽量薄，真正的能力沉到可复用的专业技能里，让每一次构建都沿着同一套质量标准往前走。
Office Hours：先问“谁真的想要这个”
视频里第一个演示不是写代码，而是 YC Office Hours。Gary 让 GStack 帮他想一个报税工具：自动去 Gmail 和金融机构里找 1099 表格。普通 agent 收到这个需求，很可能直接开始做 Gmail 搜索和 PDF 下载；Office Hours 先停下来，问一个 YC 式问题：你凭什么知道有人真的要这个？随后它继续追问，TurboTax、H&R Block、Plaid 已经在做类似事情，为什么还没有解决你的问题？这一步的价值，是把“我想做一个功能”提前改成“这个痛点有没有足够强的商业楔子”。
“决定其他一切的问题是：你有什么最强证据证明真的有人想要这个？”
这个例子后来变得更有意思。模型没有停在“每年收几美元帮用户聚合税表”，而是推导出更大的路径：先用“找到所有 1099”作为入口，再把用户带到报税准备和 CPA 匹配。Gary 认可这个方向，因为交易抽成的价值可能远高于单纯文档聚合。对产品经理和创业者来说，GStack 在这里不是替你拍脑袋，而是把 YC 合伙人常问的商业问题，提前嵌进了构建流程。它先逼你回答需求证据、现有替代品和商业模式，再决定是否值得写代码。这样做会慢几分钟，但能避免团队花几天甚至几周，把一个没人真正想要的功能做得很完整。
好 agent 不是照做，而是帮你改写问题
Gary 特别喜欢 Office Hours 的一点，是它“不像在轨道上跑”。如果他只输入“帮我找 1099”，模型会照做；但真实创业不是把任务执行完，而是理解用户是谁、痛点是什么、现有替代方案为什么不够好。于是这个报税工具被重新塑造成一个浏览器自动化方案：用户自己登录 Gmail 和银行网站，AI 在可见浏览器里导航、寻找税务文档、下载 PDF，全程不需要把凭证交给云端。
“它不是那种沿着轨道走的东西，更像是和你的模型的一场对话。”
这里有一个很实用的启发：AI 编程的起点未必是代码。它可以先帮助你把一个粗糙需求变成更清晰的产品假设，再把方案拆成多个可选路径。Gary 最后选择了“Gmail 加 AI 浏览器自动化，加 CPA 市场”的方向，还补充了一个想法：甚至可以绕过 Google OAuth，让用户直接打开 Gmail，由浏览器 agent 搜索相关邮件和附件。这种方案在几个月前可能没人会认真尝试，但今天它已经变成可以马上验证的产品路线。
计划不是文档，是降低返工的自动化流程
Office Hours 之后，Gary 进入 plan mode。模型给出三条路径：小范围 Gmail 搜索、完整的 Gmail 加浏览器自动化加 CPA 市场、或者从 CPA 端反转 go-to-market。他选了第二条，但没有直接开工，而是继续让系统做多步对抗性评审。评审发现了缺口：没有失败处理、没有隐私章节、2FA 交接没有方案。系统能自动补的就补，不能补的留成后续问题。计划的意义不再是写一份漂亮文档，而是让返工和风险尽量在动手前暴露。
“我们的设计文档经历了两轮对抗性评审，并自动发现和修复了 16 个问题。”
这也是 Gary 所说“像团队一样工作”的具体样子。传统上，一个资深工程师或产品负责人会在动手前指出方案漏洞；现在，这些检查可以变成默认命令。模型不是一次性给答案，而是在不同角色之间来回推敲：CEO 视角看商业，工程视角看实现，设计视角看体验，开发者体验视角看可维护性。最后评分从 6 分提高到 8 分，剩下的问题也被明确记录。这种记录很重要，因为 agent 并不应该假装所有风险都已经消失。它应该把能修的修掉，把还需要人类判断的部分显性化，让工程师知道接下来要盯住什么。
AI 编程的关键，不是更会写代码，而是更会评审
当计划被批准，Claude Code 可以开始写代码。但 Gary 更在意的是后半段：代码写完后如何被检查。他提到 review 可以做 staff 级别的 bug 捕捉，把工作重新过一遍，找出 plan mode 没覆盖到的问题。更关键的是浏览器能力。Gary 说自己写了围绕 Playwright 和 Chromium 的 CLI，让 agent 能截图、点击、填表、下载媒体、跑回归测试，甚至根据真实浏览器问题更新 CSS。
“一旦 agent 开始做计划、设计和编码，我发现自己坐在那里做 QA。”
这句话点出了 AI 编程的新瓶颈：当机器承担更多产出，人类最容易被困在验证环节。Gary 甚至直说，做 QA 可能是软件开发里最没意思的部分，所以必须自动化。如果 agent 只会写代码，你得到的是更快的风险；如果它还能在真实浏览器里验证，你才开始接近可交付的软件工厂。这也是他不满足于 Claude Chrome MCP 的原因：慢、上下文膨胀、动作不稳定，都会在高频 QA 中迅速放大。把浏览器能力做成 CLI，等于把验证变成 agent 可以可靠调用的基础设施。
设计也可以并行，但人要做选择
视频中还有一个很有代表性的环节：Design Shotgun。系统围绕税务文档追踪页面，一次生成三个方向：command center、friendly progress、split view。Gary 逐个看，给 A 四星，觉得 B 更适合普通用户，C 太复杂，于是选了 B。这个过程说明，他并没有把设计判断完全交给模型。agent 负责快速扩展可能性，人负责判断哪一个更贴近用户。
“如果你不喜欢它，可以输入反馈并重新生成；但这次我们选择 B 继续。”
对设计师和产品负责人来说，这个环节比“AI 会不会取代设计”更有参考价值。Gary 要的不是一个炫技界面，而是一个友好的卡片式进度体验，让普通人知道哪些银行、哪些 1099、当前状态是什么。AI 让草案变多，但品味和取舍仍然要回到用户场景。这也是为什么他把设计工具放在整套流程里，而不是单独当成图片生成器。
多 agent 不是更多窗口，而是并行 PR 的工厂
Gary 把 GStack 能达到的状态称作接近“level 7 software factory”。意思不是一个 agent 替你完成所有事，而是你可以同时开多个 Conductor 窗口，在不同项目、不同分支、不同功能上并行推进。他说自己现在经常同时运行 10 到 15 个 Claude Code 会话，有时一个项目就有多个 session，在不同分支上做平行 PR，最后再合并落地。
“我同时运行 10 到 15 个 Claude Code 会话。”
这听起来很激进，但背后仍然是流程，而不是盲目堆 agent。每个想法、bug report、用户抱怨，都可以变成一个独立 worktree；每个 work item 都跑 Office Hours、CEO review、工程评审、对抗性评审和最终 review。并行的前提，是每条线都有清楚的边界和交付门槛。否则，多 agent 只会把混乱并行放大。Gary 的做法更像把每个新想法都变成可追踪的工作单元：它有自己的分支、自己的评审、自己的发布门槛。人类不再手写长长的待办清单，而是不断判断哪些 work item 值得继续、哪些应该停下。
最后一层护栏，是把安全和交付放进默认流程
越是高并行，越不能只看速度。Gary 特别提到，AI coding 里很可怕的一件事是供应链攻击，所以他对开源 PR 非常谨慎。GStack 里的 ship tool 是落到 main 之前的最后一步，负责确认 PR 是否真的准备好合并。对一个每天可能处理很多 PR 的人来说，这不是形式主义，而是把安全、质量和交付节奏变成默认动作。
“我不再有待办清单了。每一个想法或 bug report，都会变成一个新的 work item。”
视频结尾，Gary 说这是历史上最不可思议的软件构建时刻，构建门槛已经坍塌，剩下的问题是你要做什么。放在整期内容里，这句话并不是鸡血。它的前提是：你得有一套足够严格的流程，把想法、计划、设计、代码、浏览器验证、评审和发布连接起来。否则，门槛降低之后，最先到来的不是生产力，而是更多未经验证的半成品。对今天的工程团队来说，这可能是最实际的提醒：不要只问模型能写多少代码，也要问这些代码从哪里来、经过哪些审查、如何在真实用户路径里被验证。
写在最后
把 agent 当团队管理，而不是当魔法按钮使用。先问证据，再定计划，再做评审和验证。模型已经足够快，接下来真正拉开差距的，是你能不能把它放进一套稳定、可复用、能交付的流程里。
内容来源：”How to Make Claude Code Your AI Engineering Team”丨Y Combinator
原视频：https://www.youtube.com/watch?v=wkv2ifxPpF8&t=0s
如果你喜欢深度好文，试试用小程序将不方便立刻阅读的文章转成播客，用「听」的方式，稍后阅读，不再错过好文章⇣
⇣ 关注我，每天为你更新硅谷最新的 AI 创业／科技播客总结，让你与前沿保持同频 ⇣