用了一年 AI Codeing开发之后,我总结出这 7 件必须先做的事

过去一年，很多开发者都开始使用 AI 辅助开发。

从写接口、补单元测试、生成 SQL，到解释老代码、改前端样式、生成文档，AI 确实能帮开发者节省不少时间。我们内部也做过一些评估，整体效率有提升，但并没有外界宣传中那么夸张。更真实的情况是：AI 在一些明确、局部、重复性强的任务上非常有效；但在复杂业务、系统架构、长期维护和质量控制上，仍然需要人来把关。

更重要的是，当 AI 开发从个人尝鲜进入企业推广阶段，问题就变了

1. 个人用 AI，关注的是“能不能帮我快点写完”。

2. 企业用 AI，关注的是“能不能在提效的同时管得住”。

这篇文章不讨论某个具体 AI 工具好不好，也不做产品推荐，只总结几个我们认为企业内部推广 AI 开发时比较实用的做法。

一、先把 AI 使用入口统一起来

很多企业推广 AI 的第一步，是让开发者自己去用各种 AI 工具。

短期看，这很自由；长期看，会带来几个问题：

• 不知道哪些人在用 AI。

• 不知道哪些部门用得多。

• 不知道调用成本花在哪里。

• 不知道代码、接口、数据库结构有没有发给外部模型。

• 不知道哪个模型更适合当前公司的业务和技术栈。

• 每个团队自己研究模型，重复试错，成本很高。

所以企业内部最好先建立一个统一的 AI 调用入口。

这个入口可以理解为企业内部的 AI 中转站。开发者、内部工具、业务系统都不直接连接不同模型，而是统一走这个入口。

它至少要解决几件事：

第一，统一 URL 和 Key。

企业不要给每个开发者单独发一堆模型账号和密钥，而是由平台统一发放内部可控的访问地址和 Key。这样方便停用、限额、审计，也方便按部门和项目统计。

第二，统一模型管理。

现在模型更新非常快，每个模型擅长的事情也不一样。有的适合写代码，有的适合长文本，有的适合推理，有的便宜，有的贵但效果好。

企业里应该有专门的人或团队负责研究模型、接入模型、评估模型，而不是让每个项目组都重复踩坑。

一个比较好的分工是：

• 普通代码解释、文档整理，走便宜稳定的模型。

• 复杂代码生成、架构分析，走能力更强的模型。

• 涉及敏感数据的任务，只能走私有化模型或企业允许的模型。

• 图片生成、文案生成、代码生成分别走不同能力的模型。

第三，统一费用统计。

AI 成本如果不统计，前期看不出来，后期很容易失控。企业至少应该知道：

• 哪个部门用得最多。

• 哪个项目用得最多。

• 哪些模型最贵。

• 哪些调用是高价值调用。

• 哪些调用可能只是低价值消耗。

这不是为了限制大家使用 AI，而是为了让 AI 使用变成可管理的资源。

第四，统一出入口安全。

开发者使用 AI 时，经常会把代码、日志、接口文档、数据库结构复制进去。很多时候不是故意泄露，而是为了让 AI 更好理解问题。

所以统一入口最好能做一些基础检查，例如：

• 是否包含密钥。

• 是否包含数据库连接串。

• 是否包含客户数据。

• 是否包含手机号、身份证、邮箱等个人信息。

• 是否包含内部接口地址。

• 是否包含不应该外发的业务规则。

发现风险后，可以根据策略处理：

• 低风险：提醒。

• 中风险：脱敏后继续。

• 高风险：阻断。

• 特殊项目：只能调用内部模型。

这一步做起来并不一定复杂，但价值很大。它让企业从“大家随便用 AI”变成“大家可以放心用 AI”。

二、给 AI 画图也要统一入口

除了写代码，AI 画图现在也越来越常见。

很多公司都会遇到一个现实问题：美工资源有限，但内部系统、活动页面、文档、PPT、官网配图、产品原型都需要图片。AI 画图可以在一定程度上缓解这个问题。

