Together AI 产品团队全公开：一套仓库让 PM 下指令就出生产级 PR

关联

人物 Akash · Charles · Nicolina

公司 Together AI

概念 智能体 · 技能 · 上下文 · PRD · 沙箱 · harness · MCP 服务器 · 人在回路 · 原型 · 开源模型 · Claude Code

来源 Product Growth Podcast

这一集聊的是：一家 AI 公司的产品团队，怎么不靠「每个人各自用 AI 变快」，而是靠一套共享仓库让整个团队集体变快。

主角是 Together AI(为 AI 应用和智能体提供算力平台的初创公司，刚融资 8 亿美元)的产品团队——产品负责人 Charles、产品经理 Nicolina 和 Pavneet、开发者体验负责人 Hassan,在主持人 Akash 面前现场打开他们真实的仓库演示。

Charles 的出发点很直接：

当人人都能用智能体随手生成代码和文档，「过了一段时间之后，感觉新的派对失误就是把你同事的上下文塞满，我们全都开始互相扔垃圾内容」。

每个人看着自己很高效，但这些产出的总和「并不必然是公司的前进」。

所以他们把 AI 的使用分成两层：集中管理共享的上下文和技能，个人自由发挥各自的工作流。

仓库长什么样：一个 Markdown 目录 + 一堆技能

Nicolina 展示的「Together 产品仓库」主体是 Markdown 文件加少量 YAML。里面有两类东西：

context(上下文)目录：按产品分组(客户智能、沙箱等)，还包括定期战略会议的成果——按使命划分的产品、季度里程碑。

写调研、和智能体一起写文档时按需拉取。

跨团队协作也靠它：「如果我在创建沙箱，而强化学习用户将会用到，我可以查看 model shaping 团队产品经理已用心写好的文档……

在她审阅之前先拿出一个相当不错的提案」——利用别人已经沉淀的工作，而不是让她从头陪聊。

skills(技能)：放与具体代码无关、团队通用的事。

比如一个「竞品新闻报告」技能，每天早上跑一分钟，汇总过去 24 小时各家模型实验室的动态，Nicolina 喝咖啡时读。还有「sprint 结束状态报告」：

过一遍所有项目，自动生成已发布、进行中、下一步的更新——以前要 10 到 30 分钟排查，现在几分钟输入提示词就行。

仓库接的模型不是锁死一家的：最初用 Claude Code,但现在很多开源 harness 都能读同一套 Markdown。

他们正转向更多用自己的开源模型——一来模型好用，二来「Anthropic 和所有这些其他模型正开始变得相当昂贵」。

谁维护？规则很简单

过期上下文是最怕的事。他们的答案：

谁的领域谁负责(沙箱、客户智能归 Nicolina);战略会议由指定的人把会议产出翻译成 Markdown;方向大转弯时 CEO 会明确写信，那是更新信号。

除此之外像普通代码一样靠 PR:「如果有人主动创建一个 PR、更新 Markdown 文件，那就是那么回事」。

技能放哪也有一套规则：离工作最近的地方。

引用代码的技能放在对应团队的仓库里；其余的先放个人分支试用——「我会看我是否会用上它几次。

如果你确实用了，就把它推到 main」——超级小众的就永远留在分支里。

PM 现场演示：从一句抱怨到生产级 PR

Pavneet(基础设施产品经理，前 Amazon)走了一遍完整流程。

他的划分是：做决策的环节高度人工，执行环节全自动——「定义功能、定义 API 表面积、定义抽象层，那些是非常需要人在环的……

写代码、执行的部分才是被自动化的」。

第一步，功能调研技能同时接入 Pylon(支持工单)、Linear(项目管理)、Notion(内部文档)。

他输入一个真实问题——多少客户在抱怨共享存储无法扩缩容——几十秒后报告回来：

过去六个月大量客户提过，仅过去两个月就有 19 张工单；

还发现这功能其实已被部分实现但坏了、停了，「所以现在我没有在重复、没有在复制别人的工作」。

手动做这些「很容易占掉我半天时间，甚至更多」;再点进 Customer Insights 工具看客户 Moonlake 的通话记录，五分钟就摸清痛点——以前要一整天。

