综合实战：从需求、选型到成品

到这一节，真正开始“像做产品了”

前面三节，其实你已经分别学了三种能力：

• 做出第一个工具
• 把工具发出去
• 让工具接住真实数据

但到真正做成品这一步，很多人还是会卡住：

“我会一点点了，但真让我从零做一个成品，我还是不知道怎么下手。”

这就是第四节要解决的问题。

如果说前三节是能力拆开练，第四节就是第一次真正把它们合起来。

---

先学会把“痛点”说成“需求”

这是很多人最容易忽略、却最关键的一步。

想法不等于需求

比如你说：

“我想做一个科室 AI 平台。”

这只是想法，不是需求。

真正的需求更像：

“规培生值班时总要翻多个文档查常用剂量，能不能做一个手机上直接打开的速查工具页，把最常用的 20 个条目放进去？”

你会发现，后者已经非常不一样了。

它说清楚了：

• 谁来用：规培生
• 在什么场景用：值班时
• 现在痛点是什么：要翻多个文档
• 最小要解决什么：常用剂量速查

这才是可执行的需求。

一个够用的快速需求模板

你可以把每个项目先写成这五行：

谁来用：
要解决什么问题：
输入是什么：
输出是什么：
最小可用版本是什么：

只要你能写清楚这五行，后面无论是找 AI 帮你做网页、做数据工具，还是接智能体，都会顺很多。

如果你想再专业一点，可以额外补一行：

验收标准是什么：

比如：

• 输入 3 个关键字段就能跑通
• 结果页面 1 屏内能看完
• 规培生第一次打开也知道先点哪里

最小可用版本，不是“简陋”，而是“收得住”

很多人一上来就想做大系统，结果做不动。

这一节最重要的产品判断之一就是：

不是功能越多越好，而是先把最关键的那一步先解决。

比如：

• 不是先做“全科室 AI 门户”
• 而是先做“值班常用评分工具页”

这就叫范围收敛。

---

方案怎么选：不是所有问题都该写成网页

这一步会真正把 L3 和 L4 接起来。

三种常见路线

什么时候更适合智能体

比如：

• 问答类助手
• 指南解读
• 教学答疑
• 文本生成和资料调用

什么时候更适合 Vibe Coding 做工具

比如：

• 评分工具
• 计算器
• 结构化表单
• 月报生成器
• 一个固定流程的小页面

什么时候更适合结合

比如：

• 前台是网页
• 后面调用 AI 做分析或生成

这一步真正要学会的一句话是：

不是所有问题都该写成网页，也不是所有问题都只靠智能体就够。

---

一次完整跑通：从需求到成品

这一节的重点，不是再看一个漂亮案例，而是你要第一次完整走通：

发现问题
  ↓
写清需求
  ↓
判断路线
  ↓
做出最小版本
  ↓
测试
  ↓
迭代

可以选的典型项目

• 术前评估清单生成器
• 不良事件上报辅助工具
• 科研项目进度管理面板
• 科室内部患者宣教页

你也可以把其中一个项目先压缩成“项目卡片”：

项目：术前评估清单生成器
用户：住院总 / 麻醉前访视医生
输入：年龄、基础病、实验室检查关键值
输出：风险提示 + 待补检查项
最小版本：先只覆盖 1 个科室、10 个高频字段
验收标准：3 个真实案例能顺利跑完，且提示项不明显漏关键风险

这一节测试什么

很多人以为测试就是“能打开就行”。

其实测试至少包括：

• 输入合不合理
• 输出稳不稳定
• 边界情况会不会出错
• 用户第一次用能不能看懂

如果只看“能不能打开”，那你测到的只是一个 demo。

如果你开始关心“别人会不会用错、会不会看不懂、会不会卡住”，你就已经在做产品测试了。

---

做完以后要复盘什么

第四节非常重要的一步，是复盘。

你至少要问自己这几个问题：

1. AI 最帮到我的地方是什么？
2. 哪些地方还是必须靠人判断？
3. 这个产品最核心的价值点到底是什么？
4. 如果下次重做，我会不会收得更小一点？

这一步为什么重要

因为真正成熟的项目，不是做完那一刻，而是：

你第二次还能改，别人也能接手的时候。

这就是为什么第四节虽然叫“综合实战”，但真正训练的是：

• 需求判断
• 范围控制
• 路线选择
• 测试迭代

这些才是产品化能力真正的骨架。