2026年，我开始把代码交给 AI

进入 2026 年，随着 AI 编程能力的提升，我的开发工作流也发生了明显变化。AI 已经能够参与方案分析、编码、测试和 Code Review。在日常工作中，越来越多代码由 AI 编写，我更多负责说清需求、提供上下文、审查产物，并根据结果补充反馈。过去，我主要靠亲自编码和调试推进实现；现在，则可以把一项任务交给 AI，让它读取工程、修改代码、运行检查，再根据反馈继续处理。人在其中需要组织好这段协作过程，决定什么时候让 AI 继续推进，什么时候介入判断。

一、工作流改变之后，需要解决什么问题

　　代码生成变快，并不意味着从需求到交付的所有环节都同样提速。AI 可以很快给出一份能够运行的实现，但人仍然需要确认它是否符合业务预期，是否契合当前架构，改动范围是否合理，以及后续是否容易维护。过去我们在编码过程中顺带建立起来的系统理解，现在也得在审查产物时重新补上。我已经在使用一些办法：让 AI 参考现有实现，要求最小化改动，反复讨论方案，再切换模型做 CR。不过，这些动作怎样安排才有效，哪些问题必须由人自己判断，仍然值得梳理。沟通、阅读、验证和返工，都需要计入完整的交付成本。本文围绕三个问题展开：

1. 怎样与 AI 协作，减少沟通和返工，提高解决问题的效率？
2. AI 完成以后，人应该检查什么，才能判断产物是否可以交付？
3. 当越来越多编码和排错交给 AI，自己怎样继续成长，并留下可复用的知识？

　　要回答这些问题，我们需要先明确人与 AI 的分工，再讨论任务如何推进、结果如何验收，以及个人能力如何积累。

二、重新理解人与 AI 的分工

　　让 AI 实现一个功能时，我们很容易把注意力放在需求有没有描述清楚。但功能描述通常只约束一部分结果，实现过程中仍然包含许多具体决定：状态放在组件里还是公共层，错误由谁处理，是否复用已有能力，以及哪些行为需要保持兼容。单看生成的代码，这些做法可能都有合理解释；但放进已有项目里，却未必合适。比如，一个新写的状态管理模块固然能完成需求，可如果工程里已经有承担同样职责的模块，这份新实现就会平白增加维护成本。要是等到审查阶段，人再去向 AI 解释项目原来的设计、推翻重写其中一部分代码，前面省下的时间就会在返工和重新理解中被抵消掉。

　　这也是我要求 AI 参考现有代码的原因。它需要参考的不只是命名和格式规范，更重要的是职责划分和行为约定——这些决定了本次修改应当接在哪里，以及哪些地方不能乱动。项目里那些还没写进文档的经验，也需要人在相关任务中点出来，才能成为 AI 用得上的依据。这样看，高质量上下文的作用就具体了：需求说明要解决的问题，代码和规范提供工程约束，验收标准明确预期行为，测试与运行结果帮助发现偏差。把这些条件准备好，AI 才有机会在实现过程中自行检查和调整，人也不必等到最后才去逐一辨认它暗中作出的假设。

　　当然，我们不可能提前把需求的每一个细节都描述完，有些问题要看到代码、实际跑起来以后才会暴露。因此，人的判断应当贯穿整个过程：足以改变方向的前提条件由人尽早明确，局部的实现细节则允许 AI 先往前推，发现偏差再靠反馈修正。对于熟悉、低风险的小改动，这个过程可以很短；一旦涉及重要未知，就值得先花时间把前提确认清楚。

三、如何高效地与 AI 共同解决问题

从项目事实出发，减少需要猜测的部分

　　老项目最有价值的条件，是它已经运行过一段时间。代码里有可复用的模式，测试里有已确认的行为，历史记录里往往还能查到某些看似奇怪的设计当初是为了解决什么问题。把这些依据找出来，比重新向 AI 描述一套理想架构更有助于完成眼前任务。因此，任务开始时，我们可以先让 AI 顺着相关入口查清当前行为，找到适用的参考实现，再说明预计改在哪里。如果自己对项目熟悉，就直接提供入口和约束；不熟悉的部分，则交给 AI 去排查。至于调查算不算充分，主要看它能不能解释清楚本次问题及其影响范围，没必要一上来先让它生成一份全仓库介绍。另外，对找出来的参考实现，人也得顺手核对一眼：旧代码可能带着历史缺陷，两个外观相似的功能也可能有不同的生命周期，决定沿用之前，至少得弄清它成立的前提。这一步既保留了人已有经验的作用，也让“参考现有代码”真正落到了实处。

