JetWave AI 智能教练：基于自有产品形态与本地日志的预研与终态方案

项	内容
日期	2026-09-14
对照目标	`temp/tagert/JetWave AI 智能教练产品规划与方案论证.md`（HeyGo 对标稿）
本方案立场	不抄滑雪夹具教练。用已在卖的板 + 遥控器 + 已上传的航行日志，做 JetWave 自己的「骑行智能」。
数据底盘	本地 `surf_motion_trajectory_history` + OSS 轨迹 JSON + TLA / 电流工况 / 油门曲线
读者	产品、研发、算法、数据；会上先看第 0～2 节

分层锚点

L1 结论：我们卖的是什么 · 原规划必须改的假设 · 终态长什么样
L2 预研：五条能用现日志验证的场景 · 字段能信不能信
L3 架构：产品 · 软件 · AI · 数据

0. 先看结论

0.1 一句话

JetWave 已经是「板体 + 遥控器 + App 回传完整航次」的产品。AI 教练的第一形态不是再做一个夹在身上的 IMU，而是把已经在库里的油门–电机–姿态–轨迹–故障变成骑手能懂的滑后指导，再长出安全与技能两条腿。实时语音是终态可选项，不是预研原点。

0.2 原规划哪些不能照抄

目标文档论证了「eFoil 值得做 AI 教练」，方向对。下面几条若原样执行，会做成另一个品类，而不是我们的品类。

原规划假设	本地事实	本方案改法
先做采集 SDK、再攒 1 万条标注	未删除航次约 2.1 万，OSS 已缓存约 0.9 万；油门曲线已跑过 8,904 航	预研只消费现日志，不先写采集 SDK
对标 HeyGo：夹具 + 100Hz 新硬件	板和遥控器已在卖；日志里已有 `attitude`、GPS、油门、电机、电流、故障码	不新增教练硬件做 MVP；JetLink / 机内更高频是增强，不是入场券
Phase 1 就要动作评分 + App，Phase 2 就上实时语音	水上没有「缆车复盘」；耳机、风噪、安全话术都没验证	滑后报告先做成可信产品；实时反馈单独设门禁
飞行高度、风浪、落水是现成特征	`wind_power` / `wave_high` / `falls_number` 全 0；轨迹 JSON 里 Depth/Pressure 多数未带	高度先用速度+电流+姿态代理，不要当水深已入库
知识图谱 15–20 项滑雪指标直接迁移	eFoil 教学未标准化；我们已有故障码、堵转、过压、翼型/负载口径	先建 JetWave 技能+安全词典，不要先画滑雪式图谱
商业从 $9.99 订阅起	板是高客单硬件；日志已在为研发/品质服务	先标配滑后报告拉留存与安全，订阅和 B2B 租赁评分后置
用户 53% 有 `play_user_id`	近一半航次匿名	个体基线以遥控器 SN / 板 SN 为键，用户账号是增强键

0.3 现在就能拍板的四件事

产品原点：滑后教练，不是实时教练。
数据原点：现有 OSS 轨迹点 + 已有分析表，不是新传感器项目。
差异化原点：油门是「意图」，电机/电流/姿态/速度是「结果」，故障是「越界」。HeyGo 没有这条因果链。
安全是教练的一半：油门顶死习惯、堵转、过压、姿态翻板，已经在伤人和品质里出现过。做成「只夸转弯」的运动 App，是产品错误。

1. 我们自己的产品形态（设计约束）

骑手 ── 遥控器（油门 / 档 / 模式 / 扳机）
         │ BLE
         ▼
       板体（ESC / ECU / BMS / 电机 / IMU / GPS）
         │ App 回传
         ▼
       OSS 单航次 JSON  +  MySQL history
         │
         ├─ TLA          故障 / 温度 / 协议码
         ├─ 电流工况 v3  翼型 / 负载 / 是否真飞
         ├─ 油门曲线     使用量、保载、扳机寿命
         └─ traj-store   地图回放（可选）

