PM 即 Builder · AI Agent 时代的 PM 进化

会议: 产品力领航者大会 PM × AI · 2026 春季 | 讲者: 莫亦寒（Zilliz 资深产品经理） | 时间: 2026-04-24 下午 · PM 角色转型分会场

一句话总结

AI 让 PM 第一次真正吃到 Spec-driven 的红利，PM 的核心交付物从「写一份 PRD」迁移为「持续维护可被 AI 消费的共享 Context」，护城河从「定义需求」变成「在更多候选里判断什么是最重要的事」。

速览

1. 数据边界困住 AI——模型越强、PM 工作里的割裂感反而越重，问题不在模型而在 SaaS Silo
2. PM 的四个新角色——Prototype Builder / Context Builder / Decision Maker / Spec Maintainer，对应进化实验的四条路径
3. PRD 升级为可交互原型——一次共识替代多轮对齐，把约束和风险前置浮现
4. Skill 是穿透 Silo 的共享层——PM 的判断、研发的追溯、设计的对齐、客服的归因，按需流动
5. 判断是 AI 时代最稀缺的稀缺品——能做的事越多，「判什么更重要」越值钱
6. PRD/SPEC 是 AI 生成代码、测试、文档、原型的唯一源头——结构化、边界清晰、可被验证
7. Skill 从内部沉淀到社区开源——Internal Skills、Zilliz Skills、zilliz-cli 三层让协作随时可得
8. Skill 生态扩大 10×、100× 后数据成为新瓶颈——Skill 管线互相隔离 + 在线 vs 离线两份数据，催生 Lakebase
9. Lakebase 在底座层闭合 CS/CD 循环——Compute moves, Data stays，一份数据两种读写姿势
10. PM 职能更新——PRD 从交付物变活资产，PM 从需求方变共享 Context 提供者

核心内容

开场问题：被「数据边界」困住的 AI

模型能力一路升级，但 PM 的工作割裂感反而越重——根本原因不在模型，而在 SaaS 数据边界。

Unix 的对照：五十年前 Unix 留给我们「Everything is a File」的统一抽象，AI 只要会读写文件就能理解整个系统。Claude Code 在编程场景超能打的前提，正是这套统一抽象——配置、代码、设备、进程、日志，全是文件。

PM 的现状：「Everything is a Silo」。每个 SaaS 平台都有自己的数据方言，中间没有统一抽象层——Slack、飞书、Zoom、Jira、Zendesk、Grafana、GitHub、Figma 都是孤岛。数据边界还在，AI 只能在系统内做小范围搜索、微局部优化，无法穿透系统壁垒×模态壁垒做端到端协作。

模型越强，PM 工作里的割裂感反而越重。

Zilliz 的 PM 进化实验：四个新角色

围绕「打穿数据边界」这件事，Zilliz 的 PM 实验出 4 个新角色定位：Prototype Builder / Context Builder / Decision Maker / Spec Maintainer。

角色 1：Prototype Builder——把需求变成原型，前置规划

Before：PRD + 口头讲解 + 线框想象——多轮会议翻译，风险后置暴露，靠工程师和设计师在脑内补全缺失的上下文。流程是 kick-off → review 1 → review 2 → review 3，多轮对齐才收敛。

After：PRD + 可交互原型——Review 里直接走完整流程，约束和风险提前浮现。工程师和设计师的问题在同一个原型上讨论。流程压缩为 kick-off → prototype → review 1 (ship-ready)，一次共识收敛。

四个增益：

• 沟通成本下降：多轮对齐收敛为一次共识
• 产品形态具象：从描述到可操作、可验证的原型
• 交付周期压缩：规划到开发的衔接更快
• 实现风险前置：技术约束在方案定型前浮现

角色 2：Context Builder——信息不再靠人搬运，穿透 Silo 按需流动

PM 不再做信息中转工，而是搭一层 Skill 共享穿透层，让信息从异构源（GitHub 代码仓库、飞书技术文档、Grafana 监控数据、群聊产品决策）直接流向职能现场（Product PM 判断、Engineering 研发追溯、Design 设计对齐、Support 客服归因），自演化、每次穿透都更进化。

