这篇回答的问题是：进入 2026 年，一个资深工程师与 LLM 协作编程的完整工作流长什么样。

最值得拿走的是三条骨架：spec 先行（一次「15 分钟瀑布」把需求、架构、测试策略谈透再动手）；小步提交（每个小块一个提交，提交即存档点，随时可回退）；人工把关（把 AI 产出当初级开发的代码逐行评审、跑测、理解后才合并）。最易误用的是大规模并行多 Agent：看似高效，盯多条 AI 线程的注意力成本常被低估，作者自己日常也只用「一主一评」配置。

相比工具评测类内容，这篇的价值在「纪律」二字：经典工程实践在 AI 时代不是失效而是加倍重要，AI 奖励的是既有最佳实践。中文读者可叠加国内语境——不少团队的 CI、staging、lint 闸门尚不健全，先补自动化地板，AI 才有安全网可借力。

本周挑一个小需求，完整走一遍 spec.md→分步计划→逐步实现→逐条提交的流程，亲自体会它与「一把梭」式提示的差距。

—— FDEChina编辑部 · 风趣讲武德

2025 年，AI 编程助手成了真正的游戏规则改变者，但要驾驭好它们，需要技巧和结构。这些工具极大提升了 LLM 在真实编程中能做的事，许多开发者（包括我自己）都投入了怀抱。

以 Anthropic 为例，工程师们对 Claude Code 的采用深入到什么程度？今天 Claude Code 自身约 90% 的代码都由 Claude Code 编写。然而，用 LLM 编程并不是一键生效的魔法——它「困难且反直觉」，要拿到好结果必须学习新的范式。批判性思维依然是关键。经过一年多的项目实践，我收敛出一套与许多资深开发者不谋而合的工作流：把 LLM 当作一位能力强大、但需要明确方向、上下文与监督的结对程序员，而不是自主判断者。

在这篇文章里，我会分享进入 2026 年时我如何与 AI 一起规划、编码与协作，把我的经验和社区集体智慧的技巧与最佳实践浓缩于此。这是一种更有纪律的「AI 辅助工程」方法——大胆用 AI，同时自豪地为产出的软件负责。

如果你想看更多关于我工作流的内容，参见《The AI-Native Software Engineer》；否则我们直接开讲我学到的那些教训。

从一个清晰的计划开始（先 spec 后代码）

不要只是把愿望丢给 LLM——先定义问题、再规划解法。

一个常见错误是拿着模糊的提示直接扑向代码生成。在我的工作流（以及许多人的工作流）里，第一步是和 AI 一起头脑风暴出一份详细的规格说明（spec），再拟出分步计划，然后才写真正的代码。对新项目，我会先描述想法，让 LLM 反复向我提问，直到我们补全需求和边界情况。最后我们把所有内容整理成一份完整的 spec.md——包含需求、架构决策、数据模型，甚至测试策略。这份 spec 是开发的基石。

接下来，我把 spec 喂给一个具备推理能力的模型，让它生成项目计划：把实现拆成一个个逻辑上小口可咬的任务或里程碑。AI 实际上是在帮我做一份迷你「设计文档」或项目计划。我常常在这个计划上迭代——编辑它、让 AI 批评或打磨它——直到它连贯而完整，之后才开始编码。这种前期投入感觉慢，但回报巨大。正如 Les Orchard 所说，这像是一次「15 分钟的瀑布式开发」——一个快速的结构化规划阶段，让后续编码顺畅得多。

有了清晰的 spec 和计划，当代码生成放飞时，人和 LLM 都清楚我们在构建什么、为什么。简言之，先规划让你和 AI 站在同一页上，避免空转。这一步很多人都想跳过，但有经验的 LLM 开发者如今都把扎实的 spec/计划当作整个工作流的基石。

把工作切成小而迭代的块

范围管理就是一切——喂给 LLM 可驾驭的任务，而不是整座代码库。

