影之刃零 · agentic workflow 探索

人机协同下的
专业进阶之道

影之刃零版本支持中的 agentic workflow 探索

2026 · 用户研究 AI 实践分享

01 / 34

INTRO · 01

相较于功能，AI 更像是地基

AI 不再是一个功能，而是一个地基

就像房子的水、电、wifi——我们不会讨论"这个房子有没有电"，因为没有电的房子根本没法住

未来我们也会越来越少孤立地讨论 AI，因为我们做的每一件事，背后都有它

01

用户体验

02

业务洞察

03

研究方法 · 工作流

基座

AI 基础设施

从"功能"到"地基"

02 / 34

INTRO · 02

Acknowledge

感谢部门团队同行，提供的一切资源和基建

01 · 部门支持

资源、信任、基建

02 · 运营组

调度与协同

03 · 体验设计

产品视角对齐

04 · 团队伙伴

每一个并肩的人

03 / 34

INTRO · 03

初面新物种：主打一个心情复杂

任何东西初接触时，都会遇到学习曲线的问题——
尤其 agent，具备一定（拟人）的硅基智慧

对于我们来说，可能是无感，到心态复杂 | 微妙变化

无感

Eureka

错愕

兴奋

04 / 34

INTRO · 04

"失重感"

这些对话，发生在一周之内——都是大家对 AI 冲击的隐忧

01

新人失去培养环境

基础任务被 AI 接管
新人无路可练

02

观点生成 >> 可靠性 QA

AI 出活速度
远超人对其的判断

03

永不说不

全是"情绪"
没有真正的价值判断

04

隐性知识无法带进上下文

那些"只可意会"的
难以显性化注入

我们的心态：无感 → 震惊 · 兴奋，伴随焦虑|难以理解，习惯性抗拒

05 / 34

INTRO · 05

两个问题｜非常规方法

面对处在非常时期的产品，我们也只能选择非常规的方法

研发反复 delay，研究规划一再延后、调整——项目时间上的紧张感扑面而来

问题 01

重复事不能再重复做

→ 需要一个能快速迭代、灵活硬对的 workflow

问题 02

从紧张的时间里抢点时间

→ 如何通过 AI 提供加速（native in agent）

06 / 34

INTRO · 06

影零项目情境

℞

影零 · 量产期会诊

2026 · 项目研发支持

现状

喜忧参半——早期被 demo 高光盖过的细小问题，开始集中在量产期暴露

主诉

研发临近封版，制作人希望对更完整的体验循环进行验证

我们的角色

飞刀医生

病征

破碎的产品 · 疲惫的团队 · 激进的 DDL

我们既幸运也不幸运——好的一面，是玩得进度最早最多的人；不好的一面，玩的是最破碎的版本

07 / 34

INTRO · 07

因此，我们所想

直接价值

尽可能减少团队的消耗，给研发的投入做减法
给我们的行动增加开放度、透明度
提供最可靠、最关键的洞察与专业建议

间接价值

明确的：第一次长线陪伴一个国单买断制内容游戏
被动的：版本意外推延，我们也是承压团队

用研作为研发合作伙伴，本身的立场就是——让大家以最低成本瞥见一眼未来

在抽象研究"价值"上追求的，与常规的"业务支持"有大致一致，也有少部分的"突破"

团队 0-1 的信任建立更窄的执行窗口和洞察赏味期旷日持久的保密危机感

08 / 34

CHAPTER 01

项目的规划与架构

解放注意力带宽，让研究者回到"每一个当下"

研究员角色从"执行者"升级为"标准制定者"

在执行框架的结构设计上，发挥 agent 长板

"洞察与呈现分离"的架构思维

09 / 34

01 · 规划与架构

研究员角色从"执行者"升级为"标准制定者"

01

我们做了一个决定

让 AI 从项目架构阶段就参与进来

02

我们的身份在起点上发生转变

从"亲手做每件事" → "定义什么是好的标准，让 AI 按标准执行"

03

注意力从执行层，上移到判断层

一系列引导性问答，让 agent 转化成具体问题 / 执行设计

e.g.

Q1

如何还原用户体验流程，回答业务关注的问题

CE 的环节如何设置，如何结合不同体验阶段研究重点

Q2

如何确保观测的代表性

定义样本组成的选择

Q3

研究最终怎么样推动影响

定义项目有几层产物 / 产出节奏 / 对象是谁

04

如此一来，我们在一开始，就确立了最原始的顶层设计

