传统的开源项目：代码在仓库里，你 clone 下来，编译，运行。
这个项目是：妥妥的提示词即应用啊！
所以这个提示词做了什么？
提示词本质上是一个软件规格说明书，里面详细规定了：
功能要求：Fn 键录音、松开注入文字、用 Apple Speech Recognition 做流式转录
UI 要求：NSPanel 毛玻璃胶囊窗口、5根波形条用 RMS 驱动、动画参数具体到毫秒
输入处理：CJK 输入法的临时切换逻辑
LLM 集成：调用 OpenAI 兼容 API 做保守纠错
系统集成：LSUIElement 菜单栏模式、Swift Package Manager 构建
提示词用中英文写，逻辑非常严密，连”±4% 随机抖动”这种细节都写了。
更有意思的是，作者还用这个视频记录了完整的 AI 构建过程——你看到的每一行代码、每一次编译，都是 AI 生成的。
录像地址：
https://asciinema.org/a/cHD6XaaNvomCuysh）voice-input-src = 提示词（规格说明书）
voice-input-dist = 产物（根据提示词构建出来的 .app）
所以当你从 dist 下载 app 时，你拿到的实际上是 AI 根据那个提示词生成的代码编译出来的产物。而那个产物和提示词之间有一一对应的关系——任何人看到这个提示词，都可以从零重新生成完全一样的 app。
本质上：这不是”用提示词实现了一个功能”，而是”用提示词从零构建了一个完整的原生应用”。
简单来说就是，我用这个提示词能给自己也做一个语音输入法的 app 了……对，就是类似闪电说，微信、豆包语音输入法这种东西。
我是直接把这个项目地址扔给我的小龙虾（部署这个项目用的模型是kimi code 2.5），让它学习并部署的。
做好了之后，我选择直接「安装语音输入法」。
就像是这样子，你们看到的这样。
也就是说，到现在，那一段提示词，直接就实现了一个完整可用的语音输入法App（纯菜单栏显示的 App）。
附上完整的提示词：
claude
–dangerously-skip-permissions
–output-format=stream-json
–verbose
-p “请实现一个 macOS menu-bar 语音输入法应用（Swift，macOS 14+），具体要求：
1. 按住 Fn 键录音，松开后将转录文字注入当前聚焦的输入框。优先使用流式转录（Apple Speech Recognition framework）。Fn 键通过 CGEvent tap 全局监听，需抑制 Fn 事件传递以防止触发 emoji 选择器。
2. 默认语言必须为简体中文（zh-CN），确保开箱即用就能识别中文输入。同时在菜单栏提供语言切换选项（英语、简体中文、繁体中文、日语、韩语）。语言选择存储在 UserDefaults 中。
3. 录音时在屏幕底部居中显示一个特别优雅精致的无边框胶囊状悬浮窗，不要有红绿灯和 titlebar。使用 NSPanel（nonactivatingPanel）+ NSVisualEffectView（.hudWindow 材质），高度足够（56px，圆角半径 28px），包含：
– 左侧 5 根竖条波形动画（44×32px），必须由实时音频 RMS 电平驱动（不要用写死的假动画），说话声音大波形就大、安静时波形就小。各竖条权重为 [0.5, 0.8, 1.0, 0.75, 0.55] 形成自然的中间高两侧低效果，平滑包络（attack 40%、release 15%），每根竖条添加 ±4% 随机抖动增加有机感。波形要足够大，清晰可见。
– 右侧文字标签（弹性宽度 160-560px）实时显示转录文本，胶囊随文字变多而弹性变宽
– 入场弹簧动画（0.35s）、文字宽度平滑过渡（0.25s）、退场缩放动画（0.22s）
4. 文字注入使用剪贴板 + 模拟 Cmd+V 粘贴方式，注入前需检测当前输入法：如果是 CJK 输入法，先临时切换到 ASCII 输入源（ABC/US 键盘）再粘贴，粘贴完成后恢复原输入法，防止中文输入法拦截 Cmd+V。注入完成后恢复原剪贴板内容。
5. 接入 LLM 来提升语音识别的准确率，尤其是中英文混杂的情况下。通过 OpenAI 兼容 API（可配置 API Base URL、API Key、Model）对转录文本进行 refine。LLM 的 system prompt 要求非常保守地纠错：只修复明显的语音识别错误（如中文谐音错误、英文技术术语被错误转为中文如「配森」→「Python」、「杰森」→「JSON」），绝对不要改写、润色或删除任何看起来正确的内容，如果输入看起来正确则必须原样返回。
6. 在菜单栏提供 LLM Refinement 子菜单，包含启用/禁用开关和 Settings 入口。Settings 窗口包含 API Base URL、API Key、Model 三个输入框，API Key 输入框要能完全清空，以及 Test 和 Save 按钮。松开 Fn 键后如果 LLM 已启用且已配置，悬浮窗显示 Refining… 状态，等 LLM 返回后再注入最终文本。
7. 应用以 LSUIElement 模式运行（仅菜单栏图标，无 Dock 图标）。使用 Swift Package Manager 构建，提供 Makefile（build/run/install/clean），构建产物为签名的 .app bundle。”
这条提示词本质上是一份软件产品规格书，而且写得非常具体——不是”实现一个语音输入法”，而是精确到”圆角半径 28px”、”权重 [0.5, 0.8, 1.0, 0.75, 0.55]”、”attack 40% release 15%”这种程度。
它不是在描述一个想法，而是在给 AI 程序员写一份带验收标准的开发文档。这种精确度是这类项目成功的关键。
最后，说说给我的启发：
传统软件开发中，代码是产品，代码是资产。
这个项目颠覆了这个认知——在这里，提示词才是产品，代码只是提示词的产物。一个项目的”源代码”，可以是纯文本。
以前我接到任务想的是”怎么实现”。现在想的是”这个系统的行为应该是什么样的”。实现路径可以交给模型。如果你能“精确”的描述出来，AI做出来的东西大概率就是你要的。
作者把”如何做一个语音输入法”的知识，精确地编码成了一段文本。知识的载体从”代码”变成了”描述”，这是认识论层面的一次跃迁。
通常我们说 AI 是工具，我是使用者。但这个项目里，AI（如Claude Code）是执行者，而我（或者作者）做的是提供意图和规范。
这意味着：当我要做一个新功能时，我应该先想清楚我要什么、我拒绝什么、我的约束边界在哪里把这些写成提示词，比直接写代码更接近问题的本质。
这个项目没有代码，但它对问题的描述，比大多数代码仓库都更精确。
「知道问题是什么，已经解决了 80% 的问题。代码是解决方案的表达形式，而不是解决方案本身。」
附上这个项目地址：
https://github.com/yetone/voice-input-src