用提示进行工程设计，而非单纯的提示工程

prompt.md 中的演示示例展示了由 AI 支持、但仍以开发者为中心的工作流的潜力：

• 开发者编写一个关于想要构建的应用的基本提示；
• main.py 生成代码；
• 开发者运行并阅读代码；
• 开发者可以：
  • 在发现提示中未明确的部分时，简单地补充提示内容；
  • 手动运行代码并找出错误；
  • 将错误信息粘贴到提示中，就像提交 GitHub 问题一样；
  • 如果需要更多帮助，还可以使用 debugger.py，它会读取整个代码库，提出具体的代码修改建议。

循环往复，直到满意为止。请注意，AI 只有在真正带来价值时才会被使用——一旦它妨碍了你的工作，你就可以毫不费力、不伤感情地接管代码库，完全摆脱这个小助手。（我们也可以让小开发者接管现有的代码库，并自行生成提示……但这属于未来的发展方向）

通过这种方式，你可以使用这个仓库的副本本身来原型化或开发你的应用。

库模式

这是小开发者 v1 的新功能！将 smol developer 添加到你自己的项目中！

pip install smol_dev

在这里，你可以将 main.py 的内容视为我们关于如何在你自己的应用中使用这些函数和提示的“文档”：

from smol_dev.prompts import plan, specify_file_paths, generate_code_sync

prompt = "一个 HTML/JS/CSS 井字游戏"

shared_deps = plan(prompt) # 返回一个长字符串，表示编码计划

# 如果需要，可以对 shared_deps 计划做些处理，比如请求用户确认或编辑，并循环迭代

file_paths = specify_file_paths(prompt, shared_deps) # 返回一个字符串数组，表示根据你的提示和 shared_deps 需要编写的文件名。依赖 OpenAI 新的 Function Calling API 来保证输出为 JSON 格式。

# 如果需要，可以对 filepaths 做些处理，比如展示计划

# 遍历 file_paths 数组，为每个文件生成代码
for file_path in file_paths:
    code = generate_code_sync(prompt, shared_deps，file_path) # 为每个文件生成源代码

    # 对文件的源代码做些处理，例如写入磁盘或在 UI 中显示
    # 此外还有一个异步版本的 `generate_code()`

API 模式（通过 Agent Protocol）

要启动服务器，请运行：

poetry run api

或者

python smol_dev/api.py

然后你可以使用以下命令调用 API：

要创建任务，运行：

curl --request POST \
  --url http://localhost:8000/agent/tasks \
  --header 'Content-Type: application/json' \
  --data '{
	"input": "用 Python 编写一个简单的脚本。它应该将 'Hello world!' 写入 hi.txt"
}'

你会得到如下响应：

{"input":"用 Python 编写一个简单的脚本。它应该将 'Hello world!' 写入 hi.txt","task_id":"d2c4e543-ae08-4a97-9ac5-5f9a4459cb19","artifacts":[]}

然后，要执行任务的一个步骤，复制上一步请求中获得的 task_id，并运行：

curl --request POST \
  --url http://localhost:8000/agent/tasks/<task-id>/steps

或者你也可以使用 Python 客户端库：

from agent_protocol_client import AgentApi，ApiClient，TaskRequestBody

...

prompt = "用 Python 编写一个简单的脚本。它应该将 'Hello world!' 写入 hi.txt"

async with ApiClient() as api_client:
    # 创建 API 类的实例
    api_instance = AgentApi(api_client)
    task_request_body = TaskRequestBody(input=prompt)

    task = await api_instance.create_agent_task(
        task_request_body=task_request_body
    )
    task_id = task.task_id
    response = await api_instance.execute_agent_task_step(task_id=task_id)

...

示例/提示词库

• 6分钟视频演示 - （抱歉音频加速了，当时我们为了推特优化，是个失误）

  • 这是最初的 smol 开发者演示——从提示词到完整的 Chrome 扩展程序，该扩展会请求并存储 API 密钥、生成弹出窗口、读取并传输页面内容，并利用 Anthropic Claude 将任意网站进行有用总结；根据输入文本的长度，模型还会切换到支持 10 万 token 的版本。
  • 提示词位于 prompt.md，输出结果为 /exampleChromeExtension。

• smol-plugin —— 用于 ChatGPT 插件的提示词（推文、分叉）

  

• 提示词生成宝可梦应用

  

• 政治竞选 CRM 程序示例

• 使用 GPT-4 创建 VSCode 扩展的经验教训（也在 HN 上发布）

• 7 分钟视频：Smol AI Developer —— 仅用一条提示词构建完整代码库，从提示词生成一个可运行的 OpenAI CLI Python 应用程序。

  

• 12 分钟视频：SMOL AI —— 一键使用 AGI 开发大型应用，在 40 分钟内以 9 美元搭建了一个相当复杂的 React/Node/MongoDB 全栈应用。

  

我正在积极寻找更多示例，请提交你的 PR！

抱歉示例不多，我知道这让人沮丧，但当时我真没想到会有这么多人参与，哈哈。

主要分叉/替代方案

请提交替代实现和在不同技术栈上的部署策略！

