选择合适的模型（必要时使用多个模型）
并非所有编程 LLM 都是平等的——有目的地选择工具，并且不要害怕在过程中更换模型。
步入 2025 年，我们拥有了各种能力出众的编程专用 LLM。我工作流的一部分就是为每个任务选择最合适的模型或服务。有时，并行尝试两个或多个 LLM 甚至非常有价值，可以交叉检查它们处理同一问题的不同方式。
每个模型都有自己的“性格”。关键点在于：如果一个模型卡住了或产出了平庸的结果，换一个试试。我曾多次将同一个提示词从一个聊天窗口复制到另一个服务中，看看它是否能处理得更好。这种“模型音乐会”能在你遇到某个模型的盲区时救你于水火。
同时，确保你使用的是可用的最佳版本。如果条件允许，请使用最新的“Pro”级别模型——因为质量至关重要。虽然这通常意味着需要付费，但带来的生产力提升完全值得。最终，选择那个与你“气场”相合的 AI 结对程序员。我认识一些人仅仅因为喜欢某个模型的回复风格而选择它，这完全没问题——当你与 AI 进行持续对话时，用户体验和语气确实会产生影响。
就我个人而言，目前我更倾向于使用 Gemini 处理大量的编程工作，因为它的交互感觉更自然，且往往能一次性理解我的意图。但我绝不会在需要时犹豫切换到其他模型；有时，第二种意见能让解决方案浮出水面。总之：工欲善其事，必先利其器，记住你的武器库中有一群 AI 随时待命。
在全生命周期中利用 AI 编程
利用针对软件开发生命周期（SDLC）各阶段的 AI 助手，为你的工作流注入动力。
在命令行领域，新的 AI 智能体（Agents）层出不穷。Claude Code、OpenAI 的 Codex CLI 和 Google 的 Gemini CLI 让你能直接在项目目录中进行对话——它们可以读取文件、运行测试，甚至执行多步修复。我也使用过 Google 的 Jules 和 GitHub 的 Copilot Agent——这些是异步编程智能体，它们会将你的仓库克隆到云端虚拟机中，在后台处理任务（编写测试、修复 Bug，然后为你提交 PR）。
亲眼目睹这一过程甚至有些不可思议：你发出一个指令，如“重构 X 的支付模块”，过一会儿你就会收到一个包含代码更改和通过测试的拉取请求。我们确实生活在未来。
然而，这些工具并非万能，你必须了解它们的局限性。它们加速了编程中的机械部分——生成样板代码、应用重复性更改、自动运行测试——但它们仍然极大地受益于你的引导。例如，当我使用 Claude 或 Copilot 这样的智能体来实现某些功能时，我通常会提供之前步骤中的计划或待办清单，以便它知道确切的任务序列。如果智能体支持，我会在让它执行之前，将 spec.md 或 plan.md 加载到上下文中。这能确保它不偏离航向。
我们还没到让 AI 智能体在无人看管的情况下编写整个功能并期待完美结果的阶段。相反，我以受监督的方式使用这些工具：我会让它们生成甚至运行代码，但我会密切关注每一步，随时准备在出现偏差时介入。还有像 Conductor 这样的编排工具，允许你并行运行多个智能体处理不同任务——这是一种扩展 AI 帮助的方式。一些工程师正在尝试同时运行 3-4 个智能体处理独立的功能。我也涉猎过这种“大规模并行”方法；它在快速完成大量工作方面出奇地有效，但监控多个 AI 线程在精神上也非常疲惫！在大多数情况下，我坚持一次使用一个主智能体，或许再加一个次要智能体进行代码审查。
请记住，这些都是电动工具——你仍然掌控着开关并引导最终的结果。