　　面对缺少参照的新项目，我们就需要先约定第一版解决什么问题、运行在什么条件下，以及怎样验收。先跑通一条能够实际使用的核心路径，确认技术选择合适后，再把这套结构和约定扩展到其他功能；否则，AI 会在需求仍然含糊时一次生成大量设计，后面只要范围一调，整批代码都得跟着返工。不过，无论是老项目还是新项目，上下文都可以逐步积累：把稳定约束留在仓库里，把任务背景写在需求说明中，把能靠机器可靠检查的规则交给工具。准备工作的投入应当与任务规模相称，我们真正需要提前弄清的，是那些一旦判断错了就会改变方案走向的重要条件。

审视需求的合理性，保留取舍的空间

　　与 AI 讨论实现时，还有一个容易忽略的前提：我们提出的需求本身，是否值得按原样实现。当任务已经被明确交给 AI，它往往会围绕“怎样满足要求”继续寻找办法，却未必主动判断这些要求是否合理、是否存在冲突，以及哪些条件其实可以调整。比如针对特定机型的 Bug，某个修复可能需要改动主体结构、增加跨模块耦合，甚至让通用逻辑长期承担特殊场景的分支。此时反复追问“有没有更好的实现”，AI 仍可能回答，在满足全部条件的前提下只能这样做。这个回答即使在技术上成立，也只说明当前条件下的实现选择受限，并不能说明这些条件都必须保留，更不能直接作为接受这份改动的理由。

　　因此，方案阶段就应当把需求合理性纳入讨论：真正要解决的用户问题是什么，提出的具体做法是否必要，哪些是必须满足的底线，哪些可以协商。让 AI 帮忙指出不合理的前提和相互冲突的要求，比较调整范围、改变处理方式或接受部分限制后有哪些选择，再结合问题的严重程度、影响和工程约束，与相关负责人确认取舍。这种判断不能单靠 AI 完成，也不能因为只影响少量场景就直接否定修复。即使方案阶段没有发现问题，实现过程中暴露出的复杂性也应当成为重新讨论的依据。如果读懂代码后发现，为了满足某项要求已经破坏了整体结构，就需要回头审视这项要求，而不是继续催促 AI 把它做完。人理解每部分改动的目的和代价，才有可能识别这种情况，判断应该继续修改实现，还是重新明确需求边界。

讨论方案，要增加判断依据

　　在实际使用中，我会反复和 AI 讨论方案。但如果每一轮只是追问“有没有更好的解法”，拿到一堆新选项之后，人反而要花更多时间去弄懂它为什么又换了推荐。这种讨论之所以转不出结果，是因为缺少收敛条件。到底是需求场景没对齐、现有代码机制没摸清，还是某个技术行为需要查资料或做实验确认？如果我们没把缺的这部分依据补上，只是换个问法继续追问，并不能保证新建议就更适合当前项目。

　　拿前端常见的请求乱序作个简短示意：先发出的请求晚返回，把后发请求的结果覆盖了。防抖虽然能减少请求次数，却没法保证已经发出的请求按顺序返回。如果问题根因确实是这个返回时序，我们继续和 AI 比较哪一种防抖写法更简洁，就没有切中要害；这时候应当先确认数据写入的实际顺序，再看修复手段能不能真正拦住过期的响应。只有把原因敲实了，才有条件讨论具体的方案取舍：现有请求封装有没有现成能力？只改局部的状态写入够不够？如果动公共层，会波及哪些调用方？只有围绕真实代码和工程约束去对比方案，人才能有依据地拍板，而不只是挑一个听起来更顺耳的解释。这也让“最优方案”有了现实的边界——只要当前选择能满足需求，复杂度和维护成本划算，又没有漏掉明显更简单的替代做法，就已经够用。我们没必要要求 AI 穷尽所有可能，也不必因为“还存在另一种写法”就反复推倒重来。

控制改动的节奏，及时接收反馈

