从开放源码到开放提示词,到开放全过程

“Talk is cheap. Show me your prompt history.”

—

一、那个把”长提示词”当作README的奇怪项目

2026年初，GitHub上出现了一件怪事。

一个名叫yetone的开发者开源了一个macOS语音输入法项目，但点进去的人发现——最吸睛的不是Swift代码，而是一段长得离谱的Prompt。

这段Prompt详细描述了一款语音输入工具该怎么工作：按住Fn录音，松开后转写注入当前输入框；默认支持简体中文，兼容中英混说；界面是底部居中的胶囊浮窗，带实时波形；甚至还包括技术词纠错策略——把”杰森”修成JSON，把”配森”修成Python。

更奇特的是，这个项目被刻意拆成了两个仓库：

– voice-input-src：像一份工程规格说明书，核心资产是那一段超详细的Prompt

– voice-input-dist：真正可构建、可运行的应用，附带构建录屏证明”仅依靠src中的信息足以复现”

这就是”开放提示词”运动的第一个标志性样本。yetone不是在炫耀”我用AI写了个应用”，而是在实验：如果修改软件最快的方式是改一段自然语言，那我们是不是该重新定义什么是source？

二、咖啡厅大屏幕上的”意图透明”

想象一下，如果这个项目的开发过程发生在那位开发者说的”咖啡厅大屏幕”前。

屏幕上不会显示枯燥的代码行，而是展示yetone与Claude的完整对话链：

第一轮：”帮我做一个macOS菜单栏应用，按住Fn录音，松开后把文字输入到当前光标位置…”

第三轮：”波形显示不够流畅，需要实时反馈，像iPhone的语音备忘录那样…”

第七轮：”中文技术术语经常识别错误，需要接入LLM做后处理修正…”

观众看到的不是魔术般的”咻一下就写好了”，而是一个真实需求如何被逐步拆解、细化、修正的完整思维过程。这比看到最终代码有价值十倍——因为这才是AI时代真正的技术壁垒：不是写代码的能力，而是说清楚要什么的能力。

在那个假设的咖啡厅里，这样的展示会成为最好的现场教学。新手开发者能直观学习：为什么yetone要在Prompt里强调”底部居中胶囊浮窗”？因为AI需要精确的UI描述；为什么要单独列出”中英文切换策略”？因为那是中文用户的痛点。每一个细节的考量都暴露在提示词历史里。

这正是我所说的”透明厨房”——不仅给你看最终的菜（dist），还给你看配方和烹饪过程（src）。

三、Src与Dist：新的开源双轨制

yetone的实验揭示了一个更深层的变化：传统开源的单一仓库模式正在解耦。

在AI生成代码占比超过80%的2026年，继续把所有东西塞进一个仓库，就像餐厅只给你上菜却不给菜谱——你可以吃，但很难学会怎么做，更难根据自己的口味调整。

voice-input-src模式 proposes 一种新范式：

– Src仓库 = 意图（Intent）+ 规格（Spec）+ 提示词链（Prompt Chain）

  – 这是人类可读的、最优先的修改入口

  – 记录了”为什么要这样做”的完整上下文

– Dist仓库 = 可运行制品（Artifact）+ 可复现性证明

  – 这是机器执行的、构建后的产物

  – 证明Src的有效性，但不是修改的首选目标

这种分离呼应了我在前三篇提到的”码超”精神：我们比拼的不是最终代码，而是人机协作的过程。

在”码超”赛场上，如果两个选手提交了功能完全相同的语音输入法，评委如何判断高下？看谁的提示词更精确、更少歧义、更易于他人理解和修改。yetone的Src仓库就是一份完美的参考答案。

四、Prompt真的能算Source吗？

yetone的项目抛出了一个尖锐的问题，这也是我第四篇的核心议题：

如果未来最有效的改法真的不是去改Swift，而是去改那条Prompt，那Prompt是否开始具备”源码属性”？

传统开源世界对source的定义是：”修改软件时最优先使用的形式”。按照这个标准，当AI模型足够稳定时，一段精心设计的Prompt确实比生成的代码更符合”源码”的定义——因为改Prompt比重写代码更快、更直观、更贴近人类思维。

当然，反对者会说：Prompt依赖模型，模型会变，推理过程不稳定。同样的Prompt，换一个模型版本可能产出不同结果。传统源码的强项是确定性，而Prompt的强项是高层抽象。

这正是我们需要在咖啡厅大屏幕上公开讨论的问题。当开发者在公众面前展示”修改一个按钮颜色”的过程——是直接去改CSS文件，还是改Prompt重新生成——观众可以亲眼见证哪种方式更高效。

yetone的价值不在于给出了标准答案，而在于他把问题提得足够具体。通过展示一个真实的、可工作的语音输入法，以及支撑它的那段超长Prompt，他为整个社区提供了一个讨论样本。

五、街头编程：从展示代码到展示思维

回到那个咖啡厅大屏幕的场景。

当yetone式的开发成为常态，屏幕上的内容会变得很有意思：

不再是黑底绿字的代码滚屏（那是20世纪的极客审美），而是三栏式的工作流展示：

– 左栏：实时语音输入的波形图，显示用户正在说”帮我写一个Python爬虫…”

– 中栏：提示词编辑区，展示开发者如何补充细节：”使用asyncio，遵守PEP8，添加异常处理…”

– 右栏：AI生成的代码预览，以及版本对比（V1→V2→V3的迭代过程）

路人可能看不懂Swift语法，但每个人都能看懂自然语言。当观众看到开发者说”波形要流畅一点”后，AI如何响应修改，这种”意图→表达→实现”的直观映射，会消解技术的神秘感。

这就是编程作为街头艺术的真谛——不是炫耀技术高深，而是展示思考的可视化。

yetone的voice-input-src之所以值得关注，正是因为它把最隐蔽的”上下文工程”推到了台前。在AI编程时代，真正难复制的不是最后那几千行代码，而是前面那一套足够清晰、足够细、足够不含糊的规格描述。

六、结语：新纪元的篝火

yetone在GitHub上的实验，加上咖啡厅大屏幕的公共展示，构成了AI时代开源运动的新图景：

我们不再只分享”我做了什么”（What），更要分享”我怎么想的”（How）和”我为什么这样想”（Why）。

当提示词历史成为比代码仓库更珍贵的资产，当修改自然语言成为比修改机器语言更高效的途径，开源的定义必须扩容。

那个在五道营胡同咖啡厅里，对着大屏幕调整提示词的开发者，和那个在GitHub上公开voice-input-src的yetone，在做同一件事：

他们不再把AI当作黑箱魔术，而是把与AI协作的过程变成可学习、可改进、可传承的公共知识。

下次当你走进一家咖啡厅，看到屏幕上显示的不是 yetone 的语音输入法项目，就是另一个类似的”Src+Dist”展示，请停下来看一会儿。

你可能会见证历史：人类第一次把”如何与AI对话”变成了一门可以公开观看、学习、讨论的技艺。

而那个大屏幕，就是这个新纪元的篝火。

—

本文是”码超”（CODE SUPER）系列第四篇。特别致敬yetone的voice-input-src项目，它用1.2k Star证明了：在AI时代，开放提示词比开放代码更需要勇气。

参考： GitHub奇观：这个 1.2k Star项目的”源码”，最吸睛的部分竟是一段发给Claude的长提示词

本文主要由kimi生成，其中的细节并未一一考究，但不影响主要意思的表达。