两个对手，同一套打法：做成 AI 产品没有秘密

9 月 8 日，Roman Ugarte 坐进 Lenny Rachitsky 的播客录音间，复盘他怎么在一个月里做出 Grok Bot。他是 Grok Bot 的产品负责人，之前是 Cursor 的增长负责人——加入时那家公司只有 15 人左右。

同一年的 4 月 23 日，Cat Wu 坐过同一个座位。她是 Anthropic 的 Claude Code 和 Cowork 产品负责人，工程师出身，中途还去风险投资行业待过一段时间。

这两个人是直接对手。Grok Bot 和 Cowork 抢的是同一批用户：想把知识工作整块交出去的人。Lenny 是 Grok Bot 的重度用户，也是他们 meetup 的合作方；他在节目里说，自己已经把不少用例从 Cowork 和 Codex 迁了过来——迁得非常快。

我把两场对谈的要点摊开逐条对了一遍，发现一件有意思的事：两个不同公司、做竞争产品、隔了四个多月开口的产品负责人，讲的是同一套打法。

不是相似，是逐条重合：原型优先于文档、亲手带早期用户上手、设计师直接提交代码、发布前大规模删功能。

两个对手独立收敛到同一套打法，说明这套打法不是某家公司的文化，也不是某个人的天才，而是结构性的东西。这篇文章把它拆出来。

一、先破一个误解：这不是天才故事

听这类复盘，最常见的归因是：他们团队强、模型强、文化好。这些归因都对，但都没用——不可复制。

真正的变量是成本结构。

我在 忙力所能及的事，是一种安全感 里算过试错的四笔账：做出来、做错了、谁担责、机会。AI 免掉的是第一笔「做出来」。那篇文章讲的是个人试错；Roman 和 Cat 做的事，是把同一笔账从产品开发里也免掉了。

传统产品开发的全套流程——PRD 评审、路线图对齐、职能分工、层层审批——本质上都是给「昂贵迭代」配的缓冲垫：

• 改方向很贵，所以先把计划做对再动手（计划缓冲）；
• 出错很贵，所以用流程把责任摊薄到每个环节（分工缓冲）；
• 接触用户很贵，所以用报表和客服转述代替直接对话（距离缓冲）；
• 删功能比加功能可怕，所以产品只做加法（功能缓冲）。

这些缓冲垫在迭代昂贵时是理性的。问题是 AI 把「做出一个能给人看的原型」的成本从几个月压到了几天甚至几分钟——Cat 的团队用 Claude Code 出原型，以分钟计；Roman 的团队进山洞一个月，做出了 Grok Bot 的内部原型，七周后公测。

迭代一旦便宜，缓冲垫就不再是保护，而是最大的成本本身：你花两周开对齐会，对手在同样两周里已经上线并拿到了真实反馈。

所以这套打法有一个统一的名字：拆缓冲垫。

二、四块缓冲垫，两个团队分别怎么拆

先把结论放在一张表里，再逐块讲细节：

计划缓冲。 Roman 的原话是「go off into a cave for about a month」——在办公室单独划一块区域，用私有 Slack 频道协作，每天做几十个没有先例的小决策。他说如果换成大团队围绕六到十二个月的计划反复讨论，做不出同样的结果。Cat 的版本更激进：在她的团队里，PRD 的位置被原型取代——与其写清楚要做什么，不如直接做出来给人看，争论会快得多。

距离缓冲。 Roman 团队里做产品的人亲自给早期用户打 onboarding 电话：有人连不上电脑，有人走到一半不知道下一步干什么，挂断电话的人第二天之前就得把问题修掉。两个细节值得抄。其一，他们刻意 不先教 试用者内部已经跑通的用法，怕收到的全是「照着示范操作」的假反馈；其二，他们通过朋友介绍找了一位咖啡店老板来用 TestFlight 版本，这位老板持续反馈 Shopify 集成和商品文案的问题——全是硅谷 AI 圈内部试用永远覆盖不到的场景。Cat 的团队把距离压得更短：反馈大约每 10 分钟来一条，而且她明确说不要赞美，「we don’t want platitudes」，只想知道哪里不 work。

分工缓冲。 Roman 说 Cursor 从他加入时的 15 人涨到上千人，他最常重复的一句话还是「我们在同一条船上，看到你认为必须发生的事，就去做，把需要的资源拉进来」——Lenny 给这种行为起的名字是 agency。Cat 团队的做法是把边界直接抹掉：设计师和 PM 往代码仓库里提交改动，工程师和 PM 的角色在融合。她在访谈里给过一个判断：写代码不再是最难的部分之后，决定写什么变得更值钱——分工缓冲保护的恰恰是「决定」和「动手」之间的那道墙。

