EdgeHippo · MVP 产品设计与软件开发任务书

修订说明（v1.0 → v1.1 → v1.2）

本版针对三条反馈做了修订，其中第一条的结论与直觉相反：OTA 对容量的影响不是「要不要」的问题，而是「槽开多大」的问题。

v1.1 → v1.2 修订（方案 C 专项评估）

一、执行摘要：三条硬发现与产品定义

1.1 产品定义（一句话）

1.2 与战略报告的对应关系

二、MVP 边界：做什么 / 明确不做什么

2.1 MVP 验收总判据（Go/No-Go ①）

三、硬件基线：双板分工与容量实测口径

3.1 双板分工（沿用现有资产，不新增硬件）

3.2 容量实测口径（按现状分区表重算，替换报告第 6 章推算值）

v1.1 注：下表是按现状分区表（app 槽 4 MB / 2.94 MB）算出的保守值。按 3.5 节方案 B 压缩 app 槽后，实际档位应上修为 N16R8 ≈ 12,900 条、N8R8 ≈ 3,700 条（均为推算、未实测），后续章节的容量数字以方案 B 为准。
v1.2 补注（W0-05 已执行）：按新几何重算的权威值为 N16R8 ≈ 14,448 条、N8R8 ≈ 3,419 条（同为推算、未实测，口径 rec_pages×4080×85%/644）；本表（0x810000 / 0x5F0000）为改分区表之前的历史账，已不再适用。

单条记忆成本：int8 向量 384 B + HNSW 链接(M=16) 128 B + 摘要 ≤150 B = 662 B；页/索引/元数据开销按 12% 计。

v1.2 修订（实测）：app 镜像实测 edgehippom-<board>-<ver>.bin = 1,530,080 B（1.459 MiB），merged-devkit-16m.bin = 1,595,616 B。v1.1 假设「裁剪 cam/mic/gps 后降至 ~1.1 MB」不成立——按 .map 逐段统计，可裁剪部分仅约 120 KB（esp32-camera 83.7 KB + I2S 驱动 31.1 KB + cam/mic/gps 三个自有模块 8.4 KB），裁剪后约 1.34 MiB；MVP 还要新增 TinyUSB 与 emlite，完整态预计 ≈1.45 MiB。因此 app 槽下限应为 2 MB（余量 ≈38%），1.5 MB 槽不可行。详见 3.5.7 节。

3.3 碎片容量规划（由此倒推叙事）

3.4 引脚分配（MVP）

3.5 OTA 与分区决策（v1.1 新增 / v1.2 修订）

3.5.1 分区账怎么算

Flash 可用空间 = 总容量 − 头部（bootloader 0x0 + 分区表 0x8000 + nvs + otadata = 0x10000）− 尾部余量（0x10000）。
换算系数：1 MB edgehippom ≈ 1,227 条（推算、未实测）（662 B/条含 12% 开销 → 752 B/条）。时序区按 N16R8 = 1.375 MB、N8R8 = 0.875 MB 预留。

3.5.2 N16R8（板 B，16 MB）四种方案

OTA 的真实净代价 = B vs D = 2,400 条（−15.7%）。而 B 相对现状 A 的收益是 +4,900 条（+61%）。也就是说：容量问题 87% 来自槽开大了，只有 13% 来自 OTA 本身。

推算口径说明（2026-10-28）：上表「容量」列为 推算值、未实测（记忆库 MB × 1,227 条/MB）。W0-05 执行后按 rec_pages × 4080 × 85% / 644 重算，方案 B 的权威值应为 14,448 条；与表内 12,900 条的差异来自 ADR-015 压缩时序区后记录区占比提高，本表尚未按新几何重算——以本节开头的 v1.2 补注为准。

3.5.3 N8R8（板 A，8 MB）四种方案

推算口径说明（2026-10-28）：上表「容量」列为 推算值、未实测。方案 B 的权威值应为 3,419 条（rec_pages × 4080 × 85% / 644）；表内 3,700 条为 v1.1 旧推算，尚未按新几何重算——以本节开头的 v1.2 补注为准。

3.5.4 推荐分区表（可直接替换）