　　方案有了依据，实现过程仍然可能跑偏。如果等 AI 改完一大批代码再从头看，人得一边回头核对需求、一边理顺它的设计，还得同时挑错，审查起来会非常吃力。把任务拆成一段段可检查的行为，我们就能更早发现方向上的偏差。当然，拆得太碎也有代价：要是每改几行就停下来解释，人和 AI 都会陷入来回确认的消耗；可如果单纯按文件拆，一段完整的行为还没成型，检查也很难下结论。比较合适的停顿节点，是当前已经有了可观察的运行结果，或者下一步正好要建立在某个需要确认的决定之上。在这些节点上，我通常会要求 AI 说明改了什么、为什么改、检查结果如何以及还有哪些未决事项，自己再顺着实际 Diff 核对。普通的语法、类型或构建报错，大可以让 AI 根据工具反馈自己修完；但如果出现了预期之外的行为，就得停下来重新检查前提假设，避免在原因不明时连续打补丁。

　　除了把控推进节奏，人还需要管住改动范围与验证方式。我理解的“最小改动”，要同时兼顾“问题是否彻底解决”和“有没有夹带无关变化”：比如修请求乱序时，如果只挡住旧列表数据写入，却任由旧请求改写错误提示或提前关掉新请求的加载状态，这叫修复不完整；反过来，为了一个局部缺陷去重写整套公共请求体系，又会扩大不必要的影响面。验证同样要跟着具体疑点走。如果测试里只断言“请求成功后能展示列表”，并不能证明它覆盖了乱序场景；要是测试预期也是由 AI 顺着自己的实现补出来的，测试和实现还可能共享同一个错误理解。过程中的检查，应当直接回答本次修改是否满足了某项具体要求；即使测试全部通过，人心里仍要清楚它到底验证了什么。

保留决定，避免下次重新猜测

　　一次任务结束后，代码能说明最终怎样实现，但复杂问题的来龙去脉往往很难只靠代码还原。简单变更，通常通过提交信息和 MR 就能说明目的与改动。对于有价值的复杂任务，我目前的做法是把对话和上下文归档到个人的私有 Git 仓库里，保留每次与 AI 共同解决问题的完整背景和过程。后面再遇到相关问题，就可以直接查阅当时掌握了哪些信息、考虑过什么方案，以及为什么作出最后的选择。

　　保留完整上下文，是因为最终方案只是解决过程的一部分。有些限制条件为什么成立、某个看似可行的方案为什么被放弃，往往要结合前面的讨论才能理解。这类信息很难全部放进提交信息或 MR，独立归档也方便以后继续追查，必要时可以将相关材料提供给 AI。不过，对话中也会保留后来被推翻的判断，回看时仍要结合最终结论和验证结果，并核对它们是否适用于当前代码。归档保存的是当时的解决过程，不能直接代替这一次的调查和判断。

四、AI 完成以后，怎样判断可以交付

　　过程中的反馈能帮我们把每一步尽量走对；到了准备交付时，我们还需要退后一步，对照完整需求看看最终产物是否真正闭环。毕竟，几段分别通过检查的局部修改，拼在一起仍有可能漏掉某个调用入口，或者无意间改变了原本应该保持的行为。这一步可以先让 AI 自查，重要改动也可以引入其他模型做交叉 CR。不过，做评审的模型必须能看到原始需求、项目约束、真实代码差异和运行证据；如果我们只把前一个模型的完成总结转手传过去，它很容易顺着同一套解释往下走。单纯增加模型数量，并不会自动补齐它们共同缺失的上下文。正因如此，模型给出的评审意见也需要人来核实：它指出的风险在当前代码里有没有实际触发条件？属不属于本次改动的影响范围？为了消除这个风险去改代码，又会引入什么新成本？把重点问题修完并重新验证相关路径后，如果没有再出现新的事实或漏洞，就不必靠无限增加评审轮次来寻找安全感。

　　机器和模型过完一轮，人的最后一轮通读依然包含许多工具难以替代的工程取舍：功能虽然实现了，值不值得为此专门抽出一个公共模块？测试虽然全绿了，控制流是不是已经绕到了难以维护的地步？这些问题都得结合项目现状和后续演进方向来衡量。AI 可以帮我们罗列利弊，但最终拍板的人，必须能解释清楚自己为什么接受当前这份实现。交付前，我会对照下面几项做一次集中确认：