05

AI 按照标准去执行整理

在人的监督下批量化地展开每一个问题后面的分支和执行手段

研究员 × agent · 多轮讨论 · 顶层设计现场

10 / 34

01 · 规划与架构

包括对于保密的标准

买断制内容型游戏的特殊性——
需要让真实玩家在远早于市场曝光的时间，获得相当长的体验

传统

01

强调保密纪律

明确传达边界

→

传统

02

设定严苛的 NDA

法律层级约束

+

基于 AI 优化

03

用户招募风险量化

从源头隔离风险

引入 agent 做参会人选风险量化

社会背景社区环境处世阅历多维因素横向对比

一开始就锁定低风险池——基于 AI 也是为了避免人的 bias 和考虑盲区

11 / 34

01 · 规划与架构

在执行框架的结构设计上，发挥 agent 长板

具体来说，在项目启动时，我们就和 AI 一起设计了整个项目的数据结构

用户画像

怎么建模

每日观察

怎么分类内容掌握 · 难度感知 · 红绿卡

体验问题

怎么分级普遍 / 偶发 · 严重 / 可克服

产出标准

什么形式

观察记录从起初就更结构化，便于每天 8h 体验后，集中讨论收拢

Day 1 FTUE

✓

✓

✓

Day 2

核心循环

Day 3

Boss 心得

每日记录与每天的体验任务 checkpoint 紧密对应——AI 处理时效率非常高，因为它清楚每条信息归到哪个维度、以什么形式输出

AI 协作最有价值的起点，是 "一起设计结构"——先把分析脚手架搭好，后面的一切才能高效运转

12 / 34

01 · 规划与架构

"洞察与呈现分离"的架构思维

我们建立了一个重要的工作环境——将"分析（洞察）"与"呈现"跑在两个分支

环境 A

分析 / 洞察

分析者主导多轮 API call 脚本主导

每日用户反馈记录与分析
专家角色参与观点精炼："用户说‘地图引导差’是标识、还是关卡设计问题？原话能区分吗？"
产出每日的观察判断

环境 B

呈现 / 产出

Agent 主导适配多媒介

同一洞察 → 适配不同受众生成相应每日小结 / 看板 / 摘要
屏蔽观点迭代中不需要的历史结果
用更干净的上下文保证 agent 注意力

研究员专注于洞察判断 · 呈现适配下放给 agent · 洞察更新时所有呈现同步刷新

13 / 34

做好 agentic 架构，最大的价值就在于：

解放我们自己的注意力带宽

——让研究者回到"每一个当下"

研究者不用分心于记录、整理、排版时，注意力可以更完整地留在用户身上

尤其对于连续 3 天内容体验这样的长时间 CE，对用户的理解深度和细节把握，会产生质的提升

14 / 34

CHAPTER 02

项目的执行推进与业务协同

增强分析纵深——用户理解的全景拼合

因此需要在早期对定性分析，给定编码规范

搭建 AI 输出的"信息溯源"机制

交互式看板替代传统文档传阅

15 / 34

02 · 执行与协同

好的 agentic 流程能保证效率，但只有效率也不够

每天晚上需要产出一份当日的研究小结——
8 个用户一整天的行为观察、关键反馈，整合成一份有洞察的文档

研究员负责记录和判断 · AI 负责整合和结构化输出

CE 测试产出的信息是多维的——
需要的不只是速度，还有严谨性

全局理解
日更小结

8 位用户的行为轨迹

每天的态度变化

不同模块的体验反馈

前后阶段对比

16 / 34

02 · 执行与协同

因此需要在早期对定性分析，给定编码规范

我们对用户的定性反馈如何分析，给定了编码的规范

AGENT

结构标注 + 情绪初筛

提供原话分析的
编码脚手架

→

研究者

语境与严重程度判断

主导分析的
方向与权重

→

AGENT

快速定位 + 关联溯源

最有信息量的原话
溯源用户的表达立场与身份

确保分析用户表达时，充分考虑语境和竞品基线

真实痛点vs习惯性抱怨

用户的正面评价→有多大权重

例如：用户说"养成体验不好" — 是资源问题/引导/系统设计？还是多因素耦合？

17 / 34

02 · 执行与协同

搭建 AI 输出的"信息溯源"机制

对不同来源的信息，做了权重上的区隔

01

座谈会一手笔录权重最高

02

每日小结会反馈中等权重

03

用户即兴发言背景补充

