5 月 7 日上午，我和 TRAE 的一次闲聊，让我意识到一件事：
最有价值的 AI 交互，恰恰发生在看不见屏幕的时刻——通勤路上的灵感、厨房油腻的双手、跑步机上的碎片思考，每天都在死。
所以我做了一枚戒指：双击就说话，再双击才确认。 没有麦克风常开，没有屏幕，没有 App 抢注意力——只有你的手指按下，AI 才听见你。
但它不是遥控器。当 AI 越强、能调用的动作越危险——订机票、转账、批合同、改配置——软件世界里所有"确认"都可以被脚本伪造：模拟点击、劫持弹窗、借用账号。手指的一次机械按压，伪造不了。
AI 越强，世界越需要一个不可伪造的 “Yes”。 一闪要做的，就是 Agent 时代那个最小、最硬的物理信任入口。
这个项目从 5 月 7 日与 TRAE 的一次对话开始，100+ 轮 session，3 个同事、3 周、从 0 到完整系统。 下面是完整记录。
一、团队介绍
队伍名称：湖头街三剑客
亚伟：本人，创始人&产品经理，Rolekey板块前后端开发，曾是一名连续创业者，0代码基础，前京东产品经理、现就职于即时零售行业
景辉：全栈开发
小余：设计师，交互和UI设计，视频拍摄
我们三个人是原生同事，白天在一起上班，晚上和周末抽空，从复赛开始、从0一起完成了整个项目；缘起是我在某个周末把他们约到了公司的会议室，经过我的一番路演宣讲，说服他们一起加入了这个项目，这也算是我们的第一次纯AI coding项目，也算是发展一份主业之外的兴趣探索。
二、是什么：
一闪 AI Key = 一枚低功耗蓝牙智能戒指 + 一个安卓伴侣 App。它是面向豆包大模型等Agent的离屏物理入口：双击极速发起意图、长按确认执行，一枚戒指完成。
戒指没有麦克风、没有屏幕、没有常开监听——收音交给用户自己已有的蓝牙耳机。
同一套交互协议，既打开个人生活上下文，也打开企业岗位上下文——个人 Key、企业 Role Key 是同一枚戒指的不同身份切片。
一闪是连接个人 AI 与岗位 Agent 的随身入口：在生活里唤起个人 AI，在工作中唤起岗位 Agent，在关键动作前留下真实人的确认。
三、面向谁
两类人，一枚戒指，两层上下文。
第一类：C 端——手机不在手但意图高频产生的离屏人群
20-40 岁、高频使用 AI 的知识型用户，典型身份包括产品经理、程序员、创业者、销售/BD、咨询顾问、内容创作者、科技数码爱好者、律师、投行咨询师…
他们有一个共同特征：高认知、爱效率、常移动、重表达、愿意尝试 AI。场景的本质不是"在哪儿"，而是手脑状态——手不方便操作手机，但大脑正在高速产生想法
| 场景 | 传统路径（意图丢失） | 一闪路径（意图接住） | 戒指动作 |
|---|---|---|---|
| 做饭 | 手沾油，想补货/记菜谱/设提醒，算了 | 双击说出需求，Agent 调用商家服务生成订单方案，耳机播报"28分钟送达，38.6元"，长按确认 | 双击发起 → 长按确认 |
| 开车 | 想记录想法/复盘会议/改导航，但不安全 | 双击唤起 AI，按压瞬间本地采集 GPS 速度判定"通勤速记"场景，直接进入驾驶模式对话 | 双击发起 → 双击继续 |
| 健身 | 想记录训练/问动作/设组间计时，手机不方便 | 跑步机上随口说"对方控制权论点站不住"，戒指+语义编译层将其编译成带论点、证据清单、质证角度的攻防卡片 | 双击发起 → 长按确认整理 |
| 通勤 | 想整理灵感/发待办，懒得掏手机 | 解锁→找App→切语音需30秒和两只干净的手；按一下戒指，3秒开始说 | 双击发起 |
| 会后路上 | 刚开完会想复盘，但上下文散落在飞书/微信里 | （C→B 过渡场景）双击唤起 AI，会议纪要已在上下文中，直接语音复盘客户潜台词 | 双击发起 → 双击继续 |
这不是"省几秒"，而是把原本不会发生的 AI 使用变成真实使用。验证指标不是"用户觉得方便吗"，而是配了戒指后 AI 周使用频次是否超过 5 次、7 日留存是否超过 40%。
第二类：B 端——企业岗位上下文的物理入口
当 AI 从"帮你查"进化到"帮你办"，企业一定会问同一个问题：这一下，到底是不是员工本人想做的？
今天企业 AI 存在一个普遍的两难：官方办公 AI 安全合规但操作繁琐、打断工作流；第三方工具顺滑但数据脱离管控。大量员工自发使用外部 AI 工具——这就是行业里的"影子 AI"。纯软件方案有一个跨不过去的天花板：软件无法确凿证明一次 AI 操作来自真人的主动意愿——账号可以借用、脚本可以模拟点击、弹窗可以劫持。
| B 端场景 | 传统路径（失控或繁琐） | 一闪 RoleKey 路径 | 戒指动作 |
|---|---|---|---|
| 新员工入职 | HR发通知→IT手工配权限→新人加群→自己摸索上下文，需数周补齐 | 企业IT分发RoleKey→员工豆包App完成企业绑定→自动加载岗位权限模板与上下文知识库 | 双击确认接收岗位上下文 |
| 销售总监开会后复盘 | 会议纪要散落在飞书，上车后无法即时调用 | 飞书会议录音/纪要自动同步到该员工豆包上下文→总监上车双击→豆包工作版唤起，已加载会议上下文→语音探讨客户潜台词 | 双击发起 → 双击继续 |
| 敏感操作授权 | 靠账号密码/弹窗确认，无法证明是真人主动发起 | 每次按压生成一条独立Grant凭证：唯一ID、权限精确到单次任务、限时3-10分钟、到期销毁、全链路可审计 | 长按确认执行 |
| 员工离职 | 权限靠IT手工回收，容易漏开/多开；客户关系在前任脑子里，组织记忆丢失 | HR发起离岗→RoleKey冻结→个人权限回收→岗位上下文归档→自动生成交接包→Key回到资管库 | 戒指物理回收/重置 |
| 岗位交接 | 前任离职只交接文档，文档过时、不完整；飞书/邮件/CRM/代码仓上下文割裂 | 前任Key回收→资管登记→IT审批岗位权限模板→继任者实名认证→根据岗位模板重新签发权限→绑定RoleKey→加载720天岗位上下文 | 双击确认接手岗位 |
关键设计原则：继承角色权限，不继承个人密钥——不是把前任的身份交给新人，而是把岗位的记忆、权限模板和工作流安全地迁移给继任者。IT 通过岗位模板重新签发权限，所有操作归属于新员工本人，审计链路完整。
为什么这件事不能由平台自己做？ 物理信任基础设施如果由平台自研，在政企采购里就是既当裁判又当运动员；独立第三方反而能帮生态打开高合规行业。大厂的硬件重心是手机、VR 这种生态级产品，蓝牙外设的模具、供应链、品控、售后，投入产出比不适合亲自下场——最优解是定标准、开接口、认证伙伴
四、完整功能：
C端场景：详见一闪AIkey-C端功能全景
| 模块 | 功能概述 | 主要功能 |
|---|---|---|
| AI Key 硬件入口 | 从「屏幕入口」变成「物理入口」，让用户在通勤、健身、会议、厨房、跑步等离屏场景中，不用解锁手机、不用打开 App，也能通过一颗蓝牙按键快速唤起 AI。它不是简单遥控器，而是一闪 AIKey 的物理意图入口，负责触发、确认和高信任操作。 | 双击开始/结束收音识别蓝牙戒指；1 秒内 DOWN/UP 成对事件判定有效点击；过滤非目标蓝牙设备；后台时按键唤醒 App；前台对话页按键控制语音录制；非对话页按键返回主页；任务确认后生成硬件签名留痕 |
| 待命模式与后台保活 | AI Key 要成为随时可用的生活入口，前提是 App 必须在后台持续「在场」。待命模式通过前台服务、悬浮窗、开机自启、电池优化白名单等能力，让用户双击按键时可以稳定唤起 AI，而不是每次都重新打开 App。 | 一键开启/关闭待命监听；前台保活服务常驻通知；后台悬浮窗快速返回 App；开机和用户解锁后自动启动保活；进入后台启动悬浮窗、进入前台停止悬浮窗；首页展示待命状态呼吸灯；AI 待命准备度评分；6 项权限状态检查；未完成项跳转系统设置引导 |
| 核心对话引擎 | 一闪的对话不是普通聊天，而是「语音输入、AI 理解、流式回复、语音播报」的任务型交互闭环。用户可以说话，也可以打字；AI 会根据当前身份、场景和模板生成更贴合当下任务的回答，并保留多轮上下文，让对话能持续推进。 | 文字输入发送；按住说话语音输入；火山引擎 ASR 实时识别；语音/文字模式切换；SSE 流式逐字输出；打字机效果与 typing 动画；AI 回复结束后 TTS 自动播报；按 conversationId 隔离多轮上下文；本地保存会话和消息；侧边栏展示最近对话；支持新建对话和历史会话切换 |
| 身份 × 场景 × 模板三层路由 | 一闪希望解决普通 AI 助手「什么都能聊，但不够专业」的问题。系统把用户当前身份、所处离屏场景和工作流模板组合起来，自动编译成更合适的 Prompt，让 AI 不再只是一问一答，而是进入特定角色和场景下的专业工作流。 | 首次启动选择职业身份；支持产品经理、律师、医学科研、投研等长期身份；支持通勤速记、力量训练、会议标记、厨房待办、跑步灵感等场景；场景页选择默认场景；根据场景展示工作流模板；模板选择后缓存到本地；首轮对话固定当时的场景配置，后续变更不影响已有会话；首页上下文卡片同步身份、场景、模板 |
| 任务级授权与审计 | 一闪的核心信任机制是「每次只授权当前任务」。AI 不能默认拥有持续权限，用户必须在看到本次任务能做什么、不能做什么、多久失效之后，通过硬件双击完成确认。所有授权都会留下记录，用户可回看每一次 AI 操作的范围和依据。 | AI 回复下方展示授权预览；展示允许操作、禁止操作和有效期；物理双击 AI Key 确认任务；授权任务完成后自动失效；日志页展示授权类记录；根据是否包含 Tool-Date 区分纯对话、授权、对话+授权类型；展示任务场景、身份、摘要、时间、轮次、有效期；硬件确认生成签名摘要留痕 |
| 日程与待办工具 | 一闪不止回答问题，还能把用户的自然语言转成可执行事项。比如用户说「明天下午三点提醒我开会」，AI 会识别出日程意图并生成结构化工具块，端侧解析后写入系统日历；当用户表达待办时，也能把对话内容沉淀成待办事项。 | 识别日程/提醒意图；AI 输出 [Tool-Date] 工具块；将明天、后天、下周等相对时间换算成具体时间；动态申请日历权限；写入系统日历事件；非日程意图不输出工具块；识别「待办/代办」关键词；将 AI 回复内容添加为待办；待办列表展示；支持待办新增、删除、编辑、标记完成；待办存入本地 SQLite |
| 设备管理与系统设置 | 为了让 AI Key 从 Demo 变成可日常使用的硬件入口，产品提供了设备管理和系统设置能力。用户可以查看当前连接设备、绑定新设备、查看连接状态，也可以进入模型、待命、权限等设置项，把设备和 App 调整到最适合自己的状态。 | 展示当前已连接设备；展示设备名称、连接状态；绑定新蓝牙设备；进入蓝牙配对流程；查看设备详情；修改设备名；查看固件版本；解绑设备；个人中心展示用户信息；进入设备管理、模型 API 设置、待命准备度、待命开关等系统设置入口 |
| AI 云端服务 | 后端 FlashThoughts 是一闪的 AI 大脑，负责把端侧传来的用户输入、身份、场景和模板组织成模型可理解的请求，再通过流式方式返回结果。它同时支持模型配置、用户绑定、上下文记忆、日志记录等能力，让 AI 不只是单机聊天，而是可配置、可运营、可排查的服务。 | Spring Boot 后端服务；JWT 鉴权；SE 流式对话接口；Spring AI 多轮上下文记忆；MessageWindowChatMemory 最大 20 条消息；按 conversationId 隔离会话；三层系统提示词拼接；火山方舟 Ark SDK 接入豆包模型；用户绑定模型配置优先；默认模型兜底；ArkService 按 apiId 缓存复用；配置变更后清理缓存；支持清空上下文 |
| 模型与 API 配置管理 | 一闪的模型能力不是写死在系统里的，后台可以配置不同的大模型 API、模型名称、优先级和可用状态，也可以为不同用户绑定不同模型。这样既方便测试不同模型效果，也能支持用户自备 Key 或后续多模型策略。 | API 配置增删改查；配置 baseUrl、API Key、模型名、是否默认、优先级、状态；API 与用户多对多绑定；用户对话优先使用绑定 API；无绑定时使用默认 API；调试对话可指定 apiId；配置修改或删除后自动失效对应 ArkService 缓存；支持 Hojo SDK 全双工对话、ASR、TTS 能力开关 |
| 身份与模板管理后台 | 产品里的职业身份和工作流模板由后台统一维护，而不是写死在客户端。运营或管理员可以新增身份、编辑模板、设置默认模板、调整提示词，让一闪可以持续扩展到更多职业和更多场景，而无需每次都重新发版。 | 身份管理 CRUD；身份名称和描述维护；身份导出；身份切换时自动绑定默认模板；模板管理 CRUD；模板名称、描述、评分、标签、提示词维护；一个身份下支持多个模板；设置默认模板；模板切换时回填所属身份；身份切换、模板切换记录业务日志 |
| 业务日志与问题排查 | 一闪不仅要能运行，还要能被运营和研发持续调试。后端会记录 AI 对话、身份切换、模板切换等关键业务行为，后台可按用户、类型、时间检索，让问题排查不再依赖服务器 grep 日志，而是进入可视化、可追踪的管理流程。 | 记录 ai_chat、switch_identity、switch_template 三类日志；记录用户、API 配置、会话 ID、目标 ID、目标名称、输入文本、系统提示词、输出结果、状态、错误信息；异步写入业务日志，不阻塞流式响应；后台按日志类型、用户、时间检索；支持错误排查和模型效果复盘 |
| 端侧数据与隐私控制 | 一闪采用本地优先的设计，用户的会话、消息、待办和部分授权记录优先保存在端侧，降低对云端的依赖。系统权限也采取按需申请原则，只有在用户触发语音、日历、通知、悬浮窗等功能时才引导授权，让用户知道为什么要开权限。 | SharedPreferences 保存 token、引导状态、身份、场景、模板；SQLite 保存 conversations 会话表；SQLite 保存 messages 消息表；SQLite 保存 todos 待办表；本地加载历史对话；端侧保存待办事项；按需申请录音、日历、通知、悬浮窗、电池优化、无障碍等权限；支持清除历史；EdgeToEdgeHelper 统一沉浸式状态栏适配 |
| 管理后台与数据存储 | 为了支撑长期运营，一闪在服务端建立了完整的数据表结构和管理能力。MySQL 负责身份、模板、用户绑定、API 配置和业务日志，Redis 用于缓存与配置加速，端侧 SQLite 负责本地会话和待办，让整个系统既能快速响应，也能长期沉淀。 | MySQL 存储 ft_identity 身份表；ft_identity_template 模板表；ft_user_identity 用户身份绑定；ft_api_config API 配置；ft_api_user API 用户绑定；ft_business_log 业务日志；Redis 缓存 ArkService 客户端、会话辅助信息、配置读取；端侧 SQLite 保存会话、消息、待办；ft-ui 管理后台基于 Vue 2.6 + Element UI 实现 |
B端场景：详见RoleKey 功能全景：Agent 时代的岗位数据物理授权入口
| 模块 | 功能概述 | 主要功能 |
|---|---|---|
| RoleKey 硬件入口 | 员工佩戴的物理授权载体，所有敏感操作必须由真实硬件按键背书 | BLE GATT 真实通道接入、单击/三击/双击三段式手势、事件签名、设备唯一标识、防重放攻击 |
| 三步物理授权 UI | 把"知情同意"这件事做成看得见的物理动作，杜绝点了就过 | 在场→知情→承诺放行三步骤进度条、手势语义提示、Step 锁定/解锁动效、授权前预览清单 |
| Android 员工端 App | 员工唯一入口，承载硬件监听、状态同步、网关容器、兜底提示全职责 | BLE 事件监听、保活前台服务、开机自启、设备状态实时同步、WebView 网关容器、音量键辅助触发通道、设置页动态配置后端地址 |
| H5 网关上下文页 | 后端动态下发的岗位数据门户，被授权员工可看到对应岗位的聚合知识 | 岗位上下文页（90D/720D 双包型适配）、今日上下文页（6 数据源长文本）、ROI 岗位价值锚定面板、岗位 ROI 数字动态计算 |
| Fallback 三态兜底 | 未到交接节点或设备异常时，强制拦截并给出清晰下一步指引 | WAIT_CONFIG 待配置（蓝）、WAIT_FLOW 待授权（琥珀）、BLOCKED_SECURITY 安全拦截（红）、三态差异化图标/文案/配色、副标题不截断自适应换行 |
| IntentGrant 物理授权协议 | 自研授权凭证标准，定义"谁授权、授什么权、授多久、留什么痕" | grant_id 凭证号、grantor/grantee 双方身份、permission_scope 权限范围、ttl 有效期、risk_level 风险等级、physical_action 物理动作、audit_trail_hash 审计哈希 |
| GestureEvent 手势事件协议 | 统一硬件事件上协议层，协议与硬件形态解耦 | event_source 来源标签（BLE / 音量键 / 物理按键 / 系统管理）、gesture_type 手势类型、timestamp 时间戳、device_id、trace_id 链路追踪 |
| Handover 交接工单引擎 | 驱动岗位交接流程的状态机，员工必须按节点操作 | 5 状态流转（CREATED→APPROVED→DISPATCHED→COMPLETED / REJECTED）、硬门禁校验、未到节点强制 Fallback、审批/下发/确认全流程可追溯 |
| 岗位上下文聚合服务 | 自动聚合多源数据生成可下发的上下文包，让交接价值可量化 | 90D 快速上岗包（近 3 个月会议/客户/项目）、720D 岗位知识传承包（2 年隐性知识）、6 数据源聚合（会议/企微/CRM/邮件/飞书审批/待办）、ROI 动态计算（工时/成本/释放倍数） |
| 设备生命周期管理 | 像管理工卡一样管理硬件与员工的绑定关系 | 设备绑定/激活/冻结/挂失/回收全生命周期、bindStatus 五态（UNBOUND/ACTIVATED/FROZEN/LOCKED/REVOKED）、报失后硬门禁即时生效、failCount 防爆破锁定 |
| 全链路审计中心 | 每一次授权、每一次访问都留下可出证的留痕 | 审计日志 9 字段模型、event_source 区分事件来源、风险等级标记、权限使用清单、全链路 trace_id 串联、授权记录不可篡改、支持管理员按人/设备/时间检索 |
| Web 企业管理后台 | IT/HR 管理员一站式操作台，交接工单、设备台账、审计日志在此管控 | 工单创建/审批/下发、设备绑定/挂失/冻结/解绑、审计日志检索与展示、event_source 可视化标签、Ctrl+Shift+D 演示一键恢复、演示模式幂等重置 |
| 双账号鉴权体系 | ADMIN（企业管理员）与 EMPLOYEE（员工）账号物理隔离 | JWT Token 身份区分、接口级权限拦截、员工端仅访问本人绑定设备、管理员态操作全部打 SYSTEM_ADMIN 标签 |
| 演示模式与评审辅助 | 方便路演/评审/培训场景秒级复位，不用清数据重搭环境 | /api/admin/demo-reset 幂等重置接口、管理端按钮 + Ctrl+Shift+D 快捷键、复位后所有工单/审计/设备状态回到初始演示态 |
五、相比初赛 Demo 的升级
对比初赛帖子——C端链路除了对话交互其余的功能均为html原型，复赛阶段则完全原生化落地，并将对话交互重构；服务端方面，初赛为0，本次从0到1搭建。
按钮背后的护城河：Prompt 编译层【初赛为纯html前端】
用户在 App 里设定自己的身份——律师、咨询顾问、投研分析师。他在跑步机上说的碎片口语，不会原样丢给大模型，而是经过我们的编译层：结合身份、场景和历史模板，编译成一条结构化的专业 Prompt，再发给豆包。
律师晨跑时随口说的"对方那个控制权论点站不住"，会变成一张带论点、证据清单、质证角度的攻防卡片。
按钮不稀缺。按钮后面接的语义编译和场景模板，才稀缺。——硬件容易被复制，行业 know-how 的模板资产，复制不了。我们复赛正是花大力气打造了这套架构。
B端链路方案，初赛完全无，本次从0到1搭建。
| 应用概述 | |
|---|---|
| Rolekey应用端+企业信息管理后台 | RoleKey 应用端是员工佩戴硬件后的"AI 时代数据工卡"入口，配合企业信息管理后台，让 HR / IT / 业务部门得以像管理工卡一样管理岗位数据授权：管理员选好上下文包一键下发，员工按 3 次物理按键完成知情承诺，审计层对每一次 Agent 调用、每一次岗位上下文访问全链路留痕可追溯，最终实现 “新员工当天上岗、离职员工知识不流失、敏感操作有物理背书” 的企业落地闭环。 |
| IntentGrant物理授权协议标准（自研）-问卷有全文 | IntentGrant 是一闪自研的物理授权协议标准，面向各 Agent 生态开放：用户一次物理按压（单击在场 / 双击确认），即生成一份单次、限时、最小权限、全程可审计的 Grant 凭证——软件无法伪造、不可重放、到期自毁。对 C 端，它是"双击发起、长按确认"的零门槛体验；对 B 端，它是每一次敏感操作的物理背书与审计依据；对未来的 A2A 生态，它是 Agent 委托链"等待授权"状态的通用物理答案——最终实现"只读零摩擦、写操作必确认、一次一授权、全程可追溯"的 Agent 时代授权闭环。 |
六、产品演示视频:
C端产品：https://v.douyin.com/FQhUpTAc_ek/
B端产品（企业与员工端）：https://www.bilibili.com/video/BV1vCum6DEtK/?share_source=copy_web&vd_source=45fae91b50bd851d8f2daacc1ce67e85
以及C端的管理后台：
1、C 端叙事片（6’23"，抖音）：一闪不是语音助手，是物理入口驱动的个性化 AI 工作流
手机任意界面双击戒指直接唤起 AI——不用解锁、不用找 App。进去之后你会看到一闪和普通语音助手的本质区别：身份 × 场景 × 模板 × 调优四层设置页——你可以是商事诉讼律师、投研分析师或产品经理，每个身份背后是不同的知识结构、交互规则和表达风格。04:12 前后的"调优"页是全片题眼：点击"预览编译后 Prompt"，能看到用户的碎片口语如何被编译成"先给结论、按模板分层、不确定信息标注待确认、给出下一步行动"的结构化指令再交给豆包。按钮不稀缺，按钮后面这层 Prompt 编译才稀缺。 结尾覆盖通勤、跑步、会议、厨房、车辆保养五个真实离屏场景。
2、B 端 RoleKey 叙事片（7’03"，B 站）：企业物理授权入口的最小闭环，含异常态
这是三段里最重的一条。RoleKey Console 企业后台完整呈现岗位交接全链路：IT 管理员创建交接工单 → 审批下发 → 员工绑定 RoleKey → 物理按键三步确认 → 审计闭环。重点看三处：上下文包——新员工拿到的不是账号权限，而是 90 天快速上岗包和 720 天岗位知识传承包（会议、客户、项目、隐性知识）；审计日志页——grant_id、physical_action、permissions_used、时间戳，每一次授权调用都有字段级留痕；"上报丢失/临时冻结"弹窗——设备丢失后即刻冻结其签名与授权能力、上下文数据不动、复核后可恢复。企业级产品和玩具的区别，就在这个异常态里。
3、C 端管理后台（1’46"，录屏）：证明 Prompt 编译层不是写死的 Demo
这条短片回答一个问题：上面的身份、场景、模板是硬编码的演示数据吗？不是。后台里有完整的 API 配置管理（多模型接入、API Key、优先级、绑定用户、默认兜底）和模板管理（模板名称、所属身份、评分、标签、默认项、编辑弹窗）。也就是说，新增一个职业身份、调一版工作流模板、切换一个模型，都不需要发版——这套系统是可配置、可运营、可迭代的。这是"产品"和"Demo"的分水岭。
七、产品创作历程：
不同于其他已诞生产品再来到TRAE的项目，或者创始人很早就沉淀的一个idea
一闪是一个TRAE原生项目（Born in TRAE），因为我做这个项目的第一个原始痛点洞察闲聊，就是从和TRAE的一次对话开始的。
5月7日上午我像往常一样打开TRAE，但这样一条简单的探讨，却是我们梦开始的地方。（sessionID：.1593641625198136:562dadfe947a3efd125e39944b5612fe_69fbf5201856b287fd24f732.69fbf5a81856b287fd24f769.69fbf5a7a342a700b9c9da46:Trae CN.T(2026/5/7 10:15:04)）经过几天和TRAE连续的对话之后，我梳理完成了自己的逻辑脉络，最终发表了文章。
五一假期我在折腾 CarPlay 接入豆包失败后发现：最有价值的 AI 交互恰恰发生在看不见屏幕的时刻——通勤路上知识工作者的"想法流"每天流失，而一个可盲操作、有触觉反馈的物理按钮，就是把这些碎片化思考捕获为结构化资产的容器；交互的重心正从屏幕图标、转向物理世界的锚点，谁定义这个按钮，谁就定义下一代 AI 交互的接入范式。
5月17日我写下《杀死App？一个按钮可能定义下一代AI交互入口》发布在我的个人公众号，6月又发表在了人人都是产品经理社区（ 杀死App？一个按钮可能定义下一代AI交互入口 | 人人都是产品经理 ）
6月16日，我正式报名了大赛，初赛过程中，为了快速demo，我采用的是APP壳子内嵌豆包网页版（Android 原生架构，Kotlin+Compose，借无障碍、前台服务和悬浮窗实现音量键双击唤起、常驻监听与轻量交互）的形式，虽然跑通了产品初版的主链路，也让我拍摄出了产品场景视频（https://www.bilibili.com/video/BV143Nt6TERy/?share_source=copy_web）。
但是，面临的最大的问题是，外设蓝牙key的按键交互，侵占了手机系统的“音量增大”，这在用户体验上是无法接受的。
因此，进入到复赛阶段，我们选择了从头原生化打造一个“豆包式”的Agent对话界面。同时，我们顺手把蓝牙按键，升级为了智能戒指，以便贴合场景本身的便携性和随身性。
正是拍完初赛的场景视频之后，我突然有了一个大胆的畅想：假设场景视频里的这位销售总监，坐上车子的时候，通过一闪AIkey唤起豆包对话，而他的个人豆包，早就无缝被授权衔接了，可以去读取他企业飞书里面的上下文呢？–而一闪AIkey正是满足这个场景，最重要的鉴权随身硬件——它用物理按压证明了"此刻是企业授权员工主动发起的请求"，通过 IntentGrant 协议生成限时 Grant 凭证，桥接个人豆包与企业飞书的身份和上下文，让总监在车里双击一下，就能带着完整上下文（如今日会议纪要）与豆包对话，且全程可审计、离职即回收。
一闪不是想做一个独立的 AI 戒指孤岛。
我真正想表达的是：未来一个人应该拥有同一个低干扰 AI 入口，但它在生活里连接个人 AI，在工作中连接岗位 Agent。
C 端是个人上下文，B 端是岗位上下文；底层共用同一套 IntentGrant 物理授权协议。低风险动作自动走，高风险动作等人用随身硬件确认。
作为外部创业者，我只能用自己的 App 把这套愿景 Demo 做出来。但真正完整的形态，很可能是豆包和飞书合流之后的下一代入口。
在初赛原本提交的demo官网中，上述叙事本来是完整的，但我考虑到理解成本，以及赛事开发的时间紧迫性，把B端叙事整个去除了。
在复赛过程中，让我坚定把这个叙事加回来的，是一个核弹级的新闻：7月30日，字节跳动进行重大组织架构调整，飞书产品团队正式并入豆包产品团队，飞书负责人向豆包负责人汇报。这标志着"飞书优先服务豆包大模型战略"落地，与我之前在TRAE聊天里面推演的"豆包工作版+飞书上下文底座"的终局形态完全吻合：AI Agent时代的"大模型与企业上下文合流"
在AI Agent跨越到“改变现实”的早期，我推演大模型要真正进入企业工作流，必然要与协同办公系统深度打通。我预判字节一定会将"豆包"与"飞书"整合，飞书将从独立SaaS演进为豆包的“企业上下文底座”，使豆包成为随员工身份激活的"工作大脑”。
在几天之内我就决定，自己把这套B端叙事用产品化的形式开发出来，由于小伙伴们都还在打磨C端，我决定一个人单干，最终，在不到4天的时间里，我真的把这套涉及（从一枚物理按键触发、员工三步确认、IT管理员后台建单审批下发，到离职员工岗位知识一键打包、新员工当天上岗对接、每次数据访问全程留痕可追溯）的复杂系统和TRAE一起开发出来了！
顺着往下推演，我又梳理出车内人机新交互、车主预约保养两个未来A2A的典型场景。这两个场景虽然在今天还未完全成型，但它们揭示了一个确定性的趋势：当 Agent 从"帮你查"进化到"帮你办"，跨应用、跨设备、跨厂商的 A2A 执行链将成为日常基础设施。 而每一条执行链，都必须回答同一个问题——这一下，到底是不是用户本人此刻主动想要执行的？
| A2A场景 | 描述 | 备注 |
|---|---|---|
| 车内人机新交互 | 车主双击一闪AI Key发起语音任务，手机主Agent调度微信Agent读取小李位置，经高德Agent规划路线启动导航，再由车机Agent投屏座舱，全程委托日志审计。车内强离屏场景下，用一句话完成跨App跨设备协作。 | 一闪AIkey — 一键直达，灵感不等待 |
| 车主预约保养 | 车主双击AI Key发起保养预约，Agent并行读取日历与4S店空档；涉及支付定金等高风险写操作时触发安全拦截，用户长按一闪AI Key物理确认、生成IntentGrant凭证后完成预约，全程委托日志可审计。 | https://www.bilibili.com/video/BV1LR3C6yEun/?share_source=copy_web |
软件可以模拟点击、模拟语音、模拟网络请求，但它伪造不了手指这一下机械的按压。OAuth 回答"你是谁"，而我们负责回答"此刻是不是你主动想执行"。这就是一闪 AI Key 在未来生态里不可替代的位置：A2A 执行链中的物理确认锚点。
我们今天做的不是一颗蓝牙按钮/蓝牙戒指，而是一枚面向 Agent 时代的物理信任入口。小米键绑小米全家桶，比亚迪键绑比亚迪闭环——跨N厂的中立外设，只有第三方能占。
不远的将来，当 A2A 协议标准化落地、当每一个 Agent 都需要人类确认才能执行敏感操作、当监管开始要求 AI 执行链必须留痕可审计——这个生态位置，不是可选的，是必然不可或缺的。
我们提前布局的，正是这一下。
由此，“同一枚戒指，三次身份升级”：
C 端：一闪 AI Key 是离屏场景的意图入口——双击发起、长按确认，让手够不着屏幕时，灵感也能直达 AI。
B 端：RoleKey 把同一枚硬件变成岗位信任密钥——每次按压生成限时、可审计的授权凭证，回答"此刻是不是你本人想做"。
未来 A2A：当 Agent 互相委托任务，IntentGrant 让整条委托链知道——最初那一下，是人类真的想做。
真正让我更加笃定的，是后来发生的事。
7 月 15 号，清华大学、北京大学、香港大学联合研究团队开源的 AOHP 框架，把"修改账户和订单状态的操作，Agent 必须让人类手动确认"写成了工程共识。–https://mp.weixin.qq.com/s/7E-LWv8bdKr8dG81xBl7yQ（清华大学智能产业研究院）
7 月 17 号，阶跃星辰董事长印奇在 WAIC 开幕式主论坛上向全行业发问：智能体代表谁行动？后果谁负责？如何可信、可控、可追溯？https://mp.weixin.qq.com/s/-3nMvD28-XYc9wq-WBmiqg
而我的那篇文章，比他们早了整整两个月。
学界和产业界在同一个7月指向同一个缺口——物理世界的确权。我们做的 IntentGrant 物理授权协议，就是想给出一份可以戴在手指上的答案。
未来，A2A 让 Agent 可以互相委托任务，但委托链越长，「人到底同没同意」就越模糊（会否是某个系统级Agent自作主张？）
IntentGrant物理授权协议（一闪自研）就是为这条链设计的——链上每一次关键动作，都有一枚戒指按压签发的、限时的、可审计的凭证。A2A 解决 Agent 之间的信任，IntentGrant 解决人对整条链的信任。———没错，IntentGrant协议，就是我们在复赛中核心自研的全面协议。
它贯穿 C 端和 B 端，是同一个协议在两种场景里的显形：在 C 端，它是 AI Key 的每一次双击与长按——用户发起意图、确认执行，每个动作都生成一份带唯一 ID 的授权凭证；在 B 端，它是 RoleKey 的"单击在场、三击知情、双击承诺"——岗位交接的每一步物理确认，都写入审计链，全程可回溯、可追责。
技术上，IntentGrant 有四条硬特性：单次性——权限精确到"这一次任务"，不可重放、不可截留；最小化——授权范围收缩到具体对象与动作，拒绝一揽子授权；限时性——凭证 3-10 分钟自动销毁，过期即失效；可审计——从按压、确认到执行，全链路留痕。同时按风险分级：查询单击、确认双击——摩擦与风险成正比。
更重要的是它的拓展性。IntentGrant 从一开始就是按"协议"而不是"功能"设计的：今天的 Lite 版跑通 C 端交互，Full 版支撑 B 端岗位授权与审计，而它的凭证结构天然可以挂载到未来 A2A 协议的"等待授权"状态上——当 Agent 互相委托任务成为常态，IntentGrant 就是那条委托链上，证明"最初那一下是人类真的想做"的物理凭证标准。
一套协议，三个阶段，同一枚戒指。
最后，需要说明的是，协议标准中规划的 SE 安全芯片、设备证书与国密协处理器，属于量产阶段的硬件信任根，本次赛事版本暂未搭载。但这不是妥协，而是架构分层带来的从容：七层架构在设计之初，就把"业务价值验证"和"硬件信任根"拆成了两个独立问题——上层六层全部真实跑通，接口契约已与 SE 方案对齐，未来接入硬件安全层时，上层业务零改动。
我们的路线很清晰：先把业务闭环验证真，再把硬件加密做硬。有限的时间里，我们选择把每一层做实，而不是把每一层做虚。
八、TRAE 实践过程:
我从大学开始就有创业经历，所以我很清楚“前 AI 时代”做一个产品意味着什么：你要自己查资料、搭团队、做原型、反复试错，很多想法还没被验证，就已经被成本消耗掉了。
有了 TRAE 之后，我的感受不是“写代码变快了”这么简单，而是我像拥有了一个 24 小时待命的项目参谋总长。每一轮对话都不是从零开始，而是在上一轮认知上继续加层、修正、升级。它能吸收我的行业判断、用户反馈和产品直觉，再帮我把它们压缩成方案、原型和叙事。
所以一闪不是我临时想法做出来的一个硬件 demo，而是一个从 4 月就开始反复推演的 AI 时代命题。
TRAE对创业者最大的改变，不只是提高执行效率，而是把一个人的认知迭代速度，推到了过去一个小团队才有的级别。
（这里仅罗列了编码层面的重要轮次，TRAE对我们更重大的意义我认为是“唯一集成工作台”，这里我在最后的【十二】会详细阐述）
1593641625198136:f7b45a5ad21c260703234718c88e0ff0_6a71f2d2757a7d0e929c4170.6a71fe3b757a7d0e929c4277.6a71fe3b757a7d0e929c4275:TraeWork CN.0.1.46.no_sid.no_ppe.T(2026/8/4 22:59:07)
1593641625198136:8ad426e4d87ad129b6912524a9833556_6a71f2d2757a7d0e929c4170.6a72cede5897dcc36252b504.6a72cede5897dcc36252b502:TraeWork CN.0.1.46.no_sid.no_ppe.T(2026/8/5 13:49:18)
B端Rolekey板块TRAE开发-从概念到可部署系统的工程联调记录：（踩坑实践）
本项目最大技术创新在于构建了“APK原生壳 + 网关WebView + 后端鉴权”的安全访问层：通过硬件Key授权状态、Token、上下文入口与后端网关路由联动，实现岗位/今日上下文的受控访问，兼顾原生体验、H5灵活性和企业级权限管控，形态独特。（实拍视频里面，我也着重演示了这个点，就是设备上报丢失则端上立刻访问失效，正是得益于网关实时校验）
这个项目最大的难点不是功能复杂，而是：
APK、H5、后端、管理后台、正式部署环境之间的状态、路径、语义必须完全一致。
*这些问题已经在最终版本中完成修复，形成了“硬件触发 - 网关上下文 - 后端鉴权 - 企业授权态 - 审计日志”的最小闭环。
这些坑本质上不是页面 Bug，而是 RoleKey 作为企业级物理授权入口必须跨端保持一致的工程校验：同一枚 Key、同一个员工、同一个岗位上下文，在 APK、H5、后端和正式部署环境里必须被识别为同一个授权主体。
| 坑 | 表面现象 | 根因 | 最终修复 |
|---|---|---|---|
| 今日上下文与岗位上下文混淆 | 入口语义与路由未隔离 | H5 / 后端 / APK gateway 链路没有彻底隔离 | 拆分 today / role 路由、entry、mode、展示 |
| WebView 授权态显示异常 | 实际已授权但 UI 显示失败 | 客户端状态文案映射错误 | ACTIVE 直接显示「已授权」 |
| 审计日志误识别为模拟点击 | 如果要视频演示会显得很假 | event_source 和前端映射还停留在 MOCK_BUTTON | 改成蓝牙key点击，并强刷最近日志 |
| 内网地址保存异常（闪退） | 点保存直接崩 | Retrofit baseUrl 缺协议或尾斜杠 | 自动补 http:// 和 / |
| 云端后端Base URL 配置错误 | APK 显示后端失败 | 8305 是 Nginx 静态站，API 在 8304 | 默认 Base URL 改成 8304 |
| Release 签名包缺失 | debug/testOnly/签名问题 | 不是标准 release signed APK | 生成临时 keystore，打 release 签名包 |
| 网关兜底路径拼接异常 | 上下文白屏 | baseUrl 末尾 / + path 开头 / |
state.baseUrl.trimEnd('/') 后再拼路径 |
1593641625198136:5df156a5effacbe5c532754d54300672_6a6598c3e2ac3c3e449170ff.6a6a0c82d6669760cbc4152d.6a6a0c81d6669760cbc4152b:TraeWork CN.0.1.45.no_sid.no_ppe.T(2026/7/29 22:21:54)
1593641625198136:c0ff2d71e51f3290a05cc4615fb6c697_6a6598c3e2ac3c3e449170ff.6a68b7ced6669760cbc40e73.6a68b7ced6669760cbc40e71:TraeWork CN.0.1.45.no_sid.no_ppe.T(2026/7/28 22:08:14)
C端AIkey：TRAE主导完整调通硬件连接
项目核心特点：硬件键控流式语音交互：蓝牙AB Shutter3遥控实现全语音操作，按键唤醒-收音-打断全链路硬件触发；三级标点断句+双向等待机制实现火山TTS真正流式边收边播零等待；配合后台悬浮窗保活与前后台自动切换，打造免触屏AI随身助手体验。
这部分不是简单的蓝牙按键演示，而是在验证一枚 AI Key 是否能够稳定完成“唤起 AI、表达意图、流式播报、前后台切换、确认执行”的完整用户路径。为此，我们围绕蓝牙按键拦截、设备识别、TS 播报和系统唤醒逻辑做了多轮工程修复，最终形成了可复现、可演示、可连续操作的 C 端体验闭环。
这些工程问题本质上不是小 bug，而是在验证一枚 AI Key 能否真正做到“抬手即达、唤起即用、确认即行”。
蓝牙按键拦截（3次方案重构）
需求：拦截AB Shutter3蓝牙自拍遥控器的按键事件，实现硬件触发操作。
方案迭代历程：
- 第一版：AccessibilityService
- 坑1：
android:exported=false→ 系统无法识别和绑定服务，功能完全失效 - 坑2：服务在进程重启后显示"服务故障" → 服务中调用
ActivityManager.getRunningAppProcesses()在部分Android ROM上触发异常崩溃 - 坑3：XML配置了不必要的flag（如flagRequestTouchExplorationMode等）导致部分系统解析配置失败
*
- 坑1：
- 第二版：精简AccessibilityService
- 最小化配置（仅保留flagRequestFilterKeyEvents，accessibilityEventTypes为空，notificationTimeout=0）
- 所有生命周期方法和事件处理加全try-catch保护
- 将前后台判断逻辑移到MainActivity的广播接收器中
- 结果：仍然不稳定，部分机型重启后还是会出问题
*
- 最终版：dispatchKeyEvent直接拦截
- 完全删除AccessibilityService相关代码和配置
- 在
MainActivity.dispatchKeyEvent()中直接拦截KEYCODE_MEDIA_NEXT和KEYCODE_MEDIA_PREVIOUS事件 - 通过InputDevice名称匹配"AB Shutter3"设备
- 结果：从根源解决服务重启问题，稳定可靠
*
额外约定：
- 双击检测：400ms时间窗口，需要两个相同keyCode的UP事件才触发，防止误触
- 按键行为逻辑：
- App在后台 → 唤醒到前台
- App在前台且在聊天页 → 切换录音状态（未录则开始，录了则停止提交）
- App在前台但不在聊天页 → 导航到聊天页
蓝牙设备检测（LT3688/AB Shutter3连接状态）
坑点：明明手机已经配对连接了蓝牙设备，但App检测不到。
原因：
- 初始代码只检测HEADSET（头戴式）和A2DP（高保真音频）两个profile
- AB Shutter3/LT3688是蓝牙HID设备（Human Interface Device，profile ID=4），不在音频profile列表中
- Android SDK没有公开的HID设备连接状态API
*
解决方案：
- 添加BLUETOOTH_CONNECT权限适配Android 12+
- 遍历所有已知Bluetooth profile（ID从1到14），包括HID_DEVICE
- 使用反射调用隐藏API
BluetoothDevice.isConnected()获取真实连接状态 - 添加1.5秒初始检测延迟，等待系统蓝牙服务就绪
- 每5秒轮询一次连接状态，更新侧边栏UI显示"设备已连接/未连接"
最难坑点：TTS流式语音播报（累计修复8+次）
问题描述：
TTS（火山引擎语音合成）总是播到一半就停止，最后几个字读不出来，当回复开头包含[Tool-Date]标签时甚至完全不发声，前后经历十几次迭代才彻底解决。
踩坑过程与解决方案：
| 问题现象 | 根本原因 | 解决方案 |
|---|---|---|
| 播到一半突然停止 | 文本缓冲断句阈值太高，网络流传输不连续导致引擎认为数据结束 | 调低断句阈值：WEAK_FLUSH_THRESHOLD=6字符，FORCE_FLUSH_THRESHOLD=12字符，FLUSH_TIMEOUT_MS=150ms |
| 两句话之间引擎被关闭 | TTS_ENDED（服务端发完音频）和PLAYER_FINISHED（播放器播完）信号不同步 | 实现双向等待机制：只有两个信号都到达才停止引擎 |
含[Tool-Date]标签的回复完全不发声 |
过滤标签后缓冲区为空，导致TTS session未启动 | 在feedTtsChunk()中补启动session逻辑：引擎运行但session未启动且缓冲区有文本时立即启动 |
| 最后几个字总是丢失 | 流结束时缓冲区残留文本未发送到引擎 | finishTtsStream()强制flush所有剩余文本，FINISH_SESSION延迟400ms发送，增加10秒安全超时 |
| 长文本仍然截断 | 多session模式切换导致状态重置 | 最终方案：单session + 多TASK_REQUEST模式，配合三级标点断句策略 |
最终稳定方案：
- 强断句：句号、感叹号、问号等句末标点立即断句
- 弱断句：逗号、冒号等且缓冲区≥6字符时断句
- 强制断句：缓冲区≥12字符或150ms超时后强制断句
- 双向信号同步 + 末尾强制flush + 安全超时兜底
其他方面：标准Intent方式在华为手机上找不到日历应用
- 解决：实现五级降级策略：
- 优先使用Calendar Provider API直接写入（需要WRITE_CALENDAR权限）
- 降级为ACTION_INSERT Intent
- 尝试Intent type vnd.android.cursor.item/event
- 直接启动已知的华为日历包名（com.huawei.calendar等）
- 最终兜底：启动日历应用让用户手动添加
九、商业化：不是卖一颗按钮，是卡住 Agent 时代的物理信任层
我们的商业化不是线性卖硬件，而是四层叠加的飞轮结构——每一层对应不同的收入模型，也对应不同的估值逻辑。
第一层｜硬件销售：用最低成本验证"用户是否愿意为物理入口付费"。
| 阶段 | 版本 | 定价 | 目标 | 逻辑 |
|---|---|---|---|---|
| 众筹期（MVP验证） | 种子版（工程模组，无外壳精加工） | 49元 | 跑通100位种子用户的真实使用频次和留存 | 低于BOM成本，纯验证，用真金白银筛出真需求用户 |
| 首批量产 | 标准版（戒指形态，基础配色） | 129元 | 覆盖BOM+制造成本，微利跑量 | 用户已验证价值，定价回归合理区间，支撑供应链现金流 |
| 品牌溢价期 | 限定版（材质/配色/刻字） | 199元起 | 建立品牌心智，测试价格弹性 | 给早期种子用户"身份标识"溢价，同时为后续B端礼盒版探路 |
- 成本结构：主控芯片（nRF52840方案）+ BLE模组 + 纽扣电池 + 戒指外壳 + 包装，标准版BOM控制在60-70元区间，129元售价留出30-40%毛利缓冲用于渠道和售后
- B端独立定价：企业按席位采购，99元/枚起（量大阶梯价），不走C端零售渠道，由企业IT统一分发回收——B端不靠硬件赚钱，靠订阅
- 核心验证指标：配戴后AI周使用频次 ≥ 5次、7日留存 ≥ 40%、30日仍佩戴率 ≥ 25%
- 关键判断：硬件买断不是终点，是飞轮的第一圈——用户买的是一枚戒指，留下来的是每天几十次双击产生的意图数据，这些数据喂养Prompt编译层的场景模板，模板越准，留存越高，飞轮越转越快
第二层｜Agent 服务订阅：从"帮你查"到"帮你办"的订阅升级。
语音转文档、灵感整理、会议纪要、客户拜访记录、飞书/Notion/备忘录同步、行业模板——硬件买断之后，Agent 工作流订阅形成持续收入。律师晨跑时的一句"对方控制权论点站不住"，经语义编译层变成带论点、证据清单、质证角度的攻防卡片。按钮不稀缺，按钮后面接的语义编译和行业 know-how 模板资产，复制不了。这是第二圈。
第三层｜场景交易分佣：当 Agent 能力被平台开放，入口即收入。
支付宝 AI 开放平台正在把商家服务封装成 Agent 可调用能力，微信小微生态也在推进商家接入。越多服务可被 AI 调用，越需要现实世界的触发和确认入口。用户在厨房双击发起下单、长按确认执行——这条链路里，一闪卡住的是"触发"和"确认"那一下，后续支付、风控、履约全部回到平台生态。交易分佣模型按 GMV × 分佣率计算，乐观情景下年 GMV 可达亿元。
第四层｜企业入口授权：B 端的岗位钥匙。
员工按人数采购 AI Key，企业订阅按席位收费，上下文集成费对接飞书/钉钉/企微数据。同一套 IntentGrant 协议，C 端管"用户此刻是否主动想花这笔钱"，B 端管"员工此刻是否主动想执行这次高危操作"——底层逻辑完全一致。企业市场不是 C 端的延伸，而是协议的第二个原生场景。
四层飞轮的逻辑是：硬件出货 → 用户拥有离屏入口 → 高频使用产生 Agent 对话数据 → 场景模板优化 → 执行成功率提升 → 留存与订阅提升 → 更多硬件销售。同时，物理意图记录沉淀为原创存证/信任锚点，反哺品牌估值溢价。
十、社会价值：AI 越强，世界越需要一个不可伪造的"Yes"
- 治理"影子 AI"：补上纯软件方案跨不过去的天花板。
今天企业 AI 存在一个普遍的两难：官方办公 AI 安全合规，但操作繁琐、打断工作流；第三方工具顺滑，但数据脱离管控——于是大量员工自发使用外部 AI 工具，形成行业里的"影子 AI"。纯软件方案能管控 AI 输出了什么，却证明不了指令是谁发的：账号可以借用、脚本可以模拟点击、弹窗可以劫持。IntentGrant 用物理按压生成单次、限时、可审计的 Grant 凭证，从源头证明"真人主动发起"——这不是授权弹窗的改良，而是补上了信任链路中最稀缺的一环。
例如，员工想用 Kimi App 整理飞书里的客户拜访纪要，但纪要含商业敏感信息，企业不允许数据直接流向第三方 AI。通过一闪 AI Key，员工双击发起 → IntentGrant 签发单次限时凭证 → Kimi 仅凭这张凭证读取指定飞书文档，3 分钟后凭证销毁、权限自动回收。企业审计日志记录：谁、什么时间、按了哪一下、授权哪个 AI 读哪份文件、多久过期。影子 AI 从"管不住"变成"可放行、可追溯、可回撤"。
【飞书没有理由为 Kimi 开门，但飞书的客户有权利让 Kimi 进来——数据是企业的，不是平台的。我们做的不是劝平台开门，而是当门被打开的任何一刻，门口已经站好了授权的哨兵。飞书里的数据所有权属于企业客户，飞书是保管方，不是所有方。当大客户说"我们内部 AI 战略选了 Kimi/自研模型，我要求我自己的数据可被安全调用"时，飞书只有两个选择：开一个可管控、可审计的接口，或者眼睁睁看着客户迁走。历史上每一个企业 SaaS 平台都走过同一条路：先封闭，再被客户要求数据可移植，最后开放受控接口——Slack、Salesforce、微软都经历过。区别只在于是主动开放还是被动开放。（数据主权、堵不如疏）】
- 隐私保护：按压才采样，用完即弃，零上传。
场景感知全部在本地完成计算，按压瞬间才并行采集【 GPS 速度】、运动状态、蓝牙、WiFi 等信号，1.5 秒出结果，用完即弃，一个字都不上传。IntentGrant 凭证限时 3–10 分钟、到期自动销毁，不存在长期有效的"空白支票"。隐私数据留在本地，不上云——这不是口号，而是协议设计的硬性约束。【中括号内为当前已实现】
- 信任基础设施的中立性：只有第三方能占的位置。
物理信任基础设施如果由平台自研，在政企采购里就是既当裁判又当运动员；独立第三方反而能帮生态打开高合规行业。大厂的硬件重心是手机、VR 这种生态级产品，蓝牙外设的模具、供应链、品控…投入产出比不适合亲自下场——最优解是定标准、开接口、认证伙伴。我们用硬件绑定岗位资产，人员离职回收戒指，岗位上下文完整移交继任者，不需要动任何账号体系的底层。跨N厂的中立外设，只有第三方能占。
终局叙事
当 AI 可以生成任何内容、模仿任何声音、伪造任何人的脸时，数字世界的信任体系会面临前所未有的崩塌。届时什么才是不可伪造的？一个人类手指，在特定时间、特定地点，按下特定按钮的物理动作。
我们不卖按钮，我们定义的是 Agent 时代的物理信任层。商业化路径从硬件买断走向场景交易分佣，最终指向协议标准化；社会价值从离屏交互的可及性走向影子 AI 治理，最终指向数字世界的物理信任锚点。AI 越强，世界越需要一个不可伪造的"Yes"。
十一、产品迭代规划
Phase 0（融合）：一闪 App 统一入口——C 端体验 × B 端上下文
【如有条件，我们有信心，在15~20号开发和测试完成】
当前 B 端 RoleKey 与 C 端一闪是两个独立 APK，碍于比赛周期，未做融合。但二者的底层协议本就共享同一套 IntentGrant 四层架构——C 端 Lite 版与 B 端 Full 版仅 Layer 0 绑定强度和审计保留策略不同，用户从 C 端切到 B 端时 App 后台自动补全字段，不需要换戒指、不需要重新学习交互。
Phase 0 要做的就是把这层窗户纸捅破：一个 App，双上下文，丝滑切换。
以新入职销售总监为例——IT 管理员在 Web 端完成交接工单创建→审批→下发，员工绑定 RoleKey 硬件后，90 天快速上岗包自动聚合近 3 个月会议、客户、项目资料，720 天岗位知识传承包承接前任隐性知识。认证完成的那一刻起，他日常工作中的每一次双击，唤起的不再只是个人豆包，而是一个已经加载了岗位上下文的工作 Agent——深聊客户策略、口述拜访纪要让 Agent 写进飞书文档、双击发起任务长按确认执行，所有操作带有岗位上下文的语义理解，所有敏感调用留有 IntentGrant 物理凭证审计留痕。
今后的每一个工作日，他都将在一闪 App 的首页对话入口里丝滑地带着上下文工作：深度对话、直接下令、让 Agent 起草文档，无需重复交代背景。一次授权，天天在场——交接不是一次性的仪式，而是持续在线的生产力。
Phase 0 的重点不是把 C 端和 B 端简单放进同一个 App，而是先把“AI 使用权”统一起来。个人用户有个人会员额度，岗位员工有岗位额度，团队有共享权益池；同一次 AI 调用，系统必须知道它属于谁、消耗谁、由谁确认、是否可回收。
因此，Phase 0 要打穿三件事：
| 融合对象 | Phase 0 表达 |
|---|---|
| 入口融合 | 一个一闪 App，同时进入个人 AI 和岗位 Agent |
| 身份融合 | 用户可在个人身份和岗位身份之间切换 |
| 权益融合 | 个人额度、岗位额度、企业共享池统一展示和扣减 |
在个人模式下，用户调用 AIkey 能力，消耗个人会员额度。
在岗位模式下，用户调用 RoleKey 能力，消耗岗位额度或企业共享池。
在授权确认前，系统展示本次调用的额度来源、预计消耗、剩余额度和风险边界；物理确认后，调用才会执行，额度才会扣减，记录才会进入审计。
Phase 1：（1）环境感知能力——按压瞬间本地并行采集加速度、WiFi、蓝牙等信号，加权规则引擎对通勤/跑步/会议/健身/厨房 5 场景独立打分，1.5 秒出结果，零上传、零服务端依赖。（2）Prompt 编译层当前以律师/咨询/投研三身份起步，碎片口语经"身份+场景+模板"编译为结构化专业 Prompt，未来通过用户评分反馈回流模板库，编译质量持续迭代。
Phase 2：加入 SE 安全芯片与国密算法，从蓝牙按压信号升级为硬件级加密签名凭证，满足等保 2.0。Prompt 编译从固定模板进化到个性化学习——记住用户常用术语、输出偏好、归档路径，支持多角色切换。环境感知扩展自定义场景与地理围栏。
Phase 3：IntentGrant协议对接豆包、Kimi 等 Agent 平台，硬件形态扩展至 Watch/Glasses，统一 GestureEvent 协议，推动协议成为 A2A 生态物理信任层标准。
Agent 时代的每一次’Yes’，都需要一个不可伪造的出处。字节可以造最聪明的大脑，我们来做那只签字的手。
十二、写在最后
OPC 与 AI 的大浪已至，每个人都在思考如何借力 AI，成为更强大的自己。但这两个月，我最深的体会是反过来的——你有多强大，你的 AI 才有多强大。AI 放大的从来不是懒惰，而是思考的密度：是我们作为人，对生活有触角、对现实有省思，才能把那个"正确的问题"定义出来、交到 AI 手上。问题定义得越准，AI 跑得越快。最终让我们更快抵达想要的未来的，是 AI 的算力，更是人的判断。
我们这支三个同事的小团队，不过是这段话的一个小小注脚。我从产品到前后端从零学起，宗池扛下全栈开发，小余搞定交互设计、UI 和视频——全部在下班和周末完成，前后不到三周。这不是一个 side project 的体量，而是一套从物理交互层到 Agent 语义编译再到企业审计闭环的完整系统。放在一年前，这需要一个小型技术团队两个月。
在这个项目或本次创业中，我完全把TRAE当成了全能的工作台，不论是深入推演、竞品调研、生图提示词、视频脚本、社媒文案……它都能帮我加速效率。回顾与TRAE的100+轮对话，每一次关键判断和重大的转捩点都是由我主动提出，而TRAE帮我快速深化。——极大地压缩了我们创始人从判断问题、定义问题，到真正实现之间的时间和工具成本——而这，我想也是“创造力大赛”的原始之义。
因此，在8月9日早上，当我看到施一公院士8.8在西湖大学开学典礼上的演讲时，尤为感触：
感谢 TRAE，不是因为平台帮我们写了多少行代码，而是它让"一个产品经理能带着两个伙伴，在三周里把一个完整产品从图纸跑成 demo"这件事变成了现实。工具降低的不是门槛，是"开始"的勇气——你不需要先成为工程师，才能让一个想法落地。
如果说 AI 放大的是人的判断，那 TRAE 放大的，就是普通人把创业方向判断，变成行动落地的加速度。