第二步，PRD Writer 技能：

接受调研产出、可选吃进一个 UX 原型，然后对 Pavneet 做逐轮访谈——而且被特别指示「要推动我、在我的假设和决策上挑战我」,还配了题库(有哪些权衡？

有没有单向门决策？)。「它不是我的替代品，但它确实做两件事：加快整个 PRD 撰写，很大程度上解决空白页问题；

还捕捉到很多我可能没想到的东西」——比如它主动提出缩容后计费要立即调整，这是 Pavneet 最初没想到的。

第三步，UX 原型技能：把一页纸 PRD 转成详细提示词，丢进 Figma Make 生成可点的东西。

因为人人能可视化方案，「很多最好的批评性反馈正是来自那里，来自工程、市场或其他任何人」。

这背后是他们重新定义了 AI 时代的 PRD:不再是 Amazon 式的 20 页把关文档，「而是用来触发构思和解决问题的工具」，一到两页，定义客户问题、列方案选项、给一段示例用户旅程。

「取代我们历史上六页纸大部分内容的，其实是一个原型」。

最后一步，PR:因为工程团队维护着一个完整的工程仓库——架构细节、runbook、历史设计文档都以技能形式开放给 Claude——「它能够在第一次尝试时就构建出高保真的 PR」。

过程中它派生多个子智能体分别检查数据平面、控制平面和文档，中途向 PM 要 PRD 或原型。产出也不是直接可用：

最终 PRD 顶部明确标着「草稿」，用户旅程里混进了内部实现细节，仍需 PM 编辑——这正对应「探索设计阶段人在环」的流程设定。

负责人的「上帝视角」：Orchestrator

Charles 日常不用钻进任何单个仓库。

他用内部工具 Orchestrator:公司所有主要仓库都在一个界面里，可以自选 harness(OpenCode / Claude / Cursor)和模型(他自己偏好 GLM + OpenCode),随口问「model shaping 产品最近启用的微调模型是什么」——它后台起一个沙箱、克隆必要的仓库片段、探查代码，一分钟给出答案(最新的是 NVIDIA Nematron Super 120B);发现小问题还能直接从这里生成 pull request。

关键设计是它继承每个仓库本地的 skills 和 MCP 服务器，「我不想为了做一个小改动，就把所有这些都构建进我本地的 open code 里」。

它服务的是「休闲用户」：只是想回答一个问题、解决一个麻烦的人。这背后是他们对共享度的反思：

「我们基本搁置了存在一个巨大的、大家都泡在里面的平面上下文的构想——它更像一个上下文层级结构，有些人属于最深处，有些人只想在顶层穿行」。

想复制？Hassan 说 Orchestrator 大概花了几周到一个月工程时间；必备件是：

接入所有仓库、继承各团队的 MCP 和技能、沙箱机制(每个调研或 PR 都在沙箱里克隆仓库片段完成)、再加一个模型网关/路由器——「每一个组件要么构建起来相对快捷，要么有开源工具，要么有商业软件」。

最后一环：拿智能体当测试用户

Hassan 团队的 Agent Evals 在发布后验证产品对智能体是否好用：

起一个沙箱跑 Claude Code,给它真实任务(比如「用这个数据集跑微调任务，部署成专用 endpoint,发推理请求评估，完了删掉」)，然后看它能不能做成。

一次运行发现智能体找不到「可微调模型列表」的文档页——翻完整转写记录才发现那页没被链接，于是提 PR 修文档。

这类工具已经带来了几十处文档修复。

Charles 认为这是产品验证方式的质变：

过去要等用户测试、收到一堆矛盾信号才能知道设计对不对，而且「对我们很多产品来说，智能体已经是主要用户了」。

「无论你的文档说你的产品是什么，你都可以确信它实际上就是那个样子，因为每隔几个小时我们就有智能体重新验证这一点」。

他说这就是他们这类产品「用户体验的新标准」。

如果产品偏图形界面，就得换用能点击、解读屏幕的视觉推理模型，但思路可平移。

PM 和工程师的边界变了吗？

