先说一个最近在项目里反复出现的情景我用 AI 生成一段功能代码耗时不到十秒但接下来为了确认它是否符合接口约定、异常处理是否足够、输入边界到底该由调用方负责还是由服务端兜底我和同事花了一个多小时争论。代码本身没有问题真正花时间的是“这段代码到底该按什么标准被接受”。这件事让我重新理解了标题里的那句话当 AI 让编码变廉价争论与可靠性才是新瓶颈。这不是一句口号而是我今年在多个项目里最直观的体感。过去写一个功能编码工作量往往占据大头需求讨论被压缩到很小的比例现在编码被 AI 大幅加速反而把需求模糊、边界不清、可靠性标准缺失这些旧问题放大了。越是用 AI 写代码越要先把“什么是对的”想清楚。下面试着把这段体会拆开来讲重点聊三件事编码变便宜之后工程问题到底从哪儿开始变了可靠性为什么成了新的技术主线以及面对这些变化 AI Engineer 该怎么重新定义自己的工作方式。1. AI 把编码成本打下来之后问题从“怎么实现”变成了“该实现什么”1.1 编码成本下降不代表项目成本下降过去我们习惯把项目工期估算成“写代码需要多久”。这个估算模型在 AI 辅助编码普及之后已经开始失效。如果只需要把需求描述清楚AI 很快能生成一版可以运行的代码速度远超人工手写。但工程项目的成本结构并不是只有编码这一环。随便拆一下一个功能从想法到上线的成本构成需求澄清和拆解成本接口设计和约定成本编码实现成本代码评审成本测试和验证成本部署和监控成本线上故障排查成本后续维护和迭代成本AI 能明显压缩的是第三项也就是编码实现成本。但它不减少其他任何一项。如果需求本来就模糊AI 生成代码的速度越快反而越容易在错误的方向上做出看起来完整的东西后续返工成本不会因为编码便宜而降低。我在实际项目中观察到一个常见现象AI 几分钟内产出的代码看起来结构完整、命名清晰、注释齐全甚至能通过单元测试。但它很容易忽略真实业务里不舒服的地方比如某个字段可能为空、某个第三方接口偶尔超时、某个历史数据格式并不统一。这些细节在需求文档里没有写AI 不知道于是它做了“最合理的假设”而这个假设往往在真实环境中不成立。这时候你面对的问题就不是“代码写不出来”而是“代码写得出来但该不该用、怎么改、谁来负责验收”。这是需求层和判断层的问题AI 替代不了。1.2 需求确认从“一次性讨论”变成了“高频校准”在传统工作流里需求确认通常发生在开发前。产品经理写好需求开发评审然后进入编码。AI 辅助编码之后这个节奏被打乱了。因为编码太快很多团队会倾向于不再做详细需求拆解而是直接把一句话需求丢给 AI先看一版结果再改。这种做法看起来很敏捷但实际上把“需求确认”从一次性评审变成了高频反复校准。每改一次双方都要重新对齐反复多轮之后沟通成本反而上升。我不是说这种做法一定错但必须意识到代价。更快地生成代码意味着你有更强的能力去快速验证一个想法的可行性。这是好事。但如果你没有把“验证什么”“按什么标准验证”提前定清楚那么快速生成只会让你更快地消耗团队注意力。我这里更建议的顺序是先花少量时间把需求里的关键问题和边界条件列出来哪怕一开始不完整也要有一个“需求问题清单”再让 AI 协助生成代码。AI 适合在问题和边界相对清楚的情况下帮你迅速铺开实现而不是反过来让 AI 替你定义需求。换句话说过去我们怕的是“写不完”现在我们更该怕“写了一大堆但讨论得太少”。1.3 验收成本才是 AI 编码时代真正的大头如果让我给一个最明确的工程建议那就是从现在开始把验收成本纳入每一项任务的成本估算。所谓验收不只是跑通用例而是确认这段代码在真实约束下可以安全上线。这包括输入边界是否清楚异常输入有没有兜底依赖的外部服务是否可控超时和重试策略是否合理数据一致性如何保证有没有幂等设计日志是否足够定位问题性能是否在可接受范围部署之后如何回滚这些工作不会因为 AI 写代码而自动完成甚至 AI 会让它们变得更隐蔽。因为 AI 生成的代码风格统一容易让人产生“它已经处理好了”的错觉实际上很多异常路径根本没有覆盖。所以我在团队里一直强调AI 生成代码只是“初稿”它的价值是把你从打字层面解放出来让你有更多精力去检查这些真正要命的地方。不要因为生成速度快就跳过了本该属于工程师的判断。1.4 从无到有做出来的东西和用 AI 快写出来的东西验收标准应该一样这是我最想提醒的一点。很多人用 AI 写代码时会下意识降低验收标准因为“反正不是自己手写的改一改就能用”。这个心态非常危险。工程上判断一段代码能不能上线只取决于它是否满足可靠性、可维护性、可扩展性要求而不取决于它是由人写的还是 AI 写的。如果 AI 生成 500 行代码你只看了一眼就提交那你在做一次没有质量保障的上线。我并不是要求所有 AI 生成代码都要达到生产级标准。如果只是本地验证思路、写个脚本跑一遍数据那当然可以怎么快怎么来。但凡是进入主干分支、要部署到线上、会被其他模块调用的代码就必须走完整验收流程。这个标准和是否用 AI 无关。注意先跑通一个最小用例只能证明流程没有断。真正的验收要看异常路径、边界输入、依赖故障和长期运行压力。不要用“AI 写的”作为降低标准的理由。2. 可靠性是新的编码主线而不是附加功能2.1 可靠性问题为什么会被 AI 放大AI 编码的典型特点是在“常态路径”上表现很好在“非常态路径”上容易想当然。它能写出一个函数处理正常输入也大概率能写出常见的 if 分支但它不会像资深工程师一样基于线上经验预判哪里会出问题。举例来说如果你让 AI 写一个读取文件的函数它通常会写出打开文件、读取、关闭最多加一个 try-except。但真实生产里你还要考虑文件不存在、编码错误、权限不足、文件过大、读取超时、部分写入、临时文件堆积、并发读写冲突。AI 生成的代码不会主动把这些都覆盖到除非你在提示词里明确要求并且能验证它真的覆盖了。这种缺失在单个小函数里不明显一旦组合成完整系统问题就成倍放大。一个模块的异常输入传给下一个模块下一个模块再传给下一个最后表现出来的是一个非常诡异的线上故障根源却在一开始的校验缺失。可靠性之所以成为新瓶颈不是因为 AI 引入了更多 bug而是因为编码变便宜后系统里被快速堆叠的代码量变多了异常相互作用的空间也随之变大。2.2 把可靠性拆成可以验证的维度“可靠性”听起来很抽象如果不拆解团队就只能在出问题之后互相甩锅。我在项目中习惯把它拆成四个可验证的维度输入可信度系统对外部输入做了什么假设假设之外的情况是否被处理依赖可用性外部服务故障、超时、返回异常时系统是否能降级或快速失败状态一致性任务重复执行、消息重投、多实例并发时是否会重复计费、重复写入、数据错乱可观测性出问题时日志和监控是否能帮助你在几分钟内定位而不是靠重启大法这四个维度不是一次性能做完的而是每写一段关键代码时都要过一遍的问题。AI 生成的代码尤其需要逐项检查因为它默认不会做超出提示词范围的防御。2.3 不要一上来就追求高可用先给可靠性分级这里很容易出现另一个极端为了让系统“可靠”什么都要做到微服务、多集群、自动容灾。但实际项目里一个内部工具和一个对外交易系统可靠性要求完全不同。我通常会把可靠性需求分成三档低档内部脚本、一次性数据分析、原型验证。允许失败重跑即可。不需要完整异常处理。中档常规服务。需要有错误处理、日志、基本监控允许短暂不可用但要快速恢复。高档核心交易链路、对外主服务。需要完整幂等、降级、容灾、告警、回滚和演练。AI 编码可以帮你快速完成低档实现但高档系统的可靠性设计仍然需要工程师基于业务场景做判断。先确认系统处于哪一档再决定要花多少精力在可靠性上会比一刀切更务实。2.4 测试策略要跟着 AI 编码方式调整传统测试往往是在代码写完后再补。AI 编码时代测试更像是代码评审的一部分甚至应该提前到需求确认阶段。我在工作流里会先写一组“验收用例”再让 AI 生成实现。这有点像测试驱动开发但更强调边界和异常而不是单纯的功能正确性。例如如果输入为 None 或空字符串函数应该返回什么如果外部接口超时是重试还是直接报错如果同一条任务被提交两次会不会产生重复结果如果磁盘空间不足日志和错误信息是否清晰这些用例写起来不复杂却能有效约束 AI 生成的方向。没有这些约束AI 会按自己的“最合理假设”发挥最后你可能花更多时间在重构上。建议让 AI 写代码前先在提示词里写明“需要处理这些边界情况”并把对应测试用例一起发过去。这样生成结果会比空泛地写“请实现一个函数”靠谱得多。3. 团队争论为什么成了新的瓶颈以及如何让争论变得有价值3.1 争论没有变多但争论的时间占比变大了编码时间缩短之后会议、评审、对齐、争论在总开发周期里占的比例上升。大家会明显感觉到代码写得快了但怎么把事情定下来的过程变得更显眼。这是必然的。AI 让“提出一个方案”变得太容易几乎每个方向都能快速生成代码。于是团队面临的不是“哪个方向能做出来”而是“哪个方向更符合长期目标、更可靠、更好维护”。这些问题天然依赖人的判断争论就是判断碰撞的自然结果。我之前参与过一个项目让 AI 在同一套需求下生成两个实现方案。一个简单直接性能一般一个复杂灵活扩展性好。两个方案都能满足当前需求但团队争执了快两个小时因为大家对公司未来半年的方向判断不一样。代码本身没有错错的是“还没有决定未来要往哪走”就开始写代码了。这类争论无法靠换更好的提示词解决只能靠更透明的决策机制解决。3.2 把争论从“个人偏好”变成“决策条件”无效争论通常集中在个人偏好上比如“我觉得这种写法更优雅”“我习惯用这种设计模式”。有效争论应该围绕可验证的条件展开比如性能指标、故障影响范围、团队维护能力、上线成本和风险。一个我常用的方法是争论前先明确三个条件。这个方案要满足的核心验收标准是什么未来半年内可能变化的外部条件有哪些如果选错回退成本有多大明确这三个条件之后很多争论会自动消失。因为判断标准已经不是“谁说得有道理”而是“哪个方案在这些条件下更稳、更省、更容易回退”。这个方法也可以用来约束 AI 生成的方案。你可以要求 AI 不只输出代码还要列出一段“假设清单”把它对输入、依赖、运行环境的假设写清楚。然后你在评审时只用逐个确认这些假设是否成立而不是泛泛地评价代码好或不好。3.3 最有价值的争论发生在“写代码之前”和“上线之后”我给团队的建议是把争论前置和后置。前置是指在写代码前先把接口约定、数据字段、错误码、幂等策略、升级兼容性这些标准定下来。这些约定一旦定好AI 生成代码的冲突就会大大减少。后置是指上线后根据真实监控数据和故障记录来复盘用事实替代争论。中间那个环节也就是对着 AI 生成的一堆代码争论风格是最不值得的。风格问题交给格式化工具规范问题交给 lint 规则剩余问题才值得人花时间讨论。这样调整之后争论仍然存在但它的产出是决策记录、约定文档、验收标准、复盘报告而不是“我觉得这个改一下更好”。3.4 把争论结果沉淀成团队知识库如果每次争论都只停留在会议结论下一次遇到类似问题还是会吵一遍。我建议团队建立一份“工程决策记录”记录每个重要决策的问题背景、可选方案、选择理由、已知代价和适用边界。这份记录的用途不是写文档交差而是给未来的 AI 提示词提供背景。你可以把决策记录里沉淀出的约定写进项目级提示词每次让 AI 生成代码时自动带上这些约束。这样团队的集体判断就能通过 AI 工具持续发挥作用而不只是存在于某个人的脑子里。这一点非常关键。AI 编码时代真正有价值的工程资产不只是代码还包括“为什么这样写”的判断。它决定了团队能不能在快速迭代时保持一致性和稳定性。4. AI Engineer 的新定位从写代码的人变成给 AI 定标准的人4.1 你卖给业务方的不是代码而是“结果可预期”我越来越觉得AI Engineer 的核心交付物不是“写了多少行代码”而是“在给定约束下结果是否可预期”。这意味着你的工作重心要转向把模糊需求转成明确验收标准把验收标准转成 AI 能理解的提示词和测试用例在 AI 输出后做系统级检查设计可靠性和监控策略在故障发生时快速定位和回滚这更像一个“技术产品经理 可靠性工程师 资深开发”的混合角色。如果你只会让 AI 生成代码但无法判断它是否可靠那你的可替代性反而比过去更高因为 AI 已经能完成那部分工作。4.2 建议的工作流先定标准再写提示词最后验证我目前在项目中跑得比较顺的流程是需求拆解把业务需求拆成功能点明确每个功能点的输入、输出、边界、异常场景。验收用例先行先写 3 到 5 个关键用例覆盖正常路径和至少 2 个异常路径。提示词组装把需求描述、验收用例、项目约定、格式要求写入提示词指定 AI 生成代码。代码检查检查 AI 输出是否满足验收用例是否引入额外风险是否遵循既有约定。小范围验证在测试环境跑通观察日志、性能、依赖调用再决定是否进入主干。发布与监控发布后关注关键指标准备好回滚方案而不是发布完就不管。这个流程看起来比“一句话丢给 AI”要重但长期来看更稳。因为它把最贵的讨论和验证放在了合适的位置而不是等项目堆了一大堆代码后再返工。4.3 适合 AI Engineer 做的任务和不适合的任务任何工具都有边界AI 编码也不例外。用得好坏很大程度取决于你是否知道它适合处理什么。比较适合 AI Engineer 处理的任务有模板化 CRUD 接口数据格式转换编写单元测试生成 API 客户端代码脚本化运维操作文档生成和注释补全对既有代码的快速重构初稿不适合完全放手给 AI 的任务包括核心架构拆分和模块边界定义涉及多团队协作的接口契约复杂状态机和分布式一致性方案安全敏感场景需要深入业务经验的规则制定在这些高风险任务里AI 可以当辅助工具提供备选方案但最终的决策和实现检查必须由有经验的工程师负责。4.4 提示词不是一次写出来的而是持续维护的很多人把提示词当成一次性输入用完就丢。实际上一个团队应该把提示词当成长期资产来维护就像维护代码库一样。我习惯把项目级的公共约束集中维护在一个文件里内容包括语言和框架版本编码规范目录结构约定异常处理约定日志规范常见边界场景禁止事项每次让 AI 生成代码时把这份约束文件作为上下文放进去。这样 AI 的输出会更符合团队习惯后续改动成本也会明显下降。这不是玄学而是把团队原来沉淀在老人大脑里的经验显性化给 AI 工具。做得好新人也能力利用 AI 写出风格接近、质量可接受的代码做得不好AI 生成的就是一次性的、风格混乱、难以维护的代码。5. 一次项目实战用 AI 辅助编码跑通一个数据同步工具5.1 需求背景和起始约束这里用一个我参与过的项目作为例子。那时需要写一个数据同步工具把业务库中的增量数据同步到分析库。数据量不大但要求不能丢数据、不能重复写还要在源库字段变化时能快速调整。放在过去这个工具大概要写两三天。但在 AI 辅助下编码本身很快就完成了真正的难点在于如何定义“不丢、不重”的验证方案以及如何处理源库结构变化。我们在开工前先列了这份约束清单同步任务支持手动触发和定时触发同一批次如果失败重试时必须跳过已成功的数据不能重复写入新旧字段映射要集中管理不能散落在代码各处每个同步批次都要有可追踪的任务 ID 和日志目标库写入失败要保留原始数据方便排查这份清单花了一个小时。但它决定了后续 AI 生成的代码长什么样也决定了项目会不会在后期翻车。5.2 怎么用 AI 生成主流程并补上可靠性设计我们先用 AI 生成了第一版主流程包括读取增量数据、字段转换、写入目标库、记录批次状态。AI 生成这版只花了不到十分钟代码风格也还算整洁。但拿过来评审时发现三个可靠性缺口。第一个是幂等。AI 只实现了“按时间范围同步”没有处理“同一个时间范围被重复执行”的情况。如果定时任务重复触发目标库会插入重复数据。我们要求 AI 增加按业务主键判断已经存在的记录只更新不插入。第二个是失败重试。AI 的默认做法是失败后整体抛异常批次标记为失败。这种设计在源库数据量小的时候没问题但一旦数据量变大整个批次重跑的成本很高。我们改成按记录粒度记录处理状态失败的数据单独归入死信表可以手动修正后重放。第三个是源库结构变化。AI 生成的字段映射是硬编码在同步函数里的。后面调整字段时要改动主流程容易引入回归。我们把字段映射拆成独立配置文件并让 AI 生成一个配置解析器这样业务方调整字段时无需改代码。这些修改在 AI 辅助下都很快每次改完都能立即跑测试。但如果你一开始没做可靠性拆解根本不会知道要往这些方向改。AI 不会主动帮你考虑“如果任务跑了一半挂了怎么办”“如果重复执行了怎么办”。这些判断只能靠人。5.3 验证用边界场景而不是正常流程来验收这个项目里最有用的一段验证是用异常场景来验收。我们构造了几类模拟数据目标库中已经存在同主键数据验证是否触发更新源库某个字段为空验证转换函数是否报错目标库写入中途断网验证任务重试后是否丢数据同一个时间范围被触发两次验证最终数据是否一致AI 生成初版时这些场景大部分都挂了。但在我们补齐可靠性设计后这些问题逐一消失。最终上线的版本代码有一半以上是 AI 生成的但真正让它能上线的是我们提前定义好的边界、验证标准和重试策略。这个案例很能说明问题AI 不是让工程师失业而是让工程师从“写代码”退后一步变成定义问题、设计验证、兜底异常的角色。如果你能做好这些事AI 会变成你手里最趁手的工具如果做不好它只会让错误以更快的速度出现。5.4 这类任务可以参考的排查链路如果 AI 生成的代码在实际运行中出问题我一般按这个顺序排查先确认现象是报错、卡住、无输出还是输出结果不对。再看输入数据格式、字段名、编码、文件路径、时间范围是否符合预期。再看环境依赖版本、Python 环境、数据库连接、权限、磁盘空间、网络。再看参数并发数、批量大小、超时时间、重试次数、日志级别。再看实现AI 生成的代码是否有不合理的假设比如默认字段非空、默认外部服务永不超时。最后看边界是不是这个场景本来就超出该工具的设计范围应该改走另一个系统。在排查 AI 生成代码的问题时不要急着改代码先确认问题出在哪一层。很多问题不是代码逻辑错了而是输入、环境或参数没有对齐。把顺序理清楚能省掉大量无效修改。建议给 AI 生成的代码加日志时尽量保留原始输入和输出上下文。靠日志判断数据流比靠肉眼看代码快得多。6. 长期来看AI 编码会改变工程师的成长路径6.1 初级工作被压缩但判断力变得更加稀缺如果只看“写代码”这件事AI 确实在压缩初级工程师的生存空间。过去需要通过大量编码练习积累的经验现在可能只需要一个不错的提示词。但这不代表初级工程师没有价值而是价值重心变了你不再靠代码量证明自己而是靠对问题判断的准确性。这意味着未来的工程师如果只会写代码会很危险但如果能通过 AI 快速验证想法、快速发现系统脆弱点、快速把混乱需求变成可执行方案那么你的价值反而更高。因为 AI 让验证成本变低你可以做更多以前因为成本太高而不敢尝试的探索。我觉得这种变化对新手其实更友好的地方在于你可以用 AI 写出很多候选方案然后逐个测试观察外部表现再回头理解内部实现。学习路径被压缩了但理解深度仍然取决于你是否愿意追问“为什么”。如果只是把 AI 输出当最终答案那确实不会成长代码能力还会退化。6.2 判断力来自哪里真实的失败经验这可能是 AI 时代最反直觉的一点既然 AI 能帮你避免很多错误为什么还要去踩坑因为如果你没有经历过线上故障、数据丢失、并发并发竞态、依赖升级踩雷就很难在需求评审时提前识别风险。AI 可以根据提示词生成“看起来很可靠”的代码但它不能替代你对真实世界的体感。可靠性系统的设计经验只能来自一次次故障复盘和事后改进。我的建议是即使有 AI 辅助也要刻意保留一些“深挖”的习惯。比如 AI 生成了一段代码你可以问它为什么这样实现有没有更稳妥的写法哪些分支是凭假设补出来的。这个过程慢但对长期判断力很有价值。6.3 团队学习机制用案例库取代个人经验当 AI 编码变成常态团队不能只依赖资深工程师的个人经验。最好把线上故障、发现问题、解决过程沉淀成案例库作为下一次 AI 提示词的约束来源。这套机制不复杂就是三件事记录问题现象和根因写清楚解决思路和验证方式把可复用的约束加入项目级提示词坚持做下去AI 在团队里的表现会越来越稳定。因为它不再只依赖通用大模型的常识而是结合了你们团队自己的业务经验。这么看 AI 没有让人的经验贬值反而让“把经验显性化”这件事变得更加值得投入。6.4 一个框架新的日常开发循环最后整理一个我认为比较适合 AI 编码时代的日常开发循环也算是对整篇内容的方法论收束。这个循环叫「定、验、生、查、测、记」。定先定义问题和边界明确验收标准和约束。验先写关键测试用例或验证场景作为 AI 输出的标尺。生让 AI 基于清晰上下文生成代码。查人工检查代码是否符合约定重点看异常路径和隐藏假设。测在真实环境或接近真实环境里验证不只跑通过用例还要看日志和性能。记把这次发现的问题、约定、经验和教训记录下来更新提示词和决策记录。这个循环不追求每一步都做得很重但每一步都不能缺失。尤其是“定”和“验”这两步直接决定了后面 AI 生成代码的质量。如果这两步偷懒后面所有环节都会还债。核心判断放在最后说一遍AI 让编码变廉价但这只是把工程瓶颈从“写代码”推向了“定标准和保可靠”。真正稀缺的不再是代码生产能力而是判断力、验收能力、可靠性和团队协作质量。AI Engineer 的未来不是写更多代码而是成为那个知道“什么不能写、什么要优先验证、什么上线前必须检查”的人。