场景 1：PM 看懂技术现实。一句「方案 A 和 B 的实现成本差异在哪里？」——Agent 穿透 GitHub / 飞书 / Grafana，把分散的信息和代码收敛成可用于产品判断的结论。

场景 2：研发追溯决策历史。工程师不用翻半年前的 PRD，一句「为什么这个参数是 1024？」就能从 PRD 和评审纪要追溯到当时的约束与取舍。

角色 3：Decision Maker——AI 放大候选，PM 收敛判断

「能做的事越多，判断什么更重要就越稀缺。」AI 让候选爆炸，PM 的护城河从「能做」迁移到「判什么」。三个维度的判断框架：

角色 4：Spec Maintainer——PRD/SPEC 成为交付骨架

Spec-driven development 不是新概念，但 AI 让 PM 真正吃到了这口红利。评审后工程师越来越多让 AI 读 PRD，而不是只靠人工转述。

PRD/SPEC 不再只是给人看——它是 AI 生成代码、测试、文档、原型的唯一源头。

新 PRD 的三个硬要求：

1. 结构化——模块、字段、状态用机器可读的层级表达
2. 边界清晰——输入输出、异常分支、非功能需求写死
3. 可被验证——每一条规则都能落成一条测试

示例 PRD（自定义角色 v1.4）：

• 目标：预置角色无感升级到自定义，权限表达力从 4 个预置扩到任意组合，迁移期间不停机
• 用户故事：作为 Org Admin，我第一次点「自定义角色」→ 看到预置角色已是默认模板 → 在其上加减权限存为新角色；存量成员及权限不变
• 核心流程：预置 = 默认模板 → 用户改写生成自定义，后端单一权限表驱动判断，失败自动回退到上一版本
• 验收标准：预置 4 个角色行为前后 diff = 0，权限生效延迟 < 5s
• 非功能：同构数据模型免迁移脚本，单一判断路径，审计日志记录每次授权变更

共同决策：共享 Context 带来视角融合

过去 · 接力：PRD 翻译 + 会议反复对齐——产品语言和技术语言来回翻译，信息在过程里流失，各自对各自的交付物负责。

当下 · 融合：围绕同一层共享 context 工作——PM、研发、AI 各自贡献观察和判断。

PM 看到架构约束，研发看到用户场景背后的取舍。融合之后，PM 的护城河是「判断得准」。

从 Skill 到 Zilliz Lakebase：底座层的演进

PM 角色更新只是表层，要把这条路走通还得动底座。

Skill 三层：从内部沉淀到社区开放

Skill 生态的下一个瓶颈：数据该落在哪里？

Skill 扩大到 10×、100× 后，新割裂浮现。Skill 无法持续优化、质量问题滞后数天、问题定位需跨系统人工比对。

割裂 1：Skill 管线互相隔离——每条 Skill 独立管线、独立存储、独立演进，知识散成新的孤岛，跨 Skill 协同无从谈起。四份数据、四份治理、四份预算，没有共享层。

割裂 2：在线 vs 离线——在线服务库负责高性能检索（毫秒级），离线分析库负责批处理（小时级）。两边写两份、读两份，中间靠夜间 ETL 和手动回灌缝合，延迟 6-24h。

Zilliz Lakebase：在底座层闭合 CS/CD 循环

The workflow is CS/CD. The infrastructure is Lakebase.

Lakebase 把 AI Serving 和 Continuous Discovery（Analytics & Evaluation）连成 The Continuous AI Data Loop——交互数据、上游数据、改进、反馈共用一个底座。

两个能力：

1. 数据全生命周期可观测——一份数据进入系统后，后续的处理、检索与使用、分析、改进，全链路可观测、可追溯、可优化
2. 底座层打通在线与离线的多模态数据——同一份数据，两种读写姿势，在线服务与离线发现共用底座，无 ETL、无反向回灌

三件事：需求驱动的架构更新（Compute moves. Data stays.）

闭环速度，就是 AI 产品的竞争力

闭环快是入场券，在更多候选里判断「做哪件事」——才是 AI 时代的护城河。

PM 职能的更新

Shift 1：PRD as a Live Asset——从「定义需求」到「持续编辑产品定义骨架」

