摘要: HarmonyOS 7（API 26）的碰一碰·精准分享把"传给谁"升级为"传到哪"——系统识别手机触碰屏幕的坐标，应用据此决定内容落在哪个窗口、哪个位置。落点本身就成了业务指令，这让精准分享从文件传输工具变成多设备协作的入口。本文给出五个可直接立项的应用构想：办公协同的参考图直插文档、创意设计的素材甩上画布、教育课堂的题目投白板、游戏互动的设备间投掷、智慧出行的行程投车机，每个构想都带用户旅程、触发链路、关键技术点和边界风险，并按"现在就能做 / 需要等能力补齐"分档，供还在构思阶段的开发者直接挑一个开干。

适用版本: HarmonyOS 7 / API 26.0.0（Beta 阶段能力边界以当前 SDK 文档为准）

开篇：落点本身，就是一条业务指令

8 月底社区发起「碰哪传哪」话题的时候，我第一反应不是"又多个传文件的方式"，而是琢磨这句话背后的东西：内容从"被发送"变成"被精准投递"。

这个转变值得停一下。

传统的跨设备分享，落点是系统决定的——文件永远进下载目录，或者接收端弹个卡片让你选。应用拿到内容后，剩下的路径（进哪个文档、放哪张画布、投到哪块白板）全是用户手动补的。精准分享多出来的那对坐标，让应用第一次知道了"用户碰的是哪"——碰的位置不再只是物理事实，它可以直接翻译成业务动作。

这就是我想通的一件事，也是本文所有构想的判定原则：落点即指令。碰到画布，指令是"插图层"；碰到文档某页，指令是"插附件"；碰到白板某题，指令是"投这里"。碰的位置没有业务含义的场景，精准分享就退化成普通分享，不值得做。

基于这个原则，我推了五个方向：办公协同、创意设计、教育课堂、游戏互动、智慧出行。每个构想下面给出用户旅程、触发链路、技术要点和边界——够细到可以直接立项，但我不假装已经开发过，凡是和现有能力边界有关的地方，都会明确标"需等能力补齐"。

图：五个构想共享同一能力底座（坐标识别 + 定向投递），差异在"落点→指令"映射表

---

一、构想的判定标准：什么样的场景配得上精准分享

不是所有分享场景都值得用精准分享。我给自己定了四条判定标准，一个场景四条都过才值得立项：

#	标准	说明	反例（不该做）
1	落点有业务含义	触碰坐标能翻译成明确的业务指令（插哪、投哪、替换哪）	接收端是纯文件列表，坐标只是"放到哪一行"，没有语义
2	内容可轻预览	落点确定后，用户能在 1-2 秒内看到"要落什么"，低风险操作直接执行、高风险先确认	内容是一个 2GB 压缩包，预览不出来，落点再准用户也不敢确认
3	失败可撤销/可拒绝	落错了能撤，落点区域无效能明确拒绝并说明原因	碰一下就执行不可逆操作（外发、删除）
4	单链路 ≤3 步	从"手机有内容"到"内容落到目标位置"，用户动作不超过 3 步（拍照/选内容 → 碰 → 确认）	还需要先登录对端、先建群、先选文件夹的链路——那说明前置成本没消化

这四条其实都来自一个观察：碰一碰把"发起分享"的成本压到了一次物理动作，如果后面还挂着三步确认，体验就回到了原点。入口短了，后面的链路必须同样短，且必须可逆。

把"落点即指令"落成工程语言，核心就是一张映射表：触点命中区域 → 业务命令 → 确认策略。五个构想里所有应用层的设计，本质都是在定义这张表：

// 落点 → 命令映射表：应用的核心资产，立项时先定义完再写代码
interface LandingCommand {
  regionId: string;          // 业务区域标识（canvas / layer-panel / readonly ...）
  command: 'INSERT_LAYER' | 'APPEND_RESOURCE' | 'REJECT' | 'QUEUE';
  riskLevel: 'LOW' | 'HIGH'; // LOW 直接执行；HIGH 先轻预览确认
  preview: {
    showThumb: boolean;      // 触点旁展示内容缩略
    confirmLabel: string;    // 确认按钮文案，如"点击插入"
  };
  undoable: boolean;         // 是否支持撤销（对接应用自身撤销栈）
}

// 应用启动时注册映射表；命中判定按"最内层区域优先"
const canvasMapping: LandingCommand[] = [
  { regionId: 'canvas',         command: 'INSERT_LAYER',    riskLevel: 'LOW',
    preview: { showThumb: true, confirmLabel: '点击插入' }, undoable: true },
  { regionId: 'layer-panel',    command: 'APPEND_RESOURCE', riskLevel: 'LOW',
    preview: { showThumb: false, confirmLabel: '点击追加' }, undoable: true },
  { regionId: 'readonly-area',  command: 'REJECT',          riskLevel: 'HIGH',
    preview: { showThumb: false, confirmLabel: '该区域不可插入' }, undoable: false },
];

