Patrick Neeman主张由AI工具使用者制定策略而非运营团队

从业者知道什么是好的输出，并应拥有最终决定权，而运营团队负责处理基础设施。

想象一下，一位研究员将 12 份访谈转录稿输入到综合工具中，得到了一个整洁的主题和引用。她亲自进行了其中六次访谈，因此在一分钟内就知道没人说过 那句话。

谈判合同的经理不会发现这一点，因为有些人缺乏做出这种判断所需的实践经验。

设计和研究运营团队一直负责处理许可证、同意书和供应商合同。当人工智能工具出现时，购买它们变成了决定它们的 用途。

这是本末倒置的，因为这不像选择 Figma 或其他工具那样，相同的输入会产生相同的输出，并且可以用检查清单来评估 它们。

在行业格局稳定之前，使用这些工具的人应该直接对策略负责，作为负责人为每个决策承担责任。他们知道该寻找什么。运营团队应该负责确保他们的选择安全的基础设施。

招聘信息已经显示出技能差距，一些团队显然不具备适应这个世界的技能，也缺乏跟进行业的主动性，这令人 遗憾：

• Okta 正在招聘一名 高级设计运营项目经理，代理式设计，该职位需使用 Claude Code 和 Cursor。
• Yahoo 发布了一个 设计运营经理，系统与 AI 赋能 职位，以负责其工具路线图。
• Etsy 希望招聘一名精通 Claude 和 Cursor 的 设计运营总监。
• Mistral 想要一名 产品运营经理（DesignOps），能够自动化团队的协调和报告工作。

我在 UX 领域担任球员兼教练已超过 20 年，并撰写了 uxGPT: Mastering AI Assistants for User Experience Designers and Product Management Professionals。这就像早期的互联网时代，当时进入这个行业的人不了解工具，做出了许多糟糕的决定。

我们应该避免重蹈覆辙。

统计影子 工具

战略在运营之外制定的第一个迹象是影子技术栈。在 Microsoft 的 2024 Work Trend Index 中，78% 在工作中使用人工智能的人自带了工具。在 UX Tools 的 State of Prototyping: Spring 2026 调查中，59.1% 的设计师在过去六个月里用人工智能构建了自己的工具、应用或实用程序。

每一个影子工具都是那些能分辨好坏输出的人投出的一票。这也是对运营团队不理解这些 工具的一票。

许多运营团队正在挣扎，他们落后是因为没有花时间关注趋势。在 The State of Research Operations 中，这是一项由 User Interviews 于 2025 年 12 月对 21 位专家进行的研究，其中六人质疑他们的角色有多少能 存活下来。

我看到一些组织将这些团队更名为“智能体运营”（agent operations），因为现有团队尚未掌握这些工具或缺乏相关技能。

这不仅仅关乎用户体验（UX）。

在各行业中，团队正在摸索如何围绕人工智能进行重组。在麦肯锡的 《2026 年 AI 现状：迈向投资回报之路》中，近四分之三的高绩效者重新设计了工作流程，而其他企业中这一比例仅为四分之一。

不懂工具的人会被懂工具的人取代，因为后者知道如何将其应用于自己的工作流。

2023 年《哈佛商业评论》对 Karim Lakhani 的采访以此为题：“AI 不会取代人类，但会用 AI 的人类将取代不会用 AI 的人类。”

从过往浪潮中学习

1979 年，VisiCalc 随 Apple II 发布，买家几分钟内就理解了它。其出版商联合创始人之一 Peter Jennings 在 VisiCalc 1979 中回忆道，他在 Tandy 总部发现经理们的办公桌上摆着苹果电脑，买来是为了运行电子表格。

Tandy 通过 Radio Shack 销售自己的电脑，但其经理们仍然绕开它们去使用其他设备。

经理们知道预算模型需要做什么，因此他们能在几分钟内评判 VisiCalc。

软件即服务（SaaS）重复了第一种模式。在其 2019 年 Form S-1 文件中，Slack 告诉投资者，组织内部的使用通常自下而上开始。Slack 之所以能逐个团队地传播，是因为负责内部工具的人不理解用例，或者没有尝试去理解。

早期互联网展示了另一面。

到该十年末，Jakob Nielsen 已经测量出大公司犯的错误。在他 1999 年的文章 谁犯了网页设计的“十大错误”？中，美国最大的 10 家公司在他的列表上的平均违规率为 20%，而访问量最高的 10 个网站的这一比例为 13%。

最大的预算买来了比那些生活在互联网上的人更多的错误。人工智能工具正同时以更快的节奏重演这两种模式。

指出评估差距

我称之为评估差距：批准工具的人与能够判断其输出何时出错的人之间的距离。生成式工具包含更多细微差别：工具运行哪个模型、如何处理长文本记录，以及是否显示其来源。

任何缺乏专业知识的人都会忽略这种细微差别及其中的失败之处。

在法律科技领域，一份遗漏了赔偿例外条款或无法区分转让与控制权变更的合同摘要，对于从未进行过谈判的人来说读起来似乎没问题。

生成式工具每次都能产出看似合理的内容，而错误隐藏在只有从业者才会检查的细节中。

主题专家（SMEs），即因从事实际工作而了解某个领域的人，拥有优势。Anthropic 于 2026 年 6 月发布的关于约 400,000 次 Claude Code 会话的初步研究 Agentic coding and persistent returns to expertise 发现，专家会话达到验证成功的频率是新手会话的两倍多。作者将此归功于领域专业知识而非编码技能。一位了解定价模型的产品经理能捕捉到遗漏了企业层级使用上限的生成需求。一位了解设计系统的设计师能发现凭空发明了第四种按钮样式的原型。

