我在2026年的LLM编码工作流
作者：Addy Osmani
原文：查看原文
摘要
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 都知道“要做什么”以及“为什么这么做”。简单说，先规划的意义，就是先把共识建立起来，避免把时间浪费在错误方向上。这一步很多人容易跳过，但对有经验的 LLM 使用者来说，扎实的规格说明和计划，已经是整个工作流的基石。
将工作分解为小的、迭代的块
范围管理至关重要——给 LLM 可管理的任务，而不是一股脑把整个代码库都扔过去。
我学到的一个关键教训，是不要指望 AI 一次吐出一个庞大而完整的答案。更好的做法，是把项目拆成一轮一轮的小任务，逐个推进。这本来就是好的软件工程实践，而在 AI 参与之后，只会变得更重要。LLM 在任务足够聚焦时表现最好：一次实现一个函数、修一个 bug、补一个功能。比如完成规划后，我会继续提示：“好，我们先实现计划里的第 1 步。” 写完、测完，再进入第 2 步。每一块都要小到 AI 能吃透上下文，你自己也能清楚审查它产出的代码。
这种方法可以防止模型偏离轨道。如果你一次要求太多，它很可能会感到困惑或产生一个**"混乱的烂摊子"，难以解开。开发者报告说，当他们试图让LLM生成应用的大量代码时，最终得到的是不一致和重复——"就像10个开发者在没有相互交流的情况下工作"，有人说。我感受过那种痛苦；解决方法是停下来，后退，将问题分解为更小的部分**。每次迭代，我们都会继承已构建内容的上下文，并逐步添加到其中。这也很好地契合了**测试驱动开发（TDD）**方法——我们可以在进行过程中为每个部分编写或生成测试（稍后会详细介绍测试）。
一些Coding Agents 工具现在明确支持这种分块工作流程。例如，我经常生成一个结构化的**"提示计划"文件，其中包含每个任务的一系列提示，以便像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帮助来增强你的工作流程。
在命令行里，也出现了一批新的 Coding Agents。Claude Code、OpenAI 的 Codex CLI和Google 的 Gemini CLI都属于这类 CLI 工具：你可以直接在项目目录中与它们对话，它们能读文件、跑测试，甚至完成多步骤修复。我也用过 Google 的 Jules 和 GitHub 的 Copilot Agent——它们属于异步 Coding Agents，会把仓库克隆到云端 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擅长的只要测试存在。毫不奇怪，那些从 Coding Agents 中获得最大收益的人往往是那些具有强大测试实践的人。像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 更改”的超大提交里，排查起来就会很痛苦。所以我会强迫自己遵守一个简单节奏：完成任务，运行测试，提交。 这也和前面“把工作拆小”的原则天然一致——每个小块最终都应该落成自己的提交或 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 的输出更贴近项目约束和团队习惯。这样做的回报很高：生成结果更稳定，后续调整更少，也更容易和现有代码库自然衔接。
拥抱测试和自动化作为力量倍增器
使用你的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 Coding Agents 现在越来越多地整合自动化钩子。一些代理会拒绝说代码任务"完成"，直到所有测试通过，这正是你想要的勤奋。代码审查机器人（AI 或其他）充当另一个过滤器——我将它们的反馈视为改进的额外提示。例如，如果 CodeRabbit或另一个审查者评论"这个函数正在做X，这不理想"，我会问AI，"你能根据这个反馈重构吗？"
通过将AI与自动化相结合，你开始获得一个良性循环。AI编写代码，自动化工具捕获问题，AI修复它们，依此类推，你监督高级方向。感觉就像有一个极快的初级开发者，其工作立即由一个不知疲倦的QA工程师检查。但请记住，你设置了那个环境。如果你的项目缺乏测试或任何自动化检查，AI的工作可能会在很久以后才出现细微的bug或质量差的问题。
所以在进入2026年时，我的目标之一是加强围绕AI代码贡献的质量门：更多测试、更多监控，甚至可能是AI对AI的代码审查。这可能听起来矛盾（AI审查AI），但我见过它捕获一个模型遗漏的东西。底线：AI友好的工作流程是具有强大自动化的工作流程——使用这些工具来保持AI的诚实。
持续学习和适应（AI放大你的技能）
将每个AI编码会话视为学习机会——你知道的越多，AI就越能帮助你，创造一个良性循环。
用 LLM 做开发，最让我兴奋的一点，是我自己也在这个过程中学得更快。AI 不是替代我原本该懂的东西，反而不断把我带到原本未必会主动尝试的新语言、新框架和新技术上。
这套逻辑其实很普遍：如果你本来就有扎实的软件工程基础，AI 往往会把你的生产力成倍放大；如果基础不稳，它放大的也可能只是混乱。很多有经验的开发者都观察到，LLM 会“奖励已有的最佳实践”——比如写清晰的规格说明、补齐测试、认真做代码审查；AI 一旦加入，这些好习惯只会更重要。就我的经验来看，AI 让我更多站在高抽象层工作：我把精力放在设计、接口和架构上，把一些样板实现交给模型。但前提仍然是：这些高层能力你得先有。Simon Willison 提过一个很准的观察：几乎所有让人成为高级工程师的能力——设计系统、管理复杂性、判断什么该自动化、什么该手写——现在也正是和 AI 协作时最值钱的能力。所以对我来说，AI 反而逼着我把工程基本功练得更扎实：规划更严格，架构意识更强，因为我其实是在“管理”一个速度极快、但仍需要引导的编码搭档。
如果你担心 AI 会让人变钝，我的看法恰好相反：前提是你用得对。审查 AI 写出来的代码，会逼你接触新的写法和解法；调试 AI 引入的问题，也会反过来加深你对语言和业务域的理解。我经常让 AI 解释它为什么这么写、为什么这么修，这有点像你不断追问候选人“请解释一下你的代码思路”，而我经常能从这些回答里学到东西。我也会把 AI 当作研究助手：如果我不确定某个库或某种做法，就让它列选项、比权衡。某种意义上，这像是有个随叫随到的百科型导师。所有这些，都会把我推成一个知识面更广、判断力更强的程序员。
更大的结论是：AI 工具放大的，其实是你的专业能力。 到了 2026 年，我并不担心它们“抢走工作”；更让我兴奋的是，它们把我从大量苦活里解放出来，让我能把时间投入到软件工程里更有创造性、也更复杂的部分。当然，我也很清楚：如果一个人没有扎实基础，AI 也可能制造出一种放大版的邓宁—克鲁格幻觉——你会觉得自己好像做出了很厉害的东西，直到系统真的开始出问题。所以我的建议是：继续打磨你的手艺，同时用 AI 去加速这个过程。也要有意识地保留一部分“不靠 AI 写代码”的练习，让基本功保持锋利。最终，开发者 + AI 的组合，远强于两者单独作战；但这个组合里，“开发者”那一端必须站得住。
结论
我已经完全接受 AI 进入我的开发工作流，但前提是：它必须处在一个经过认真设计、由人主导的框架里。我的方法，本质上更接近 “AI 增强的软件工程”，而不是“AI 全自动替代的软件工程”。
我最大的体会是：当你把经典的软件工程纪律带进 AI 协作，结果反而会最好。 那些我们花很多年才养成的习惯——先设计再编码、补测试、用好版本控制、坚持工程标准——不但没有过时，反而在 AI 开始写掉你一大半代码时变得更重要了。
我对接下来的事情很兴奋。工具还在持续进化，我的工作流也一定会继续调整。未来也许会有更高自治度的 AI 系统接手更多繁重实现，而我们把更多精力放在设计、判断和集成上；也可能会出现全新的调试与代码探索范式。无论如何，我都打算继续深度参与——引导 AI、向它学习，并以负责任的方式放大自己的生产力。
对我来说的底线是：AI编码助手是令人难以置信的力量倍增器，但人类工程师仍然是节目的导演。
我很高兴地分享我与O'Reilly发布了一本新的AI辅助工程书籍。如果感兴趣，书籍网站上有许多免费提示。