科大讯飞 · 智慧城市事业部 · 产品经理实习

AI档案检索与数字档案馆交付复盘

围绕两个真实项目展开：一个是 AI 产品 0→1 演示系统，一个是 ToG 数字档案馆交付。重点不是罗列能力，而是讲清楚问题如何被拆解、方案如何进入流程、交付如何闭环。

看 AI 项目 看 ToG 交付
数智档案演示系统项目检索 🛡
查询：会议纪要中关于“土地审批”的原始记录
ASR音视频转写命中 02:14可溯源
⌕内容理解与语义检索待复核
⌕人工校正与结构化已校正
项目一AI 档案检索 0→1

从文件级搜索延伸到内容级检索，聚焦非结构化档案识别、索引、定位和来源可追溯。

项目二ToG 数字档案馆交付

面向政府数字档案馆项目，关注多角色协同、权限边界、流程规范和验收材料落地。

参与内容场景判断 / 数据链路
工作流设计 / PRD 支持

从真实业务场景出发，把 AI 能力、数据处理路径和产品流程转成可评审方案。

交付结果可信兜底 / UAT 走查
缺陷闭环 / 验收材料

围绕低置信度、来源追溯、异常字段和交付验收，推动问题记录、复核与闭环。

01

数智档案演示系统

问题不是“有没有 AI 能力”，而是信息明明存在，却不能被结构化使用与检索。我的工作围绕需求拆解、数据处理路径、产品链路和可信机制展开。

Archive AI Demo
数智档案演示系统
动画播放后自动进入下一段，也可点击跳转

从模糊问题，到产品链路。

围绕 AI 档案检索项目，把工作拆成五个连续动作：先确认真实检索困难，再拆数据处理路径，最后落到页面、流程、PRD 和 UAT 验证。

01

需求判断

这不是简单的搜索框需求。实际要解决的是非结构化档案的内容定位：文件里的具体内容、时间点、图片区域和来源依据都要能查到。

工作输入项目讨论、档案数据样本、检索演示目标、用户查询路径和已有检索方式。
分析动作对照标题、档号检索与内容级检索，梳理扫描件、图片、音视频和会议纪要无法直接命中的原因。
输出材料归纳文件级搜索不足、非结构化内容难定位、结果缺少来源三类问题，明确 AI 的适用范围。
文件级搜索不足内容难定位结果可追溯AI 介入边界
02

问题拆解

把模糊的检索需求拆成一条可处理的链路：识别内容、整理信息、建立索引，再把结果关联回原始档案。

工作输入ASR、OCR、LLM 能力清单，以及音视频、图片、扫描件和文档样本。
分析动作按数据类型分别梳理处理方式，标记需要保留的时间点、页码、区域和原文来源。
输出材料整理输入数据、AI 处理、可检索文本和来源定位的链路说明。
ASROCRIndex来源字段数据链路
03

方案设计

重点不是把模型放进页面，而是让 AI 进入实际检索流程。查询结果需要看得懂，也要能回到原文。

工作输入检索页、结果页、溯源入口、低置信提示和复核状态等功能需求。
设计动作梳理查询、解析、召回、展示、溯源和复核流程，拆出页面入口、结果字段与异常提示。
输出材料补充核心流程图、原型页面说明，以及 PRD 中 AI 能力的输入输出描述。
查询入口结果字段来源绑定复核入口PRD 辅助
04

可信兜底机制

在政务档案场景里，速度不是唯一标准。结果还要能解释、能回看，也要允许人工修正。

判断依据AI 输出可能误识别、遗漏或生成错误内容，不能直接当作业务结论。
设计动作每条结果绑定来源档案、页码、时间点或图片区域，低置信内容进入人工复核。
输出材料补充结果溯源、低置信提示、人工校正和异常状态说明，方便评审与测试。
低置信提示来源校验人工复核异常状态回写记录
05

输出与验证闭环

会议里的需求想法最终要落到页面、流程和问题记录中，研发、测试和项目成员才能按同一套逻辑推进。

工作内容需求讨论、流程梳理、原型表达、PRD 辅助说明和 UAT 走查。
执行动作梳理检索、解析、溯源和复核流程，记录功能、流程及 AI 输出问题，并跟进复验。
输出材料流程图、原型说明、PRD 辅助内容、UAT 问题记录和验收沟通材料。
流程图原型说明PRD 支持UAT 记录验收材料
02

滁州市数字档案馆

这个项目的重点不是页面表现，而是流程能否标准化、权限能否讲清楚、问题能否闭环，以及系统能否按验收标准稳定交付。

滁州市数字档案馆交付系统
Reflection

反思与能力沉淀

在这个项目中，我最明显的变化，是从最开始关注“功能怎么画”，逐渐转向思考“这个功能为什么存在、服务谁、处在哪条业务链路里，以及最终如何被客户验收和使用”。

滁州市数字档案馆项目不是单一页面或单一模块的设计任务，而是一个涉及多系统、多角色、多流程、多交付节点的 ToG 项目。项目推进过程中，我逐渐意识到，产品经理在这类项目中的价值，不只是输出原型，而是把分散的建设要求、客户反馈、系统能力和研发实现转化为清晰、可确认、可推进的产品方案。

01

复杂需求拆解能力

项目前期面对建设方案、测评标准、基线版本和客户实际需求等多类信息。我从功能点罗列，逐渐转向按“业务流程、角色权限、数据流转、功能差异、待确认问题”的顺序拆解。

先理解业务场景，再拆解系统模块；先判断已有能力，再识别缺失功能。
02

ToG / B 端产品理解

相比 C 端产品更强调体验转化，ToG 项目更重视业务合规、流程完整、权限清晰、材料规范和交付闭环。页面本身只是结果，组织流程和业务规则才是方案成立的基础。

不同网络环境、角色权限和档案全链路，都会直接影响产品设计。
03

产品交付闭环意识

参与功能宣贯、客户汇报、系统走查、用户手册、功能录屏和发布材料整理后，我意识到产品工作不会在原型完成后结束。

需求确认、方案设计、研发理解、测试验证、客户演示和验收支持都需要保持信息一致。
04

沟通与协作能力

很多需求不是一次沟通就能完全明确，而是需要通过问题清单、原型说明、会议确认和后续走查不断推进。

产品经理不是简单传递需求的人，而是把模糊问题结构化、把分散信息统一化、把不同角色目标对齐的人。

项目反思

回看这个项目，我也意识到自己前期存在一些不足：一开始更容易从页面和功能点出发，对业务链路、权限边界和数据流转的理解还不够系统。随着项目推进，我逐渐学会在设计前先问清楚三个问题：这个功能对应哪个业务场景？由哪个角色操作？产生的数据会流向哪里？这段经历让我对产品经理岗位有了更具体的理解：产品经理的核心价值，不只是“把需求画出来”，而是把复杂业务拆清楚，把方案讲明白，把问题推进到可落地的结果。