功能缓冲。 Roman 给了两个可以直接抄的操作。第一个是 launch tweet 检验：做任何东西之前，先写它的发布推文——如果这条推文没有说服力，这件事也许就不该做。第二个是把「Grok Bot now has X」改写成「Grok Bot can now X」：「now has」后面接的是按钮、菜单、集成，「can now」逼你说清楚 bot 到底帮用户多做成了什么事。发布前那两周，团队按这两条标准删掉了模型思考过程、记忆痕迹、开发者调试界面——这些东西对排查问题有用，但用户不需要看。

拆掉四块缓冲垫的结果摆在时间线上：Grok Bot 从第一行代码到公测，七周；Claude Code 保持着以分钟计的「原型→用户→修改」循环。

三、缓冲垫下面的四条共同信念

拆缓冲垫是「怎么做」。「怎么做」下面还有一层「为什么」——两个人没有串过供，但信念也重合。这一节是价值观，比方法论更难抄，也更值钱。

其一：用户没有义务永远站在 AI 的前沿。 Roman 解释他们为什么把 skill 这类概念从用户面前藏起来：用户不需要知道什么是 skill、不需要打任何斜杠命令，这些抽象应该在后台被自动创建。他的原话大意是——要求用户学习你的内部概念，是把你的工程负担转嫁给用户。

其二：决定造什么，比造出来更值钱。 这是 Cat 的「决定写什么」和 Roman 的「launch tweet 检验」的共同底座。原型可以用 AI 分钟级地出，GitHub 上的反馈有上万条，真正稀缺的是把其中绝大多数否掉的判断。这条信念和我在 忙力所能及的事，是一种安全感 里的结论是同一件事在产品侧的镜像：当「做出来」这笔账被免掉，判断、担责、机会这三笔一分没便宜，反而更贵了。

其三：把 Agent 当同事，不当工具。 Roman 管自己叫 colleague-pilled：产品讨论僵住时，换一个问法——如果对面是一个人类同事，在这个情境里我们希望他怎么做？「每个 bot 有自己的电脑」这个设计也来自同一个比喻：新员工入职第一天，你不会让他和你永远共用一台笔记本、互相绊脚、互相拿到对方的凭证。Cat 的方向一致——她流传很广的一个分享里把信任拆成「能力 × 行为可预测性 × 被纠正时的反应」，这是描述同事的公式，不是描述工具的公式。我在 AI 干完了 8 成的活，我才发现需求提错了 里写过这个公式的另一面：Agent 被纠正时的反应（diff、评论、一票否决），恰恰是它开始像同事的地方。

其四：护城河是发现的，不是规划的。 Roman 说得很直接：如果他们当年试图从某张战略图倒推护城河，造不出今天这个产品。Cursor 反复在跑的循环是这样的：

看清 3-6 个月后世界会走到哪
        ↓
用工程把那个未来提前拉到今天（哪怕堆满脚手架）
        ↓
模型追上来了 → 把脚手架全部删掉
        ↓
为下一个 3-6 个月，重来
# generated by hugo AI

Lenny 把这个总结成「moats are discovered, not planned ahead of time」。注意这个循环和「功能缓冲」是咬合的：敢删脚手架，是因为当初堆脚手架的时候就知道它是要删的——脚手架是租来的，不是资产。

四、一个可以带走的诊断器

方法论要能诊断自己才有用。四块缓冲垫各自对应一个可观察的问题，我把它写成了一个十行就能跑完的诊断器——输入你团队的事实，输出你还剩几层缓冲、先拆哪层：

"""缓冲垫诊断器：四个可观察问题，判断你的团队卡在哪一层。"""
from dataclasses import dataclass


@dataclass(frozen=True)
class Buffer:
    name: str
    question: str   # 可观察的诊断问题
    tear_down: str  # 拆掉它的最小动作


BUFFERS: tuple[Buffer, ...] = (
    Buffer("计划缓冲", "原型出来之前，需求要先过 PRD 评审吗？", "让原型代替文档进评审会"),
    Buffer("距离缓冲", "用户的抱怨要经报表或客服转述才到你手上吗？", "给产品同学排一班 onboarding 电话"),
    Buffer("分工缓冲", "设计师和 PM 能直接合并代码吗？", "给非工程角色开提交权限"),
    Buffer("功能缓冲", "上一次删掉用户可见的功能，超过一个月了吗？", "对下周的发布清单跑一遍 can-now 检验"),
)


@dataclass
class TeamFacts:
    """按上面四个问题如实回答，不要猜。"""
    prd_before_prototype: bool
    feedback_via_reports: bool
    non_engineers_can_merge: bool
    deleted_feature_within_month: bool


def diagnose(facts: TeamFacts) -> list[Buffer]:
    """返回仍然存在的缓冲垫列表。"""
    stuck = (
        facts.prd_before_prototype,
        facts.feedback_via_reports,
        not facts.non_engineers_can_merge,
        not facts.deleted_feature_within_month,
    )
    return [b for b, s in zip(BUFFERS, stuck) if s]


