从三类咨询，
到分流与配置
医院 Agent｜个人原型：归纳问题，设计静态检索、动态查询与风险处理路径，配置知识库和规则。
查看需求与方案证据 ↗需求 · 流程 · 验证 · 文档
从业务问题出发，
让方案有据可验。
梳理流程、配置原型，用测试和文档推进方案验证。
从三类咨询，
3/10 → 9/10
医院原型：同一组 10 条模拟问题，1.0 → 2.0 完整复测通过数。四类 API 场景、n8n 11 条批量闭环分别记录，不合并计算通过率。
查看测试与排错证据 ↗12+ 科室导览
真实实习实践：完成 VR 设计与上线，访问记录 700+；制作 SOP 获团队采用，明确步骤和交付规范。
查看工作实践与 SOP ↗医院 Agent / n8n：个人方案与验证实践；VR / 实习 SOP：真实工作中的执行与标准化实践。模拟测试结果不代表医院线上效果。
简历与联系方式 ↓01 / 核心案例 · 实习场景自主原型
医院咨询业务流程优化
与 AI 应用原型项目
从医院新媒体后台的重复咨询出发，探索哪些问题可以标准化承接，哪些必须查询可靠数据，哪些需要停止回答并转向官方渠道。
目标与当前范围
以公开医院信息构建咨询原型，验证信息检索、需求澄清、风险规则与模拟排班查询。未接入医院生产系统，也未验证真实患者运营效果。
我的贡献与 AI 协助
负责问题归纳、方案设计、知识组织、规则配置与测试迭代；模拟 API 等代码实现借助 AI 完成。能够说明数据流和边界，不以代码存在证明独立编程能力。
02 / 业务问题与需求分析
先确定问题，
再确定系统该做什么。
后台咨询存在重复问题与响应断点。以下分类来自私信观察与进一步梳理，非逐条统计，也不是经医院签字确认的需求文件。
| 问题类型 | 需求拆解 | 处理约束 |
|---|---|---|
| 医院基本信息 | 地点、就诊流程等公开信息 | 依据可追溯知识，不补造缺失内容 |
| 科室信息 | 口语表达映射，必要时澄清需求 | 辅助识别咨询方向，不替代医疗诊断 |
| 医生信息 | 静态介绍与指定日期排班分开 | 排班经工具查询；无记录与调用失败分别处理 |
输入 → 输出
患者自然语言问题；排班查询进一步提取 doctor、date。输出为可靠信息、澄清问题，或明确无法确认并提示官方咨询渠道。
优先约束
信息时效性、知识缺失、工具失败和医疗风险优先于回答完整性。低风险标准化咨询才适合由 AI 辅助承接。
03 / 流程梳理
把响应断点，
转成明确的处理分支。
观察到的原有问题
患者私信 → 等待人工处理 → 部分咨询未及时响应
未测量响应耗时、积压数量或人工成本。咨询输入 → 分类与风险判断
常见低风险信息
检索结构化知识库
→ 有来源再回答
动态排班
提取医生与日期
→ 模拟 API 查询
高风险／信息不明
澄清或停止普通回答
→ 官方渠道提示
无可靠答案／工具失败 → 不编造 → 官方渠道或人工咨询
上述为原型设计与模拟验证路径。官方渠道提示已测试；尚未连接真人客服，也未实现真实预约闭环。
04 / 方案与系统配置
配置的重点，
是依据和边界。
信息标准化
医院、科室、医生三类知识表，将公开资料组织为可检索信息；配合口语映射与需求澄清，避免直接猜测用户意图。
行为规则
设置高风险优先级、禁止编造、动态信息查询与知识缺失兜底。工具和提示词服务于处理路径。
Agent → getSchedule → 模拟 FastAPI → found / message / data
GET /schedule · 输入 doctor、date。JSON 模拟排班数据不代表医院实时排班；临时公网入口不具备生产可用性保证。
05 / 测试与缺陷处理
用用例验证行为，
用失败定位问题。
3/10 → 9/10
同一组 10 条自建模拟问题
1.0 与 2.0 完整版本对照
高风险、知识缺失、澄清等失败案例推动规则调整。后续 Prompt A/B 未观察到明确增益；调整模型配置后做了异常案例定向复测，未重新完整运行全部 10 条，因此保留 9/10。
| API 场景 | 已验证行为 |
|---|---|
| found=true / available=true | 查到排班，返回可用状态 |
| found=true / available=false | 查到记录，区分不可用状态 |
| found=false | 未查到记录，不自行编造 |
| 公网入口失效 / no such host | 工具失败，明确无法确认并转官方渠道 |
调用成功证据查询有返回，
查询有返回，
结论有依据。
Agent → getSchedule → API → found=true
与同题 10 条测试分开记录，不合并计算通过率。
接口失效，也不能补造答案。
外部入口不可访问 → Agent 不编造 → 官方渠道／人工咨询。这里的“人工”是渠道提示，不是已接通的客服系统。
06 / 项目成果与实施边界
从方案配置，
到可追溯的验证成果。
已完成三类知识库、需求澄清与风险规则配置，并留存知识库与规则截图。
已完成同题版本测试、四类模拟 API 验证及故障兜底；保留成功、失败与回答证据。
本版将已有实践整理为需求分类、处理流程和配置说明，便于理解与复核；不是医院正式验收文件。
实施边界：真实医院系统与客服接入、生产权限与监控、企业用户验收（UAT）、培训和正式验收尚未完成。旧项目文档全文未补核，不作为当前成果证据。
07 / 补充实践
用不同场景，
补充流程与交付证据。
批量 JD 分析：把结果写回正确的位置。
表格读取 → AI 分析 → 结构校验／格式修复 → 原行回写
已有项目记录记载 11 条批量闭环验证。保留原始行号，通过 source_row_number 对应目标行；单条失败不进入成功写入，也不误标为已分析。
证明数据流组织、字段映射与异常排查实践。未证明更大批量、长期稳定运行或独立掌握全部实现；本版没有重新运行工作流。
从试点到导览，沉淀可复用的检查项。
12+ 科室导览设计与上线，访问记录 700+。数字沿用已有资料，不推导患者满意度或效率收益。
流程总结的重点
目标与资源对齐 → 点位与素材规范 → 命名和热点跳转 → 小范围验证 → 后续制作与交付。
已有 SOP 是检查清单，不表示书面确认、培训、备份机制或复盘会等条目全部执行。
查看 VR SOP 的关键检查项
- 明确最小可验证范围、验收人与决策路径。
- 规划点位与路线，处理隐私与拍摄配合要求。
- 统一素材结构、命名、热点文案与返回路径。
- 先验证试点，再沉淀制作流程并分阶段同步。
摘自《VR全景导航项目落地SOP（1.0版）》，作为已有流程总结呈现。
让制作步骤、参数与交付结构更明确。
针对步骤不统一、交接遗漏及返工问题，梳理字幕、音频、画面对齐、预告制作与文件交付规范。已有简历记载 SOP 获团队采用，未提供可核实的耗时改善数据。
当前可迁移的能力
把问题说清楚，
把过程留下来，
把结果验证好。
希望在初级实施、数字化项目或业务分析岗位中，参与真实需求、项目协同与交付验证，逐步补齐企业系统和正式上线经验。
简历与联系方式
具体资料将在本人确认后补充。
简历文件 · 待补充联系方式 · 待补充