制造业公司做软件，最容易撞上的问题是：代码越写越多，人却不够。

TCL 的情况有点典型——软件业务占比已经超过 50%，内部沉淀了上百套代码分支，既有历史包袱，也有跨端需求。他们要做的不是"用 AI 写个 demo"，而是把 AI 编程工具接进真实研发流程。

一、怎么落地的

TCL 引入企业版 AI 编程工具后，核心研发团队的覆盖率超过 90%。

这个覆盖率是关键。AI 编程工具的价值随使用人数线性增长，但如果只有少数人用，代码风格、审查流程、知识沉淀都对不齐，收益会被抵消。

二、可量化的收益

最直接的一个案例是跨终端迁移：安卓与 iOS 之间的项目迁移，从两周缩短到 2 天。

这类任务的特点是重复度高、规则明确、但极其耗神——大量界面适配、API 替换、状态管理改写。人做容易出错，而且枯燥。交给 AI 做初稿，人做审查和修正，是效率提升最明显的场景。

三、为什么大团队收益更大

三个原因。

第一，代码库大，检索成本高。新人找一个函数的用法可能要翻半天，AI 可以秒级定位。
第二，分支多，同步成本高。上百套分支意味着大量重复的合并、回填工作。
第三，规范明确，可校验性强。大团队通常有编码规范、测试覆盖和审查流程，AI 的输出有验收标准。

反过来说，如果团队没有规范、没有测试，AI 生成的代码没人能判断对错，收益就会变成负的——返工比手写还慢。

四、风险控制

把 AI 编程接进生产流程，有几件事必须做：

代码审查不能省。AI 生成的代码看起来合理但可能有隐蔽 bug，尤其是边界条件。
依赖与许可证要查。AI 可能引入不兼容或带传染性许可的库。
敏感信息要隔离。不要把密钥、内部地址喂进对话。
分支策略要清晰。AI 改动的粒度大，容易冲突。

五、可复制的条件

如果你也想复制这条路，先自查四条：

1. 代码是否有统一规范？没有的话，先补规范再上工具。
2. 测试覆盖率够不够？这是判断 AI 输出对错的唯一自动化手段。
3. 是否有明确的迁移/重构任务清单？这类任务最适合起步。
4. 团队是否愿意改变工作方式？工具再强，流程不改也没用。

写在最后

AI 编程的收益不是均匀分布的。它在"重复、规则明确、有验收标准"的任务上收益最高，在"需求模糊、架构设计"的任务上收益最低。找准前者，比追求"全员全场景 AI 化"更实际。