ELEC5620 项目需求范例拆解：Intelligent Healthcare Service Application

Posted on 2026-08-14 Edited on 2026-08-17 In ELEC5620 Word count in article: 3k Reading time ≈ 11 mins.

ELEC5620 官方需求范例（智能医疗应用）的完整拆解。整理四条新增的硬性规定（≥3 个 AI 角色、每人至少 2 个核心 + 1 个可选特性、必须新颖、必须是协作式 agent 而非直接调用大模型），逐角色梳理核心与可选特性，并提炼出可套用到任意领域的需求文档模板。

ELEC5620 项目需求范例拆解

来源：Project_Requirement_Example.pdf（4 页）配套：项目指南（Project Description + Tutorial 1 + Lab 1）

⚠️ 先说结论：这份文档表面上是"一个医疗应用的例子"，实际上它引入了 Project Description 里没有的四条硬性规定，直接决定你的选题能不能过关。范例本身不是必做题目，但它示范的文档结构是要求你照着写的。

📌 另外确认一下：这次上传的 Project Description (1).pdf 与之前那份文本逐字相同（均 3601 字符），评分要求没有变化。

一、⭐ 四条新增的硬性规定（最重要）

这四条散落在文档开头和结尾的 "Please Note"，必须逐条对照检查：

#	规定	原文关键句
1	⭐ 必须有 1 个人类 founder/operator + 至少 3 个明确区分的 AI 角色，这些角色要承担 stakeholder 或业务职能，并在工作流中互相协作	at least three clearly differentiated AI roles that perform stakeholder or business functions and collaborate in the application workflow
2	⭐⭐ 每位组员必须各自独立实现「至少 2 个核心特性 + 1 个可选特性」，且提交物要清楚标明每个人的贡献	Every group member must individually implement at least two core features and one optional feature
3	⭐ 项目必须新颖，或对现有应用有实质性改进	Your project should be new and novel, or present a meaningful improvement to an existing application
4	⭐⭐ 特性要发挥 AI 模型的长处；要做的是「多个 LLM agent 协作」，而不是「直接调用一个大模型」	consider building collaborating LLM-based agents rather than merely using a large model directly

第 2 条对选题规模的直接影响（这是最容易被忽略的）：

组员数	核心特性下限	可选特性下限	合计
3 人	6	3	9
4 人	8	4	12
5 人	10	5	15

⚠️ 所以选题不能太窄——一个只有三四个功能的应用撑不起一个 5 人组。反过来，组队人数决定了你需要设计多少特性，这一点在 Lab 1 选题阶段就要想清楚。

另外：文档最后明确要求，你必须用这份范例作为模板，呈现出： primary users、AI roles、key capabilities、core features、optional features。

二、范例的问题定义（怎么写"背景"）

日常生活中很多人有轻微身体不适，但因为传统就诊流程繁琐而不愿就医。结果是小症状被拖着不治，久了演变成大问题。

解决方案：一个由 LLM agent 驱动、由一位人类 founder/operator 监督的智能医疗应用，为常见小病提供快速、准确、个性化的建议。

双重价值（注意它同时讲了对用户和对系统的价值）：

改善患者结局（patient outcomes）
减轻医疗资源压力（reduces the strain on healthcare resources）

💡 可直接套用的写法： 「某类人群有某个真实痛点 → 因为某个具体原因而没被解决 → 我们的方案 → 对用户的价值 + 对行业的价值」 这正好对应 Tutorial 1 里 StrideWise AI 的 Surface Request → Underlying Need → Business Goal 三层结构。

三、角色设计（范例的核心示范）

六个角色

角色	类型	职责
Patients	👤 用户	描述症状、获得初步健康建议；系统可自动推荐医生并预约
⭐ AI Care Coordinator	🤖 AI 角色 1	管理面向患者的对话、症状采集、预约协调、随访
⭐ AI Doctor Agent	🤖 AI 角色 2	生成和审阅详细健康报告，帮助患者和外部医疗人员理解病例
Human Doctor	👤 人类专业	审阅被升级的或低置信度的病例，做出不可委托给 AI 的临床决策
⭐ AI Technical Manager	🤖 AI 角色 3	管理病历、权限、系统监控、受控的 agent 更新
Human Founder/Operator	👤 创始人	监督 AI 角色、审阅异常、对公司运营负最终责任

