第13章 学生项目冲刺一：确定项目原点
前12章由教师主导完成了一次完整产品开发。后六周转为学生主导。每组选择一个真实、可感知、可验证的物理AI问题。学生复用已经掌握的方法，在六周内发布v1.0。
本周只确定一个足以启动开发的“项目原点”：
一个具体用户
＋ 一个真实场景
＋ 一个可感知事件
＋ 一个可执行反馈
＋ 一条六周内可完成的闭环
项目原点不是完整商业计划，也不是功能愿望清单。它要使团队能够在下一周立即验证核心技术，并在第三周形成第一个可运行版本。
项目立项曾经常以题目新颖或功能数量为主要依据。物理AI项目还受传感条件、数据来源和硬件资源限制。项目原点先要求可核查问题和最小闭环，从而减少后期因基础假设不成立而返工。
完成本章后，应当能够：
- 从实际观察和访谈中提出项目候选；
- 判断物理事件是否能被课程条件下的传感器观察；
- 识别高风险、不具备数据条件或范围过大的题目；
- 使用AI扩展候选并通过证据收敛；
- 定义单一最小智能闭环；
- 确定六周版本路线和停止条件；
- 在
README.md中准确描述项目当前状态； - 建立团队责任和个人可追溯贡献；
- 通过立项合并请求接受教师与同伴评审。
13.1 建立项目选择边界
13.1.1 六周项目的基本尺度
建议每组2—4人，项目第一版只包含：
1类主要传感输入
1个核心状态或事件
1个模型或确定性基线
1条设备到用户的反馈链路
1种课程统一硬件或已验证替代
1个公开发布范围
以下信号表明范围过大：
- 需要多种尚未验证的传感器同时工作；
- 同时开发移动端、管理后台和多种通信协议；
- 需要大量难以取得或授权的数据；
- 第一版就要求识别很多类别；
- 依赖尚未取得的定制芯片或结构件；
- 需要跨地区、大规模用户或长期运行才能验证；
- 用“平台”“生态”“全场景”代替具体结果。
范围缩小不等于降低技术质量。六周目标是完成一条能够运行、验证、发布和继续演进的产品闭环。
13.1.2 不选择高风险自动决策
学生项目不直接承担：
- 医疗诊断或治疗建议；
- 人身安全的唯一报警依据；
- 未经授权的身份识别和持续跟踪；
- 对个人进行惩罚、筛选或高影响评价；
- 未经允许采集声音、图像、位置或生理信息；
- 可能造成设备损坏或人身伤害的自动控制。
若候选项目接近这些范围，应改为低风险教学验证。项目可以只记录受控实验状态，提供非关键提示，并要求人工确认。
13.2 从真实问题形成候选
13.2.1 先记录发生过的实例
每位成员提出不超过两个候选，并填写：
## 候选项目
- 相关用户：
- 发生场景：
- 最近一次实际实例：
- 当前处理方式：
- 问题造成的时间、操作或信息影响：
- 用户收到结果后可以采取的行动：
- 可能观察该事件的物理信号：
- 当前已有证据：
- 仍需验证：
没有实际实例的创意可以保留为备选，但不能立即写成已确认需求。
13.2.2 候选来源
可从下列范围寻找：
- 教学实验、设备管理和校园公共空间中的低风险状态；
- 运动、姿态、振动、环境或使用行为中的简单事件；
- 现有人工巡检、记录和提醒流程；
- 对无障碍、节能、维护或信息反馈有帮助的场景；
- 三门课程已经具备传感、数据和原型条件的问题。
项目主题可以不同，工程闭环保持一致：
物理信号
→ 数据窗口
→ 模型或规则
→ 产品事件
→ 用户反馈
→ 记录和改进
13.3 开展快速真实调研
本周至少完成：
- 2—3名相关人员访谈；
- 1次目标场景观察；
- 2种当前替代方案；
- 2项可靠公开资料；
- 1次核心信号可感知性检查。
研究记录延续第5章的方法，区分：
F：可以核查的事实
U：用户原意
J：团队判断
H：待验证假设
例如：
F-03：观察O01中，人工检查每30 min进行一次。
U-02：受访者U02希望先知道“是否需要检查”，不要求自动处置。
J-01：及时提示可能减少无效巡检。
H-04：三轴传感器能稳定区分目标状态和普通扰动。
H-04必须通过技术验证和数据证明，不能因AI给出肯定回答而变成事实。
13.4 验证事件是否可感知
13.4.1 建立信号假设
用下列结构：
当<目标事件>发生时，
<传感器>在<安装位置和配置>下
可能观察到<信号变化>，
该变化与<主要干扰>存在可分析差异。
需要检查：
- 事件是否在传感器量程和频率范围内；
- 安装位置是否稳定；
- 主要干扰是否产生相似信号；
- 是否能合法、重复采集正例和反例；
- 事件频率是否支持六周验证；
- 传感数据是否涉及个人隐私；
- 课程硬件能否持续采集。
13.4.2 做一次最小技术探查
使用课程硬件或现有仪器采集少量正例与反例，画出或查看基本信号。技术探查只回答“是否值得继续”，不提前宣称模型准确率。
记录：
# 技术探查TP-01
- 假设：
- 硬件与配置：
- 固件提交：
- 操作：
- 正例数量：
- 反例数量：
- 可观察现象：
- 主要干扰：
- 结论：继续/调整/停止
- 下一项验证：
探查代码放在任务分支，通过合并请求保存有价值的脚本和记录。一次性临时代码若不进入产品主线，也要说明其用途和结论。
13.5 使用AI扩展和收敛候选
13.5.1 扩展阶段
将脱敏记录提供给AI：
请基于research-log.md提出不超过3个项目候选。
每个候选只使用材料中已有的用户、场景和问题；
给出可能的物理信号、用户反馈和最小闭环；
把没有证据支持的内容标记为假设；
不要提供市场规模、准确率和成本数字；
不要直接修改文件。
AI用于重新组合和发现遗漏，不决定最终项目。
13.5.2 收敛阶段
请对三个候选进行反向审查：
1. 哪个需求证据最弱；
2. 哪个事件最难重复采集；
3. 哪个方案依赖未验证硬件；
4. 哪个项目最容易产生隐私或安全问题；
5. 哪个MVP仍包含多条闭环；
6. 每个候选本周必须完成的最小技术验证。
结论必须引用记录编号；无证据时写“缺少证据”。
团队回到记录核查AI引用。把被否决候选和理由保留在决策记录中，避免项目受阻后重复进入已知不可行方向。
13.6 使用四个门槛选择项目
| 门槛 | 通过条件 | 不通过处理 |
|---|---|---|
| 需求 | 有真实实例、现有做法和可执行用户结果 | 补充调研或换题 |
| 感知 | 有可重复信号假设和初次探查 | 调整传感器/安装或换题 |
| 数据 | 能在授权范围取得正例、反例和元数据 | 缩小类别或换题 |
| 工程 | 硬件、时间、成员和服务器支持六周闭环 | 缩小范围或采用课程基线 |
任何一个门槛未通过，都不能仅靠AI生成代码继续推进。
建议比较表：
| 候选 | 需求证据 | 感知可行 | 数据可得 | 工程可行 | 风险 | 决定 |
|---|---|---|---|---|---|---|
表中每项链接研究或探查记录，不使用只有总分没有依据的评分。
13.7 定义最小智能闭环
项目闭环写成：
输入：<一种物理信号>
→ 窗口：<明确时间或样本范围>
→ 判断：<一个状态/事件>
→ 策略：<确认和重复控制>
→ 反馈：<一种用户可见结果>
→ 行动：<用户能够采取的操作>
最小可行产品验收至少包含：
- 一个真实正例；
- 一个真实反例；
- 一个主要干扰；
- 一条成功端到端路径；
- 一条通信或设备失败路径；
- 一项隐私或数据边界检查；
- 一个可回退版本。
项目暂时没有模型时，先定义确定性基线或可重复输入。第15章必须先发布v0.1，第16章再用模型替换判断组件。
13.8 规划六周版本路线
第13周：项目原点与立项MR
第14周：架构、核心技术探查和仓库基线
第15周：真实设备最小闭环v0.1
第16周：数据与模型版本v0.5
第17周：系统测试和v1.0-rc
第18周：开源审查、展示和v1.0
为每周写一条可演示结果，不写“继续开发”。例如：
第15周结果：
在课程开发板产生一次物理输入，
服务器接收同一event_id，
授权页面显示对应事件。
同时确定停止或降级条件：
- 核心信号在第14周仍不可区分；
- 必需数据无法取得授权；
- 模型无法在课程硬件运行且没有替代；
- 项目出现超出课程范围的安全风险；
v0.1闭环到第15周仍未打通。
触发条件后，团队应执行降级方案。可以缩小类别、改用已验证输入、采用服务器推理，或回到课程建议题目。
13.9 建立项目仓库和README.md
在校内GitLab创建私有项目并初始化README.md。第一稿：
# <项目名称>
## 项目目标
<用户、场景、问题和结果>
## 最小智能闭环
<输入→窗口→判断→事件→反馈>
## 当前证据
- 需求：
- 技术探查：
- 数据：
## 六周范围
- 必须：
- 本期不做：
## 版本路线
- v0.1：
- v0.5：
- v1.0-rc：
- v1.0：
## 当前状态
立项评审中，尚无可运行版本。
## 文档
- 调研记录：
- 项目章程：
- 风险与假设：
名称应专业、稳定，避免依赖短期活动、特定成员昵称或尚未确定的产品形态。
13.10 明确团队与个人责任
团队共同使用一个仓库，每个成员至少承担一个可验收工程对象：
产品与验证
设备与硬件接口
数据与模型接口
服务器与用户反馈
小组人数较少时可以兼任。责任不是独占文件，所有关键合并请求仍需同伴评审。
个人贡献通过以下证据体现：
- 负责或参与的议题；
- 提交和合并请求；
- 评审意见；
- 验证记录；
- AI建议的接受、修正和拒绝；
- 项目复盘中的具体判断。
提交次数和代码行数不能单独代表贡献。
13.11 编写项目章程
docs/product/project-charter.md：
# 项目章程
## 1. 用户与问题
- 目标用户：
- 场景：
- 当前做法：
- 核心问题：
- 证据编号：
## 2. 项目目标
<可观察的产品结果>
## 3. 最小智能闭环
- 输入：
- 判断：
- 事件：
- 反馈：
- 用户行动：
## 4. MVP范围
### 必须
-
### 本期不做
-
## 5. 可行性
- 信号探查：
- 数据条件：
- 硬件条件：
- 主要技术风险：
## 6. 数据、安全和隐私
-
## 7. 六周版本路线
-
## 8. 团队责任
-
## 9. 停止或降级条件
-
章程中尚未验证的内容明确写成假设，不用正式语气掩盖证据不足。
13.12 提交立项合并请求
从分支提交：
git switch -c issue-1-project-origin
git add README.md docs/product
git commit -m "docs(product): define project origin and six-week scope"
git push -u origin issue-1-project-origin
立项合并请求说明：
- 选择该问题的证据；
- 技术探查结果；
- 最小闭环；
- 排除项；
- 六周路线；
- 最大风险和降级方案；
- AI参与和人工核查。
评审清单：
[ ] 有真实用户问题和可核查实例
[ ] 目标事件可以被物理信号观察
[ ] 数据可以在授权范围取得
[ ] MVP只有一条核心闭环
[ ] v0.1不依赖完整模型
[ ] 六周结果可逐周演示
[ ] 高风险用途已排除
[ ] 停止和降级条件明确
[ ] README.md准确写明尚无可运行版本
合并请求获得教师和同伴批准后合并。未通过某个门槛时，根据评审修改项目原点，而不是在未批准分支直接开始大规模开发。
13.13 本章小结
本章完成学生项目的原点选择。团队从真实实例出发，以需求、感知、数据和工程四个门槛筛选候选。入选项目应形成一条六周可完成的最小智能闭环。README.md、项目章程和立项合并请求共同保存决策。
AI帮助扩展候选、发现证据缺口和检查范围。真实调研、技术探查和团队风险判断决定项目是否启动。
第14章将把项目原点转成工程基线。团队还将完成最先影响成败的核心技术验证。
13.14 综合实践
- 从校园或生活观察中提出3个项目候选。每个候选须有一个可核查实例、一个可感知事件和一个低风险用户结果。
- 为每个候选建立“事件—传感器—安装位置—信号—干扰”假设，并用限时技术探查取得证据。
- 使用需求、感知、数据和工程4个门槛比较候选。选择一项并说明舍弃另外两项的依据。
- 为入选项目形成
README.md、项目章程、六周版本路线和停止条件，不把待验证假设写成事实。 - 提交立项合并请求，并评审另一组项目。评审意见应指向证据、范围或工程边界。