• JS/TS：https://github.com/PicoCreator/smol-dev-js smol-dev 的纯 JavaScript 变体，允许通过提示词进行更细粒度的增量修改（如果你不想一次性完成整个 spec2code 流程），从而可以将它实时接入任何项目中（无论好坏）。
• C#/Dotnet：https://github.com/colhountech/smol-ai-dotnet 用 C# 实现！
• Golang：https://github.com/tmc/smol-dev-go 用 Go 实现。
• https://github.com/gmchad/smol-plugin 可以按照 smol-developer 风格，在 Markdown 中指定 API，自动生成 @openai 插件。
• 您的分叉也欢迎提交！

创新与洞见

请订阅 https://latent.space/ 获取更详细的说明、见解和反思。

• 只需 Markdown 即可 —— Markdown 是进行完整程序合成的理想提示方式，因为它能轻松混合英文和代码（无论是 variable_names 还是完整的 ``` 代码块）。
  • 结果发现，你甚至可以在提示词中嵌入代码来指定指令，而 GPT-4 会完全照做。
• 复制粘贴式编程
  • 通过简单地粘贴 curl 请求和响应，教会程序如何围绕新的 API 编写代码（Anthropic 的 API 在 GPT3 的知识截止点之后）。
  • 将错误信息粘贴到提示词中，再模糊地告诉程序该如何处理。这种感觉有点像“日志驱动编程”。
• 通过 cat 查看整个代码库并结合错误信息进行调试，进而获得具体的修复建议——这尤其令人愉悦！
• 保持整个程序连贯性的技巧 —— 我们选择的示例用例是 Chrome 扩展，其中文件之间存在大量间接依赖关系。一旦出现跨文件依赖的幻觉，整个程序就会报错。
  • 我们通过增加一个中间步骤来解决这个问题：让 GPT 思考 shared_dependencies.md，然后坚持在每个文件的生成过程中都使用这份文件。这实际上相当于让 GPT 自己与自己对话……
  • ……不过目前还不完美。shared_dependencies.md 有时无法全面理解文件之间的硬性依赖关系。因此，我们直接在提示词中明确指定一个特定的 name。起初觉得有些“脏”，但确实有效，归根结底还是清晰明确的沟通而已。
  • 更多关于 SOTA smol-dev 提示词的内容，请参阅 prompt.md。
• 降低对陌生 API 的学习门槛
  • 我们从未真正学过 CSS 动画，但现在只要说想要一个“充满活力的红白条纹加载指示器”，它就能搞定。
  • 同样的情况也适用于 Chrome 扩展 Manifest v3——文档简直一团糟，但幸运的是，我们现在不需要阅读它们就能完成基本功能。
  • Anthropic 的文档（非常糟糕）缺少关于返回签名的指导。于是我们就直接把 curl 响应丢进提示词里，哈哈。
• Modal 就够了 —— 我们选择 Modal 是为了解决以下四个问题：
  • 解决开发和生产环境中的 Python 依赖地狱；
  • 实现代码生成的并行化；
  • 提供从本地开发到云端托管端点的简单升级路径（未来）；
  • 实现具有重试/退避机制的容错型 OpenAI API 调用，并附带存储功能（供未来使用）。

请订阅 https://latent.space/ 获取更详细的说明、见解和反思。

注意事项

我们当时是在开发 Chrome 扩展，需要生成图片资源，因此加入了一些特定于用例的代码来避免重复生成或销毁这些图片，但我们尚未决定如何将其通用化。

我们目前无法访问 GPT-4-32k，但如果可以的话，我们会尝试将整个 API/SDK 文档作为上下文注入进去。

当前的反馈循环非常缓慢（使用 time 测试显示，即使借助 Modal 实现并行化，用 GPT-4 生成一个程序仍需约 2–4 分钟，偶尔还会更高），但可以肯定的是，随着时间的推移，这个时间会逐渐缩短（详见下文“未来方向”）。

未来方向

待尝试的事项/欢迎讨论和提交 PR 的开放问题：

• 为每个生成的文件指定 .md 文件，并在其中提供进一步的提示，以便对输出进行微调。
  • 比如 popup.html.md、content_script.js.md 等等。
• 为现有代码库自动生成 prompt.md：编写一个脚本，读取代码库内容，并生成一段描述性的、项目符号列表形式的提示，用于重新生成该代码库。
  • 目前由 smol pm 实现了这一功能，但效果还不太理想。希望能有更多专注的打磨和努力，直到我们能实现一个能够自我生成的“Quine 式小开发者”为止，哈哈。
• 具备安装自身依赖的能力：
  • 这会涉及到对运行环境的依赖，而众所周知，这很容易导致依赖地狱。该如何避免呢？是使用 Docker 容器化？还是采用 Nix 包管理工具？亦或是参考 web container？
  • Modal 提供了一种有趣的思路：生成能够与 Modal 对话的函数，这样也能解决依赖问题。详情见：https://twitter.com/akshat_b/status/1658146096902811657。
• 自我修复能力：通过实际运行生成的代码，并将错误信息作为重新提示的依据。
  • 不过，在 Chrome 扩展环境中获取错误信息有一定难度，因此我们尚未尝试这一方案。
• 使用 Anthropic 作为代码生成层：
  • 可以运行 modal run anthropic.py --prompt prompt.md --outputdir=anthropic 来试用。
  • 但目前效果不佳，因为 Anthropic 在按照指令生成文件代码方面表现并不理想。
• 构建能够自动循环运行此代码并监控 prompt.md 文件的代理，每次都在新的 Git 分支上重新生成代码。
  • 代码可以同时在 5 个 Git 分支上生成，只需切换分支即可检查各分支的输出结果。