我学到的一个关键教训，是别让 AI 一次性产出庞大的单体输出。相反，我们把项目拆成迭代的步骤或工单，逐个击破。这本身就像好的软件工程实践，但在有 AI 参与时更加重要。LLM 在获得聚焦提示时表现最好：一次实现一个函数、修一个 bug、加一个功能。比如，规划完成后，我会对代码生成模型说：「好，我们来实现计划里的第 1 步」。写完、测完，再进入第 2 步，依此类推。每一块都小到 AI 能在上下文内处理、你能读懂它产出的代码。

这种做法能防止模型脱轨。一口气要太多，模型多半会犯迷糊，或产出难以理清的「一团乱麻」。有开发者反馈，当他们让 LLM 一次性生成应用的巨大片段时，得到的是不一致与重复——「像 10 个互不沟通的开发者各写各的」。我吃过这种苦头；解法是停下、回退、把问题切小。每一轮迭代，我们都带着已构建部分的上下文往前增量推进。这也与测试驱动开发（TDD）天然契合——我们可以边走边为每一块写或生成测试（测试稍后细说）。

如今一些编程 Agent 工具明确支持这种分块工作流。比如，我常生成一个结构化的「prompt plan」文件，里面是按任务排好序的一串提示，让 Cursor 这类工具逐条执行。关键是避免大跃进。用小循环迭代，我们大幅降低灾难性错误的概率，也能快速纠偏。LLM 擅长快速、有边界的任务——好好利用这一点。

提供充足的上下文与指引

LLM 的上限取决于你给的上下文——把相关代码、文档和约束摆到它们面前。

在代码库上工作时，我会确保把 AI 需要的全部信息喂给它：它要修改或参考的代码、项目的技术约束、已知的坑或偏好的做法。现代工具能帮忙：比如 Anthropic 的 Claude 在「Projects」模式下能把整个 GitHub 仓库导入上下文，Cursor 或 Copilot 这类 IDE 助手会自动把打开的文件放进提示。但我常常走得更远——我会用 Context7 这类 MCP，或在怀疑模型缺料时，手动把代码库或 API 文档的关键部分复制进对话。

资深 LLM 用户都强调这个「上下文打包」步骤。比如在编码前做一次「脑倾（brain dump）」，把模型该知道的一切都倒出来：高层目标与不变量、优秀方案的示例、以及「别走这些弯路」的警告。如果我要 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 也很有价值，交叉看看它们处理同一问题的不同思路。

每个模型都有自己的「性格」。关键是：如果一个模型卡壳或输出平庸，换一个。我真的干过把同一条提示从一个聊天窗口复制到另一个服务，看它能不能处理得更好。这种「模型抢椅子」能在你撞上某个模型盲区时救你一命。

另外，务必用你能拿到的最好版本。可以的话，用最新的「pro」档模型——质量很重要。是的，这往往意味着付费，但生产力的提升能值回票价。归根结底，挑那个「手感」与你合拍的 AI 结对程序员。我认识有人就因为喜欢某个模型回答的感觉而固定用它。这完全成立——当你事实上在和 AI 持续对话时，交互体验和语气都会产生影响。

就我个人而言，近来很多编程工作我更偏爱 Gemini（先声明：我在 Google 参与 Gemini 的工作，自然更熟悉它），因为它的交互更自然，常常一次就听懂我的需求。但需要时我也会毫不犹豫换模型；有时候第二意见能让方案自己浮现。总结：为活选对工具，并记住你手边有一整支 AI 武器库。

让 AI 编程贯穿整个生命周期

用编程专用的 AI 帮手给软件开发生命周期（SDLC）的每个环节提速。

命令行上冒出了新一代 AI Agent。Claude Code、OpenAI 的 Codex CLI 和 Google 的 Gemini CLI 都是可以在项目目录里直接对话的 CLI 工具——它们能读文件、跑测试，甚至多步修复问题。我也用过 Google 的 Jules 和 GitHub 的 Copilot Agent——这些是异步编程 Agent，会真的把你的仓库克隆进云端虚拟机，在后台处理任务（写测试、修 bug，然后给你开一个 PR）。旁观这个过程有点奇妙：你发出一句「把支付模块按 X 重构」，过一会儿就收到一个代码改动齐全、测试通过的 PR。我们真的活在未来。更多讨论可读《conductors to orchestrators》一文。

