AI 时代，产品经理还可以这样交付一套企业培训系统

本文根据客户实践整理。项目背景为国内某新能源车企的内部培训系统落地过程，本文以参与该项目的产品经理视角叙述。

AI 编程在企业里的处境挺微妙。这是眼下少有的、企业肯真金白银买单的 AI 场景——省的是工程师工时，写完好不好使跑一遍测试就知道。开发者个人用得很痛快，装个 Coding Agent，接上模型，写代码的速度直接飞起。但企业想把它从个人行为变成组织能力，光有大模型和工具账号远远不够。

这篇文章讲一个具体的案例：从团队里的产品经理视角切入，看如何把一套企业培训系统从一句需求做到上线。再把“用平台实现”和“个人用 AI 工具实现”放在一起比，看看差距在哪。

一、产品经理拿到了一套开箱即用的流水线工具链

以前，作为产品经理，项目开始后的产出是需求文档和原型。这些东西交出去之后，还要经过人工确认与转换：业务方看着原型点头，觉得符合自己的诉求；开发翻着需求文档皱眉，因为总有些地方不够详细，要靠经验推断。

基于一套开箱即用的流水线平台之后，变化发生在两层。一层是工具，另一层是协作方式。

工具这层，平台给每个成员配一个智能助手，也就是一个现成的工作环境。环境里已经装好了项目的全部上下文：大模型配置、各个角色要用的 Skills、产品文档、架构设计、API、代码。IDE 不用装，Agent 不用装，API key 不用填，一个浏览器就够——这些工具与配置，平台都开箱即用的备好了。

平台用户的权限跟着角色走。若是产品经理，对应的 Agent 拿的就是产品经理的权限和 Skills。产品经理想改生产环境的配置也改不了，因为没有那个权限；也不用每次写一大段提示词告诉 AI“你是个资深产品经理”，这些早就沉淀在平台里了。这样至少有两个好处：

• 产品经理的 Agent 被限制住，改不到其他成员负责的内容；
• 提示词、Skills 等 AI 资产沉淀在企业平台里，可以复用。

一个人本地做，得自己把工具凑齐：哪个 IDE、哪个 Agent、接哪个模型、提示词怎么存。十个人有十套用法，人一走，整套流程也跟着带走，没法给别人复用。平台把这些做成了内置的，工具链从个人资产变成组织资产。

协作这层，差别更大。Axure 虽然能导出 HTML 原型让其他成员查看界面与交互，但这样的原型就像是信息孤岛。发给开发，开发看一眼就关掉，或者直接把原型丢给 Agent 让它来实现。但这些上下文没有一个统一的存放位置，只留在开发本地的 Agent 上下文里。中间如果有改动，还得开发跟产品经理开站会交流，没法快速同步给各相关方，也没法把全量上下文留存下来。

我把这样的流程叫“缝合”。协作流程本来是断开的，得靠不同的人一段段缝合起来。缝得细不细、顺不顺，得看这人是否理解到位，也看他那天有没有空。缝合过程但凡出现问题，就是一轮返工。

但是回到平台上，原型是流水线里的一环。产品经理的产出存放在 pm 库里，架构师打开自己的智能助手就读得到，开发读的也是同一份上下文，这样全量上下文有一个统一的存放位置。不用把信息从一个工具搬到另一个工具，也不用开那场“产品经理给开发讲一遍需求”的站会。

二、一套企业培训系统的交付，快在哪

现在来看这套流程跑起来是什么样，快在哪里。

需求是周一上午 HR 负责人发来的一段话：

“我们要一套内部培训系统。要能线上学习，能在线考试，线下培训也得管起来——报名、签到、场地、讲师都要在系统里。年底要跟绩效打通。安全合规那部分每年内容都要换，得让我们自己能在后台改。”

从这段话，可以把需求分成几个主要内容：线上学习、在线考试、带场地的线下培训和集成。线上学习得考虑学习形式，线下培训得考虑场地是否冲突、讲师日程排期等。从需求的不断细化里能感觉到，这个系统的复杂度每一条都在往上增加。

如果按旧有的方法来安排工作，接下来可能就是花一周写 PRD、两周画原型、三周评审，等系统能点开看的时候，需求已经变更过好几轮了。当然在使用了 AI 工具之后，产品经理可以把各项工作的时间大大缩短，但还是得在不同成员之间手工传递交付物。

