smol developer: 每个人都能拥有的「AI 初级程序员」

它是什么？

想象一下：你对 AI 说一句「帮我写一个带用户登录功能的博客系统」，然后去泡杯咖啡，回来时整个代码仓库已经搭建好了——文件夹结构、数据库模型、前后端接口、甚至配置文件，一应俱全。这不是科幻小说里的场景，而是 smol developer 正在做的事情。

smol developer（GitHub: smol-ai/developer，⭐ 12K+）由 AI 领域知名博主 @swyx 创建，是一个「初级程序员」级别的 AI 编程代理。与传统的单文件代码补全工具不同，它的设计目标是：从产品需求出发，一次性生成整套可运行的代码仓库。

背景故事：为什么需要「会搭房子的初级程序员」？

2023 年，大语言模型开始真正进入编程辅助领域。大多数工具停留在「帮我写这个函数」的单点层面——Copilot、Codeium，无不如此。但程序员真正花时间的，其实不是写代码，而是搭建项目骨架：创建目录结构、配置依赖、规划模块关系……这些重复性的「体力活」消耗了大量时间，却没有任何 AI 工具真正解决过。

smol developer 的诞生正是为了填补这个空白。它不是帮你写一行代码，而是帮你搭建一座房子。从产品需求出发，经过「规划 → 确定文件路径 → 分工生成」的流程，输出一个完整项目。

工作原理：三层提示词架构

smol developer 的核心是一个巧妙的三层提示词流水线：

第一层：规划（plan）。将用户的自然语言需求转化为结构化的开发计划，输出 shared_deps.md，明确各模块之间的依赖关系。这是保证「整体一致性」的关键——如果让 AI 自由生成，文件之间很容易出现接口不匹配、变量名冲突等问题。通过提前规划「共享依赖」，确保每个文件「知道自己该做什么、该和谁配合」。

第二层：规划文件路径（specify_file_paths）。利用 OpenAI 的 Function Calling API，结构化地确定需要生成哪些文件，以及每个文件的路径。这保证了输出是 JSON 格式的、程序可解析的文件列表，而非自由文本。

第三层：逐文件生成（generate_code_sync）。遍历文件列表，对每个文件独立生成代码。每次生成都携带完整上下文（原始需求 + 共享依赖 + 目标文件路径），确保代码既满足具体需求，又与整体架构保持一致。

这种「规划 → 拆解 → 生成」的三层架构，是 smol developer 与简单 Prompt 工程的核心差异。它的本质是让 AI 扮演架构师，而不是打字员。

三种使用方式：CLI、库、API

smol developer 提供了三种接入方式，适配不同场景：

Git Repo 模式（CLI）：克隆仓库，通过 python main.py "需求描述" 直接运行。适合快速原型验证，支持 --debug 查看流式输出，--prompt 加载长提示词文件。生成的代码默认放在 generated/ 目录。

库模式（Library）：通过 pip install smol_dev 安装，在自己的 Python 项目中导入核心函数：

from smol_dev.prompts import plan, specify_file_paths, generate_code_sync

prompt = "一个 HTML/JS/CSS 井字棋游戏"
shared_deps = plan(prompt)
file_paths = specify_file_paths(prompt, shared_deps)
for file_path in file_paths:
    code = generate_code_sync(prompt, shared_deps, file_path)
    # 写入文件或展示在 UI 中

这是最有价值的模式——把 smol developer 的能力嵌入自己的产品中，比如低代码平台、Prompt IDE 或 AI 原生开发工具。

API 模式：通过 poetry run api 启动 HTTP 服务，基于 Agent Protocol 标准接口，支持跨语言调用和任务状态追踪。适合构建服务端 AI 编程服务。

技术栈：极简但精妙

smol developer 的技术选型非常克制：Python >= 3.10，核心依赖只有 4 个——OpenAI SDK（GPT-4 调用）、openai-function-call（结构化函数输出）、tenacity（重试机制）、agent-protocol（API 模式协议）。总代码量不过 5 个 Python 文件：prompts.py（提示词逻辑）、main.py（CLI 入口）、api.py（HTTP 服务）、utils.py（文件操作）、init.py（导出）。整个项目不到 500 行核心代码，却实现了完整的 AI 代理逻辑。

它的代码哲学是用提示词解决问题，而不是用代码解决问题——把复杂性转移到 prompt 里，保持底层逻辑的简洁。代码注释中甚至写道：「basically means GPT is able to talk to itself」，幽默地承认了这个设计的人为性。

上手门槛：极低，但有隐性条件

smol developer 本身的安装和运行门槛极低：pip install smol_dev 即可。但使用它有一个隐性前提——你需要有 OpenAI API Key。项目本身不提供模型，只负责组织和调用 GPT-4。

部署难度评为「简单」：无 GPU 需求（纯 CPU 推理），内存占用极低（约 512MB），磁盘仅需 50MB。Python 3.10+ 环境即可运行，无需 Docker——这既是优势（部署简单），也是局限（缺乏容器化隔离）。

局限与争议

生成一致性不稳定。涉及跨文件依赖的项目，容易出现「幻觉式依赖」——生成的代码中引用了不存在的模块或函数。README 中坦诚写道：「felt dirty at first but it works」——承认这是一种 hack。

反馈循环较慢。用 GPT-4 生成一个完整项目通常需要 2-4 分钟，即使有并行化加持，体验仍然偏慢。

无 self-heal 能力。理想中的 AI 编程代理应该能「运行代码 → 发现错误 → 自动修复」，但目前它做不到这一点。依赖人工反馈——把错误信息「粘贴」到 prompt 里，重新生成。

行业意义：AI 编程从「补全」走向「生成」

smol developer 的出现，代表了 AI 编程工具的一个范式转变：不是帮程序员写代码，而是替程序员做架构。如果说 Copilot 是「高级打字机」，smol developer 更像是「初级程序员的外包团队」。

GitHub 12K+ 的 stars 证明了这个方向的巨大需求。开源社区迅速出现多语言移植版本（JS、C#、Go），也说明 smol developer 的架构思路是可复制的。它或许不是终点，但确实是一个重要的里程碑。