这和 HeyGo「靴侧夹具 → 手机 → 云」不是同一形态：

控制输入在遥控器上，不是纯被动捕捉身体。
动力结果在电驱上，可以量化「加了多少油、电机回了什么」。
日志已经是产品的一部分，不是教练硬件带来的副产品。
安全件已经出过事故（EF01 扳机簧）。教练若回避油门习惯，等于回避我们最懂的数据。

因此终态品牌可以叫「AI 教练」，但系统身份应是：

Ride Intelligence：一次航次的意图、响应、结果、越界，变成对骑手和内部都可复算的结论。

对外是教练，对内是同一条分析面（品质、研发、租赁、经销已经在用这条面）。

2. 四视角：同一套形态，四条必须同时成立

2.1 顶级 AI 产品经理

用户真正买的不是「100 项指标」

eFoil 用户的钱已经花在板上。他们要的是三句能执行的话：

这次为什么飞不稳 / 飞不起来 / 转弯发飘。
下次先改哪一个动作（油门、重心、速度，一次只改一件）。
有没有在伤害自己或伤害板（顶油门、过流、过热、姿态过大）。

原规划的 P0「基础动作评分 + 滑后报告」方向对，但评分对象必须改成 eFoil 自己的动作单元，不能拿「弯」硬套。

动作单元（产品词典，预研就要锁）

单元	骑手能懂的名字	日志里用什么切
离水	这次飞起来没有、花了多久	油门上升 + 电流峰 + 速度跨过约 15–20 km/h
巡航	飞稳没有	连续航段、速度方差、油门抖动、电流是否异常偏高
转弯	弯是否干净	GPS 曲率 + roll + 油门是否在弯中猛补
加速 / 顶油	是不是一直捏死	油门开度分布、满油门保载占比（寿命报告已有方法）
减速 / 着水	收得干净不	油门回落、速度回落、姿态冲击
越界	这次有没有危险或伤机	TLA 故障、堵转、过压、大倾角、超温

一页报告只允许：1 个主问题 + 1 个下次动作 + 1 个安全提示（可空）。多了就是仪表盘，不是教练。

预研要验证的产品假设（比功能列表重要）

假设	怎么用本地日志证伪
H1 骑手在意滑后 60 秒结论，不在意 100 个特征	内部先出 30 份人工可读报告，给 5～10 个真骑手 / 教练看，问「下一趟会不会改」
H2 油门习惯比姿态更能解释「飞不好」	同一批航次：只看油门曲线 vs 只看姿态，哪边和教练主观分更一致
H3 安全提示不会被当成扫兴	把「满油门保载过高」「接近堵转」写成教练话术，看是否被接受
H4 实时语音现在做，会伤害信任	预研阶段不做耳机；若滑后结论经常错，实时只会放大错

明确不做（预研 90 天）

新夹具、新 IMU 配件、单独卖 $199 升级盒。
社区、排行榜、课程市场、教练预约。
「人格化语气」大模型先上。先把哪一句该说做对，再包装语气。
用大模型直接读原始点序列出分数。分数必须可复算。

商业顺序（改原规划）

标配滑后报告（随 App，服务已售出的板）→ 留存、口碑、客服减负。
安全+技能双轨 让研发/品质和用户看同一套数 → 内部 ROI 先于订阅。
租赁 / 教练机构 B2B：同一套航次评分，按队、按板看「今天有没有人在硬飞」。
订阅和实时耳机，是报告被信任之后的加价，不是第一张牌。

2.2 顶级软件架构师

原则

不要为教练再铺一条采集和存储。教练是现有日志面的产品投影。

