不是哥們，現(xiàn)在都這樣開源了？？？

3 月的最后兩天（不是愚人節(jié)），一個(gè)奇怪的開源項(xiàng)目突然在 X 上引發(fā)了討論：

這個(gè)項(xiàng)目的作者 yetone 在 GitHub 上有不少作品，其中最出名的一個(gè)叫 avante.nvim—— 讓 Neovim 編輯器用起來像 Cursor 那樣支持 AI 輔助編程，目前積累了 17.7k star，顯然是一個(gè)正經(jīng)的開源作者（）

而他發(fā)布的這個(gè)新項(xiàng)目：voice-input-src，功能聽起來很日常 —— 一個(gè) macOS 菜單欄語音輸入法，按住 Fn 鍵開始錄音，松開后語音自動(dòng)轉(zhuǎn)文字，注入當(dāng)前聚焦的輸入框，類似系統(tǒng)層面的語音聽寫，但加入了 LLM 糾錯(cuò)和多語言切換。

項(xiàng)目本身不算稀奇，稀奇的是打開這個(gè)倉庫，沒有任何代碼文件，除了倉庫結(jié)構(gòu)里的一個(gè)dist/子模塊指向發(fā)布版本，可以看的內(nèi)容只有 README。README 里也沒有安裝說明，沒有 API 文檔，也沒有貢獻(xiàn)指南，只有一段自然語言寫成的詳細(xì)指令，也就是丟給 AI 的 Prompt：

起初大家都以為他在玩抽象，但仔細(xì)一想現(xiàn)在誰還在用古法手作編程？這不比直接把一大坨 AI 生成的代碼復(fù)制粘貼上來開源簡(jiǎn)潔高效多了嗎。

我們細(xì)看這段開源 Prompt 可以發(fā)現(xiàn)：

請(qǐng)實(shí)現(xiàn)一個(gè) macOS menu-bar 語音輸入法應(yīng)用（Swift，macOS 14+），具體要求：1. 按住 Fn 鍵錄音，松開后將轉(zhuǎn)錄文字注入當(dāng)前聚焦的輸入框。優(yōu)先使用流式轉(zhuǎn)錄……

然后是極為細(xì)致的工程規(guī)范：項(xiàng)目必須使用 Swift Package Manager 結(jié)構(gòu)、自動(dòng)生成 Makefile、使用LSUIElement模式讓應(yīng)用不出現(xiàn)在 Dock 里、錄音時(shí)彈出一個(gè)帶波形動(dòng)畫的無邊框浮窗、實(shí)時(shí)展示轉(zhuǎn)錄內(nèi)容…… 一路寫到 CJK 輸入法的兼容處理、LLM 糾錯(cuò)的調(diào)用時(shí)機(jī)、API Key 管理的 UI 設(shè)計(jì)細(xì)節(jié)。

整篇算下來接近一千字，沒有一行 Swift 代碼。

yetone 在原推中說明，他用 Claude Code 執(zhí)行了這段 Prompt，一次性生成了完整可運(yùn)行的應(yīng)用，然后將這段 Prompt 公開，就算“開源”了。

換一個(gè) AI，也能跑通

這件事被 V2EX 用戶發(fā)現(xiàn)后，在論壇引發(fā)討論，標(biāo)題就叫“新的開源形式”。

討論里有人表示好奇：這段 Prompt 是綁定 Claude Code 的，換別的模型還管用嗎？有用戶做了個(gè)實(shí)驗(yàn)，將原 Prompt 原封不動(dòng)復(fù)制，交給 OpenAI Codex（基于 GPT-5.4 模型），讓它按照同樣的描述生成代碼。結(jié)果是一次性生成、構(gòu)建、運(yùn)行全部成功，功能和原版基本一致。

這個(gè)細(xì)節(jié)比“AI 生成了一個(gè) App”更值得關(guān)注，它說明這段 Prompt 并不是某個(gè) AI 的專有格式，而是一份對(duì)需求的完整表達(dá) —— 足夠精確，以至于任何能力足夠的語言模型都可以從中還原出同一個(gè)應(yīng)用。

代碼是執(zhí)行結(jié)果；Prompt 是執(zhí)行依據(jù)。

Linus 說過的那句話

二十多年前，Linus Torvalds 在一場(chǎng)郵件爭(zhēng)論里說了一句話，后來變成開源社區(qū)最廣為人知的格言：

Talk is cheap. Show me the code.

意思是：說再多不如秀代碼。那個(gè)時(shí)代的開源邏輯很清晰 —— 你的貢獻(xiàn)等于你提交的代碼，pull request 是協(xié)作的貨幣，diff 是知識(shí)的載體。

現(xiàn)在有點(diǎn)不一樣了。當(dāng) AI 工具可以從一段精確描述里生成完整可運(yùn)行的代碼，代碼本身退化成了一種臨時(shí)產(chǎn)物 —— 它是 Prompt 的實(shí)例化輸出，不再是知識(shí)本身。就像編譯器把高級(jí)語言編譯成機(jī)器碼，而沒有人會(huì)去閱讀機(jī)器碼來理解程序的意圖。yetone 開源的不是結(jié)果，而是生成結(jié)果的意圖。

這個(gè)轉(zhuǎn)變有一個(gè)更直白的說法，在那個(gè) V2EX 帖子的評(píng)論里有人提到了：

“Code is cheap, show me the prompt.”

開發(fā)者的知識(shí)資產(chǎn)在哪一層

傳統(tǒng)的開源協(xié)作，協(xié)作的單元是代碼。你 fork 一個(gè)倉庫，改幾行，提 PR，討論在 issue 區(qū)，分歧落實(shí)為具體的代碼行。

如果 Prompt 開源成為一種常見模式，這個(gè)鏈路會(huì)有些變化。貢獻(xiàn)者不需要理解 Swift 的語法；覺得某個(gè)功能描述有歧義，可以直接在 Prompt 的對(duì)應(yīng)段落提出修改；想新增一個(gè)功能，只需要在 Prompt 里加一段需求描述，重新跑一遍，對(duì)比兩次生成結(jié)果的差異。

版本管理的對(duì)象變成自然語言文檔，issue 的內(nèi)容變成“第 12 條描述不夠精確導(dǎo)致 LLM 理解錯(cuò)了”，PR 變成“在第三節(jié)加上這個(gè)約束條件”。

這不是說代碼從此消失。AI 生成的代碼依然需要人去調(diào)試、驗(yàn)證、修改；對(duì)于復(fù)雜系統(tǒng)，單靠一段 Prompt 根本無法完整描述所有約束；遇到需要深度定制的功能，自然語言描述的精度會(huì)不夠用。

但對(duì)于一部分足夠明確、邊界清晰的應(yīng)用 —— 語音輸入法、翻譯工具、菜單欄小工具這類 ——Prompt 已經(jīng)可以作為完整的規(guī)格交付物。而這個(gè)邊界，正在隨著模型能力的提升向更復(fù)雜的方向移動(dòng)。

yetone 的 voice-input-src 只有 1.1k star，沒有登上任何主流媒體的頭條。但它展示的邏輯是清晰的：一些程序員已經(jīng)把寫 Prompt 當(dāng)成主要的工作產(chǎn)品，并開始以同樣的方式分享它。

他們分享的不是怎么寫代碼，而是怎么想清楚一件事。

參考來源

• https://github.com/yetone/voice-input-src

• https://www.v2ex.com/t/1202162

• https://x.com/yetone/status/2038183163579810024

• https://github.com/jovix0101/voice-ime