三个已经跑通的
真实场景
我们只写跑通了的东西。下面三个场景，每一条链路都做过端到端实测 —— 包括每个场景目前还差什么。
经销商在线订货，从加购到发货单一条链
平台内置的 B2B 订货商城：经销商在自己的界面上选品、加购、结算，提交后直接生成发货订单。 不用在聊天工具里对单，也不用把订单再录一遍。
选品与加购
按款号或名称搜索商品，选好规格与颜色后加入购物车；同款多色按行列出，下单不必再逐项对。
购物车与结算
购物车里逐行改数量、删行、选收货店仓；提交前有二次确认，价格以结算单据为准。
生成发货订单
提交后生成发货订单并落库，经销商可在「我的订单」里查状态与明细。
这条链覆盖的四个环节
商品与选品
款号、名称与规格统一检索，颜色维度分行展示，选完直接进购物车。
购物车
逐行改数量、删行、实时汇总；行内编辑不必回列表页重做一遍。
结算与提交
提交前二次确认，选好收货店仓后生成发货订单，价格以结算单据为准。
我的订单
已提交订单的状态与明细可查，经销商与平台看的是同一份数据。
已实测跑通的八项能力
这条链目前的边界
订货链路已做端到端实测（加购 → 购物车 → 结算 → 提交发货订单）， 尚未在对外正式环境验证；商城账号与业务组织也还未绑定， 目前仅平台管理员可进入。对外开放前，需要完成账号绑定与商品资料整理。
待办、消息与审批，在路上就能处理完
织元移动助手把平台的待办、消息、单据与报表带到手机上： 出差路上收到待办，可以直接看单据、给结论，数据口径与平台端完全一致。
五个入口
待办、消息、工作台、报表、我的 —— 五个入口各自独立， 工作台按业务分区与分类组织，入口卡随权限自动收敛。
随权限生效待办与消息真出数
待办与消息都从平台实时取数，不是缓存列表； 不同角色看到的条数与内容不同，和平台上看到的完全一致。
真机实测单据与审批落库
单据详情可看可读；审批的「批准」与「驳回」都能真实落库， 审批结论回到平台侧生效，不是界面上的假动作。
落库已验证已实测跑通的八项能力
当前的定位：只读客户端
移动端目前定位为只读客户端 —— 看待办、看单据、跑报表、给审批结论， 不提供新增、编辑、删除、提交与审批办理入口。 写操作仍在平台端完成，避免两端规则打架。
不止帮开发，也直接帮业务看数
业务同事不必等开发出报表 —— 在助手里把问题问出来， 就能拿到带来源说明的经营分析。AI 取数严格按提问者本人的权限，看不到的会明说看不到。
用业务话提问
在平台的 AI 会话里用业务语言提问，不必先知道该查哪张表、哪个字段。
按您的权限取数
系统为当前登录人签发一枚短时效只读凭据，AI 用它回取数据 —— AI 能看到的，不超过您能看到的。
拿到带来源的分析
每一段都注明数据来源与统计口径；取不到的部分逐项说明原因，不拿半截数据当完整结论。
档案经营分析
针对当前分析的那个对象，按您的权限取档案、引用关系与往来明细， 产出档案概要、往来概览、结构特征、关联关系、风险提示五节分析。
主数据首发场景风险与异常提示
基于已取到的事实提示异常（如金额高度集中、金额与审核额差异明显）， 只陈述已核实的情况，不预测未来，不替人拍板。
随场景逐步扩展跨单据关联梳理
把「谁引用了我、我关联谁」这类跨单据关系一次理清， 让上下游的往来脉络不用再靠人工逐张单据去翻。
随场景逐步扩展为什么这类助手值得信
业务场景里最怕的不是 AI 答不上来，而是它把不知道的说得像知道。 所以我们把三件事做进了产品：每个数字都能追到来源与口径； 明确标出这条信息是刚核过的、可能已变的、还是这次没核； 算不出来的地方直接标出盲区，而不是用「看起来合理」的内容填空。
还没接通的两件事
一是从业务记录页一键带出上下文唤起助手 —— 取数与分析本身已经能跑， 但这条「在单据上直接问」的入口尚未接通； 二是用量统计与操作审计的落库，正在接线中。这两件事在补齐前， 我们不会把它写成一个已经可用的功能。