业务只写：history 行 + OSS JSON
        │
        ▼
   会话计算层（增量，主键 trajectory_id = history.id）
        ├─ TLA          故障 / 温度 / 协议     （已有，只读）
        ├─ Usage/JUA    翼型 / 负载 / 真飞     （已规划）
        └─ Coach        分段 / 技能分 / 话术键 （本方案新增，旁路表）
        │
        ▼
   产品出口
        ├─ App 滑后页
        ├─ 后台 / 客服
        └─ 内部报告（品质、寿命、选址已在用）

主键与版本（锁死）

规则	为什么
`trajectory_id` = `surf_motion_trajectory_history.id`	和 TLA、JUA、后台分析页同一条航次
`object_key` 唯一	同一文件不打两套分
`content_fingerprint` + `coach_analyzer_version`	算法升级才重算，和 TLA 同一套路
点级不进业务 MySQL	分段与特征进旁路表 / `ext_json`；回放走 OSS 或 traj-store
话术键 ≠ 话术正文	库里存 `takeoff.slow` / `throttle.hold_high`，App 再本地化；模型不得直接写分数

预研软件形态（4 周能跑）

不要先做 App。先做和现在电流/寿命同一类的东西：

本地批处理：读已缓存 OSS → 切段 → 打技能分 → 出 Markdown/HTML 单航次报告。
一张对照表：规则分 vs 教练/骑手主观分（哪怕先内部 30 条）。
复算入口：py -3.12 analysis/tools/coach_session.py --trajectory-id …
和弹簧、密封圈一样：主张必须能复算。

上线时 Coach 服务形态对齐 TLA：Docker + cron，只消费 analyze_status=done 的航次，避免两套 OSS 客户端。

实时反馈的软件门禁

只有同时满足才允许做「航中语音」：

滑后主问题准确率被骑手/教练接受（见第 7 节指标）。
端上能在 200 ms 内用已缓存的规则判定「现在能不能说话」（起飞中 / 大倾角 / 故障码），云端 LLM 不得在航中决策。
遥控器或手表有可靠近端通道；失败时静默，不半句卡死。

原规划 Month 4–6 上实时 APP，按我们的形态应改成：滑后稳定一个旺季之后再开闸。

与现系统边界

系统	教练用它做什么	教练不替代它
TLA	越界、温度、协议故障当安全通道	不改故障判定口径
电流工况 v3 / JUA	是否真飞、翼型、负载档	不在教练里重做 K-Means
油门寿命分析	满油门保载、半程再扣	不把 93,000 次台架指标暴露给骑手
traj-store	报告里的轨迹回放	不把点灌进教练库
Calibra / 主张校准	教练词典和阈值走同一套可审批主张	教练 App 不是组织操作系统

2.3 顶级 AI 架构师

模型分层（由稳到险）

L0 规则切段     油门 / 速度 / 电流 / 姿态阈值     必须先有，可复算
L1 统计特征     段内方差、滞后、曲率、保载比     必须先有
L2 个体基线     同一 SN 近 N 次的分位             预研可先做遥控器键
L3 小模型       段分类、异常、与教练分校准        有标注再上
L4 大模型       只把「话术键 + 三个数」写成人话   不得当裁判

原规划把「知识图谱 + 个体基线 + 人格化」和姿态估计绑在同一阶段。按我们的数据，姿态估计已经在 ECU / App 里算完（attitude = roll,pitch,yaw，0.1° 写入）。AI 的第一件工作不是再写一套 Madgwick，而是：

在已有姿态和已有油门上，定义「好航次 / 坏航次」的可检验标签。

因果是我们的模型，不是装饰

HeyGo 只能做「姿态 → 推测动作」。我们能做：

意图 u(t)  = 油门、档、模式
响应 x(t)  = 电机转速、电流、电压、温度
姿态 q(t)  = roll, pitch, yaw
结果 y(t)  = 速度、轨迹曲率、（若有）高度
越界 e(t)  = ESC/ECU/BMS 事件、堵转、过压、大倾角

预研要算清的三件事：

