规范前置很重要但规范文件不是万能的。因为很多团队的真实开发习惯并不完全写在文档里而是藏在已有代码里。比如某类接口通常怎么命名。某类表单页面通常怎么组织。权限判断一般放在哪里。查询条件如何封装。枚举如何定义。前端组件如何拆分。保存、删除、导出这类功能有哪些固定写法。所以除了写规范还要让 AI 参考项目已有代码。一个实用原则是让 AI 写新代码前先让它读 2-3 个同类文件。例如你要让 AI 新增一个“客户管理”功能不要直接说“帮我写客户管理接口”。更好的方式是请先阅读项目中已有的“供应商管理”和“联系人管理”相关代码 理解本项目的 Controller、Service、Mapper、DTO、权限、日志和异常处理风格。 然后按照相同风格生成“客户管理”功能。这比单纯贴一份规范更有效。因为 AI 不只是知道“应该怎么写”还能看到“这个项目实际是怎么写的”。企业内部可以把这件事做成标准流程新增功能前先找相似功能。让 AI 总结相似功能的结构。再让 AI 按同样结构生成新功能。最后让 AI 自查是否偏离已有风格。这样可以明显降低 AI 生成代码的割裂感。五、AI Review 和人工 Review 要分工很多人讨论 AI Review 时容易走两个极端。一种观点是AI Review 没用还是得人看。另一种观点是AI Review 可以替代人。我们更倾向于中间路线技术规范、低级错误、安全风险可以先让 AI 看业务逻辑、架构取舍、关键流程必须人来看。AI 很适合检查这类问题是否违反开发规范。是否出现硬编码。是否缺少空值判断。是否有明显 SQL 注入风险。是否有敏感信息日志输出。是否重复造轮子。是否引入不必要依赖。是否缺少基础测试。是否和已有代码风格明显不一致。但 AI 不适合单独判断这类问题业务规则是否真的符合客户要求。流程是否符合公司制度。权限边界是否符合组织结构。这个设计未来是否容易扩展。某个需求为什么要这样取舍。某个异常场景是否真实存在。所以比较合理的 PR 流程是开发人员提交代码。AI 先做一次基础 Review。AI 输出风险点、规范问题、安全问题。开发人员先处理明显问题。人工 Review 重点看业务逻辑和架构设计。关键项目必须人工确认后才能合并。对于一些非专业开发者使用 AI 生成的代码最好增加一道专门 Review。因为他们可能不知道 AI 写出来的代码哪里有问题。这个时候企业可以指定一个有经验的开发人员或小组负责兜底。如果项目风险较低也可以先只做 AI Review但如果涉及生产系统、客户数据、财务数据、权限控制就不应该只依赖 AI Review。六、企业推广 AI 开发真正要建立的是流程很多团队一开始会把注意力放在工具用哪个模型用哪个 AI 编码器哪个生成速度快哪个上下文长哪个代码能力强这些当然重要但企业真正要长期受益靠的不是某一个工具而是一套流程。比较完整的企业 AI 开发流程可以是模型统一接入。用户统一授权。调用统一审计。敏感信息统一检查。项目规范统一生成。AI 写代码前先读规范和已有代码。PR 阶段先做 AI Review。人工 Review 负责业务和架构。高风险项目保留完整审计记录。AI 使用成本按部门和项目统计。这套流程不是为了限制开发者而是为了让开发者更放心地使用 AI。如果没有流程AI 用得越多企业越焦虑。如果有流程AI 用得越多企业越能积累经验。七、几个可以直接落地的建议第一企业应该有一个 AI 模型管理员或 AI 平台负责人。这个人不一定是管理岗位但要持续研究模型效果、价格、稳定性、安全策略并负责统一接入。否则每个团队都会重复试错。第二AI 使用要按项目管理而不是只按个人管理。因为企业最终关心的是哪个项目产生了价值、哪个项目产生了风险、哪个项目消耗了成本。第三AI 规范文件应该成为项目初始化的一部分。新项目创建时就应该自动带上基础规范而不是等代码乱了以后再补规范。第四AI 画图也要纳管。图片生成看似和代码无关但同样涉及商用、版权、品牌、安全和资产管理。第五AI Review 不要替代人工 Review。AI 应该先处理重复性、规则性、基础安全问题。人工应该把精力放在业务逻辑、架构设计和风险判断上。第六企业不要追求所有人马上深度使用 AI。更合理的方式是先建立统一入口和规范再逐步扩大使用范围。八、结语AI 开发的价值不在于让每个人都变成“十倍工程师”。更现实的价值是让开发者少做重复劳动让团队更快验证想法让企业内部的软件生产效率提升。但企业不能只看到“快”。AI 让代码生成更快也让错误生成得更快让图片生成更快也让版权风险扩散得更快让业务人员做系统更快也让影子 IT 出现得更快。所以企业推广 AI 开发时最重要的不是买哪个工具而是先建立一套基本秩序