团队中AI编程推行踩坑记录

这2个多月，我们团队(20人)一直在做 AI 编程落地的探索。

回头看，这件事不是装个工具就结束了。它更像一件要分阶段往前走的事。

先让大家接触。再统一入口。再开始试方法。最后再慢慢找到适合团队自己的推进节奏。

如果按时间线来拆，我觉得这两个月，差不多走了四步。

第一步，先把工具推到大家手边

最开始，我们做的事情其实很简单，就是先推工具。

一开始推的是 IDE 插件。这种方式最容易被接受，因为轻，不太打断原来的开发节奏。

后面也试过独立 App。能力看起来更完整，但切换成本明显更高。研发只要觉得多绕了一步，使用意愿就会往下掉。

这一阶段我们主要干了几件事：

• • 给团队推荐常见工具
• • 鼓励大家在日常开发里先顺手试一试
• • 观察不同工具形态的接受度
• • 收集团队第一轮真实反馈

这一阶段最大的收获，不是马上提效了多少，而是团队终于开始真正接触这件事，而不是停留在“听说过”。

很多时候，企业里推新工具，第一步不是立刻见效，而是先让大家知道：

• • 它到底能做什么
• • 它适合什么场景
• • 它值不值得继续投入时间去学

这一步看起来基础，但很关键。因为只有真的开始用了，问题才会浮出来，经验才有机会积累下来。

这一阶段的问题也很典型：

• • 大家用得比较零散
• • 热情不一致
• • 真正愿意持续深挖的人不多
• • 更多人还是“推一下，用一下”

所以我们那时候没有急着追统一，也没有急着追结果。先接受一个现实：

第一步最重要的，不是立刻提效，而是先让团队真正开始用。

第二步，从零散试用走向统一工作流

工具推了一段时间后，我们很快意识到一个问题：

如果每个人都在试，但每个人试的都不一样，团队层面其实很难沉淀经验。

所以第二阶段，重点开始变成统一入口。

后来团队逐步切到了 CloudCode + 公司内部模型 这套组合上。这一步的意义，不只是工具收口，而是团队终于开始在同一套工作流里实践。

这一阶段我们主要做了几件事：

• • 统一主工具链
• • 接入公司内部模型能力
• • 尽量让大家在同一套环境里实践
• • 开始积累团队层面的共同经验

统一之后，很多事情才慢慢变得可复用：

• • 哪类任务适合先交给模型
• • 哪种提问方式更稳定
• • 什么样的上下文给法更有效
• • 哪些坑是大家反复踩到的

这个阶段我们也越来越明确一件事：

企业落地，不只是选模型，更是驯模型。

任务怎么拆、上下文怎么给、约束怎么写、什么时候该人工接手，这些比单纯比较模型参数更影响实际效果。

这一阶段也不是没有问题。

• • 大家会有一点 token 焦虑
• • 对模型能力边界，尤其是复杂任务上的稳定性，心里还是有顾虑

但继续往前走之后会发现，token 不是最核心的问题。真正重要的是，团队有没有开始形成一套稳定用法。

第三步，开始找方法论

当团队不再满足于让 AI 帮忙补几行代码，问题就会自动升级：

AI 能不能参与完整需求。

也就是说，不只是局部辅助，而是往前走到需求澄清、方案设计、开发实施这些环节。

这个阶段，我们开始看一些更偏方法论的东西，比如 OpenSpec，以及后来接触到的 EEC Everything Cloud Code。

这一阶段我们主要做了几件事：

• • 看官方文档
• • 看外部团队的公开实践
• • 在内部组织虚拟小组做深度探索
• • 尝试拿完整需求去跑流程
• • 比较不同方法的约束程度和适配性

这一阶段最大的收获，不是找到了某个标准答案，而是开始明白：

企业里能落地的方法论，不一定是最完整的，而一定是最适合当前团队的。

有些方法论很完整，也很先进。但它往往默认团队已经具备一些前提：

• • 文档质量足够高
• • 需求边界足够清晰
• • 上游输入足够结构化
• • 团队愿意接受新的协作方式

这些条件如果不具备，方法论越完整，落地反而越重。

所以后来我们更偏向那些可裁剪、可编排的方法。不是因为它更高级，而是因为它更贴近团队现状。

第四步，先找到推进节奏，再谈最优解

走到这里之后，我们对这件事的看法开始变得更务实。

一开始大家容易关注：

• • 哪个模型更强
• • 哪个工具更像未来
• • 哪套方法论更先进

但真正推进一段时间之后，团队更应该关心的是：

• • 现在最适合推到哪一步
• • 哪些东西可以先统一
• • 哪些东西适合先试点
• • 哪些问题是工具问题
• • 哪些问题其实是协作问题

这也是我们这一轮探索里最大的变化之一。

团队开始从“找最优解”，慢慢转向“找可持续的推进路径”。

如果用一句话总结，就是：

AI 编程不是装一套工具就结束，而是一套团队协作方式的渐进升级。

先让大家接触，再统一入口；先有实践，再谈方法；先有适配，再谈规模化。

顺序不能乱，节奏也不能乱。

写在最后

回头看这前半段探索，我觉得最重要的，不是我们已经跑通了多少东西，而是团队开始慢慢找到自己的节奏了。

从工具引入，到统一工作流，再到开始尝试方法论，本质上是在一层层把团队真正带进来。

但走到这里，我们也碰到了新的问题：

• • AI 每次做需求，到底靠什么理解项目
• • 知识怎么沉淀
• • 探索怎么提速
• • 结果怎么验证

这些，才是更深一层的硬骨头。

下一篇我准备继续写这部分，重点聊聊知识库、验证体系，以及为什么 AI 编程最后拼的是工程基本功。

如果你也在团队里推进 AI 编程，欢迎关注我。

后面我会把这次内部探索里整理过的一些资料脱敏后慢慢放出来，包括：

• • 团队内部培训提纲
• • 方法论对比笔记

私信518，送给同样在一线推进这件事的朋友。进群一起探索AI编程。