// 未命中任何区域 → 兜底命令，不猜默认位置
function resolveCommand(hit: RegionHit | null): LandingCommand {
  return hit ? matchByInnermost(hit, canvasMapping) : FALLBACK_QUEUE;
}

这张表为什么值得单列：它是"碰哪传哪"和"碰了再手动放"的分界线。映射表定义得越完整，用户需要的手动修正就越少；映射不了的区域兜底进队列（QUEUE）而不是静默失败，这是判定标准 3 的直接推论。

把映射表跑起来的执行流水线是这样的——触点进来，先过区域命中，再查映射表，按风险等级决定直接执行还是轻预览确认：

图：落点 → 指令的执行流水线。REJECT / QUEUE / CANCELLED 三个出口都不静默失败，这是"失败可拒绝"标准的落地形式

和现有跨设备手段放一起对比，精准分享的定位更清楚：

手段	落点由谁决定	应用参与度	适合内容
投屏/分享屏幕	用户（全屏替换）	无	演示、会议
传统碰一碰/快传	系统（下载目录/接收卡片）	收文件为止	任意文件
拖拽（同屏）	用户（手动拖）	有，但无坐标语义	本机/同屏窗口
碰一碰·精准分享	应用（触点坐标→业务指令）	收指令，定义映射表	可轻预览、可撤销的定向内容

最后一行的"应用参与度"是本质：只有精准分享要求应用理解触点含义，也正因为如此，它才有五个构想的想象空间。

---

二、构想一：办公协同——参考图直插文档

这是我认为落地阻力最小、最先能做出来的构想。

场景：开会时手机上拍了白板、合同、名片，回到工位要把这些参考图放进正在编辑的文档。旧路径：找照片 → 分享 → 等接收 → 切文档 → 拖进合适位置。新路径：打开照片直接碰文档窗口，图落在触点附近，自动生成带图注的附件引用。

用户旅程：

触发链路：拍照页/相册详情页注册 knockShare → 碰触 → 文档应用按 targetWindowId 校验窗口与文档版本 → 坐标换算到页内坐标 → 区域命中（正文/页边距/只读区）→ 轻预览 → 插入。

关键技术点：

• 触点到页内坐标的换算是核心：文档的页框、页边距、分页都是换算参数，碰在页边距上指令应该是"插到该页页尾"而不是失败——落点语义要按区域定义，不能只做二值判定；
• 引用自动补全是体验放大器：插入的不只是图，是"带来源信息（拍摄时间、设备）的附件"，后续找这张图时能直接回溯"哪次拍的"，这一步纯软件就能做，不依赖任何新能力；
• 幂等与撤销沿用姊妹篇的状态机设计，文档场景的 undoToken 直接对接文档自身的撤销栈，用户"Ctrl+Z"就能撤掉这次碰入的图。

边界与风险：

• 多窗口同开时，碰的是哪个窗口由系统识别，应用要处理"识别到的窗口不是用户想给的那个"——轻预览就是给用户纠偏的机会，这一步不能省；
• 只读文档（如受保护合同）碰上去要明确拒绝并说明"该文档为只读"，不能静默落失败。

可交付性：现在就能做。文档应用侧的插入逻辑是现成的，新增的只有"碰触入口 + 坐标换算 + 轻预览"，一个 2 人小团队 1-2 周能出 demo。

---

三、构想二：创意设计——素材甩上画布

做创意的人一天从手机里挪上百个参考图：街拍、配色截图、字体参考、客户发来的素材。这个场景里"碰哪插哪"的价值最直观——画布就是坐标空间，落点语义天然成立。

场景：设计师手机图库里翻到一张配色参考，不想切出来再拖过去（切屏打断心流），直接把手机往画布窗口上一放，素材落在触点位置，自动生成一个新图层。

手机图库（可分享页）──碰──▶ 画布应用
                          ├─ 触点在画布区 → 触点处新建图层
                          ├─ 触点在图层面板 → 追加到面板资源列表
                          └─ 触点在只读预览区 → 拒绝 + 提示

设计草图：触点落图层 + 面板追加 + 只读区拒绝的三区域命中判定（设计草图，正式设计稿待手绘补充）