# partitions_emgw_16m.csv —— v1.1 方案 B（N16R8）
nvs,        data, nvs,     0x9000,    0x5000,
otadata,    data, ota,     0xe000,    0x2000,
app0,       app,  ota_0,   0x10000,   0x200000,
app1,       app,  ota_1,   0x210000,  0x200000,
edgehippom, data, 0x42,    0x410000,  0xBE0000,
#  0x410000 + 0xBE0000 = 0xFF0000，尾部留 64 KB 余量
#  edgehippom subtype = 0x42（旧 edgemem/kb_static 的 0x40/0x41 已废止）
#  稳态容量约 14,448 条（rec_pages 2,683 × 4080 × 85% / 644）—— 推算、未实测

# partitions_emgw.csv —— v1.1 方案 B（N8R8）
nvs,        data, nvs,     0x9000,    0x5000,
otadata,    data, ota,     0xe000,    0x2000,
app0,       app,  ota_0,   0x10000,   0x200000,
app1,       app,  ota_1,   0x210000,  0x200000,
edgehippom, data, 0x42,    0x410000,  0x3E0000,
#  0x410000 + 0x3E0000 = 0x7F0000，尾部留 64 KB 余量
#  edgehippom subtype = 0x42（旧 edgemem/kb_static 的 0x40/0x41 已废止）
#  稳态容量约 3,419 条（rec_pages 635 × 4080 × 85% / 644）—— 推算、未实测

3.5.5 三条必须知道的配套事实

3.5.6 决策与执行

3.5.7 方案 C 专项评估（v1.2 新增）

v1.1 把方案 C 标为「激进但可行」，理由是「裁剪后固件约 1.2 MB，1.5 MB 槽余量 0.3 MB」。这个 1.2 MB 是估的，v1.2 用实机 .map 把它测出来了，结论相反。

实测：裁剪 cam/mic/gps 到底能省多少

数据源：C:\emgw-build\fw_ascii\build_devkit_16m\edgehippom-<board>-<ver>.map（devkit/16m 变体，逐段统计 .text + .rodata + .dram）。

对比参照：cli_json.c 一个文件就 13.8 KB，link_mgr.c 10.3 KB。真正的 flash 大头是 WiFi/BLE/mbedTLS（libnet80211、libbtdm_app、psa_crypto 等都在 20–57 KB 量级），这些 MVP 一样也砍不掉。

MVP 完整态固件尺寸预算

三个方案按实测重算

四、软件架构：五层 + 双后端引擎 HAL

4.1 分层

L4  接口层   usb_cdc(行协议)  usb_msc(拖拽灌库)  ble(link_mgr)  mcp_shim  http(仅灌库/OTA)
L3  策略层   EdgeMemory：生命周期(工作/短期/长期) / 遗忘淘汰 / 冲突消解 / 去重 / 重要性
L2  引擎层   EM Engine HAL  ← 单一真源接口，两套可替换后端
               ├─ emdb   : eXtremeDB 后端（目标形态，授权到位后启用）
               └─ emlite : 自研 flash-backed HNSW + 列式时序环 + WAL（P0 立即可用）
L1  存储层   edgehippom 分区 / PSRAM cache / 页管理 / CRC32 / 磨损均衡
L0  平台层   ESP-IDF v6.1 + FreeRTOS + TinyUSB + NimBLE

4.2 引擎 HAL 接口（em_engine.h，单一真源）

/* 生命周期 */
em_err_t em_open (const em_cfg_t *cfg, em_db_t **out);
em_err_t em_close(em_db_t *db);

/* 事务 */
em_err_t em_txn_begin (em_db_t *db);
em_err_t em_txn_commit(em_db_t *db);      /* 掉电安全：要么全见，要么全不见 */
em_err_t em_txn_abort (em_db_t *db);

/* 记忆条目 */
em_err_t em_mem_put   (em_db_t *db, const em_mem_t *m, uint64_t *id);
em_err_t em_mem_get   (em_db_t *db, uint64_t id, em_mem_t *out);
em_err_t em_mem_del   (em_db_t *db, uint64_t id);

/* 混合查询：向量 + 精确条件 + 时间范围，同一事务 */
em_err_t em_query(em_db_t *db, const em_query_t *q, em_hit_t *hits,
                  size_t max_hits, size_t *n_out);
/*  em_query_t {
      const int8_t *vec;      uint16_t dim;      /* 宿主提供，板侧不 embedding */
      uint16_t topk;          uint16_t ef_search;
      uint16_t frag_mask;     /* 限定碎片 */
      uint32_t t0, t1;        /* 时间范围（时序/记忆共用） */
      uint16_t dev_id;        uint8_t  level;    /* 精确条件 */
      float    min_salience;
    } */

