动态

场景：PR #1（lc_power_shield → main，STM32F030 多通道 ADC 采样 / 功耗测量）开好后，zephyr_rtos_ci 发起 REQUEST_REVIEW，评审机器人 ai-review-bot 在 25 分钟内把报告直接贴回 PR 讨论区（COMMENT，5775 字）。结论是可合入，但没有一句「看起来不错」：1 条 MINOR 落到 Kconfig:4、3 条 INFO 落到具体行号，另外把 7 个非 C 文件与 7 条机器给不了结论的问题单独列出来交给评审人——这比「AI 说没问题」有用得多。

提交者开 PR #1（20 个文件）        https://zephyrrtos.cn:3000/zephyrrtos_china/zephyr/pulls/1
  │  zephyr_rtos_ci 发起 REQUEST_REVIEW
  ▼
ai-review-bot（zephyrrtos.cn 评审引擎 · 规则 40 条 + tree-sitter 结构/复杂度）
  │  取 refs/pull/1/head，与 origin/main 做 diff；基于完整文件，存量问题也报
  ▼
在 PR 上以 COMMENT 形式发布报告（5775 字 · 固定六段）
  ├─① 结论：可合入 · MAJOR 0 / MINOR 1 / INFO 3
  ├─② 问题清单：文件:行 + 规则 ID + 置信度 + 判据 + 建议
  ├─③ 结构分析：main() CC=14 · SLOC=66 · 嵌套 4 · 调用 23
  ├─④ 机器检查：本次未跑上游 checkpatch（显式写明，不假装跑过）
  ├─⑤ 未验证 / 需人工确认：7 个 .overlay/.yaml + 7 条机器判不了的问题
  └─⑥ 规则覆盖：命中 3 条 / 已执行未命中 37 条
  ▼
人：按清单改 → 复跑 → 合入或拒绝（BLOCK 只能评审人给）

• MINOR · R-KCF-002 Kconfig:4 config SEQUENCE_SAMPLES 缺 help 说明（同类共 4 处：4/17/21/24）——判据是上游要求新符号必须有 help，缺了不能合入，用户也看不出开关干什么
• INFO · R-KCF-003 Kconfig:21 SEQUENCE_32BITS_REGISTERS 与 Kconfig:24 SHELL_ADC_PS 既无 depends on 也无 default/select：没有可见性/默认值的符号会出现在所有配置里，容易被误开
• INFO · R-KRN-003 src/main.c:31 可写 static vrefs_mv 被 3 个函数（defined / cmd_adc_status / main）使用，全文件没有 k_mutex/k_spinlock/atomic/irq_lock——volatile 只防优化，不防撕裂
• 结构分析给数字不给形容词：main.c 238 行 / 3 个函数；复杂度热点 main() CC=14、SLOC=66、嵌套 4、调用 23；并如实标注「语法树 2 个 ERROR 节点，函数数是下界」
• 诚实清单：6 个 .overlay + 1 个 sample.yaml 只做通用检查（未做规则扫描）；另列 7 条机器判不了的项目——设计意图、栈与实时性、优先级反转、性能预算、API 语义、版本兼容、测试证据，要求评审人逐项给结论

边界与用法：这是机器 + 启发式的评审，等级契约写在引擎里——机器规则最高 MAJOR、启发式一律降级 INFO「待人工确认」、BLOCK 只能评审人给；报告第 5 段固定列「未验证 / 需人工确认」，没有这段就说明报告没按契约出。想自己复现或对别的 commit/PR 跑一遍：把 Gitea 链接的 host 换成 /agent/api/r/ 即可（PR → /agent/api/r/zephyrrtos_china/zephyr/pull/1，?raw=1 取 Markdown）。目前 PR 评审只覆盖 zephyrrtos_china/zephyr；合入与否仍由人决定。

场景：提交者贴来一个 commit 链接、一个 PR 链接，或者直接把一段驱动代码丢过来问「这个能合入吗」。以前这活儿靠人读；现在把链接里的 zephyrrtos.cn:3000 换成 zephyrrtos.cn/agent/api/r，服务器自己去取这次改动的 PR 头 / commit，跑一遍评审引擎，回一份六段报告——不是「LLM 看着像有问题」，而是 40 条规则 + checkpatch + tree-sitter 结构/复杂度给出可核对的结论，每条都带规则 ID 与置信度。只读：不改仓库、不改 PR 状态。

你给：Gitea 链接（私有库也能给）
  │   https://zephyrrtos.cn:3000/zephyrrtos_china/zephyr/pulls/2
  ▼  换个前缀（host 后面的 path 原样保留）
  https://zephyrrtos.cn/agent/api/r/zephyrrtos_china/zephyr/pull/2
  │
  ▼ 服务器侧：用 Gitea 上的 refs/pull/<n>/head 取 PR 头（SSH 密钥只在服务器）
     commit 评审则直接取该 commit 与父提交的 diff
  │
  ▼ 与 origin/main 做 diff → 调评审引擎
     规则 40 条 · checkpatch · tree-sitter（结构 / 圈复杂度）· clang-format（可选）
  │
  ▼ 六段报告（HTML 页面；加 ?raw=1 拿 Markdown）
     1 结论（判定 + 等级计数）      4 未验证 / 需人工确认
     2 问题清单（文件:行 + 规则 ID） 5 规则覆盖（启用/命中/跳过）
     3 结构分析（复杂度热点）        6 机器检查（checkpatch 明细）

