大厂 AI 原生实践中的常见陷阱与应对思路

当 AI 从个人效率工具进入企业工作流，衡量效果的标准就不能只看生成速度。代码是否经过审查、结果能否可靠验收、团队经验能否复用，以及智能体权限是否可控，都会直接影响落地成效。围绕这些真实问题，可以更清楚地理解企业推进 AI 原生转型时容易踩中的坑，以及对应的改进路径。

这是苍何的第 601 篇原创！

大家好，我是苍何。

我潜伏了大概有几百个 AI 群，然后整了个群热点坚控工具。

我发现最近在不少社群，在疯狂流传一份从大厂内部传出来的《AI 原生实践避坑指南》。

我相信你们多少也在各自的社群刷到过，又或许没刷到过。

不过这都不重要，重要的是，我看完还是挺有感触的，想单独写一篇文章算是做个分享。

这份指南由一位 360 员工基于 30 多个 AI Native 实践案例整理，覆盖研发、安全、IoT、法务、市场等业务。

完整的指南，我也同步了一份到 GitHub，大家可以自行查阅：github.com/freestylefl…

这份指南一共总结了 7 个坑。

我看下来，有一条线特别清楚：刚开始，我们关心怎么让 AI 帮自己干活。用得多了，开始关心它干出来的东西能不能交付。再往后，问题就变成了：我已经跑通的方法，能不能让同事也用起来？

我想顺着这条线，聊几个自己最有感触的地方。

首先是第一大坑，不少企业 AI 转型，上来就想搞一波大的，我是亲眼见证过的，说我们要搞个全能智能体，拉通所有业务，形成闭环....

甚至老板亲自开启动会，势必要打一场胜仗。

结果拉通不拉通我不知道，最后的结果是让大家对 AI 都失去了信心，也包括老板自己。

贪大求全是 AI 转型的第一杀手。什么都想做，等于什么都做不成。

指南中说小步快跑的方式我也比较认同，通过业务驱动 AI 落地，通过“痛、小、快”的标准来进行切入，快速看到结果。

但也有另一种情况：场景选得很小，AI 也很快给出了结果，最后交付的时候，人却更累了。

代码几分钟写完，检查、调试花了半天；报告一口气生成几十页，里面的数据还得逐条核对。

生成得快，验收跟不上。

这就是指南里说的“一键生成坑”，我觉得这个更值得聊。

指南里提到，360 安全保鲜箱的开发，会让独立的子智能体审查代码，发现问题就打回修复，重新审查通过后才进入提交阶段，人则在关键节点做判断和验收。

这个做法值得借鉴：让 AI 把生成之后的检查、修改也接起来。到底省没省时间，要把后面的验收和返工一起算进去。

不过，一个人跑通了，还会遇到下一个问题：这套方法，同事能不能直接用？

这就到了指南里的“孤岛坑”。

指南里提到有个十人的 AI 产品团队，每个人都用 AI 写代码，单看都挺快，合到一起却出了问题：命名不统一、接口对不上，同一个功能还被重复实现。

后来，他们把规范、文档和 Skill 放进同一个 Git 仓库，开工前先读同一套规则。再把各自搭好的智能体放到纳米 Work 上，让团队成员可以互相调用。

比如设计师不在，产品也能调用设计师沉淀的 Skill，生成符合规范的页面。

类似的做法，指南里还有：法务把知识库和审核规则接入纳米 Work，跑通的审核流程再沉淀成 Skill；IoT 团队把日志排查经验做成数字员工，同事遇到问题，直接 @ 它就能调用。

一个人摸索出来的方法，终于能让其他人少走一遍弯路。

我觉得这也是团队用 AI 很值得关注的一点：除了看谁做得快，还要还要看他留下来的经验，能不能被下一个人用起来。

建立组织级知识共享体系就显得尤为重要了，知识沉淀成 Markdown，然后去流动和共享。