话虽如此，这些工具并非万无一失，你必须理解它们的边界。它们加速的是编码的机械部分——生成样板代码、应用重复性改动、自动跑测试——但仍然非常需要你的指引。比如，我用 Claude 或 Copilot 这类 Agent 实现东西时，常常把前几步产出的计划或待办清单喂给它，让它知道任务的确切顺序。如果 Agent 支持，我会先把 spec.md 或 plan.md 装进上下文，再让它执行。这能让它不跑偏。

我们还没到让 AI Agent 无人值守写完一整个功能还能指望完美结果的阶段。相反，我以「有人监督」的方式使用这些工具：让它们生成甚至运行代码，但我盯着每一步，一有不对劲就随时介入。还有一些编排工具如 Conductor，可以让你在多个任务上并行跑多个 Agent（相当于放大 AI 产出的方式）——有些工程师在同时跑 3-4 个 Agent 各做各的功能。我也玩过这种「大规模并行」，快速铺开工作量惊人地有效，但同时盯多条 AI 线程也相当烧脑！多数情况下，我一次只用一个主 Agent，可能再加一个做评审的副手（后面会讲）。

记住，这些是电动工具——扣动扳机的仍然是你，方向盘也仍在你手里。

让人类始终在环：验证、测试、评审一切

AI 会兴高采烈地产出看起来很合理的代码，但质量的责任在你——永远认真评审和测试。我的头号铁律是绝不盲信 LLM 的输出。正如 Simon Willison 的妙语，把 LLM 结对程序员想成「过度自信、容易犯错」。它满怀确信地写代码——连同 bug 和胡话——你不抓，它不会告诉你哪里不对。所以我把每段 AI 生成的代码都当作初级开发交上来的活：通读、运行、按需测试。你必须测试它写的东西——跑单元测试，或手动过一遍功能，确认它名副其实。更多可读《vibe coding is not an excuse for low-quality work》。

实际上，我把测试直接织进了工作流。前面规划阶段常包含为每一步生成测试清单或测试计划。用 Claude Code 这类工具时，我会指示它在实现完一个任务后跑测试套件，有失败就自己调试。这种紧反馈循环（写代码→跑测试→修）正是 AI 擅长的，前提是测试得存在。难怪从编程 Agent 中获益最多的，往往是测试实践扎实的人。有一个好的测试套件当安全网，Claude 这样的 Agent 可以在整个项目里「飞」起来。没有测试，Agent 可能轻飘飘地认为一切都好（「没问题，都挺好！」），而实际上它已经弄坏了好几处。所以，投资测试——它既放大 AI 的用处，也放大你对结果的信心。

除了自动化测试，还要做代码评审——人肉的和 AI 辅助的都要。我会常态化地停下来，逐行读一遍到目前为止生成的代码。有时我会开第二个 AI 会话（或换一个模型），请它批评或评审第一个产出的代码。比如让 Claude 写代码，再问 Gemini：「你能评审一下这个函数有没有错误或可改进之处吗？」这能抓住细微的问题。关键是：不能因为代码是 AI 写的就跳过评审。如果说有什么不同，AI 写的代码反而需要更严的审视——它有时表面可信，却藏着人类一眼未必能看出的缺陷。

我还用 Chrome DevTools MCP（我和上一个团队一起构建的）来打通静态代码分析与浏览器实际执行之间的断层，服务我的调试与质量闭环。它「给你的 Agent 一双眼睛」。它让我的 AI 工具直接看到浏览器所看：检查 DOM、拿到丰富的性能 trace、console 日志或网络 trace。这一集成免去了手动切换上下文的摩擦，可以直接通过 LLM 做自动化 UI 测试。这意味着 bug 可以基于真实运行时数据高精度地诊断和修复。

