原文：Harper Reed - 2025.02.16

tl;dr: 头脑风暴制定规范 → 制定计划 → 使用 LLM 生成代码。离散循环。然后见证魔法。✩₊˚.⋆☾⋆⁺₊✧

我一直在使用大语言模型开发许多小型产品。这个过程既有趣又有用，但也存在可能浪费大量时间的陷阱。之前有朋友问我如何使用 LLM 编写软件，我想"天啊，你需要多少时间听我讲！“于是就有了这篇文章。

（注：如果你是 AI 反对者，可以直接跳到结尾部分）

我与许多开发朋友讨论过这个话题，我们的方法大体相似，只是在具体细节上各有调整。

以下是我的工作流程。它建立在我的个人实践、与朋友的交流以及从各种网络社区收集的最佳实践之上。

这个流程目前运行良好，但可能在两周后失效，或者效率翻倍。¯\_(ツ)_/¯

开始吧

Juggalo 机器人

我总是觉得这些 AI 生成的图片有点可疑。向我的 Juggalo 编程机器天使打个招呼吧！

开发有很多途径，但我通常遇到两种情况：

  • 全新项目代码（Greenfield）
  • 现代化改造中的遗留代码（Legacy modern）

我将展示这两种情况的处理流程

全新项目开发

对于全新项目开发，我发现以下流程效果显著。它提供了可靠的规划和文档方法，允许通过小步快跑的方式轻松执行。

绿地项目

步骤一：构思提炼

使用对话式 LLM（我使用 ChatGPT 4o/o3）来完善想法：

Ask me one question at a time so we can develop a thorough, step-by-step spec for this idea. Each question should build on my previous answers, and our end goal is to have a detailed specification I can hand off to a developer. Let’s do this iteratively and dig into every relevant detail. Remember, only one question at a time.

Here’s the idea:

<IDEA>

请每次只提一个问题，通过迭代对话逐步完善这个想法的详细规范。每个问题都应基于我的前一个回答，最终目标是形成可供开发人员直接执行的详细规格说明。让我们通过迭代深入每个相关细节。记住，每次只能提一个问题。

以下是想法概要：

<IDEA>

在头脑风暴结束时（会自然得出结论）：

Now that we’ve wrapped up the brainstorming process, can you compile our findings into a comprehensive, developer-ready specification? Include all relevant requirements, architecture choices, data handling details, error handling strategies, and a testing plan so a developer can immediately begin implementation.

现在我们已经完成头脑风暴，能否将讨论结果整理成完整的开发就绪规范？请包含所有相关需求、架构选择、数据处理细节、错误处理策略和测试计划，以便开发人员可以立即开始实施。

这将输出一个相当完整且直接的规范文档。我喜欢将其保存为代码库中的 spec.md。

这个规范有多种用途。虽然我们用于代码生成，但也可以用于通过推理模型寻找漏洞（需要更深入！）、生成白皮书或商业模型。你还可以进行深入研究并获得万字支持文档。

步骤二：制定计划

将规范传递给合适的推理模型（o1*、o3*、r1）：

（TDD 版本提示词）

Draft a detailed, step-by-step blueprint for building this project. Then, once you have a solid plan, break it down into small, iterative chunks that build on each other. Look at these chunks and then go another round to break it into small steps. Review the results and make sure that the steps are small enough to be implemented safely with strong testing, but big enough to move the project forward. Iterate until you feel that the steps are right sized for this project.

From here you should have the foundation to provide a series of prompts for a code-generation LLM that will implement each step in a test-driven manner. Prioritize best practices, incremental progress, and early testing, ensuring no big jumps in complexity at any stage. Make sure that each prompt builds on the previous prompts, and ends with wiring things together. There should be no hanging or orphaned code that isn't integrated into a previous step.

Make sure and separate each prompt section. Use markdown. Each prompt should be tagged as text using code tags. The goal is to output prompts, but context, etc is important as well.

<SPEC>

请为这个项目制定详细的构建蓝图。在形成可靠计划后，将其分解为可迭代的小模块。检查这些模块并再次分解为更小步骤。评估结果，确保步骤足够小以保证安全实现和严格测试，同时又足够大以推动项目进展。反复迭代直到步骤大小适合本项目。