每个人用 AI 省下来的时间，得在交接、协作的时候也能省下来，团队才算真的提效了。Spec-First 帮大家先把要求说清楚，跑通的经验放进共享仓库，再整理成 Skill，让下一个人接着用。

写到这里，其实已经能看出来，光靠几个会用 AI 的员工，很难把这些事全部推动起来。

谁来统一标准？谁给大家留出试错的时间？一个人花时间整理了团队都能用的 Skill，这份贡献算不算成绩？

这些，都需要管理者参与。

所以指南里有句话，我挺认同：管理者应该是 AI 原生转型的第一责任人。

自己先跑通一条工作流程，才知道团队卡在哪里，也才知道哪些经验值得留下来。

这点老周给我的印象挺深。之前在 WAIC 陪他逛展，能感觉到，他自己就很想弄明白，这些 AI 产品到底能干什么、能用到哪里。

有在 360 的朋友告诉我说，去年 8 月公司宣布全员 All in Agent，全员发 token，然后让各大业务线去跑案例。

我倒觉得，看看这些员工现在在讨论什么，就能看出一些变化。

AI 写的代码谁来审，我调好的 Skill 同事怎么用，设计师不在的时候工作怎么继续。能聊到这些问题，说明至少在这些团队里，AI 已经用得挺深了。

用着用着，接到一个任务，自然就会先想一下，哪些步骤可以交给 AI。这种习惯，我觉得才是 AI Native 比较具体的样子。

老周说“用 AI 重新创业”，前面这些案例多少能帮我理解这句话。公司原来的业务还在，但做这些事的方法，包括人怎么分工，都得重新琢磨。

纳米 Work 也是放在这个背景里看，才有意思。这个企业级智能体办公平台，是 360 把内部跑通的方法一点点做进产品的结果。

它能接微信、飞书、钉钉，网页就能用，云端任务也不会因为你关了电脑就停下来。对一个已经有固定工作习惯的团队来说，能沿用熟悉的工具，少折腾本地部署，大家才更容易用起来。

另外，指南里提到的“裸奔坑”也得解决。智能体会读文件、装软件、改数据，企业得管得住它的权限，也查得到它做过什么。按 360 提供的 IDC 评估材料，纳米 Work 在 12 款参评产品中拿到了“安全可控”维度唯一的 Top 评级，多智能体编排、生态与开放性两项也是满分。

自己公司的研发、法务、市场先用起来，产品就会遇到一堆具体要求。一个人的智能体挺好用，能不能给整个团队用？规则改了，大家用的版本能不能跟着更新？这些问题，在真实工作里躲不过去。

360 内部的用法也挺直接，就是全员先吃自己的“狗粮”。按 360 提供的数据，今年 5 月，公司给每位员工发了 1 亿 Token，不用申请审批，先拿业务试。

到 7 月纳米 Work 发布时，360 披露：10 万多个智能体投入真实业务，150 天覆盖 630 个岗位，消耗 350 万亿 Token，收集了 5.6 万条反馈，迭代了 166 个版本。

敢把这个规模的智能体放进研发、法务、安全、IoT、市场，胆子确实够大。背后也有它做安全的积累，云端隔离、权限控制这些要先跟上。参与的业务越多，问题暴露得越快，产品也就有更多机会在真实工作里改。

这组数字里，我会多看一眼那 5.6 万条反馈。整个公司每天都在用，哪里不好用，同事明天还会来找你，演示做得再漂亮也没用。

说白了，先让自己公司的同事用顺，再拿出来给别人用。我觉得做企业 AI 产品，这个顺序挺重要的。

360 给自己的定位是“国内第一家系统性推进 AI Native 转型的公司”。看完这些实践，再看它说的“用 AI 重新创业”，就能理解它想强调什么：老板自己下场，员工在业务里反复试，再把跑通的方法做进纳米 Work。

从这份员工自发写的避坑指南也能看出，这是一种自下而上长出来的员工习惯。这才是真正的AI Native。

等到 AI 成了大家干活时的习惯，这些经验就会跟着每一次交付继续积累，我觉得这才是企业早点开始实践的价值。