数据发布
供给侧：定义“有什么”
把底层表/国库数据包装成可订阅的数据资产，并维护上架、下架、停用和维表关联。
Module Framework
数据发布
发布清单
资产名称创建人状态更新时间
发布配置
发布数据资产关联维表字段口径数据来源
生命周期
已上架已下架国库已停用恢复上架
运营反馈
使用统计订阅人数查询次数失效次数
把底层表/国库数据包装成可订阅的数据资产，并维护上架、下架、停用和维表关联。
数据自助查询 | AI Native Workflow | 2024 - 2025
数据自助查询 Agent Host
Overview & Context
数据自助查询是一个我真正觉得接近 AI Native Workflow 的项目。它不是简单地把聊天框接进数据平台，而是将用户原本散落在"找数、问人、导出、Excel加工、反复核对、沉淀口径"里的工作，重新组织成一条可以被 AI 参与、被用户验证、被系统沉淀的完整工作流。
产品
网页平台 | 企业级数据应用
能力
AI Native 工作流、Agent UX、数据平台、UX 策略、设计工程
时间
2024 - 2025
团队
miHoYo 数据平台
Situation
从工具视角看：旧平台的困境已有“查数能力”，但用户完成任务困难
数据自助查询平台的原始目标是成为"一站式查数工具"，替代用户线下用 Excel 查数、对数的习惯。从功能上看，它已经具备数据资产浏览、订阅、查询、筛选、联查、导出等能力。
数据集市
转化侧：发现并订阅
用分类树、搜索和资产卡片帮助用户发现可用数据，并完成订阅或转入查询。
Module Framework
数据集市
资产发现
搜索最近搜索资产推荐资产卡片
分类导航
财务域采购域销售域人事域
资产理解
资产名称资产描述订阅状态来源说明
转化动作
订阅去查数查看详情权限申请
用分类树、搜索和资产卡片帮助用户发现可用数据，并完成订阅或转入查询。
我的订阅
消费侧：日常查数入口
沉淀用户已订阅资产与自定义联查，是日常查数和再次进入查询的主路径。
Module Framework
我的订阅
订阅清单
资产搜索订阅数据自定义联查
查数入口
查询数据修改配置新建联查字段说明
状态维护
正常权限失效配置失效数据源变更
关系维护
取消订阅联查配置关联维表临时权限
沉淀用户已订阅资产与自定义联查，是日常查数和再次进入查询的主路径。
从用户视角看：查数不是一个动作，而是一条链路
用户是谁：财务 BP、财务分析、经营分析、业务同学。
在接手当前平台，和第一波用户对话后，我更深层的发现是：用户的真实查数过程并不是从“打开一个已知数据表”开始，而是从一个不完整的业务问题开始。
例如，他们想看某个产品的数据，但不知道对应哪个数据资产；知道大概的业务问题，但不确定字段、口径和时间范围；查到了数据，最终还是导出到 Excel 自己做筛选、联表、加工和验证。
因此，旧平台的问题不是单个页面不好用，而是用户完成一次查数任务的路径仍然太长、太依赖经验，也较难沉淀。
对这些用户而言，查数包含五个连续动作：找到正确的数据、理解字段/口径/数据关系、根据业务问题筛选/联查/加工、判断结果是否可信、把有价值的结果留到下次继续用。
传统数据平台更多支撑第 1-3 步；AI Native 的机会，是把理解口径、任务执行、结果验证和资产沉淀重新串起来。AI 负责理解需求、规划任务、调用工具、生成视图，用户负责确认、追问、调整、验证和沉淀。
Task
不是做一个 AI 查数助手，而是设计一套新的数据工作方式
项目目标是让用户用自然语言表达模糊需求，让 Agent 在需求不完整时主动澄清，并把 AI 的结果呈现为可检查的数据视图，而不是只给一段答案。
把一次临时查数，转化为一个可验证、可调整、可保存、可复用的数据资产。
自然语言表达
用户可以先说一个不完整的业务问题，而不是先学习表、字段、筛选器。
可检查结果
结果需要能展示数据来源、处理规则和 SQL，让用户建立可信度。
资产沉淀
一次问数结果可以保存为我的数据资产，并进一步复用或发布为 MCP。
Action 1
用户任务建模：从功能地图转向路径地图
如果按功能模块优化，很容易变成每个页面都改一点，却无法判断用户完成任务的能力是否真的变强。核心判断是先建立查数任务路径，而不是先拆页面。
01 / 04找数据
Action 2
AI 对话交互设计：设计从模糊到明确的澄清机制
澄清不是失败，而是 AI 工作流的一部分。自然语言降低了输入门槛，也带来了不确定性；不追问，答案不可信；追问太多，用户又会觉得 AI 没帮上忙。
01
定义追问触发条件
当信息不足以可信生成时，让 Agent 主动停下来确认。
- 意图识别不清：用户输入无法解析为明确查询类型，例如单表查询、联查或文件加工。
- 槽位缺失：意图清晰但关键信息不完整，例如缺少时间范围、筛选条件或存在歧义字段。
- 执行失败：Skill 或工具调用返回异常，例如表不存在、权限不足或 SQL 报错。
02
设计分层追问体验
根据场景选择交互形式：能选择就选择，无法收敛时再开放追问。
- 选项式澄清：可选范围明确且数量有限时，用选项卡降低认知负担。
- 自然语言追问：范围不明确或选项过多时，用开放式问题引导用户补充上下文。
- Preflight 确认：影响较大的生成前，先展示方案摘要，让用户有机会修正方向。
03
定义对话节奏规则
澄清不是无限追问，而是持续推进双方对任务目标的共识。
- 带着已理解内容追问：每次追问都携带已识别的产品、指标、时间等信息，让用户看到 Agent 有进展。
- 澄清和生成交叉：先生成初步结果，再允许用户通过“改一下筛选”“加一列”等方式局部修订。
- 目标是建立共识：让用户确认“你理解对了”，再进入后续生成与验证。
Action 3
结果可信性设计：让用户敢用 AI 的结果
数据场景的难点不在让 AI 回答，而在让用户敢用。财务同学查的数据会进入汇报、进入决策；如果无法核实，就不会信任。
Insight
数据场景的难点不在让 AI 回答，而在让用户敢用。核心判断是：在高可信场景，透明度 > 效率。
Moves
通过五层可检查机制，从「过程透明」到「结果可调」再到「反馈闭环」。
01
思考过程透明
Agent 的思考链集中在可折叠容器中，默认收起不打断流程；展开后可查看用了哪些表、解析了哪些字段，以及为什么选择这个查询方式。
02
结果呈现分层
统一采用「结论 + 数据/图表」结构，先给结论，再给明细表格和可视化图表，帮助用户快速判断结果是否符合预期。
03
数据来源可查
数据流转展示数据从哪张表、经过哪些处理步骤到达结果；处理规则展示筛选/计算/联合逻辑；SQL 展示实际执行语句。
04
结果可调整
支持筛选、排序、列设置，也允许用户通过页面元素选取指定局部区域，让 AI 在已有结果上做局部修订。
05
反馈闭环
点赞/点踩与埋点持续反向衡量生成质量；结果调整频率和重置率用于发现初始生成质量问题。
Action 4
资产沉淀闭环：从一次性问数到可复用资产
如果每次问数都是一次性的，产品只是一个智能搜索框。真正的价值在于一次问数的结果能否被沉淀下来，变成可复用的数据资产，甚至被其他系统调用。
临时会话 -> 保存视图
表格、筛选条件、排序规则可以保存为我的数据资产，解决重复查数。
保存视图 -> 发布 MCP
有价值的视图发布为 MCP 接口，从个人工具变成组织能力。
官方资产管理
验证过的高质量查询模板推荐给其他用户，降低新用户冷启动门槛。
Action 5
AI Native 协作方式：从交付界面到定义行为
这个项目里，协作方式经历了从静态图到可运行 Demo、再到生产代码和 Skill 规则的演化。本质不是设计流程变快了，而是设计交付物不断靠近产品真正运行的地方。
Deliverable Evolution
交付物不断靠近产品运行时
图 -> Demo -> Commit -> Skill
图
静态界面与标注
Demo
可跑通的对话流
Commit
直接进入研发代码
Skill
可执行的行为规则
01 / 过去
传统瀑布模式
交付物：静态设计稿
信息经过多轮传递，研发只能从图片里猜对话节奏
严格串行流把设计意图压缩成静态截图和标注，默认产品体验可以被固定状态穷举。
用户想法产品 PRDUX 设计稿前后端实现测试上线验收
适用前提
核心体验由确定状态构成，可以先画完再交付。
Agent 场景失效点
非确定性回答、Prompt/Skill 深度耦合、周级迭代，让静态图无法承载决策逻辑。
02 / 现在
我的实践：两次缩短距离
交付物：Demo + MR
反馈延迟从天缩短到分钟，信息损耗趋近零
交付物从图变成可运行 Demo，再进入研发代码本身；设计意图从“传达”变成“执行”。
MVP：cc-agent-sdk Demo动态对话流2.0：Platgit 走查提交 MR
MVP 阶段
用代码代替设计稿，表达动态节奏、Tool Calling 链路和 AI 能力边界。
2.0 阶段
直接拉取研发分支，在生产代码上走查交互/样式，发现问题就修改并提交。
03 / 未来
行为规则成为设计稿
交付物：Skill 定义文件
设计直接进入智能体决策逻辑
当产品本身由 Agent 驱动，设计师的交付物会继续靠近运行时，变成可被执行的 Skill 定义。
intent-skillclarify-skillgenerate-skillAgent 行为
角色变化
从界面设计师转向 AI 行为架构师，定义智能体在什么场景下如何与人协作。
边界变化
当一个人能定义意图规则、写交互 Demo、在代码上验收，角色就更接近产品体验工程师。
Core Insight
AI Native 对设计师的真正影响，不是用 AI 更快生成设计稿，而是重新定义“设计交付物”本身。
当产品体验由智能体决策逻辑驱动，设计的对象就不只是界面状态，而是人和 Agent 协作的规则。
Result
成果与度量
项目结果不只是一组页面，而是一套能被产品和工程继续使用的工作流框架：从 Demo、交互规则、Skill 架构到埋点体系，都围绕找、查、用、留四段任务路径组织。
MVP 全流程
完成数据 Agent 全流程交互设计与 Demo 开发，支持自然语言问数、文件上传加工、数据联查、结果可视化。
2.0 工作流平台
完成从问数工具到数据工作流平台的转型，引入视图沉淀、MCP 发布、官方资产管理等闭环能力。
19+ 真实财务场景
从单表查询到多表联查、从文件加工到异常检测，围绕真实场景验证关键链路。
找数据
搜索无结果率、搜索点击转化率、入口使用分布
AI 对话构建
视图生成前问答次数、视图生成时间、终止思考频率、点赞/点踩比
数据消费
查询成功率、查询后调整频率、重置率、明细/图表 Tab 使用偏好
资产沉淀
视图保存率、复用率、MCP 发布量、临时会话转化率
Reflection
我的 AI Native 思考
这个项目让我明确：AI Native 对设计师的真正影响不是“用 AI 提效”，而是重新定义交付物。当产品本身由 Agent 驱动，设计师的价值在于定义智能体如何与人协作。
设计师角色变化
工作范围覆盖用户任务建模、埋点体系设计、Skill 架构定义、交互 Demo 开发、代码走查与 Merge。
AI Native 产品原则
不是给功能加 AI，而是用 AI 重新组织任务流；在高可信场景，可检查性大于流畅性。
迭代判断
先找到重复且繁琐、或原本做不到的高价值场景做深，再扩展到更通用的能力。
数据自助查询 2.0 不是一个 AI 问数入口，而是一条从模糊业务问题到结构化数据视图，再到可信验证、资产沉淀与复用的 AI Native 数据工作流。