基于此，你应能为代码生成 LLM 提供系列提示词，以测试驱动的方式逐步实现。优先考虑最佳实践、增量进展和早期测试，确保每个阶段复杂度没有突增。确保每个提示词都建立在前序步骤基础上，最终完成系统集成。不应存在未集成的孤立代码。

请用 markdown 分隔每个提示词部分。每个提示词需使用代码标签标记。目标是输出提示词，但上下文等信息也很重要。

<SPEC>

（非 TDD 版本提示词）

Draft a detailed, step-by-step blueprint for building this project. Then, once you have a solid plan, break it down into small, iterative chunks that build on each other. Look at these chunks and then go another round to break it into small steps. review the results and make sure that the steps are small enough to be implemented safely, but big enough to move the project forward. Iterate until you feel that the steps are right sized for this project.

From here you should have the foundation to provide a series of prompts for a code-generation LLM that will implement each step. Prioritize best practices, and incremental progress, ensuring no big jumps in complexity at any stage. Make sure that each prompt builds on the previous prompts, and ends with wiring things together. There should be no hanging or orphaned code that isn't integrated into a previous step.

Make sure and separate each prompt section. Use markdown. Each prompt should be tagged as text using code tags. The goal is to output prompts, but context, etc is important as well.

<SPEC>

请为这个项目制定详细的构建蓝图。在形成可靠计划后，将其分解为可迭代的小模块。检查这些模块并再次分解为更小步骤。评估结果，确保步骤足够小以保证安全实现，同时又足够大以推动项目进展。反复迭代直到步骤大小适合本项目。

基于此，你应能为代码生成 LLM 提供系列提示词来逐步实现。优先考虑最佳实践和增量进展，确保复杂度没有突增。确保每个提示词都建立在前序步骤基础上，最终完成系统集成。不应存在未集成的孤立代码。

请用 markdown 分隔每个提示词部分。每个提示词需使用代码标签标记。目标是输出提示词，但上下文等信息也很重要。

<SPEC>

应输出可通过 aider、cursor 等工具执行的提示计划。我喜欢将其保存为代码库中的 prompt_plan.md。

然后生成可勾选的 todo.md：

Can you make a `todo.md` that I can use as a checklist? Be thorough.

能否制作一个详细的待办清单 `todo.md` 作为检查表？

可保存为代码库中的 todo.md。代码生成工具应能在处理时勾选 todo.md，这对跨会话保持状态很有帮助。

计划完成！

现在你拥有了可靠的计划和文档，可帮助顺利执行和构建项目。

整个过程大约需要15分钟。相当高效，说实话有点疯狂。

步骤三：执行

执行阶段有很多选择，成功与否主要取决于步骤二的完成质量。

我尝试过使用 github workspace、aider、cursor、claude engineer、sweep.dev、chatgpt、claude.ai 等工具。这些工具效果都不错，预计适用于任何代码生成工具。

但我更偏爱原生 Claude 和 aider：

Claude 使用

我基本上是与 claude.ai 结对编程，逐个输入提示词。来回交互可能有点烦人，但总体有效。

我负责初始样板代码和正确设置工具链。这在初期提供了选择自由和技术指导。Claude 倾向于直接输出 React 代码——拥有坚实的语言基础、代码风格和工具链选择会很有帮助。

当遇到卡点时，我会使用 repomix 等工具进行迭代（稍后详述）。

工作流程如下：

  • 设置代码库（样板文件、uv init、cargo init 等）
  • 将提示词粘贴到 Claude
  • 从 claude.ai 复制代码到 IDE
  • 运行代码和测试
  • ……
  • 成功则继续下一个提示词
  • 失败则使用 repomix 将代码库传给 Claude 调试
  • 循环往复 ✩₊˚.⋆☾⋆⁺₊✧

Aider 使用

Aider 的使用体验新奇有趣。我发现它能很好地适配步骤二的输出，可以用极少量工作走得很远。

工作流程与上述类似，但改为将提示词输入 aider。然后就能观看 aider 的"表演”，仿佛在玩 cookie clicker。

