先说一个最近在项目里反复出现的情景：我用 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 的未来，不是写更多代码，而是成为那个知道“什么不能写、什么要优先验证、什么上线前必须检查”的人。
)