• 三个入口：提交 /agent/api/r/<owner>/<repo>/commit/<sha> · PR /agent/api/r/<owner>/<repo>/pull/<n> · 文件 /agent/api/r/<owner>/<repo>/src/<ref>/<path>；只给 sha 也能用短入口 /api/r/<sha> 自动反查仓库
• 实测（就在这条动态发布时跑的）：PR #2「gicv3 跳过 shared distributor init」→ 20 个文件、1497 增 5 删，报告 5 KB；PR #1「lc_power_shield」→ 11 KB 报告；commit 5e92f1c → 2 个文件 2.7 KB。全部 200
• 它抓到了什么：PR #2 上有一条 MINOR / R-UP-002 —— commit 标题 76 字符 > 72，Zephyr 的提交规范会因此判 CI 失败；报告还给了改法。这类「人肉容易漏、CI 会拦」的问题就是机器规则该负责的部分
• 等级契约写死在引擎里：机器规则最高 MAJOR；启发式（LLM 判断）一律降级 INFO「待人工确认」；BLOCK 只能由评审人确认后给出。报告第四段「未验证 / 需人工确认」是刚性要求——没有它就说明这份报告没按契约出
• 评审基于完整文件而不是只看 diff 片段：diff 模式会读被改文件的新版本，存量问题也报并标注「存量」；要更大上下文用 ?context=full&related=1

边界（先看这几条）：① PR 评审目前只对 zephyrrtos_china/zephyr 生效——它是在服务器上的 Zephyr 检出里做 diff，其它仓库会明确提示改用文件级评审；② PR 头是现取现评：refs/pull/<n>/head 拉不到就直接报错，不猜、不回退成「目录树」（本版顺手修掉了旧行为：把 PR 链接塞给 /api/gitea 曾静默回退成目录树，会给出误导结果）；③ 这些页面是公开只读的——任何人拿到 URL 都能看到该 commit/PR 的差异统计与评审报告，私有库正文不随页面整库下发；不想公开就别把 URL 发出去；④ 报告是机器 + 启发式结论，合入与否仍由人决定。

场景：一台 RK3588 主机（rock-5b-plus）用 USB 同时挂着两块 STM32F030F4P6——一块用片上 ADC 做 8 通道采样，一块外挂 ADS1256（8 通道 24 位）做高精度采样。这类双板环境真正难的从来不是写应用，而是三件事：能不能编译（工具链版本互相咬合）、能不能上板（两块板的烧写通道与控制台串口不能搞混）、装不装得下（16 KB flash 是硬约束）。这次最值钱的一条记录是：板 2 烧完完全没输出、也不报错——查下去是板子上没有焊 8 MHz HSE 晶振，而基础板 DTS 写着 &clk_hse status="okay"，于是时钟驱动在 set_up_fixed_clock_sources() 的 while (LL_RCC_HSE_IsReady() != 1) 里死等一颗不存在的晶体。

rock-5b-plus（开发主机）
  Zephyr 工作区 /mnt/raid1/shared/zephyrproject · .venv312（Python 3.12.14 · cmake 4.4.4 · ninja 1.13.2）· SDK arm-zephyr-eabi 14.3.0
  hwmap.yaml：板1 = stm32f030_demo     板2 = stm32f030_demo_no_hse
        │ west flash --dev-id 000069610657              │ west flash --dev-id 000069610517
        ▼                                               ▼
  板1 · stm32f030_demo                             板2 · stm32f030_demo_no_hse（无 HSE 晶振）
  ADC1 PA0–PA7 · 12 bit · ACQ 240 周期             外挂 ADS1256 · 8ch · 24 bit · vref 2.5 V
  丢首样本 → 均值 → adc_power_measure              SPI1 PA5/PA6/PA7 · CS PA4 · DRDY PA8 · RESET PB1 · SYNC PA3
  USART1 → J-Link VCP（ttyACM0）                   adc_sequence / ads1256_async（单线程内核）
        │                                           USART1 → CH340（ttyUSB0）
        ▼                                               │
  #CFG,ch=8,… / D,<ms>,<8 个原始码>                 ADC sequence reading / ADC input N value: X uv
        └───────────► 主机脚本 / twister 按协议解析、积分功耗 ◄───────────┘

