上个月我去一家做供应链 SaaS 的公司做技术评审CTO 上来第一句话就问AI Coding 这么火我们到底该不该全面铺开他身后的大屏上投着一条演示——输入一段自然语言IDE 里哗啦啦冒出一大片代码会议室里有人已经开始鼓掌。我泼了盆冷水这个演示只能证明 Copilot 很会用 Markdown 写注释证明不了你的团队已经准备好了 AI Coding。事实上那家公司后来全量铺开的前两周PR 合并速度确实快了但主干分支的构建失败率也翻了快一倍。这篇想聊的是我这一年多反复在企业里观察、实践并踩过的坑AI Coding 真正改变的到底是什么。答案和大多数 PPT 里说的不一样——这不是写代码速度的问题而是需求到代码的距离、质量的定义、以及工程师的职责边界这三件事被彻底重写了。如果你正在做技术选型、带团队评估 AI Coding或者只是对那几个热搜问题感兴趣代码生成规范、AI Coding 工程师算不算人工智能工程师、代码质量会不会下降这篇文章应该能给你一份比热搜完整得多的答案。1. 先拆掉一个执念AI Coding 不是让 AI 替人写代码很多团队引入 AI Coding 的方式从一开始就跑偏了。他们以为买了一台自动写代码机等于雇了一群不用发工资的初级程序员。这个执念不拆掉后面所有环节都会变形。1.1 我在企业里看到的三种伪 AI Coding第一种装了插件就当用上了 AI Coding。全团队开权限、开会员IDE 里多了一个能自动补全的对话框需求流程、评审流程、测试流程一概不动。三周之后代码库开始出现大量看起来逻辑完整但没人说得清为什么这么写的代码代码量涨了 40%缺陷密度没降反升。这不是 AI Coding 的问题这是把 AI 当输入法用——自动补全给你补出一个错别字连篇的文档你还直接发出去了。第二种把对话式工具当翻译器。我见过不止一个业务侧负责人拿着自然语言往对话框里一贴帮我把这个模块改成微服务架构AI 确实给了方案但它在没有全局上下文的情况下做了断章取义的重构建议。这种用法最危险因为它产出的东西看起来非常专业实际上全是没验证的假设。你不是在使用 AI Coding你是在制造技术债。第三种买了AI 开发平台但只接入了代码生成这一环。测试还是人工补、CI 还是手动触发、代码评审还是从头看到尾。等于你给一个工人买了两倍速的缝纫机却还是让他手工量体裁衣——快是快了但快出来的部分没有任何质量约束路径最后反而拖慢交付。1.2 真正跑通的是人机结对不是机器代工我给这家公司的建议是把 AI Coding 想象成导航而不是自动驾驶。导航不会替你开车它负责给路线、提示拥堵、在你走错的时候重新规划司机仍然要掌握方向盘判断路况对一车人的安全负责。AI Coding 在企业里的正确姿势本质上是一种人机结对AI 负责把已知模式快速落成初稿生成样板代码、单元测试、文档注释在短时间内产出大量可预测的编码工作。人负责定义边界、拆解任务、设定验收标准、审查差异、修复 AI 的错误假设以及承担最终的系统责任。我为什么强调结对而不是代工因为 AI 模型的能力边界是概率性的它擅长看起来对而不是保证对。企业代码库恰恰是必须对的地方。一个订单多扣一笔钱一次权限校验漏了一条错误日志没打这些在 demo 里都不是问题在生产环境里都是事故。所以凡是把 AI 当外包程序员而不是结对同事的团队大概率会经历一波虚假繁荣然后在某个深夜的 on-call 电话里醒来。2. 最先被改写的不是 IDE而是需求到交付的链路如果只挑一个最先被改变的环节我会选需求到代码这一段而不是编辑器体验。因为 AI Coding 把需求描述变成了流水线上的第一道工序——这道工序的质量直接决定了后面所有生成代码的成色。2.1 需求描述成为新的核心资产以前写需求讲究人能看懂。现在写需求讲究人能看懂、AI 能执行、测试能验证。同样的需求两种写法的差距比大多数人想象的大得多。维度传统需求描述AI-ready 需求描述筛选订单用户可以在订单列表按条件筛选订单列表支持按状态、金额区间、下单时间筛选默认按下单时间倒序金额区间边界包含端点无结果时展示空态图筛选条件与权限范围取交集错误处理保存失败时提示用户保存失败时区分网络错误与校验错误网络错误可重试校验错误定位到具体字段所有错误需输出结构化日志边界条件分页展示每页 20 条禁止一次查询超过 1000 条超出时必须二次确认并限制导出并发修改时以后提交为准并提示冲突为什么会差这么多因为大模型生成代码的质量上限基本由你给它的上下文质量决定。你喂给它五行的模糊需求它回你十行的平庸代码你喂给它结构化的行为规格它才能产出带边界、带异常处理的完整实现。这不只是prompt 技巧这是一个工程问题需求描述已经变成了新的编译产物它需要被评审、被版本化、被测试覆盖。我在团队里要求所有进入 AI 编码环节的用户故事必须包含三件事验收条件、约束条件、至少一个明确的反例。验收条件告诉 AI什么算做完约束条件告诉它什么不能做反例告诉它别碰什么边界。很多团队说 AI 生成的代码质量差我让他们把需求文档拿过来一看——反例一条都没有边界全靠 AI 自己猜质量差是必然的。2.2 评审重点从看代码变成看差异与意图代码评审这件事被 AI Coding 冲击得最厉害。以前一个 PR 几百行人眼可以逐行看AI 进场之后一个 PR 动辄上千行逐行看既不可能也没必要。评审的重点必须从这段代码写得对不对转向四个问题这段代码的意图是否与验收条件一致有没有 AI 幻觉模式调用了不存在的 API、引入了并不存在的库、把已有工具函数又实现了一遍边界和失败路径是否覆盖还是只实现了 happy path安全相关逻辑权限、金额、日志脱敏有没有被 AI顺手简化这四个问题对应的是一套新的评审 checklist可以做成 PR 模板的必填项。我们的做法是AI 生成的代码必须标注生成来源评审人在 diff 视图里首先看意图声明再看关键风险点最后才看实现细节。80% 的常规代码其实不需要逐行读但 20% 的核心逻辑事务、权限、并发必须人工盯死。这个比例可以按团队风险偏好调整但原则不变——AI 生成 无差别人工审查 既浪费人工又漏掉风险。2.3 发布节奏、回滚策略与 CI 流水线的新约束当生成代码的效率上来了测试代码也能跟着批量生成单元覆盖率不再是发布瓶颈的时候团队的自然冲动是把发布频率往上拉。这本身是好事但它会暴露另一组短板环境稳定性、数据质量、回滚能力。我的建议是CI 流水线要单独加一道AI 生成检查层和传统静态检查、单元测试并排跑。这道检查至少包含三件事识别代码中的 AI 生成标记、扫描危险调用模式硬编码密钥、绕过权限校验、异常吞掉、比对生成的 diff 是否超出任务声明的范围。检查通过后才进入人工评审。回滚策略也是一样。过去回滚是把上一个版本重新部署现在代码迭代速度翻倍版本之间的差异越来越大回滚更应该变成切流量到上一个稳定版本或者按特性开关回退。哪个团队先想清楚这件事哪个团队才能安心享受高发布频率而不是每周都在做紧急回滚。3. 代码质量会不会下降会除非把质量和规范重新定义一遍这是热搜上吵得最凶的问题也是我必须给一个明确答案的问题会下降。只要不加约束AI Coding 一定会让代码质量下降。但我要补一句——下降的不是模型能力而是团队管理 AI 产物的能力。这就好比复印机不会让文档质量下降但全员乱复印、不校对、直接盖章发出的文档质量一定会稀烂。3.1 为什么生成一时爽merge 火葬场我看到的质量下降通常走这样一条路径第一周团队惊叹于生成速度合并大量代码第二周开始出现莫名其妙的重复实现和错误 API 调用第三周有人在一个深夜发现某个生成的事务处理漏了回滚第四周CTO 出来宣布AI Coding 试点暂停。问题不在AI 写错了而在于团队把生成代码的验收门槛设置得和手写代码一样——甚至更低。手写代码的人至少要懂业务逻辑AI 生成代码的时候它只是基于概率补全了最像样的下文。它不知道你的订单表有多大数据量不知道你的交易系统对一致性有多敏感不知道你的审计合规要求。这些知识必须通过规范和测试传导给模型否则它就是在没有业务常识的情况下替你写代码。3.2 代码生成规范示例约束对象是人和模型的共同界面很多团队听到代码生成规范以为就是写一堆 prompt 咒语这是误解。真正的生成规范是人和模型之间的共同界面——它约束人怎么描述需求也约束模型怎么输出代码。下面这个例子来自我们某个后端团队的实践可以直接抄作业{ project_context: { tech_stack: Java 17 Spring Boot 3 PostgreSQL, architecture_constraints: 禁止在 Service 层直接操作 Redis禁止循环内查库, existing_utils: [OrderStatusUtil, MoneyUtil, QueryPageUtil] }, generation_rules: { naming: 遵循工程既有命名规范禁止自创缩写, error_handling: 业务异常必须抛 BizException禁止 RuntimeException 裸抛, logging: 关键状态变更必须打日志含 requestId禁止打印敏感字段, security: 所有写操作必须经过权限校验禁止拼接 SQL, tests: 每个新方法必须带至少一个成功用例和一个失败用例 }, forbidden_patterns: [ 不存在的第三方库, 重复实现已有工具类, 吞掉异常的 catch 块 ], definition_of_done: [ 单测通过, 静态检查通过, AI 生成标记已添加, 评审人确认意图匹配 ] }这份规范不是写在 wiki 里吃灰的而是要注入到每个任务的上下文中让模型在生成时看到它同时让评审人在验收时照着它逐条打勾。你会发现一个很有意思的结果规范约束的是共同界面所以人写需求的时候也变得更严谨了——因为你只有把边界写清楚模型才能输出符合规范的代码。规范不是用来限制生产力的是用来把概率正确收敛成工程正确的。3.3 让AI 生成可追踪、可度量、可回退很多团队最缺的不是生成能力而是对生成产物的可观测性。代码库里有几成是 AI 写的、哪些模块生成比例偏高、生成代码的缺陷率是多少、哪次改动引入的不稳定这些数据如果一团黑质量下降就只是时间问题。我们的做法有三步难度不高但非常有效。第一所有 AI 生成的代码自动加一个签名注释包含模型、生成时间和触发任务 ID。第二CI 里加一个扫描任务统计每次合并中 AI 生成代码的占比超过阈值比如核心模块超过 50%的 PR 强制要求人工评审。第三把缺陷单关联到生成标记上每月出一份AI 生成代码缺陷密度对比表。这一套跑下来团队对AI 到底靠不靠谱就有了数据支撑而不是靠感觉吵架。还可以用一些低成本的手段做防御性检查。比如基于正则或语义规则扫描危险模式硬编码密钥、gitleaks 类工具可以顺便跑用 diff 工具专门看生成代码是否动了不该动的范围。质量治理的本质是让每一次AI 输出都有迹可循能回溯、能分析、能改进。3.4 用测试前置把质量门禁焊死在生成那一刻在所有质量手段里我体会最深、也最推荐的一招是测试前置。具体做法是让 AI 生成代码之前人先写出测试用例AI 的产出标准不是通过编译而是通过这套测试。我观察过一个真实团队的做法同一批订单模块的需求一半模块采用AI 直接生成 事后人工补测试另一半采用人先写测试 AI 生成实现。两个月后前者的缺陷密度比项目平均水平高了不少后者反而低于平均水平。原因不难理解测试用例本质上是需求的可执行版本当 AI 以测试为约束生成代码时它的幻觉空间被大幅压缩当测试是事后补的AI 已经放飞过一轮了人只是在补救。所以我的建议是把不带测试的生成代码不允许合并设为硬性门槛而不是软性建议。这件事在 AI Coding 时代变得更加可行了因为 AI 生成测试代码的能力很强人要做的是审查测试是否有效、是否覆盖了边界而不是从零写测试。质量门禁不是拦路虎它是让 AI 的生成效率真正转化为交付质量的那道闸门。4. AI Coding 工程师到底在做什么岗位与技能的真实拆解热搜里有一个问题AI Coding 工程师算不算人工智能工程师答案大概率让很多人失望——它更接近人工智能辅助软件工程工程师而不是训练模型、调参数那种人工智能工程师。岗位名字里有 AI不代表懂 Transformer就像数据工程师不等于算法科学家。4.1 新岗位不是提示词专家企业里真正能打的 AI Coding 工程师日常花在写提示词上的时间不到两成。大部分时间在做四件事上下文工程把模糊的业务需求加工成结构化、可验证的行为规格准备好让模型理解的信息包。验收测试设计写测试用例定义质量边界把模型输出不可控变成测试结果可控。产物审查对 AI 生成的 diff 做意图校验和风险识别拦截幻觉代码修复错误假设。规范维护根据事故复盘和缺陷数据持续更新生成规范、禁止模式、模板库让团队的经验沉淀成可复用的约束。这四件事没有一件是会聊天就能做的。它需要扎实的软件工程功底需要懂领域建模需要知道事务、并发、缓存、安全这些底层的代价在哪里。所以我对那个热搜问题的回答是AI Coding 工程师本质上是更懂 AI 能力边界的高级软件工程师而不是换个方向的人工智能工程师。前者是在用模型做工程后者是在做模型本身两条赛道。4.2 原有工程师的幸存者技能AI Coding 进入企业之后原有岗位一定会分化。最先被冲击的是重复性最高的部分样板代码、CRUD 生成、数据搬运、文档和注释书写。这些活计过去让新人练手现在模型几秒钟就能完成。那留下来的或者说反而增值的技能是什么我自己的观察是这样一组系统分解与领域建模能决定哪些东西可以分给 AI、哪些必须人肉守住的能力。代码评审与质量判断识别 AI 幻觉、评估设计意图、发现边界漏洞的能力。根因分析与调试系统出错时能把问题定位到具体链路而不是只会重新生成一遍代码。性能、事务、安全和容量这些非功能需求的判断力这些恰恰是模型最容易忽略、也最难自动验证的部分。这组技能的共同点是它们都建立在对系统整体负责的思维上。AI 可以帮你写一个函数但不能帮你决定这个函数该不该存在、放在哪个层次、和隔壁模块怎么协作。工程师的价值正在从生成代码迁移到确定边界和承担责任。4.3 考核和晋升标准必须跟着改如果岗位职责变了考核体系还停留在老维度组织一定会出现扭曲。最典型的扭曲是还在按代码行数和PR 数量考核工程师结果全员疯狂让 AI 生成大块代码行数是涨了质量没人负责。我们调整考核时主要改了三个指标从产出量转向交付效果看需求是否按期转化为线上运行的功能看核心链路可用性看缺陷密度。从写了多少测试转向测试是否拦住了缺陷统计线上事故有没有被测试提前发现这比测试覆盖率数字诚实得多。从个人代码贡献转向系统质量贡献评审质量、规范贡献、上下文工程模板沉淀都进入晋升答辩的考察范围。晋升答辩的问题清单也要换血。过去常问你负责的模块怎么设计的现在要加一句你怎么确保 AI 生成的代码符合你的设计意图出问题时你怎么定位。问法一变团队的行为就会跟着变。5. 那些没写进 PPT 的落地成本和推进顺序最后聊点务实的AI Coding 进入企业的隐性成本以及我建议的推进顺序。这些东西几乎不会出现在厂商的演示片里但恰恰决定了一个团队能不能把 AI Coding 用好。5.1 看得见的成本上下文、算力与数据治理第一块成本是上下文维护。AI 生成代码的质量依赖上下文而高质量上下文的编写和评审非常耗时。以前一个需求写两行现在可能要写两屏。这不是流程繁琐这是把原本在程序员脑子里的隐性知识变成了显性的工程资产。短期看效率是变慢的但它换来的是人员流动时业务知识不流失长期一定是划算的。第二块是模型调用与算力成本。企业级使用很少是免费的按 token 计费的模式下提示词越长、生成的候选越多账单越厚。我见过一个团队为了多试几次让 AI 为同一个任务生成五个版本再挑一个月度账单翻了四倍最终性价比极差。合理的做法是控制生成轮次把上下文精炼到必要信息让模型一次生成、人工精修而不是无限试错。第三块是数据治理。企业代码是有资产属性的核心代码进入公共模型服务之前必须做脱敏和权限评估。私有化部署和 API 调用之间不是单纯的价格选择而是对代码资产控制权的选择。这块没有一个标准答案但有一条原则必须提前定哪些模块允许进模型、哪些绝对不允许要在试点前就划定而不是等代码泄露了再补齐规则。5.2 我建议的落地顺序先低风险先打质量门禁先练审查者如果团队问我全面铺开之前先干什么我的建议通常是三条按顺序走第一从低风险模块开始。内部工具、测试代码、文档生成、非核心业务的样板接口这些地方试错成本低适合让团队先建立手感。核心交易链路、权限系统、资金处理至少在前两个月不要碰 AI 生成只允许用 AI 写测试和辅助审查。第二先把质量门禁打出来再谈规模化。生成规范、CI 检查、测试前置、生成标记这些基础设施不建好规模越大风险越大。门禁的优先级高于接入的人数也高于模型版本的选择。第三先训练审查者再培训使用者。团队里总有一部分人擅长结构化思维和代码评审让这批人先吃透规范的用法再让他们去带其他人。比全员铺开、人人乱试要稳得多。我还建议每个试点团队做一个 6 到 8 周的基线对比同样的需求统计采用 AI Coding 前后的交付周期、缺陷密度、返工次数和工程师主观负荷。这个基线数据不只是为了向管理层汇报更是为了让团队自己的迭代有参照系——没有基线你根本说不清变好了还是变坏了。我自己的体会是AI Coding 进企业真正的分水岭不在 IDE 里而在每个工程师怎么定义自己的工作。这一年多走下来我最大的变化不是写代码变快了而是我几乎把一半的精力花在了把需求写清楚上——因为模型逼着我承认一个我自己都没想清楚的边界它也不可能替我守住。最后分享一个实战小技巧当你不知道该怎么给 AI 描述一个改动时先动手写它的测试用例写完用例提示词自然就清晰了。这个方法我推荐给每一个刚开始用 AI Coding 的团队比任何 prompt 教程都管用。 
长河君 · 2026/11/3 16:10:05 · 阅读 1.2k AI Coding 不是替人写代码：人机结对、需求重塑与质量门禁
上个月我去一家做供应链 SaaS 的公司做技术评审CTO 上来第一句话就问AI Coding 这么火我们到底该不该全面铺开他身后的大屏上投着一条演示——输入一段自然语言IDE 里哗啦啦冒出一大片代码会议室里有人已经开始鼓掌。我泼了盆冷水这个演示只能证明 Copilot 很会用 Markdown 写注释证明不了你的团队已经准备好了 AI Coding。事实上那家公司后来全量铺开的前两周PR 合并速度确实快了但主干分支的构建失败率也翻了快一倍。这篇想聊的是我这一年多反复在企业里观察、实践并踩过的坑AI Coding 真正改变的到底是什么。答案和大多数 PPT 里说的不一样——这不是写代码速度的问题而是需求到代码的距离、质量的定义、以及工程师的职责边界这三件事被彻底重写了。如果你正在做技术选型、带团队评估 AI Coding或者只是对那几个热搜问题感兴趣代码生成规范、AI Coding 工程师算不算人工智能工程师、代码质量会不会下降这篇文章应该能给你一份比热搜完整得多的答案。1. 先拆掉一个执念AI Coding 不是让 AI 替人写代码很多团队引入 AI Coding 的方式从一开始就跑偏了。他们以为买了一台自动写代码机等于雇了一群不用发工资的初级程序员。这个执念不拆掉后面所有环节都会变形。1.1 我在企业里看到的三种伪 AI Coding第一种装了插件就当用上了 AI Coding。全团队开权限、开会员IDE 里多了一个能自动补全的对话框需求流程、评审流程、测试流程一概不动。三周之后代码库开始出现大量看起来逻辑完整但没人说得清为什么这么写的代码代码量涨了 40%缺陷密度没降反升。这不是 AI Coding 的问题这是把 AI 当输入法用——自动补全给你补出一个错别字连篇的文档你还直接发出去了。第二种把对话式工具当翻译器。我见过不止一个业务侧负责人拿着自然语言往对话框里一贴帮我把这个模块改成微服务架构AI 确实给了方案但它在没有全局上下文的情况下做了断章取义的重构建议。这种用法最危险因为它产出的东西看起来非常专业实际上全是没验证的假设。你不是在使用 AI Coding你是在制造技术债。第三种买了AI 开发平台但只接入了代码生成这一环。测试还是人工补、CI 还是手动触发、代码评审还是从头看到尾。等于你给一个工人买了两倍速的缝纫机却还是让他手工量体裁衣——快是快了但快出来的部分没有任何质量约束路径最后反而拖慢交付。1.2 真正跑通的是人机结对不是机器代工我给这家公司的建议是把 AI Coding 想象成导航而不是自动驾驶。导航不会替你开车它负责给路线、提示拥堵、在你走错的时候重新规划司机仍然要掌握方向盘判断路况对一车人的安全负责。AI Coding 在企业里的正确姿势本质上是一种人机结对AI 负责把已知模式快速落成初稿生成样板代码、单元测试、文档注释在短时间内产出大量可预测的编码工作。人负责定义边界、拆解任务、设定验收标准、审查差异、修复 AI 的错误假设以及承担最终的系统责任。我为什么强调结对而不是代工因为 AI 模型的能力边界是概率性的它擅长看起来对而不是保证对。企业代码库恰恰是必须对的地方。一个订单多扣一笔钱一次权限校验漏了一条错误日志没打这些在 demo 里都不是问题在生产环境里都是事故。所以凡是把 AI 当外包程序员而不是结对同事的团队大概率会经历一波虚假繁荣然后在某个深夜的 on-call 电话里醒来。2. 最先被改写的不是 IDE而是需求到交付的链路如果只挑一个最先被改变的环节我会选需求到代码这一段而不是编辑器体验。因为 AI Coding 把需求描述变成了流水线上的第一道工序——这道工序的质量直接决定了后面所有生成代码的成色。2.1 需求描述成为新的核心资产以前写需求讲究人能看懂。现在写需求讲究人能看懂、AI 能执行、测试能验证。同样的需求两种写法的差距比大多数人想象的大得多。维度传统需求描述AI-ready 需求描述筛选订单用户可以在订单列表按条件筛选订单列表支持按状态、金额区间、下单时间筛选默认按下单时间倒序金额区间边界包含端点无结果时展示空态图筛选条件与权限范围取交集错误处理保存失败时提示用户保存失败时区分网络错误与校验错误网络错误可重试校验错误定位到具体字段所有错误需输出结构化日志边界条件分页展示每页 20 条禁止一次查询超过 1000 条超出时必须二次确认并限制导出并发修改时以后提交为准并提示冲突为什么会差这么多因为大模型生成代码的质量上限基本由你给它的上下文质量决定。你喂给它五行的模糊需求它回你十行的平庸代码你喂给它结构化的行为规格它才能产出带边界、带异常处理的完整实现。这不只是prompt 技巧这是一个工程问题需求描述已经变成了新的编译产物它需要被评审、被版本化、被测试覆盖。我在团队里要求所有进入 AI 编码环节的用户故事必须包含三件事验收条件、约束条件、至少一个明确的反例。验收条件告诉 AI什么算做完约束条件告诉它什么不能做反例告诉它别碰什么边界。很多团队说 AI 生成的代码质量差我让他们把需求文档拿过来一看——反例一条都没有边界全靠 AI 自己猜质量差是必然的。2.2 评审重点从看代码变成看差异与意图代码评审这件事被 AI Coding 冲击得最厉害。以前一个 PR 几百行人眼可以逐行看AI 进场之后一个 PR 动辄上千行逐行看既不可能也没必要。评审的重点必须从这段代码写得对不对转向四个问题这段代码的意图是否与验收条件一致有没有 AI 幻觉模式调用了不存在的 API、引入了并不存在的库、把已有工具函数又实现了一遍边界和失败路径是否覆盖还是只实现了 happy path安全相关逻辑权限、金额、日志脱敏有没有被 AI顺手简化这四个问题对应的是一套新的评审 checklist可以做成 PR 模板的必填项。我们的做法是AI 生成的代码必须标注生成来源评审人在 diff 视图里首先看意图声明再看关键风险点最后才看实现细节。80% 的常规代码其实不需要逐行读但 20% 的核心逻辑事务、权限、并发必须人工盯死。这个比例可以按团队风险偏好调整但原则不变——AI 生成 无差别人工审查 既浪费人工又漏掉风险。2.3 发布节奏、回滚策略与 CI 流水线的新约束当生成代码的效率上来了测试代码也能跟着批量生成单元覆盖率不再是发布瓶颈的时候团队的自然冲动是把发布频率往上拉。这本身是好事但它会暴露另一组短板环境稳定性、数据质量、回滚能力。我的建议是CI 流水线要单独加一道AI 生成检查层和传统静态检查、单元测试并排跑。这道检查至少包含三件事识别代码中的 AI 生成标记、扫描危险调用模式硬编码密钥、绕过权限校验、异常吞掉、比对生成的 diff 是否超出任务声明的范围。检查通过后才进入人工评审。回滚策略也是一样。过去回滚是把上一个版本重新部署现在代码迭代速度翻倍版本之间的差异越来越大回滚更应该变成切流量到上一个稳定版本或者按特性开关回退。哪个团队先想清楚这件事哪个团队才能安心享受高发布频率而不是每周都在做紧急回滚。3. 代码质量会不会下降会除非把质量和规范重新定义一遍这是热搜上吵得最凶的问题也是我必须给一个明确答案的问题会下降。只要不加约束AI Coding 一定会让代码质量下降。但我要补一句——下降的不是模型能力而是团队管理 AI 产物的能力。这就好比复印机不会让文档质量下降但全员乱复印、不校对、直接盖章发出的文档质量一定会稀烂。3.1 为什么生成一时爽merge 火葬场我看到的质量下降通常走这样一条路径第一周团队惊叹于生成速度合并大量代码第二周开始出现莫名其妙的重复实现和错误 API 调用第三周有人在一个深夜发现某个生成的事务处理漏了回滚第四周CTO 出来宣布AI Coding 试点暂停。问题不在AI 写错了而在于团队把生成代码的验收门槛设置得和手写代码一样——甚至更低。手写代码的人至少要懂业务逻辑AI 生成代码的时候它只是基于概率补全了最像样的下文。它不知道你的订单表有多大数据量不知道你的交易系统对一致性有多敏感不知道你的审计合规要求。这些知识必须通过规范和测试传导给模型否则它就是在没有业务常识的情况下替你写代码。3.2 代码生成规范示例约束对象是人和模型的共同界面很多团队听到代码生成规范以为就是写一堆 prompt 咒语这是误解。真正的生成规范是人和模型之间的共同界面——它约束人怎么描述需求也约束模型怎么输出代码。下面这个例子来自我们某个后端团队的实践可以直接抄作业{ project_context: { tech_stack: Java 17 Spring Boot 3 PostgreSQL, architecture_constraints: 禁止在 Service 层直接操作 Redis禁止循环内查库, existing_utils: [OrderStatusUtil, MoneyUtil, QueryPageUtil] }, generation_rules: { naming: 遵循工程既有命名规范禁止自创缩写, error_handling: 业务异常必须抛 BizException禁止 RuntimeException 裸抛, logging: 关键状态变更必须打日志含 requestId禁止打印敏感字段, security: 所有写操作必须经过权限校验禁止拼接 SQL, tests: 每个新方法必须带至少一个成功用例和一个失败用例 }, forbidden_patterns: [ 不存在的第三方库, 重复实现已有工具类, 吞掉异常的 catch 块 ], definition_of_done: [ 单测通过, 静态检查通过, AI 生成标记已添加, 评审人确认意图匹配 ] }这份规范不是写在 wiki 里吃灰的而是要注入到每个任务的上下文中让模型在生成时看到它同时让评审人在验收时照着它逐条打勾。你会发现一个很有意思的结果规范约束的是共同界面所以人写需求的时候也变得更严谨了——因为你只有把边界写清楚模型才能输出符合规范的代码。规范不是用来限制生产力的是用来把概率正确收敛成工程正确的。3.3 让AI 生成可追踪、可度量、可回退很多团队最缺的不是生成能力而是对生成产物的可观测性。代码库里有几成是 AI 写的、哪些模块生成比例偏高、生成代码的缺陷率是多少、哪次改动引入的不稳定这些数据如果一团黑质量下降就只是时间问题。我们的做法有三步难度不高但非常有效。第一所有 AI 生成的代码自动加一个签名注释包含模型、生成时间和触发任务 ID。第二CI 里加一个扫描任务统计每次合并中 AI 生成代码的占比超过阈值比如核心模块超过 50%的 PR 强制要求人工评审。第三把缺陷单关联到生成标记上每月出一份AI 生成代码缺陷密度对比表。这一套跑下来团队对AI 到底靠不靠谱就有了数据支撑而不是靠感觉吵架。还可以用一些低成本的手段做防御性检查。比如基于正则或语义规则扫描危险模式硬编码密钥、gitleaks 类工具可以顺便跑用 diff 工具专门看生成代码是否动了不该动的范围。质量治理的本质是让每一次AI 输出都有迹可循能回溯、能分析、能改进。3.4 用测试前置把质量门禁焊死在生成那一刻在所有质量手段里我体会最深、也最推荐的一招是测试前置。具体做法是让 AI 生成代码之前人先写出测试用例AI 的产出标准不是通过编译而是通过这套测试。我观察过一个真实团队的做法同一批订单模块的需求一半模块采用AI 直接生成 事后人工补测试另一半采用人先写测试 AI 生成实现。两个月后前者的缺陷密度比项目平均水平高了不少后者反而低于平均水平。原因不难理解测试用例本质上是需求的可执行版本当 AI 以测试为约束生成代码时它的幻觉空间被大幅压缩当测试是事后补的AI 已经放飞过一轮了人只是在补救。所以我的建议是把不带测试的生成代码不允许合并设为硬性门槛而不是软性建议。这件事在 AI Coding 时代变得更加可行了因为 AI 生成测试代码的能力很强人要做的是审查测试是否有效、是否覆盖了边界而不是从零写测试。质量门禁不是拦路虎它是让 AI 的生成效率真正转化为交付质量的那道闸门。4. AI Coding 工程师到底在做什么岗位与技能的真实拆解热搜里有一个问题AI Coding 工程师算不算人工智能工程师答案大概率让很多人失望——它更接近人工智能辅助软件工程工程师而不是训练模型、调参数那种人工智能工程师。岗位名字里有 AI不代表懂 Transformer就像数据工程师不等于算法科学家。4.1 新岗位不是提示词专家企业里真正能打的 AI Coding 工程师日常花在写提示词上的时间不到两成。大部分时间在做四件事上下文工程把模糊的业务需求加工成结构化、可验证的行为规格准备好让模型理解的信息包。验收测试设计写测试用例定义质量边界把模型输出不可控变成测试结果可控。产物审查对 AI 生成的 diff 做意图校验和风险识别拦截幻觉代码修复错误假设。规范维护根据事故复盘和缺陷数据持续更新生成规范、禁止模式、模板库让团队的经验沉淀成可复用的约束。这四件事没有一件是会聊天就能做的。它需要扎实的软件工程功底需要懂领域建模需要知道事务、并发、缓存、安全这些底层的代价在哪里。所以我对那个热搜问题的回答是AI Coding 工程师本质上是更懂 AI 能力边界的高级软件工程师而不是换个方向的人工智能工程师。前者是在用模型做工程后者是在做模型本身两条赛道。4.2 原有工程师的幸存者技能AI Coding 进入企业之后原有岗位一定会分化。最先被冲击的是重复性最高的部分样板代码、CRUD 生成、数据搬运、文档和注释书写。这些活计过去让新人练手现在模型几秒钟就能完成。那留下来的或者说反而增值的技能是什么我自己的观察是这样一组系统分解与领域建模能决定哪些东西可以分给 AI、哪些必须人肉守住的能力。代码评审与质量判断识别 AI 幻觉、评估设计意图、发现边界漏洞的能力。根因分析与调试系统出错时能把问题定位到具体链路而不是只会重新生成一遍代码。性能、事务、安全和容量这些非功能需求的判断力这些恰恰是模型最容易忽略、也最难自动验证的部分。这组技能的共同点是它们都建立在对系统整体负责的思维上。AI 可以帮你写一个函数但不能帮你决定这个函数该不该存在、放在哪个层次、和隔壁模块怎么协作。工程师的价值正在从生成代码迁移到确定边界和承担责任。4.3 考核和晋升标准必须跟着改如果岗位职责变了考核体系还停留在老维度组织一定会出现扭曲。最典型的扭曲是还在按代码行数和PR 数量考核工程师结果全员疯狂让 AI 生成大块代码行数是涨了质量没人负责。我们调整考核时主要改了三个指标从产出量转向交付效果看需求是否按期转化为线上运行的功能看核心链路可用性看缺陷密度。从写了多少测试转向测试是否拦住了缺陷统计线上事故有没有被测试提前发现这比测试覆盖率数字诚实得多。从个人代码贡献转向系统质量贡献评审质量、规范贡献、上下文工程模板沉淀都进入晋升答辩的考察范围。晋升答辩的问题清单也要换血。过去常问你负责的模块怎么设计的现在要加一句你怎么确保 AI 生成的代码符合你的设计意图出问题时你怎么定位。问法一变团队的行为就会跟着变。5. 那些没写进 PPT 的落地成本和推进顺序最后聊点务实的AI Coding 进入企业的隐性成本以及我建议的推进顺序。这些东西几乎不会出现在厂商的演示片里但恰恰决定了一个团队能不能把 AI Coding 用好。5.1 看得见的成本上下文、算力与数据治理第一块成本是上下文维护。AI 生成代码的质量依赖上下文而高质量上下文的编写和评审非常耗时。以前一个需求写两行现在可能要写两屏。这不是流程繁琐这是把原本在程序员脑子里的隐性知识变成了显性的工程资产。短期看效率是变慢的但它换来的是人员流动时业务知识不流失长期一定是划算的。第二块是模型调用与算力成本。企业级使用很少是免费的按 token 计费的模式下提示词越长、生成的候选越多账单越厚。我见过一个团队为了多试几次让 AI 为同一个任务生成五个版本再挑一个月度账单翻了四倍最终性价比极差。合理的做法是控制生成轮次把上下文精炼到必要信息让模型一次生成、人工精修而不是无限试错。第三块是数据治理。企业代码是有资产属性的核心代码进入公共模型服务之前必须做脱敏和权限评估。私有化部署和 API 调用之间不是单纯的价格选择而是对代码资产控制权的选择。这块没有一个标准答案但有一条原则必须提前定哪些模块允许进模型、哪些绝对不允许要在试点前就划定而不是等代码泄露了再补齐规则。5.2 我建议的落地顺序先低风险先打质量门禁先练审查者如果团队问我全面铺开之前先干什么我的建议通常是三条按顺序走第一从低风险模块开始。内部工具、测试代码、文档生成、非核心业务的样板接口这些地方试错成本低适合让团队先建立手感。核心交易链路、权限系统、资金处理至少在前两个月不要碰 AI 生成只允许用 AI 写测试和辅助审查。第二先把质量门禁打出来再谈规模化。生成规范、CI 检查、测试前置、生成标记这些基础设施不建好规模越大风险越大。门禁的优先级高于接入的人数也高于模型版本的选择。第三先训练审查者再培训使用者。团队里总有一部分人擅长结构化思维和代码评审让这批人先吃透规范的用法再让他们去带其他人。比全员铺开、人人乱试要稳得多。我还建议每个试点团队做一个 6 到 8 周的基线对比同样的需求统计采用 AI Coding 前后的交付周期、缺陷密度、返工次数和工程师主观负荷。这个基线数据不只是为了向管理层汇报更是为了让团队自己的迭代有参照系——没有基线你根本说不清变好了还是变坏了。我自己的体会是AI Coding 进企业真正的分水岭不在 IDE 里而在每个工程师怎么定义自己的工作。这一年多走下来我最大的变化不是写代码变快了而是我几乎把一半的精力花在了把需求写清楚上——因为模型逼着我承认一个我自己都没想清楚的边界它也不可能替我守住。最后分享一个实战小技巧当你不知道该怎么给 AI 描述一个改动时先动手写它的测试用例写完用例提示词自然就清晰了。这个方法我推荐给每一个刚开始用 AI Coding 的团队比任何 prompt 教程都管用。