GitHub 在今年的 GitHub Universe(New from Universe 2024: Get the latest previews and releases[1])上再次强调其核心主题:对开发者和开发者体验的持续关注
。回顾了十年来从发明 pull request 到推出 AI 编程助手 GitHub Copilot 的创新历程,如今服务超过 1 亿名开发者。通过社区和生成式 AI 的结合,GitHub 助力开发者更高效地构建、发布、扩展和保障软件安全。
这次大会的主题包括 GitHub Spark、GitHub Copilot Extensions、GitHub Models(GitHub 助力 AI:免费体验,轻松部署)、Copilot Autofix、以及 IDE 功能增强等。其中最有意思的就数 GitHub Spark 了,所以今天的文章主要围绕 Spark 展开。
背景
在如今这个数字工具高度普及的时代,开发者们一直希望工作流程更加个性化,能真正贴合自己的使用习惯。虽然配置编辑器、管理 dotfiles、写自动化脚本是常规操作,但往往还不够。很多创意,特别是小型应用,往往因为开发耗时、不易维护或需求有限而被搁置。我们手上有强大的设备,却因为开发门槛高,始终离专属化软件的灵活性差一步。
于是问题就来了:个性化软件的开发是否可以变得像自定义开发环境一样简单?不仅是专业开发者,所有人都能随时根据需求构建轻应用。GitHub Spark[2] 正是基于这一愿景诞生的。作为一种由 AI 驱动的实验性工具,Spark 通过自然语言生成代码,让人们快速实现自己的创意,尤其是那些原本复杂但却有趣的小型应用。
📌 dotfilesdotfiles 是指那些以
.
(点)开头的配置文件,通常用于定制用户的开发环境。在类 Unix 系统(比如 Linux 和 macOS)中,这些文件通常隐藏在用户的主目录下,比如.bashrc
、.vimrc
或.zshrc
,用于配置命令行的外观、行为和工具设置。开发者会花时间编辑这些 dotfiles 来个性化自己的开发体验,例如自定义终端颜色、设置快捷键、或自动运行特定脚本。通过管理这些文件,开发者可以更高效地工作,因为他们的环境设置完全符合个人偏好。
从 Copilot 到 Spark
Spark 申请链接:
https://github.com/github_spark_waitlist_signup
GitHub Spark 的诞生并非一夜之间。自 GitHub Copilot 首次推出以来,它便因其代码自动补全和生成的功能大受欢迎。人们不禁猜测,未来我们是否只需用自然语言描述需求,便能生成完整的应用?过去几个月,各种类似的 AI 生成代码实验如雨后春笋般涌现(如 bolt.new[3]、v0.dev[4]、Cursor[5]、Replit AI[6] 等),而 GitHub Spark 正是 GitHub 官方针对这一愿景的正式实验性尝试。
GitHub Spark 来自于 GitHub Next 实验室。这个项目的目标是让用户通过自然语言轻松创建和自定义小型 web 应用。有开发经验的用户依然可以查看和编辑底层代码,而这些代码实际上存储在 GitHub 仓库中,并可以通过 GitHub Actions 和 Azure CosmosDB 提供的托管环境进行管理和运行。这个体验设计的核心在于:用户能够借助类似聊天的交互方式快速生成应用原型,并在后续通过自然语言逐步完善。
📌 GitHub NextGitHub Next[7] 是 GitHub 的一个研究和开发团队,专注于探索软件开发的未来。这个团队由研究人员和工程师组成,旨在推动各种创新项目和技术原型,以改善开发人员的工作体验,并促进更高效的协作。例如 GitHub Copilot[8]、Copilot CLI[9]、Monospaced[10](一个等宽编程字体,支持连字符)等项目均出自该团队。
GitHub Spark 核心
GitHub Spark 主要由三个核心组件构成,协同作用以支持用户从想法到应用的快速过渡:
NL 驱动的编辑器:用户可以通过简单的自然语言描述应用需求,并随着时间的推移不断调整和完善。
托管运行时环境:这个环境专门为用户创建的 spark 提供所需的资源,包括数据存储、主题自定义和大型语言模型(LLMs)支持。
支持 PWA 的仪表盘:该仪表盘可以让用户从任何设备管理和启动 spark 应用,使得应用在桌面和移动端均能流畅使用。
GitHub Spark 的设计目的是降低创建应用的复杂性,让用户不必担心代码或部署问题,同时也支持用户随时查看和编辑代码。对于有编码经验的开发人员,这种代码可见性和可编辑性带来了更大的灵活性,尤其是在 AI 生成的代码需要修正时,用户可以轻松介入,确保应用符合预期。
微应用理念:轻量化、个性化
GitHub Spark 提出的“微应用”(micro apps)理念,受到 “Unix 哲学” 的启发,强调应用应专注于单一功能,且做到极致,特别是为了满足个人用户在特定时间内的需求。微应用的“微”并非指应用价值小,而是指其功能上的精简。比如,GitHub Spark 团队在项目开发期间创建了许多有趣的小应用,从生活管理工具到学习辅助工具,再到一些轻松有趣的动画应用,每个微应用都是根据其创作者的需求量身定制,展示了微应用在个性化体验方面的独特魅力。
一个用于记录每周 KTV 之夜的应用,包含每位受邀嘉宾的状态信息。
关键功能:从自然语言到应用预览
GitHub Spark 中的自然语言工具链为用户提供了轻松的创作体验。开发过程通过以下四个核心功能辅助。
交互式预览
用户输入自然语言描述后,Spark 会立即生成代码并呈现应用预览。这种即时的“应用反馈”模式帮助用户在视觉上逐步确认需求,并进行快速迭代。
修订版本
Spark 可以基于用户描述生成多个版本,每个版本会有细微但有意义的差异,为用户提供多种设计和交互的灵感。
历史记录
每次修改都会自动保存,允许用户随时恢复早期版本。这种功能不仅让开发更加无忧,也为用户在共享 spark 时提供了查看他人创作思路的机会。
模型选择
Spark 提供多个大型语言模型的选择,包括 Anthropic 的 Claude Sonnet 和 OpenAI GPT 模型,用户可以根据需求选择不同模型生成的代码。
这些功能设计的目标在于降低用户的开发负担,提升创作流畅性,使自然语言驱动的开发过程更轻松、更富有创意。
托管环境:免部署、可扩展的应用管理
GitHub Spark 并不仅仅是代码生成器,它更是一个“以应用为中心”的平台,帮助用户将想法转化为实际的功能应用。其托管运行时环境提供了以下几个关键能力,让 GitHub Spark 成为了一个功能完善的微应用托管平台,用户不仅可以轻松创建应用,还可以实时在不同设备上体验。
免部署托管
用户的代码和应用会自动托管在 Spark 环境中,支持桌面、平板和移动端的访问和安装。
自定义主题
Spark 内置了一套美观的 UI 组件和主题系统,用户可以轻松调整主题颜色、边框半径、布局间距等,让应用外观更加个性化。
数据持久化
大多数应用需要数据存储,GitHub Spark 提供了托管的键值存储,并集成数据编辑器,用户可以轻松查看和管理应用状态。
集成模型 prompt
Spark 环境支持 GitHub 的 AI 模型,允许用户在应用中添加生成式 AI 功能,例如摘要生成、内容创作等,且无需编写代码。
未来展望
尽管 GitHub Spark 目前仍处于技术预览阶段,但其潜力十分巨大。GitHub CEO Thomas Dohmke 表示,Spark 的目的是为用户提供一个工具,用以探索新想法并简化开发过程。未来,GitHub 计划扩展 Spark 的协作功能和编辑器功能,如提供公共作品库、支持 fork 的语义合并、多用户协作模式等。除此之外,GitHub 还计划拓展其运行时环境,支持更多内置组件、第三方服务集成、文件存储和向量搜索等新功能。
延伸阅读
Copilot 模型选择
在最新的 GitHub Universe 活动中,GitHub 宣布为 Copilot 引入多模型选择功能(Bringing developer choice to Copilot with Anthropic’s Claude 3.5 Sonnet, Google’s Gemini 1.5 Pro, and OpenAI’s o1-preview[11]),支持 Anthropic 的 Claude 3.5 Sonnet、Google 的 Gemini 1.5 Pro 和 OpenAI 的 o1-preview 和 o1-mini。这些模型将逐步上线,开发者可以选择最适合的模型,用于 Copilot Chat、代码审查、自动修复等场景。Claude 3.5 Sonnet 擅长复杂多步骤任务,Gemini 1.5 Pro 支持多模态处理,o1-preview 具有更强的代码推理能力,为开发者提供更多选择。
不同模型效果演示:
Unix 设计哲学
Mike Gancarz 在 1995 年出版了一本关于此主题的小书《The UNIX Philosophy》,他列出了两套原则:9 个主要原则和 10 个次要原则。
主要原则
小即是美(Small is beautiful.)。小型程序相较于大型程序有极大的优势,其中之一就是可以以独特且有用的方式与其他小程序组合。
让每个程序只做好一件事(Make each program do one thing well.)。专注于单一任务的程序可以减少不必要的代码,从而减少额外开销、复杂性和缺乏灵活性。
尽早构建原型(Build a prototype as soon as possible.)。大多数用户在看到软件之前并不知道自己真正需要什么,因此需求文档常常无法准确反映用户的实际需求。Unix 设计哲学将原型开发作为方法论的核心:尽早给用户提供一些初步成果,让用户提出反馈,并以此为基础进行改进。
优先选择可移植性而非效率(Choose portability over efficiency.)。如果当下的硬件能够勉强运行某个程序,未来的硬件将轻松胜任。因此开发人员的任务是确保程序能够轻松在新硬件上运行。
将数据和配置信息存储在扁平的 ASCII 文件中(Store data and configuration info in flat ASCII files.)。宝贵的数据通常比任何一个程序、机器、编程语言或用途更为长久。数据只有在被使用时才有价值,而扁平的文件能帮助数据在最长时间内保持可用性。对于复杂的数据结构,如果扁平文本格式不合适,可以使用像 XML 这样的结构化文本格式,这样总是可以去除标记来获取原始数据。
利用软件的杠杆效应(Use software leverage to your advantage.)。许多程序员对可复用代码模块(re-usable code modules)的重要性缺乏深入理解。代码复用帮助开发者利用软件的杠杆效应,一些 Unix 开发者利用这一概念在相对较短的时间内创建了大量应用程序。
使用 shell 脚本增加杠杆效应和可移植性(Use shell scripts to increase leverage and portability.)。脚本具有极大的杠杆效应——每行脚本都可以调用多个“正规”程序,每个程序可能包含数千行代码。无法复用其他程序的程序员将不得不重新编写这些功能。
避免捆绑的用户界面(Avoid captive user interfaces.)。一个阻止用户使用其他命令的程序会“束缚”用户,阻止其利用其他命令。程序应具有多种使用方式,以最大化其实用性。
让每个程序成为过滤器(Make every program a filter.)。所有软件的基本性质是只能修改数据,不能创造数据。因此它们应被编写成过滤器,因为它们本质上就是过滤器。
次要原则
允许用户定制环境(Allow the user to tailor the environment.)。没有单一决策适合所有用户——不要强加。环境的可定制性越高,用户越能根据自己的需求调整,使用起来会更愉快。
使操作系统内核保持小而轻量(Make operating system kernels small and lightweight.)。尽管对新功能的追求永无止境,Unix 开发者倾向于将操作系统的核心部分保持小巧。他们不总是能实现这一目标,但这是他们的追求。
使用小写并保持简洁(Use lower case and keep it short.)。在 Unix 环境中使用小写字母已成传统,即便当初因为电传机上带有下行的文本更易阅读的原因已不再适用。
节约纸张(Save trees.)。打印到纸上的数据基本上就“死”了。保持所有文本在线,使用强大的工具来处理文本,有充分的理由。
沉默是金(Silence is golden.)。沉默的命令通常更易用,仅提供所需的功能而无多余信息。可以为喜欢更具对话性的用户提供包装器。
并行思维(Think parallel.)。大多数任务由可以并行处理的子任务组成,这对用户交互也适用。并行处理可节省大量时间和减少挫败感。
整体大于部分的和(The sum of the parts is greater than the whole.)。一组小程序构建的大型应用比单个大型程序更灵活,因而更有用。尽管两种方法可能都具有相同的功能,但“小程序集合”方法更具前瞻性。
寻求 90% 的解决方案(Look for the 90% solution.)。做到 100% 往往很难,做到 90% 更高效且成本更低。处理 90% 并让剩下的 10% 自生自灭——通常它们会比你更好地解决自己的特殊需求。
劣质即优(Worse is better.)。便宜但有效的东西比高质量而昂贵的更可能普及。PC 兼容世界借鉴了这一思想并取得了很大成功。
分层思维(Think hierarchically.)。分层允许任务和属性在嵌套元素中统一应用。这是一个鼓励分解和模块化的强大理念。