NN/g 提出 Research-in-the-Loop：UX 研究如何适配 AI 研发速度

内容摘要：随着 AI 极大提升了开发速度，用户研究如何跟上节奏成了新难题。其实，用研可以明确每次发布需要衡量什么，并帮助团队从中发现更有价值的信息。

发布速度正反超用研

随着 AI 智能体编写的代码越来越多，构建软件的经济逻辑正在被重塑，长期以来打造易用软件的成熟做法也随之改变。类似的技术变革在历史上并非首次发生。

早期的摄影师节奏很慢。胶片昂贵，曝光耗时，而且必须等胶卷冲洗出来才能看到成片。因此，每一次按下快门前都需要精心构图。

后来，数码摄影彻底改变了拍照的经济学逻辑。现在，你只需按住快门连拍数十张，查看效果，微调后再拍。你依然需要瞄准对焦，但大量的试错与学习都发生在拍摄之后——因为每拍一张几乎没有成本。

软件开发目前也在经历同样的转变。有了 AI 编程智能体，许多团队现在只要选定一个方向，就能迅速开发、发布并观察实际反应。如果方向错了就改，因为迭代成本极低。

然而，如果产品发布的速度比做一次用户研究还要快，用研该何去何从？与废片不同，一个糟糕的上线版本会直接影响真实用户。因此，研究不可或缺，但必须做出改变，以跟上 AI 时代的开发速度。我们把这种转变称为研究在环（research-in-the-loop）。

要讲清楚这一点，我们和 AI 一样，也需要了解一些背景。

软件研发的成本

在软件发展史的大部分时间里，开发成本高昂，而修改已建构的功能更难。开发一个功能可能需要几个月；一旦把错误发布出去，往往要等到下一个完整的发布周期才能修复，这不仅耗费金钱和时间，还会损害客户的信任。

因此，形成性研究总是先行一步。在工程师动笔写代码之前，团队就已经完成了用户调研和方案验证。

AI 编程智能体大幅消除了上线后修复错误的成本。当一个功能可以在一个下午搞定，开发前耗费数周做研究就变得难以立足，许多团队如今选择“先发布，后验证”。

但上线只能告诉你“发生了什么”，却很少能告诉你“为什么会这样”。团队看着数据看板，能发现用户流失在某个流程中，却看不出他们原本想做什么，或是哪里困扰了他们。而这正是用户研究一直在解答的问题。

快速做出错误的东西依然是失败。无论开发速度有多快，研究都至关重要。但核心问题在于：用研究竟该如何适应 AI 驱动的开发节奏？

答案仍在探索之中，但新的可能以及对传统实践的迭代更新已经初露端倪，值得深入探讨。

同样的成本下降也适用于用研

这种让前期漫长调研显得不再合理的转变，同时也为用研打开了一扇新大门，使其能够在 AI 速度下的产品开发中发挥更大价值。

回顾一下过去研究人员通常需要工程团队提供什么：用户放弃某个流程时弹出的拦截问卷、新功能的事件埋点、针对特定版本的反馈按钮、展示流程卡在哪里的监控看板。每一项都需要耗费工程时间，而工程资源往往优先投给新功能的开发。

如今，编程智能体在开发功能的同时就能顺便把这些工具搭好，往往只需要在需求里加几句话。搭建研究所需的监测机制，成本已经变得像写其他代码一样低廉。

借助 AI，团队可以在构建软件的同时直接搭建研究机制，从而让开发与研究之间的闭环更加紧密。

研究在环

在 AI 领域，“人在回路”（human-in-the-loop）指人在原本自动化的流程中负责审查或审批决策。随着越来越多团队开始构建基于智能体的工作流（有时被称为软件工厂，即输入需求，输出可用的软件），人们开始思考：在这个闭环中，人类究竟应该处于什么位置？

“研究在环”（Research-in-the-loop）是一种将 UX 研究融入 AI 辅助软件开发的方法，旨在让研究活动跟上更快的开发节奏。它利用 AI 的能力，在开发产品功能的同时顺便构建基于埋点和监测的评估机制，并明确何时需要其他研究方法（如开放式探索），以此为开发决策提供依据。

在构建之前，研究可以帮助明确发布版本需要采集哪些数据；在构建期间，编程智能体在实现功能的同时把这些数据采集机制一并做好；发布之后，研究人员分析实际表现；而他们得到的结论，又会反馈到下一批需求中。

“研究在环”可以支持多种不同类型的研究活动：

评估：调整是否带来了预期的效果？是否引发了预料中的问题？通过追踪预设的明确指标，监测埋点能够帮助解答这些问题。
排查：用户为何会表现出这种行为？发生了哪些团队未曾预料的情况？监测机制能揭示数据中的异常，进而引导研究人员（通常通过定性研究）展开进一步调查。
发现：团队未曾预料到的需求、行为或问题有哪些？解答这类问题往往需要更开放式的研究，而不一定与具体的产品发布或监测机制绑定。