/* 时序 */
em_err_t em_ts_append(em_db_t *db, uint16_t dev_id, uint8_t ch, uint32_t ts, float v);
em_err_t em_ts_agg   (em_db_t *db, uint32_t win_ms);   /* L0 → L1 分钟聚合 */

/* 碎片 */
em_err_t em_frag_install(em_db_t *db, const char *path);  /* 灌库 */
em_err_t em_frag_list   (em_db_t *db, em_frag_t *out, size_t *n);
em_err_t em_frag_remove (em_db_t *db, uint16_t frag_id);

/* 运维 */
em_err_t em_stat(em_db_t *db, em_stat_t *out);   /* 条数/字节/RAM峰值/命中率 */
em_err_t em_gc  (em_db_t *db, float water_mark); /* 遗忘淘汰 */

emdb 与 emlite 必须同时通过上述同一组接口的一致性测试（W1-08），否则 HAL 形同虚设。

4.3 目录结构（在现有 fw_ascii 上增量，不推倒重来）

main/
├── app_main.c            (现有，改：形态标识 form；旧 role 已废止)
├── em_engine.h           ★ 新增：HAL 接口单一真源
├── em_engine_lite.c      ★ 新增：emlite 后端（页管理 + HNSW + 时序环 + WAL）
├── em_engine_db.c        ★ 新增：emdb 后端（eXtremeDB，授权到位后填）
├── em_ann.c              ★ 新增：int8 距离核 + HNSW 遍历 + IVF 粗划分
├── em_ts.c               ★ 新增：列式时序 L0/L1/L2
├── em_wal.c              ★ 新增：事务日志与崩溃恢复
├── em_mem.c              ★ 新增：策略层（生命周期/遗忘/去重/重要性）
├── em_frag.c             ★ 新增：.emf 碎片包解析、校验、安装
├── em_mcp.c              ★ 新增：MCP shim
├── usb_dev.c             ★ 新增：TinyUSB 复合设备 CDC+MSC
├── usb_msc_disk.c        ★ 新增：虚拟 U 盘 + 拖拽灌库
├── em_store.c            (现有，改造：底层改用 em_engine，保留 store.map 诊断)
├── cli_json.c            (现有，扩展：mem.* / frag.* / ts.* / ann.* 命令)
├── link_mgr.c            (现有，复用：板间 BLE 互联与碎片接力)
├── led_mgr.c wifi_mgr.c ble_mgr.c ota_mgr.c kb_ota.c http_srv.c   (保留)
└── cam_mgr.c mic_mgr.c gps_mgr.c  (MVP 裁剪：Kconfig 控制，默认 n)

4.4 eXtremeDB 优势保留矩阵（v1.1 新增）

emlite 先行不代表可以随便写一个「能跑就行」的向量检索——那样到替换时等于重写一遍。本节把 eXtremeDB 的公开能力逐条映射为 emlite 的设计约束与验收点，确保替换前后行为语义一致、性能特征连续。以下能力描述均取自 McObject 官方技术规格页、Steve Graves 技术文章与 Andrei Gorine 的公开发表材料（见修订说明中的来源清单）。

4.4.1 先锁定三条来自 Andrei Gorine 的硬约束

4.4.2 优势保留矩阵（14 项）

4.4.3 emlite 的自有硬指标（三个不可退让的数字）

这三个数字同时是「替换收益」的度量基线：接入 emdb 后重测同一组指标，差值即为授权谈判中值得付出的溢价。

4.4.4 一个值得抄的工程做法：flash 仿真层

4.4.5 替换验收清单（W1-13 的细化）

五、数据模型：schema 草案

用统一的 schema 语言描述，emdb 后端直接编译成 eXtremeDB DDL，emlite 后端映射为等价 C 结构体 + 定长页布局。两份定义必须同源同构——这是报告第 7.1 节「模式统一」原则的工程落实，避免 PC 侧打包器与板侧布局漂移。

5.1 记忆表 Memory（核心）