跳过人工监督的惨痛后果是有案可查的。一位在赶工项目里重度依赖 AI 生成的开发者，把结果形容为一场不一致的混乱——重复的逻辑、对不上的方法名、没有连贯的架构。他意识到自己一直在「盖楼、盖楼、盖楼」，从没退后一步看看 AI 织出了什么东西。代价是一次痛苦的 refactor，外加一个再也不让事态失控的誓言。我把这句话刻在了心里。无论用多少 AI，我始终是那个负责任的工程师。

落到实处：只有在我理解了代码之后，我才会合并或上线。如果 AI 生成了绕弯的东西，我会让它加注释解释，或者亲自用更简单的写法重写。哪里不对劲，我就挖下去——就像人类同事交的代码亮了红灯时一样。

关键是心态：LLM 是助手，不是可自主信赖的编码者。我是资深开发；LLM 在这里是为了加速我，而不是替代我的判断。保持这个姿态不仅产出更好的代码，也保护你自己的成长。（听过有人担心太依赖 AI 会钝化技能——我认为只要你在环内、主动评审并理解每一行，你依然在磨砺直觉，只是速度更快。）一句话：保持警觉，勤于测试，永远评审。说到底，这是你的代码库。

高频提交，把版本控制当安全网。绝不提交你解释不了的代码。

频繁提交就是你的存档点——它们让你能撤销 AI 的失误、看懂改动。

跟一个能飞速生成大量代码的 AI 共事，事情很容易跑偏。我用极致细粒度的版本控制习惯来对冲：早提交、勤提交，比手写代码时还勤。每完成一个小任务、或每批自动化编辑成功落地，我就 git commit 一次，附上清晰的信息。这样，如果 AI 的下一步建议引入 bug 或一团乱改，我有一个新近的检查点可以回退（或从中 cherry-pick），不至于赔上几个小时的工作。一位实践者把它比作把提交当成「游戏里的存档点」——LLM 会话跑偏了，随时可以回滚到上一个稳定提交。这个建议对我极其受用。当你知道大刀阔斧的 AI 重构随时可以用 git reset 撤销时，实验的心理压力小得多。

规范的版本控制还有助于与 AI 协作。既然不能指望 AI 记住它做过的每件事（上下文窗口所限），git 历史就成了宝贵的日志。我经常翻看最近的提交，给 AI（或我自己）简报改动。实际上，只要你提供提交历史，LLM 自己也能利用它——我把 git diff 或 commit log 贴进过提示，让 AI 知道哪些代码是新的、之前的状态是什么。有趣的是，LLM 非常擅长解析 diff、并用 git bisect 这类工具定位 bug 的引入点。它们有无限的耐心遍历提交历史，可以增强你的调试。但这有个前提：你的提交历史得先整洁。

另一个好处：带清晰信息的小提交本身就在记录开发过程，这对代码评审（人类或 AI）都有帮助。如果一个 AI Agent 一口气做了五处改动然后出了问题，分散在多个提交里更容易定位是哪个提交闯的祸。如果全都堆在一个叫「AI changes」的巨型提交里，祝你好运！所以我给自己立了规矩：做完任务、跑测试、提交。这也和前面「把工作切小块」的技巧咬合——每一块最终对应自己的提交或 PR。

最后，别怕用分支或 worktree 隔离 AI 实验。我采用了一个进阶工作流（受 Jesse Vincent 等人启发）：为新功能或子项目开一个全新的 git worktree。这让我能在同一个仓库上并行跑多个 AI 编程会话而互不干扰，之后再合并改动。有点像给每个 AI 任务一个自己的沙箱分支。实验失败，扔掉那个 worktree，主干毫发无伤；成功，就合并进来。当我让 AI 实现 Feature A、同时我（或另一个 AI）做 Feature B 时，这个方法至关重要。版本控制正是这种协作得以可能的前提。一句话：勤提交，用分支组织工作，把 git 当作让 AI 改动可管理、可回退的控制机制来拥抱。