这几类活动相辅相成。监测机制可以大幅提升评估与排查的效率，但无法取代独立的开放式发现。

因此，“研究在环”意味着需要重新审视如何在 AI 辅助开发中分配研究资源：哪些问题可以通过持续评估来回答，哪些需要独立探索，哪些又必须在开发启动前完成研究。如何最好地平衡这些活动，目前依然是一个开放性课题。

一个颇具潜力的切入点，是在开发产品功能的同时顺便构建研究所需的监测机制。

从研究需求到监测机制

在 AI 辅助开发模式下，团队可以在同一份需求文档中同时写明研究与产品需求，编程智能体在实现功能的同时，就能一并构建好所需的监测埋点。随后，研究人员可以利用收集到的数据指导后续的设计改进，并在适当时机继续推进其他类型的研究。

支持这一流程的一种方法，是在团队及其编程智能体所依据的需求文档中增加一个“调研”（Research）板块。该板块可以用通俗语言编写，存放在与其他规格说明并列的文件中，以便人类和智能体都能阅读。

举个例子，假设某款客服工单系统被拥有多个支持部门的企业所使用。以往，需要转交给其他部门的工单必须重新回到中央队列排队；而某个产品团队正在开发一项新功能，允许部门之间直接互转工单。在 AI 的助力下，这项功能的开发和发布速度会非常快。

该功能的需求文档（在 AI 辅助开发团队中常被称为“规格说明”或“意图”文档）中，针对调研的部分可能会写成这样：

## 调研

**预期效果：**允许部门间直接流转工单后，工单能更快送达对应团队，交接次数也会减少。

**符合预期的迹象：**工单从创建到解决的耗时缩短；流转经过三个及以上部门的工单数量减少；按周转时间衡量，单张工单的整体支持成本下降。

**出现问题的迹象：**被打回重新审核的工单变多，或者被客户重新打开的工单增加。

**需要跟踪的指标：**每一次工单交接：发送部门、接收部门、等待时长，以及是否被退回。在专供调研团队的小型看板中展示这些数据，按部门而非按个人进行归类，目的是帮助调研人员确定该访谈哪些对象。

**何时进行访谈：**当某个部门退回工单的比例异常高，或者工单在该部门出现积压停滞时，安排对该部门员工进行情境访谈（contextual inquiry）。

读取这份规格说明的编程智能体在开发该功能的同时，就能一并构建事件日志埋点、数据看板以及退回工单的相关提问，让调研所需的监控工具与软件同步上线。

规格说明中的前三项明确了团队希望评估的结果。它们帮助团队成员判断最初的预测是否准确，并特意兼顾了用户体验指标（更少的交接次数）与业务指标（单张工单支持成本）。事后将用户行为与业务成果关联起来往往非常困难，而在这里，这种关联在软件发布前就已被设计进了系统当中。

最后两项则帮助调研人员深入排查数据所暴露出的问题。看板虽然无法解释工单为何会在某个特定部门停滞，但能指引调研人员该去找哪个部门沟通。此外，独立于这些数据信号之外的其他调研，还能发现埋点监测未能覆盖的问题或需求。例如，调研可能会发现客服人员往往会绕开正式的工单转交流程，转而通过与其他部门熟人的非正式沟通来处理问题。由于这些互动发生在工单系统之外，因而很难反映在数据中。

需要明确的是，这份规范还算不上完整的评估设计。它虽然确定了要衡量什么，却无法证实所观察到的指标变化是否由新功能引起。例如，新版本上线后工单处理时间变短了，我们怎么确定这是新功能的效果，还是因为人员调整或季节性业务量变化导致的？一次严谨的评估往往不仅需要一套指标，还可能涉及设立对照组、确定样本量和观察周期。此外，研究人员还需要判断这些指标能否如实反映预期效果：举个例子，如果系统只是减少了工单在队列里的排队时间，而实际处理时长并未缩短，那么解决时间变短并不必然意味着技术支持成本的降低。

AI 可以让数据埋点和对照实验对研究人员来说变得触手可及，但他们仍需自行判断需要哪些证据，并确保以科学严谨的方式来采集和解读数据。

定量与定性研究融入闭环

这里蕴藏着海量的数据潜力。因此对定量研究而言，这可以说是一个极好的时代。每一次版本发布都能从真实用户群体中获取数据。研究人员可以借助 AI 搭建仪表盘，把支持工单、满意度评分以及产品内行为数据整合在一起，并完成初步的综合分析。

然而，定量分析只能覆盖上线版本预先设定抓取的内容，它反映的是用户的行为表现。要想解释数据背后的规律，挖掘全新的用户需求，依然离不开定性研究。

因此，定性研究始终不可或缺，改变的只是它嵌入整个闭环的具体方式。定性研究可以采取多种并行方式展开，例如：