• 原始需求已经满足，必须保留的行为没有遗漏，也没有擅自增加功能。
• 修改位置和职责划分合理，改动范围足以解决完整问题，没有夹带无关重构或重复建设。
• 命名、结构和控制流清晰可读，新增的复杂度有实际理由，相关的失败和边界行为已经核对。
• 自己理解各部分改动的目的，能讲清关键机制、方案代价，以及出问题时的排查入口。
• 相关验证确实执行过，结果仍适用于当前代码，重要的测试预期和评审意见已经核实。
• 尚未验证的部分及其潜在影响已经说明，遗留问题和下一步动作已有记录。

　　要求自己理解改动，并不是要把所有底层依赖的内部实现都摸透，但支撑本次修改正确性的关键机制绝不能含糊。如果面对某处逻辑，自己还只能重复“AI 说这样写没问题”，那就说明还得继续读代码、查资料或补做验证。

　　代码确认无误后，我还会站在使用者角度做一次人工黑盒验收，看看这份实现放回真实流程里到底好不好用：主流程顺不顺畅，异常与恢复是否正常，界面表现、文案和交互细节有没有别扭的地方。验收时的预期应当来自原始需求，而不能完全照着 AI 根据代码生成的测试步骤去点，否则同一个场景遗漏很可能会在代码和验收步骤里同时出现。当然，人工手测也没法覆盖所有内部深层缺陷，它需要与前面的代码审查、针对性自动化验证互相补位。如果这一步发现了问题，就退回去修改并重测受影响的部分，前面那些依然有效的验证结果则可以直接复用。最终写交付说明时，把修改目的、已确认的结果和剩余限制交代清楚，远比只留下一句“测试通过”更让人踏实。

五、任务完成以后，怎样留下自己的成长

　　任务顺利交付了，不代表自己的能力也跟着长了一截。因为 AI 能直接给出可用的修复，人很容易跳过原本在查资料、试错和单步调试中攒下的理解。眼前的故障虽然消除了，可等到下次前提条件一变，还是得从头找 AI 解释。所以，我们要把仓库里沉淀的资料和个人真正掌握的能力分开来看：文档保存的是最终结论，而后续维护靠的是人对代码运行过程的把握。比如，知道了怎么忽略过期响应之后，如果再叠加上防抖、缓存或页面恢复，自己能不能判断原来的修复前提还成不成立？遇到新的偶发异常时，知不知道先盯住哪个状态、去哪抓证据？这些才是日常维护里真正带得走的能力。AI 的讲解可以帮助我们建立认识，但看着解释觉得顺畅，离真正掌握还有一段距离。试着合上对话自己讲清一条执行路径，改一个条件预测运行结果，或者亲手去定位一个相关问题，往往一下就能暴露出理解上的盲区。对重要机制多做这一步，心里才会有底。

　　当然，人的精力有限，这种学习投入也需要有所取舍。自己经常维护、影响面大、容易出隐蔽故障的核心机制，值得花时间深入读源码、做小实验，并保留亲手编码和调试的机会；而偶尔调用的边缘工具，先摸清它的适用条件和验证方式就够了，没必要把所有生成代码都重写一遍，也不必把每个小任务都当成一门课来学。回看协作过程，我们还可以把反复撞上的问题分成两类：如果是项目约束没交代清楚，就去完善仓库规范、补充参考示例或加上自动化检查；如果是某个机制自己始终拿不准，那就老老实实放进学习计划里补课。前者是在改善下一次协作的外部条件，后者是在补足自己的工程判断力。要是偷懒把这两类问题都只塞进下一轮提示词里，知识缺口依然会留在原地。

六、总结

　　回看这段时间的工作流变化，把代码交给 AI 并没有减轻人的工程责任，只是把我们的投入重心从“亲手写出每一行实现”转向了“建立依据、校准方向和验证结果”。我希望在日常协作中逐渐减少的，是每次重复解释同一套背景、重复核对同类低级错误的消耗；而省下来的时间，则需要留出一部分，用来吃透那些接下来还要长期维护的代码。只有这样，下次再让 AI 实现新需求时，自己才能问出更准的问题，也更清楚什么样的结果才算合格。

　　不过，这套做法有一个隐含前提：在熟悉的领域里，我尚且能靠过去积累的经验去审核 AI；当工作进一步扩展到不熟悉的技术栈，连“到底该检查什么”都缺乏判断时，我们又该如何建立新的依据？这个问题，我想留到下一篇继续讨论。