权重自上而下递减

为什么这样设权重

越往后，用户体验时间越长——他们的反馈是建立在更充分的版本信息认知之上的

技术契合

更符合 agent 对上下文注意力的分配

落地

AI 撰写分析时遵循该权重体系——每个结论都能对应具体、可信的信息来源

全景拼合的前提是——溯源机制能保障信息源不会被污染数据扭曲

18 / 34

02 · 执行与协同

交互式看板替代传统文档传阅

AI 输出的每日小结是结构化数据——可以直接喂入项目看板

按时间

按用户

按问题

Live

实时

业务方制作人和核心成员可按时间、按用户自由浏览

透明

团队随时查看最新进展信息同步高效透明

信任

主动展示研究过程成果——是 0-1 团队信任建立的捷径

19 / 34

Agent 帮研究员加速了"全景拼合"的过程——

让研究员更快抵达全景视角

把多维数据的关联性快速拉出来

增强分析纵深的前提，是严谨性有制度保障

20 / 34

CHAPTER 03

用户洞察与业务影响

让影响力发生在当下

从"节点交付"到"持续交付"

"多阶段渐进式生产"让报告产出的每步锚点更受控

21 / 34

03 · 洞察与影响

改变研究发现"被看见"的时间

无论架构规划、过程管理多么完善——研究最终的价值，还是要回到项目影响

传统项目从执行到影响业务

测试结束→ 写报告→ 交付→ 业务消化→ 讨论→ 决策

⏱ 中间隔了两周——各方很难再回忆起现场信息，对研究发现的期待也在下降

对影零的支持，在所剩无几的带宽中更加关键——
所以从早期我们就在打算：改变研究发现"被看见"的时间

22 / 34

03 · 洞察与影响

从"节点交付"到"持续交付"

过去 · 节点交付

⋯⋯⋯⋯⋯⋯⋯⋯⋯

📄

做完后才交付
仅一份最终报告
影响力集中在末端

现在 · 持续交付

📊

📋

📈

💡

📑

边做边交付——AI 驱动的实时看板和结构化数据流
从测试第一天起，研发团队就能看到
参会用户构成 / 每日进展 / 体验问题矩阵

同一份洞察，通过看板、摘要等多种形式触达不同决策者——影响力通过多触点覆盖被放大了

23 / 34

03 · 洞察与影响

"多阶段渐进式生产"让报告产出的每步锚点更受控

最终报告所承担的价值，有相当一部分已经被前移了
最终产出更像一个形式上的讨论材料：有空间增加更多针对问题优先级和影响的判断|提出更多 what-if|促进团队共识

SOTA "力大砖飞" 直出→ 不可控

人机混合左右开弓→ 仍有断裂

我们能分享的较优路线 — one thing a single step, rule of three

01

定性小结

→

02

PPT 文字大纲

→

03

文字版报告逐字稿

→

04

线框稿

→

05

线框稿 plus

→

06

美化初版 80分
之后人为接手精修

为什么这么做

减少"抽卡依赖"——增加过程的 harness

怎么做到

更高频的 restatement——主动在每个节点上对记忆做全量召回（类似 system prompt 级别的权重）

24 / 34

03 · 洞察与影响

为什么听起来这么"绝望"

其实探索过程仍是有趣的，当前卡点更多在 agent 能力，而非工程策略
——我们仍可对发展抱有信心

V1

10 min

→

V6

6 hrs

→

V12

3 天

阶段一

内容骨架

先快速验证分析框架是否正确

研究员只需聚焦分析判断
不被排版美化分散精力

阶段二

呈现美化

确认骨架后再投入美化工作

避免"花了很多时间做漂亮
但方向错了"的浪费

先验证骨架，再投入美化——迭代速度更快，试错成本更低

25 / 34

CHAPTER 04

产出交付与研究资产沉淀

获取项目资产与洞察的复利

让项目经验沉淀为研究资产，形成知识飞轮

持续完善 Agentic Workflow，沉淀团队记忆

26 / 34

04 · 资产与沉淀

让项目经验沉淀为研究资产，形成知识飞轮

我们把项目过程中摸索出的方法论编写成 10 个结构化的知识模块

写作标准

设计规范

交付流程

数据架构

编码规则

溯源机制

看板模板

报告流水线

…

memory.md

10 modules

项目 1

100% cost

建立标准

项目 2

~30%

部分复用

项目 N

→ 0

直接加载