滞后：油门加上去之后，速度 / 电流 / 俯仰谁先动、隔多少秒。这就是「手感」。
过量：同样速度下电流是否显著偏高（负载/翼型/技术）。v3 已有速度带电流。
失控前兆：油门 >0 且转速 0、过压点、姿态跳变（已有 FAULT_BOARD_ATTITUDE / ±180° 问题，教练必须当「信号脏」处理，不能当翻板）。

标注策略（别一上来 1 万条）

先 200 条高质量，覆盖：

真飞巡航（v3 连续航段通过）
未起飞 / 水中滑行
急弯 + 大倾角
含堵转或过压
满油门保载很高的「猛骑」
新手短航 vs 成熟长航

标签只要 6 个李克特或是否：离水、巡航稳、转弯、收油、安全、总体。教练和内部各标一份，算一致率。一致率 < 0.6 说明词典没对齐，先改词典，不堆模型。

姿态脏数据（架构必须写进方案）

内部已发现 attitude 可出现 ±180° 跳变，不完全等于翻板。教练模型：

倾斜评分用中位和稳健统计，不用单点极值。
|roll|>135 先标「姿态不可信或疑似翻板」，与速度、油门、电流联合才升级为安全提示。
原规划「精度 ≤3°」对标 HeyGo，我们先做字段卫生，再谈精度广告。

实时模型

航中只允许 L0/L1（规则）。L4 只在上岸后，把已算好的键写成 3 句话。禁止「整段轨迹进长上下文再打分」。

2.4 顶级数据分析架构师

现在手里的层

层	大约规模	教练能做什么	不能做什么
history 未删除	~2.1 万航次	量、季节、设备、区域	点级技能
有质量 GPS	~1.9 万	转弯几何、圣地、轨迹	风浪
本地已缓存 OSS	~0.9 万	预研主样本	未缓存的 1.2 万先不进模型
v3 真飞连续航段	~1,618	巡航/翼型/负载金标准	不能代表全部新手
油门曲线研究样本	8,904	意图、保载、水平分层	没有身体关节
有用户 ID	约一半	账号级成长	另一半必须用 SN

字段卫生（教练特征白名单）

能进第一版特征

点：time, throttleLeverQuantity, motorSpeed, electricCurrent, hourSpeed, latitude, longitude, attitude, mode, gear
点：温度 / 电压 / 电量、ecuEventCode / escEventCode / bmsEventCode
会话：航时、距离、最高速、remote_sn / board_id、固件版本
旁路：TLA 故障摘要、v3 是否真飞、翼型/负载档（有则用）

禁止当真实物理量

wind_power, wave_high, falls_number（全 0）
maximum_tilt_angle（空列）
average_speed 头字段（脏；用连续航段）
轨迹里缺失的 Depth/Pressure（traj2ulog 已标明填 0）
姿态单点 ±180° 当翻板

指标分层（分析架构，不是产品文案）

L1 会话健康     是否真飞、有无故障、超温、数据是否完整
L2 意图画像     油门分布、满油门时间比、半程再扣、档/模式
L3 响应品质     电流–速度曲线是否落在该翼型/负载带
L4 姿态与转弯   稳健倾角、转弯半径（已有 attitude_turn_analysis）
L5 成长         同 SN 近 8 周 L2–L4 的分位移动

产品对外只暴露 L1 一句话 + L2/L4 里的一个主问题。L3 同时给内部电池/翼型。

评估与防漂

每个 coach_analyzer_version 保留：样本清单、阈值、复算脚本、30 条金标准航次。
金标准里必须有「姿态脏但没翻」和「真危险倾斜」各若干，防止模型学成乱报翻板。
主张变更走同一套可复算纪律（和 0x400000、93,000 次一样），不在提示词里改阈值。

预研数据任务（按周）

周	数据交付
1	从已缓存 OSS 抽 500 航：字段完整率、attitude 脏点率、油门采样是否≈1 Hz
2	对 500 航跑切段；与 v3「真飞 / 未起飞」对拍
3	200 航人工/教练六标签；出规则分 vs 人工一致率
4	冻结 V0 词典和阈值；列出「必须补采」的字段（水深？更高频 IMU？）——有证据再提硬件