class Memory {
    uint64   id;               /* 全局唯一，单调递增 */
    uint32   ts_ms;            /* 创建时间 */
    uint16   frag_id;          /* 所属碎片包 —— 物理接力与卸载的最小单位 */
    uint8    level;            /* 0=工作记忆 1=短期 2=长期 */
    uint8    src;              /* 来源：0灌库 1时序闭环 2宿主写入 3接力 */
    float    salience;         /* 重要性 0..1，遗忘淘汰的输入 */
    uint32   access_cnt;       /* 命中次数 */
    uint32   last_access_ms;   /* 最近命中，LRU 输入 */
    uint16   dev_id;           /* 关联设备（精确条件） */
    uint16   tags;             /* 标签位图（精确条件） */
    char     payload[150];     /* 摘要正文，UTF-8，硬上限 150 B */
    vector<int8, 384> emb;     /* int8 量化向量 */

    unique tree<uint64>            pk;
    tree<uint16, uint64>           by_frag;
    tree<float, uint64>            by_salience;
    tree<uint32, uint64>           by_time;
    ann<cosine, 384>               ann_idx;   /* HNSW，M=16，ef_construct=200 */
};

5.2 时序三表（闭环的物理载体）

class Sample {                 /* L0 原始：环形，必然被覆盖 */
    uint64 id;  uint32 ts_ms;  uint16 dev_id;  uint8 ch;  float val;
    unique tree<uint64> pk;    tree<uint32, uint64> by_time;
};
class Window {                 /* L1 分钟聚合：趋势追溯、合规留痕 */
    uint64 id;  uint32 win_start;  uint16 dev_id;
    float  min[16], max[16], mean[16], rms[16];
    unique tree<uint64> pk;    tree<uint32, uint64> by_time;
};
class Pattern {                /* L2 特征向量：闭环产物，长期资产 */
    uint64 id;  uint32 win_start;  uint16 dev_id;  uint8 label;
    float  confidence;
    vector<int8, 384> emb;
    uint64 src_win_id;         /* ★ 可回溯到产生它的那段时序 */
    ann<cosine, 384> ann_idx;
    unique tree<uint64> pk;    tree<uint32, uint64> by_time;
};

src_win_id 这一列是整个方案的技术内核：ANN 命中后能直接回溯到生成它的那一段传感器历史——这正是 McObject 官方文章给出的路径终点，也是「记忆」区别于「硬盘」的地方。

5.3 碎片表 Fragment 与账本

class Fragment {
    uint16 frag_id;   char  name[24];   uint32 version;
    uint32 count;     uint32 bytes;     uint32 crc32;
    uint8  sig[64];                    /* 来源签名（离线可验签） */
    uint32 install_ms;  uint8 state;   /* 0安装中 1就绪 2损坏 3卸载中 */
    unique tree<uint16> pk;
};

5.4 .emf 碎片包结构（与 schema 同源）

memory-fragment.emf            一个自洽、可离线验证的记忆单元
├── manifest.json              schema 版本 / 条数 / 维度 / 量化方式 / 领域标签 / 时间范围
├── vectors.bin                int8 向量，【按 IVF 簇顺序排列】
├── graph.bin                  HNSW 链接，离线构建，已优化落盘顺序
├── payload.bin                每条 ≤150 B 摘要（可选加密）
├── timeseries.bin             附带的时序特征历史（可选）
└── signature                  来源签名 + CRC32（离线可验签）

5.5 三级留存策略（遗忘机制的物理实现）

这组对比同时回答三个常被追问的问题：为什么不上云、为什么能长期学习、以及「记忆」和「硬盘」的区别是什么（硬盘什么都留，记忆会挑）。

5.6 修正：L0 不落 flash，L2 靠去重收敛（Flash 预算分配）

量产平衡方案（时序权重更高时）：记忆 5.0 MB（≈6,300 条）/ L1 1.2 MB（≈54 天）/ L2 1.2 MB（≈2,100 条）/ 取证 0.4 MB。各区大小应为 Kconfig 可配，不由代码写死。

5.7 计算分层（明确每一层算力从哪来）

六、软件开发任务总表（WBS）

共 7 个工作包（WP0–WP6）、51 项任务。优先级：P0 阻塞P1 主路径P2 增强。人日为单人估算（含自测），未含评审与返工缓冲（建议按 ×1.3 计）。

WP0 · 基建与基线（Board Bring-up）先做，建立信心

战略报告提示：USB 复合设备有两个官方示例可参考，风险最低，应最先做。本工作包先把它前面的路铺平。

WP1 · 引擎层（EM Engine HAL）核心，最长

WP2 · 策略层（EdgeMemory）差异化所在

ObjectBox 核心数据库免费，纯「嵌入式向量库」会撞上免费壁垒。差异必须建立在策略层——遗忘、冲突消解、闭环回写，这些是需要真实长期运行才能调对的东西。

