买完票后,用户不知道下一步做什么。
订单信息很多,但真正有用的动作不够清楚。
中转时间只有 55 分钟时,用户很难判断风险。
够不够、怎么走、行李是否直挂,都需要被提前解释。
航班延误后,用户不知道该怎么办。
需要的是改签、后续行程和服务兜底,而不是更多通知。
用户并不缺信息。
缺的是“哪个方案更适合我”,以及为什么。
真实演示
北京飞巴厘岛,香港中转延误后的处理过程。
这个移动端 HTML 原型展示一个真实任务:用户查看航班风险、确认中转安排、理解行李规则,并进入改签或后续服务。
当前场景
北京 → 香港 → 巴厘岛。香港中转时间紧,前序航班出现延误。
当前问题
是否来得及登机、行李是否直挂、是否需要改签,用户无法快速判断。
AI 如何帮助
识别中转余量、延误影响和行李规则,把复杂判断解释成下一步。
用户完成什么
快速判断风险,找到服务入口,降低不确定带来的焦虑。
真实产品逻辑
先拆清楚用户遇到什么,
再决定页面应该出现什么。
从订单信息,到出行安排。
信息堆在订单里。航班、乘机人、费用、规则、服务入口混在一起,用户需要自己判断什么更重要。
先呈现出行安排:下一步做什么、有什么风险、哪些服务能处理。订单信息退回辅助层。
履约阶段真正需要处理的判断。
三个真实方向
不是概念展示。
是三个真实做过的出行产品问题。
用户买完票后,真正需要什么?
不是更多订单信息,而是更清楚的出行安排。
传统订单页信息很多,但用户无法快速知道下一步该做什么。因此我把“出行安排”和“订单信息”拆开,让行动路径优先出现。
- 从信息堆叠拆成“出行安排”和“订单信息”。
- 把行前准备、值机选座、安检登机、航班抵达组织成连续服务链路。
- 把中转、延误、行李、改签等高焦虑节点前置成可处理的服务。

用户焦虑
不知道下一步、不知道有没有风险、不知道是否误机、不知道怎么处理。
服务链路
设计判断
从“信息展示”升级为“出行服务链路”。
用户并不缺选择,缺的是判断依据。
AI 的价值,是把复杂选择解释清楚。
传统搜索让用户在复杂条件里反复筛选、跳转和比较。AI 决策的重点不是“给一个答案”,而是解释为什么推荐、风险是什么、为什么更适合。
- 自然语言输入,AI 理解需求、偏好和旅程阶段。
- 通过风险分析、推荐解释、多维度比较建立信任。
- 把规划、预订、履约中的关键判断串起来,而不是只做搜索推荐。

信任层
可感知、可理解、可解释、可托付、可验证。
决策对比
设计判断
推荐不应该是黑盒,AI 要暴露判断过程。
让真实问题更快进入原型验证。
工作流不是主角,它服务于真实产品判断。
这部分只作为辅助:把用户反馈、问题提炼、设计规范和 HTML 原型连接起来,让真实问题更快进入验证。
- 用户反馈输入后,AI 提炼出真实体验问题。
- 设计规范与业务规则参与生成,避免孤立页面。
- 评审和修改闭环帮助方案更快回到真实业务场景。

从反馈开始
真实用户反馈进入问题识别,而不是停留在需求转述。
协同图
设计判断
AI 不替代设计,AI 改变设计分工。
结果
真实产品,最后要回到真实结果。
履约服务和 AI 决策不是概念,它们要回答用户是否更清楚、咨询是否减少、决策是否更快、服务是否更可控。
更多沉淀
我关心的不是单个页面。
而是系统如何被理解。
腾讯安心平台
从品牌升级到小程序体验,把“一物一码”追溯能力转译成可信任的用户场景。
品牌视觉
通过品牌屋、视觉基因、色彩与物料统一,提升安心平台的品牌感知。
专利沉淀
个人专利 11 项,团队专利 20 项+,把业务创新转为可沉淀的方法资产。
团队影响力
组件协同、设计指南、AI 工程链路与协作机制,推动团队设计共识。
我为什么在做这些
OTA 过去更擅长交易,但用户最焦虑的时刻常常在交易之后。
我开始关注履约体验,是因为用户真正需要被帮助的时刻,常常发生在行前、值机、中转、延误、抵达这些不确定节点。
我关注 AI 决策,是因为机票选择并不只是价格排序。时间、风险、偏好、行李、改签规则,都需要被解释成用户能理解的判断。
AI 工作流只是辅助:它帮助我更快把真实反馈转成可体验的原型,但最终仍然要回到真实产品问题。