如何从需求接收者变成前线构建者
入职两个月的观察与实践
在实际项目中遇到的问题和做出的尝试
抛砖引玉，交流学习
希望得到各位指点，一起优化工作方式
1
背景和思路
从一个项目说起
2
岗位角度
我的工作模式变化
3
局部 → 全局
对团队和公司的意义
项目严重延期
5月接手时，开发资源一直排不开，客户意见很大
观察到的问题
需求反复确认 / 变更 / 新增
多项目并行，设计周期长
产出无法直接作开发依据
开发排不开，不断延期
跨部门协作难，KPI 隔离
重复开发定制化需求
这些问题并非某个人的失误，而是链条过长 + 高定制化 带来的系统性挑战。
根因 1
定制化程度高
无法快速开发部署
根因 2
业务链条过长
信息逐层衰减
岗位角度 — 我自己怎么变了
AI时代产品经理的工作模式转变 + 实际案例演示
局部角度 — FDE 模式的可行性
借鉴 Palantir 的 FDE 理念解决信息损失问题
全局角度 — 对公司意味着什么
从业务链条和公司战略出发的组织升级思考
收集需求
会议/邮件/口头
写 PRD
Word/Confluence
画原型
Axure/Figma
评审
多轮会议
交付文档
给开发
反复修改
循环...
产出不可执行
PRD 到开发仍需大量沟通
周期长
需求→可用 Demo 数周起步
信息损失
需求在文档传递中不断衰减
产品经理的核心产出，从"描述需求的文档"变成"可运行的解决方案"。
文档沉淀
分项目知识库
可交互 Demo
前端代码直出
验收标准
对应投标文件
开发用 PRD
可直接使用
核心目标：产出的内容能否可以直接用？研发拿到后能否直接开发？不只是"生成文档"，而是"生成可执行的解决方案"。
朗星电子班牌 · 教室设备预约 · 显示逻辑 — 1 天内产出可评审底稿
右侧图库：群聊截图 · 界面原型 · 流程图 · 讨论底稿 · Demo 动图（悬浮放大浏览）
飞书群沟通记录
客户需求讨论、会议纪要
飞书 CLI 提取结构化信息
自动抓取群消息和文档
Claude Code 生成方案底稿
PRD + 技术方案 + Demo
输出完整讨论底稿
直接用于客户对接和内部评审
设备预约冲突方案
业务规则与重叠处理
电子班牌显示逻辑
状态 / 课表 / 预约联动
PRD + 技术说明
研发可直接对照开发
可交互 Demo
客户现场演示与确认
让 AI Agent 操作飞书的命令行接口
Codex / Claude Code 通过 CLI 直接读写飞书数据，实现办公自动化
互补关系：CLI 做"从 0 到 1 写出可用东西"，智能体做流程自动化和团队协作。
$ lark-cli docs +fetch --doc "沈阳南项目文档" --format markdown # 自动提取飞书文档内容，输出结构化 Markdown $ lark-cli chat +read --group "沈阳南项目群" --since 7d # 读取项目群最近 7 天消息
文档内可滚动；悬浮放大至顶底 · 翻页请点左侧空白或键盘
对外演示包中的 HTML 文档，可直接嵌入幻灯片现场操作
在约束清晰的前提下，产品经理可在原项目上推进简单改动
可以做
在既有项目上继续开发，帮助前端处理单元级改动、补交互、改文案与布局
前提
约束前端框架、组件库、数据库与接口协议，避免 AI 自由发挥
仍交给前端
性能优化、工程化发布、联调排障与线上质量，仍由前端工程师收口
「美丽的废物」
格式规范、样式优美，但无法进入评审、无法交给研发直接开发
能评审
需求细节与交互说得清
能规格化
可作为需求规格说明书
能开发
研发拿到即可动手
目标：不只是生成文档，而是生成可执行、可验收、可迭代的解决方案。
Telegram 网关 · 主用法：链接沉淀到 Obsidian（非替代飞书/IDE）
飞书做协作，Obsidian 做个人洞察 · 右侧：Telegram / 关系图谱
解决链条前半段「信息逐层损失」——把 Palantir 的前线部署理念，对照捷安高科的交付链路来理解。
线：不是换工具，而是让「听懂客户」的人更早坐在现场，并把洞察喂回平台。
括号内职责说明已省略，聚焦主链条流转（与 Part1 一致）
局部视角的问题：不是产品设计写得慢，而是到手里时已是「二手需求」——FDE 要把听和做前移到链条前半段。
不是卖功能清单，而是派最强的人嵌入客户现场，从工作流里「打捞」需求。
业务模式
第三条路：不只做平台，也不只做行业 SaaS，而是嵌入客户把流程数字化，再从个性化工作流中抽共性。
为什么值得参考
客户常说不清要什么；今天聊、今天有 demo 的决策回路，才能把真话问出来。
写生产代码 · 长期嵌入现场 · 对业务结果负责 · 反向喂养平台
Echo · 听
领域专家：识别哪些痛点值得解决，把「正确问题」提到最高优先级。
Delta · 做
工程师：把听到的痛点快速做成可用 demo，当天迭代。
在捷安，我现在的角色接近 Echo + 一部分 Delta——Part2 的案例，就是这条线在培训产品线的试运行。
不是个人工具秀，而是：交付结构、AI 提效方向、垂类平台投资——能否对齐。
面：把 Part2 的岗位实践、Part3 的 FDE 方法论，放回捷安高科的生意与组织里看。
而是「设备 + 仿真 + 课程 + 师资 + 考核」一体的教学解决方案。
业务现实
组织现实
结论：交付物比 Palantir 典型客户更复杂，却用更长的远程瀑布链路——结构与业务本质错配，这正是 FDE 模式在捷安「反而更贴切」的原因。
是给「AI 提效、垂类平台、任职资格」配一套可执行的协作方法论。
公司强调的方向
产品经理提出正确问题；研发做有价值的创新；研发/运营流程AI 化；垂类知识成为核心竞争力。
FDE 的对应动作
Echo 前移识别真问题；Delta + AI Coding 快速验证；现场数据反哺运营洞察；patterns 沉淀进产品与职教垂类大模型建设。
推 FDE，本质是给公司 AI 战略配「协作结构」——工具换不掉信息在十个杯子里的损耗，结构可以。
工具层 · 飞书智能伙伴 / 智能体
会议纪要、文档协作、流程自动化——在现有协作基础设施里提效。
典型场景
群消息汇总 · 纪要结构化 · 审批/分配规则化
流程层 · FDE 工作方式
人坐到需求源头，可运行 demo 替代二手文档，洞察反向喂回平台。
典型场景
售前技术交流 · 当天 demo 迭代 · patterns 进规划
我的工作流：飞书 CLI / 智能伙伴负责「捞信息」→ Codex / Claude Code 负责「出 demo」→ Obsidian 负责「沉淀 patterns」——三层串起来，信息不再断在转述里。
粘
业务流程长在平台上，换供应商成本高
厚
每次交付让平台/modules 变厚，边际成本下降
准
定价可对齐 ROI，而非功能清单比价
对公司：证明一种「前线构建 + 反向沉淀」在培训交付里跑得通；对个人：积累可量化的案例与客户洞察资产。
不申请新岗位，先把行为做出来——3 个月小试点，用结果说话。
「我做现在的工作 + 增量：售前可叫我、现场可出 demo、走访必产出三件套。」
可证伪：每个阶段有产出物，方便跟上级复盘。
第 1 个月 · 基础设施
Obsidian 四库（客户 / 需求 patterns / 方案 / 复盘）· 绑定 2–3 位销售 · demo 30 分钟工作流跑顺 · 1on1 对齐试点
第 2–3 个月 · 现场验证
跟 1–2 个真实项目出差 · 当天 demo 迭代 · 每次走访三件套：需求 patterns / 方案 patterns / 反共识 insights
第 4–6 个月 · 沉淀扩大
v1「客户需求语义图谱」· 频次 ≥3 的 patterns 推产品 roadmap · 1–2 个内部分享案例 · 评估是否在 AI 提效项目里铺开
常见顾虑：销售不愿带？从最棘手客户切入。demo 吊高期望？标「探索原型」。跟 KPI 无关？短期是投资，长期提升需求质量与 AI 项目落地。
推荐动作（零成本启动）
找 1 位销售同事，约定一句话：
「凡是客户问到 AI / 智能化 / 数字人 / 实训升级的，第一时间叫我。」
不用改流程、不用批项目——先接到第一个电话，用 Part2 的工具链在 48 小时内回一个可点的 demo 或结构化纪要。
备选动作
对当前在手项目（如沈阳南）补一份走访「三件套」模板，下次出差直接填。
三件套模板
客户改需求的成本越接近 0，反馈越有价值——下周的目标，是让第一次低成本验证发生。
入职两个月的观察与实践，不一定对，但愿意用真实项目继续验证。
从需求接收者 → 前线构建者
杨明哲 · 产品经理 — 培训服务产品线 · 捷安高科