最佳实践：在使用AI编码时保持控制

AI编码助手在今年成为了游戏规则的改变者，但有效利用它们需要技巧和结构。 这些工具极大地提升了LLM在现实世界编码中的能力，许多开发者（包括我自己）都接受了它们。

例如，在Anthropic，工程师们大量采用Claude Code，以至于今天约90%的Claude Code代码是由Claude Code自己编写的。然而，使用LLM进行编程并不是一键式的魔法体验——它是"困难且不直观的"，要获得出色的结果需要学习新的模式。批判性思维仍然至关重要。经过一年多的项目实践，我已经形成了一种工作流程，这与许多经验丰富的开发者正在发现的方法类似：将LLM视为一个强大的结对编程伙伴，需要清晰的指导、上下文和监督，而不是自主判断。

在这篇文章中，我将分享我在2026年如何规划、编码和与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仓库导入其上下文，像Cursor或Copilot这样的IDE助手会自动在提示中包含打开的文件。但我经常更进一步——我会使用像Context7这样的MCP，或者如果怀疑模型没有这些信息，我会手动将代码库或API文档的重要部分复制到对话中。

专家LLM用户强调这个"上下文打包"步骤。例如，在编码之前进行"大脑转储"，包括模型应该知道的一切：高级目标和不变性、良好解决方案的示例，以及关于要避免的方法的警告。如果我要求AI实现一个棘手的解决方案，我可能会告诉它哪些简单解决方案太慢，或者提供来自其他地方参考实现。如果我使用小众库或全新的API，我会粘贴官方文档或README，这样AI就不会盲目飞行。所有这些前期上下文都显著提高了其输出的质量，因为模型不是在猜测——它面前有事实和约束。

现在有一些实用工具可以自动化上下文打包。我尝试过像gitingest或repo2txt这样的工具，它们基本上将代码库的相关部分"转储"到文本文件中供LLM读取。在处理大型项目时，这些工具可能是救星——你生成一个包含关键源文件的output.txt包，让模型消化它。原则是：不要让AI在部分信息上操作。如果bug修复需要理解四个不同的模块，向它展示这四个模块。是的，我们必须注意token限制，但当前的前沿模型有相当大的上下文窗口（数万个token）。明智地使用它们。我经常选择性地只包含与手头任务相关的代码部分，并明确告诉AI如果某些内容超出范围，不要关注什么（以节省token）。

我认为Claude Skills有潜力，因为它们将过去脆弱的重复提示转变为持久和可重用的东西，通过将指令、脚本和领域特定专业知识打包到模块化能力中，当请求匹配技能时，工具可以自动应用。这意味着你获得比通用提示更可靠和上下文感知的结果，并且你从一次性交互转向编码可重复程序和团队知识的流程，以一致的方式处理任务。存在一些社区策划的技能集合，但我最喜欢的例子之一是前端设计技能，它可以"结束"LLM生成的UI中普遍存在的紫色设计美学。在更多工具正式支持技能之前，存在变通方法。

最后，在提示内部用注释和规则指导AI。我可能在代码片段之前加上："这是X的当前实现。我们需要扩展它以执行Y，但要注意不要破坏Z。"这些小提示大有帮助...

拥抱测试和自动化作为力量倍增器

使用你的CI/CD、linter和代码审查机器人——AI在能够自动捕获错误的环境中工作得最好。

这是保持在循环中并提供上下文的必然结果：一个运行良好的开发管道增强了AI的生产力。我确保任何我大量使用AI编码的仓库都有强大的持续集成设置。这意味着每次提交或PR都会运行自动化测试，强制执行代码风格检查（如ESLint、Prettier等），理想情况下，任何新分支都有可用的暂存部署。为什么？因为我可以让AI触发这些并评估结果。例如，如果AI通过像Jules或GitHub Copilot Agent这样的工具打开拉取请求，我们的CI将运行测试并报告失败。我可以将这些失败日志反馈给AI："集成测试因XYZ失败，让我们调试这个。"它将bug修复转变为具有快速反馈的协作循环，AI处理得相当好（它们会建议修复，我们再次运行CI，并迭代）。

自动化代码质量检查（linter、类型检查器）也指导AI。我实际上有时会在提示中包含linter输出。如果AI编写的代码没有通过我们的linter，我会将linter错误复制到聊天中并说"请解决这些问题。"然后模型确切知道该做什么。这就像有一个严格的老师在监督AI。根据我的经验，一旦AI意识到工具的输出（如失败的测试或lint警告），它会非常努力地纠正它——毕竟，它"想要"产生正确的答案。这回到了提供上下文：给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将放大你的生产力数倍。如果你缺乏这个基础，AI可能只会放大困惑。经验丰富的开发者观察到LLM"奖励现有的最佳实践"——像编写清晰的规范、拥有良好的测试、进行代码审查等事情，当涉及AI时都变得更有力量。根据我的经验，AI让我在更高的抽象级别上操作（专注于设计、接口、架构），而它处理样板代码，但我需要首先拥有这些高级技能。正如Simon Willison指出的，几乎使某人成为高级工程师的一切（设计系统、管理复杂性、知道自动化什么与手写代码）现在在使用AI时产生最佳结果。所以使用AI实际上推动我提升我的工程水平——我对规划更加严格，对架构更加有意识，因为我有效地"管理"一个非常快但有点天真的编码者（AI）。

对于那些担心使用AI可能会降低他们能力的人：如果做得对，我会争辩说相反。通过审查AI代码，我接触到了新的习语和解决方案。通过调试AI错误，我加深了对语言和问题领域的理解。我经常要求AI解释其代码或修复背后的理由——有点像不断面试候选人关于他们的代码——我从它的答案中获得了见解。我还将AI用作研究助手：如果我不确定库或方法，我会要求它列举选项或比较权衡。这就像有一个百科全书式的导师随时待命。所有这些都使我成为一个更有知识的程序员。

大局是AI工具放大你的专业知识。进入2026年，我不害怕它们"抢走我的工作"——我很兴奋它们让我从苦差事中解脱出来，让我能够花更多时间在软件工程的创造性和复杂方面。但我也意识到，对于那些没有坚实基础的人来说，AI可能导致邓宁-克鲁格效应（它可能看起来像你构建了很棒的东西，直到它崩溃）。所以我的建议：继续磨练你的技能，并使用AI加速这个过程。有意识地定期在没有AI的情况下编码，以保持你的原始技能敏锐。最终，开发者+AI二人组比单独任何一个都强大得多，而该二人组的开发者一半必须承担他们的责任。

结论

当我们进入2026年时，我已经完全接受了AI在我的开发工作流程中——但以一种深思熟虑的、专家驱动的方式。我的方法本质上是"AI增强软件工程"而不是AI自动化软件工程。

我学到了：当你将经典的软件工程规范应用到你的AI协作时，会产生最佳结果。事实证明，我们所有来之不易的实践——编码前设计、编写测试、使用版本控制、维护标准——不仅仍然适用，而且当AI编写你一半代码时变得更加重要。

我对未来感到兴奋。工具不断改进，我的工作流程肯定会与它们一起发展。也许完全自主的"AI开发实习生"将处理更多苦差事，而我们专注于更高级的任务。也许新的调试和代码探索范式将出现。无论如何，我计划保持在循环中——指导AI，向它们学习，并负责任地放大我的生产力。

对我来说的底线：AI编码助手是令人难以置信的力量倍增器，但人类工程师仍然是演出的导演。

那么...2026年快乐构建！🚀

---

原文来源: https://addyo.substack.com/p/my-llm-coding-workflow-going-into