让任何按键变成任何功能
创意名称：VoiceKeyApp — 让任何按键变成任何功能
一句话定位：把无线设备的按键变成任意功能的开关，用 AI 帮零基础用户生成自定义按键脚本，未来做成大家共享脚本的社区平台。
赛道：学习工作
产品形态：一个 Windows 桌面工具（exe，免安装），三步配置即可使用，内置 AI 脚本生成器，未来扩展为按键脚本共享社区。
无线设备（蓝牙遥控器、录音笔、智能眼镜按键等）的按键功能是出厂写死的，用户没法自定义。比如 Insta360 Mac Air 的音量键只能调音量，但用户希望按它一下就开始语音输入、再按一下自动转写并发送。更进一步的痛点是：普通人想让按键执行自定义操作，但 AutoHotkey 等工具的编写门槛极高，基本劝退所有非技术用户。
用 Insta360 Mac Air 时发现，它有一个按键在电脑上只能当音量键用，太浪费了。想把它变成语音输入开关，但找了一圈没有现成工具能做到。于是用 TRAE + AutoHotkey v2 从零开发，做的过程中发现"AI 帮你写脚本"这件事可以做成一个通用产品——不止语音输入，任何按键映射需求都可以用自然语言描述给 AI，AI 生成安全可执行的脚本。
把"学习 AutoHotkey 语法 → 编写脚本 → 调试 → 编译打包 → 分发安装"这条需要数天的链路，压缩成"用自然语言描述需求 → AI 生成 → 一键启用"的 30 秒体验。非技术用户第一次拥有了对硬件按键的完全控制权。
第三阶段的按键脚本共享平台，让有创意但没技术的人也能使用别人创建的按键方案。比如教师分享"上课专用按键方案"、主播分享"直播控制台方案"、残障人士分享"无障碍辅助按键方案"。按键脚本从个人工具变成社区资产，让硬件交互的创造力不再被技术门槛阻挡。
以下为产品策划助手提出的 5 个关键问题，以及经过验证与讨论后的结论。
很多无线设备的按键走 Windows HID 多媒体键层，系统可能在程序拦截之前就响应了。拦不到按键，后面全白搭。
已实测通过。Insta360 Mac Air 的音量上升键可以被拦截并识别，已跑通完整脚本——按一下开始录音，再按一下开启转写，等待一段时间后发送。
不同厂商设备按键走的协议层不同（HID 普通键 vs 多媒体键 vs 私有协议），有些设备的音量键系统层就吞掉了。已验证 Insta360 能拦，不代表所有蓝牙设备都能拦。
增加"按键测试功能"。开启测试后让用户按一下按键：屏幕跳出绿色勾 → 可拦截且可识别，能做后续映射，地基成立；未识别到或识别到但无法调用 → 该设备暂不支持。让用户从一开始就知道自己的设备能不能用，主动管理预期。
PowerToys 已能做按键重映射，AutoHotkey 社区有海量脚本。核心壁垒是"AI 生成"还是"零门槛"？
核心差异不在简单重映射，而在于复杂的 toggle 逻辑（按一下开始、再按一下结束），以及"零门槛带引导"的体验。PowerToys 做不了 toggle，AutoHotkey 能做但门槛高。
消除最后一点阻力，让操作做到最直观、带引导。用户只需用自然语言描述需求，AI 生成脚本，不需要自己写。
自然语言描述需求本身有边界。"按一下自动发邮件"这类需求涉及登录、选收件人、写内容，AI 生成不出来。
制作"能做 / 不能做"清单，给用户正确的心理预期，明示能力边界。
语音转文字要调 ASR 服务，涉及网络、API key、延迟和费用。内置还是用户自配？
实际方案是借助微信输入法——它已内置语音输入转写，还能用大模型重新组织语言、去掉语气词、提升逻辑性。把微信输入法的"开始录音"键设成键盘某键，再把设备音量上升键映射到该键，即实现完整链路。
不构成问题。市面上已有 TypeLess、闪电说、微信等多款 AI 语音输入法，用户大多已有用顺手的软件。若有人不知道可以这样进行语音输入，反而是商机——可与输入法厂商合作。
AI 生成脚本不可能 100% 正确，有 bug（死循环、热键冲突、误操作文件）时零基础用户完全没法自己改。怎么保证安全可执行？
采用"安全动作白名单 + 双 AI 审查 + 用户可见预览"三层防护，从源头堵死危险，而非事后拦截。
真正的隔离沙箱非常重，零基础团队自己做成本高、风险大；白名单约束 + 双 AI 审查 + 用户预览这三层比沙箱更可控，也更适合团队能力边界。
脚本只能从预定义安全动作中组合，不能写任意代码，危险操作根本进不来
一个 AI 写脚本，另一个 AI 审查：有没有越出白名单？动作合不合理？
运行前展示动作清单，用户确认后才执行
| 安全动作 | 说明 |
|---|---|
| 模拟按键 | 按下 / 释放 Ctrl、Alt、字母键、功能键等 |
| 发送文本 | 输入一段指定文字 |
| 启动程序 | 从预批准的列表中选择并启动 |
| 延时等待 | 等待若干秒后继续执行 |
| 条件判断 | 按了几次、是否在某窗口等逻辑分支 |
用户预览示例：这个脚本会：① 按下 F8 键 → ② 等待 0.3 秒 → ③ 按下 Ctrl+V 粘贴 → ④ 按下回车发送
社区最怕冷启动，早期没有社区时单机版"AI 生成脚本"能不能让用户觉得值？如果永远做不成社区，产品还成立吗？
第二阶段（自然语言一键生成脚本）本身已有价值，对很多人有吸引力。成本在用户自己身上——大模型 API 由用户自己调用，产品方无成本压力。
用户自己调 API = 用户自己申请 key、配置到软件里，这又是一个门槛，与"零基础用户"定位冲突。
是否内置默认 API（开箱即用、给免费额度），高级用户才自己配 key。此问题留待后续确认。
从可行性验证中提炼出的核心设计决策：
| 序号 | 决策 | 说明 |
|---|---|---|
| 1 | 按键测试功能 | 用户首次使用时测试设备按键是否可拦截，绿色勾通过 / 否则提示不支持，主动管理预期 |
| 2 | 能力边界清单 | 明示"能做 / 不能做"，给用户正确心理预期 |
| 3 | 安全动作白名单 | 脚本只能从预定义安全动作中组合，从源头禁止危险操作 |
| 4 | 双 AI 审查 + 用户预览 | 写脚本 AI + 审查 AI + 用户确认动作清单，三层保障可靠性 |
| 5 | API 成本由用户承担 | 大模型 API 由用户自调，产品方零成本（默认开箱即用模式待定） |
以下问题在讨论中提出，尚未最终确认：