但企业内部使用 AI 画图，也不建议完全放开。

原因有几个：

• 不同模型的商用规则不同。

• 图片可能包含版权风险。

• 图片可能生成近似商标、人物、IP、品牌元素。

• 不同团队生成的图片风格不一致。

• 图片资产没有统一管理，后续找不到、复用不了。

我们现在更倾向于建设一个内部统一 AI 画图站点。

这个站点不只是“给大家一个画图入口”，还应该承担几个管理职责。

第一，统一模型和提示词模板。

普通员工不一定会写好的提示词。平台可以内置一些常用模板：

• 产品配图。

• 文章封面。

• PPT 插图。

• 图标。

• 背景图。

• 活动海报。

• 界面占位图。

• 商务风格图片。

• 卡通风格图片。

这样生成质量更稳定，也能减少大家反复试错。

第二，统一风格。

企业内部图片最好有基本一致的风格。比如颜色、构图、人物风格、是否偏写实、是否偏插画，都可以提前定义。

第三，统一检测。

图片生成后，可以做一些自动检查：

• 是否包含明显商标。

• 是否包含疑似版权角色。

• 是否包含敏感人物。

• 是否包含不适合商用的内容。

• 是否违反公司视觉规范。

• 是否有文字乱码、手部异常、明显画面错误。

第四，统一资产管理。

生成后的图片最好进入企业素材库，记录：

• 谁生成的。

• 用了哪个模型。

• 用于哪个项目。

• 是否通过检测。

• 是否允许商用。

• 是否已经被使用。

AI 画图不是简单替代美工，而是把一部分“基础视觉生产”变成可管理的内部能力。

三、AI 写代码前，先把规范放进去

很多团队使用 AI 写代码时，容易犯一个错误：直接让 AI 开始写。

这样做的问题是，AI 会按照它自己的通用经验写代码，而不是按照你的团队习惯写代码。

比如：

• 目录结构不一致。

• 命名风格不一致。

• Controller、Service、DAO 分层不一致。

• 异常处理方式不一致。

• 日志规范不一致。

• 接口返回格式不一致。

• 前端组件写法不一致。

• SQL 风格不一致。

• 权限判断遗漏。

• 注释风格不统一。

所以我们认为，企业使用 AI 写代码时，第一步不是选工具，而是做规范前置。

简单说，就是在 AI 开始写代码之前，先告诉它这个项目应该怎么写。

比较实用的做法是，为每个团队或项目准备一份 AI 可读的开发规范文件，例如 AGENTS.md。

这份文件可以包含：

• 项目技术栈。

• 目录结构。

• 命名规范。

• 分层规则。

• 接口规范。

• 数据库规范。

• 日志规范。

• 异常处理规范。

• 权限控制要求。

• 单元测试要求。

• 禁止事项。

• 示例代码。

例如，一个 Java 项目的规范可以写得很具体：

# 项目开发规范## 技术栈- 后端使用 Java 17 + Spring Boot。- 数据访问使用 MyBatis。- 接口返回统一使用 Result<T>。- 不允许 Controller 直接访问数据库。## 分层规则- Controller 只处理参数校验和请求转发。- Service 负责业务逻辑。- Mapper 只负责数据库访问。- DTO 用于接口入参和出参。- Entity 只映射数据库表。## 异常处理- 不允许直接 return null。- 业务异常使用 BusinessException。- 所有异常信息必须可读，但不能暴露数据库字段或内部实现。## 日志规范- 关键业务操作必须记录日志。- 日志中不能输出手机号、身份证、Token、密码。- 不允许使用 System.out.println。## AI 写代码要求- 生成代码前，先阅读项目已有同类文件。- 优先复用已有工具类。- 不要引入新的第三方依赖，除非明确说明原因。- 如果需求不明确，先提出问题，不要自行假设复杂业务逻辑。

这类文件看起来简单，但效果很明显。

它能让 AI 从一开始就更接近团队风格，减少后续 Review 成本。对于没有太多代码经验的内部用户，也能避免 AI 随意生成一套不符合公司标准的代码。

