将工作拆解为微小的迭代块
范围管理（Scope Management）决定成败——给 LLM 易于处理的任务，而不是整个代码库。
我学到的一个至关重要的教训是：避免要求 AI 产出庞大、单一的内容。相反，我们将项目拆分为迭代步骤或任务单（Tickets），并逐一攻克。这虽然借鉴了优秀的软件工程实践，但在有 AI 参与的情况下显得尤为重要。
LLM 在处理专注的提示词时表现最佳：一次只实现一个函数、修复一个 Bug 或添加一个功能。例如，在规划完成后，我会提示代码生成模型：“好了，让我们开始执行计划中的第一步。”我们编写代码、进行测试，然后进入第二步，以此类推。每个块都足够小，AI 可以在上下文中轻松处理，你也能够完全理解它生成的代码。
这种方法能防止模型“跑偏”。如果你一次要求太多，它很可能会变得混乱，或者产出一堆难以理清的**“乱麻代码”。有开发者报告称，当他们试图让 LLM 生成应用程序的大部分内容时，最终得到了不一致且重复的代码——“就像 10 个互不沟通的开发者在同时工作”。我也曾经历过这种痛苦；解决办法是停下来，退后一步，将问题拆解得更细**。在每次迭代中，我们都带着已构建内容的上下文，循序渐进地增加新功能。这也能完美契合**测试驱动开发（TDD）**的方法——我们可以边做边为每个部分编写或生成测试。
目前的许多 AI 编程工具都显式支持这种分块工作流。例如，我经常生成一个结构化的**“提示词计划（Prompt Plan）”文件，其中包含每个任务的提示词序列，以便 Cursor 等工具可以逐一执行。核心点在于避免跨度过大**。通过小循环迭代，我们能极大地降低灾难性错误的概率，并能迅速纠正方向。LLM 擅长快速、受限的任务——请务必利用好这一点。
提供详尽的上下文与引导
LLM 的表现上限取决于你提供的上下文——向它们展示相关的代码、文档和约束条件。
在处理代码库时，我会确保喂给 AI 表现出色所需的所有信息。这包括它需要修改或参考的代码、项目的技术约束，以及任何已知的坑或首选方案。
现代工具对此很有帮助：例如，Anthropic 的 Claude 可以在“Projects”模式下导入整个 GitHub 仓库，而 Cursor 或 Copilot 等 IDE 助手会自动将打开的文件包含在提示词中。但我通常会做得更深入——如果我怀疑模型缺乏某些信息，我会使用 Context7 等 MCP 工具，或者手动将代码库的重要部分、API 文档复制到对话中。
资深 LLM 用户非常强调这种“上下文打包”步骤。例如，在编码前进行一次**“脑力倾倒（Brain Dump）”**，告诉模型它应该知道的一切，包括：高层目标和不变性约束、优秀方案的示例，以及需要避开的坑。如果我要求 AI 实现一个复杂的方案，我会告诉它哪些幼稚的方案太慢，或者提供其他地方的参考实现。如果我使用的是一个冷门的库或全新的 API，我会粘贴官方文档或 README，这样 AI 就不会盲目摸索。
现在已经有了自动化上下文打包的工具。我尝试过 gitingest 或 repo2txt，它们能将代码库的相关部分“倾倒”到一个文本文件中供 LLM 阅读。在处理大型项目时，这些工具简直是救星。原则是：不要让 AI 在信息碎片的基础上操作。如果修复一个 Bug 需要理解四个不同的模块，那就把这四个模块都展示给它。虽然要注意 Token 限制，但目前的顶尖模型拥有巨大的上下文窗口（数万个 Token），请明智地使用它们。我通常会选择性地只包含与当前任务相关的代码，并明确告诉 AI 哪些内容不在讨论范围内，以节省 Token。
此外，通过提示词中的注释和规则来引导 AI 也非常有效。我会在代码片段前加上：“这是 X 的当前实现。我们需要扩展它以实现 Y，但注意不要破坏 Z。”这些微小的提示能起到巨大的作用。LLM 是教条主义者——它们会严格执行指令，所以请给它们详细且带有上下文的指令。通过主动提供上下文和引导，我们能最大限度地减少幻觉和偏离目标的建议，从而获得契合项目需求的代码。