触发链路：图库图片详情页注册 knockShare → 碰触 → 画布应用换算触点到画布坐标系（完整转换链见姊妹篇第五节：窗口偏移 → 视口偏移 → 缩放 → 滚动 → 旋转）→ 区域命中 → 插入。

关键技术点：

• 三区域命中语义是设计重点：画布区 = 建图层，图层面板区 = 追加资源，只读区 = 拒绝。同一个物理点在不同区域是不同命令，这套"触点→命令"映射表是应用的核心资产，建议在立项时先定义完映射表再写代码；
• 缩放/旋转下的坐标换算：创意软件的高倍缩放和画布旋转是常态，转换链一步都不能省（姊妹篇坑 5 的偏移问题在这个场景是高频）；
• 批量碰：设计师一次碰 5 张图的诉求很真实，但当前能力是"一次碰传当前可分享内容"，批量要么应用侧组织好"可分享内容=选中的多张"，要么等能力支持多内容碰传——这是本构想目前唯一的硬依赖，立项前要向官方确认边界；
• 图层属性继承：碰入的图层应该继承画布当前工具状态（不继承当前选中的画笔，继承的是"新图层"语义），避免把手机里的图直接画到当前编辑图层上污染用户的工作。

边界与风险：

• 大素材（4K 图、短视频）的轻预览要用缩略图 + 大小标注，确认后再传原文件，不能碰一下就阻塞画布；
• 创意软件的状态很复杂（多选图层、路径编辑中），碰触插入要选对时机——正在编辑路径时插入图层要排队到编辑结束，这类"状态机交互"细节决定 demo 和产品的差距。

可交付性：核心链路现在就能做；批量碰需等能力确认。建议 demo 先做"单张碰入建图层"，这一个动作就足以在评审会上说清楚价值。

---

四、构想三：教育课堂——题目投白板

课堂是"一对多"最自然的场景：老师手里的手机，是全班的广播器。精准分享在这里的落点语义是"投到白板的哪个位置"——某道例题旁边、练习区、还是讨论区。

场景：讲题时学生举手机拍错题，老师把手机往白板错题区域一碰，题目落到白板对应位置，全班学生端的互动卡片同步弹出这道题——讲题、投题、学生端同步，一次碰触完成。

用户旅程：

关键技术点：

• 区域 = 教学动作：白板的分区本身就是教学结构的映射（例题/练习/讨论），触点落在哪个分区执行哪个教学动作，这套映射比创意画布的"建图层"更有业务纵深，也是本构想区别于"投屏"的本质——投屏是全屏替换，这里是定向落点；
• 学生端同步走互动卡片：题目投白板的同时，学生端桌面卡片同步弹出，学生不用抬头看白板也能收到"你的题被讲了"的反馈——卡片通道是现有能力，不需要新依赖；
• 匿名化处理：学生错题投白板默认匿名（只留学号后两位），涉及学生信息的图片要过一层脱敏，这是教育场景的合规底线；
• 课堂防抖：一节课 40 分钟、几十个学生轮流碰，入口防抖（姊妹篇坑 2）在课堂是刚需不是优化——多个学生可能同时碰，服务端按 transferId 排队处理，白板上按提交顺序展示。

边界与风险（本构想最需要诚实标注的部分）：

• 一对多扇出是当前能力边界外：精准分享定义的设备对是"手机 ↔ 一台 PC/2in1/Tablet"。老师一次碰触让全班 N 台学生端同步，扇出发生在白板应用的业务层（白板→云端→学生端），不是碰一碰能力本身——技术上成立，但立项时要分清"碰一碰负责什么、业务层负责什么"，别把扇出算进碰一碰的需求里；
• 多学生手机同时碰同一块白板：需要应用层排队 + 顺序保证，白板侧要有一个"接收队列"而不是并发写入；
• 教室环境：白板/教学一体机是否在官方支持的设备形态里，立项前需确认（2in1 形态覆盖是明确的，一体机要看具体机型列表）。

可交付性：单端链路（老师碰白板定向落点）现在就能做；学生端同步走现有卡片/推送通道；"一次碰全班同步"是业务层架构问题，不依赖碰一碰能力升级。

---

五、构想四：游戏互动——设备间投掷

这是脑洞最大的一个方向，也是我反复推演后认为"能力形态最匹配"的场景——游戏里"把东西扔给另一台设备"的交互，天然需要"碰哪投哪"。

场景：双人同屏游戏，A 用手机碰 B 的 PC 游戏窗口，手机里的道具/皮肤/截图直接落进游戏画面里 B 的角色手里或者场地某处——投掷的落点就是碰的落点。

