2026年的编程智能体工作流
内容
2025 年，AI 编码助手成为游戏规则的改变者，但有效地利用它们需要技能和结构。这些工具极大地增加了大型语言模型（LLM）在现实世界编码中可以做的事情，许多开发人员（包括我自己）都接受了它们。
例如，在 Anthropic，工程师们大量采用了 Claude Code，以至于今天大约 90% 的 Claude Code 代码都是由 Claude Code 自己编写的。然而，使用 LLM 进行编程并不是一个简单的点击即可实现的魔术体验 - 它是“困难和不直观的”，并且需要学习新的模式。批判性思维仍然至关重要。在一年多的项目中，我逐渐形成了一个类似于许多经验丰富的开发人员正在发现的工作流程：将 LLM 视为一个需要明确方向、上下文和监督的强大配对程序员，而不是自主判断。
在这篇文章中，我将分享我如何在 2026 年开始时规划、编码和与 AI 协作，总结我的经验和社区的集体学习。这是一种更有纪律的“AI 辅助工程”方法 - 在保持对软件生产负责的同时，大胆利用 AI。
如果您对我的工作流程感兴趣，请参阅“AI 本地软件工程师”，否则让我们直接深入探讨一些我学到的经验。
以明确的计划开始（在编码前制定规格）
不要只是向 LLM 抛出愿望 - 首先定义问题并规划解决方案。
一个常见的错误是直接跳入代码生成，使用模糊的提示。在我的工作流程中，以及在许多其他人的工作流程中，第一步是与 AI 进行详细的规格集思广益，然后概述一个一步一步的计划，在编写任何实际代码之前。对于一个新项目，我会描述这个想法，并要求 LLM 迭代地问我问题，直到我们充分阐述了需求和边缘情况。到最后，我们会将其编译成一个全面的 spec.md，其中包含需求、架构决策、数据模型，甚至测试策略。这个规格成为开发的基础。
接下来，我将规格输入到一个具有推理能力的模型中，并提示它生成项目计划：将实现分解为逻辑的、可管理的任务或里程碑。AI 本质上帮助我做一个小型的“设计文档”或项目计划。我经常迭代这个计划 - 编辑并要求 AI 批评或改进它 - 直到它变得连贯和完整。只有然后我才继续编码。这一前期投资可能看起来很慢，但它带来了巨大的回报。正如 Les Orchard 所说，这就像做一个**“15 分钟的瀑布”** - 一个快速的结构化规划阶段，使后续的编码变得更加顺畅。
拥有明确的规格和计划意味着当我们释放代码生成时，人类和 LLM 都知道我们正在构建什么以及为什么。简而言之，先规划迫使你和 AI站在同一立场上，并防止浪费循环。这是一个很多人想跳过的步骤，但经验丰富的 LLM 开发人员现在将强大的规格/计划视为工作流程的基石。
将工作分解为小的、迭代的块
范围管理是关键 - 将可管理的任务喂给 LLM，而不是一次性给它整个代码库。
我学到的一个关键经验是避免要求 AI 生成大型、单一的输出。相反，我们将项目分解为迭代步骤或任务，并一次处理一个。这与良好的软件工程实践相吻合，但在与 AI 协作时，这一点更加重要。LLM 在给定专注提示时表现最佳：一次实现一个函数、修复一个 bug 或添加一个功能。例如，在规划之后，我会提示代码生成模型：“好吧，让我们实现计划中的步骤 1”。我们编写代码、测试它，然后转到步骤 2，依此类推。每个块都足够小，以至于 AI 可以在上下文中处理它，你也可以理解它生成的代码。
这种方法可以防止模型脱轨。如果你一次要求太多，很可能会让它感到困惑或产生**“混乱的乱码”，难以理清。开发人员报告说，当他们尝试让 LLM 生成整个应用程序的大部分代码时，他们最终得到了不一致和重复的代码 - “就像 10 个开发人员在没有交谈的情况下工作一样”，有人说。我也经历过这种痛苦；解决方案是停止、后退并将问题分解为较小的部分**。每次迭代，我们都会带上已经构建的内容的上下文，并逐渐添加到它上面。这也符合**测试驱动开发（TDD）**的方法 - 我们可以为每个部分生成或编写测试（稍后会详细介绍）。
几种编码代理工具现在明确支持这种分块工作流程。例如，我经常生成一个结构化的**“提示计划”文件，其中包含每个任务的提示序列，因此像 Cursor 这样的工具可以逐一执行它们。关键点是避免巨大的飞跃**。通过小循环迭代，我们大大降低了灾难性错误的可能性，并且可以快速纠正错误。LLM 在快速、封闭的任务中表现出色 - 利用这一点。
提供大量的上下文和指导
LLM 的好坏取决于你提供的上下文 - 向它们展示相关代码、文档和约束。
在处理代码库时，我确保向 AI 提供所有必要的信息，以便它高效地执行。这些信息包括它应该修改或参考的代码、项目的技术约束以及任何已知的陷阱或首选方法。现代工具可以帮助完成这项工作：例如，Anthropic 的 Claude 可以在“项目”模式下将整个 GitHub 存储库导入其上下文中，而 IDE 辅助工具如 Cursor 或 Copilot 可以自动将打开的文件包含在提示中。但是我经常更进一步 - 如果我怀疑模型没有这些信息，我会使用像 Context7 这样的 MCP 或手动将代码库或 API 文档的重要部分复制到对话中。
专家 LLM 用户强调了这一“上下文打包”步骤。例如，进行**“脑力倾倒”**，将模型应该知道的所有内容都倾倒出来，包括：高级目标和不变量、良好解决方案的示例以及要避免的方法的警告。如果我要求 AI 实现一个棘手的解决方案，我可能会告诉它哪些天真的解决方案太慢，或者提供一个来自其他地方的参考实现。如果我使用一个小众库或一个全新的 API，我会粘贴官方文档或 README，这样 AI 就不会盲目地进行操作。所有这些前期上下文都极大地提高了其输出的质量，因为模型不是在猜测 - 它有事实和约束在面前。
现在有工具可以自动化上下文打包。我尝试过像 gitingest 或 repo2txt 这样的工具，它们本质上**“转储”**代码库的相关部分到一个文本文件中供 LLM 阅读。这些可以在处理大型项目时成为救命稻草 - 您可以生成一个输出.txt 包含关键源文件的包，并让模型处理它。原理是：不要让 AI 操作不完整的信息。如果一个 bug 修复需要理解四个不同的模块，请向它展示这四个模块。是的，我们必须注意令牌限制，但当前的前沿模型具有相当大的上下文窗口（成千上万的令牌）。明智地使用它们。我经常只包含与任务相关的代码的部分，并明确告诉 AI 哪些内容不在范围内（以节省令牌）。
我认为 Claude Skills 有潜力，因为它们将以前容易出错的重复提示转变为可持续和可重用的模块化能力，这些能力将指令、脚本和特定领域的专业知识打包成工具可以自动应用的模块，当请求与技能匹配时。这样，您可以获得比通用提示更可靠、更上下文感知的结果，并且您可以从一次性交互转向编码可重复的过程和团队知识以一致的方式处理任务。有一些社区策划的 Skills 集合，但我最喜欢的例子之一是 frontend-design 技能，它可以“结束”LLM 生成的 UI 中普遍存在的紫色设计美学。直到更多工具官方支持 Skills，变通方法 是可行的。
最后，使用注释和规则在提示中指导 AI。我可能会在代码片段之前添加：“这是 X 的当前实现。我们需要将其扩展到执行 Y，但要小心不要破坏 Z。”这些小提示可以带来很大的帮助。LLM 是字面主义者 - 它们会遵循指令，因此请提供详细的、有上下文的指令。通过主动提供上下文和指导，我们可以最小化幻觉和脱离轨道的建议，并获得符合项目需求的代码。
选择合适的模型（并在需要时使用多个模型）
并非所有编码 LLM 都是平等的 - 有意选择工具，并且不要害怕在流程中切换模型。
2025 年，我们被各种功能强大的代码专注 LLM 所宠坏。我的工作流程的一部分是为每个任务选择最合适的模型或服务。有时，尝试两个或多个 LLM 并行地处理同一个问题会很有价值。
每个模型都有自己的“个性”。关键是：如果一个模型卡住或给出平庸的输出，请尝试另一个模型。我已经将同一个提示从一个聊天窗口复制到另一个服务，以查看它是否可以更好地处理它。这“模型轮椅”可以在您遇到模型的盲点时拯救您。
另外，请确保您使用的是可用的最佳版本。如果可以，请使用最新的“专业”级别模型 - 因为质量很重要。并且，是的，这通常意味着需要付费获得访问权限，但生产力收益可以证明这是值得的。最终，选择与您**“氛围”相符的 AI 配对程序员。有些人喜欢一个模型，只是因为他们喜欢它的响应方式。我知道有些人更喜欢 Gemini 来进行大量的编码工作，因为与它的交互感觉更自然，它经常在第一次尝试时就理解我的请求。但是我不会犹豫地切换到另一个模型，如果需要的话；有时，第二种意见会有所帮助。在总结，我使用最适合工作的工具，并记住您有一个 AI 武库可供选择**。
跨生命周期利用 AI 编码
使用特定于编码的 AI 帮助来增强您的工作流程，涵盖整个 SDLC。
在命令行上，新的 AI 代理出现了。Claude Code、OpenAI 的 Codex CLI 和 Google 的 Gemini CLI 是 CLI 工具，您可以直接在项目目录中与它们交互 - 它们可以读取文件、运行测试，甚至可以多步骤地修复问题。我还使用了 Google 的 Jules 和 GitHub 的 Copilot Agent - 这些是异步编码代理，实际上会将您的存储库克隆到云 VM 中，并在后台处理任务（编写测试、修复 bug，然后为您打开 PR）。这有点令人毛骨悚然 - 您发出一个命令，如“为 X 重构支付模块”，一段时间后，您会收到一个带有代码更改和通过测试的 PR。我们确实生活在未来。您可以在 conductors to orchestrators 中阅读更多关于此内容的信息。
话虽如此，这些工具并非万无一失，您必须了解它们的局限性。它们加速了编码的机械部分 - 生成样板代码、应用重复性更改、自动运行测试 - 但它们仍然从您的指导中受益。例如，当我使用像 Claude 或 Copilot 这样的代理来实现某些功能时，我经常提供计划或要执行的任务清单，以便它知道确切的任务序列。如果代理支持它，我会在执行之前将我的 spec.md 或 plan.md 加载到上下文中。这让它保持在正确的轨道上。
我们还没有达到让 AI 代理无人值守地编码整个功能并期望完美结果的阶段。相反，我以监督的方式使用这些工具：我让它们生成甚至运行代码，但我始终密切关注每一步，随时准备在出现问题时介入。也有像 Conductor 这样的编排工具，可以让您并行运行多个代理以处理不同的任务（基本上是一种扩大 AI 帮助的方法）- 一些工程师正在尝试同时运行 3-4 个代理以处理不同的功能。我也尝试过这种“大规模并行”方法；它出乎意料地有效，可以快速完成很多工作，但同时也会让人感到精神疲劳！对于大多数情况，我坚持使用一个主要代理，可能还有一个用于审查的次要代理（稍后会讨论）。
只要记住这些是强大的工具 - 您仍然控制着触发器并指导结果。
保持人类在循环中 - 验证、测试和审查一切
AI 会很乐意生成看似合理的代码，但您负责质量 - 始终彻底审查和测试。 我的基本规则之一是永远不要盲目信任 LLM 的输出。正如 Simon Willison 恰当地 所说，将 LLM 配对程序员视为**“过于自信且容易出错”**。它以完全的信心编写代码 - 包括 bug 或无意义的内容 - 并且不会告诉您有什么问题，除非您发现了它。因此，我将每个 AI 生成的代码段都视为初级开发人员的代码：我阅读代码、运行它并根据需要进行测试。您绝对必须测试它编写的内容 - 运行那些单元测试，或手动执行功能，以确保它按预期工作。请阅读 vibe coding is not an excuse for low-quality work 中的更多内容。
事实上，我将测试融入工作流程本身。我的早期规划阶段通常包括为每个步骤生成测试列表或测试计划。如果我使用像 Claude Code 这样的工具，我会指示它在实现任务后运行测试套件，并在出现任何故障时进行调试。这种紧密的反馈循环（编写代码 → 运行测试 → 修复）是 AI 出色的地方，只要有测试。它并不奇怪，那些从编码代理中获得最多价值的人往往是那些拥有强大测试实践的人。像 Claude 这样的代理可以在有良好测试套件作为安全网的情况下“飞速”地完成项目。没有测试，代理可能会自满地认为一切都很好（“当然，没问题！”），而实际上它已经破坏了几件事情。所以，投资测试 - 它放大了 AI 的有用性和对结果的信心。
除了自动测试外，我还会进行代码审查 - 手动和 AI 辅助。我经常暂停并审查到目前为止生成的代码，逐行检查。有时我会启动第二个 AI 会话（或不同的模型），并要求它审查或检查第一个模型生成的代码。例如，我可能会让 Claude 编写代码，然后要求 Gemini：“可以审查这个函数以查找任何错误或改进吗？”这可以捕捉到微妙的问题。关键是不要跳过审查，只因为 AI 编写了代码。如果有的话，AI 编写的代码需要额外的审查，因为它有时可能看起来很有说服力，但隐藏着人类可能没有立即注意到的缺陷。
我还使用 Chrome DevTools MCP，它是与我之前的团队一起构建的，用于我的调试和质量循环，以弥合静态代码分析和实时浏览器执行之间的差距。它“给了我的代理眼睛”。它允许我授予我的 AI 工具直接访问浏览器可以看到的内容，检查 DOM，获取丰富的性能跟踪，控制台日志或网络跟踪。这种集成消除了手动上下文切换的摩擦，使我能够直接通过 LLM 进行自动化 UI 测试。它意味着可以根据实际运行时数据精确诊断和修复 bug。LLM 在解析差异和使用诸如 git bisect 之类的工具来查找 bug 引入位置方面非常出色。它们有无限的耐心来遍历提交历史，这可以增强我的调试。只要我有一个整洁的提交历史，才能做到这一点。
另一个好处是：小提交和良好的消息本质上记录了开发过程，这有助于代码审查（AI 或人类）。如果 AI 代理一次做了五个更改，出了问题，有了这些更改的单独提交，就更容易找出哪个提交导致了问题。如果所有内容都在一个名为“AI 更改”的巨大提交中，好运！所以我自律：完成任务，运行测试，提交。这也符合我之前关于将工作分解为小块的提示 - 每个块最终都变成了自己的提交或 PR。
最后，不要害怕使用分支或工作树来隔离 AI 实验。一个我采用了的高级工作流是为新功能或子项目创建一个新的 git 工作树。这允许我在同一个存储库上并行运行多个 AI 编码会话，而不会相互干扰，我稍后可以合并更改。就像每个 AI 任务都有自己的沙盒分支。如果一个实验失败，我会丢弃那个工作树，主分支不会受到任何损害。如果成功，我会将其合并。这种方法在我同时使用 AI 实现功能 A 和功能 B 时至关重要。版本控制使这种协调成为可能。在简短的总结中：提交频繁，使用分支组织工作，并接受 git 作为管理 AI 生成更改的控制机制。
自定义 AI 的行为，使用规则和示例
通过提供风格指南、示例，甚至“规则文件”来引导您的 AI 辅助工具 - 一点前期调整可以带来更好的输出。
我学到的一个事情是，您不必接受 AI 的默认样式或方法 - 您可以通过提供指南来显著影响它。例如，我有一个 CLAUDE.md 文件，我会定期更新，它包含 Anthropic 的模型应该遵循的过程规则和首选项（以及使用 Gemini CLI 时的 GEMINI.md）。这包括诸如“以我们的项目样式编写代码，遵循我们的 lint 规则，不使用某些函数，首选函数式样式而不是面向对象编程”等内容。当我启动一个会话时，我会将此文件提供给 Claude 以使其与我们的约定保持一致。令人惊讶的是，这样做可以多好地使模型保持“在轨道上”，正如 Jesse Vincent 注意到 的那样 - 它减少了 AI 偏离脚本或引入不需要的模式的趋势。
即使没有花哨的规则文件，您也可以使用自定义指令或系统提示来设置基调。GitHub Copilot 和 Cursor 都引入了功能，允许您为项目配置 AI 的行为 全局。我利用了这一点，通过编写一段关于我们编码风格的段落，例如“使用 4 个空格缩进，在 React 中避免箭头函数，首选描述性变量名称，代码应通过 ESLint”。有了这些指令，AI 的建议更符合人类同事的编写风格。Ben Congdon 提到 他有多么惊讶，很少有人使用 Copilot 的自定义指令，考虑到它们的有效性 - 通过提供一些示例和首选项，他可以指导 AI 输出符合其团队惯用的代码。我也同意这一点：花时间教 AI 了解您的期望。
另一种强大的技术是提供内联示例，以展示所需的输出格式或方法。如果我希望 AI 以非常特定的方式编写一个函数，我可能会先向它展示代码库中类似的函数：“这是我们如何实现 X 的示例，请使用类似的方法实现 Y”。如果我希望某种注释样式，我可能会自己编写一个注释，然后要求 AI 以相同的样式继续。基本上，我为模型提供要遵循的模式。LLM 擅长模仿 - 向它们展示一个或两个示例，它们就会继续以这种方式进行。
社区已经想出了创造性的“规则集”来驯服 LLM 的行为。你可能听说过 “大佬”规则 或在提示中添加“不幻想/不欺骗”条款。这些基本上是提醒 AI 要诚实，不要过度编造不存在的代码。例如，我有时会在提示前添加：“如果您对某些内容不确定或上下文信息不完整，请要求澄清，而不是编造答案”。这减少了幻想。另一个我使用的规则是：“在修复 bug 时，请在注释中简要解释您的推理”。这样，当 AI 生成修复时，它也会留下注释，如“// 已修复：将 X 更改为 Y 以防止 Z（如规格所述）”。这非常有用，适合稍后的审查。
总而言之，不要将 AI 视为黑盒 - 调整它。通过配置系统指令、共享项目文档或编写明确的规则，您可以将 AI 转变为更专门的开发人员，成为您的团队成员。就像为新员工提供风格指南和一些入门提示一样 - 为您的 AI 配对程序员做同样的事情。投资的回报是巨大的：您会得到需要较少调整并且更好地集成到代码库中的输出。
接受测试和自动化作为倍增器
使用您的 CI/CD、linters 和代码审查机器人 - AI 将在一个可以自动捕获错误的环境中发挥最佳作用。
这与保持在循环中和提供上下文有关的另一个相关方面是：具有良好开发流程的环境可以增强 AI 的生产力。我确保任何使用大量 AI 编码的存储库都有一个健全的持续集成设置。这意味着每次提交或 PR 都会自动运行测试，代码样式检查（如 ESLint、Prettier 等）会被执行，理想情况下，还会有一个用于任何新分支的暂存部署。为什么？因为我可以让 AI 触发这些，并评估结果。例如，如果 AI 通过像 Jules 或 GitHub Copilot Agent 这样的工具打开 PR，我们的 CI 会运行测试并报告故障。我可以将这些故障日志反馈给 AI：“集成测试失败，出现 XYZ，讓我们调试它”。这将调试转变为与 AI 的协作循环，反馈迅速，AI 可以处理这种情况。
自动代码质量检查（linters、类型检查器）也可以指导 AI。我实际上有时会在提示中包含 linter 输出。如果 AI 编写的代码不能通过我们的 linter，我会将 linter 错误复制到聊天中，并说“请解决这些问题”。然后，模型就知道该怎么做了。就像有一个严格的老师监督 AI 的工作一样。如果 AI 编写的代码没有通过我们的 linter，我会将 linter 错误复制到聊天中，并说“请解决这些问题”。然后，模型就知道该怎么做了。就像有一个严格的老师监督 AI 的工作一样。就像有一个严格的老师监督 AI 的工作一样。
AI 编码代理本身也越来越多地整合自动化挂钩。一些代理在所有测试通过之前不会说代码任务“完成”，这正是您想要的严谨性。代码审查机器人（AI 或其他类型）充当另一个过滤器 - 我将它们的反馈视为改进的额外提示。例如，如果 CodeRabbit 或其他审查者评论说“这个函数正在执行 X，这不是理想的”，我会要求 AI“根据此反馈重构”。通过将 AI 与自动化结合使用，您开始获得一个良性循环。AI 编写代码，自动化工具捕获问题，AI 修复它们，依此类推，您监督整个过程的高层方向。感觉就像有一个非常快的初级开发人员，他们的工作会被一个不知疲倦的 QA 工程师实时检查。但是，请记住，您 设置了这个环境。如果您的项目缺乏测试或任何自动化检查，AI 的工作可能会在一段时间后以微妙的 bug 或质量问题的形式悄悄地通过，直到后来才被发现。
所以，当我们进入 2026 年时，我的一个目标是加强围绕 AI 代码贡献的质量门槛：更多测试、更多监控，甚至可能是 AI 对 AI 的代码审查。听起来可能有些矛盾（AI 审查 AI），但我已经看到它可以捕捉到一个模型可能会错过的东西。总的来说，AI 友好型工作流程是具有强大自动化的工作流程 - 使用这些工具来让 AI 保持诚实。
持续学习和适应（AI 放大您的技能）
将每个 AI 编码会话视为学习机会 - 您知道的越多，AI 就能帮助您越多，形成一个良性循环。
使用 LLM 在开发中的一个最令人兴奋的方面是，我在此过程中学到了多少。与其取代我学习的需要，AI 实际上让我接触到了我可能不会自己尝试的新语言、框架和技术。
这种模式通常成立：如果你带着扎实的软件工程基础知识来到这里，AI 将放大你的生产力。然而，如果你缺乏这种基础，AI 可能只会放大混乱。经验丰富的开发人员观察到，LLM“奖励现有的最佳实践”- 写清晰的规范、编写测试、进行代码审查等，所有这些在使用 AI 时变得更加强大。在我的经验中，AI 允许我在更高的抽象层次上运作（专注于设计、接口、架构），同时它处理样板代码，但我需要首先具备这些高层次的技能。正如 Simon Willison 所说，几乎所有使某人成为高级工程师的事情（设计系统、管理复杂性、知道什么应该自动化，什么应该手动编码）都是与 AI 合作时能带来最佳结果的因素。因此，使用 AI 已经实际上提高了我的工程水平 - 我在规划和架构方面更加严谨，因为我有效地“管理”一个非常快但有点天真的程序员（AI）。
对于那些担心过度依赖 AI 会削弱他们技能的人，我会说，情况恰恰相反，如果做得正确。通过审查 AI 代码，我接触到了新的惯用语和解决方案。通过调试 AI 错误，我加深了对语言和问题领域的理解。我经常要求 AI 解释其代码或修复背后的推理 - 就像不断地向候选人提问代码一样 - 并从其答案中获得见解。我还将 AI 用作研究助手：如果我不确定某个库或方法，我会要求它列出选项或比较权衡。就像有一个百科全书式的导师随时可供咨询。所有这些都让我成为一个更有知识的程序员。
更广泛地说，AI 工具放大了您的专业知识。进入 2026 年，我并不害怕它们“抢走我的工作” - 我很兴奋它们让我摆脱了繁琐的工作，并让我能够在软件工程的创造性和复杂方面花费更多时间。但我也意识到，对于那些没有坚实基础的人来说，AI 可能会导致“杜林-克鲁格效应”（Dunning-Kruger effect）- 它可能看起来像你构建了某些东西，但直到后来才会崩溃。所以，我的建议是：继续磨练你的技艺，并利用 AI 来加速这个过程。要有意识地定期编码，而不使用 AI，以保持你的原始技能敏锐。在最终分析中，开发人员 + AI 的组合比单独的任何一个都更强大，而开发人员这一半必须坚持自己的责任。
结论
我已经完全接受了 AI 在我的开发工作流程中 - 但以一种经过深思熟虑的、由专家驱动的方式。我的方法基本上是**“AI 增强的软件工程”**，而不是 AI 自动化的软件工程。
我学到了：将经典的软件工程学科应用于与 AI 的合作可以带来最好的结果。事实证明，我们辛苦获得的所有实践 - 设计然后编码，编写测试，使用版本控制，保持标准 - 不仅仍然适用，而且在 AI 编写一半代码时更加重要。
我很期待接下来会发生什么。工具会不断改进，我的工作流程也会随着它们的演进而演进。也许完全自治的“AI 开发实习生”会处理更多的繁琐工作，而我们专注于更高层次的任务。也许新的调试和代码探索范式会出现。不管怎样，我计划保持在循环中 - 引导 AI，向它们学习，并以负责任的方式放大我的生产力。
最终，我的底线是：AI 编码助手是不可思议的倍增器，但人类工程师仍然是这场表演的导演。