六、软件开发任务总表（WBS）· 续

WP3 · 接口层产品感知面

WP4 · 时序闭环（场景侧）技术内核

WP5 · PC / Hub 工具链决定 UX 成败

WP6 · 测试与验收Go/No-Go 唯一依据

6.2 合成数据源规格（v1.1 新增：MVP 不接传感器）

/* 命令接口 */
{"cmd":"ts.inject","args":{"ch_mask":7,"rate_hz":4000,"seed":12345,
                           "fault":"bpfo","severity":0.6,"dur_s":30}}
/* 同一 seed + 同一参数 ⇒ 任何一块板上产出完全一致的字节流 */

{"cmd":"ts.script","args":{"file":"s1_scenario.json"}}   /* 按脚本跑完整场景 */

6.3 工时汇总

单人全职约 12–13 个月；2 人并行（固件 1 + 工具链 1）约 6.5 个月，与战略报告 P0（M1–M4）+ P1（M5–M9）的节奏基本吻合。若只做 Go/No-Go ① 所需的最小集（WP0 + W1-01…W1-11 + W3-01/02 + W5-01/02/05 + W6-03），约 130 人日，2 人约 3 个月可拿到第一个实测结论。
v1.1 变化：去掉传感器让 MVP 减少 2 人日，但真实采集验证（W4-07）移入 P2，含 P2 总量 +3 人日。

七、场景 S1｜工业设备振动故障指纹库（时序主导 · α 形态）

7.1 数据规格

7.2 知识库碎片构成（灌入板 B）

7.3 典型查询与闭环

Q1  纯相似      vec=<当前10s窗口特征>, topk=5
                → 返回最相似的 5 个历史状态 + 每个的 src_win_id

Q2  混合查询    vec=<当前特征>, dev_id=2, t0=30天前, t1=now, topk=10
                → 「这台设备、最近一个月内，最相似的 10 个状态」★ 核心卖点

Q3  条件过滤    vec=<当前特征>, tags=温度过高, min_salience=0.6, topk=5
                → 相似度与精确条件在同一事务内完成

闭环  检出异常 → 人工确认为「螺杆磨损」→ 回写为新指纹（level=2, salience=0.9）
      → 30 天后同类特征再次出现时，Q1 应能直接命中该指纹

7.4 场景级判据

• 召回：注入 8 类故障各 20 个测试样本，已知故障类型的 top-1 命中率 ≥ 85%；top-5 ≥ 95%
• 误报：稳态正常工况下，被判定为「新颖/异常」（相似度低于阈值）的比例 ≤ 5%
• 闭环有效性：人工确认后回写的指纹，在后续同类样本中可被命中（这是闭环成立的唯一证据）
• 可回溯：任一条 ANN 命中都能通过 src_win_id 取回产生它的那段时序区间并绘图

八、场景 S2｜野外巡检记忆包与物理接力（断网 · β 形态）

8.1 数据规格

8.2 知识库碎片构成

8.3 三种接力的完整演示路径

① 物理接力   专家带着板 A（装着 expert-zhang-v1）到现场
              → 拔下 → 插到巡检员的设备上 → 巡检员的宿主立刻获得老张的经验
              → 最低信任成本，最难被软件复制

② 近场接力   板 A 与板 B 通过 BLE 点对点传输 expert-zhang-v1（1.35 MB）
              → 传输的是几百 KB 的自洽产物，不是 GB 级模型权重
              → 接收方【离线验签】通过后合并入库

③ Hub 中继   回办公室后板 B 插 USB → 同步到 Hub
              → Hub 汇总全天新增记录 → 构建新版 defect-v2 → 次日批量下发全班组

8.4 典型查询

Q1  vec=<"拱顶渗水伴有白色析出物">, topk=5
    → 命中历史缺陷记录 + 老张经验中的相关条目

Q2  vec=<"渗水">, site_id=K12+300, t0=2024-01-01, t1=now, topk=10
    → 「这个点位历史上出过几次同类问题，怎么处置的」

Q3  纯条件（无向量）  site_id=K12+300, tags=结构类, topk=20
    → 验证精确条件路径不依赖 embedding 也能工作

8.5 场景级判据

