正步 112 步/分钟是什么概念：华为云码道开发鸿蒙「分列式节拍器」，滑杆推演方队过线时间

阅兵解说里最常听到的两个数字是「112 步/分钟」和「75 厘米步幅」，但这两个数凑在一起到底意味着什么？一个 14×25 的徒步方队从第一排踏上白线到最后一排离开白线要几秒？我让码道 Agent 把这个抽象概念落成一个可交互的鸿蒙应用：三根滑杆控制步速、步幅、行数，Canvas 实时推演方队过线动画，右侧卡片同步刷新通过时间、方队长度、单兵总步数。

仓库地址：https://atomgit.com/2501_92427005/march-metronome

0. 缘起：112 bpm 到底有多快

看阅兵直播时，解说员报「正步，每分钟 112 步，步幅 75 厘米」，大部分人（包括我）对这组数字没有体感。直到自己按计算器：

• 步速 = 112 / 60 × 0.75 = 1.4 m/s，正好是成年人快步走的速度；
• 一个 14 排的方队，前后排间距 1.2 米，纵长 = 13 × 1.2 = 15.6 米；
• 从排头踏上观礼台白线，到排尾离开白线，需要 15.6 / 1.4 ≈ 11.14 秒。

也就是说，电视画面里那个看起来「一瞬间」通过的方队，其实要在镜头前走整整 11 秒多。这个数字震撼到我了，于是决定把它做成一个能拖滑杆、能看动画的小工具——正好接上系列「日晷、卫星、流星雨」的天文科普人设，只是这次算的是人间的时间。

照例先立六条硬约束，写进给 Agent 的提示词：

• 纯本地、零权限：requestPermissions 保持 []，不联网、不存储；
• ArkTS + ArkUI 声明式，API 12+，DevEco Studio 5.0 直接打开可构建；
• domain 层纯净：步速/步幅/方队几何计算不 import 任何 @ohos.*，能在 Node 里跑单元测试；
• 数值必经 sanitize：滑杆输入先过 sanitizeBpm / sanitizeStrideCm / sanitizeRowsCols，空串/NaN/越界全部有兜底；
• 中文文案全走资源：resources/base|dark/element，深浅色双主题；
• 测试必须真绿：npm test 用 Node 的 --experimental-strip-types 直接跑。

1. 给 Agent 的提示词：先建仓，再开发

沿用系列验证过的「两步走」：

第一步，建仓。 让码道在 AtomGit 创建 march-metronome 仓库，只写 README 标题 + MIT License + .gitignore（含 .hvigor/、*.hap 这些鸿蒙特有忽略项），不写任何业务代码：

Agent 确认仓库参数，准备调用 AtomGit API：

调 ag-cli 技能完成建仓：

建仓完成，仓库地址落定：https://atomgit.com/2501_92427005/march-metronome

第二步，开发。 单独开会话，把完整需求喂给 Agent——核心是把 112 bpm / 75 cm 这两个数背后的物理模型写死：匀速直线运动，方队是刚性阵列，过线时间 = 方队纵长 / 步速。不给模型「自由发挥」的空间：

红线清单也一并给出：禁 any/unknown、禁旧作换皮（日晷/节气/流星雨/假期打卡/五星红旗全点名）、公式永不进组件事件、提交语义化、README 末尾追加说明不动前面：

Agent 接到任务后的执行过程：先 clone 空仓，检查工具链，列出三层骨架计划，然后按「骨架 → 领域层+测试 → UI+动画」三步提交：

2. 需求拆解：三根滑杆、一段动画、四个数字

应用功能一句话讲完：

拖滑杆改步速/步幅/行数，屏幕上的方队按物理公式实时重排，看不同参数下通过观礼台要几秒。

具体三层：

层	职责
domain	由 bpm/步幅/行列推出全部物理量：速度、方队纵长、过线时间、总步数、单兵里程
ui	Canvas 绘制方队圆点阵列与过线动画，滑杆与播放开关，结果卡片
resources	深浅色色板、全部中文文案、免责声明

交互细节：

• 步速滑杆 60–200 bpm，默认 112（正步标准）；
• 步幅滑杆 40–120 cm，默认 75（正步标准）；
• 行数滑杆 2–20，默认 14（标准徒步方队），列数固定 25；
• 「播放/暂停」Toggle 控制动画，t=0 定义为排头刚好踏上白线；
• 结果卡片实时显示：通过时间（秒，两位小数）、方队长度（米）、单兵走完 100 米总步数、当前速度（m/s）。

3. 架构：domain 层是全部精华

工程结构（Agent 产出，我未改分层）：

entry/src/main/ets/
├── domain/
│   └── march.ets          纯物理：常量表 + 纯函数，零 @ohos.* import
├── entryability/
│   └── EntryAbility.ets
└── pages/
    └── Index.ets          @Entry：Canvas + 滑杆 + 结果卡片

3.1 常量表：把阅兵标准翻译成代码

// domain/march.ets
export const STANDARD_BPM: number = 112;
export const STANDARD_STRIDE_CM: number = 75;
export const FRONT_ROW_SPACING_M: number = 1.2;

三个数全部来自公开报道的阅兵训练标准，写死成常量，UI 层默认值直接引用。

3.2 核心公式：匀速直线运动

export function speedMps(bpm: number, strideCm: number): number {
  return (bpm / 60) * (strideCm / 100);
}

export function frontLengthM(rows: number): number {
  return (rows - 1) * FRONT_ROW_SPACING_M;
}

export function passTimeSec(rows: number, bpm: number, strideCm: number): number {
  return frontLengthM(rows) / speedMps(bpm, strideCm);
}

注意 passTimeSec 没有列数参数——方队是刚性阵列，所有列同步过线，过线时间只取决于纵长和速度。这个「消参」是物理建模的关键一步。

