这两年我接触了不少研发团队一聊起“团队都在用 AI 写代码公司怎么把这件事管起来”几乎所有人都会先沉默两秒。不是没想过这个问题而是不知道从哪儿下手。禁止吧挡不住也显得跟时代过不去放任吧又怕代码质量塌方、敏感信息外泄、合规审计的时候拿不出交代。很多公司的现状是团队早就在用 AI 写的代码上跑业务了管理制度还停留在“不鼓励、不反对、不负责”的三不状态。这篇东西想跟你聊的就是如何把这件事真正“管起来”。不是写一份挂在墙上的规定而是从摸底、分级、技术拦截、制度落地到持续改进的一整套可操作做法。适合正在带研发团队的技术管理者、负责研发效能和安全的同学也适合那些想在公司内部主动推动规范化的一线工程师。我尽量不给你一套完美的理论而是把能直接拿去用的清单、流程和踩坑经验都摆出来让不同规模的公司都能找到自己能落地的那一层。1. 现状摸底先别急着定制度看看团队到底在怎么用很多人一上来就起草《AI编码工具使用规范》结果要么管得太死大家偷偷用要么写得太宽跟没写一样。我个人的经验是制度永远要晚于现状出台。你连团队在用哪些工具、拿它写什么代码、代码流到哪儿都不知道定出来的制度就是空中楼阁。1.1 为什么摸底是第一步AI编程这事跟过去引入新框架、新语言不太一样。以前引入一个新东西往往是架构组或少数技术带头人先评估、再推广节奏是可控的。AI写代码则是“病毒式扩散”的一个人发现能省半小时第二天整个小组就都在用了。更关键的是这类工具的使用场景极其分散有人用IDE里的自动补全有人用对话式工具生成整段函数有人把内部接口文档粘进去问实现方案还有人拿它写测试用例和注释。这些不同用法风险等级完全不一样。自动补全可能只是帮你把下一行代码猜出来对话式工具可能把企业私有代码片段发给外部模型而“拿内部文档去问AI”这件事本身就可能触发数据合规问题。如果不在摸底阶段把真实使用方式区分开后面制定的策略就会要么太松、要么太紧。摸底还有一个额外好处它能帮你找到团队里的“AI编程实践高手”。这个人往往是制度落地时最好的内部讲师而不是管理者自己。1.2 摸底方法问卷、访谈、代码扫描三件套建议用三种手段同时做互为印证别只依赖任何一种。首先是匿名问卷。要明确告诉团队是匿名、不会秋后算账目的是把现状搞清楚。问题可以包括你每周大概有多少比例的代码是AI生成的你主要用哪个工具你会在什么场景下使用——新功能、修Bug、写测试、重构、写文档你有没有把公司内部代码贴进过AI工具你是否知道公司的数据安全要求这些问题不用设计太多十道题以内就够了关键是让团队敢说真话。匿名问卷最大的价值是把“大家都在用”这件事从猜测变成实锤。其次是面对面的小组访谈。问卷问的是“你有没有用”访谈问的是“你具体怎么用”。访谈时多问“你拿它写过最难的一段代码是什么”“你有没有遇到过它给出看起来对但实际错的结果”这类问题能让你了解团队对AI生成代码的信任度和判断力。访谈人数不用多每个小组挑两三个人就行但最好覆盖老中青、前端后端、不同职级的人。你会发现经验丰富的工程师对AI结果更警惕而新人往往更容易“拿来就用”。最后是代码扫描。这是很多人忽略但特别重要的一步。把仓库里最近三个月的主要分支代码拉出来做一次统计重点看几个信号提交注释里有没有AI工具标记很多工具自动带非常规风格的“真空降”函数数量短时间内大批量涌进主干的代码文件带大量重复注释、命名风格忽前忽后不一致的代码块。这些不能百分之百证明是AI写的但能给你划定一个“高嫌疑区域”用来核对问卷数据是否可信。1.3 用一张表把现状画出来摸底完成后把所有信息归到一张表里按“场景、使用比例、数据流入、质量风险、合规风险”五个维度画出来。我给你一个可以直接抄的模板方向使用场景典型比例是否可能上传私有代码主要风险当前控制手段IDE自动补全很高通常只上传上下文片段质量稳定性基本无对话式生成函数/模块高高常整段粘贴数据外泄、版权无生成测试用例中等中测试代码也涉及业务逻辑测试有效性无代码解释与文档整理较高高常粘贴代码问数据外泄无重构建议较低中行为改变风险无这张表做完你基本就知道管理的重点在哪了。大多数团队的核心矛盾不是“用不用”而是“私有代码和业务逻辑正在被大量送出公司边界”。问题清晰了治理方案也就有了靶子。提示摸底结果非常可能显示“AI生成代码的比例远超你想象”。请做好心理准备不要用摸底结果去问责它是用来设计管理方案的不是用来清理门户的。2. 分级管理什么代码能交给AI写什么必须人写摸底做完就该进入核心环节了。我推荐的做法是先做分级分类。管AI写代码不能一刀切应该像给文件定密级一样把代码和任务分成不同风险等级再匹配不同的使用策略。2.1 按数据敏感度和代码性质分四类我参考多个团队的实际做法把日常编码工作分成四类第一类公开或低敏感代码。比如纯前端样式、通用算法、示例代码、开源库的封装调用、文档字符串、单元测试的mock数据。这类代码不含业务核心逻辑即使被AI模型记住也不会造成实质泄露。建议完全放开鼓励使用把这部分效率红利吃满。第二类内部业务逻辑代码。比如订单状态机、用户权限判断、库存扣减规则、内部服务调用链等。不直接包含密钥和用户隐私但能反映业务模型。这类代码可以用于AI辅助生成但必须遵守两条粘贴前要经过处理去掉注释里的内部术语、字段名做脱敏、生成结果必须经过有经验的工程师评审。第三类高敏感代码。包括密钥、Token、数据库连接串、内部IP和域名、用户个人信息处理逻辑、加密解密相关实现。这类代码一不能贴进公开AI工具二不能让AI自动补全在敏感字段附近“帮你补”。建议通过技术手段做硬隔离比如在IDE插件配置里屏蔽这些目录、在CI阶段加检测规则。第四类核心算法与安全关键代码。比如支付清算核心链路、权限校验核心模块、涉及数据合规策略的代码。这类代码不只是数据敏感还必须是“人类可完全解释”的因为一旦出事故你需要向审计解释每一行逻辑。AI可以辅助写伪代码、梳理思路但最终提交到主干的代码必须由一个明确署名的人完全理解并负责。2.2 分级之后怎么落到流程分级不能只停留在口头宣贯要落到具体流程里。我的建议是做三层第一层是IDE配置统一。团队统一安装经过评估的AI编码插件并在插件设置里关闭“自动收集代码训练模型”的选项同时配置敏感目录白名单让插件在这些目录下不工作或降级到只做本机补全。这件事最好由工具链负责人统一配置后分发给团队避免每个人装法都不一样。第二层是提交前自检。可以给团队设计一个极简的提交前自查清单这段代码是不是包含密钥或内部地址你是不是整段从AI对话里复制过来的你是否逐行理解了每一句话这几个问题打印出来贴在工位上也好放在PR模板里也好关键是让作者在提交前主动走一遍。第三层是评审区隔。低风险代码走常规Review流程中等风险代码必须指定一名模块负责人重点看逻辑边界高风险代码则要求写上“这段代码由AI辅助生成人工审查要点如下”的说明让评审人有明确检查靶点。这样做不是要限制AI使用而是让风险跟流程匹配。2.3 一个判断口诀很多工程师会问我又不是安全专家怎么知道一段代码算高敏感还是低敏感这时候给一个简单粗暴的判断口诀特别有用“里面有没有别人没有、拿到就能造成损失的信息有就别进AI没有但属于业务核心逻辑改错会出事故就慎重既不涉密又不核心放开用。”这个口诀不严谨但它解决了一个实际问题让普通工程师在拿不准的时候选择那个更保守的选项。宁可把一段本来可以放开的代码管严了也不能让密钥裸奔到外部模型那儿去。具体的技术判断标准可以写进制度附件但日常执行靠口诀就够了。3. 建好两条技术防线代码入库和上线前的双重拦截制度管人技术管代码。只有制度没有技术防线等于靠自觉只有技术防线没有制度等于没解释为什么挡。我坚持“两条腿走路”重点建设入库前和上线前两道拦截机制。3.1 第一条防线静态扫描与敏感信息检测代码进入主干分支之前必须过一遍自动化扫描。现有CI/CD平台都能接入这类能力不一定非要买商业版开源方案组合一下就能覆盖大部分场景。扫描的重点可以分四层第一层是密钥和凭据扫描。检查所有新增代码里有没有出现AK/SK、密码占位符、Token、内部Endpoint、测试环境连接串。这类扫描规则成熟关键是别只在主干上跑要在每个MR分支上就跑否则合并后再发现就已经迟了。第二层是私有代码外发特征检测。这块比较有意思主要查那些“AI生成痕迹明显的代码”是否出现在不应当出现的地方。比如某段代码风格与项目历史代码明显不一致或者包含低概率实义注释的组合自动标记出来让Reviewer确认。第三层是合规低频词扫描。可以根据公司业务品类配置业务敏感词比如涉及未公开产品名称、特定合规术语、内部项目代号。这些词如果出现在代码注释里说明开发者很可能把内部上下文粘进了AI工具。第四层是依赖安全扫描。AI生成代码常常会引用第三方库而且倾向于“用看起来合理的库名”有些库名可能是幻觉产生的、根本不存在。如果接入依赖扫描会发现很多AI建议的第三方包其实不在公共仓库里这种代码必须拦截。无论扫描工具是哪一套我建议把扫描结果做成MR评论而不是“一刀切禁止合并”。原因是AI生成代码本无罪问题代码才有罪我们要拦的是“包含高风险内容的代码”而不是“AI写的代码”。这条原则执行得好团队对技术防线的接受度会高很多。3.2 第二条防线Code Review 清单扫描过得了的代码不代表人能看得懂。AI生成代码最典型的特征是“语法全对逻辑局部错误”尤其容易在处理边界条件时翻车——比如没考虑空集合、时间边界、并发竞争、外部依赖超时。这些是静态扫描很难发现的必须靠人来兜底。我给评审团队准备了一份AI代码专项Review清单核心就五条这个函数是不是只覆盖了“快乐路径”异常和边界处理去哪了这段代码里的命名是真实业务术语还是AI编出来的“看起来合理”的词循环、递归、异步调用有没有潜在的性能发散或栈溢出风险对第三方库的调用方式是否真的和该库文档一致版本选对没有有没有无端增加复杂度的写法比如为了应付一道题而搞出多重继承或过度封装这份清单不必打印但可以挂在PR模板里作为一个勾选项。我见过不少团队把这段清单直接做成一个任务模板标题就叫“AI辅助代码人工审查要点”效果比靠评审人自觉好得多。另外一个实际技巧如果整个MR都是AI生成的代码不要允许一次性大包合并。宁可让开发者把MR拆小一个功能一个功能过。因为大段AI代码的审查难度是指数上升的人看50行很清醒看500行就开始“看起来都对”了。让AI代码以小步方式进入主干是质量最实的保障。3.3 全过程留痕与审计管AI写代码还有一个很多人忽视的刚需审计留痕。现在很多公司要过的外部认证或者客户尽调都会问“你们开发流程里用没用AI生成代码怎么控制的”如果答不上来就很被动。所以从第一天起就要让过程可以被追溯。具体做法不复杂在MR描述里增加一个“是否使用AI辅助生成”的下拉框选“是”的话要求补充生成工具、人工修改比例、审查人。再配合代码扫描记录就能回答“这段代码是谁写的、AI参与了多少、谁最终负责”这个铁三角问题。把这些数据定期汇成一份简表每季度看一眼AI参与度趋势、高风险拦截次数、因AI代码引发的事故数。这些数据既是管理依据也是对外证明“我们有控制”的证据。这个过程刚开始会有点烦但跑顺之后就是惯性团队不会觉得多大事。注意AI生成代码的版权归属问题目前还存在灰色地带不同国家地区规定不一。从公司管理角度最稳妥的方式是在团队规范里明确“员工在履职过程中使用AI生成的代码其权利归属和风险由公司统一承担但员工必须保证在代码进入主干前已充分审查理解”。这句话建议找法务过一遍再写进制度。4. 制度落地别搞成一纸空文技术防线搭好了制度文本反而变得好写了。但“好写”不等于“能落地”。我见过太多制度写得完美发完邮件就再没人看。要让制度真正转起来关键是在四个方面做到位。4.1 制度要写清楚的四件事第一件是边界。不要写“鼓励合理使用AI”要写清楚哪些场景是明确允许的、哪些是禁止的、哪些是需要审批的。用第2节的分级结果直接作为制度正文就好。模糊地带越少执行成本越低。第二件是人。每个团队要有一个代码安全责任人通常是技术负责人兼任。所有高敏感场景的使用申请、违规处置、定期检查结果都归口到这个人身上。有了具体的人制度才不会变成无主之物。第三件是流程。从开发到提交、扫描、评审、合并、发布的每一步制度里都要说清楚在哪一步会有控制动作。建议配一张简图非技术流程图就是文字版但注意不要用mermaid直接在制度里用文字描述即可。第四件是处置。违规怎么办我的建议是分阶梯第一次提醒第二次通报第三次限制AI工具使用权限并重新培训。不要搞“发现一次就开除”这种吓人条款那样只会让团队背着你用治理就回到原点。处置措施要与造成的实际风险挂钩比如真把密钥传出去的跟只是用AI生成了一段低敏感内部代码性质完全不同。4.2 培训和反馈机制制度发布当天不是终点是起点。第一个季度至少要做三次全员培训一次讲制度、一次讲工具安全配置、一次讲案例复盘。尤其是案例复盘把真实发生过的高风险行为拿来讲比任何说教都管用。同时要给团队一个反馈渠道。AI工具在快速进化制度一定跟不上所以一线觉得“这条太严了”或者“那条漏了”要有地方提。可以是一个内部群也可以是一个每月评审会议里固定的议程。制度不是锁死的它应该每个季度小更新一版保持跟实际使用节奏同步。4.3 度量指标怎么知道管理有效治理搞了半年怎么判断有没有用我建议盯几个指标不用多四个就够AI辅助代码占比了解整体使用趋势过低说明管得太死过高说明质量风险可能积累。高风险扫描拦截次数反映技术防线是否在发挥作用。因AI代码导致的线上故障数这是最直接的业务质量指标。团队反对声量这个听上去不硬核但很有用。如果每周都有大量投诉“制度太烦”说明流程可能过度了如果完全没人讨论说明制度大概率已经被绕过。这四个指标放一起基本能画出一张“治理是否健康”的画像。真正理想的曲线是AI使用占比缓慢上升而故障数和高风险拦截数都在下降。这说明管理和效率不是对立的而是相辅相成的。5. 经验与坑真实推行过程中我反复踩的几个地方这个环节我不讲框架了纯粹聊聊实操中会遇到的麻烦和我的应对思路。AI编程治理这事说到底是跟人打交道技术只是辅助手段。5.1 最容易引发抵触的三种做法第一种是一上来就全公司禁止使用某个AI工具。哪怕这个工具真有安全风险也不要搞全体禁令。因为团队已经对它有依赖了直接禁用会带来巨大的效率反弹和隐性对抗。更好的做法是先拉一个“允许清单”和“试用清单”把高风险工具先替换掉低风险工具逐步收编。第二种是过度采集数据搞到人人自危。比如要求每个开发者的IDE都上报所有按键记录还要关联个人绩效这绝对会把团队推到对立面。数据采集要止步于“代码和MR级别”不要到“个人行为级别”。管理者要的是团队层面的风险和效能视图不是当监工。第三种是只许州官放火不许百姓点灯。管理者自己天天用AI写PPT和邮件却要求一线工程师“慎用AI写代码”这种双标会被迅速识破制度公信力瞬间归零。要求团队做到的事管理者和管理层的技术岗位首先要做到甚至要更严格。5.2 几条独家建议第一要把AI代码当“实习生写的代码”来管。这个比喻在团队里特别好用。实习生写的代码你总不可能直接上线吧你得帮他把关、改完再发布。AI写代码也一样它不是不可用而是不能“无监督上岗”。心态一换管理动作就自然了。第二建议选一个内部先锋小组先跑制度。不要把制度一次性压到所有团队头上。找个改进意愿最强、风险意识最好的小组带着他们把查清单、扫描策略、评审模板跑顺然后拿着他们的成果向其他团队推广。眼见为实比行政命令有用得多。第三别把AI产生的代码质量事故记到个人绩效里。至少第一年不要。因为团队的技能成长需要周期过早追责会让所有人隐瞒AI使用情况反而失去治理的抓手。更好的做法是记录事故分析原因改进流程形成“事故—改进”的正循环。第四要时刻关注AI工具本身的能力变化。很多治理策略都是基于当时工具的上传机制和模型能力设计的。比如某款工具近期宣布企业版数据不出域那你原来的禁止策略就可以相应放宽某款工具推出了敏感目录检测插件你就可以把它纳入白名单。制度要随工具迭代不能一套规则用一年。我在实际操作中最深的体会是管AI写代码这件事本质不是技术治理而是信任建设。团队需要相信“公司不是来抓我的是来帮我的”管理者也需要相信“团队在AI时代有能力对自己写的代码负责”。把这两层信任建立起来剩下的规则只是锚点。如果只盯着控制和拦截制度迟早会被绕过如果完全放养风险迟早会让你付出代价。所以最理想的公司管法不是用规则锁死AI而是用规则告诉大家我们清楚AI能带来的效率也清楚它藏着的风险所以让我们用一种更专业的方式把它变成真正可依赖的同事。