把用户任务、模型、数据、权限和既有系统约束，压缩成企业用户能进入、能配置、能交付的产品路径。
这是我在公司里承担产品职责的一段经历：负责两条产品线，把模型、数据、权限与既有系统约束翻译成能交付的产品路径。
为什么做这个
2024 年 9 月至 2025 年 3 月，我在某创业企业 AI 平台担任前端开发，同时承担产品职责，负责文档专家、设备专家两条产品线，业务场景是能碳大模型 RAG。文档专家、设备专家和企业 RAG 同时受首次使用成本、既有系统嵌入、数据格式、知识库、模型路由与应用权限约束；只做一个聊天入口无法覆盖真实交付。公开界面为保护业务隐私而重绘，不代表公司线上原始截图。
要解决的痛点
- 首次使用成本太高，企业用户进不来
- 客户要求保留既有系统入口，独立后台的假设不成立
- 数据集导入、知识库、模型路由、应用权限之间有依赖，平铺配置无法治理
- 模型、接口、运行条件分别由不同角色负责，需要按周协调
- 检索超时这类问题会直接让产品不可用
用户体验流程
关键决策
两条产品线分别定义给谁用、解决什么问题，各自出需求与方案
做一个通用助手覆盖两类用户
文档场景和设备场景的使用者、前置条件和权限边界都不同
文档专家把首次使用信息收敛为 4 项，降低进入成本
沿用完整独立后台的完整配置流程
完整后台会增加客户切换与接入成本，首次使用成本决定能不能进来
设备专家采用 iframe 嵌入客户既有系统，用 postMessage 处理跨域通信
要求客户切换到独立后台使用
客户要求保留既有系统入口；只做聊天入口又处理不了数据与权限
RAG 配置按 数据集 → 知识库 → 模型路由 → 应用权限 分层组织
把配置项平铺在一个设置页里
这几项之间有依赖关系，按依赖排序才能被理解和治理
公开版本只写职责、约束与取舍，数字一律写"—"
写业务指标、用户量，或写自己实现了检索算法与 RAG 架构
企业项目的公开规则：岗位和时间写准确，但不暴露内部数据、未公开功能与同事姓名
我的角色与能力
我负责
职位是前端开发，同时承担产品职责：负责「文档专家」「设备专家」两款 AI 对话助手与能碳 RAG 控制台的前端开发，包括需求分析、方案设计、前端实现与接口联调，并按周协调算法、后端与运维推进技术评审、自测、提测和发布。
能力体现
把模型、数据、权限与既有系统约束翻译成企业用户能进入、能配置、能交付的产品路径；在前端侧落地 SSE 流式输出、iframe + postMessage 嵌入通信、可观测可中断的 RAG 长任务，并沉淀覆盖 18 个页面的公共组件与自定义 Hooks。
AI 做了
业务场景是能碳大模型 RAG；我不主张自己实现了检索算法或 RAG 架构。
我做了
我负责两条产品线的需求定义、方案设计、接入取舍、配置结构与跨职能协调。
成果与下一步
已完成
- 文档专家首次使用信息收敛为 4 项；设备专家以 iframe + postMessage 嵌入既有系统
- RAG 按 数据集 → 知识库 → 模型路由 → 应用权限 分层配置，并完成用例评审、双周火车发布与上线审批
- AI 助手与动态交互：按智能体返回的卡片类型动态渲染策略配置、数据表格等交互组件；用 fetch-event-source 接入 SSE 流式输出，处理增量消息解析、结束标记、鉴权失效与异常中断，并用缓冲区控制和动态渲染节奏缓解消息积压；设备专家嵌入客户系统时，设计 iframe + postMessage 通信机制，实现设备定位与结果回传。
- RAG 控制台：基于 Umi、Ant Design Pro 实现数据集导入、格式映射、文档模板配置及文件上传、下载与预览；把数据集导入设计为可观测、可中断、可重试的长任务，支持失败统计、单文件重试与重复数据集校验；提出服务端签名直传与回调入库方案解耦文件上传与清洗切片，并实现租户 × 应用维度的知识库生效范围配置。
- 前端工程化：参与 API 迁移及组件化重构，沉淀覆盖 18 个页面的公共组件，封装字典字段、无限滚动等自定义 Hooks。