• 断网可用性：Wi-Fi 与 BLE 全关（仅 USB 供电）时，Q1–Q3 全部可答，延迟与联网时一致（±5%）
• 接力完整性：BLE 传输 1.35 MB 专家包后，接收方条数、CRC、抽样检索结果与发送方一致
• 离线验签：篡改 1 字节的包必须被拒绝；无网状态下也能拒绝（这是物理接力成立的前提）
• 换班连续性：模拟换班（板 B 拔下 → 插入另一台宿主），新宿主检索结果与原宿主一致

九、场景 S3｜专业私域知识库（纯语义 · 首销 SKU 定价锚）

9.1 知识库碎片构成（压满容量，用于验证 G1）

v1.1 更新：按 3.5 节方案 B，N16R8 记忆库 ≈ 14,448 条（推算、未实测），故 S3 的满载规模从 8,000 条上调到 12,000 条（占记忆库约 83%，推算）。这是唯一能把容量压到判据线附近的场景。

9.2 灌库与查询路径（全部离线）

灌库   ① PC 侧：docs/ → 切块 → embedding(384d) → IVF聚簇 → HNSW构图 → 顺序布局 → .emf
       ② 拖 .emf 进虚拟 U 盘 → 板侧校验 → 合并 → STATUS.TXT 回写结果
       ③ 全程无外网，可在飞行模式的笔记本上完成

查询   MCP 客户端（或 Host SDK）
       → 宿主侧算查询向量
       → CDC/MCP 下发 {"cmd":"mem.query","args":{"vec":[...],"topk":5}}
       → 板侧返回命中的 payload 摘要 + 相似度 + frag_id
       → 宿主用摘要组装 prompt（原文留在 PC 侧，板侧只存 150 B 摘要）

9.3 典型查询与特殊用例

Q1  常规      vec=<"eXtremeDB 的 ANN 索引支持哪些距离度量">, topk=5
Q2  碎片限定  vec=<"上周关于定价的结论">, frag_id=2, topk=5
Q3  ★冲突消解  vec=<"我们的目标客户是谁">, topk=5
              预期：返回最新结论，且【能指出存在被推翻的旧结论】
              —— 这是策略层相比纯向量库最直观的差异
Q4  去重      灌入 500 条含 100 条近重复的笔记 → 库内重复率应显著下降
Q5  卸载      frag.remove(1) 后，剩余 2,000 条仍可正常检索（碎片自洽性验证）

9.4 场景级判据

• 满载可用：12,000 条装载后，P50/P99 仍满足 G2（这是 G1 与 G2 的联合验证点）
• 断网：笔记本飞行模式下完成灌库与查询全流程
• 冲突消解：Q3 能正确返回最新结论并标记旧结论；不能返回互相矛盾的两条却不加区分
• 碎片自洽：单独卸载任一碎片后，其余碎片功能完全不受影响
• 定价锚：完成 30 人的可用性观察，记录「愿意为这个能力付多少钱」的分布（输入战略报告待验证项 4）

9.5 三场景能力覆盖对照（证明「器官」可跨行业复用）

十、测试用例集

共 52 条用例：核心 TC-C-* 8 条、碎片/灌库 TC-F-* 8 条、场景各 8 条（S1/S2/S3）、非功能 TC-N-* 12 条（v1.1 新增 TC-N-11 footprint 基线、TC-N-12 abort 可预测性）。用例列：前置 → 步骤 → 预期。

10.1 核心引擎（TC-C）

10.2 碎片与灌库（TC-F）

10.3 场景 S1（TC-S1）

10.4 场景 S2（TC-S2）

10.5 场景 S3（TC-S3）

10.6 非功能测试（TC-N，直接对应 Go/No-Go ①）

十一、里程碑、Go/No-Go 与执行顺序

11.1 Go/No-Go ① 的处置规则

11.2 与战略报告路线图的对齐

本任务书覆盖战略报告的 P0（M1–M4 技术闭环验证）并延伸到 P1 前半段。P0 出口即本任务书 M9。差异在于：战略报告 P0 只有 4 个月，本任务书按 2 人并行估到约 5 个月（22 周）——多出的部分主要是双后端 HAL 的额外工作量（W1-12/13 的 16 人日）与三场景语料构建（8 人日）。若授权提前到位且只验证一个场景，可压缩回 4 个月。

十二、风险登记与已知工程坑

12.1 风险登记册

12.2 已知工程坑清单（本项目实战积累，MVP 必须遵守）

12.3 下一步的四个动作（本周可做，零成本）