⭐ 正好 3 个 AI 角色，满足硬性规定 1。

⭐ 值得抄的三个设计模式

① 用 confidence（置信度）驱动升级

这是整份范例的主线机制，贯穿多个角色：

每次诊断都附带一个置信度，让患者了解建议的可靠性
AI Care Coordinator 依据 confidence、complexity、clinical risk 三个维度决定路由：
- 常规病例 → 转给 AI Doctor Agent 自动审阅
- 低置信度 / 复杂 / 高风险病例 → 升级给 Human Doctor
AI Doctor Agent 会标记低置信度的报告交由外部医疗人员跟进
AI Technical Manager 会收集低置信度记录，据此准备模型更新建议

⭐ 这正是 Week 1 讲的 "Build guardrails" 和 "Map the work：区分 judgment / repeatable tasks / risky exceptions" 的具体落地。

② 明确划出"AI 不能碰"的红线

Human Doctor 做出的临床决策 "must not be delegated to AI agents"（不得委托给 AI agent）。

⭐ 这一句是人类问责（human accountability） 的书面化。你的项目里也必须有这样一条明确的红线——不管什么领域。

③ 模型更新要人类批准

AI Technical Manager 准备的是 "controlled model-update recommendations for approval by the founder/operator"（供创始人批准的、受控的模型更新建议）。

⭐ AI 提议，人类拍板。 这是"一人公司"里 founder 保留控制权的关键设计。

四、核心特性（按角色拆分）

面向 Patients（AI Care Coordinator 提供）

特性	要点
Automatic Diagnosis	与 agent 交互描述症状 → 初步诊断；可反复细化症状描述以获得更贴合的建议；⭐ 每次诊断附带置信度；形成持续的个性化问诊过程
Health Record	注册账号即启用；自动记录所有就医交互；每次问诊后持续更新；患者可查看、补充、分享给医疗人员
Medical Appointment	输入偏好与可用时间 → agent 匹配合适的医生；可同步到个人日历；支持修改和取消
Health Consultation	超出自动诊断范围的广泛健康咨询；有专科需求时直接接通平台上的医生

面向各 AI 角色

角色	特性	要点
AI Care Coordinator	Doctor Coordination	把常规病例转给 AI Doctor Agent；把低置信度 / 复杂 / 高风险病例升级给 Human Doctor，并把临床决策回传给患者
AI Doctor Agent	Diagnosis Report Review	按专科分类报告；评估置信度并向 founder 反馈以持续改进；标记低置信度患者交外部医疗人员跟进
AI Doctor Agent	Medical Records Access	访问分类后的报告和授权范围内的病历；⭐ 可报告数据不一致并请求人工复核
Human Doctor	Escalated Case Review	审阅升级病例；确认或修正 AI 的评估；给出诊断、治疗或转诊决定
AI Technical Manager	Daily Maintenance	用专门工具审阅系统日志、发布公告；⭐ 只处理非隐私信息，确保维护不侵犯用户隐私
AI Technical Manager	Permission Management	为不同用户群启用/停用特性；管理用户权限级别
AI Technical Manager	Model Updates	访问低置信度诊断记录；准备待批准的模型更新建议；为不同功能和用户群协调不同版本的 agent

五、可选特性（Optional Features）

归属	可选特性
Patients	AI 生成的形似患者的头像；视频问诊；支付信息管理（账单、支付方式、账户、支付历史、电子发票）；健康事件提醒
AI Doctor Agent	针对特定患者的笔记（支持随访与人工复核）；起草健康科普文章，发布前需批准
AI Technical Manager	访问运营日志及其字段；⭐ 促进 AI 角色之间沟通与交接（hand-off）的功能

💡 观察：可选特性大多是锦上添花或运营辅助，而核心特性都在主业务闭环上。你自己拆分核心/可选时可以照这个思路。另外注意 "起草文章需批准发布" 又是一次 human-in-the-loop。

六、⭐ 可复用的需求文档模板

把范例的结构抽象出来，换成你自己的领域直接填：

1. 应用名称与一句话定位
   Intelligent ___ Service Application