固定节奏。访谈调研可以按固定周期（例如每周）常态化开展，而不与软件发布强行绑定。研究团队可以将当期的调研重心放在最近上线的功能上，借此检查核心工作流、评估整体用户体验的健康度，或者开展其他有价值的探索性研究。
捕捉异常信号。上线数据或收到的用户反馈可能会暴露出一些需要深入探究的现象，而用户研究正是展开这类调查的最佳方式——例如，数据可能会指向某个值得探究的群体或环节：某个部门的工单经常卡住、某类用户表现出异常行为，或是用户在流失问卷中留下了不同寻常的回答。
辅助重大决策。有些决策一旦做出就很难推倒重来，比如定价策略、客户承诺、敏感数据处理方式，或是引入全新的认知模型。这类决策必须在团队拍板前拿出充分的事实依据。例如，编程智能体可以在功能正式开发前快速搭建交互原型，协助完成前期调研。

在快节奏的 AI 驱动研发闭环中，传统用户研究该如何完美融入，目前尚未形成定论。但上述几种模式，正是当下许多团队正在积极尝试的方向。

Research-in-the-Loop framework: research methods feed a repeating cycle of Specify, Build and Instrument, Release, and Evaluate and Learn. — “研究入环”（Research-in-the-loop）一方面通过数据埋点将效果评估嵌入 AI 辅助的研发周期，另一方面也借助传统的调研手段，为接下来的产品规划和探索方向提供指引。

新工作与新技能

将研究融入研发闭环，为研究人员催生了全新的工作形态：

撰写编程智能体能够直接执行的研究需求
将研究方法封装为智能体技能，例如根据功能设计意图自动起草调研需求
自行构建工具：数据看板、拦截式问卷、各类原型变体
持续综合分析新收到的用户反馈和工单；一旦数据出现异常，立即自动触发新一轮定性研究

用户研究板块与UX 背景信息及产品需求文档并列存在，成为团队开展研发的直接依据。

其中部分工作要求研究员掌握以往不常涉足的技能：

熟练编写技术规范：读写 Markdown 格式的规范文档，掌握基础 Git 操作
调度编程智能体：指挥智能体构建功能，并验收交付成果
熟悉数据埋点与指标体系：了解事件埋点、用户分群、功能开关（Feature Flags）以及灰度发布
数据底层管道：熟悉 MCP 协议连接、各类 API，以及各环节的数据访问权限

但这套闭环对用研核心能力的要求不降反升：提出切中要害的问题、规避偏见、在归纳综合时准确判断、设计严密的定量实验并分析数据，以及恪守研究伦理。智能体可以在几分钟内生成一份问卷，但问卷能不能问对问题，全靠研究员把关。

待探讨的问题

“研究在环”（Research-in-the-loop）目前仍处于概念倡议阶段，还有许多未决的问题：

不同类型的研究该置于何处？探索性、基础性和长期跟踪研究，可能各自适合闭环中的不同节点。
如何监测并评估系统层面的连带影响？某项功能单看运转正常，但可能会波及系统其他模块。
如何设计埋点，既能得出可靠结论，又能避免 AI 综合归纳时凭空捏造规律或带入偏见？
如何判断何时该用传统研究方法，而不是持续评估？
发布节奏、数据信号与决策三者该如何平衡？如果只跟着信号走，团队就只能研究那些已经埋了点的内容。
新版本上线后，什么样的数据才能算作有效证据？短时间内伴随大量噪音的数据，以及用户自发填写的问卷，在效度上都有很大局限。
对每次发布都做量化评估，会带来什么影响？这会不会让团队偏向于追求易于衡量的微小改进，从而忽视了更重大的命题？
研究需求到底归谁管？是研究员、产品经理，还是双方共同负责？由谁来审核？
做到什么程度算过度？应用内弹窗拦截和调研如果频繁打扰同一批用户，埋点过多还会让用户觉得被监视。

如何起步

无需重组团队也能立刻开始尝试：挑一个版本，走通一次端到端流程。

评估数据就绪情况。梳理用户信号分布在哪些渠道，确认你和团队的智能体能够接入哪些数据源。
撰写一个研究板块。写下一个假设、成功与负面影响的判定标准、需要追踪的指标，以及何时需要与用户访谈。
与团队同步。把方案拿给负责该版本的产品经理和工程师看，推动将其内嵌到开发中。如果当前版本还不具备条件，也可以先用 AI 从现有数据中挖掘洞察。

跟上 AI 节奏的用户研究

现在直接上线版本的成本，往往比前期做一次大规模研究还要低。然而，即便团队发版速度前所未有地快，依然需要知道上线的内容到底有没有用、为什么有用，也依然需要挖掘尚未被发掘的用户需求。让发版成本大幅下降的技术红利，如今同样能让研究员把这些答案直接融入每一次版本发布中。

这是研究团队以往从未有过的机遇。多年来，研究人员只能申请工程支持并苦苦等待。如今，他们可以直接指明一次发布需要采集哪些数据，并看着这些机制与功能同步开发落地。

手持数码相机的摄影师拍下的照片远比用胶卷时要多，但最终依然得有人懂得挑出哪一张才值得保留。