在使用 AI 协作研发平台之后，工作流程则大不一样了。首先是项目经理先建好项目、配好角色，他给自己的智能助手发一句话，把目录结构、脚手架、代码库都初始化好了——一个主库带四个子库（pm / test / dev / ops），各角色各管一个。产品经理管 pm，架构师和开发管 dev，测试管 test，运维管 ops，所有人都能读全部内容，但只能修改自己负责的库。

然后是产品经理。打开浏览器，给自己的智能助手发指令，启动“产品经理工作流”，五步做完需求：产品设计、场景流程、业务对象、框架、出 HTML 原型，全程不到一天。然后把原型链接直接发给 HR 负责人去体验，从注册账号开始，报名、考试、拿证走了一遍，体验结束后提了多条反馈意见。这些反馈意见当天下午就进入了设计流程。同时测试人员这会儿也已经在做测试设计了，因为产品和测试在需求阶段是可以并列进行的。

后面的工作，由每个角色各对自己的智能助手发指令来继续推进：

1. 架构师做架构设计和审查，产出落在 dev 库；
2. 开发读同一份上下文直接编码，不用再“重新理解一遍需求”；
3. 架构师也把企业的编码规范沉淀成 Skills，对着智能助手发一句话，就完成了对开发提交代码的审查；
4. 随后开发发指令触发部署，部署成功后平台直接提供一个可以访问的域名；
5. 然后产品经理把域名发给业务系统的实际用户；
6. 用户拿真实数据体验跑了一遍后，又提出反馈意见；
7. 产品经理在平台上继续把反馈消化成设计和修改，进入从设计到交付的循环。

上线之后，运维人员通过自己的智能助手做故障诊断，看到的是从需求设计到开发测试以及可观测数据的全量上下文，能把故障定位到具体某一行代码。而一个只在本地装的 Agent 工具，出故障时 Agent 只能看到粘进对话框的那几段报错日志。

三、组织 AI 开发与个人 Coding 实现的区别

前面是产品经理一个人的经历。从企业的角度来分析，平台的价值点其实不止这些。

不少企业推 AI 编程推不动，其实不是工具有问题。个人本地通过 AI 实现提效，但这样的快只是快在员工单点上，而不是快在整条团队协作链上。

一个需求的交付周期可以分成七段：需求澄清、设计评审、开发、测试、部署、验收、运维。其中一段快三倍，另外六段照旧，总周期省不了多少。更麻烦的是可能会出现新的单点瓶颈，比如代码产出变快了，但堆积的代码评审排队却可能变长了。

“个人用得爽”和“组织效能真的提上去”，中间还隔着一些阻碍需要打通。

企业真正落地至少会有四道坎：安全、可管、合规、组织级效能。个人本地搞，一道都过不去：

• 代码和数据要出域，API key 散在每个人电脑上，没人审计；
• 规范、Skills、模型、工具没人统一管；
• 需求到编码合规没人校验；
• 多人多 Agent 协作更无从谈起。

平台把这四件事做成了配置项、留痕和检查动作，打通了这些阻碍。

最后来看看投入与产出。一家头部新能源车企实现这套培训系统，供应商报价 300 多万，企业的研发团队通过 AI CloudOS 平台自己实现，只要 70 多万就能落地，效能提升 5 倍。

企业 AI Coding 落地，但平台不是装完就结束了。它的交付方式是产品加 FDE 双引擎模式，类似 SAP 配咨询师，分三步陪跑：

1. 种子团队三个月跑通全链路；
2. 小范围团队推广三到六个月补齐协作；
3. 最后企业全面推广。

交付不是终点，让企业不断从平台上获得价值才是根本目标。

四、结语

再回顾一下这段经历。产品经理以前的做法，是把业务方的话翻成需求文档交出去——交给架构师、交给开发、交给测试，每交一次就重新理解一次，中间就可能丢失一些信息。整个研发流程本来是断开的，需要靠一个个团队成员缝合起来。

在 AI 协作研发平台上，产出不需要被手工交接或者在不同工具间迁移，项目成员就能在同一个项目空间下阅读这些全量信息与变更。这中间产品经理不需要写一行代码，也不用配置环境，干的还是产品经理那点事。

从需求到系统运行起来，中间的流程不再是靠每个人缝合起来，而是通过平台自动流转起来。

听露爷侃侃