大模型与智能体的崛起正在重塑生产力的底层逻辑。AI 不仅提升了个体的工作效率,也在重构组织的协作方式和运营模式,催生出“10x 团队”和“10x 工作者”的全新形态。那么,如何拆解 AI 落地的路径、坑与组织升级?又如何把用好 AI 的少数人变成团队的能力?
近日 InfoQ《极客有约》X AICon 直播栏目特别邀请 来也科技联合创始人 & 首席技术官胡一川 担任主持人,和 阿里巴巴高级前端技术专家汤威、 美团产品经理邹明远、快手磁力引擎风控技术负责人王东旭 一起,在 AICon 全球人工智能开发与应用大会2025 北京站即将召开之际,深入探讨 AI 时代的「10x 个体」与「10x 组织」。
胡一川:你们各自团队里,是否存在所谓的「10x 个体」?如果有,大家会怎么描述他们的特征?
汤威: 可能没有 10x 的,但有 5x 的。过去大家通常认为效率很高的同事,是因为他们写代码又快又好、质量高,因此一个人能承担多人工作。但在现在的 AI 阶段,许多代码无论难易,AI coding 工具,例如 Claude Code 等,往往能写得比人更好,只要你会正确使用它们。因此,在我看来,现在所谓的“10x 个体”,核心不在于编码速度,而在于他们是否主动思考、善于利用各种方法解决问题,而不局限于“我是前端”或“我是后端”这样的角色边界。
这些人会基于问题本身,灵活使用各种手段与工具来完成目标。由于 AI 已经让执行层的阻力大幅降低,他们只需要更清晰地表达需求,思考如何让工具实现目标,并协调多个智能 Agent 达成整体效果。关键在于,他们不仅强在开发层面,更强在产品化能力的思考——从业务痛点开始,他们能清楚地知道该产出怎样的方案、设计怎样的稿件、建立怎样的交互链路;产品上线后如何验证效果、证明能解决问题,以及如何迭代优化。因此,现阶段的“10x 个体”最突出的能力是:他们能迅速理解要解决的核心问题。
其次,他们非常善于使用各种工具,并不受限于某一种技术栈,并不会认为“必须使用 AI”或“必须使用某种语言”。无论是 JS、Python 或其他语言,对他们来说只是工具。在要求更高的层面,他们从产品构思、开发实现到验证上线,都能保持清晰的理解。这些能力正是我认为当下要成为“10x 个体”所需要具备的。
胡一川: 在过去的研发体系里,每个人都严格依照岗位分工协作,由于缺乏工具支撑,每个人的能力边界非常清晰,团队可能需要五到十种不同岗位才能共同完成一件事情。而现在,有些工程师即使主要负责开发,也能够理解产品为什么要这样设计、需求是什么、用户如何使用等,因为他们可以借助新工具参与以往自己无法参与的工作。你提到团队里可能没有“10x 个体”,但有“5x 个体”。那你通常从哪些角度来量化或评估?
汤威:“10x 个体”在团队内部出现的前提,是团队成员能力水平差异较大;如果团队整体实力都在相对较高的水准,想出现“10x”差距是很困难的。但如果将个人放在更大的行业环境中,我认为是有可能成为“10x 个体”的。这里的“10x”并不意味着他做了 10x 的需求量,而是他带来的贡献与业务效果能够达到其他人的 10x。大多数人看到“10x”时会误解为“工作量是别人 10x”,但我认为不现实,真正可能出现的是“贡献的价值是他人的 10x”。
胡一川: 之前大家理解“10x”往往停留在代码行数等指标。但在我看来,一个人能够把一个产品从 0 到 1 做出来,并推动商业化,原本需要一个十人团队的能力,如果由一个人完成,那就是“10x 个体”。因此,讨论“10x 个体”不应只从岗位产出的效率来看。因为如果纯看效率,今天借助 AI coding,一个人写出的代码可能远远超过过去的 10x,但关键在于你写的代码是否产生价值。
邹明远: 作为一个传统的泛研发团队,我们正在经历一个明显的变化:角色边界不断被打破。例如,作为产品经理,我现在可以独立完成一些 1 PD、2 PD 或 5 PD 内的小需求,并直接与 PR 流程衔接;我们也看到后端工程师开始写前端代码,往全栈方向发展。
除了个人能力边界变化外,更显著的是团队协作方式的变化。过去各角色划分清晰,因此需要复杂的协作流程,并因此产生额外沟通成本,例如撰写大量交接文档、遵守各种规范。而流程链路中的信息传递往往会损耗,使最终产物可能与最初设想有差异。现在由于角色边界被弱化,协作链条中的参与者变少,为协作付出的成本显著降低,效率明显提升。
第二个视角是我们在做面向非研发人员的 AI coding 产品。在某些场景下,我们确实看到超过“10x”的效率提升。例如有一位业务同学,为团队的一两百人构建了一个业务图片审核系统,三五天就能搭建完成,支持每月 30–50 万张图片的审核量。这样的成果在过去几乎不可想象,也是我认为在某些场景下效率提升甚至超过“10x”的原因。
王东旭: 既然今天主题是“10x 效率”,我想先回应这个数字。我也不知道为什么大家都说“10x”,但我们团队最近的一个例子恰好符合这个数字。我们过去做模型微调与强化学习,每个人都有自己的方案。我上周问团队能否把这套能力线上化,他们与产品和设计评估后给出的排期是 30 天。我认为这种竞争环境不能等待一个月,于是建议他们尝试 AI coding copilot 或 Vibe coding 的方式。结果他们三天就完成了,30 天对比 3 天,正好是 10x 的效率提升。
我们过去的协作方式属于“固态组织”,分工明确、边界强、各自垂直深入。新的 AI 时代,组织形态应从“固态”向“液态”转型,像水一样流动、包容、互相补位,能力边界不断拓展。
从风控角度,我们看到的效率提升远超过 10x。我们每天需要审核超过几亿条短视频,还有几千名审核员作为最后一道人工关口。我们持续推动通过大模型将人工审核 AI 化、线上化。由于大模型具备强大的多模态理解能力,只要提供足够 GPU 资源,就能实现 7×24 小时不停审查。因此在我们的场景里,AI 带来的组织力和生产力提升已远超“10x”。
胡一川:和两三年前相比,在这一轮大模型 / 生成式 AI 浪潮下,你觉得“优秀工程师 / 产品 / 技术人”的评价标准,有哪些最明显的变化?
王东旭: 首先是组织战略层面推进 AI First。这一定调是自上而下完成的,整个技术体系都在贯彻这一战略。
第二点是我们设定了一个衡量团队的指标,叫“AI 率”。我管理下有多个子组织,我会关注每个团队内部及团队之间的 AI 率差异。以算法团队为例,AI 率并不是看他们是否完成传统的 CV 或 NLP 小模型工作,而是衡量他们从事大模型相关生产活动的比例。
在数据团队,AI 率的衡量方式不同。团队原本以 Data Engineer 为主,主要负责数据计算、数据引擎和 BI 类工作。今年 BI+AI 十分热门,因此我们会看数据同学参与“数据飞轮”“数据引擎”相关 AI 化工作的比例。例如,本来需要人工完成的标注,现在让数据同学去研发智能标注工具。美国的 Scale AI 就是典型代表,我们的数据方向也基本对标这样的能力体系。
研发团队的 AI 率衡量又是另一套逻辑。团队规模不小,但过去的工作方式偏传统:产品经理写好 PRD,我们拆分任务按部就班执行,类似纯交付型研发。我们对研发同学的 AI 能力有两方面要求:第一,交付过程中使用 Copilot 或 Vibe coding 生成代码的比例;第二,除了做需求交付,还要看他们是否创造性地用大模型做一些工具或小产品。因此团队之间会进行 AI 率的 PK。“AI 率”是可以被量化成具体数字的,因此在组织层面与团队层面,我们都有明确且可衡量的引导机制。
邹明远: 我的团队主要是产品和运营,虽然不直接带研发团队,但双方合作紧密。研发团队也会像东旭老师提到的那样,通过指标观察代码中 AI 生成的比例,并自上而下进行宣贯。至于产品和运营,由于难以量化,我们更关注一些现象与能力边界的变化。例如,现在产品经理不仅能写 PRD,也能写代码,甚至直接向代码仓库提交。
我希望团队成员能借助 AI 快速进入一个新的领域,并达到能与研发同学顺畅沟通的基础水平。背景是我们之前做 DevOps 工具,涉及很多不同方向,例如代码仓库与发布系统之间就存在知识壁垒。过去人员流动或补位较困难,现在我更加强调利用 AI 快速学习,掌握一个方向中的基本名词、流程和业务逻辑,从而更快上手。
因此,目前我们最关注的是团队是否能借助 AI 高效学习,并快速理解新方向的基础知识,为跨领域合作打下更稳的底层能力。
汤威: 如果团队较年轻,例如前端团队,我个人可能不会采用强推“AI 率”的方式。因为经验告诉我们,像 ChatGPT 刚出现时,不想用的人即使强推也不会用,而愿意用的人能把工具用得很深。同样,AI coding 这类工具也是如此。即使我们购买国外服务包月,也仍有同学坚持“古法手工写代码”。如果他们的思路没转变,即便工具再好也不会用。
回到“优秀工程师”的评估标准,过去我们看代码质量、需求完成度、技术沉淀等,核心是个体对团队和公司的贡献。但现在,写得好、写得快只是基本要求,更重要的是他能为业务带来多大贡献。例如原本需要一个团队完成的事情,如果他一个人能做好,而且质量高,这就是我们推崇的能力。
我会更鼓励团队成员做一些具体技能的拓展。例如团队里审美好的同学,我会让他练习绘制草图、稿件、高保真界面,以便沟通更高效。擅长数据分析的同学,我会让他们结合 AI 做 SQL、做多维下钻分析,为业务提供洞察,例如国庆酒店房型为何增幅明显、背后原因是什么,这些都能通过 AI 快速得出并给业务 Leader 提建议。
此外,在 AI 平台和产品方面,我们也鼓励同学以业务为核心,在平台中实践,从 0 到上线再到迭代与效果达成,且达成并非上线即算成功,而是指标满足业务需求,例如准确率或回收率达到 95% 才算完成。这个过程能带来大量成长。
技术门槛在降低,但对人的要求比过去更高。思维活跃但技术一般的同学反而更有优势,而技术好但不愿折腾的同学会吃亏。至于所谓的“10x 工程师”,其实就是技术强、想法多、愿意钻研的人,相当于给优秀个体配上一支强力团队,他自然呈现出 10x 效果。这也会带动团队去主动对标、主动靠齐,因为大家都希望工作更轻松,也希望有成就感。我更愿意带着团队往这种开放、内驱的方向发展。当然,不同团队性质也会有差异。安全与算法团队更强调严谨、准确率与安全系数,而我们偏工程的团队会更注重效率与效果。
胡一川: 我最近与一位朋友交流,他所在的公司已将 AI 能力纳入全员考核,不仅是产品和工程,而是每个人。我问他如何考核,他说他们与 HR 讨论后形成两个维度:第一,这个人在考核周期内是否做成过去他做不到的事情;第二,他是否能做到别人能做的事情。无论他是销售、财务还是工程师,都按这两个指标评估。我听完觉得特别有道理,因为这会促使每个人扩展自己的能力边界,从而让整个组织的能力像流动的水一样被整体放大、融合,而不再是职责分明、割裂的结构。
汤威: 愿意折腾的同学会主动钻研,但不愿折腾的人如果看不到希望,仍会保持原状。因此我们采取了三个做法。第一是在去年 Cursor 很火的时候,团队里一些同学开始尝试这些工具,有的人使用得非常熟练。我们会让这些同学编写高质量的分享文档,在团队内部进行展示与演示,重点讲解他们如何高效完成任务、如何利用 MCP 等能力进行实操。这样能够带动部分同学主动尝试。这个阶段我们并不强制要求,只强调把工作做好即可,因此主要目的是让大家先感受到价值。
第二个做法是通过具体事务进行引导。例如在全球化项目中,我们需要与 Agoda、Booking 等大型供应商合作,对方提供 API 文档,过去需要大量研发工作才能完成对接。但利用 AI,可将文档自动转成可解析的协议,再通过我们统一标准对接,效率大幅提升。我们也将这些能力产品化,构建平台,让正式员工专注能力打通,而后续再招一些偏执行的同学承担“填空式”工作,从而进一步提升整体效率。这个过程本质上是一个“漏斗”,明确哪些环节用 AI,哪些由人完成,哪些需要更强的工程师介入。
第三是组织层面的推动。公司从上到下强调 AI First,飞猪也是如此。其实在更早之前,业务中大量重复性、可 SOP 化的任务就已开始由 AI 替代。但我认为组织要求只是第一步,更关键的是团队内部的要求,包括考核标准和晋升标准都要调整。我也在思考,国内技术管理者是否应该重新设计技术晋升路径。以阿里为例,AI 出来后晋升标准仍在更新,但其实应该更快。不同管理者对 AI 的接受度不同,团队步调也需要统一。因此团队的晋升体系、绩效标准本身就是重要的引导机制,但最终还是要让同学们看到希望:真的能因此更高效、甚至更早下班。
邹明远:AI 产品大致有两类。一类是应用场景明确的工具,例如 Cursor,其主要使用场景就是工程师写代码。对这类工具,团队中总会出现一些“用得好、爱折腾”的同学,我们会把他们树立为典型,通过激励带动更多人跟进。当然,其中也涉及大家对工具本身掌握程度的差异。
任何 AI 工具都会经历一个阶段:第一次使用时非常惊艳,仿佛能解决 100% 的问题,但真正落地时往往只有 50%–60% 的效果。如何让它提升到 70%–80%,甚至达到稳定可信的水平?我认为需要组织内部的学习机制,也需要从外部引入更好的实践或专家来指导团队持续改进。
第二类是 AI 时代催生的新型产品,例如 Vibe coding 或 NoCode 产品,主要面向非技术序列,用于生成应用。但它们常面临一个问题:大家试用时觉得很强,但不知道在实际工作中该做什么。从产品数据也能看出这一点:上线初期大家会尝试做小游戏或简单后台,但一个月后使用量迅速下滑,因为用户找不到合适的应用场景。
我们目前有两类应对方式。一是文化层面的引导,通过考核或正向激励,让大家不断尝试,不要求必须与当前岗位直接关联,但要持续动手做。可能做 1000 个项目,真正能产生工作价值的只有 10 到 20 个。另一条路径是从具体场景向外扩散。例如 A 团队在数据采集场景做出了很好的实践,我们会横向推广到其他团队,让大家思考是否存在可借鉴的场景。总之,就是尽一切方式让团队更多使用 AI 工具,理解它的能力边界,并不断探索与自身工作的结合点。
王东旭: 首先,仍然强调自上而下的 AI First 战略方向,以及与之配套的考核和晋升机制的重要性。
其次是横向推进。我们会组织许多 AI 小比赛,例如最近技术部举办的 AI 编码大赛。另一个例子是上周五晚上,一位同学在群里分享了一个 Vibe coding 产品,结果大家纷纷跟帖展示自己的作品,一晚上分享了近二十个,这类轻松的横向氛围能自然推动大家投入。
第三是自底向上的推动,每个角色都应该向价值链的上游迁移。AI 带来了全新的生产力,会改变产、研、运、测整个生产关系。举例来说,原本一些业务必须依靠运营人工审核,但多模态大模型出现后,部分人工审核可被替代。人处于生产链上游,AI 处于下游,当下游能力增强,上游必然感到压力,需要转型。例如之前负责审核的运营同学必须学习 prompt、RAG、workflow 编排等能力,才能驾驭模型。
而运营会 prompt 后,反向也会对算法同学的工作内容形成挤压。例如早期 prompt 都是算法同学在写,如今运营能做这些后,算法就需要继续上移,去做更高层的能力构建,例如生成自动化 prompt 工具、构建 SMT 或强化学习的自动化 pipeline,为运营提供更强的基础设施。
胡一川: 过去和现在,你们和团队都在用些什么样的 AI 赋能的工具?
王东旭: 在 AI 辅助编程方向,除了 Cursor,我们公司内部也有类似的代码辅助工具,例如 Kwaipilot。此外,包括 Vibe coding 的各类能力,NoCode 是其中一种,我们内部也有 AutoCode 产品。刚才提到的 Lovable,我个人非常喜欢,还有诸如 Figma、Bolt.New 等工具,我也经常浏览 Product Hunt 查看最新的海内外产品。
从我们自身业务来看,也有一些有趣的尝试。第一,刚才多次提到,我们使用多模态大模型,并在业务场景中尝试训练垂直领域的预训练模型,用于辅助人工审核,甚至完全替代人工审核。其次,多模态大模型不仅在内容理解方面进步明显,在内容生成和内容编辑方面也非常强。我们在 AI 大赛中做了一个尝试:过去遇到夸大虚假宣传的视频,例如“吃一粒药立刻怎样怎样”,模型通常直接拒绝。现在通过多模态模型,我们可以识别视频中具体的违规点,再利用生成式 AIGC 技术对内容进行重新生成或编辑修改,使其在不违规的前提下继续投放。原来审核会直接阻断,现在可以让内容继续运营,这在业界算是一个有意思的创新点。
胡一川:你提到团队里大家不断使用新工具,那在你们团队或在快手内部,对这些新工具的使用是鼓励开放自由,还是会有一些要求或限制?
王东旭: 在 Vibe coding 领域,无论是国内外的工具,或 Product Hunt 上的新产品,我都持续在测试,这仍属于早期探索阶段。回到公司内部的具体业务场景,我们发现开源或公开工具在实际落地中与公司内部环境的适配度并不总是理想。例如 Lovable,其前端代码生成能力非常优秀且界面美观,但后端能力存疑。然而若要打造可投入生产的产品,仅有前端显然不够,后端能力也必须完备,因此我们必须在工具选型上作长期权衡。
此外,每家公司内部都有自己的中间件团队,例如存储、计算等都有内部定制版本。开源或外部工具不一定能适配这些内部体系,因此中间件适配也是必须考虑的因素。未来工具选型一定是综合这些维度来决定。
对一些简单、面向 M 端且无需大规模扩展能力的场景,可以考虑使用 Lovable、Figma 等类似产品。但如果对前后端代码质量、以及前后端 API 的串联要求很高,我认为目前的产品仍有发展空间。同时,与每家公司内部中间件的适配也有较大的提升余地。
邹明远: 首先,我个人认为 NoCode 这类产品未来不可能“一统江湖”,不能解决所有需求。从模型和工程能力看,目前还看不到那种彻底通用的可能性。这类工具适合特定场景,例如 M 端、低流量压力的业务。其次,关于后端能力,我们内部当然也有自己的版本,而内部与外部最大的区别,在于与公司的中间件、基础设施、基础工具之间进行了深度集成与打通。
回到“我们会用哪些工具”这个问题:除了 NoCode 类 Vibe coding 工具外,我们还有团队负责构建相关基础设施工具,或与其他工具做集成。我们团队也有类似 Cursor 的产品,叫 CatPaw,最近刚对外发布,这类产品作为核心能力,我们使用得非常频繁。其他常用的工具,与大家差别不大,包括基础办公类的 AI 化工具。
现在几乎所有工作场景都在经历 AI 化。例如 IM 工具、文档工具、检索工具,它们可能不是纯粹的原生 AI 产品,但都在不断加入 AI 能力。我们的业务领域中,也面向特定行业做应用,例如为餐饮企业快速生成点餐小程序,其中不仅涉及 NoCode,还包含图像素材生成、与微信生态的集成等流程。现在几乎所有工作都在被 AI 改变,区别只在于产品是 native AI,还是传统产品的 AI 改造。
汤威: 我每月在 AI 工具上的支出大约是 100 美元,其中 20 美元用于 Claude Code,20 美元用于 ChatGPT 的 CodeX,约 10 美元用于 GitHub Copilot CLI,还有一些用于 xAI 的 API、推特订阅等。总体加起来约 100 美元,但这些主要用于个人学习、体验优秀产品,同时与公司内部工具作对比。阿里内部也有自研大模型,使用率非常高。
很多时候在做业务探索前,我会先使用最强的模型测试,以便了解能力上限,这样也能为团队制定更明确的“标杆”。我个人日常编码会优先使用 Claude Code,其次是 CodeX,然后 GitHub Copilot,必要时购买 xAI 的 API,但这些主要用于调研和技术研究。公司内部仍以遵循国内法律使用阿里自研工具为主。就个人而言,我强烈建议大家订阅一个 ChatGPT Plus,它对工作和生活的帮助非常大。我过去一年基本很少再使用百度或谷歌搜索,通常直接与 ChatGPT 对话。
例如午休前我会让它做一项研究,我睡醒时它已经完成。我习惯把 AI 工具“用到极致”。从个人角度看,我投入的费用是值得的,因为使用效率远高于成本。
胡一川: 如果能深度使用这些 AI 工具,它们带来的价值远超订阅成本。我从上个季度开始订阅了 Claude Max,每月 200 美元。最初只是想试试看其真正能力,但用了一段时间后发现离不开。尤其是七八月份那两个月,我几乎每天都会深度使用一到两个小时。单从那段时间它为我生成的代码和产出内容来看,花 1400 元 / 月是绝对请不到一个能做到同样产出的“员工”的。后来用于写代码、写文档、写对外内容,我也开始用 Claude Code,它在架构上的灵活性使它已超出单纯 coding agent 的范畴。
我也跟公司同事说,这类工具不只适合研发团队,财务团队可以用来做数据分析,市场团队可以用来生成内容。必须自己亲自试用,才能真正发现它的价值。
胡一川:如果让你选一个近两三年里印象最深的 AI 应用实践,可以不点公司名,单纯从“类型+过程”简单讲一下吗?
王东旭: 第一类是偏设计和创作工具,例如 Lovable、Figma 以及各类 NoCode 产品,这些工具已经给我相当大的震撼。最近我们也在准备一些 PPT,我尝试了 AI 生成 PPT 的 Agent,能力确实很强,比如 SkyWork、Claude Max。
第二类是与我们真实业务场景高度相关的工具。在开户与资质审核中,审核员需要根据广告主提交的资质文件,去政府网站、企查查等多个平台查询资质信息是否合法有效。有的资质文件长达二十多页,且查验站点很多。
在这个背景下,我们发现了一个叫 GUI Agent 的能力。它可以在 Web、PC、Native 等各端执行全自动化操作,而且与早年简单的“按键精灵”不同,它是大模型原生智能化的版本,只需自然语言描述需求即可。例如我告诉它:“帮我核对广告主的某项资质,去十个网站对比真实性,并给我结果。”整个流程就能自动完成。
更令人惊讶的是它具备纠错能力。我让同学做了个实验:在 App Store 或安卓应用市场中搜索“微信”,我用的是拼音输入。GUI Agent 执行后发现路径不通,还会自己回退,就像代码的入栈、出栈逻辑一样。在回退后,它把拼音版的“weixin”改成中文“微信”,再继续搜索。这种智能化程度对我冲击非常大。
邹明远: 过去半年基座大模型的能力并没有像早期那样出现翻天覆地的变化,因此更容易让人眼前一亮的反而是与日常场景结合得好的新产品。例如“猫箱”这类偏二次元的产品,我本来对二次元文化不熟,是听团队里年轻同事介绍的。传统小说是纯文本阅读或听书,而这类二次元产品会用模型构建带入式体验,图文结合、还能互动,提供完全不同的叙事方式。
第二个例子是我想为我们公司打个小广告:过去大家常说“大模型能不能帮你点外卖?”美团推出“小美”后,我第一时间测试,让它帮我点了一份外卖,最后我真的收到了。它既与生活贴近,又能影响到物理世界,感觉与过去的 AI 产品很不同,像是确实在改变现实世界。
汤威: 前段时间有一个“AI 炒币”实验,他们使用 ChatGPT、Claude、千问等模型,给 AI 10 万美元让它交易。ChatGPT 会用一些激进策略反复买卖,而中国模型甚至直接 10x 杠杆做多比特币。这种差异其实与模型内化的价值观、知识和训练策略密切相关。随后又有人做了“AI 炒股”,让模型分析英伟达、特斯拉等公司的行为模式。我发现 AI 在某些场景无法替代人类,特别是需要“人性”“经验积累”或长期世界观判断的领域。但如果人类能恰当地利用 AI 辅助决策,它仍然可以成为有效工具。
相较于文本、图像、视频等“平面世界”的数据,物理世界的复杂度要高得多,李飞飞前几天也发布了一项与 3D 物理 AI 相关的内容。我认为未来更大的发展空间在物理世界 AI,因为它拥有持续变化的环境和不断产生的新知识。平面世界的高质量文本数据基本已被模型吃得差不多,新数据很多是 AI 自己产出的,有一定枯竭趋势,而物理世界不会“耗尽”。
观众:使用这些 AI 工具时,公司或团队在信息和数据安全方面是否有要求?尤其是代码上传会不会有风险?
王东旭: 有,而且管控非常严格,大厂通常要求使用自家提供的大模型辅助生成工具。
胡一川: 所以平时我们使用这些工具更多是做快速原型,从 0 到 1 的探索,而不是用在团队生产环境的代码上。
观众:如何客观量化 AI 为组织带来的效率提升?
汤威:AI 带来的主要是“增效”,而非直接“降本”。降本的前提通常是增效带来的资源重新分配。例如审核场景,过去图片或视频审核需要上千人,用了 AI 后,原团队还在,但可以处理更多任务。原来需要 100 人的审核团队,使用 AI 后只需要 50 人,另外 50 人可以去做更复杂的工作。可以用一个“分层漏斗”理解:哪些交给 AI、哪些交给普通人、哪些交给更专业的人。
衡量方式很简单:比较个人或团队原本的工作量与引入 AI 后的工作量差异,特别是计件类岗位,包括工程师也类似。举例来说,一个需求有长有短,但一年下来可以被拉平;因此用需求数量、需求完成率等指标,以年度对比,就能明显看出差异。短期很难判断,但把时间拉长、人数放大,效果就很清晰。
胡一川:对于想要在组织内部推动 AI 落地的团队负责人,有什么建议?
邹明远: 首先在文化层面,需要鼓励并倡导大家积极使用 AI。短期内可能看不出直接收益,但这是组织文化建设的重要部分。第二,我觉得要把行业内、业界中的优秀实践更快地在组织内部传播和扩散,让团队看到具体可参考的案例和可达到的水平。第三,有些团队可能会担心 AI 的引入意味着人员调整,因此管理者需要正确看待和评估 AI 对组织的价值,想清楚它究竟能带来什么、目标是什么,这些都是非常本质的问题。
王东旭: 我用八个字总结:瞻前顾后,眼高手低。听起来像贬义词,但放在管理者视角就是褒义词。“瞻前”指一线管理者如果要推动 AI,一定要主动掌握前沿的技能与知识,每个月至少花点钱亲自体验先进的工具。“顾后”指要深刻理解自己的业务现状和历史脉络,不能盲目地为用 AI 而用 AI,要明确业务痛点。“眼高”是要了解行业整体水平,不只关注自己的业务或技术,要知道同行、竞品的状态和极限在哪里。“手低”则是管理者不能放养式管理,还是要亲自下场推动具体工作。
汤威: 组织的管理方式本身需要因 AI 而改变。过去的组织像一根层级繁多的大水管,每个员工都是接在水管上的分支,但由于层级多、流程复杂,信息经常会失真。现在 AI 已经能够很好地执行确定性任务,真正的瓶颈不在执行本身,而在信息传递是否通畅。因此这根“管道”应该尽可能顺畅,让每个链接其上的人都能清楚理解业务痛点、优先级和目标。
这意味着组织内部需要确保上下文信息在团队之间能够精准、透明地共享,规则、沉淀、要求都要清晰一致。技术管理者最需要做的,是让这根信息管道保持畅通,让知识和上下文能被精炼、标准化并有效传递。只有这样,整个组织才能真正借助 AI 提升效率。
