01
数智档案演示系统
问题不是“有没有 AI 能力”，而是信息明明存在，却不能被结构化使用与检索。我的工作围绕需求拆解、数据处理路径、产品链路和可信机制展开。
Archive AI Demo
数智档案演示系统
从模糊问题，到产品链路。
围绕 AI 档案检索项目，把工作拆成五个连续动作：先确认真实检索困难，再拆数据处理路径，最后落到页面、流程、PRD 和 UAT 验证。
01
问题背景
我先把“档案检索不好用”落到真实场景：用户不是找不到档案文件，而是找不到文件里的具体内容。
工作输入项目讨论、档案数据类型、检索演示目标和用户查询路径。
分析动作区分标题/档号检索与内容检索，梳理音视频、扫描件、图片无法被直接命中的原因。
输出材料整理“文件级检索、非结构化档案、结果可信度”三类核心问题，作为后续方案边界。
问题清单数据类型梳理检索痛点归纳
02
问题拆解
我参与把一个模糊需求拆成系统可以处理的链路：识别内容、组织内容、建立索引、返回来源。
工作输入ASR、OCR、LLM 等能力清单，以及音视频、图片、扫描件、文档等数据来源。
分析动作按不同数据类型拆处理路径，明确每类数据需要保留的时间点、页码、区域或原文来源。
输出材料形成“输入数据 - AI处理 - 可检索文本 - 来源定位”的能力链路说明。
能力链路数据处理路径索引规则来源字段
03
方案设计
方案不是把模型放进页面，而是把 AI 能力嵌入检索流程，让用户能查、能看懂、能回到原文。
工作输入检索页、结果页、溯源页和人工复核页的功能诉求。
设计动作梳理“查询 - 解析 - 展示 - 溯源 - 复核”主流程，拆分页面入口、结果字段和异常提示。
输出材料辅助完成核心流程图、原型页面说明和 PRD 中 AI 能力输入输出描述。
主流程图页面结构原型说明PRD 辅助
04
关键判断
政务档案场景不能只追求“AI 回答得快”，更重要的是结果能解释、能回看、能人工修正。
判断依据AI 输出存在误识别和遗漏风险，不能直接作为业务最终结论。
设计动作把每条结果绑定来源档案、页码/时间点/区域，并为低置信内容保留人工复核入口。
输出材料补充结果溯源、置信提示、人工校正和异常状态的说明，减少方案评审歧义。
溯源机制低置信提示复核入口异常状态
05
我做了什么
我主要把会议讨论和需求想法整理成研发、测试、项目成员都能对齐的页面、流程和问题记录。
参与内容需求讨论、流程梳理、原型表达、PRD 辅助说明和 UAT 走查。
执行动作整理检索/解析/溯源/复核主链路，记录功能、流程、AI 输出相关问题并跟进复验。
产出沉淀形成流程图、原型说明、AI 输入输出边界、UAT 问题记录和验收沟通材料。
流程图原型说明PRD 支持UAT 记录
02
滁州市数字档案馆
这个项目的重点不是页面表现，而是流程能否标准化、权限能否讲清楚、问题能否闭环，以及系统能否按验收标准稳定交付。
滁州市数字档案馆交付系统
-
01
项目背景
多端系统与多子系统并行，需要在基线版本上适配滁州建设方案。
点击查看细节 -
02
需求拆解
对照建设方案、测评标准和现有版本，拆出可复用、缺失和待确认功能。
点击查看细节 -
03
原型设计
围绕基线未覆盖的业务场景，补充多个子系统的功能原型。
点击查看细节 -
04
宣贯走查
同步原型方案，配合客户演示，并在测试环境走查关键业务链路。
点击查看细节 -
05
交付支持
进入交付准备后，协助整理材料、录屏、权限确认和验收前演示。
点击查看细节
Reflection
反思与能力沉淀
在这个项目中，我最明显的变化，是从最开始关注“功能怎么画”，逐渐转向思考“这个功能为什么存在、服务谁、处在哪条业务链路里，以及最终如何被客户验收和使用”。
滁州市数字档案馆项目不是单一页面或单一模块的设计任务，而是一个涉及多系统、多角色、多流程、多交付节点的 ToG 项目。项目推进过程中，我逐渐意识到，产品经理在这类项目中的价值，不只是输出原型，而是把分散的建设要求、客户反馈、系统能力和研发实现转化为清晰、可确认、可推进的产品方案。
复杂需求拆解能力
项目前期面对建设方案、测评标准、基线版本和客户实际需求等多类信息。我从功能点罗列，逐渐转向按“业务流程、角色权限、数据流转、功能差异、待确认问题”的顺序拆解。
先理解业务场景，再拆解系统模块；先判断已有能力，再识别缺失功能。ToG / B 端产品理解
相比 C 端产品更强调体验转化，ToG 项目更重视业务合规、流程完整、权限清晰、材料规范和交付闭环。页面本身只是结果，组织流程和业务规则才是方案成立的基础。
不同网络环境、角色权限和档案全链路，都会直接影响产品设计。产品交付闭环意识
参与功能宣贯、客户汇报、系统走查、用户手册、功能录屏和发布材料整理后，我意识到产品工作不会在原型完成后结束。
需求确认、方案设计、研发理解、测试验证、客户演示和验收支持都需要保持信息一致。沟通与协作能力
很多需求不是一次沟通就能完全明确，而是需要通过问题清单、原型说明、会议确认和后续走查不断推进。
产品经理不是简单传递需求的人，而是把模糊问题结构化、把分散信息统一化、把不同角色目标对齐的人。项目反思
回看这个项目，我也意识到自己前期存在一些不足：一开始更容易从页面和功能点出发，对业务链路、权限边界和数据流转的理解还不够系统。随着项目推进，我逐渐学会在设计前先问清楚三个问题：这个功能对应哪个业务场景？由哪个角色操作？产生的数据会流向哪里？这段经历让我对产品经理岗位有了更具体的理解：产品经理的核心价值，不只是“把需求画出来”，而是把复杂业务拆清楚，把方案讲明白，把问题推进到可落地的结果。