一、AI 模块：Prompt 迭代，驯服 LLM 的输出

工具调用稳定之后，这周的工作重心转移到了一个更难的问题：LLM 能稳定地调用工具、获取正确的图谱证据，但它把这些证据"翻译"成最终回复时，质量很差。

问题的起点是一个真实的测试案例。用户输入"我在吃阿司匹林，最近胃不太好，可以吃布洛芬吗？"——图谱返回了两条 HIGH 级冲突（阿司匹林-布洛芬 DDI + 布洛芬-胃溃疡禁忌），但 LLM 给出的回复是"建议您在服用布洛芬前咨询医生或药师的意见……希望您早日康康！"。对于两条高危冲突，这是完全不及格的输出。

问题根因分析指向三处：决策规则只说"必须输出 blocked"但没明确禁止"同时输出温和建议"；LLM 有根深蒂固的"建议咨询医生"免责习惯；action_type 字段约束了结构但没约束自然语言字段的措辞。

六轮迭代记录：

第一轮： 把"建议"改成"判断"，加禁止措辞列表。效果不稳定——LLM 可以用无穷多种变体表达"建议"，穷举防不住。结论：从负面禁止行不通，要从正面约束。

第二轮： 加入多冲突整合规范，要求 LLM 必须整合为一段连贯的风险描述，说明核心风险点和叠加效应。效果提升明显，但暴露了更隐蔽的问题——LLM 在整合时开始"发挥"，自发引入图谱之外的药理知识（比如"布洛芬可能降低阿司匹林的心脏保护作用"——药理上正确，但图谱里没有这条记录，属于越权输出）。

第三轮： 处理 CLARIFY 场景的追问质量。初版追问一次性列出五个问题，没有用户愿意回答。改为：每次只追问一个最关键的缺失信息（优先级：妊娠期/哺乳期 > 肝肾功能 > 当前用药 > 过敏史），且每个问题必须包含"为什么问这个"的简短说明。测试反馈：用户"知道系统为什么在问这个"，不再感到被审问。

做完三轮迭代后，总结出一个对称性观察——LLM 在医疗场景下有两种对称的失败模式：过度自信（越界发挥训练数据里的药理知识）和过度保守（有图谱证据也不敢给出清晰结论）。两者根因相同：LLM 没有清晰的"我被授权说什么"的边界感。最有效的 Prompt 写法不是"告诉 LLM 怎么回答"，而是"告诉 LLM 在这个系统里扮演什么角色、权限边界在哪里"。

---

二、ReAct 工作流与双重 JSON 保险的工程设计

为什么放弃 Multi-Agent 选 Single-Agent： 架构评审阶段曾考虑过"分诊 Agent + 药师 Agent"的多智能体方案，压测后发现两个模型互相轮询对话的延迟普遍超过 15 秒，在门诊场景下完全不可接受。Single-Agent + ReAct 的方案在延迟和复杂度之间取得了更好的平衡。

System Prompt 三段式结构： 本周明确了 Prompt 的 [Identity]-[Workflow]-[Constraints] 工程化结构。Identity 定义角色和目标；Workflow 明确 Thought→Action→Observation→Final Answer 的 ReAct 循环步骤；Constraints 是绝对红线——其中最核心的两条是"禁绝幻觉（必须 100% 依赖工具返回的 Observation，绝不依赖训练数据进行药理判断）"和"强制 JSON 输出（不含 Markdown 标记、无前置后置问候语）"。

双重 JSON 保险机制： 单靠 Prompt 约束 JSON 格式成功率约 92%，剩余 8% 的失败需要工程层兜底。本周确定了双重保险方案：一是在调用模型 API 时开启 response_format: {"type": "json_object"} 从底层约束输出；二是用 LangChain 的 PydanticOutputParser 建立拦截网，解析失败时捕获 ParseError 并把错误信息反馈给模型强制自纠错。两层保险叠加后，JSON 解析失败率接近零，极少数情况触发后端兜底逻辑返回 FALLBACK。

---

四、后端与模型微调：42 条测试 100% 通过，全链路闭环跑通

这是本周四条线里工程量最密集的一条。第四阶段的核心定位是：不新增设计，只验证第三阶段的设计能否正确运转。

联调策略： 不依赖 GPU 或模型权重，全部验证在 macOS CPU 环境完成，用占位 PatientContext 直接调引擎函数做单元级验证，确保逻辑正确性与训练环境解耦。