3. 本地日志资产盘点

3.1 一条航次实际长什么样

OSS JSON 根上有设备 SN、固件、用户、起止时间；trajectoryList[] 是约 1 Hz 的点。每点已经同时带：

意图：油门、档、模式
动力：电机转速、电流、电压、温度
空间：经纬度、时速
姿态：attitude = roll,pitch,yaw（度）
越界：三路 event code

这不是「以后装了传感器才有」的数据，是现在就能切段打分的数据。

3.2 和原规划传感器表的对齐

原规划当作已有	日志里的真实情况	预研策略
板 IMU 100–200 Hz	App 回传约 1 Hz 姿态串	滑后够用；实时/暗数据才要机内高频
水深 ~1 cm	轨迹点通常无 Depth	用速度+电流代理离水；硬件补采单独立项
遥控器 IMU	上传的是油门，不是手部姿态	油门就是手；手部 IMU 是增强
GPS 10 Hz	点里有 lat/lon，密度随回传	转弯用已有脚本，先求稳健不求 10 Hz
风浪落水	列在，值全 0	删除特征，直到客户端真报

3.3 我们已经会算、教练应直接复用的

已有能力	脚本 / 服务	教练怎么用
故障与失控	`tla/fault_engine.py` `session_analyzer.py`	安全通道，不重写
真飞 / 起飞电流 / 翼型负载	`current-distribution-analyzer` v3	巡航是否成立、能量是否离谱
油门使用谱、保载、半程再扣	`throttle_profile.py` / 寿命报告	意图画像、猛骑提示
倾斜 + 转弯半径	`attitude_turn_analysis.py`	转弯与危险倾斜
轨迹回放	traj-store / 本地 ulog	报告配图，不进评分

预研禁止从零再写一套「电流均值」「油门次数」。

4. 预研产品场景（用现有日志就能开跑）

下面五条是产品场景，不是算法作业。每条都带：用户价值、输入字段、输出、成功标准、失败时怎么办。

S1 滑后 60 秒：这次到底怎么飞的

用户：上岸打开 App，看到「飞起来了 / 飞得很晃 / 油门太死」和一条下次只改的动作。

输入：单航次 OSS + TLA 摘要 +（可选）v3 真飞标记。

输出：主问题键、一个建议键、安全键（可空）、三段时间轴（离水 / 巡航 / 收油）。

成功：10 个内部或友好用户里，≥7 人说「说的是我这次」。
失败：改词典和切段，不上大模型，不改 App 大页。

这是唯一必须打穿的预研场景。其它都为它服务。

S2 油门–结果因果：手和板是不是同一件事

用户：理解「我加了油，板晚了 / 电流先炸 / 头先抬」。

输入：throttleLeverQuantity 与 hourSpeed / electricCurrent / attitude.pitch 的互相关和滞后。

输出：典型滞后秒数、是否「油门抖、速度不抖」（手忙）或「油门死、电流高」（捏死）。

成功：能复现寿命报告里已有的现象——扣着时间 63%、满油门占损伤一半——并翻译成教练话。
失败：采样过稀则只出会话级分布，不出毫秒级手感。

这是对 HeyGo 的结构性优势，预研必须做成样例，而不是 PPT。

S3 转弯与姿态：干净弯 vs 飘 vs 疑似危险

用户：知道自己弯是「立住了」还是「靠油门硬掰」。

输入：复用 attitude_turn_analysis.py（半径、倾角、移动中大倾角）。

输出：急弯次数、稳健倾角、是否在弯中补大油。

成功：与人工看轨迹回放的「这个弯狠/稳」一致率可报。
失败：姿态脏点高则降级为「只报 GPS 曲率，倾斜仅作参考」。

S4 安全教练：这次有没有在伤人或伤机