2. 问题定义
   ├─ 目标人群有什么真实痛点
   ├─ 为什么现在没被解决（具体障碍）
   ├─ 我们的方案（LLM agent + 1 位人类 founder 监督）
   └─ 双重价值：对用户 / 对行业

3. Primary Users and Roles          ← 必须 ≥ 3 个 AI 角色
   ├─ 👤 终端用户
   ├─ 🤖 AI 角色 1：面向用户的协调者
   ├─ 🤖 AI 角色 2：核心业务处理者
   ├─ 🤖 AI 角色 3：运维与治理者
   ├─ 👤 人类专业角色（处理升级、承担不可委托的决策）
   └─ 👤 Human Founder/Operator（监督、审异常、担责）

4. Key Capabilities and Core Features
   └─ 按角色分组，每条写清：做什么 + 怎么交互 + 输出什么

5. Optional Features
   └─ 同样按角色分组

6. 贯穿全篇的三个机制（强烈建议保留）
   ├─ ⭐ 置信度驱动的升级路由
   ├─ ⭐ 明确写出"AI 不得决定"的红线
   └─ ⭐ 关键变更需人类批准

换个领域怎么套（以 Project Description 的另外六个方向为例）

领域	AI 角色 1（对客）	AI 角色 2（业务）	AI 角色 3（运维）	人类红线
Finance	客户顾问 agent	风险分析 agent	合规监控 agent	⭐ 实际交易 / 转账必须人工批准
Retail / E-commerce	导购 agent	库存与定价 agent	运营监控 agent	退款与纠纷裁定
Education	学习陪伴 agent	出题与批改 agent	课程内容治理 agent	成绩认定
Smart Home	家庭助理 agent	设备编排 agent	安全与固件 agent	门锁 / 安防的最终控制
Smart Cities	市民服务 agent	调度优化 agent	数据治理 agent	应急响应决策
Smart Personal Assistant	对话 agent	任务执行 agent	隐私与权限 agent	代付、代发消息

⚠️ 金融方向要特别注意：涉及实际下单、转账的操作，红线必须画得非常清楚——这也是现实世界的合规要求。

七、检查清单

选题阶段（Lab 1）：

⭐ 至少 3 个明确区分的 AI 角色，且在工作流中真的互相协作（不是三个各干各的）
⭐ 有 1 位 human founder/operator 承担监督与问责
⭐ 有明确的人类角色处理升级案例，并写清哪些决策不得委托给 AI
⭐ 特性总数够分：组员数 × 2 个核心 + 组员数 × 1 个可选
⭐ 项目新颖或对现有应用有实质改进
⭐ 是多 agent 协作，不是"套一层 UI 直接调大模型"

文档阶段（Stage 1）：

按范例结构写全五块：primary users、AI roles、key capabilities、core features、optional features
核心 / 可选特性按角色分组呈现
⭐ 明确标注每位组员负责哪 2 个核心 + 1 个可选特性
设计里体现置信度驱动的升级机制
设计里体现关键变更需人类批准

八、和前两周内容的呼应

这份范例其实是把 Week 1 讲座和 Tutorial 1 的抽象原则落成了一份可交付文档：

Week 1 / Tutorial 1 的抽象说法	范例里的具体实现
Narrow promise：一个客户、一件痛苦的事、一个可测量结果	「有轻微不适但不愿走繁琐流程就医的人」+「减少不必要的线下问诊」
Map the work：分离 judgment / repeatable / risky exceptions	常规病例 → AI Doctor Agent；低置信度 / 复杂 / 高风险 → Human Doctor
Build guardrails：数据访问、质量检查、审批、降级	授权范围内访问病历；置信度评估；模型更新需批准；只处理非隐私信息
Create memory：存决策、样例、指标、教训	Health Record 自动记录所有交互；低置信度记录用于模型改进
Human Oversight（StrideWise 表格最后一行）	Human Doctor + Human Founder/Operator 两层人类监督
DESIGN TEST：创始人不介入每一步也能反复交付价值	AI 三角色跑完主流程，founder 只审异常

⭐ 一句话：范例证明了 StrideWise AI 那张「Agent 六要素 → 工程需求」映射表是真的能当骨架用的——把它填成医疗场景，就是这份文档。