每个工程团队都在用AI，但没人统计过一个数字：同一代码库里有多少套不同的AI使用规则。
我聊过的团队里，这个数字通常是10比1——10个开发者，10种设置，10份规则文件，10套提示词习惯。同一个需求、同一个迭代，AI接触代码的方式却千差万别。这不是效率工具，这是规模化的混乱加速器。
看不见的裂缝：当AI放大既有问题
一个开发者的本地环境里有 meticulous（细致的）CLAUDE.md，写满了架构决策、测试规范、代码风格。隔壁工位的同事什么都没有，只有"感觉"和一个空白的上下文窗口。两个人都能提交代码，都能通过评审。不一致性隐形存在，直到某天突然爆发。
AI没有制造这个问题，它只是放大了早已存在的病灶：缺乏真正被执行的共享工程标准。
三个盲区正在同时恶化。
第一，零可见性。你不知道团队怎么用AI。谁遵循最佳实践，谁没有。什么被评审过，什么盲目上线。工程经理有部署频率、测试覆盖率、PR周期时间的仪表盘，但对AI如何塑造团队每天写的代码，完全看不见。
第二，零一致性。同一个需求，十种处理方式。有人让AI先写测试，有人跳过测试直接要实现。有人给AI完整的架构上下文，有人什么都不给。输出差异巨大——不是因为AI不稳定，而是因为人的输入不稳定。
第三，知识随人走。开发者离职时，他的上下文、模式、快捷方式全部消失。他构建的规则、优化的提示词、在本地设置里编码的架构决策——没了。新 hire（招聘）从零开始。这在AI之前就是问题，现在更糟，因为开发者AI设置里的隐性知识量巨大且完全无文档。
正方：共享规则文件是起点
最直观的反应是"建一个共享规则文件"。大多数团队从这里开始，也在这里停下。
仓库里的共享规则文件解决了格式问题，没解决执行问题。没人检查开发者是否真的在用。没人知道它是否最新。没人知道上个月入职的新人是否知道这东西存在。
而且规则只是开始。哪些模型被批准？哪些工作阶段应该用AI，哪些不该？成本怎么控制？哪些架构决策应该约束AI在你特定代码库里的生成方式？
标准化AI使用不只是技术问题，是组织问题。需要有人定义标准，有人维护，有人确保执行，有人随工具演进更新。这不是一个文件能解决的。
反方：标准会扼杀AI的灵活优势
另一派观点很直接：AI的价值恰恰在于突破僵化的流程。给每个开发者同样的规则，等于给所有人同样的枷锁。
不同任务需要不同策略。探索性原型和核心支付模块，能用同一套标准吗？资深工程师和新人，需要同样的AI辅助程度吗？强制统一可能让团队失去AI带来的速度红利，回到"申请-审批-执行"的老路。
更现实的顾虑是：标准一旦写下来，就面临过时风险。模型能力每季度变化，今天的好规则明天可能拖后腿。维护标准的成本，会不会超过它节省的返工成本？
还有执行层面的困难。怎么检测谁没按规则来？代码评审能看逻辑，能看提示词历史吗？强制标准会不会变成形式主义，开发者表面遵守、私下绕过？
我的判断：标准不是终点，可见性才是
两派都有道理，但都在回避真正的问题。
共享规则文件失败，不是因为标准本身错了，是因为团队把"写文件"当成了"解决问题"。没有 enforcement（执行）机制的标准，只是建议。没有 visibility（可见性）的 enforcement，只是抽查。
反对方担心僵化，但混淆了"标准"和"僵化"。好的标准不是禁止灵活，是定义何时灵活、如何灵活。就像代码风格指南不禁止特殊情况，但要求注释说明理由。
关键认知转变：AI标准化的核心不是控制输出，是降低协作成本。
当十个开发者用十种方式解决同一类问题，评审者需要为每种方式重建上下文。这不是AI的问题，是任何协作系统的问题——只是AI让产出的速度远超了评审和吸收的速度。
真正需要的不是一份完美的规则文件，是一套让团队能持续对齐的机制：
谁用了什么模型、什么提示策略、生成多少代码——这些数据先被看见，才能被讨论。讨论后才能形成共识，共识后才能迭代标准。没有数据的标准是猜测，没有标准的数据是噪音。
从规则到基础设施：下一步在哪
短期内，务实的团队在做三件事。
第一，最小化可执行标准。不是覆盖所有场景，是先锁定最高风险的环节——比如核心模块的AI使用必须留痕，支付相关的代码生成必须经过特定检查清单。小范围强制，大范围建议。
第二，把隐性知识显性化。不是要求开发者写文档，是在工具层面捕获。哪些提示词组合效果好、哪些模型在特定任务上更可靠——这些经验从个人笔记搬到团队可见的地方。
第三，接受标准的临时性。明确标注版本和失效日期，定期复盘。标准本身也是代码，需要维护、重构、有时废弃。
长期看，这个问题会被工具层解决。IDE和AI编码助手会内置更细粒度的策略控制，代码托管平台会提供AI使用分析仪表盘，合规审计会要求AI生成内容的可追溯性。但在那之前，团队得自己先趟出一条路。
为什么这件事值得现在关注
AI代码生成的速度还在指数级提升。今天的"十个开发者十种方式"，明年可能是"一百种方式"——因为工具更丰富了，因为新 hire 带着各自前公司的习惯，因为模型能力变化让旧策略失效。
混乱的代价也在指数级增长。一个架构决策的偏差，在AI辅助下可能一小时就扩散到几十个文件。返工不再是"重写一个函数"，是"重构一个被AI渗透的模块"。
这不是要扼杀AI的使用，是要让AI的使用可预测、可协作、可继承。代码库是团队的共享资产，不是十个私人工作区的临时拼接。
最讽刺的是：我们花了二十年建立代码评审、持续集成、架构决策记录这些协作机制，却在AI这个最强大的生产力工具上，集体倒退了到"各自为战"。
修复它不需要等待完美的工具，需要承认这是个问题——然后像对待任何技术债务一样，开始还。
毕竟，让AI写代码的速度翻倍，但让理解代码的成本翻三倍，这笔账怎么算都是亏的。
热门跟贴