• 没有晶振要建模成板级属性：新 `stm32f030_demo_no_hse` 变体把 &clk_hse 设为 disabled，PLL 改由 HSI 供（HSI 8 MHz → PLL 输入 HSI/2 = 4 MHz → mul = 12 → 48 MHz，与晶振版同频）；其余 SoC/UART 引脚/115200/runners 与基础板一致
• 单线程内核是两块板共用的底层改造：CONFIG_MULTITHREADING=n 时内核没有信号量/队列，而 ADC 与 SPI 驱动都要 k_sem_take → 链接失败。补齐 10 个 kernel/*_single.c（共 1451 行）并顺手修 spi_context.h 里对 Z_SEM_INITIALIZER 的无条件依赖。收益：adc_sequence 15596 B → 13340 B（81.42%）
• ADS1256 驱动 620 行（阻塞式 spi_transceive_dt）+ Kconfig + binding，接线全部归板 DTS；踩到一次 API 漂移：SPI_DT_SPEC_INST_GET(n, op, 0) 在当前 main 只接受 2 个参数（编译期直接报错）
• 「省空间开关」在两个版本上结论相反：旧分支有用的四个开关（SPI_STM32_INTERRUPT=n、NUM_PREEMPT_PRIORITIES=0、CORTEX_M_FAULT_FULL_PROCESS=n、MINIMAL_LIBC_LL_PRINTF=y）实测全部 16188 → 16188 B 空转——LTO 已把故障路径裁到 262 B。要再省只能砍功能，不是调开关
• 尺寸与字节构成：ads1256_async 16188 B（98.80%），只剩 196 B；按符号聚合 35.7% 是 STM32 驱动、27.1% 零散小符号、13.8% 内核+arch、12.8% ADC、7.5% libc/printk

验证与边界：烧写后用 J-Link 回读 flash 头部与本地镜像逐字节比对，两次都一致；两块板串口抓取都打通（板 2 的 0 uv 是因为 8 路输入真的接地）。已知限制：ADS1256 镜像只剩 196 B（1.2%），log 改单字符 printk 才装得下；RAM 还有余量（三个 1 KB 栈可减半，约能到 50%）；fault.c 裁剪那版基于旧上游、整份拿来会回退约 500 行新代码而收益接近零，明确不做；与内部 ADC 那条 lc_power_shield 分支是两条并行线，尚未合并。代码与文档在 zephyrrtos_china/zephyr 的 board-no-hse 分支（commit 5e92f1c，私有库需账号）；提交同样标了 Assisted-by: DSH with deepseek-v4-flash。

场景：要在一个只有 16 KB flash / 4 KB RAM 的 STM32F030F4P6 上做「8 通道 ADC 轮流采样 → 平均值 → 机器可读串口输出 → 主机按时间积分功耗」。这类活儿真正的难点不是「能不能跑」，而是两件事：放不放得下（余量只有 8.7%，加一个 log 级别就溢出 784 B）、以及数字可不可信（首样本偏低约 980 码、buffer 位宽错配会读出天文数字且不报错）。本分支把每个取舍都称过重：不是「应该能放下」，而是把 flash 用到 91.31% 时还算得清每个字节从哪来。

  PA0..PA7 ──▶ ADC1（8 rank 序列 · 12 bit · ACQ = 240 周期）
                 │ EOC 每转换一次（无 DMA 走中断；DMA1 Ch1 可选，+616 B）
                 ▼
          adc_context 中断驱动 ──▶ 序列完成（8 个 EOC）
                 ▼
      channel_reading[5][8] ──▶ 丢首个样本 ──▶ 每通道 4 点均值
                 ▼
  开机一次： #CFG,ch=8,res=12,ref_mv=1250,seq=5,avg=4
  每次触发： D,<uptime_ms>,<8 个原始码>          （读失败 → #ERR,<errno>）
                 ▼
  USART1 PA9/PA10 @115200 8N1 ──▶ 主机脚本 ──▶ mV = raw × 1250 / 2^12 ──▶ 功耗积分

• 采样链路：PA0–PA7 由 devicetree 的 channel@0..7 描述（代码里没有硬编码通道号）· 12 bit · 内部参考 1250 mV · 每通道 5 个样本、丢首个样本后取 4 点均值 · 采样时间 240 ADC 周期（默认 1.5 周期会 overrun）
• 输出协议：开机一行 #CFG 说明怎么换算，之后每次触发一行 D,4337,2743,2303,2049,2073,1634,2022,2174,2046；时间戳取序列完成时刻的 k_uptime_get()，实测间隔 1005/1005 ms 与 1 s 触发吻合，可直接当功耗积分的时间基准；读失败是 #ERR,<errno>，脚本不会把错误当数据
• 体积账：FLASH 14960 B = 91.31% / RAM 2544 B = 62.11%。关键三笔：LTO + ISR_TABLES_LOCAL_DECLARATION 合计 −1.46 KB 且二者不可拆（关任一个 → 16756/16752 B，溢出 372 B）；输出改机器可读 −272 B；排查时打开 ADC_LOG_LEVEL=4 是 +784 B 直接溢出，于是改用单字符 printk 插桩
• DMA 能跑但要付 616 B：默认最短采样时间 + DMA 下 8 通道全部正确、连续读取稳定；但把能省的都省掉也只到 16288 B（99.41%）、只剩 96 B，所以发布默认配置是无 DMA + 240 周期，DMA 作为可选配置写在文档里
• 五个有现象的坑：多通道 overrun（打印表头后卡死）· SEQUENCE_32BITS_REGISTERS 与 F0 上 16 位 adc_data_size_t 错配（读出 149621369 还不报错）· GEN_SW_ISR_TABLE=n 让 ADC 中断永不派发 · 上游把 ADC DT 拆成 common + 实例节点后 undefined reference to __device_dts_ord_19 · 首样本比稳态低约 980 码（≈60 mV），丢弃后均值抬高 100–220 码

边界（写清楚，免得被当成万能模板）：只在这一块 stm32f030_demo 上实测；flash 余量只有 8.7%（约 1.4 KB），任何新增功能都得先看 size 报告；DMA 默认不开（+616 B）；浮空输入时后续样本仍在爬升，测绝对电压前要接低阻分压源；采样时间只能取 DTS 表里的离散值，F0 的 ADC 时钟只有 PCLK/2 与 PCLK/4。代码与发布说明在这个分支：zephyrrtos_china/zephyr 的 lc_power_shield（commit 636dafd，私有库需账号），文档在 sample 目录的 RELEASE-NOTES.md。提交里标了 Assisted-by: DSH with deepseek-v4-flash —— 这是工作组「人 + AI + 真实设备」的常规协作方式，实测数字和已知限制一条没省。

场景（工作组自己的用法）：写一段歌的简谱——纯文本，几行数字：1=D 76BPM、5 5 4 3 2 3 | 1———把它连同「要什么风格」一起喂给 DSH。DSH 在这块 RK3588 板子上把谱子编配成声部（钢琴/吉他/鼓/主旋律…）、合成成分轨 PCM、再排成一条混音时间线，最后按 100 帧/s 灌进 AMP 从核，由 Zephyr guest 驱动 I2S 出声。听起来是一段有伴奏的歌，而不是一个提示音。

你写：一段简谱（纯文本）        例：1=D 76BPM   5 5 4 3 2 3 | 1—
  │
  ▼
DSH + 本系统（Linux 侧 / A76）
  ├─① 读谱编配   简谱 → 若干声部（钢琴 / 吉他 / 鼓 / 主旋律 …）
  ├─② 合成声部   每个声部一段 PCM（合成器配方，不是采样库）
  ├─③ 混音时间线 mix.json：时段、增益、淡入淡出、声像
  ├─④ 效果参数   厅堂 RT60 / 预延迟 · 人声颤音 / 气声 · 乐手时差 ms
  └─⑤ 灌流        amp-mix-play.py：100 帧/s × 1920 B（10 ms/帧）
        │
        ▼  /dev/ndp_pcm ── 共享内存 ring（32 槽）+ 邮箱门铃 ──►
Zephyr guest（A55 core3）
  ├─ 抖动缓冲 240 ms：Linux 卡一下，伴音不断
  ├─ PL330 DMA → I2S0：时序由 guest 的固定节拍保证
  └─► ES8316 codec → 喇叭 / 耳机   ⇐ 你听到的伴奏与旋律

• 伴奏可按要求调整：mix.json 的 clips 决定「哪个声部、从第几秒到第几秒、增益多少、淡入淡出多长、声像在哪」；同一段简谱能出钢琴版 / 吉他版 / 弦乐加厚版，旋律不用重写
• 剧场（厅堂）：hall{rt60_s, pre_delay_ms, early[], damping_hz, wet/dry, stereo_width}——《成都》用的是 RT60 1.6 s、预延迟 16 ms 的小场；改厅堂不必重合成，直接重播（混音器现算）
• 人声：领奏按「簧片/人声」配方合成——奇次谐波 + 气声 + 5.6 Hz 颤音 + 起音滑音（-20~-40 音分滑到 0）；每轨 reverb_send 决定送多少混响，drift_cents（±0.6 音分）给一点人的音准漂移
• 延时：parts[].delay_ms（0–15 ms）做「乐手反应时差」，配合厅堂预延迟，声音有前后层次而不是一刀切
• 实测：1920 B = 10 ms、100 帧/s、起播预充 24 帧；2800 帧 / 28 s 送完，速率比 1.00、busy=0，guest frames 单调增长（每帧都被真实消费）；《成都》240 s 四声部、《D 大调卡农》20 声部 5 分钟都在这条链路上放完

边界写清：编配/合成工具链在仓库 tools/amp-mp3-mix/（不在 v1.0.0 发布包内），发布包只保证「混音后的 PCM → I2S 出声」这一段；简谱变声部是合成器编曲，不是采样乐团；《成都》的旋律是凭记忆重建、不保证与原曲逐音一致（原谱只有图片，模型读不了图）；所谓「实时效果」是灌流时按参数现算的厅堂/延时/漂移，不是可交互的插件面板；改音色要重合成，改厅堂/延时/漂移只需重播。完整参数表与框图见 AMP-AUDIO 发布页 · 简谱变伴音。

场景：在 RK3588 上做低延迟、高确定性的音频输出，但不想放弃 Linux 的解码与混音生态。传统做法是 Linux 独占 I2S，音频路径里塞着整个内核调度、电源管理与驱动栈——上游一卡就爆音，而且出问题时只有一层 ALSA 抽象可看。这一版把末端的时序敏感部分挪到 AMP 从核：A76 跑 Linux 做解码混音，A55 core3 上的 Zephyr guest 直接驱动 I2S + PL330 DMA 出声，两域之间用共享内存 ring + 邮箱门铃通信，中间带 240 ms 级抖动缓冲。

发布形态是可复现的功能包（7 份发布文档 + 5 份技术文档 + 5 个脚本 + 6 个产物 + 两份许可证）。上手只要三条命令：verify-release.sh 校验和自检 → amp-audio-up.sh 装模块并点火 guest → amp-tone.py 听琶音。发声脚本自带 PCM 发生器，不需要任何 mp3 素材——这正是「伴音发生器」的最小可用形态：一条跨域音频通路，三行命令验证。

• 实测数字：PCM 帧 1920 B = 10 ms（48 kHz/16 bit/立体声）、送数 100 帧/s、抖动缓冲 241–288 ms、停送数 200/250 ms 不断音、L2Z ring 32 帧 = 320 ms 容量
• DMA 不是 CPU 喂 FIFO：PL330 通道 cyclic 搬运，fifo_full_waits=0、播放线程迟到峰值 8.75 µs、4 分钟长跑 i2s underrun=0；上游 tests/drivers/dma 12/12、tests/drivers/i2s 15/15 编译用例通过
• 反向实验能复现：把 DT 请求线改成 1，DMA 吞吐从 470 400 塌到 3 840（122 倍），回滚后 md5 逐字节还原——数字不是设计估算
• 边界写清：只验证过本板 6.1.75-abdbg 与 48 kHz；其余采样率、录音 RX、多小时浸泡都未验证；shm_mode=2 的一致性前提没做过判定实验；guest 活着时卸模块会让板子无现场复位（脚本默认拒绝），停 guest 只能重启

获取方式与许可：仓库 zephyrrtos_china/zephyr_ndp 的标签 v1.0.0-amp-audio（Release 附 tar.gz 与 SHA256SUMS；私有仓库，需账号或会员）。许可按组件分两类——文档/脚本/guest 镜像 Apache-2.0，两个内核模块 .ko 是 GPL-2.0 目标码，对应源码在仓库 linux/ndp_cons/ 与 linux/amp_clk_hold/。完整说明、实测表与边界见 AMP-AUDIO v1.0.0 发布页。

场景：在 RK3588 上做「A 核 Linux + 实时域 Zephyr」的异构开发，内核、设备树、guest 镜像、内核模块四类产物天天改，每一次改动都可能让板子起不来、或起来但门铃不响——而这种活儿最容易的失败方式不是写错代码，是把板子试挂了却回不去。所以我们把「环境本身」做成了可发布的成果：实验怎么试、失败怎么回、结论怎么证。

当前实测形态：Radxa ROCK 5B+（RK3588）· Armbian + 内核 6.1.75-abdbg · Zephyr guest 由 ATF 经厂商 rockchip,amp 路径在 A55 core3（MPIDR 0x300）启动 · 通过共享内存 + 门铃协作。运行分支为 debug，abcount 自动记账。

• A/B 双分支 + 自动回滚：ab-ctl use-debug 武装、use-stable 回退、touch /boot/ab-off 急停；ab-boot-ok 在约 +199 s 判健康并清零计数，连续 3 次失败自动切回稳定分支并持久禁用 debug——这块板子没有串口，自动回滚是唯一的兜底通道
• 四类产物只写 /boot/debug/，每次覆盖前留 .pre-<tag>-<epoch> 备份，回退就是把备份改回原名
• 「部署生效」用两把尺：uio mmap 前 4 KiB 的 md5 vs 镜像文件（read() 只给中断计数，用 dd/cat 自证会得到假阴性）+ guest 自报 pcm 的 build id
• 边界说清：无串口、非干净复位会丢最近约 120 s 写入（证据只落 RAID）、AMP 数据面在线时跑重构建/重 I-O 已两次导致无现场复位、guest 每次开机只有一次 CPU_ON 有效

完整方法、命令与边界见 RK3588 AMP 开发环境 页面；代码在私有仓库 zephyrrtos_china/zephyr_ndp 与 zephyrrtos_china/linux-rockchip-rk3588-amp，文档与每次启动的账本在板子 RAID 的 /mnt/raid1/shared/ab-boot-docs/。

工作组的第一篇对外长文已发布到开源中国：以 Zephyr 为底座，建一套「中国驱动」的软件系统。它不是工具清单，而是一次完整的立场陈述——为什么中国需要的是「从芯片到应用都能自己说清楚」的软件系统，而不是又一个 RTOS 替代品。

文章把这条链拆成八个方向（操作系统、系统优化、体系架构、编译器、行业应用、数据加密、开发工具、AI），逐个说明「这个方向中国团队必须自己掌握什么」，并列出已经落地、可验证的东西：官网与数据驱动的动态、国内镜像、ROCK 5B+ 远端沙盒、四个已发布的 DSH 插件、带 18 个工具的智能体、自建 Gitea 与会员机制。

• 三条纪律：只发机制不发结论、跳过不是通过、不把计划写成已交付——文章里连着「我们还没做到什么」一起写了
• 边界说清：合规门禁借用 ISO 26262-8 第 11 章的方法论，但不构成任何功能安全合规声明（原文硬约束 L4）
• 本站备份：Markdown 版本（便于引用与版本化）

中国需要的不是「国产 RTOS 的替代品」，而是一套从芯片到应用都能自己说清楚的软件系统：系统的每个数字怎么量出来的、每条判据谁写的、每次放宽边界留了什么痕、每次发布带了哪些 open 偏差。这件事一个人做不完，但一群人用同一条链、同一套工具、同一份证据去做，是可以开始的。

场景：一次跑很久的任务——大型迁移、反复失败重试、无人值守的长期目标——把上下文顶到窗口上限，而同会话压缩已经压不动：装了大型工具集的 envelope 本身就占掉一块、一次超大工具调用是个不可分单元、或「摘要的摘要」逐轮失真。第四个工作组插件 dsh-handoff 针对的就是这一格：它不再试着把历史压得更狠，而是换一条干净会话接着干——提炼一份交接简报，开一条空上下文的后继会话并唤醒它，旧会话作为归档保留，侧栏里以谱系缩进显示两者关系。

它不自作主张：交接的代价明显高于压缩（一次摘要调用 + 一条新会话 + 用户的注意力被打断），所以默认立场是不交接，要三重门同时打开才动手——① 压力真的到顶（已用 ≥ handoffRatio × 路由模型 contextWindow，该阈值在装载时被强制要求严格大于压缩的 0.8，否则直接装载失败）；② 观测到同会话压缩已失败（无可压区间 / 连续压缩释放量低于窗口 5% / 溢出恢复未产生持久进展 / 一轮因 max-tokens 收尾且有活跃目标）；③ agent 正处于空闲边界（没有 driver 在调度、没有打开的轮次）。另有护栏：链深达上限、后继没干过活、会话无可继承工作目录时一律拒绝。

交接简报不会因为模型不可用而失败：首选模型摘要（逐字回放前任的 system 与工具 schema，让辅助调用成为会话的真正前缀，提供方热前缀缓存可复用），失败则从日志确定性重建——最后一条用户输入、最近的助手输出、被读改过的文件、未完成待办、未结清审批、最近错误。质量更差，但永远可用；而「上下文满了」与「模型正在挣扎」本来就是相关的。简报超预算时按优先级裁剪，但「原始意图」与「下一步」永不丢弃——丢了它们，简报就不值得换一条会话，宁可放弃交接。

被实测纠正的一件事，写在这里因为它是本次发布最值钱的部分：插件最初有一条判定证据——「从宿主上下文探不到压缩服务 ⇒ 没有压缩后端」。装上去实测，日志确实报「探不到」。但查下去发现 dsh-web-app 模式明确禁用了宿主层的压缩行，把压缩后端挂到 agent preset 上——所以宿主层的探测在压缩完全正常工作的部署里也永远返回「缺失」。而那条证据单独就能放行，于是插件会去抢压缩的活，正是整个设计要避免的那一个失败。现在它被删掉了：判定只用会话日志证据（压缩到底做了什么，日志说了算，与后端挂在哪一层无关），并有一条回归测试守着。静态评审不可能发现这一点。

• 版本：@hakehuang/dsh-handoff@0.1.0（私有 Gitea registry 的 dist-tag latest）；附注标签 pkg-v0.1.0 锚定产包提交——Gitea 的 registry 不返回 gitHead，标签是唯一的溯源锚
• 分发：不在公共 npm（dsh-handoff 这个名字已被他人占用，故用 scoped 名）。私有 registry https://zephyrrtos.cn:3000/api/packages/hakehuang/npm/（匿名 401）或 git 依赖钉标签 #pkg-v0.1.0
• 消费者视角已验证：registry 返回 0.1.0、安装加入 1 个包、装出 17 个文件、插件行 name 等于包名（否则会静默挂不上）、包内不含台账
• 零运行时依赖：所有 @deepseek-ai/* 导入都是动态的，由宿主在装载时解析——这一条直接消掉了「依赖范围无法满足而装不上」那类失败

配套上线页面 dsh-handoff 发布与接入：它解决什么、三重门与判定证据、交接简报的三条路径、三种安装方式、配置字段，以及照实写的局限——包括「触发门槛在 1M 上下文上高达 92 万 token，所以在正常用法里它几乎不会触发；稀有是设计正确的证据，不是没生效」，和「客户端半边（徽章/横幅/自动切台）尚未实现」。

场景：车规 / 工业功能安全一类项目开始把 AI 代理放进开发流程——让它写代码、改配置、跑验证、甚至发版。这类项目最怕的不是代理写错，而是说不清：这条需求谁实现的、按哪条判据验证过、当时放宽了什么边界、发布快照里还有哪些 open 偏差。第三个工作组插件 dsh-compliance 提供的正是这个场景需要的机制：把「每一个『已完成』的结论都带可复现的反证」变成机器的默认动作——校验器、生成器、空模板与 CI 片段，只发机制，不发结论。

它长在哪些环节：①需求 → 判据 → TCL 定级 → 验证证据 → 发布记录全链的引用可解析性（悬空引用、孤儿文档、到期偏差都会被拦，实测曾出现过 31 条提交 trailer 全部指向不存在的要求而门禁一直全绿）；②交付给客户 / 第三方时，发布记录由工具从标签快照生成（tag → commit → treeHash，文件身份用 git blob SHA），「发布时有哪些 open 偏差」只能由标签回答；③让代理自己跑门禁（非零退出码原样上报，SKIP 与 PASS 分列——跳过不是通过）；④凭据扫描覆盖工作树文件、提交补丁与提交信息三类载体（实测：令牌只放进提交信息时，前两道扫描器都报干净，第三道拦下）。

针对的是三种固定形状的失真：「做了≠做对」（扫描器在管道被截断时只扫了部分历史却报 no leaks found）、「门禁自己会撒谎」（门禁只查「有没有这东西」，不查「这东西是否成立」）、「放宽边界不留痕」（沙箱拒绝、一次性升权、审批结论若不成链，回放就不出「当时到底放宽了什么」）。

配套上线页面 dsh-compliance 发布与接入：典型场景、七个检查各自在防什么、三种接入方式（私有 registry / git 依赖钉标签 / vendored）及其分发边界差异、每条附实测依据的优势，以及完整的局限清单（结构性 6 条、环境与工程 7 条、尚未实现 7 条 + 什么时候不要用它）。

关于标准，必须说清：它的 TCL 定级框架借用 ISO 26262-8 第 11 章的工具置信度方法论，但项目自己的方法论里有硬约束 L4——「本仓库中任何出现 TCL 的文档，都不得被解读为『符合 ISO 26262』」，且标准原文至今未直接查阅（DEV-007）。因此它不构成任何功能安全合规声明：它能帮你把证据链与门禁做实，不能替你取得任何认证。

• 版本：包产物 0.1.1（私有 Gitea registry 的 dist-tag latest；0.1.0 首发）与治理基线 v1.0.0 是两条独立轴，别混
• 分发：不在公共 npm（同名包已被他人占用）。私有 registry https://zephyrrtos.cn:3000/api/packages/hakehuang/npm/（匿名 401）或 git 依赖钉标签 #pkg-v0.1.1——后者会把整个仓库交给消费者，而 registry 路径实测只有 40 个文件、边界成立
• 当前仍 open：跨仓库工具一致性未实现（DEV-003）、凭据吊销暂缓（DEV-006，到期 2026-10-24）、96 条需求从未被任何提交指向、四项门禁未强制——这些都写在页面里，不假装已强制

场景：一轮任务里「规划」需要强模型、其余步骤用便宜模型就够；但模型选择又必须留在 harness 自己的注册表里（会话日志要记录调用方真正请求的东西）。这条路由让 auto / lead / worker / worker:<id> 像普通模型一样可选——一次 lead 调用做规划，其余步骤交给 worker，便宜路由持续失败时再升级回 lead。

dsh-llm-router 0.1.1 已发布（2026-09-20）。它把 Lead/Worker 路由做成 harness 的一等公民：插件在 ctx.llm 上注册一条虚拟提供方路由（默认 lead-worker），并提供 cordis 服务 ctx.llmRouter。模型路由因此不再是躲在外部二进制或旁路代理里的决策——它就是每个模型调用都要经过的同一张注册表里的一条路由：可观察、可拦截、可替换。

0.1.1 修掉的是与 dsh-ubuntu-sandbox 0.1.0 同源的安装阻断（schemastery ^3.18.2 在公共源不存在 → notarget），依赖范围改为 ^3.18.0；同时新增 check-installable / verify-installed 两步「打包 → 真实解析依赖装进临时 profile → 以 bundle 启动」的发布前校验，让这类不可安装的版本不再有机会发出去。

配套上线新页面 dsh-llm-router 发布与安装：三种安装方式（社区市场 / dsh plugin / 手工 patch 行）、配置字段表、虚拟模型与策略规则、推理强度为什么归路由所有、观察 / 拦截 / 替换三种改路由方式，以及「成本与边界」——prompt cache、故障转移绝不拼接答案、重试仍归 dsh-llm-retry、决策不进持久会话日志。

• 轮次成本形状：一次 lead 调用做规划，其余步骤交给 worker；便宜路由持续失败时再升级回 lead（升级自限，成功即清零）
• 虚拟模型：auto / lead / worker / worker:<id>——模型选择器、会话日志、压缩、会话标题都无需改动
• 无配置时休眠：既没有 lead 也没有 workers 时只打一行日志、不挂载任何东西；但「写了一半」的路由会明确报错
• 目录源已在线：https://zephyrrtos.cn/dsh-llm-router/catalog-source.json，市场里条目名为 Lead/Worker Model Router

安装前请先读插件安装与更新教程里的两个通用坑：dsh plugin 只装依赖、不写挂载清单（要确认 dsh.profile.bundles 含包名），以及 pnpm 10/11 的 store 版本冲突（ERR_PNPM_UNEXPECTED_STORE）。

场景：板子放在机柜里、没有键鼠显示器，或者你在 Windows 上写代码、却要在 ARM64 板子上编译与调试——把远端主机当作 agent 的命令行工作区，远端编译、板端调试、文件同步都在板子上跑。默认开 tmux 持久会话：cd / export / 后台任务跨调用保持，SSH 断线重连也不丢。

0.1.1 修掉了一个会让插件根本装不上的问题：0.1.0 声明依赖 schemastery ^3.18.2，而公共 npm 源里最新只有 3.18.0，于是 npm/pnpm install 与 DSH 社区市场的安装都会以 notarget 失败——之前只在「把插件目录手工拷进 profile」的场景下被掩盖了。现在依赖范围改为 ^3.18.0，安装恢复正常；0.1.0 已在 npm 上标记废弃（deprecated）并指向 0.1.1，请使用 ≥0.1.1。

同时新增教程页 dsh-ubuntu-sandbox 安装与更新：三种安装方式（DSH 社区市场 / dsh plugin 命令行 / 手工离线）、更新与回滚、装完的验证清单，以及安装期最常见的报错处置。

• 前置：DSH ≥ 0.1.2-rc.1；远端主机装 tmux；主机写进 ~/.dsh/dsh-ssh.json（与 dsh-ssh 共用）
• 一条命令：dsh plugin --profile desktop add @hakehuang/dsh-ubuntu-sandbox@0.1.1，然后重启 DSH
• 装完必查：profile 的 dsh.profile.bundles 是否含包名——dsh plugin 只装依赖、不写挂载清单，缺了不会报错、只是工具不出现
• 验证：dsh --profile desktop --dump-config 里出现 id: ubuntu-sandbox，且工具列表出现 sb_cwd / sb_session / sb_exec / sb_ls / sb_read / sb_write

排查提示：如果安装报 ERR_PNPM_UNEXPECTED_STORE，那是 profile 的 node_modules 由 pnpm 10 建立、而 DSH 强制使用自带的 pnpm 11 造成的。完全退出 DSH 后在 profile 目录执行一次 DSH 自带的 pnpm install 迁移 store 即可根治；不想迁移就用与现有 store 匹配的 pnpm 手工安装。两种做法都写在教程页里。

除了邮件与 Gitea，我们把智能体支持接进了站点的几个入口：在智谱清言上的工作组智能体，可以直接问 Zephyr 入门、镜像导入（west / insteadOf 重定向）、远端沙盒接入与工具使用的日常问题。

• 首页——资源区「智能体支持（智谱清言）」入口，参与区也加了「向智能体提问」按钮；
• 加入页——新增「支持渠道」板块（邮件 / 智能体 / Gitea），并补了一条 FAQ「遇到技术问题去哪里问」；
• 沙盒页——相关链接新增「支持与答疑」，覆盖接入、采购与预装咨询；
• 分工建议——日常答疑找智能体，需要留痕跟进的开 Issue，账号与合作事宜走邮件。

国内直连 github.com/zephyrproject-rtos/* 经常慢到 west update 跑不完。我们把这条路径固化成一份可直接照做的说明：zephyrrtos.cn 项目导入。

• 核心只有一条配置——git config --global url."https://www.zephyrrtos.cn:3000/zephyrrtos_china/".insteadOf "https://github.com/zephyrproject-rtos/"，之后 west init / west update / 手动 clone 全部走镜像，无需改动工程文件；
• 从零搭建步骤——Ubuntu 依赖、Python venv、west 安装、重定向、west init/update、SDK 获取（zephyr_sdk）与首次编译；
• 已有工程切换与还原——单仓库改远端、仅当前目录生效、一键取消重定向，都给了命令；
• 排错与凭据建议——401/403、仍走 GitHub、模块缺失、update 中断的处理；强调凭据不要写进脚本或 URL。

镜像组织 zephyrrtos_china 需要账号访问——先在 如何加入 申请账号并在账号里配置公钥或访问令牌。页面上同时提供两个可直接下载的脚本：zephyr_redirect.sh（3 行，只做重定向）与 zephyr_cn_setup.sh（依赖 + venv + west + init/update 一键完成，不含任何凭据）。

zephyrrtos.cn 官方网店现已开通。我们把这个远端开发沙盒的整机与配件放上了货架——需要一台能远程开发的 ARM64 机器，可以直接下单，不用自己攒。

• 开发沙盒整机——基于 Radxa ROCK 5B+（RK3588，8 核 / 16GB 级内存），出厂为「通用型人工智能个人代码数据中心」形态：定制散热、定制电源、定制外壳、双 128GB NVMe 组 RAID1；
• 固件与软件预置——Armbian 系统、Samba 共享、SSH、Gitea 本地代码托管、RAID1 文件系统等按需启用；
• 拿到就能远程开发——配合 dsh-ubuntu-sandbox 与 DSH，把板子接进主机库即可当远端开发机使用（见平台说明）。

购买前想先了解平台规格、实测配置与接入方式，可以看 远端开发沙盒（ROCK 5B+）；企业或高校批量采购、需要预装与配置服务，直接在邮件里说明需求即可。

zephyrrtos.cn 会员现已开通申请。发一封邮件即可开始：提供你的用户名与邮箱，我们为你开通 3 个月免费会员，用来使用 zephyrrtos.cn 的资源。

• 怎么申请——发邮件到 hakehuang@gmail.com，主题写「申请 zephyrrtos.cn 会员」，正文提供用户名与邮箱；
• 免费期——3 个月，从我们回信确认开通之日算起；
• 到期之后——可自行选择是否开通正式会员（年费 RMB 200），到期前会提醒一次，不自动扣费、不强制。

会员可用于自建协作平台（Gitea）、工作组工具与插件、中文资料与国产芯片适配仓库等 zephyrrtos.cn 资源；其中正在建设与规划中的部分，会员可优先获取与参与。

企业、高校团队同样可以加入——在申请邮件里说明团队情况与用途即可。

工作组自建的基础设施同日就绪，全部运行在自己的服务器上：

• 官网：zephyrrtos.cn（HTTPS，证书自动续期）；
• 代码托管：zephyrrtos.cn:3000（自建 Gitea，Issue / PR 全部公开）；
• DSH 插件目录源：/dsh-ubuntu-sandbox/catalog-source.json——符合 DSH 社区市场 v1 契约，可被任何用户添加；
• 工具发布链路：npm 公开包 + 目录源收录 + CI（Gitea Actions）自动发布。

工作组发布第一个工具 dsh-ubuntu-sandbox：把一台远程 Ubuntu / Debian 主机变成像本地命令行一样的「工作沙盒」，用于远程编译、烧写辅助、板端调试与文件同步。

• 远程执行 bash，默认 tmux 持久会话：cd / export / 后台任务跨调用保持，断线重连不丢；
• 远程文件能力：目录列表、读、写（自动建父目录），与本地工具同款退出码 / 超时标记；
• 与 @linxin666/dsh-ssh 共享主机库 ~/.dsh/dsh-ssh.json，支持密钥 / 密码 / agent 认证；
• 已在 aarch64（Armbian）与 x86_64（Ubuntu 22.04）实机验证：会话保持、读写回环、断连续用；
• MIT 许可；npm 公开包，同时收录进工作组自建目录源，可在 DSH 社区市场一键安装。

安装：dsh plugin --profile <profile> add @hakehuang/dsh-ubuntu-sandbox

工作组确定把 DSH（DeepSeek Harness）作为标准工程协作工具，用于把「人 + AI + 真实设备」的开发流程固定下来。

选择它的理由：

• 可扩展——插件化架构，工具、技能、面板都能按工作组需要扩展，不被单一厂商流程绑死；
• 本地优先——可自建、可离线、数据留在本地与自有服务器，符合自主可控要求；
• 贴近真实工程——直接操作终端、文件与远端主机，而不是停留在聊天窗口；
• 可协作——插件与目录源可自行发布，工作组能把内部工具沉淀成公共能力。

后续工作组的适配脚本、板级辅助工具、文档工作流，都会以 DSH 插件 / 技能的形式发布，并通过自建目录源统一收录。

今天，zephyrrtos.cn 工作组正式成立，并公开发出倡议：成立独立的 Zephyr RTOS 本土开源组织，补齐本土生态短板，让顶级开源 RTOS 真正落地中国产业。

我们的出发点是四个已经被反复验证的现实问题：

• 国产芯片适配近乎空白——缺少批量维护的国产 MCU / 开发板 BSP 与适配仓库；
• 中文生态贫瘠——文档全英文、体系庞杂，设备树 / CMake / west / Kconfig 学习曲线陡峭；
• 社区响应滞后——本土问题难以进入主线，定制化需求得不到优先处理；
• 产业配套缺失——培训、企业服务与落地案例稀缺，技术被闲置。

工作组的定位很明确：不是另起炉灶，而是扎根全球开源、服务中国产业——做国产芯片适配、中文内容建设、本土快速响应与产业赋能，并把经过验证的本土方案反向回馈上游主线。