插播：Aider 在其 LLM 排行榜中对新代码模型进行基准测试。这是了解新模型效果的好资源。

测试环节更轻松，因为 aider 可以自动运行测试套件并调试问题。

工作流程：

  • 设置代码库
  • 启动 aider
  • 输入提示词
  • 观看 aider 跳舞 ♪┏(・o･)┛♪
  • aider 运行测试，或手动验证应用
  • 成功则继续下一个提示词
  • 失败则与 aider 问答修复
  • 循环往复 ✩₊˚.⋆☾⋆⁺₊✧

成果

我用这个工作流构建了大量项目：脚本、Expo 应用、Rust CLI 工具等。它跨编程语言和场景都表现良好。

如果你有拖延中的大小项目，我建议尝试这个方法。你会惊讶于短时间内能取得的进展。

我的 hack 待办清单已清空，因为我边看电影边完成了所有项目。多年来第一次，我有时间接触新编程语言和工具，这拓展了我的编程视野。

非全新项目：迭代与增量开发

有时你需要维护现有代码库而非从头开始：

棕地项目

针对这种情况，我采用略有不同的方法。与上述流程相似，但减少"总体规划"，改为按任务规划。

获取上下文

每个深度使用 AI 的开发者都有不同的工具，但你需要某种方式将源代码高效输入 LLM。

我目前使用 repomix。在全局配置 ~/.config/mise/config.toml 中定义了任务集合（mise 规则），可对代码库执行各种操作。

LLM 任务列表：

1
2
3
4
5
6
7

LLM:clean_bundles           使用 repomix 生成 LLM 代码包输出文件
LLM:copy_buffer_bundle      将生成的 LLM 代码包从 output.txt 复制到剪贴板
LLM:generate_code_review    根据 output.txt 存储的代码库内容生成代码审查报告
LLM:generate_github_issues  根据 output.txt 内容生成 GitHub issues
LLM:generate_issue_prompts  根据 output.txt 内容生成问题提示
LLM:generate_missing_tests  根据 output.txt 内容生成缺失测试用例
LLM:generate_readme         根据 output.txt 内容生成 README.md

生成包含代码库上下文的 output.txt。如果 token 超限，可以编辑生成命令，排除与当前任务无关的代码部分。

mise 的优势在于任务可以在工作目录的 .mise.toml 中重定义。当代码库差异较大时，可以用不同工具打包代码，只要生成 output.txt 就能使用 LLM 任务。我经常覆盖 repomix 步骤来包含更广泛的忽略模式，或使用更有效的打包工具。

最终，mise 任务运行类似：cat output.txt | LLM -t readme-gen > README.md 或 cat output.txt | LLM -m claude-3.5-sonnet -t code-review-gen > code-review.md。核心在于 LLM 命令处理繁重工作（支持不同模型、保存密钥和使用提示模板）。

例如需要快速审查和修复测试 coverage：

Claude 流程

  • 进入代码目录
  • 运行 mise run LLM:generate_missing_tests
  • 查看生成的 markdown 文件（issue-prompts.md）
  • 获取完整代码上下文：mise run LLM:copy_buffer_bundle
  • 将上下文和第一个缺失测试"问题"粘贴到 Claude
  • 将生成的代码复制到 IDE
  • ……
  • 运行测试
  • 循环往复 ✩₊˚.⋆☾⋆⁺₊✧

Aider 流程

  • 进入代码目录
  • 启动 aider（始终在新分支操作）
  • 运行 mise run LLM:generate_missing_tests
  • 查看生成的 markdown 文件
  • 将第一个缺失测试"问题"粘贴到 aider
  • 观看 aider 跳舞 ♪┏(・o･)┛♪
  • ……
  • 运行测试
  • 循环往复 ✩₊˚.⋆☾⋆⁺₊✧

这是逐步改进代码库的有效方式。在大代码库中进行小规模修改时特别有用，任何规模的任务都能处理。

提示词魔法

这些快速技巧能有效增强项目健壮性，既快速又高效。

以下是我用于现有代码库的部分提示词：

代码 review