团队做的每一个项目都在让 AI 变得更强——这就是飞轮

27 / 34

04 · 资产与沉淀

持续完善 Agentic Workflow，沉淀团队记忆

Agentic 沉淀，与传统用研沉淀的最大区别——
由"形式"走向"实用"的一步巨大跨越

传统做法

📦

复盘会 / 总结报告

一次性集中产出
之后束之高阁
知识依附于人，易流失

→

Agentic 沉淀

🧠

实时知识库

每次方法论迭代实时更新到知识库
每次标准的完善都被记住
知识不依赖于人

AI 扮演了"团队记忆"的角色——它记住了所有方法论、设计规范、历史决策
知识不会因为时间流逝或人员变动而丢失

28 / 34

CHAPTER 05

最后，是一些思考和 tricks

短期理性，长期乐观；卡点是行业的卡点，不是工程的

Q1Skill 应该怎么用？

Q2什么时候用 agent，什么时候用脚本？

Q3项目管理 AI 化的关键挑战？

29 / 34

05 · 思考 tricks · Q1

我应该如何开始用 agents、用 skills

这个东西没有那么高深——拿 skill 做一个拟人的表达，归根结底他是一个标准化工程的说明书

是什么

规则（指令）调用的自动化载体

解决什么

减少重复性的指令交代规范解释

带来什么

减少重复劳动 · 提升精准度优化上下文资源占用

🏋️

就像运动器材的 fitting——减少你在行动中的肌肉劳损

30 / 34

05 · 思考 tricks · Q2

什么时候用 agent，什么时候用脚本

需求的确定性和任务复杂度，决定了你该用哪种方式 — 不是 agent 越多越好

高 ↑确定性↓ 低

高确定 · 简单

脚本 / API call

规则明确 · 无需推理
最便宜最稳

高确定 · 复杂

脚本流水线 / workflow

步骤多但每步规则清晰
用 workflow 编排，不需 reasoning

低确定 · 简单

单次 LLM 调用

模糊判断 one-shot 能搞定
分类、抽取、改写等

低确定 · 复杂

Agent

需要推理 + 多步 + 工具调用

⚠ 警惕 subagent — 表面解决上下文拥挤，实则转化为 agent 间通信损耗与一致性难题，成本指数级飙升

← 简单任务复杂度复杂 →

31 / 34

05 · 思考 tricks · Q4

性质变难+标准抬升——Agent 交付永无止境的最后一公里

Agent 从 demo 走向真正落地，最大的难点已经从 "能不能执行任务" 变成 "能不能完成收尾" —— 这件事没有终点

朴素直觉

50%AI/50%人

90%AI/10%人

AI 完成 50%，人类就只需做剩余 50%；AI 做 90%，人类仅需负责剩下 10%

线性替代的想象

真实情况

90%前段 · 低密度/10%最后 · 高密度

前 90% 是生成 / 整理 / 初稿低价值密度
最后 10% 是判断 / 取舍 / 验证 / 交付高价值密度

错误机器测不出|标准没写在任务里|AI 无法独立完成

—— 而且，"足够好"的定义在同步前移

AI 能快速处理大量低密度执行任务，但决定质量的是少数高密度交付环节 · 今天的 99 分，明年可能只是 50 分

AI 没有消除最后一公里，反而让它成为价值最高的环节

32 / 34

收束 · 01

定调的总结

短期 · 长期

短期，AI 的预期不妨理性
长远我们还是非常乐观

不要放弃古法

虽然 AI 很强，但请不要放弃逻辑能力

需要强化什么

writing 能力
构建 context 的能力
控制熵增——更精准描述问题、需求、知识
connecting the dots

33 / 34

收束 · 02

我们的卡点，也是行业的"卡点"

卡点

memory degradation
上下文注意力衰减
lost in the middle
记忆召回效果
多条指令对注意力带宽的挤占和争夺
全局 .md 文档、RAG 带来的指数级消耗上升

擅长

高度可标准化、重复性的任务

基础问卷
用户招募表
执行文档类产出

需求与产出预期可高度被标准化、明盘

不擅长

"隐性判断层"——即便 SOTA 模型也很难

把控观点的火候 / 颗粒度
优化 PPT 叙事的观点密度和取舍

工具最需要的是确定性，一致性

——agent 作为工具本身，仍有很大"提升"空间

34 / 34

END

Thanks

人机协同下的专业进阶之道

影之刃零版本支持中的 agentic workflow 探索

END