我在2026年的LLM编码工作流
摘要
AI编码助手在2025年成为游戏规则改变者，但有效利用它们需要技巧和结构。以下是我在规划、编码和协作中的工作流程...
AI编码助手在2025年成为游戏规则改变者，但有效利用它们需要技巧和结构。 这些工具极大地提升了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仓库导入其上下文，而像Cursor或Copilot这样的IDE助手会自动将打开的文件包含在提示中。但我经常更进一步——我会使用像Context7这样的MCP，或者如果我怀疑模型没有它们，我会手动将代码库或API文档的重要部分复制到对话中。
LLM专家用户强调这个"上下文打包"步骤。例如，在编码之前进行**"大脑转储"**，包括模型应该知道的所有内容：高级目标和不变量、良好解决方案的示例，以及关于要避免的方法的警告。如果我要求AI实现一个棘手的解决方案，我可能会告诉它哪些简单的解决方案太慢，或者提供来自其他地方的参考实现。如果我使用的是小众库或全新的API，我会粘贴官方文档或README，这样AI就不会盲目飞行。所有这些前期上下文都会显著提高其输出质量，因为模型不是在猜测——它面前有事实和约束。
现在有一些实用工具可以自动化上下文打包。我尝试过像gitingest或repo2txt这样的工具，它们本质上**"将代码库的相关部分转储到文本文件中供LLM阅读"。在处理大型项目时，这些工具可以成为救星——你生成一个包含关键源文件的output.txt包，让模型摄取它。原则是：不要让AI在部分信息上操作**。如果bug修复需要理解四个不同的模块，就向它展示这四个模块。是的，我们必须注意token限制，但当前的前沿模型有相当大的上下文窗口（数万个token）。明智地使用它们。我经常有选择地只包含与手头任务相关的代码部分，并明确告诉AI如果某些内容超出范围，不要关注什么（以节省token）。
我认为Claude Skills很有潜力，因为它们将过去脆弱的重复提示转变为持久且可重用的东西，通过将指令、脚本和领域特定专业知识打包成模块化能力，工具可以在请求匹配Skill时自动应用。这意味着你可以获得比通用提示更可靠和上下文感知的结果，并且你从一次性交互转向以一致的方式编码可重复程序和团队知识的工作流程。存在许多社区策划的Skills集合，但我最喜欢的例子之一是frontend-design skill，它可以"终结"LLM生成UI中普遍存在的紫色设计美学。在更多工具正式支持Skills之前，存在变通方法。
最后**，在提示中用注释和规则引导AI**。我可能会在代码片段前加上："这是X的当前实现。我们需要扩展它以执行Y，但要小心不要破坏Z。"这些小提示大有帮助。LLM是字面主义者——它们会遵循指令，所以给它们详细的、上下文化的指令。通过主动提供上下文和指导，我们最大限度地减少幻觉和偏离基础的建议，并获得符合我们项目需求的代码。
选择正确的模型（并在需要时使用多个）
并非所有编码LLM都是平等的——有意识地选择你的工具，不要害怕中途切换模型。
在2025年，我们被各种强大的以代码为重点的LLM宠坏了。我工作流程的一部分是选择最适合每个任务的模型或服务。有时，甚至可以并行尝试两个或更多LLM，以交叉检查它们如何以不同方式处理同一问题。
每个模型都有自己的"个性"。关键是**：如果一个模型卡住或给出平庸的输出，尝试另一个。** 我实际上会将同一个提示从一个聊天复制到另一个服务，看看它是否能更好地处理。这种"模型音乐椅"可以在你遇到模型盲点时拯救你。
此外，确保你使用的是最佳版本。如果可以，使用最新的"专业"层级模型——因为质量很重要。是的，这通常意味着付费访问，但生产力的提升可以证明其合理性。最终，选择与你**"氛围"契合**的AI结对编程伙伴。我知道有些人更喜欢某个模型，仅仅因为他们喜欢其响应的感觉。这是有效的——当你本质上与AI进行持续对话时，用户体验和语气会产生影响。
就我个人而言，我现在倾向于使用Gemini进行大量编码工作，因为交互感觉更自然，它通常在第一次尝试时就能理解我的请求。但如果需要，我会毫不犹豫地切换到另一个模型；有时第二个意见有助于解决方案的出现。总之：使用最适合工作的工具，并记住你有一整套AI可供使用。
在整个生命周期中利用AI编码
通过在SDLC中使用特定于编码的AI帮助来增强你的工作流程。
在命令行上，出现了新的AI代理。Claude Code、OpenAI的Codex CLI和Google的Gemini CLI是CLI工具，你可以直接在项目目录中与它们聊天——它们可以读取文件、运行测试，甚至多步骤修复问题。我也使用过Google的Jules和GitHub的Copilot Agent——这些是异步编码代理，实际上将你的仓库克隆到云VM中，并在后台处理任务（编写测试、修复bug，然后为你打开PR）。见证这一点有点诡异：你发出一个命令，比如"重构支付模块以实现X"，过一会儿你就会收到一个包含代码更改和通过测试的拉取请求。我们真的生活在未来。你可以在从指挥者到编排者中阅读更多相关内容。
也就是说**，这些工具并非万无一失，你必须了解它们的局限性**。它们加速了编码的机械部分——生成样板代码、应用重复更改、自动运行测试——但它们仍然极大地受益于你的指导。例如，当我使用像Claude或Copilot这样的代理来实现某些东西时，我经常向它提供早期步骤的计划或待办事项列表，以便它知道确切的任务序列。如果代理支持，我会在告诉它执行之前将我的spec.md或plan.md加载到上下文中。这使它保持在正轨上。
我们还没有到让AI代理无人看管地编写整个功能并期望完美结果的阶段。相反，我以监督的方式使用这些工具：我会让它们生成甚至运行代码，但我会密切关注每一步，准备在某些东西看起来不对劲时介入。还有像Conductor这样的编排工具，可以让你在不同任务上并行运行多个代理（本质上是一种扩展AI帮助的方式）——一些工程师正在尝试同时在不同功能上运行3-4个代理。我尝试过这种"大规模并行"方法；它在快速完成大量工作方面出奇地有效，但监控多个AI线程在精神上也很累！对于大多数情况，我坚持一次使用一个主要代理，也许还有一个次要代理用于审查（稍后讨论）。
只要记住这些是电动工具——你仍然控制扳机并引导结果。
保持人类参与——验证、测试和审查一切
AI会愉快地生成看似合理的代码，但你对质量负责——始终彻底审查和测试。 我的一个基本原则是永远不要盲目信任LLM的输出。正如Simon Willison恰当地所说，将LLM结对编程伙伴视为**"过度自信且容易犯错"。它以完全的信念编写代码——包括bug或无意义的内容——除非你发现问题，否则不会告诉你有什么问题。所以我将每个AI生成的代码片段视为来自初级开发者：我通读代码，运行它，并根据需要进行测试。你绝对必须测试它写的东西**——运行那些单元测试，或手动执行功能，以确保它做了它声称的事情。在vibe编码不是低质量工作的借口中阅读更多相关内容。
事实上，我将测试融入工作流程本身。我早期的规划阶段通常包括为每个步骤生成测试列表或测试计划。如果我使用像Claude Code这样的工具，我会指示它在实现任务后运行测试套件，并让它在出现任何失败时进行调试。这种紧密的反馈循环（编写代码→运行测试→修复）是AI擅长的只要测试存在。毫不奇怪，那些从编码代理中获得最大收益的人往往是那些具有强大测试实践的人。像Claude这样的代理可以在良好的测试套件作为安全网的情况下"飞速"完成项目。没有测试，代理可能会轻率地假设一切都很好（"当然，一切都好！"），而实际上它破坏了几件事。所以，投资于测试——它放大了AI的有用性和对结果的信心。
即使超越自动化测试**，也要进行代码审查——手动和AI辅助的**。我经常暂停并逐行审查到目前为止生成的代码。有时我会启动第二个AI会话（或不同的模型）并要求它批评或审查第一个产生的代码。例如，我可能让Claude编写代码，然后问Gemini，"你能审查这个函数是否有任何错误或改进吗？"这可以捕获细微的问题。关键是不要仅仅因为AI编写了代码就跳过审查。如果有的话，AI编写的代码需要额外的审查，因为它有时可能表面上令人信服，同时隐藏着人类可能不会立即注意到的缺陷。
我还使用Chrome DevTools MCP（由我上一个团队构建）进行调试和质量循环，以弥合静态代码分析和实时浏览器执行之间的差距。它"给你的代理眼睛"。它让我授予我的AI工具直接访问权限，以查看浏览器可以看到的内容，检查DOM，获取丰富的性能跟踪、控制台日志或网络跟踪。这种集成消除了手动上下文切换的摩擦，允许直接通过LLM进行自动化UI测试。这意味着可以根据实际运行时数据以高精度诊断和修复bug。
跳过人类监督的可怕后果已有记录。一位在赶工项目中严重依赖AI生成的开发者描述结果是一个不一致的烂摊子——重复的逻辑、不匹配的方法名称、没有连贯的架构。他意识到自己一直在"构建、构建、构建"，而没有退后一步真正看到AI编织在一起的东西。修复是一次痛苦的重构，并发誓再也不让事情失控到那种程度。我把这一点铭记于心**。无论我使用多少AI，我仍然是负责任的工程师**。
在实际操作中，这意味着我只在理解代码后才合并或发布代码。如果AI生成了一些复杂的东西，我会要求它添加注释来解释它，或者我会用更简单的术语重写它。如果某些东西感觉不对，我会深入研究——就像我对引发危险信号的人类同事贡献的代码所做的那样。
这一切都关乎心态**：LLM是助手，而不是自主可靠的编码者**。我是高级开发者；LLM在那里加速我，而不是取代我的判断。保持这种立场不仅会产生更好的代码，还会保护你作为开发者的成长。（我听到一些人担心过度依赖AI可能会削弱他们的技能——我认为只要你保持参与，积极审查和理解一切，你仍然在磨练你的直觉，只是速度更快。）简而言之**：保持警觉，经常测试，始终审查。** 归根结底，这仍然是你的代码库。
经常提交并使用版本控制作为安全网。永远不要提交你无法解释的代码。
频繁提交是你的保存点——它们让你撤销AI的失误并理解更改。
当与可以快速生成大量代码的AI一起工作时，事情很容易偏离轨道。我通过采用超细粒度的版本控制习惯来缓解这一点。我提交得早且频繁，甚至比我在正常手工编码中更频繁。在每个小任务或每次成功的自动编辑之后，我会用清晰的消息进行git提交。这样，如果AI的下一个建议引入了bug或混乱的更改，我有一个最近的检查点可以恢复（或从中挑选），而不会丢失数小时的工作。一位实践者将其比作将提交视为**"游戏中的保存点"**——如果LLM会话出错，你总是可以回滚到最后一个稳定的提交。我发现这个建议非常有用。当你知道如果需要可以用git reset撤销它时，尝试大胆的AI重构会减少很多压力。
适当的版本控制也有助于与AI协作。由于我不能依赖AI记住它所做的一切（上下文窗口限制等），git历史成为一个有价值的日志。我经常扫描我最近的提交，向AI（或我自己）简要介绍发生了什么变化。事实上，如果你提供，LLM本身可以利用你的提交历史——我已经将git diff或提交日志粘贴到提示中，以便AI知道哪些代码是新的或之前的状态是什么。有趣的是，LLM在解析diff和使用像git bisect这样的工具来找到引入bug的位置方面真的很擅长。它们有无限的耐心来遍历提交历史，这可以增强你的调试。但这只有在你首先有一个整洁的提交历史时才有效。
另一个好处：带有良好消息的小提交本质上记录了开发过程，这有助于进行代码审查（AI或人类）。如果AI代理一次性进行了五次更改并且某些东西坏了，将这些更改放在单独的提交中可以更容易地确定哪个提交导致了问题。如果所有内容都在一个标题为"AI更改"的巨大提交中，祝你好运！所以我约束自己：完成任务，运行测试，提交。 这也与早期关于将工作分解为小块的提示很好地契合——每个块最终都成为自己的提交或PR。
最后，不要害怕使用分支或工作树来隔离AI实验。我采用的一个高级工作流程（受Jesse Vincent等人的启发）是为新功能或子项目启动一个新的git工作树。这让我可以在同一个仓库上并行运行多个AI编码会话而不会相互干扰，我可以稍后合并更改。这有点像在自己的沙盒分支中进行每个AI任务。如果一个实验失败，我扔掉那个工作树，主分支中什么也不会丢失。如果成功，我将其合并进来。当我让AI实现功能A，同时我（或另一个AI）同时处理功能B时，这种方法至关重要。版本控制使这种协调成为可能。简而言之**：经常提交，用分支组织你的工作，并拥抱git**作为控制机制，使AI生成的更改可管理且可逆。
通过规则和示例自定义AI的行为
通过提供风格指南、示例，甚至"规则文件"来引导你的AI助手——一点前期调整会产生更好的输出。
我学到的一件事是，你不必接受AI的默认风格或方法——你可以通过给它指导方针来大力影响它。例如，我有一个CLAUDE.md文件，我会定期更新，其中包含Claude（Anthropic的模型）要遵循的流程规则和偏好（类似地，在使用Gemini CLI时有一个GEMINI.md）。这包括诸如"以我们项目的风格编写代码，遵循我们的lint规则，不要使用某些函数，更喜欢函数式风格而不是OOP"等内容。当我开始一个会话时，我将这个文件提供给Claude以使其与我们的约定保持一致。正如Jesse Vincent 指出的那样，这种方法效果惊人——它减少了AI偏离脚本或引入我们不想要的模式的趋势。
即使没有花哨的规则文件，你也可以通过自定义指令或系统提示设置基调。GitHub Copilot和Cursor都引入了功能，让你全局配置AI对你项目的行为。我利用了这一点，写了一小段关于我们编码风格的段落，例如"使用4个空格缩进，避免在React中使用箭头函数，更喜欢描述性变量名，代码应该通过ESLint。"有了这些指令，AI的建议更加贴近人类队友可能编写的内容。Ben Congdon 提到他对很少有人使用Copilot的自定义指令感到震惊，考虑到它们是多么有效——他可以通过预先提供一些示例和偏好来引导AI输出与他团队的习惯用法相匹配的代码。我赞同这一点：花时间教AI你的期望。
另一个强大的技术是提供你想要的输出格式或方法的内联示例。如果我想让AI以非常特定的方式编写函数，我可能首先向它展示代码库中已有的类似函数："这是我们如何实现X的，对Y使用类似的方法。"如果我想要某种注释风格，我可能会自己写一个注释，并要求AI以该风格继续。本质上，用要遵循的模式启动模型。LLM擅长模仿——向它们展示一两个示例，它们会以那种方式继续。
社区还提出了创造性的"规则集"来驯服LLM行为。你可能听说过"Big Daddy"规则或在提示中添加"无幻觉/无欺骗"条款。这些基本上是提醒AI要真实，不要过度编造不存在的代码的技巧。例如，我有时会在提示前加上："如果你对某事不确定或缺少代码库上下文，请要求澄清而不是编造答案。"这减少了幻觉。我使用的另一个规则是："在修复bug时，始终在注释中简要解释你的推理。"这样，当AI生成修复时，它还会留下一个注释，如"// 修复：将X更改为Y以防止Z（根据规格说明）。"这对以后的审查非常有用。
总之，不要将AI视为黑盒——调整它。通过配置系统指令、共享项目文档或写下明确的规则，你将AI转变为团队中更专业的开发者。这类似于入职新员工：你会给他们风格指南和一些入门提示，对吧？对你的AI结对编程伙伴做同样的事情。投资回报是巨大的：你得到的输出需要更少的调整，并且更顺畅地与你的代码库集成。
拥抱测试和自动化作为力量倍增器
使用你的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可能只会放大混乱。经验丰富的开发者观察到LLM"奖励现有的最佳实践"——诸如编写清晰的规格说明、拥有良好的测试、进行代码审查等，当AI参与时，所有这些都变得更加强大。根据我的经验，AI让我在更高的抽象层次上操作（专注于设计、接口、架构），而它处理样板代码，但我需要首先拥有那些高级技能。正如Simon Willison指出的，几乎所有使某人成为高级工程师的东西（设计系统、管理复杂性、知道什么要自动化vs手工编码）现在都是与AI产生最佳结果的东西。所以使用AI实际上推动我提升我的工程水平——我对规划更加严格，对架构更加有意识，因为我实际上在"管理"一个非常快但有点天真的编码者（AI）。
对于那些担心使用AI可能会降低他们能力的人：我认为如果做得对，恰恰相反。通过审查AI代码，我接触到了新的习惯用法和解决方案。通过调试AI错误，我加深了对语言和问题领域的理解。我经常要求AI解释其代码或修复背后的理由——有点像不断面试候选人关于他们的代码——我从它的答案中获得见解。我还使用AI作为研究助手：如果我不确定库或方法，我会要求它列举选项或比较权衡。这就像有一个百科全书式的导师随叫随到。所有这些都使我成为一个更有知识的程序员。
大局是AI工具放大你的专业知识。进入2026年，我不害怕它们"抢走我的工作"——我很兴奋它们让我从苦差事中解放出来，让我能够花更多时间在软件工程的创造性和复杂方面。但我也意识到，对于那些没有坚实基础的人来说，AI可能导致类固醇上的邓宁-克鲁格效应（它可能看起来像你构建了一些伟大的东西，直到它崩溃）。所以我的建议是：继续磨练你的技艺，并使用AI来加速这个过程。有意识地定期在没有AI的情况下编码，以保持你的原始技能敏锐。最终，开发者+AI组合比单独任何一个都强大得多，而那个组合的开发者部分必须坚守自己的一端。
结论
我已经完全接受了AI在我的开发工作流程中——但以一种经过深思熟虑的、专家驱动的方式。我的方法本质上是**"AI增强的软件工程"**而不是AI自动化的软件工程。
我学到了**：当你将经典的软件工程纪律应用于你的AI协作时，会产生最佳结果**。事实证明，我们所有来之不易的实践——在编码之前设计、编写测试、使用版本控制、维护标准——不仅仍然适用，而且当AI编写你一半的代码时更加重要。
我对接下来的事情感到兴奋。工具不断改进，我的工作流程肯定会随之发展。也许完全自主的"AI开发实习生"将处理更多的繁重工作，而我们专注于更高级别的任务。也许会出现新的调试和代码探索范式。无论如何，我计划保持参与——引导AI，向它们学习，并负责任地放大我的生产力。
对我来说的底线是：AI编码助手是令人难以置信的力量倍增器，但人类工程师仍然是节目的导演。
我很高兴地分享我与O'Reilly发布了一本新的AI辅助工程书籍。如果感兴趣，书籍网站上有许多免费提示。