我与生成式工具打交道已有近四年，在此之前还与其他人工智能合作了七年。这段经历告诉我，在新工具上应该优先检查哪些输出。

别再数 席位

运营团队衡量的是他们能看到的东西：席位、支出、续订和登录次数。这些数字适合许可证管理，却不符合战略需求。更好的指标来自领域专家（SME），例如经过转录文本核查后仍成立的合成声明占比，以及每项已完成研究的 token 成本。

在 User Interviews 的研究中，八位专家描述称，工具管理在工作中的比重日益增加。资金紧张：17 人表示其职责范围扩大了，而 12 人表示预算、人员或资源持平甚至 缩减。

这个案例表明——如果业务部门无法看到业务影响，那么这一系列职位就会被裁撤。

席位正在让位于 token。在 Gartner 预测到 2028 年 AI 编码成本将超过开发人员平均薪资一文中，Gartner 指出，自 2026 年 6 月起，编码供应商正从按席位收费转向按消耗量定价。决定哪项工作值得使用最昂贵的模型，需要一位了解该 工作的人。

工具臃肿是过去运营失误的煤矿金丝雀。这些失误正在导致该领域的岗位流失，运营团队必须在建立信誉之前先解决这一问题。

在 UX Tools 调查中，53% 的设计师表示过多的工具拖慢了他们的速度。不断膨胀的技术栈意味着没有具备判断力的人来决定每个工具的用途，这是负责者的能力 问题。

一旦领域专家确定了哪些工具因其价值而应被保留，运营就可以削减数量，因为这是他们的 权利。

把管道交给 运营

运营依然 重要。

Peter Merholz 在 Peter Merholz：敏捷如何使设计师沦为像素搬运工这篇 2020 年的 Superside 访谈中阐述了这一观点。“如果你不关注运营，车轮就会脱落，”他 说。

人工智能增加了管道工作，包括从业者构建的工具和工作流的合同与维护。即使在法律科技领域多年后，我也不想负责合同事宜。我曾在一个团队中，内部工作流应用程序变成了维护噩梦。因此，根据评估差距划分决策权：

• 掌握判断权。使用工具的领域专家（SME）是团队采用哪些工具以及何种输出可被视为合格的直接责任人（DRI）。他们制定战略。
• 运行管道。运营负责安全和隐私审查、合同和数据边界、访问权限、预算和维护。他们确保流程 顺畅运行。

从业者应决定什么是好的标准，而运营应使其安全地得以实现。

糟糕的决定即将到来，必须有人为此负责。许多运营人员认为自己对这些选择的影响力超过了其经验所能支撑的程度，而从那个位置制定战略无异于玩火。

选择了会捏造引语的工具的研究员可以解释失败原因并修复审查 步骤。

从未开展过研究的运营经理只能取消合同，而且通常行动过于迟缓。应将这种安排视为临时性的，因为我们正以光速前进，并在该领域如所有创新周期一样稳定下来后重新审视所有权归属。

结论

Tandy 有自己的电脑要卖，但其管理者仍然购买 Apple II 来运行电子表格。一旦负责预算的人找到了更好的工具，官方计划就失去了意义。如今设计和研究团队也面临同样的情况，影子技术栈就是证据。

现在正是重新评估运营团队的好时机，就像我们重新评估设计系统和其他角色一样：他们提供什么价值？工作需要什么技能？UX 领域和所有其他领域一样，必须向更少角色、更多技能的方向演进，因为角色头衔是自私的：它们保护的是地盘而非工作本身，这正在损害该领域。在运营之下蓬勃发展的工作，是让优秀决策得以规模化的基础设施。

从业者也有工作要做。掌控战略意味着写下质量标准，分享有效的工具而不是将其隐藏，并淘汰那些不再产生回报的工具。想要拥有决策权的设计师必须在预算审查中为其辩护，用关于工作的数据说话，而不是 登录次数。

想象一下那位研究员，她在不到一分钟内就发现了虚构的引用。把决策权交给她，并把确保行动安全的工作交给运营团队。

行动项

• 制定决策章程。指定三到五位每周使用人工智能工具的领域专家（SME）作为直接责任人（DRI），决定设计和研究采用、续订或弃用哪些工具，并对结果负责。将职责划分写在一页纸上，由运营团队负责安全、隐私、合同、访问权限、令牌限制和维护，并在该领域稳定之前每六个月重新审视一次。
• 建立任务基准测试。收集 10 个你的团队信任其答案的真实任务，例如编码访谈或完成的流程，并在任何人签署合同之前让每个候选工具在这些任务上运行，对捕获的错误、所需的编辑、节省的小时数和令牌成本进行评分。用结果来解决关于工具的争议。这是 Ethan Mollick 在 Making AI Work: Leadership, Lab, and Crowd 中推荐的那种内部基准测试。
• 揭示影子技术栈。询问团队他们使用哪些个人工具以及用于什么目的，承诺回答不会受到惩罚，并将这份清单视为评估的候选名单以及需要削减的冗余数量。
• 重写运营职位描述。像评估设计系统那样重新评估设计和研究运营的目的，并在招聘或培训时注重实际工具技能、令牌和预算治理以及供应商管理，而不仅仅是合同 工作。