团队引入AI后反而产出大量低质内容?这7条避坑指南教你正确推进组织AI化转型

最近有人向我咨询，团队开始使用AI后反而产出大量低质量内容，该如何解决？

这实际上是许多企业和团队的普遍现象。从最初的陌生、抗拒，到疯狂使用AI工具，最终却产生了一堆毫无价值的AI废料。

当时随手记录了几条建议。

写完之后发现，这个问题远比你想象的复杂。当一个人提交了一份充满AI痕迹的材料时，我们当然可以指出问题。但当这类情况开始批量出现时，仅仅盯着个人的Prompt已经远远不够。许多问题出现在他动手之前，也出现在交付之后。

过去一年多，Claude、Codex等产品将Agent从Vibe Coding工具推向了新的阶段。它们已经能够读取文件、操作软件、调用工具、连续完成任务，越来越像一位精通电脑的白领工作者。

我对这件事的态度很复杂。

一方面，我担心未来的自己、所在行业，甚至整个白领群体会受到多大的冲击。

另一方面，我也在快速学习和使用Agent，希望自己至少能成为较早适应的那批人。

因为还在企业工作，我碰到的问题也很实际。

传统互联网产品如何被AI重构，是另一个话题，我以后单独写。许多企业已经在尝试，效果参差不齐，有些体验甚至可以说是强行、笨拙，完全对不起参与项目那些人的薪资。

今天只讨论企业内部的工作方式，如何被AI重构。

我所在的企业并不以效率著称，有些组织机制甚至天然反效率。想要在这样的环境里推动AI Native，阻力肯定不会小。

尽管如此，我们还是取得了一些成果。

产研速度快了，交付质量也提高了。

比如我从0到1推动的Toy，它帮助Vibe Coding创作者便捷部署和分发自己做的网页。

项目起初只有一名研发，没有设计，产品工作由我兼职承担。

从启动到上线只花了几周，内测一个多月已经迭代了上百个feature。

有百大UP主用它做了数十个Toy，单条视频播放量最高过百万。

这些成果还谈不上证明什么。

我只是确实在一个真实组织里推过、撞过墙，也得到了一些回报。下面七条经验，都是从这些事情里一点点磨出来的。

能用御三家，就用御三家。

模型能力的差距，实际使用时非常明显。如果核心任务只能用落后一档的模型，团队很容易拿着糟糕体验证明「AI不行」。试过几次，输出又慢又差，后面再想推动就更困难了。

预算有限当然是现实问题。如果资源有限，可以先让一小批人、几类关键任务用上足够好的模型。雨露均沾，把差模型平均发给所有人，看起来公平，最后很可能谁都没有真正用起来。

初学者使用AI，经常会出问题。这个很正常，大家都有学习和提升的过程。

看到一份AI痕迹很重的材料，我会不停地问。

这是你拿AI做的吗？

你自己的观点具体是哪一部分？

里面哪些判断，你可以负责？

我不太关心一个人每天向Claude或Codex提了多少次问题，也不太关心他用了多复杂的Prompt。我看交付。东西有没有变好，结论经不经得起追问，出了问题能不能说清楚。

AI是手段。手段后面的判断，最后还是要落在人身上。

我推过一些AI分享会，一部分邀请外部嘉宾，一部分让内部同学分享。

内部同学讲的往往很朴素，可能只是怎么整理一次调研，怎么让Agent帮忙搭页面，怎么少做几轮机械修改。恰恰是这种一线经验，最容易让身边的人动起来。

大家会觉得，他跟我差不多，他能用好，我应该也能。

外部高手提供另一种刺激。他们会把能力上限拉到很远，让人看到原来AI还能这样用，原来一个完整工作流可以做到这个程度。

两种熏陶都需要。

我有一个感受，会反复跟团队讲。

AI可以比较容易地帮新手达到70分。它很难直接帮专家完成一个80分以上的专业任务。

专业任务通常需要Harness，需要提前编排上下文、工具、规则和验收方式。它也需要Agent-human Loop。人先给目标和标准，Agent动手，人看结果、给反馈，Agent再修，最后拿明确标准验收。这个循环可能要走很多次。

Prompt只是其中一个环节，而且未必是最重要的那个。

如果一项任务属于你的专业领域，但你自己都不知道什么叫交付得好，AI很难救场。你的输入可能有问题，它给出的结果是对是错，你也没有判断。

拿需求文档举例。你得有能力把需求想明白，只是暂时还没花足够时间去想。在这个前提下，Agent才能帮你加速。要是连问题都没看清，生成速度越快，有时只是更快地得到一堆垃圾。

很多任务怎么使用AI，人和机器怎么配合，慢慢是可以固定下来的。

好用的SOP、上下文、检查表、Skill和Harness，都应该以.md文件或者其他合适的形式留在团队里。

大家做出来的页面太丑，可以把frontend-design装上。AI交付不够系统，就把已经验证过的流程和Skill整理出来。下一个人接手时，有现成的起点，也能继续往上改。

否则每个人都要从零学一遍。同样的坑，张三踩完李四再踩。所谓提效只发生在个体身上，人一走，经验也跟着清空了。

这件事其实挺笨的，就是把有用的东西写下来、放到大家找得到的地方、持续更新。但组织能力很多时候就是这么长出来的。

我很喜欢Codex的Goal任务。

结果足够明确、可以衡量以后，中间过程就能允许一定程度的黑盒。人也好，机器也好，具体怎么做可以有很大的自由，最后拿同一套标准看交付。

交付结果不好，可以换人。也可以回到前面的几条继续查，模型够不够，判断能力有没有，Loop是否存在，团队资产有没有真正被用上。

Goal写不清楚，往往说明管理者自己也没有想清楚要什么。这个锅没法甩给AI。

这条很容易被理解成裁员。我说的「系统」，指的是流程图里的节点数量。

那些厉害的人，其实可以做很多事情。管理者要帮他们减少摩擦，让他们能够端到端交付，别把大量精力耗在排期、交接、对齐和等待上。

传统互联网的产研流程可能是这样。

产品 → 交互 → 视觉 → 前端 + 后端 → 测试

有了Agent，它可以缩短成这样。

产品 → 研发

有些项目甚至可能只剩一个产品，一个人带着多个Agent把事情做完。

流程里每增加一次交接，信息都会损耗一点，还会多出一次等待和重新对齐。节点少了，小团队才有机会把一个目标从头做到尾。人的能力也不会被切碎在流水线上。

所以，我现在理解的AI Native，是在「所有员工都装上了AI」的基础上，AI开始改变企业的成本结构、协作接口和组织拓扑。

前者是工具推广。

后者才叫转型。