用户：被提醒「油门顶太久」「接近失控码」「电池/电机过热」，而不是只看到奖章。

输入：TLA 故障、堵转分数、过压点、超温、满油门保载比。

输出：最多一条安全提示；严重越界时主问题强制让路给安全。

成功：内部品质/结构看了不觉得和 CAPA 口径打架。
失败：和故障口径冲突则教练侧只引用 TLA 键，不自造严重度。

这一条是原规划几乎没写、按我们形态必须有的。没有它，教练是玩具。

S5 水平分层：我是新手水中滑、还是真的在飞

用户：报告不会用职业骑手的尺子打新手。

输入：v3 连续航段、最高速、航时、油门谱；键用 remote_sn。

输出：水平档（未起飞 / 能飞不稳 / 能巡航 / 猛骑），个体基线用同档近 N 次。

成功：1,618 条真飞和明显未起飞能分开，且不把经销试板当成「这个人退步了」。
失败：匿名航次只出当次结论，不出「你比上周差」。

5. 终态产品形态

5.1 终态不是 HeyGo-on-water

维度	HeyGo 式终态（原规划）	JetWave 终态（本方案）
硬件	夹具 + 耳机是产品	板和遥控器就是产品；手表/耳机是附件
主场景	滑行中一句话	上岸后一次说清；航中只在安全必要时出声
数据护城河	百万弯的姿态	意图×响应×越界的电驱因果，外加故障与寿命
对内	弱	与品质、研发、租赁同一条航次结论
教学单元	弯	离水 / 巡航 / 转弯 / 收油 / 越界
实时	核心差异	有门禁的增强，不是身份

5.2 终态用户能看见的三层

层 A · 每次航次（所有已联网用户）

60 秒滑后：主问题、一次改进、安全（可空）
轨迹回放上标出三段和越界点
和自己近 8 次比，不和全球排行榜比（避免猛骑被奖励）

层 B · 一个季节（活跃用户）

水平档移动：未起飞 → 能飞 → 巡航稳
油门习惯是否在伤扳机 / 电池（翻译成人话，不暴露台架次数）
可选：教练或经销看同一份，用来安排课

层 C · 航中（终态可选）

只允许 4 类话：抬头、收油、稳住、停（故障）
规则在端上；不上云推理
默认关，用户打开；租赁车队可强制安全音

5.3 终态系统形态

        ┌──────── App / 租赁平板 / 客服后台 ────────┐
        │  只读：话术键、三段、回放、水平档           │
        └──────────────────▲────────────────────────┘
                           │ Coach API
        ┌──────────────────┴────────────────────────┐
        │  coach_session（旁路，trajectory_id 1:1）   │
        │  切段 · 特征 · 键 · 版本 · 金标准对拍       │
        └──────────────────▲────────────────────────┘
         只读 TLA / JUA / OSS
        ┌──────────────────┴────────────────────────┐
        │  已有：history · OSS · TLA · 工况 · 寿命    │
        └────────────────────────────────────────────┘

没有第四条「教练专用数仓」。没有平行采集。

5.4 终态能力地图（按依赖，不按月份幻想）

已有日志卫生 ──► S1 滑后主问题 ──► App 一页
       │                │
       ├─ S2 油门因果 ──┤
       ├─ S3 转弯姿态 ──┤
       ├─ S4 安全通道 ──┘
       └─ S5 水平档 ──► 季节成长 ──► 租赁/教练 B2B
                              │
                    滑后被信任一个旺季
                              │
                    才允许层 C 航中四字

原规划 Phase 2 的实时、Phase 4 的课程市场，在本图里都是右上角，不是主干。

6. 路线：预研 → MVP → 终态

不采用原规划「3/6/12/18 个月」的滑雪复制表。按证据门推进。