/api/review 联调（3个 case 全部通过）：

Case 1（高风险药物相互作用）：67 岁男性，心梗+高血压，当前服华法林+阿司匹林，候选布洛芬。规则引擎正确命中 ddi_warfarin_ibuprofen_bleeding（HIGH）和 ddi_aspirin_ibuprofen_antiplatelet（MEDIUM），取最高风险等级 high，触发 block_decision=true，替代建议正确指向对乙酰氨基酚。

Case 2（过敏信息缺失）：34 岁女性，肺炎，候选阿莫西林，过敏史未知。正确检测过敏信息缺失，育龄女性触发妊娠状态追问，risk_level=unknown、block_decision=true 是正确的保守策略。

Case 3（妊娠相关禁忌）：28 岁育龄女性，高血压，候选赖诺普利（ACEI 类，妊娠禁忌），妊娠状态未知。正确触发 pregnancy_status 追问；risk_level=unknown 而非 high——因为人群规则条件是 pregnancy_status == pregnant，当前状态是 unknown，规则未触发。当用户确认怀孕后，高风险规则将正确触发。这个边界行为是预期之内的，设计合理。

/api/clarify 联调（双路径均通过）：

追问模式（need_user_input）：3 个问题按高优先级排列（过敏 > 妊娠 > 当前用药），与 clarification_targets 完全对齐，最多 3 个问题的限制符合设计。

保守降级模式（conservative_fallback）：高风险 DDI + 无法补充信息时，正确切换状态，输出 3 个 actionable 操作步骤，免责声明明确法律边界。

/api/consult 总入口联调（完整链路通过）：

35 岁女性，高血压+偏头痛，青霉素过敏史，妊娠状态未知，候选赖诺普利+布洛芬。全链路串联结果：Review 检测到妊娠状态缺失 → Clarify 输出单一追问（pregnancy_status）→ Final 给出等待补充的最终建议。青霉素过敏已知但赖诺普利非青霉素类，过敏规则未误触发——这个负例验证同样通过。

Case Log 持久化验证： extract / review / clarify / final 四阶段事件链完整写入 JSON，4 个案例全部可回放，GET /api/case/{id} 接口正常返回完整历史。

SFT 数据集构建：

• Review 数据集：173 条（训练集 156 / 验证集 17），风险等级分布：unknown 46.8% / high 26.0% / none 18.5% / medium 8.7%，所有风险等级均已覆盖，block_decision=true 占比 81.5%
• Clarify 数据集：190 条（含保守降级 60 条），全部转换为 Chat SFT 格式（system / user / assistant 三段），每行一个完整 JSON 对象

联调总结：

测试总数：42
通过数量：42
失败数量：0
通过率：100.0%

当前进展： 第四阶段目标全部完成。从数据到规则引擎到 API 接口，第一条完整业务链路已经可以在无模型权重的条件下运转。下阶段重点是接入 GPU 环境，启动 Qwen2.5-7B 的 LoRA 微调实验。

---

五、前端：动态视图渲染完成，中期演示所需界面全部就位

本周前端完成了界面层最核心的工作：把后端返回的非结构化 JSON 数据，自动渲染为可交互的医疗表单界面，并与 AI 决策状态机完成联动。

核心设计原则： 医疗数据全部由 Agent 动态生成，字段数量和内容不固定，绝对不能写死。前端必须能适配任何合法的 JSON 结构，空值自动隐藏，字段动态增减。

患者信息动态渲染： 使用 v-for 遍历 patientProfile 对象的所有字段，配合 v-if 过滤空值，el-descriptions 组件保证医疗表格的语义清晰。完全不依赖固定字段，AI 多输出一个字段就自动多渲染一行，后端字段调整不需要改前端代码。

用药冲突风险列表： 冲突条目动态遍历渲染，高危冲突（danger）触发红色 error 类型警告，慎用提醒触发黄色 warning 类型，颜色语义与医疗安全规范一致。冲突数量由接口数据决定，界面自动适配。

AI 决策状态联动： 三条渲染路径通过 v-if / v-else-if 条件切换，完全由后端返回的 backendStatus 驱动：

• blocked → 显示红色高危阻断界面（el-result status="error"）
• needs_clarification → 显示追问弹窗，渲染 clarificationQuestion 文本
• fallback → 显示蓝色免责降级提示（el-alert type="info"）

这三条路径对应了系统的三种决策结果，前端渲染逻辑与林煒第二周定义的接口契约完全对齐。