AI Coding 这件事，我最早听到一个说法：像带着一个实习生干活。
这个比喻当时挺贴切。你得把需求拆细，边界讲清楚，时不时纠偏，还要预防它一本正经地写错东西。后来模型能力明显上来了，这个比喻就开始不准了。今天你如果还把 AI 当成一个只会补全样板代码的低阶助手，动作大概率会变形。它在很多局部任务上，已经更像一个执行力很强、知识面很宽、但稳定性很一般的高级工程师。它写得快，覆盖面大，愿意 24 小时连轴转，最大的问题不在勤奋，而在可信度。
这件事一旦放进团队环境里，问题马上就变了。不再是「能不能写代码」，而是「谁对结果负责」。
现在很多 AI Coding 用得多的团队可能已经出现了一个问题：开发人员自己都说不清 AI 到底写了什么，项目能跑，测试勉强过，线上暂时没炸，但整个系统已经开始黑盒化。代码库里到处是风格不一致的实现、边界模糊的封装、说不明白的依赖链、没人敢删的工具函数。大家嘴上说的是 vibe coding，实际落地很快就变成了 wish coding：我希望它是对的，我希望这段逻辑没坑，我希望下次出事故时还能找到人解释。
如果你带过技术团队，可能也遇到过类似局面。
你如果深入一线，参与每个细节，能获得越强控制感，但你会被细节拖死。今天盯需求，明天盯设计，后天盯代码，发布前再把链路捋一遍，管理者最后会退化成一个高配版救火队长。你如果完全不深入，只盯结果和报表，也会出事。周报很好看，效率数字很漂亮，线上指标暂时平稳，但你心里知道，很多东西已经不在掌控中。
管理上我们一般讲抓大放小，不盯每一行代码，不替工程师做执行层决策，但把几个关键控制点抓牢。需求评审、架构约束、关键实现的检查、上线前的验收，这几个点抓住了，系统就大概率还在掌控中；抓不住，团队再忙也只是热闹。把这个思路放到 AI Coding 上，基本同样成立。
当 AI 已经深度进入开发流程以后，技术负责人应该怎么管，工程师应该怎么用，团队应该在哪些地方建立制度，哪些地方故意放手，哪些地方必须强控。
角色变化
先说角色
哲学三问中，你是谁是第一个问题。
先把角色认知摆正。
AI 不是 IDE 里的自动补全增强版。它也不是一个真正意义上的「同事」。它更像一个可并行调用的高能力执行单元，特点比较明显：局部推理强，整体一致性弱；生成速度快，长期责任感为零；知道很多模式，理解你的真实业务上下文却高度依赖你喂给它的材料。但他的上下文窗口有限，当内容太多，注意力不集中时，它就开始一本正经的胡说八道。
这意味着，我们不能用管理普通工程师的方式去管理 AI，也不能用使用工具的方式去使用 AI。
管理普通工程师时，我们可以默认一些东西。比如他知道哪些代码是线上关键路径，知道哪些依赖最好别碰，知道改了认证模块要补审计日志，知道某个老接口看着丑但背后绑着三个大客户。AI 不知道。你不告诉它，它就会按通用最优解去写，而最优解在具体业务里是对是错只有老天知道。
把 AI 当工具也不对。工具不会自作主张重构半个模块，不会顺手引入一个新依赖，不会把看似重复的逻辑「优化」成抽象层级过高的通用组件。AI 会。它的危险恰恰来自这里：它不是纯被动的。
所以我给团队定了一个简单的原则：AI 可以承担实现工作，但不能天然拥有设计权和上线权。
这句话展开，有三层意思。
第一层，AI 可以生成候选实现。写接口、补测试、改脚本、整理配置、迁移重复逻辑、补文档，这些都可以大胆用。 第二层，AI 不应该单独决定系统边界。模块职责怎么划，异常怎么传播，事务在哪一层收口，缓存一致性怎么保证，这些属于设计，不该默认交给模型。 第三层，AI 绝对不能越过验证链路直接进入生产。任何由 AI 生成的内容，只要影响线上行为，就必须进入和人工代码同等级甚至更严格的检查。
很多团队嘴上也这么说，执行时却变成另一个样子：能跑就合，回归靠运气，出事了再追。原因很简单，AI 把产能抬得太高了，组织会本能地放松审查强度。如果还沿用原来的评审和验收动作，表面看起来流程没变，实际上单位时间内流进仓库的风险已经上了一个量级。
黑盒失控
现在最危险的一类项目，不是代码质量最差的，而是没人说得清。
你问某个接口为什么这么设计，负责人会说「这是 AI 当时改的」。
你问这个重试机制为什么是 5 次，没人知道。
你问为什么这里多了一层 DTO 转换，回答是「改着改着就这样了」。 你再追一下链路里的幂等保证在哪一层，大家开始翻代码。
这种状态非常像管理失控的团队。每个人都在交付结果，但没人真正掌握系统。
AI 容易把项目推到这个方向，原因有三个。
上下文漂移
模型没有持续稳定的项目记忆。今天你给了它一份架构说明，它能按这个思路写；明天上下文窗口换了，它可能又按另一套默认范式重写。开发者如果没有持续灌输项目约束，AI 的输出就会在不同 session、不同文件、不同任务之间漂移。时间一长，代码库会出现多个世界观并存的情况。
最典型的表现是：
- 相同问题在不同模块有不同解法
- 命名风格不统一
- 异常处理策略前后矛盾
- 同一种校验逻辑散落在多层
- 一些抽象提得过高，另一些地方又完全硬编码
这些问题单看都不致命，叠在一起就会把维护成本抬上去。
幻觉落地
团队管理里，人会掩饰不知道；AI 会直接生成一个看起来很像知道的答案。最麻烦的是，很多错误不是语法错误，也不是单测能轻易打出来的错误，而是业务语义错误、边界条件错误、依赖认知错误。
比如它知道常见认证流程，于是给你补了一套标准 JWT 校验；但你的系统里真正生效的是网关下发的内部签名头。 它知道数据库迁移常规做法，于是生成一套看似完整的 DDL；但你们线上有历史脏数据，唯一索引根本建不上。 它知道消息消费要做重试和死信；但你们这个场景一旦重试就会造成外部扣费重复。
这些都不是「代码水平不够」，而是上下文不够。
责任悬空
只要团队里开始频繁出现一句话------「这是 AI 写的」------责任链就已经断了。
工程系统最怕这种模糊状态。一个改动进入主干，必须有人能够解释设计意图、风险边界、验证方式、回滚方案。AI 不负责解释，真正危险的是人也不再解释。代码作者默认自己只是搬运者，评审人默认差不多就行，负责人默认测试会兜底。最后所有人都参与了生成，没有人承担了理解。
这个局面如果不扭转，团队会很快进入一个假高效阶段：提交很多，迭代很快，事故也越来越玄学。
管理映射
技术团队管理里，有两种极端。
一种是事无巨细全盯。这样的负责人短期看起来最有掌控力，长期一定被拖垮。团队一旦习惯了你兜底，工程师就会下意识少做判断，组织会变得越来越依赖少数核心人。 另一种是纯结果导向，过程完全放掉。报表上看很轻松，实质是把风险往未来递延。到真正出事故的时候，代价通常是成倍的。
AI Coding 也是同一个道理。
如果你要求每一段 AI 生成代码都由资深工程师逐行重写，等于没用上 AI。 如果你完全相信模型，把它产出的内容直接并入主干，风险一定会爆。
真正可落地的方案，是把控制力集中在关键节点，而不是均匀撒在所有细节上。
我将这里的分为四个控制面：需求面、架构面、实现面、发布面。
需求面
需求面本质上是控制 AI Coding 的输入，或者说控制给的上下文。
先控制输入，而不是等输出出问题再返工。
AI 很擅长在模糊需求下生成「合理但不对」的实现。需求如果只有一句「做个导出功能」，模型会自己脑补分页、异步任务、文件格式、权限校验、字段范围，甚至会热心地加一堆你没要的优化。它写出来的不一定烂，甚至可能比初级工程师写得更工整，但偏题的概率非常高。
团队里只要打算让 AI 参与实现，需求定义就得更工程化。我一般要求至少明确这些内容：
- 目标行为是什么
- 非目标是什么
- 输入输出边界
- 权限和安全要求
- 性能指标
- 失败场景处理
- 与现有模块的关系
- 哪些部分不能改
这不是为了给模型看起来更专业，是为了减少返工。AI 生成速度越快，错误方向上的产能越高。模糊需求在人工时代可能只是多讨论两轮，在 AI 时代会直接变成一堆质量不错的错误代码。
架构面
这一层是最值得管的。
负责人一定要盯住结构性决策。因为实现错了，通常改一个函数、补一个测试还能收回来；结构错了，越往后越难拆。
什么属于结构性决策？大概如下：
- 模块边界怎么划
- 数据流向怎么走
- 状态在哪一层维护
- 事务和幂等在哪一层兜
- 缓存和数据库的一致性策略
- 对外依赖如何隔离
- 领域对象和接口对象是否混用
- 错误码、日志、监控埋点是否统一
这些东西如果让 AI 自由发挥，它会默认选择自己最熟悉的常见模式。问题在于，常见模式不等于适合你的系统。一个 30 人团队维护的核心交易系统，和一个 3 人团队维护的后台运营平台，架构取舍完全不同。AI 不会天然理解这点。
所以我更建议把架构约束显式化，直接写成可以复用的项目规则。比如：
- Controller 不直接访问 repository
- 跨服务调用必须经过 adapter 层
- 领域异常不向外透传基础设施细节
- 任何写操作必须显式声明幂等策略
- 核心链路禁止新增同步远程调用
- 序列化协议和字段命名遵循统一规范
这类规则一旦沉淀下来，AI 的可用性会明显提升。因为它最怕的是隐性规范。人能靠经验感知氛围，模型不行。你不写出来，它就当不存在。
实现面
实现层不适合全面强控，但也不能放养。
把实现分成三类。
第一类，低风险、可回归、易验证的任务，尽量放给 AI。 比如脚本生成、接口样板、文档补全、测试补齐、静态检查修复、重复性重构、SQL 改写、配置迁移。这些任务共同特点是边界清楚、验证便宜、出错后影响可控。
第二类，中风险任务，要求 AI 先给方案，再由工程师选型落地。 比如新增一个中等复杂度业务流程、改动已有模块的职责边界、引入缓存、调整异步化方式。这里 AI 可以参与设计草案，但不能直接拍板。工程师需要明确保留什么、删掉什么、为什么。
第三类，高风险任务，限制 AI 的参与深度。 比如认证鉴权、计费结算、风控规则、事务一致性、数据库迁移、跨服务协议升级、核心性能优化、线上故障止血。我的建议是，AI 可以辅助分析、生成候选 patch、补测试、整理日志，但主实现和最终判断必须由资深工程师掌控。
这个暂时是有效的。因为它把「能不能用 AI」这个抽象争论，变成了「在哪些任务上怎么用」。团队一旦形成共识，执行成本会低很多。
发布面
发布前的检查是最后一道硬门槛。
我其实不太在乎代码是不是 AI 写的，我在乎的是它上线前有没有经过足够严肃的验证。很多团队的问题不在生成，而在合入。只要生成速度暴涨，原来还能勉强工作的验收机制就会失效。
发布面我建议至少卡这几件事：
- 关键链路是否有自动化测试覆盖
- 变更是否影响数据库 schema、缓存键、消息协议
- 是否新增外部依赖或远程调用
- 是否有灰度和回滚方案
- 监控和告警是否补齐
- 安全、权限、审计是否受影响
- 变更说明能否被非作者读懂
一个改动如果作者自己都说不清，你就别指望值班同学半夜扛住。
控制颗粒
管理 AI Coding，最难的是控制颗粒度。抓太细，团队效率掉；抓太粗，项目失控。
其核心在于「看哪些信息」。
很多负责人一听说要控制 AI，就开始要求：
- 所有 AI 生成代码必须标记
- 所有 AI 生成 PR 必须由 TL 审
- 每天统计 AI 提交占比
- 每周复盘 AI 产出质量
这些动作不能说完全没用，但经常抓错重点。标记来源本身并不会提高代码质量，TL 审所有 PR 很快就会过载，提交占比看多了只会诱导团队冲数字，周报复盘往往流于形式。
可以尝试看以下的四种变化：
看变化范围
不要先看代码是谁写的，先看它改到了哪里。
如果一个改动只是补几个测试、修一个前端样式、调整一段文案，来源没那么重要。 如果它同时改了接口定义、数据库字段、缓存逻辑和消息消费，这就必须提高警惕。AI 特别擅长顺着链路一路改下去，改着改着影响面就失控了。
所以我很看重 diff 的范围和扩散路径。改动越跨层、越跨模块、越涉及状态一致性，检查级别越高。
看约束是否被突破
很多事故不是代码写错，而是越界了。
比如本来规定 service 层不能依赖 controller DTO，结果 AI 图省事直接拿来用了。 本来约定核心链路禁用同步跨服务调用，它为了实现方便直接加了。 本来规定所有删除都是软删，它看到数据库有删除接口就直接调了。
所以评审时我更关注它有没有破坏系统约束，而不是代码风格漂不漂亮。风格问题会难受，越界问题会出事故。
看解释能力
一个工程师把 AI 生成的 PR 提上来，我经常会问三个问题：
- 你为什么这么改
- 还有哪些方案
- 最担心的风险点是什么
如果回答停留在「AI 建议这样写」「我跑过了没问题」，那这个改动就不该进主干。这里不是为难人，而是在验证作者是否真正理解了结果。团队只要默认可以在不理解的情况下提交代码，系统质量一定会持续下滑。
看验证成本
有些改动本身没那么复杂，但验证很贵，这种也要慎重。
比如一个缓存键规则调整，看起来只改了几行，实际上可能要覆盖冷热数据、回源行为、失效策略、兼容旧键的读取逻辑。 再比如一个 SQL 优化，看起来执行计划好了很多，但线上数据分布和测试环境未必一样。
AI 会让这类改动生成得非常轻松，甚至给出完整理由。真正难的其实是验证。谁承担验证成本，谁才真正拥有决策权。
上下文工程
如果说传统开发最重要的是代码组织，那 AI Coding 时代，另一个同样重要的能力是上下文工程。
很多人把这个词理理解为写 prompt。远不止。真正有效的上下文工程，是把项目里的隐性知识、约束、范式、决策历史，整理成 AI 可以稳定消费的输入材料。
因为 AI 的主要问题，不是不会写，而是不知道你们为什么这么写。
我见过一些团队让模型直接读整个仓库，效果也有，但远没有把关键上下文结构化后喂进去稳定。仓库太大，噪音太多，历史包袱太重，模型容易抓到表层模式，抓不到真正的组织原则。
我一般建议把上下文分四层维护。
第一层：项目事实
这层是客观信息，尽量稳定。
包括：
- 技术栈和版本
- 模块结构
- 编码规范
- 常用命令
- 测试方式
- 发布流程
- 环境差异
- 外部依赖清单
这层材料的作用，是避免 AI 生成一些和项目现实不兼容的内容。比如用错框架特性、调用不存在的脚本、按新版本语法写旧版本代码、误判构建方式。
第二层：架构约束
这层最关键。
包括：
- 分层规则
- 模块边界
- 数据一致性策略
- 错误处理规范
- 日志和监控规范
- 安全要求
- 性能红线
- 禁止事项
这层材料决定了 AI 是在你们的系统里工作，还是在它自己熟悉的抽象世界里工作。
第三层：业务语义
很多错误都死在这里。
比如订单状态机、权限模型、计费规则、对账口径、用户分层、活动优先级、历史兼容逻辑。 AI 对通用业务名词有概念，但你们自己的业务语义常常和行业通用定义并不一致。一个「已完成」状态，在不同系统里可能意味着完全不同的后置动作。你不把这些定义清楚，模型一定会按最常见的解释去补全。
第四层：决策历史
这层经常被忽略，但对减少反复重构很有用。
包括：
- 为什么当初不用某种框架能力
- 为什么这个模块暂时保留重复逻辑
- 为什么某个接口设计看起来别扭
- 哪些历史兼容不能删
- 哪些性能坑已经踩过
AI 最大的问题之一，就是它看见「不优雅」就想优化。很多所谓的不优雅，其实是业务现实和历史包袱共同作用下的局部最优解。没有决策历史，模型会反复建议你走回已经被证明不行的路。
这四层东西，整理起来当然费劲。但只要团队已经重度使用 AI，这件事就是值得做的基础设施。它带来的收益不是「提示词写得更漂亮」，而是返工减少、风格稳定、评审成本下降、事故率可控。
人的变化
很多人讨论 AI Coding，喜欢把焦点放在模型能力。我更关心人的变化，因为组织问题最后都落在人身上。
AI 进来后，团队里的能力结构会发生变化，而且变化挺残酷。
初中级工程师
AI Coding 会让很多传统的练手机会会减少。
以前新人会从写 CRUD、补测试、改脚本、做小重构开始，在这些任务里慢慢建立对系统的感知。现在这些活 AI 一大半都能做，而且速度更快。结果是，新人如果只是把 AI 当外挂，自己很容易失去建立基本功的过程。
这对个人发展是危险的。因为你以为自己在高效交付，实际只是高效搬运。真到需要独立判断的时候，很容易露底。
我对初中级工程师的要求反而更高了： 你可以用 AI 写，但你必须能解释。 你可以不会第一时间手写所有实现，但你必须看得出哪里不对。 你可以借助模型生成方案，但你要知道为什么选这个，不选那个。
说白了，AI 让「动手能力」的门槛下降了，反而把「判断能力」的门槛抬高了。
高级工程师
高级工程师的价值不会下降，反而会被重新定义。
过去很多高级工程师的时间花在亲自解决复杂实现问题上。以后这部分工作里，会有更多内容交给 AI 先铺底稿。真正稀缺的能力会变成：
- 建模能力
- 边界识别能力
- 风险预判能力
- 架构约束表达能力
- 评审和验收能力
- 故障分析能力
一个高级工程师如果还停留在「我写代码比别人快」这个层面，优势会越来越窄。能把 AI 纳入稳定工程流程的人，价值会高很多。
技术负责人
技术负责人要调整的地方最多。
以前很多 TL 的权威来自个人技术深度和关键路径救火能力。以后这些能力仍然重要，但不够了。你还得会设计一套让普通工程师借助 AI 也能稳定产出的机制。这里的核心不是「你自己会不会用最强 prompt」，而是你能不能把团队知识沉淀成规则、把高风险任务识别出来、把评审和发布机制改造到位。
简单说，TL 以后更像一个工程系统设计者，而不只是资深开发。
成本结构
很多公司上 AI Coding，第一个看到的是效率收益，第二个才会看到成本迁移。
账不能只算生成阶段节省了多少人天，还要看这些成本转移到了哪里。
- 前置成本上升：需求要写得更清楚，架构规则要沉淀，上下文要维护，模板要整理，评审口径要统一。这些都是前置投入。团队如果没有这个耐心，AI 只能在局部提效，很难规模化稳定落地。
- 验证成本上升：生成越快，验证越贵。特别是中高风险改动，AI 会让你短时间得到更多候选实现，但筛选、测试、压测、灰度、回滚预案这些事情并不会同步变便宜。有些场景下，验证成本甚至会超过实现成本。
- 知识债积累更快：AI 会加快代码变化速度，也会加快知识过期速度。文档、设计、接口约定、运维手册如果跟不上，系统会很快进入「代码在变，认知没变」的状态。到这一步，组织沟通成本会上升得很明显。
- 人才分化加剧：会用 AI 且保持工程判断的人，产能会非常高。只会依赖 AI 但缺乏判断的人，短期看似也很忙，长期会成为风险源。团队内部的能力差距会被进一步放大，管理上必须承认这一点，不能再用过去那套平均主义的培养和考核方式。
最后
AI Coding 它已经足够强，强到不能再按「辅助工具」那套粗放方式来管；它又还不够稳，远没到可以把理解和责任一起外包出去的程度。
我们可以把技术团队管理里那些早就被验证过的控制逻辑，重新映射到 AI 开发流程里：输入要清楚，架构要收口，实现要分级，发布要设门槛，责任要落到人。
你如果什么都亲自盯，会被 AI 的产能拖死。 你如果什么都不盯，项目很快就会黑盒化。 中间那条路可以试一试：只抓关键控制点，把系统保持在可解释、可验证、可回滚的状态里。
工程管理说到底不是追求一种绝对正确的方法，而是控制失误或失控的半径。AI 加进来以后，这件事变得更重要了。因为它放大的从来不只是产能，也包括混乱。谁能把这两者一起管住，谁的团队才真能吃到 AI Coding 的红利。
以上的所有思考都是基于当前个人对 AI Coding 的理解，不一定正确，请各位看官批判着看。
以上。