用规则和示例定制 AI 的行为

用风格指南、示例甚至「规则文件」引导你的 AI 助手——一点点前期调教，换来好得多的产出。

我学到的一点是：你不必接受 AI 的默认风格或做法——给它规则就能深度影响它。比如我有一个定期更新的 CLAUDE.md，里面是给 Claude（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 行为的创意「规则集」。你可能听说过「Big Daddy」规则，或在提示里加一条「不许幻觉/不许欺骗」的条款。这些本质上都是提醒 AI 说实话、别凭空编造不存在代码的技巧。比如我有时会在提示前加一句：「如果你对某件事不确定、或代码库上下文缺失，请提问澄清，而不是编一个答案。」这能减少幻觉。我用的另一条规则是：「修 bug 时，永远在注释里简要解释你的推理。」这样 AI 生成修复时，会留下类似「// Fixed: Changed X to Y to prevent Z (as per spec).」的注释。这对事后评审超级有用。

总之，别把 AI 当黑盒——调教它。配置系统指令、共享项目文档、写下显式规则，你就能把 AI 变成团队里更专门的开发者。这就像给新员工做入职：你会给他风格指南和一些起步提示，对吧？对你的 AI 结对程序员也一样。投入产出比极高：产出更少需要返工、与代码库融合得更顺滑。

把测试和自动化当成力量倍增器

用上你的 CI/CD、linter 和代码评审机器人——AI 在能自动抓错的环境里表现最好。

这是「人在环内」与「提供上下文」两条的推论：一条润滑良好的开发流水线能放大 AI 的生产力。我确保任何重度使用 AI 编程的仓库都有健全的持续集成：每次提交或 PR 自动跑测试、强制代码风格检查（ESLint、Prettier 之类）、理想情况下每个新分支都有可用的 staging 部署。为什么？因为我可以让 AI 触发这些流程并消化结果。比如 AI 用 Jules 或 GitHub Copilot Agent 开了 PR，CI 会跑测试并报告失败。我可以把失败日志喂回给 AI：「集成测试挂在 XYZ 了，我们来调一下。」这让修 bug 变成快速反馈的协作循环，AI 处理得相当好（它提修复，我们再跑一遍 CI，继续迭代）。

自动化质量检查（linter、类型检查器）也在引导 AI。我有时会直接把 linter 输出放进提示。如果 AI 写的代码过不了 linter，我就把报错复制进对话说「请解决这些问题」。模型随即清楚该干什么，就像有一位严厉的老师站在 AI 身后。经验之谈：一旦 AI 看到了某个工具的输出（挂掉的测试、lint 警告），它会非常努力去纠正——毕竟它「想」给出正确答案。这呼应了提供上下文那一条：把 AI 行为在环境中的结果（测试失败等）交给它，它会从中学习。

AI 编程 Agent 本身也在持续吸纳自动化钩子。有些 Agent 在所有测试通过前拒绝宣称任务「完成」——这正是你想要的严谨。代码评审机器人（无论是否 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「奖励既有的最佳实践」——写清晰的 spec、有好的测试、做代码评审等等，一旦有 AI 参与，这些实践的威力都变得更大。以我的经验，AI 让我得以在更高的抽象层级上工作（聚焦设计、接口、架构），由它去产出样板代码，但前提是我得先拥有那些高层技能。正如 Simon Willison 所说，几乎一切让一个人成为资深工程师的东西（设计系统、管理复杂度、知道什么该自动化什么该手写），恰恰是如今与 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 辅助工程的新书，书站上有一批免费技巧可供查阅。

延伸阅读：关于 AI 编程工作流与工程师能力建设，参见站内 AI Coding 主题、FDE 能力模型、FDE 项目生命周期 与 实践指南。

本文由 FDEChina 团队翻译自原文，转载已注明出处；如需引用请以原文为准。