乐于分享
好东西不私藏

团队推AI第一步不是选工具

团队推AI第一步不是选工具

上周接到一个电话。

打来的是个嵌入式团队负责人,管十来个人,STM32为主,用Keil开发。

他开门见山,团队写代码,程序架构那些不统一。又说,想用AI去实现组织流程的规范性,让大家架构统一。

他不是第一个这样想的人。我接触过的嵌入式团队负责人,十个有八个上来就问,你们用什么AI工具,能不能帮我们搭一套。

但很少有人先问,我们团队的代码架构统一了吗?

这就像一家人连菜谱都没有,就跑去问厨师,你们厨房用什么牌子的锅。

锅好不好当然重要,但你连做什么菜都没定,什么锅都救不了你。

这个客户的团队,基本没有成文的代码规范。十个人写代码,架构风格完全不一样。同样的功能,张三用状态机实现,李四用switch-case,王五用回调函数。命名风格也不统一,有人喜欢驼峰,有人喜欢下划线,有人中英文混着来。

新人来了怎么办?问老人。老人离职了怎么办?知识就断了。

十个人的代码库里,同一个功能可能有三种不同的实现方式,互相看不懂。

你说这种情况下推AI会怎样?

AI会帮你加速这种混乱。

十个人各自用AI写代码,产出十种风格的代码。。。

而且每种风格都比以前更难看懂,因为AI生成的代码比人写的更复杂、结构更庞大。

你以为AI会帮你统一?不会。AI只会根据每个人给的提示词,生成符合那个人习惯的代码。张三的提示词跟李四不一样,AI给张三和李四生成的代码就不一样。混乱被放大了,不是被解决了。

回到那个客户的诉求。他说想让团队架构统一,这句话翻译过来就是,我先不管AI好不好使,我的团队连最基本的代码规范都没有,我想用AI来帮我解决。

但AI没法帮你定规范。

规范是你自己要先想清楚的。你团队用什么架构模式,裸机轮询还是RTOS?驱动层和应用层怎么分离?错误处理用返回值还是全局标志?这些决策必须人来做,做了之后写下来,然后AI才能在这个框架下帮你写代码。

我做了一个AI工作流,把我自己做开发10年的一些编程规范和代码架构投喂给它。

现在基本每个项目都能统一成以下风格:

下面是一些规则文件。

所以用AI,难点就在这里,你得有经验喂给它。

然后我还发现了一个问题,不是说你喂得越多越好,规则多了,容易臃肿,一臃肿就会产生上下文污染,导致AI无法精准命中你的规则,俗称幻觉。

我觉得很多不同行业的规律,都是相通的。

就像我们以前写代码,同一个功能,有些人300行代码实现,有些人100行代码实现,设计AI工作流skill也是如此。

这就是为啥我天天研究,依然觉得时间不够用的原因。

后来我跟他说了三件事,有先后。

先把代码架构统一了,不用多复杂,选一种团队大部分人都在用的架构模式,定下来。然后把开发规范文档化,命名规则、文件组织、驱动接口风格、注释要求,写下来,新人来了照着做。最后才是AI工具导入。

框架定好了,不管谁来用AI,输出都是同一套风格、类似的架构。新人来了有规范参照,不依赖老人手把手教。AI写的代码在框架内,接手的人看得懂。

目前我已经初步跑通了这套AI工作流,感兴趣的可以看我下面这篇文章:

我花了半年,把 AI 塞进了单片机开发的每一个环节

如果这三件事的顺序反了呢?

AI加速的不是开发效率。是加速混乱。

这个客户后来又说了句话让我印象挺深的。他说,新手来了也能很快上手,项目有问题可以快速得到解答。

你看,他真正想要的不是AI。他想要的是一个团队不再依赖某几个人的系统。AI只是他想到的一个手段。

但手段之前,得先有地基。

没有统一架构的团队,给再多AI工具都是空转。不是工具不行,是你的基础还没到能用好工具的阶段。

如果你也是嵌入式团队负责人,正在想怎么推AI提效,先别急着选工具。先看看你团队的代码,十个人写的代码放在一起,能看出是同一个团队做的吗?

如果不能,我觉得可以先把这件事解决了。