You are a senior developer. Your job is to do a thorough code review of this code. You should write it up and output markdown. Include line numbers, and contextual info. Your code review will be passed to another teammate, so be thorough. Think deeply  before writing the code review. Review every part, and don't hallucinate.

你是一位高级开发人员，任务是对代码进行全面审查。请以 markdown 格式输出审查报告，包含行号和上下文信息。审查报告将转交其他开发人员，因此务必详尽。在撰写前深入思考，审查每个部分，避免幻觉。

GitHub Issue 生成

（需要自动化实际 issue 提交！）

You are a senior developer. Your job is to review this code, and write out the top issues that you see with the code. It could be bugs, design choices, or code cleanliness issues. You should be specific, and be very good. Do Not Hallucinate. Think quietly to yourself, then act - write the issues. The issues will be given to a developer to executed on, so they should be in a format that is compatible with github issues

你是一位高级开发人员，任务是审查代码并列出主要问题（包括 bug、设计选择或代码整洁度问题）。请具体明确，确保质量。禁止幻觉。先静心思考，然后写出符合 GitHub issue 格式的问题清单。

测试缺失

You are a senior developer. Your job is to review this code, and write out a list of missing test cases, and code tests that should exist. You should be specific, and be very good. Do Not Hallucinate. Think quietly to yourself, then act - write the issues. The issues  will be given to a developer to executed on, so they should be in a format that is compatible with github issues

你是一位高级开发人员，任务是审查代码并列出缺失的测试用例。请具体明确，确保质量。禁止幻觉。先静心思考，然后写出符合 GitHub issue 格式的测试需求清单。

这些提示词略显"老旧"（可称为"婴儿潮一代提示词"），需要重构改进。如有优化建议请告知。

滑雪式开发 ᨒ↟ 𖠰ᨒ↟ 𖠰

当向他人描述这个过程时，我常说"必须积极跟踪进展，因为很容易失控"。

不知为何，我在谈论 LLM 时常说"over my skies"。也许因为这就像在粉雪上优雅滑行，突然陷入"什么情况！“的迷茫，然后跌落悬崖。

使用规划步骤（如全新项目流程）有助于保持控制。至少你有文档可以核对。我也坚信测试的重要性——特别是在使用狂野的 aider 编码时，有助于保持代码质量。

尽管如此，我仍常陷入"滑雪失控"状态。有时短暂休息或散步会有帮助。这种问题解决过程虽加速到惊人速度，但本质未变。

我们常要求 LLM 在正经代码中加入荒诞元素。例如要求创建背景故事文件并在 UI 中引用——用于 Python CLI 工具管理云函数或待办清单。天空才是极限。

孤独感 (｡•́︿•̀｡)

这种工作流的主要缺点是单人模式——所有交互都是单机游戏。

我经历过多年单人编程、结对编程和团队开发。与人合作总是更好。这些工作流不适合团队协作，机器人会产生冲突，合并噩梦，上下文复杂。

我真心希望有人能解决这个问题，使 LLM 编码成为多人游戏，而非单人 hacker 体验。这方面大有可为。

快来解决这个问题！

ⴵ 时间魔法 ⴵ

代码生成极大提升了个人的代码产出量，但有个奇特副作用：我发现自己有很多等待 LLM 生成 token 的"空闲时间”。

打印

恍如昨日的记忆

我已调整工作方式，开始利用等待时间：

  • 为其他项目启动"头脑风暴"
  • 听唱片
  • 玩 cookie clicker
  • 与朋友和机器人交流

这种 hacker 体验令人着迷。想不出还有哪个时期能如此高效地产出代码。

反对者的声音 ╭( •̀_•́ )╮

很多朋友认为"LLM 糟透了"。我不介意这种观点，虽不认同，但认为保持怀疑态度很重要。讨厌 AI 的理由很多，我主要担忧能耗和环境影响。但…代码必须流淌。对吧…唉。

如果你愿意了解但不想成为赛博程序员，我的建议不是改变观点，而是阅读 Ethan Mollick 关于如何应用 LLM 的著作：Co-Intelligence: Living and Working with AI。

这本书很好地解释了技术优势，而非科技无政府资本主义式的说教。我发现它非常有用，并与阅读过的朋友进行了许多高质量的交流。强烈推荐。