3.3 动画辅助：t 时刻的横向偏移

export function memberOffsetM(
  row: number, col: number, t: number,
  bpm: number, strideCm: number
): number {
  const v = speedMps(bpm, strideCm);
  const headX = v * t;
  return headX - row * FRONT_ROW_SPACING_M;
}

t=0 时排头（row=0）在 0 点，第 r 排落后 r × 1.2 米；col 不参与横向偏移，只用于 Canvas 上的纵向排布。符号上「尚未到线」为负，「已过线」为正。

3.4 输入消毒：滑杆值也要过安检

export function sanitizeBpm(input: unknown, fallback: number): number {
  const n = toFiniteNumber(input);
  if (n === null) return fallback;
  return Math.max(60, Math.min(200, n));
}

空串、null、NaN、字符串数字、越界值各有归宿。passTimeSec 内部先调 sanitize，所以即使 UI 层忘了，domain 层也不会产出 NaN 时间。

4. UI：Canvas 绘制与动画驱动

4.1 绘制流程

private drawMarch(t: number): void {
  const v = speedMps(this.bpm, this.strideCm);
  // 1. 画竖直过线参照
  ctx.strokeStyle = '#CF0A2C';
  ctx.beginPath();
  ctx.moveTo(lineX, 0);
  ctx.lineTo(lineX, ctx.height);
  ctx.stroke();
  // 2. 画 rows×cols 个圆点
  for (let r = 0; r < this.rows; r++) {
    for (let c = 0; c < 25; c++) {
      const offsetM = memberOffsetM(r, c, t, this.bpm, this.strideCm);
      const px = lineX + offsetM * scale;
      const py = topMargin + c * rowGap;
      ctx.beginPath();
      ctx.arc(px, py, dotRadius, 0, Math.PI * 2);
      ctx.fill();
    }
  }
}

比例尺 scale 按屏幕宽度自适应，保证最大纵长 19×1.2=22.8 米能完整显示。

4.2 动画驱动

aboutToAppear(): void {
  this.timer = setInterval(() => {
    if (this.playing) {
      this.t += 0.05;
      if (this.t > this.maxT) this.t = 0;
      this.drawMarch(this.t);
    }
  }, 50);
}

50 ms 一帧，t 步进 0.05 秒，循环播放。maxT 按当前参数算好，保证方队完全过线后重置。

5. 单元测试：Node 直跑 ArkTS 子集

沿用上一篇验证过的路子：tests/transpile.mjs 把 domain/*.ets 改 import 路径、转存为 .ts，Node 22+ 的 --experimental-strip-types 直接执行，零第三方依赖。

"scripts": {
  "pretest": "node tests/transpile.mjs",
  "test": "node --experimental-strip-types --test tests/*.test.mjs"
}

7 条用例覆盖：

• sanitize：空串/null/NaN/-5/999/112 各断言；
• 手算尺子：bpm=112, stride=75 → speedMps = 1.4 m/s；
• 手算尺子：rows=14 → frontLengthM = 15.6 m；
• 手算尺子：passTimeSec = 15.6 / 1.4 ≈ 11.142857（EPS=1e-9）；
• memberOffsetM：t=0 时 r=0 为 0，r>0 为负；
• 反推校验：totalDistanceM(passTimeSec(...), ...) ≈ frontLengthM(rows)；
• 随机扫描：10000 组随机参数全链路有限不抛错。

$ npm test
ℹ tests 7
ℹ pass 7
ℹ fail 0

6. DevEco 实测：四个状态

工程在 DevEco Studio 5.0 里 Sync 一次过，Pura X 模拟器直接 Run：

默认首屏，112 bpm / 75 cm / 14×25，方队尚未过线：

调参后，157 bpm / 90 cm / 20 行，方队纵长拉长，通过时间缩短：

方队过线瞬间，排头刚好压线，t ≈ 0：

方队已过线大半，排尾即将离开，t ≈ 8 秒：

边界实测：

• 步速拉到 60 bpm，通过时间拉长到 20 秒以上，动画节奏明显变慢；
• 步幅拉到 40 cm，速度掉到 0.4 m/s，方队几乎「蠕动」；
• 行数拉到 20，纵长 22.8 米，Canvas 仍能完整显示；
• 快速来回拖滑杆，Canvas 重绘无闪烁（@State 驱动，声明式渲染）。

小结

这篇是系列里物理建模最「轻」的一篇——没有三角函数、没有天文算法，只有匀速直线运动。但恰恰是这种「轻」，让「112 步/分钟」从解说词变成了可拖拽、可验证、可感知的数字。三点心得：

1. 抽象概念需要「锚点」。112 bpm 本身没有体感，但 1.4 m/s、15.6 米、11.14 秒有。好的科普工具不是堆数据，而是找到那个让人「啊，原来如此」的锚点。

2. 消参是建模的功力。方队过线时间看起来跟 14×25=350 人有关，实际上只取决于纵长和速度。提示词里把「列数固定 25，不用滑杆」写死，就是逼 Agent 想清楚哪些参数真的影响物理过程。

3. 动画是调试器。memberOffsetM 的符号一开始写反了（把 row 的系数写成正），Canvas 上立刻看到方队「倒着走」，比单元测试更早暴露问题。可视化是最快的物理直觉校验。

• 应用名称：March Metronome（分列式节拍器）
• 仓库地址：https://atomgit.com/2501_92427005/march-metronome
• 技术栈：HarmonyOS ArkTS + ArkUI 声明式 · API 12+ · Canvas 2D · Node node:test（--experimental-strip-types）
• 核心特性：零权限、纯本地、正步物理内核、3 滑杆实时推演、方队过线动画、深浅色双主题、7 条单元测试全绿