四、让 AI 学已有代码，而不是只读规范

规范前置很重要，但规范文件不是万能的。

因为很多团队的真实开发习惯并不完全写在文档里，而是藏在已有代码里。

比如：

• 某类接口通常怎么命名。

• 某类表单页面通常怎么组织。

• 权限判断一般放在哪里。

• 查询条件如何封装。

• 枚举如何定义。

• 前端组件如何拆分。

• 保存、删除、导出这类功能有哪些固定写法。

所以除了写规范，还要让 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 流程是：

1. 开发人员提交代码。

2. AI 先做一次基础 Review。

3. AI 输出风险点、规范问题、安全问题。

4. 开发人员先处理明显问题。

5. 人工 Review 重点看业务逻辑和架构设计。

6. 关键项目必须人工确认后才能合并。

对于一些非专业开发者使用 AI 生成的代码，最好增加一道专门 Review。

因为他们可能不知道 AI 写出来的代码哪里有问题。这个时候，企业可以指定一个有经验的开发人员或小组负责兜底。

如果项目风险较低，也可以先只做 AI Review；但如果涉及生产系统、客户数据、财务数据、权限控制，就不应该只依赖 AI Review。

六、企业推广 AI 开发，真正要建立的是流程

很多团队一开始会把注意力放在工具

• 用哪个模型？

• 用哪个 AI 编码器？

• 哪个生成速度快？

• 哪个上下文长？

• 哪个代码能力强？

这些当然重要，但企业真正要长期受益，靠的不是某一个工具，而是一套流程。

比较完整的企业 AI 开发流程可以是：

1. 模型统一接入。

2. 用户统一授权。

3. 调用统一审计。

4. 敏感信息统一检查。

5. 项目规范统一生成。

6. AI 写代码前先读规范和已有代码。

7. PR 阶段先做 AI Review。

8. 人工 Review 负责业务和架构。

9. 高风险项目保留完整审计记录。

10. AI 使用成本按部门和项目统计。

这套流程不是为了限制开发者，而是为了让开发者更放心地使用 AI。

如果没有流程，AI 用得越多，企业越焦虑。

如果有流程，AI 用得越多，企业越能积累经验。

七、几个可以直接落地的建议

第一，企业应该有一个 AI 模型管理员或 AI 平台负责人。

这个人不一定是管理岗位，但要持续研究模型效果、价格、稳定性、安全策略，并负责统一接入。否则每个团队都会重复试错。

第二，AI 使用要按项目管理，而不是只按个人管理。

因为企业最终关心的是哪个项目产生了价值、哪个项目产生了风险、哪个项目消耗了成本。

第三，AI 规范文件应该成为项目初始化的一部分。

新项目创建时，就应该自动带上基础规范，而不是等代码乱了以后再补规范。

第四，AI 画图也要纳管。

图片生成看似和代码无关，但同样涉及商用、版权、品牌、安全和资产管理。

第五，AI Review 不要替代人工 Review。

AI 应该先处理重复性、规则性、基础安全问题。人工应该把精力放在业务逻辑、架构设计和风险判断上。

第六，企业不要追求所有人马上深度使用 AI。

更合理的方式是先建立统一入口和规范，再逐步扩大使用范围。

八、结语

AI 开发的价值不在于让每个人都变成“十倍工程师”。

更现实的价值是：让开发者少做重复劳动，让团队更快验证想法，让企业内部的软件生产效率提升。

但企业不能只看到“快”。

AI 让代码生成更快，也让错误生成得更快；让图片生成更快，也让版权风险扩散得更快；让业务人员做系统更快，也让影子 IT 出现得更快。

所以，企业推广 AI 开发时，最重要的不是买哪个工具，而是先建立一套基本秩序：

• 入口统一。

• 模型统一。

• 费用透明。

• 数据可控。

• 规范前置。

• 风格对齐。

• Review 兜底。

• 风险可追溯。

只有这样，AI 才不是一个短期提效工具，而会变成企业长期可管理的开发能力。