过去 · DOCUMENT：PRD = 交付物。编写 → 评审 → 冻结 → 执行，增量补丁式演进。

当下 · LIVING SPEC：PRD = 活资产。编写 · 阅读 · 比对 · 跨版本回扫 · 持续维护。从「编写一次」走向「持续维护」。

一点思考：产品需求未来应该更像 IaC 一样被定义和管理。AI 显著降低需求跨版本比对、场景分析、代码实现的成本之后——PRD/SPEC 应更定义代码的骨架，下游代码、原型、测试、文档像骨肉一样随骨架一起生长和更新。PM 的产出权重也会从「需求产出」迁向「判断哪些该保留、哪些该 revert」——判断力，是这条路上唯一不会贬值的资产。

Shift 2：Context Provider——从「需求方」到「共享 Context 的提供者」

过去 · 两段接力：Product → Engineering，PM 单向把需求扔给研发，各自对各自的交付物负责，信息双向传递靠会议反复对齐。

当下 · 共享 context 层：PM · AI · Engineering 共享 Context 层，各方围绕同一层共享 context 同向推动方案——每方都是 context 的生产者与消费者。

PM 从「需求方」走向「共享 Context 的提供者 + 方案共同所有者」——新的核心产出不再是需求供给，而是在爆炸的候选里判断什么是「最重要的事」。

关键金句

「模型越强，PM 工作里的割裂感反而越重。」——莫亦寒

「能做的事越多，判断什么更重要就越稀缺。」——莫亦寒

「PRD/SPEC 不再只是给人看——它是 AI 生成代码、测试、文档、原型的唯一源头。」——莫亦寒

「闭环快是入场券，在更多候选里判断『做哪件事』——才是 AI 时代的护城河。」——莫亦寒

「判断力，是这条路上唯一不会贬值的资产。」——莫亦寒

可行建议

• 把 PRD 写成结构化、边界清晰、可被验证的 SPEC——让 AI 能直接消费，而不是只能给人读
• 评审从「PRD + 口头讲解」升级为「PRD + 可交互原型」，把约束和风险前置到方案定型前
• 把跨部门的诊断流程、运维经验、产品方案统一 Skill 化，建立内部的共享穿透层
• 用 Decision Maker 三维框架（架构可拓展 / 节奏可演进 / 用户连续性）做候选收敛
• 把 PRD 当 IaC（基础设施即代码）维护：编写、阅读、比对、跨版本回扫，而不是冻结后只增量补丁

关键数据/案例索引

数据点：

• Milvus GitHub：314+ contributors、43K+ stars、68M+ docker pulls、4.0K+ forks
• Forrester Wave Vector Database Providers, Q3 2024：Zilliz 处于 Leaders 象限
• 在线 vs 离线传统 ETL 延迟：6-24 小时
• Schema 加列从「拉锯以周计」压缩到「一个下午」

案例：

• 自定义角色 v1.4 PRD（结构化 SPEC 示范）
• Schema 加列流程：瀑布式跨团队接力 → Lakebase 一个下午完成
• Agent 一轮迭代：以周计 → 以天计收敛

工具/产品：

• Milvus（开源向量数据库）
• Zilliz Cloud（向量数据库托管服务）
• Zilliz Lakebase（统一在线 + 离线的数据底座）
• Internal Skills / Zilliz Skills / zilliz-cli（Skill 三层架构）
• Claude Code（PPT 用作 Unix 抽象红利的对照案例）

客户名单（Zilliz 服务的标杆）：Accenture、Airbnb、AT&T、Bosch、Chegg、Cisco、Cision、Compass、Deloitte、eBay、Farfetch、Grab、IKEA、Inflection、Intuit、Microsoft、New Relic、NVIDIA、OMERS、Otter.ai、PayPal、Palo Alto Networks、Poshmark、Roblox、Salesforce、Shell、Shutterstock、T-Mobile、Trend Micro、Walmart、ZipRecruiter、Zomato

讲者背景：Zilliz 资深 PM，主导 Zilliz Cloud 企业级产品能力体系规划，负责 BYOC 产品线 0-1 落地与 AI Agent 产品体系全链路设计；此前在腾讯云负责大数据平台产品规划，持续在 AI Agent 与 Skill 工具链方向一线实践。