触发链路：手机道具页（可分享页）→ 碰 PC 游戏窗口 → 游戏读坐标换算到游戏世界坐标（这里比画布更复杂：屏幕坐标 → 窗口坐标 → 游戏视口 → 3D 场景平面）→ 落点判定（可投放区域/障碍区/友方区域）→ 道具入场动画。

关键技术点：

• 屏幕坐标到游戏世界坐标的换算是比画布更深的一层：2D 画布是平面变换，3D 游戏要再做一次视口投影（把 2D 触点反投影到场景的某个深度平面，比如角色所在平面）。这一步的数学是现成的，但要和游戏的相机状态（位置、角度、FOV）耦合，每个游戏要单独适配；
• 高频互动的防抖策略不同于办公场景：游戏里"快速连碰连投"是玩法的一部分（比如道具雨），姊妹篇的 1000ms 硬防抖在这里会打断手感。游戏场景的防抖应该是"按 transferId 去重"而不是"按时间丢弃"——同一次碰触的重复回调丢弃，不同碰触全部放行，队列排队入场；
• 落点失败的反馈要游戏化：投到障碍区不是弹 toast，是道具弹开的物理反馈，失败也要有手感。

边界与风险：

• 物理姿态是硬约束：俯视夹角 ≤5° 意味着手机基本要平放，游戏场景里玩家单手举着手机碰屏幕的姿态不一定满足，这是本构想最需要真机验证的点——如果姿态容差偏紧，游戏互动的"随手一碰"就不成立，得降级为"把手机放到屏幕上"的交互设计；
• 延迟敏感度：游戏对"碰→入场"的延迟容忍度远低于办公场景，回调时延 + 坐标换算 + 动画起播的总链路要压到 200ms 量级才有手感，这个需要真机实测标定（姊妹篇的时延数据目前待实测，游戏场景的预算要单独压）；
• 设备对：手机 ↔ PC 明确支持，手机 ↔ 手机的游戏对碰不在当前设备对列表内，"两台手机互碰投道具"要等能力扩展。

可交付性：单设备对（手机碰 PC）链路现在就能做，但 3D 场景换算 + 延迟标定决定了它是最难做出手感的构想，建议放第二批，先出 2D 游戏的简化版（触点直接映射到 2D 场景平面）。

---

六、构想五：智慧出行——行程投车机

出行场景的特殊性在于：接收端是车机，落点语义是"投给导航/投给媒体/投给通讯录"，而且安全边界是第一位的——行驶中的任何交互设计都要让位于"别分散驾驶注意力"。

场景：手机上收到一条新行程（打车确认、会议地点、酒店订单），开车前把手机往车机屏的导航区一碰，路线直接进导航开始规划——不用再掏手机、不用再点"发送到车机"、不用再选目的地。

触发链路与安全边界：

环节	设计	说明
触发时机	仅车辆静止时响应碰触	行驶中碰触不触发、不提示，避免任何分心
落点语义	导航区 = 规划路线；媒体区 = 播放内容；通讯录区 = 存入联系人	三区映射，同白板分区思路
轻预览	车机屏顶部横幅"即将导航至 XX，3 秒后开始，点击取消"	不弹窗不抢焦点，倒计时可撤销
失败降级	车机不在支持列表/能力不可用 → 回退"发送到车机"手动入口	出行场景降级路径必须是用户熟悉的老路径

关键技术点：

// 车机侧接收：静止判定 + 落点映射 + 倒计时可撤销（伪代码）
interface VehicleState { isMoving: boolean; speedKmh: number; }

async function onKnockReceived(ctx: PrecisionShareContext, vehicle: VehicleState) {
  // 安全闸：行驶中一律不响应，不提示，不打扰
  if (vehicle.isMoving || vehicle.speedKmh > 0) {
    hilog.info(0x0000, TAG, 'vehicle moving, ignore knock');
    return;
  }
  const cmd = resolveCommand(hitRegion(ctx.screenPoint), carMapping);
  if (cmd.command === 'REJECT') return showBanner('该内容不能投给车机');

  // 轻预览：顶部横幅 + 3 秒倒计时，用户可随时取消
  const ticket = showBanner(`即将${cmd.preview.confirmLabel}，3 秒后执行`);
  if (await countdown(3000, ticket)) {           // 用户取消或超时
    ticket.cancel();
    return;
  }
  await executeCarCommand(cmd, ctx.content);     // 进导航/进播放/存联系人
}

