Skip to content

executable-full-process-plan.md

Latest commit

 

History

History
219 lines (140 loc) · 6.46 KB

executable-full-process-plan.md

File metadata and controls

219 lines (140 loc) · 6.46 KB
Raw

CareMind 参赛版全流程执行方案（以 Beta 原型为基线）

目标：在 2026 年 9 月 5 日前，完成一套可解释、可展示、可答辩的 CareMind 参赛版作品。
当前日期基线：2026-06-08
当前项目状态判断：main 负责总体方案与知识底座，Beta 已形成独立 Streamlit 演示原型，但默认入口仍以模拟数据为主。

一、现在的出发点已经变了

旧版本执行方案默认“代码骨架尚未建立”。
截至 2026 年 6 月 8 日，这个前提已经不成立。

当前更准确的起点是：

  • main 仍然承载项目总愿景、知识来源、理论背景和执行路线
  • Beta 已经承载一个可展示的原型系统
  • 当前最大缺口不是“没有代码”，而是“原型事实、知识可信度和主项目叙事还没有彻底对齐”

因此，这份执行方案的重点也要同步改成：

  1. 统一文档口径
  2. 保住知识底座
  3. 明确 Beta 的真实边界
  4. 再决定如何扩展实时路径、测试和指标

二、最终交付长什么样

到 2026 年 9 月 5 日，CareMind 参赛版至少应包含：

  1. 一套对 main / Beta 关系说得清楚的主文档
  2. 一套可运行、可复现的 Beta 演示原型
  3. 一组可追溯的知识来源说明，尤其是用药安全部分
  4. 一套最基本的测试与评估口径
  5. 一套可答辩的 PPT、文案、截图与演示流程

建议统一对外表述：

CareMind 是一个面向失能老人照护的多智能体协同研究与原型项目；main 分支负责总体架构和知识底座，Beta 分支负责当前的 Streamlit 演示原型。

三、范围控制

为了保证 2026 年 9 月 5 日前能稳定交付，本阶段必须收住范围。

必做

  • 主文档与 Beta 事实对齐
  • Beta 的模拟模式边界写清楚
  • 用药安全来源重新挂接到原型叙事
  • 至少形成一条“评估 -> 编排 -> 审核”的稳定展示链
  • 补出最小测试与指标口径

可做但不作为主线

  • 把 live path 接入默认入口
  • 增加更多案例
  • 增加更复杂的家属沟通展示
  • 做更完整的可视化和日志页

明确不做

  • 把 Beta 包装成临床级实时决策系统
  • 在无知识审核链的情况下夸大用药安全能力
  • 同时重做主项目定位和重写全部底层代码

四、阶段化执行路线

阶段 1：主文档校正

时间：2026 年 6 月 8 日 - 2026 年 6 月 14 日

目标：

  • 把 Beta 明确定义为独立演示原型
  • 统一 main 的对外说法
  • 让新成员快速看懂当前真实状态

本阶段产物：

  • README.md
  • docs/system-design.md
  • docs/beta-prototype-status.md
  • docs/beta-to-main-capability-map.md
  • 更新后的 AGENTS.md / CLAUDE.md

阶段验收：

  • 文档不再出现“暂无代码骨架”的过时说法
  • 文档明确写出默认入口仍以模拟模式为主
  • 新成员只读 3 份入口文档就能判断系统真实状态

阶段 2：知识底座重新挂接

时间：2026 年 6 月 15 日 - 2026 年 6 月 28 日

目标：

  • 把 main 中最关键的高层资产重新锚定到 Beta 叙事里
  • 尤其是用药安全的来源、边界和审核表述

本阶段重点：

  • 重新明确 docs/medication-safety-knowledge-sources.md 的角色
  • 明确哪些高风险输出必须写“联系医生/药师复核”
  • 明确哪些文案属于越权表达
  • 在参赛材料中补出来源可追溯的说明页面或附录

阶段验收：

  • 对外材料能回答“你们的药物风险知识从哪里来”
  • 对外材料能回答“为什么这不是替代医生/药师的系统”

阶段 3：原型现实能力补强

时间：2026 年 6 月 29 日 - 2026 年 7 月 19 日

目标：

  • 在不破坏当前演示稳定性的前提下，补足 Beta 的真实能力说明

可选推进项：

  • 评估是否把 live path 接入默认入口
  • 如果暂不接入，也要把入口和代码路径的差异说明写清楚
  • 给关键输出增加来源、备注或风险提示展示位

阶段验收：

  • 无论是否接入 live path，都能清楚说明当前真实执行路径
  • 不再出现“代码里有”和“默认演示里有”被混为一谈的情况

阶段 4：测试与评估口径

时间：2026 年 7 月 20 日 - 2026 年 8 月 9 日

目标：

  • 给 Beta 增加最基本的可验证性

建议最低要求：

  • 至少 3 个演示案例可稳定复现
  • 至少 1 份高风险知识来源说明
  • 至少 1 组边界表达检查清单
  • 至少 1 套统一评估口径

建议评估维度：

  • 工程可运行性
  • 架构清晰度
  • 文档诚实度
  • 项目辨识度
  • 可信与安全边界

阶段 5：答辩与提交物整合

时间：2026 年 8 月 10 日 - 2026 年 9 月 5 日

目标：

  • 形成一套讲法统一、边界清楚的展示包

必须完成：

  • 最终 PPT
  • 最终演示路径
  • 最终截图与报告样例
  • 知识来源与边界说明
  • 提交包整理

五、当前最值得做的具体动作

如果从 2026 年 6 月 8 日当天继续推进，建议顺序如下：

  1. 完成主文档修订
  2. 明确 Beta 默认入口是模拟演示
  3. 为用药安全来源补一段与 Beta 的衔接说明
  4. 确定是否要推进 live path 接入默认入口
  5. 建立最小评估表，用于后续答辩和内部复盘

六、验收标准

这份方案执行到位，至少要满足以下判断：

  1. Beta 能被准确定义为“独立演示原型”
  2. 主文档能同时解释“项目愿景”和“当前原型现实”
  3. 关键领域文档没有因为原型出现而失效
  4. 新成员不会再把模拟模式误当成默认实时系统

七、当前最大风险

风险 表现 当前应对
文档继续写旧事实 仍写“暂无代码骨架” 立即修主文档
对外表述过头 把模拟演示写成实时推理 在入口文档中加硬边界
知识底座被弱化 只剩流程展示，没有来源说明 重新锚定背景、行业和药学来源文档
项目辨识度下降 变成泛化的养老协同展示器 在主文档里守住失能照护、用药安全、家属沟通主线

八、最终判断

CareMind 现在最需要的不是再造一份“从零开始”的执行计划，而是：

以已有 Beta 原型为现实基线，重建文档诚实度、知识可信度和项目主线一致性。

只要这件事做好，后续无论继续打磨 Beta，还是围绕它做竞赛展示，都会更稳。