第5章 分析需求并确定产品边界
从本章开始，学生将以“智能感知终端”为贯穿项目，完成从产品定义到v1.0发布的全过程。该项目利用传感器获取物理世界信息，在设备端识别指定状态或事件，并向用户提供反馈。具体传感器、安装形态和事件类别由真实调研与技术条件共同决定。
本章不先选择芯片或编写程序，而是回答三个直接决定工程范围的问题：
为谁解决什么问题？
→ 在什么场景下提供什么结果？
→ 第一个可验证版本只包含哪些能力？
AI可以协助检索、整理、比较和质疑，但不能代替真实用户、可靠资料和团队决策。所有进入项目仓库的结论都应能够追溯到调研证据、技术约束或明确标注的假设。
较早的项目常在开发前形成完整需求文档，再按计划逐项实现。这种方法适合需求稳定的任务，却难以及时发现用户问题本身是否成立。迭代式开发先用较小闭环检验关键假设，代价是需求和文档必须随证据持续修订。
完成本章后，应当能够：
- 从宽泛设想中提取具体的用户、场景、问题和结果；
- 区分事实、用户陈述、团队判断和待验证假设；
- 组织访谈、观察、公开资料和替代方案调研；
- 使用AI整理材料，同时核对来源并删除无依据结论；
- 用明确的纳入项和排除项控制产品范围；
- 编写项目
README.md和轻量产品需求文档； - 把产品需求拆成可跟踪的GitLab议题与里程碑；
- 通过合并请求评审产品定义，而不是直接在主分支反复改写。
5.1 建立智能感知终端仓库
5.1.1 用一个中性名称开始
课程项目名称采用：
智能感知终端
Intelligent Sensing Terminal
这个名称描述产品的技术类别，不预设手表、胸牌、固定节点或其他最终形态。形态应由使用场景、佩戴或安装要求、传感方式和成本约束决定。
在校内GitLab创建项目，并使用“初始化README.md”建立默认分支：
项目路径：<小组命名空间>/intelligent-sensing-terminal
可见性：Private
默认分支：main
开发阶段先使用私有仓库。未经许可，不得公开访谈材料、设备标识和内部服务地址。未审查的第三方内容也不得公开。本章暂不添加开源许可证，第12章完成审查后再决定公开范围。
5.1.2 克隆并建立最小目录
克隆新项目：
git clone <校内GitLab项目地址>
cd intelligent-sensing-terminal
git switch main
本章只建立与产品定义直接相关的目录：
intelligent-sensing-terminal/
├─ README.md
└─ docs/
└─ product/
├─ research-log.md
├─ product-brief.md
└─ prd.md
暂时不要复制完整固件、服务端或模型模板。仓库骨架应随已经确认的工程需要增长，而不是预先建立大量空目录。
在项目设置中保护main，后续修改继续采用第4章工作流。
5.2 从项目原点定义产品
5.2.1 README.md是项目入口
README.md应让第一次进入仓库的人在短时间内知道：
- 项目是什么；
- 它解决什么问题；
- 当前处于什么阶段；
- 已经能够运行什么；
- 目录中有哪些重要内容；
- 如何参与或提出问题。
新项目尚未形成可运行版本，因此第一稿README.md可以很短：
# 智能感知终端
## 项目目标
利用传感器识别指定状态或事件，并向用户提供及时、可理解的反馈。
## 当前阶段
产品问题与最小可行产品定义。
## 当前范围
- 目标用户：待调研确认；
- 目标场景：待调研确认；
- 目标事件：待调研确认；
- 反馈方式：待调研确认。
## 文档
- [调研记录](docs/product/research-log.md)
- [产品简述](docs/product/product-brief.md)
- [产品需求文档](docs/product/prd.md)
## 版本
尚未发布可运行版本。
“待调研确认”比编造完整产品描述更可靠。README.md会随版本演进，当前内容只反映当前仓库已经知道的事实。
5.2.2 用一句话限制问题
产品问题可以用下面的结构表达：
在<具体场景>中，
<具体用户>需要及时知道<可识别的状态或事件>，
以便完成<可以观察的行动或结果>。
例如，若调研聚焦实验室设备运行状态，可以形成：
在无人持续值守的教学实验环境中，
实验组织者需要及时知道指定设备是否出现异常振动事件，
以便检查设备并减少故障持续时间。
这只是表达结构的示例，不是本项目预先确定的市场结论。每组必须用自己的真实调研材料填写，并能解释为什么选择该场景。
一句话中应避免：
- “所有人”“各种环境”等无法控制的用户和场景；
- “全面提升”“更加智能”等无法验收的目标；
- 一开始同时识别十余种状态；
- 尚未调研就指定昂贵或复杂的技术方案；
- 把“使用人工智能”本身当作用户价值。
5.2.3 产品定义需要随证据修订
较早的软件项目常在开发前编写完整需求，再按既定计划实施。这种方法适合边界稳定、变更代价很高的工程。面向新场景的产品却包含许多尚未证实的假设。若一开始写成完整功能清单，团队容易把“已经写入文档”误认为“用户确实需要”。
轻量、可版本化的产品定义保留了必要约束，也允许证据推动修订。它的代价是团队要持续维护需求、测试和发布说明之间的一致性。AI可以加快文档整理，但不能把未经调研的设想变成事实。
5.3 设计小规模真实调研
5.3.1 四类调研回答不同问题
| 调研方法 | 主要回答 | 典型证据 |
|---|---|---|
| 访谈 | 用户怎样描述当前问题和处理方式 | 匿名访谈记录、原意摘要 |
| 现场观察 | 问题在真实流程中怎样发生 | 时间、地点、操作步骤、照片或示意图 |
| 公开资料调研 | 市场、标准、同类方案和技术边界 | 可访问来源、发布日期、摘录位置 |
| 替代方案分析 | 用户现在怎样解决问题 | 人工流程、通用设备、现有系统 |
大学一年级的课程项目不要求大规模市场调查，但要求接触真实问题。建议每组至少完成：
- 3名相关使用者或管理者的访谈；
- 1次目标场景观察；
- 3项可核查的公开资料；
- 2种现有替代方案分析。
数量只是最低课堂要求，不能由少量样本推断整体市场规模。调研结论应使用“本次受访者中”“在本次观察场景下”等准确表述。
5.3.2 访谈问题围绕现有行为
优先询问已经发生的行为：
1. 最近一次出现这个问题是什么时候？
2. 当时你怎样发现它？
3. 发现后采取了什么行动？
4. 从发生到发现大约经过多久？
5. 哪些信息会帮助你更快判断？
6. 现在使用什么工具或人工方法？
7. 当前方法最不方便或最不可靠的地方是什么？
8. 错报一次和漏报一次分别会造成什么影响？
避免直接问：
“如果有一个AI设备，你会不会使用？”
这类问题容易得到礼貌性的肯定，但不能证明需求真实存在。产品价值要从问题频率、处理成本、时间要求和现有替代方案中判断。
5.3.3 保护个人信息
访谈前说明课程用途和记录方式，并取得参与者同意。公开仓库中不保存真实姓名、联系方式、精确行动轨迹、原始语音或未经授权的照片。
调研记录可以使用匿名编号：
## 访谈U03
- 日期：<实际日期>
- 角色：实验课程助教
- 场景：教学实验室设备巡检
- 当前做法：课前与课后人工检查
- 最近实例：<按原意摘要，不记录身份信息>
- 主要困难：<事实或用户陈述>
- 待验证假设：<团队推断，单独标记>
敏感原始材料若确有保留必要，应放在经过授权的受控位置，不进入将来可能开源的产品仓库。
5.4 让AI协助调研而不代替证据
5.4.1 先分配研究任务
为产品定义建立GitLab议题，例如：
# 调研智能感知终端的目标场景
## 任务
比较三个候选场景，从问题真实性、事件可感知性、
原型可实施性和数据合规性四方面形成选择建议。
## 输入
- 访谈记录U01—U03；
- 现场观察O01；
- 已核查公开资料S01—S05。
## 输出
- 候选场景比较表；
- 推荐场景及理由；
- 仍需验证的假设；
- 不进入最小可行产品的需求。
## 验收
- 每项事实标注来源编号；
- AI不得补写访谈中没有出现的观点；
- 无法确认的信息标记为“待验证”；
- 结果经团队成员复核。
从议题建立分支：
git switch -c issue-21-product-scope
AI参与的文档变更同样要经过差异、提交和合并请求，不能因为“只是文字”就跳过工程流程。
5.4.2 使用结构化材料作为上下文
把已经脱敏的调研记录和来源清单提供给Cline，并限制读取范围：
请只读取：
- docs/product/research-log.md
- docs/product/product-brief.md
任务：
1. 提取候选用户、场景、问题、现有做法和期望结果；
2. 每个结论标注记录编号；
3. 区分“原始事实/用户陈述”“团队判断”“待验证假设”；
4. 找出材料之间的矛盾；
5. 不补充材料中不存在的市场规模、用户比例和性能数字；
6. 只输出分析，不修改文件。
AI整理后，逐项回到原始记录核对。若模型把一位受访者的意见写成“用户普遍认为”，应改回准确范围。
5.4.3 公开资料必须回到原始来源
AI可能提供看似完整的产品、标准、价格和参数。正式进入仓库前至少核对：
- 来源页面是否真实存在；
- 发布者是否为厂商、标准组织或其他可识别主体；
- 标题、日期、版本和参数是否一致；
- 内容是否适用于目标地区和使用场景；
- 价格和供货信息是否标注查询日期；
- 引用是否只支持当前结论，而不是被过度推断。
研究日志可以采用：
| 编号 | 问题 | 来源 | 发布/更新日期 | 核查日期 | 支持的结论 | 限制 |
|---|---|---|---|---|---|---|
| S01 | <问题> | <原始链接> | <日期> | <日期> | <结论> | <适用范围> |
无法打开或无法确认出处的AI答案只能作为搜索线索，不能作为产品决策依据。
5.5 比较候选应用场景
5.5.1 用约束比较，而不是凭新奇程度选择
每组先提出不超过三个候选场景，再使用统一尺度比较：
| 维度 | 判断问题 | 记录方式 |
|---|---|---|
| 问题真实性 | 是否有可核查实例和现有处理成本 | 调研证据编号 |
| 事件可感知性 | 传感器是否能观察到与事件相关的信号 | 已知、待验证 |
| 反馈价值 | 用户收到结果后能否采取行动 | 具体行动 |
| 误报与漏报风险 | 错误判断分别造成什么后果 | 风险等级和理由 |
| 原型可实施性 | 课程硬件、时间和场地是否支持 | 约束清单 |
| 数据可获得性 | 能否合法、持续获得必要数据 | 授权和采集条件 |
| 成本边界 | 最小可行产品是否能在课程预算内实现 | 目标成本，不写虚假实测 |
| 推广可能性 | 是否存在可重复部署的同类场景 | 待验证范围 |
评分可以辅助讨论，但评分背后的证据比总分更重要。对于尚未进行技术验证的项目，应写“待验证”，不能为了得到完整表格而编造分数。
5.5.2 明确项目不做什么
范围控制至少包括以下排除项：
## 最小可行产品不包含
- 不用于医疗诊断、安全执法或其他高风险自动决策；
- 不保证识别所有用户、所有设备和所有环境；
- 不持续上传未经处理的原始个人数据；
- 不在第一版本同时支持多种传感器和多种通信链路；
- 不在模型和数据尚未验证时承诺准确率；
- 不把课程原型表述为可直接量产产品。
排除项不是项目缺陷，而是当前版本的工程边界。后续若要扩大范围，必须建立新的议题，补充风险、资源和验证。
5.6 定义产品结果和系统输出
5.6.1 区分信号、模型结果、事件和通知
智能感知终端涉及四层不同信息：
传感器信号
→ 模型或规则给出的状态判断
→ 满足策略条件的产品事件
→ 呈现给用户的反馈或通知
例如，传感器某一时段出现特征变化，不等于产品必须通知用户。模型结果还要经过阈值、连续确认、冷却和风险规则，才能形成产品事件。
本课程重点管理这四层之间的接口、版本和验证。信号处理、特征构造与模型训练的深入内容由《人工智能数据科学》承担；传感器接口、设备资源与嵌入式实现由《感知与异构计算系统原型》承担。
5.6.2 写出可观察的产品结果
产品结果应描述用户能够看到或采取的行动，例如：
当设备确认目标事件后，
本地状态指示在规定时间内变化，
服务器收到包含设备、事件类别和时间的记录，
授权用户能够查看事件及其处理状态。
这段描述仍不是完整规格，但已经比“实现智能识别”更接近可以验证的产品行为。
5.7 确定最小可行产品
5.7.1 最小可行产品用于验证核心闭环
最小可行产品（Minimum Viable Product，MVP）用于验证核心问题和解决方式。它是能够完成上述验证的最小产品闭环。它应当能够运行，并接受目标使用者评价。单独的界面、模型或硬件还不能构成MVP。
智能感知终端的第一条完整闭环可以定义为：
一个已确认的输入
→ 一个事件判断
→ 一条结构化事件
→ 一种用户反馈
→ 一份可追溯记录
第7章将先用按键或可重复输入替代尚未稳定的传感与模型，验证端到端工程闭环。第8—10章再逐步替换为真实传感器、正式数据和端侧模型。
5.7.2 使用优先级表控制范围
将需求分为四类：
| 级别 | 含义 | 本课程处理 |
|---|---|---|
| 必须 | 缺少后无法验证核心闭环 | 进入最小可行产品 |
| 应该 | 显著改善使用，但可在核心闭环后完成 | 进入后续迭代 |
| 可以 | 有价值但当前证据或资源不足 | 放入候选列表 |
| 本期不做 | 风险高、范围大或偏离核心问题 | 明确排除 |
示例：
| 需求 | 级别 | 理由 |
|---|---|---|
| 设备产生一种目标事件 | 必须 | 核心输入 |
| 事件可上传并被确认 | 必须 | 核心端云闭环 |
| 用户查看最近事件 | 必须 | 核心反馈 |
| 断网后保存少量事件 | 应该 | 提高可用性 |
| 同时支持多类传感器 | 本期不做 | 扩大硬件和数据范围 |
| 自动完成高风险处置 | 本期不做 | 超出课程产品边界 |
每一项“必须”需求都应能在18周内产生证据。若最小可行产品仍有十余项相互依赖的“必须”，说明范围尚未收敛。
5.8 编写产品简述
docs/product/product-brief.md采用一页结构：
# 智能感知终端产品简述
## 1. 用户与场景
- 目标用户：
- 使用场景：
- 当前做法：
## 2. 核心问题
<一句话问题定义>
## 3. 产品结果
<用户收到什么结果并采取什么行动>
## 4. 证据
- 访谈：
- 观察：
- 公开资料：
- 替代方案：
## 5. MVP
- 输入：
- 判断：
- 事件：
- 反馈：
- 记录：
## 6. 不在本期范围
-
## 7. 主要风险与待验证假设
| 假设 | 为什么重要 | 验证方法 | 截止版本 |
|---|---|---|---|
## 8. 成功判据
<说明可测量结果，区分目标值和当前实测值>
产品简述只保留最重要结论。访谈全文、比较表和来源信息放在研究日志中，通过链接追溯。
5.9 编写轻量产品需求文档
产品需求文档（Product Requirements Document，PRD）记录用户问题和产品范围。它还记录需求及其验收条件。本书采用轻量形式，只保存能够指导当前版本的内容。
5.9.1 给需求稳定编号
在docs/product/prd.md中为需求分配标识：
# 产品需求文档
## PR-01 事件产生
当设备确认目标状态或动作达到事件条件时，
系统应产生一条包含事件类型、设备标识和时间信息的事件。
验收：
- 给定有效输入时产生一条事件；
- 未达到条件时不产生事件；
- 同一事件在冷却期内不重复通知。
## PR-02 事件送达
设备应把事件发送给课程服务器，并获得明确确认。
验收：
- 服务器接受有效事件并返回成功状态；
- 无效消息返回可区分的错误；
- 失败发送不会被记录为成功。
## PR-03 用户反馈
授权用户应能查看最近事件及其处理状态。
验收：
- 页面或客户端显示事件类型和时间；
- 未授权用户不能查看设备事件；
- 用户可以区分待处理与已处理事件。
PR表示产品需求。编号在后续规格、议题、测试和发布说明中保持稳定。修改需求内容时保留其历史；若需求含义完全改变，应创建新编号并说明旧需求状态。
5.9.2 需求写行为，不预先锁定实现
下面两种写法含义不同：
需求：设备应在目标事件确认后5 s内提供用户可见反馈。
方案：设备通过某通信模块调用某接口发送消息。
第一句描述需要验证的结果，第二句描述一种实现。产品需求文档优先写结果，技术方案在第6章确定。过早把特定芯片、云服务或模型写进需求，会使后续选型难以比较和替换。
5.9.3 不填写未经测量的结果
需求中的数字分为三类：
| 类型 | 示例 | 写法 |
|---|---|---|
| 目标 | 反馈延迟目标不超过5 s | 标记为Target |
| 估计 | 当前方案预计约3—8 s | 标记为Estimate并说明依据 |
| 实测 | 在指定版本和环境中测得4.2 s | 标记为Measured并链接证据 |
在尚未构建系统时，不能把目标值写成“实测指标”。后续每次迭代都用版本和环境更新实测结果。
5.10 用AI检查范围而不是扩展范围
产品简述和产品需求文档形成后，让AI进行一次反向审查：
请只读取：
- docs/product/product-brief.md
- docs/product/prd.md
- docs/product/research-log.md
任务：
1. 找出没有调研证据支持的产品结论；
2. 找出无法观察或无法验收的需求；
3. 找出MVP中相互依赖但未说明的需求；
4. 找出与“不在本期范围”冲突的内容；
5. 找出把技术方案误写成产品需求的位置；
6. 不增加新功能，不直接修改文件。
输出：
- 文件和位置；
- 问题；
- 影响；
- 最小修订建议；
- 对应证据编号或“缺少证据”。
团队逐项判断AI意见。模型指出“缺少证据”时，团队应查明证据缺口。可以补充调研、降低表述强度、标记假设或删除需求。不应要求AI编写没有依据的理由。
5.11 提交并评审产品定义
检查差异：
git status --short
git diff -- README.md docs/product
产品定义可按逻辑拆成提交：
git add README.md docs/product/research-log.md
git commit -m "docs(product): record initial research evidence"
git add docs/product/product-brief.md docs/product/prd.md
git commit -m "docs(product): define sensing terminal MVP"
两个提交分别记录“依据”和“结论”，便于评审者追溯。创建合并请求时说明：
- 选择了哪个目标场景；
- 哪些证据支持选择；
- 哪些内容仍是假设；
- 最小可行产品包含与排除什么；
- AI怎样参与整理和审查；
- 团队拒绝了哪些范围扩张。
评审者重点检查：
[ ] 问题来自真实调研，而不是技术想象
[ ] 用户、场景和期望结果具体
[ ] 事实、判断和假设已经区分
[ ] 公开资料可以追溯
[ ] MVP形成完整但最小的产品闭环
[ ] 排除项明确
[ ] 需求可以观察和验收
[ ] 没有把目标或估计写成实测结果
[ ] README.md与PRD描述一致
完成修改和评审后合并到main，建立里程碑：
v0.1 最小端云闭环
将产品需求文档中的必须需求拆为后续议题，但不要在本章同时启动全部开发任务。
5.12 本章工程检查
本章结束时，仓库至少应包含：
README.md
docs/product/research-log.md
docs/product/product-brief.md
docs/product/prd.md
并满足：
[ ] 仓库位于校内GitLab且main受保护
[ ] README.md准确反映当前阶段
[ ] 至少有规定数量的真实调研证据
[ ] 个人信息已经脱敏
[ ] 产品问题可以用一句话表达
[ ] MVP只有一条核心闭环
[ ] PRD需求有稳定编号和验收条件
[ ] 目标、估计和实测已经区分
[ ] 产品定义通过合并请求评审
5.13 本章小结
本章从真实问题出发，建立了智能感知终端的项目仓库、调研记录、产品简述和轻量产品需求文档。AI用于整理材料、发现矛盾和检查范围，调研证据与人工判断决定哪些结论能够进入仓库。
产品定义不是开发前一次性完成的文件。后续原型、数据、模型和用户试用可能推翻当前假设。每次改变都应通过议题说明原因，以Git差异记录变化，并同步更新需求、测试和发布说明。
第6章将把产品需求转化为系统边界、接口契约和资源预算。关键选择将写入技术决策记录。三门课程由此能够围绕同一项目并行工作。
5.14 综合实践
- 选择一个真实校园场景，通过访谈、观察和公开资料形成研究日志。每项结论标明事实、用户陈述、团队判断或待验证假设。
- 让AI对调研材料进行归类并指出矛盾。人工回到原始记录核对，形成“接受、修正、删除”三类处理表。
- 为本组项目编写
README.md、产品简述和PRD。MVP只保留一条完整闭环，并明确不少于3项本期排除内容。 - 与另一组交换产品定义。双方分别找出一项无证据结论、一项不可验收需求和一项范围过大的设计，并通过合并请求完成修订。