• "静止才响应"不是 UI 层的事：要接车辆状态（车速/挡位信号），应用层拿不到车辆状态时，最保守的做法是默认要求用户在车机侧点一次确认才开始导航——宁可多一步，不能在行驶中自动起导航；
• 内容门禁更严：进导航的必须是结构化的目的地（地点名称 + 坐标），纯文本、图片不能走"碰一下进导航"的链路，避免把无关内容投进车机；
• 多设备冲突：两人手机都碰车机时，以最后一次碰触为准但要有明确提示"已切换为 XX 的行程"，行程类操作覆盖别人的计划是不可接受的静默行为。

边界与风险：

• 车机是否在支持的设备形态内是最大变量：当前能力明确覆盖 PC/2in1/Tablet，车机形态要看具体车机系统与版本的支持列表，立项前必须向官方确认，否则整个构想的接收端不成立；
• 本构想的很多环节（发送目的地给车机）现有方案已经能做，精准分享的增量在于"落点决定去向"——碰导航区进导航、碰媒体区进播放，省掉的是"选去向"那一步。增量真实但幅度有限，所以放第五位。

可交付性：需等能力补齐——车机设备对支持是前置条件，其余（静止判定、落点映射、横幅确认）都是应用层可实现的。建议现在就把车机侧接收逻辑按"落点映射"的架构写好，等车机进支持列表后直接接入。

---

七、落地分档与下一步

五个构想按依赖关系分两档：

图：分档矩阵——3 个现在就能做、1 个现在可做 demo、1 个等车机能力补齐

构想	姿态稳定性	一对多扇出	设备对覆盖	落点语义复杂度	分档
一：办公参考图直插文档	低要求（平放即可）	不需要	手机↔PC 明确	低（页内坐标）	现在就能做
二：创意素材甩画布	低要求	不需要	手机↔PC 明确	中（画布变换 + 批量待确认）	现在就能做（批量碰待确认）
三：教育题目投白板	低要求	业务层实现	手机↔一体机待确认	中（分区映射）	现在就能做（一体机形态待确认）
四：游戏道具投掷	高要求（姿态容差待验证）	不需要	手机↔PC 明确	高（3D 投影 + 延迟）	现在可做 demo，手感标定需真机
五：行程投车机	低要求	不需要	车机待支持	中（车辆状态耦合）	等能力补齐

分档之外，三个构想在立项前要向官方确认的事：

1. 车机/教学一体机是否在设备支持列表（构想三、五的前置）；
2. 一次碰触能否携带多份内容（构想二的批量碰）；
3. 姿态容差的实际真机表现（构想四的前置）。

如果让我挑一个最先动手：构想一。它的落点语义最清晰、依赖最少、demo 价值最容易在评审会上说清——“拍照 → 碰文档 → 图落在光标处”，三秒演示，不用解释。构想的目的是让"碰哪传哪"从一个能力词条变成一组可以排期的产品，办公文档就是第一块试验田。

---

八、总结与评论引导

回到开头那句话：落点即指令。

精准分享真正的产品机会不在"传得更快"——近场传输的速度从来不是瓶颈。机会在于系统第一次把"用户碰的是哪里"告诉了应用，而"哪里"在文档里是页、在画布里是图层、在白板上是教学分区、在游戏里是道具落点、在车机上是功能入口。同一个 API，落点语义由应用定义，这就是它能长出这么多场景的原因。

工程侧的四道关（能力降级、入口防抖、窗口二次校验、幂等撤销）在姊妹篇里都写过了，这里不重复；做任何一个构想，那四道关都躲不掉，区别只在于落点语义的翻译层怎么设计。

你在构思什么碰一碰的场景？评论区聊聊你的"落点即指令"定义——碰的是哪，你想让它执行什么。有落地进展的也欢迎晒，尤其是姿态容差和延迟的实测数据，目前社区里还缺这部分真机信息。

---

边界与已知限制

限制项	具体表现	规避方式
构想属性	本文为场景构想，非实测结论	已按"现在能做 / 需等能力补齐"分档
能力分期	部分场景依赖尚未开放的能力	先做分档中"现在能做"的部分
设备前提	需要双方设备支持对应能力	接入前做能力检测与降级路径
业务闭环	落点需要接收端有明确业务含义	先确认接收端的数据模型再设计交互
合规边界	跨设备传输涉及数据合规	明确数据范围与留存策略

小结

把"碰一碰"从传文件工具升级为协作入口，关键是把落点映射成业务指令——落到哪一行、哪个窗口、哪个位置，本身就是用户意图的表达。

落地建议是从最刚需、数据结构最规整的场景开始（比如台账行、文档段落），别一上来挑需要复杂坐标映射的场景。工程实现细节见姊妹篇的四道关（降级、防抖、窗口校验、幂等）。

评论区交流: 你的应用里，触点坐标想翻译成什么业务指令？车机/一体机形态的支持情况有消息吗？