背景

岗位

局部

全局

行动

From Receiver to Builder

AI时代
产品经理的工作模式

如何从需求接收者变成前线构建者

Framework

点 · 岗位角度

线 · 局部角度

面 · 全局角度

问题 → 思考 → 方案 → 沉淀 → 泛化

杨明哲产品经理 — 培训服务产品线

2026.05← → 翻页 · Space 下一步

背景

岗位

局部

全局

行动

Before we start

这次分享的初衷

入职两个月的观察与实践

在实际项目中遇到的问题和做出的尝试

抛砖引玉，交流学习

希望得到各位指点，一起优化工作方式

Today's Route

1

背景和思路

从一个项目说起

2

岗位角度

我的工作模式变化

3

局部 → 全局

对团队和公司的意义

杨明哲产品经理 — 培训服务产品线

2026.05Space 下一步

背景

岗位

局部

全局

行动

Story

从沈阳客运项目说起

项目严重延期

5月接手时，开发资源一直排不开，客户意见很大

9

经手工位

N+

需求变更次数

高

定制化程度

观察到的问题

需求反复确认 / 变更 / 新增

多项目并行，产品设计周期长

产品产出无法直接作为开发依据

开发资源排不开，项目不断延期

跨部门协作难度高，KPI 隔离

不断重复开发定制化需求

这些问题并非某个人的失误，而是链条过长 + 高定制化带来的系统性挑战。

杨明哲产品经理 — 培训服务产品线

2026.05Space 下一步

背景

岗位

局部

全局

行动

Business Chain

公司的业务链条与信息衰减

销售

招投标

客户沟通市场/项目经理

            
            产品设计
            PRD/原型/Demo

架构设计

开发定制化部署

测试

部署

验收逐字核对

信息完整度 ← 逐层衰减 →

100% ???

客户需求

产品设计

交付

根因 1

定制化程度高

无法快速开发部署

根因 2

业务链条过长

信息逐层衰减

杨明哲产品经理 — 培训服务产品线

2026.05Space 下一步

背景

岗位

局部

全局

行动

Framework

我的思考框架：点 · 线 · 面

点

岗位角度 — 我自己怎么变了

AI时代产品经理的工作模式转变 + 实际案例演示

线

局部角度 — FDE 模式的可行性

借鉴 Palantir 的 FDE 理念解决信息损失问题

面

全局角度 — 对公司意味着什么

从业务链条和公司战略出发的组织升级思考

杨明哲产品经理 — 培训服务产品线

2026.05Space 下一步

背景

岗位

局部

全局

行动

Point · 点

传统产品经理的工作模式

传统工作流

收集需求

会议/邮件/口头

写 PRD

Word/Confluence

画原型

Axure/Figma

评审

多轮会议

交付文档

给开发

反复修改

循环...

传统模式的痛点

产出不可执行

PRD 到开发仍需大量沟通

周期长

需求→可用 Demo 数周起步

信息损失

需求在文档传递中不断衰减

杨明哲产品经理 — 培训服务产品线

2026.05Space 下一步

背景

岗位

局部

全局

行动

Shift

AI 时代的新模式

Before · 传统模式

写 Word PRD → 画 Axure 原型

多轮评审会议对齐

开发拿到文档还得反复确认

周期：数周 ~ 数月

After · AI 驱动模式

AI Agent 直接生成可交互 Demo

PRD / 验收标准 / 代码同步产出

开发拿到的是可运行代码，不是纯文档

周期：数小时 ~ 数天

产品经理的核心产出，从"描述需求的文档"变成"可运行的解决方案"。

杨明哲产品经理 — 培训服务产品线

2026.05Space 下一步

背景

岗位

局部

全局

行动

My Workflow

我的工作链条

INPUT

飞书沟通记录

飞书 CLI

Codex / Claude Code

OUTPUT

文档沉淀

分项目知识库

可交互 Demo

前端代码直出

验收标准

对应投标文件

开发用 PRD

可直接使用

LOOP

跟进项目群开发进度

及时更新产品设计和输出

核心目标：产出的内容能否可以直接用？研发拿到后能否直接开发？不只是"生成文档"，而是"生成可执行的解决方案"。

杨明哲产品经理 — 培训服务产品线

2026.05Space 下一步

背景

岗位

局部

全局

行动

Case Study

案例：沈阳南电子班牌方案

工作流程

飞书群沟通记录

客户需求讨论、会议纪要

飞书 CLI 提取结构化信息

自动抓取群消息和文档

Claude Code 生成方案底稿

PRD + 技术方案 + Demo

输出完整讨论底稿

直接用于客户对接和内部评审

1

天内完成底稿

4

份产出文档

可直接用

研发无需二次翻译

杨明哲产品经理 — 培训服务产品线

2026.05Space 下一步

背景

岗位

局部

全局

行动

Tool Deep-dive

关键工具：飞书 CLI

让 AI Agent 操作飞书的命令行接口

Codex / Claude Code 通过 CLI 直接读写飞书数据，实现办公自动化

核心能力

读取 / 创建 / 更新飞书文档

抓取群消息和会议纪要

日程和任务管理

被 Agent Coding 工具直接调用

为什么用 CLI，而不是飞书智能体？

CLI

智能体

项目隔离

分项目管理

全局共享

上下文

相对隔离

混合上下文

扩展性

接入外部工具链

飞书生态内

定位

生产力工具

协作自动化

互补关系：CLI 做"从 0 到 1 写出可用东西"，智能体做流程自动化和团队协作。

terminal

$ lark-cli docs +fetch --doc "沈阳南项目文档" --format markdown
# 自动提取飞书文档内容，输出结构化 Markdown

$ lark-cli chat +read --group "沈阳南项目群" --since 7d
# 读取项目群最近 7 天消息

杨明哲产品经理 — 培训服务产品线

2026.05Space 下一步