Akash 追问：产品经理到哪为止、开发者从哪开始？Charles 的答案出人意料地保守：

「每件事的本质，今天和 AI 出现之前并没有太大不同」——产品人的核心仍是带来经过充分验证的、关于市场的独特洞见；

工程师的核心仍是拿出最高效、可维护、利于长期架构的设计。

变的是两边伸进对方领域的便捷度:PM 能深入实现、提交 PR,工程师也能用 Customer Insights 自己做客户分析、建常驻查询。

至于生产力到底涨多少，他很克制：「我肯定可以说我们的速度提升超过了 5%。

我觉得那些说 3 倍的说法非常可疑」——探索、辩论、协调这些环节「并不会因为 AI 而神奇地变好」,压缩研究和编码已经很值了。

成本上他们也经历过 token 开支激增，但靠自有开源模型缓解，而且「如果你专注于让团队整体高效，而不是靠大量产出让自我感觉高效，你最终不太可能落到三倍于人们薪水的疯狂 token 预算上」。

本集带走

• 「集体高效」先于「个人高效」：先集中沉淀共享上下文和技能，防止团队互相倾倒垃圾产出——这是整套体系的地基。

• 上下文靠版本控制式机制保鲜：谁的领域谁负责，战略会议有人翻译成 Markdown,方向转变以 CEO 明确信号为准，其余一律走 PR。

  【背景】原文所用比喻为「类 Git」的版本控制机制。

• 技能放置规则：离工作最近：涉码技能进对应仓库，通用技能先在个人分支试跑几次、验证可重复再合入 main。

• AI 时代 PRD = 一两页触发讨论的文档 + 一个原型：定义客户问题、列方案选项、给一段用户旅程；原型比长文档更能激发跨职能批评。

• 决策环节人在环，执行环节全自动化：定义功能和 API 抽象由 PM 主导，写代码交给带完整工程上下文的智能体，产出标「草稿」、必经人审。

• Orchestrator 类工具四个必备件：接入全部仓库、继承各仓库本地的技能与 MCP、沙箱机制、模型网关——几周到一个月工程量即可搭起。

• 把智能体当第一类用户做持续评估：每个几小时自动重验「产品是否如文档所述」，评估发现的痛点直接变成文档修复 PR。

• 对生产力倍数保持清醒：协调、辩论、探索不会因 AI 消失；可控的成本来自「为团队而非为个人产出」的使用方式。

我们全都开始互相扔垃圾内容。
We all just start launching slop at one another.
—— Charles · [00:05]

对我来说并不清楚的是，所有这些的总和，对我们作为一家初创公司来说是否必然是前进的进步。
And it wasn’t clear to me that the sum of all that was actually necessarily forward progress for us as a startup.
—— Charles · [02:34]

所以我们的看法是，做出决策的那部分，也就是定义功能、定义 API 表面积、定义抽象层，那些是非常需要人在环的，我亲自上手和 Claude 一起做。而写代码、执行的部分，才是被自动化的部分。
So the way we see it is the part which is where the decisions are being made, right, which is defining the feature, defining the API surface area, the abstraction layer, those are very human in the loop, right, where I’m hands on with Claude. And the code writing part, the execution part, is actually the part which is automated.
—— 嘉宾 · [16:57]

所以我们基本搁置了「存在一个巨大的、宽广的、平面的上下文，我们所有人都在其中游泳」的想法。它更像是一个上下文层级结构。
So we sort of set aside the idea that there is one big, broad, flat set of context that we’re all going to swim in. And it’s much more like a context hierarchy.
—— Charles · [41:01]

而在这里，本质上，到这个时候，对我们很多产品来说，智能体已经是主要用户了。
And here essentially, at this point for a lot of our products, agents are already the majority user.
—— Charles · [50:36]

而且拥有那份信心去知道，无论你的文档说你的产品是什么，你都可以确信它实际上就是那个样子，因为本质上每隔几个小时我们就有智能体重新验证这一点。
And it’s really powerful to have the confidence to know that whatever your documentation says your product is, you can be sure that it actually is that because essentially every few hours we have agents revalidating that.
—— Charles · [51:00]