def report(label: str, facts: TeamFacts) -> None:
    left = diagnose(facts)
    print(f"{label}: 剩 {len(left)}/4 层缓冲")
    for b in left:
        print(f"  - [{b.name}] {b.tear_down}")


report("企业团队", TeamFacts(True, True, False, False))
report("山洞团队", TeamFacts(False, False, True, True))
# generated by hugo AI

两个样例分别是：我观察到的典型企业产品团队（四层全卡），和按访谈内容自查的 Roman 山洞团队（清零）。实际输出：

企业团队: 剩 4/4 层缓冲
  - [计划缓冲] 让原型代替文档进评审会
  - [距离缓冲] 给产品同学排一班 onboarding 电话
  - [分工缓冲] 给非工程角色开提交权限
  - [功能缓冲] 对下周的发布清单跑一遍 can-now 检验
山洞团队: 剩 0/4 层缓冲
# generated by hugo AI

诊断器故意不问「你们文化好不好」「团队强不强」——那些不可观察，也不可行动。四个问题全部是 yes/no 的事实：有没有 PRD 前置、反馈经不经过转述、非工程角色有没有提交权限、最近一个月删没删过功能。事实可以下周就开始改，文化不行。

五、反方：哪些是创业公司的特权

到这里必须把最强反方摆上桌：这套打法有一个没说出口的前提——你是一支创业公司的小团队。

证据来自 Roman 自己。他在节目里说，Grok Bot 的 GTM 重点是企业和团队，下一个大问题是「记忆在组织层面该长什么样」。但他用来做产品的方法——进山洞、不是申请许可的文化、脚手架用完就删——恰恰是大组织最不能容忍的方法。在百人团队里「看到该做的事就去做」叫 agency，在万人组织里同样的动作叫越权。

更尖锐的证据藏在这期访谈内部。Roman 用「每个 bot 有自己的电脑」来解释设计：新员工不会和同事永远共用一台笔记本。但整理这期对谈的作者去查了官方文档并实测，发现实际是 每位用户一台共享 VM，多个 bot 共享文件、cookie 和登录态——没有隔离。我在 Grok Bot 能当队友，还当不了员工 里写过，企业让数字员工上岗的前提恰恰是那份四步清单：给身份、划边界、定完成、立 Case——可查询、可恢复、可审计。一个没有隔离的 bot，在创业公司的内网里是同事，进了企业就是安全事故。Roman 用来打动人的那个比喻，恰好在他自己宣称的优先级（企业）上最先崩。

我的回应是把「普适」和「特权」切干净：

• 拆四块缓冲垫是普适的。 计划、距离、分工、功能这四层病，大组织只会更重，不会没有。企业产品团队同样应该让原型进评审会、让产品同学接用户电话、给设计师开提交权限、定期删功能。
• 但「删脚手架不留痕」和「不问许可」是特权。 企业版的做法是：拆流程，不拆问责。补偿模型不足的工程脚手架（Roman 循环里那种）该删就删；审计链、权限模型、责任记录这类制度脚手架不能删，只能换——换成更薄、更可自动化的版本。我在 模型与 Agent 的边界正在消失，但企业会选择看不见的那条线 里论证过：企业选边界的位置，永远在能看见责任的地方。

换句话说：Roman 和 Cat 的方法论回答了「怎么把 AI 产品做出来」，但「怎么把它放进企业」是下一道题——那道题的答案不在山洞里，在入职清单上。

写在最后

两个对手给出同一套打法，最大的启示反而是「没有秘密」这四个字：做成 AI 产品，靠的不是天才、不是文化、不是某张战略图，而是停止用昂贵迭代时代的流程，去做便宜迭代时代的产品。

但拆完四块缓冲垫之后，还剩一个问题：原型 AI 能出、代码 AI 能写、反馈每 10 分钟自己涌进来——产品经理还剩下什么工作？两个人给出了同一个答案：判断。决定做什么，决定删什么，决定什么时候放手。

这也是为什么这篇文章和试错那篇是同一件事的两端：AI 把「做出来」变便宜之后，所有便宜不下来的东西——判断、担责、机会——都涨了价。 做产品如此，做职业选择也如此。

你的团队上一次删掉一个用户可见的功能，是什么时候？你和用户的真实声音之间，隔着几层缓冲垫？欢迎留言聊聊你的诊断结果。

See also

• 任务好搬，关系难搬：AI 产品留存的三任务结构
• AI 干完了 8 成的活，我才发现需求提错了
• 别新建系统了：用 GitHub Issue 把 AI-Native SDLC 跑起来
• Grok Bot 能当队友，还当不了员工
• Runbook：把「代码为什么是现在这样」写进版本库