现有业务系统嵌入 AI 助手，应先约定员工从哪里打开、助手正在看哪张单据、以谁的身份办理，以及结果回到哪里。适合从订单详情、项目详情等对象明确的页面接入，让员工在原来的工作位置处理问题。
页面原型至少要画出正常使用、切换单据、登录失效和任务尚未结束四种状态。只展示一个能对话的侧栏，无法说明它在实际业务中怎样与表单、列表和人员账号配合。
页面入口与任务范围
不同入口对应不同的问题范围。订单页适合核对这张订单的缺项，列表页适合比较已选择的记录，首页适合查询跨项目信息。实施时应给每类入口写一句明确的范围说明，并显示当前对象。
| 入口位置 | 建议带入的信息 | 需要约定的交互 |
|---|---|---|
| 单据详情 | 对象类型、编号、当前版本 | 标明本轮问题针对哪张单据 |
| 业务列表 | 筛选条件、已选记录编号 | 区分选中几条与全部筛选结果 |
| 项目工作台 | 项目编号、当前阶段 | 跨项目提问时重新选择范围 |
| 全局入口 | 当前组织、可用业务范围 | 对象不明确时先补选对象 |
员工在列表勾选三张单据后问“检查这些”，页面应把这三张的编号提交给后台。不能让助手根据截图自行猜测勾选范围；涉及“全部”时，也应显示记录数量与筛选条件，避免只处理当前屏幕却让人以为已经检查全量。
页面信息与正式业务数据
页面可以提供对象线索，正式数据仍应从业务系统读取。建议最小传递对象编号、类型和界面版本，再由后台取得所需字段。这样既能减少重复传输，也便于识别页面是否已经过时。
未保存的表单内容要单独标为“当前草稿”。员工请助手润色备注，可以使用草稿；员工要求检查已经批准的交期，则应读取正式记录。两种内容同时存在时，应并列显示，不能把草稿交期当作已经生效的承诺。
更多字段准备工作可参照业务系统如何补齐 Agent 事实源。页面接入清单应进一步注明每个字段来自页面草稿还是正式记录，以及什么时候重新读取。
身份映射与组织切换
建议用稳定的人员编号关联两个系统，姓名只用于显示。开通时核对人员、组织和账号状态；重新登录、切换组织、停用账号时，同步处理助手会话的可用范围。后台凭据由服务端保管，页面只负责发起当前用户的请求。
同一个人属于两个业务组织时，应在入口持续显示当前组织。切换后，新任务使用新组织身份；正在执行的旧任务保留原组织标识，不能悄悄换到另一套数据继续办理。权限设计可进一步参考企业 Agent 的三重权限校验。
身份无法对应时，界面应提示联系管理员绑定账号，并允许员工继续使用原业务页面。不要让一个辅助功能的登录问题挡住整张订单的正常查看和编辑。
页面操作与助手操作的分工
已有成熟表单的动作，可以由助手整理数据后交回表单确认；需要跨多张记录核对的工作，则由助手生成结果清单。方案中逐项注明结果是填入草稿、打开已有页面，还是提交正式动作。员工应能在操作前看清三者区别，不需要猜测点下按钮后会不会直接改变业务记录。
复制链接分享结果时，也应保留对象和任务的关联，并让接收者按自己的身份打开。不要把发起人的可见内容直接装进一个任何人都能访问的结果地址。
示例：采购单页面的缺项检查
以下为设计示例：采购员打开采购单“采购示例-021”，要求检查收货信息。助手显示当前单号，后台读取地址、联系人、约定到货日，并指出联系人为空。采购员补齐草稿后，再请助手检查草稿与原记录的差异。
此时采购员跳转到“采购示例-022”。侧栏顶部切换浏览对象，但上一项检查仍标明属于 021。若采购员继续说“把刚才那项填上”，系统应展示具体单号和拟修改字段，避免把上一张单据的信息填到新单据。
保存完成后，页面提供原单据入口和刷新提示。若表单还有其他未保存内容，先提示员工处理这些内容，再刷新；直接整页重载可能让另一部分草稿丢失，这应纳入交互验收。
联调材料与验收动作
交给实施团队的材料可以收敛为入口原型、身份映射表、页面上下文表和交互用例。上下文表明确对象编号、草稿标识、版本、返回地址；用例覆盖双标签页、组织切换、对象删除、登录过期和窄屏显示。
验收时让业务人员连续完成一次实际操作：从列表选单、打开助手、切页、返回原单、查看处理结果。记录每一步显示的对象与身份，检查是否需要反复复制编号，以及错误时能否回到原工作位置。
这些约定可在开发前并入定制开发的系统衔接方案。先把页面与业务对象对应清楚，再补所需动作，界面才能成为日常工作的入口。
