我花3年踩坑AI：从"全员拒绝"到重新押注，CTO的复盘

2022年，我带领12人工程师团队测试GitHub Copilot，一个月后全员投票：0人愿意续费。作为CTO，我当场取消订阅，把AI打入"炒作"冷宫。两年后，同一批工程师里超过一半每天离不开AI工具。这中间发生了什么？

我的判断失误，不是因为技术不行，而是测试方法出了问题。

当年我们设计了一套"严谨"评估流程：给每位工程师两周时间，在真实项目中使用Copilot，最后匿名填写满意度问卷。结果平均分2.3/5，评论区写满了"打断思路""代码质量参差""不如自己写快"。我拿着这份报告向CEO汇报，结论是"节省不了工时，反而增加审查负担"。

现在回头看，这套流程像个精心设计的陷阱——我们在用衡量成熟工具的标准，去审判一个还在学步的新事物。要求工程师"正常使用"两周，但Copilot当时的交互逻辑和今天完全不同，没有自然语言对话，没有上下文理解，本质上是个高级自动补全。用户需要学习怎么和它配合，两周刚好卡在"足够厌烦，还没熟练"的甜蜜点。

更隐蔽的偏差在于权力结构。我是CTO，我宣布"评估AI工具"，工程师们会下意识寻找缺陷来证明我的判断。这不是恶意，是组织行为的常态。一位工程师后来私下告诉我：「我当时确实觉得没用，但现在想想，我可能也没认真试。」

第二次入场：从"评估工具"变成"评估自己"

2023年中，团队里一个前端工程师开始偷偷用ChatGPT写正则表达式。不是官方采购，是他自己充的20美元月费。我注意到是因为他的代码审查通过率突然从85%跳到97%，且速度没变快——说明不是敷衍，是质量真提升了。

我找他聊了一次。他的用法让我意识到，AI的价值不在"替代工程师"，而在"消化工程师讨厌的工作」。正则、配置脚本、测试数据生成——这些活儿技术含量不高，但消耗大量认知资源。他用ChatGPT不是当副驾驶，是当外包临时工。

这个观察改变了我的策略：不再问"AI能不能帮我们"，而是问"我们哪些工作宁愿不做"。

我重新启动团队评估，但规则全换。不设统一工具，不设使用时长，只要求每人找一个"自己讨厌的任务"尝试用AI解决，每周五分享花了多少时间、结果能不能用。三个月后，7人里有4人形成了稳定 workflow，另外3人确实找不到场景——这很正常，他们的工作以架构设计为主，AI当时帮不上。

我的立场：AI不是好或坏，是"看你怎么组织"

LinkedIn上有个评论让我反思了很久。Kirill在我上一篇文章下留言：「AI在正确的人手里可能是好事。」我当时写的是工程师与管理者的沟通断裂，但大篇幅聊到AI，导致整篇文章被误读成技术善恶之争。这是我的失误——写作时跟着思绪跑，没把主线钉死。

所以这篇直接摊牌：我对AI的态度是"情境依赖论"。同样的Copilot，2022年我的团队用不出价值，2024年另一批人用成了标配，变量不是技术版本号，是组织怎么接纳它。

我见过三种失败模式。第一种是我的早期版本，把AI当成熟工具采购，要求即时ROI，测完就扔。第二种是强制全员使用，KPI里写"每周AI生成代码占比"，工程师被迫把能自己写的也丢给AI，质量崩盘。第三种最隐蔽——完全放任，结果团队里形成"AI派"和"手工派"两个阵营，互相看不起，代码库风格分裂。

相对成功的做法，是把AI当成需要磨合的新同事。给足时间探索个人 workflow，允许有人用、有人不用，但要求用的人把"什么场景有效"文档化。三个月后，这些文档自然沉淀出团队共识：哪些任务AI处理更快，哪些必须人工把关，哪些现阶段完全不能碰。

一个还在验证的假设

我现在对AI的兴奋点，和当年前端爆发期类似：不是某一项技术成熟，是整个生态的混乱创造力。当时没人能预测React会赢，但你能感觉到"网页可以做成应用了"这个方向是对的。今天的AI领域，我能确定的是"自然语言可以成为严肃接口"，但具体哪家长期存活、哪种交互范式成立，押注还为时过早。

我的团队目前稳定使用的工具组合：Claude用于长文档分析和需求拆解，Cursor用于代码生成和重构，Perplexity用于技术调研。这个清单明年可能全换，我不介意。真正重要的是保持"愿意重新评估"的状态——2022年我取消Copilot订阅是对的，但把AI整体打入冷宫是错的，区别在于前者基于事实，后者基于情绪。

前端开发那几年教会我一件事：新技术的价值往往在"不正经"的用法里浮现。当年谁也没想到，为了兼容IE6而诞生的jQuery，会意外培养出一代DOM操作专家，为后来的组件化革命铺了路。AI现在的"胡说八道"和"幻觉"问题，会不会也藏着某种我们还没看懂的价值？

你们团队是怎么引入AI工具的？是集中采购、个人自发，还是干脆禁止？我想知道实际运行中的 friction 在哪——这比任何产品发布会都更能说明问题。