一个能嵌入GitHub代码片段的Web Component,技术上不难,难的是能有多快做出来。Simon Willison最近发布了这样一个实验性组件,叫github-code。它接收形如<github-code href="https://github.com/.../blob/commit/path#L9-L18">的标签,自动把这个链接转换成raw.githubusercontent.com的原始文件地址,用fetch()拉取内容,按指定行号区间显示——带行号,但明确说了,不做语法高亮。
整个组件用GPT-5.5和一段prompt完成,prompt本身也被公开挂在一个gist里。这不是能力不够,而是主动选择——这恰恰是这条新闻里最值得琢磨的地方。
这是做了减法,不是补了空白
GitHub代码嵌入不是新问题。官方早就支持用一段script标签直接嵌入Gist,免费、稳定、够用。自己动手的话,主流路线是拉取原始文件,配合Prism.js或Shiki这类高亮库渲染,连行号高亮插件都是现成的。
也就是说,github-code能做的事,行业里已经有更完整的方案。它的差异化不在功能更强,而在覆盖面不同:能处理任意commit下任意文件的任意行号区间,不局限于专门建一个Gist;代价是放弃了语法高亮,一个技术上完全不难加的东西。
这张对比图说明一件事:github-code从功能上看是减法,不是加法。它砍掉了本可以轻松拥有的高亮能力,换来一个更小、更快能写完的组件。
十分钟原型的固定套路
Willison的做法有个稳定路径:写一段prompt,让模型直接生成组件代码,再把prompt本身公开存进一个gist——这次的gist标了"Secret",但链接照样能访问,算不上真正隐藏。做完的工具最后会进他自己维护的一个工具名录页,github-code已经列在其中。
这套流程是vibe coding的一个标准样本:prompt就是产品说明书,AI生成的代码就是最小可用版本,发布即完成文档。人工介入被压缩到两步——写清楚要什么,确认能跑。
检索这条新闻的过程中,曾出现过一份看起来像github-code"实现代码"的示例,属性名写的是src和lines,和原文prompt里明确描述的href加GitHub blob URL自动解析完全对不上。这份代码更像是AI凭空拼出来的产物,不是Willison真实写的东西。
放在这里说,不是跑题,而是想提醒一件更实际的事:AI辅助写作和AI辅助检索共享同一个弱点——都倾向于把"听起来合理"的内容,当成"确实发生过"的内容来输出。遇到一份"疑似实现代码",第一反应该是回去对照原始prompt和作者原话,而不是直接当真。
模型看着更强,检索结果却可能更虚。
- 提醒.检索到的"实现代码"如果接口设计和原始prompt对不上,大概率是AI幻觉产物,不能当真实还原用。
一件还没查清的事
GPT-5.5具体由谁发布、和GPT-5或GPT-4系列什么关系,原文没写,目前也查不到确切信息。这不是细枝末节——如果一个模型能在十分钟量级的交互里,把一份口语化的需求描述直接变成能跑的Web Component,值得知道背后是哪家公司、哪个版本。这个问题眼下只能先挂着。
github-code这个组件大概率不会成为主流方案——Gist embed免费又成熟,Prism、Shiki功能更全。它真正的价值,是一份关于个人开发者现在能多快把一个念头变成能跑的东西的样本记录,顺带留了个提醒:检索到的东西,和原文说的东西,不总是一回事。