AI 协作之前档案需邀请码
旅云保综合业务原型
复杂业务平台的持续演进
按年份与业务模块归档持续发生的功能更新，保留复杂流程、角色关系与产品判断的变化。
PRODUCT OBJECTIVE
这组原型解决什么问题
在长期功能迭代中持续梳理业务结构，让新增需求能够进入已有流程，而不是把平台拆成彼此孤立的页面。
VERSION TIMELINE
版本如何演进
- 01
从核心投保链路起步
先把产品选择、投保信息与名单录入组织成可连续完成的主流程。
- 02
补齐订单与异常状态
让订单结果、部分失败、凭证与后续动作在同一套状态结构里可追踪。
- 03
连接销售与移动协作
把潜客、客户与移动端订单接入平台，验证多角色、多端之间的任务衔接。
- 04
形成跨模块业务平台
理赔、财务和产品管理进入同一工作台，平台从页面集合收敛为业务网络。
KEY VERSION EVIDENCE
四类任务，看到平台如何长成系统
先把高密度信息变成可连续完成的任务
产品、期限、投保主体和名单不再分散在多个入口中，使用者沿着一条主线完成关键录入与确认。
潜客与客户不是独立表格，而是后续业务的起点
把跟进、开户与客户状态放进统一工作台，让销售动作能够自然进入后续产品与订单流程。
状态、筛选和动作需要使用同一种业务语言
理赔任务进入平台后，列表不只呈现记录，还要说明当前状态、责任角色和下一步可执行动作。
移动端保留判断与动作，不照搬桌面信息密度
在有限空间里优先呈现订单状态、异常结果和高频操作，让跨端协作保持同一套判断依据。
公开页面仅使用脱敏后的代表界面与结构判断；包含真实业务名称、客户信息和完整流程的墨刀原型只在受控档案中开放。
PRODUCT DECISIONS
持续增加功能时，结构必须先稳住
平台结构按角色要完成的任务组织，而不是按需求来源堆菜单
新模块先明确进入哪条业务链、服务谁以及完成后流向哪里，再决定页面入口。
同一个业务对象在不同端必须共享状态和动作语义
桌面与移动端可以有不同密度，但有效、失败、待处理等判断不能各自定义。
部分失败与回退路径是主流程的一部分
失败原因、可重试范围和后续责任要被明确展示，不能只为全成功场景设计。
模块越多，越要让入口、过程与结果能够相互追溯
从销售到订单再到理赔，使用者始终能知道当前对象来自哪里、下一步去哪里。
CONTINUE EXPLORING
继续查看完整档案
这页已经讲完问题、演进与关键判断。更完整的版本材料和可体验入口进入独立档案，方便按需继续深入。