阶段	时间（建议）	交付	开门条件
P0 预研	4 周	本地 500 航切段 + 200 标签 + 30 份可读报告；本文五场景各有样例	现缓存 OSS 可复算
P1 滑后 MVP	P0 开门后 8–10 周	Coach 旁路表 + App/后台一页；只出 S1+S4	主问题一致率达标；与 TLA 口径不冲突
P2 双轨	一个旺季内	S2/S3/S5 入页；SN 基线；租赁只读看板	P1 周活使用滑后页，且误报可追溯
P3 航中	P2 后	端上四字安全/姿态提示	见 2.2 门禁
P4 生态	有偿需求出现后	教练标注工具、课程、B2B API	词典已稳定，不是用社区补算法

P0 四周任务（可执行）

冻结动作单元和话术键表（产品 + 一名真教练）。
把切段和 S1–S5 做成一条本地命令，主键 trajectory_id。
出字段卫生报告：attitude 脏点率、水深有无、采样间隔。
200 条六标签；公布规则 vs 人的混淆矩阵。
决定「要不要提水深/高频 IMU」——只允许用第 3 步的缺口提，不允许用对标 HeyGo 提。

团队不需要原规划 6–8 人起步。P0：产品 0.5 + 懂现日志的工程 1 + 能标的教练/资深骑手 1（兼职）。P1 再加 App。

7. 指标、风险、口径

7.1 预研 / MVP 指标（可测）

指标	门槛	不要用的替代
主问题 vs 人工一致率	≥70%（六标签里「总体 / 主问题」）	NPS、DAU（太早）
安全键与 TLA 冲突率	0（冲突则只显示 TLA）	自建严重度
单航复算	一键出与报告相同的键	聊天里「感觉对」
姿态脏点误报翻板	金标准上假阳性可控	广告「≤3°」
滑后页打开率（P1）	有航次的用户当周 ≥40% 打开过一次	日活游戏化

原规划 DAU/MAU>30%、NPS>40 留到 P2 再看。P0 看一致率。

7.2 主要风险（按我们形态重写）

风险	为何比原规划更真实	处理
1 Hz 不够做「暗数据」	回传不是机内 100 Hz	滑后用 1 Hz；要暗数据再立项机内存储
姿态跳变	已有分析	稳健统计 + 金标准
一半无用户 ID	基线对不准人	SN 键；账号绑定后合并
教练话术与故障口径打架	0x400000 等已有语义战争	安全键只引用 TLA
奖励猛骑	排行榜会鼓励顶油门	终态不做全球速度榜；猛骑走安全通道
大模型胡写建议	水上安全	L4 只渲词，不判分
做成新硬件项目	抄 HeyGo	P0 禁止硬件范围

7.3 口径（按这个讲，不要改回去）

教练是现有航次日志的产品层，不是新品类硬件。
预研只使用本地已缓存日志和已有脚本，主张必须可复算。
动作单元是离水 / 巡航 / 转弯 / 收油 / 越界，不是滑雪的「弯」。
油门是意图，不是噪声。
风浪落水、头字段均速、空的水深，不进第一版特征。
实时语音有门禁；没有滑后信任，就没有航中说话。
安全与技能同一条航次、同一主键；安全与 TLA 冲突时听 TLA。
商店式对标（HeyGo 夹具、100 项指标、18 个月课程市场）不是设计原点。

8. 和目标文档怎么分工

文档	职责
`JetWave AI 智能教练产品规划与方案论证.md`	品类机会、HeyGo 调研、为什么 eFoil 值得做教练
本文	在 JetWave 已有板、遥控、日志、TLA、工况、油门寿命上，教练预研什么、终态长什么样、什么先不做

目标文档继续回答「值不值得做」。本文回答「用我们现在的东西，做成什么样才算我们的产品」。

复算与后续实现入口（P0 落地时建）：analysis/tools/coach_session.py（待建，主键 trajectory_id）。
已有可直接调用：analysis/attitude_turn_analysis.py、tla/session_analyzer.py、电流工况 v3、analysis/tools/throttle_profile.py。