Salesforce 在 2026 年 9 月的产品发布中介绍 Slackforce，并展示 Surfaces：将业务数据和协作上下文组织为团队可共同使用的界面。官方页面同时说明，实时数据功能从 10 月开始逐步推出；评估时应区分当前可用界面与后续开放能力。Slackforce Surfaces 官方介绍
团队看板加入 AI 后，消息和业务记录的关系需要更清楚。群里提到的预计交期、系统中的承诺交期以及实际发货时间，应保留各自含义。
协作上下文的整理
可以围绕一个项目或商机汇集相关讨论，但应保留原消息时间、参与人及关联对象。转发消息可能缺少上下文，Agent 提炼时需要注明其与当前任务的关系。
同名项目尤其容易混淆。建议使用系统编号定位，名称用于展示。讨论中出现“上次那个版本”时，应结合当前线程和附件核对，找不到明确对象就提出确认，不把最近上传的文件默认当成目标。
看板数据的表达
| 信息 | 建议展示 | 避免的混淆 |
|---|---|---|
| 正式业务状态 | 原系统状态及查询时间 | 将聊天中的意向当正式状态 |
| 进度判断 | 判断依据与未完成条件 | 把推测写成已完成 |
| 负责人 | 当前责任人与来源 | 按消息活跃度推断责任 |
| 截止日期 | 已确认日期与提出人 | 将建议日期当作承诺 |
| 更新异常 | 最近成功刷新时间 | 用旧数据展示实时外观 |
看板允许评论和筛选时，应明确这些操作是否影响原系统。某人隐藏一条记录只是调整视图，不能让团队误以为业务已经关闭。
讨论转为业务动作
例如，团队讨论后决定把商机推进到合同阶段。Agent 应先核对必要条件与操作者权限，生成待确认的变更内容，再通过正式接口执行。成功后展示记录链接和更新结果，使其他成员能核对。
如果系统拒绝更新，讨论中的决定仍可保留，但看板必须说明正式状态未改变。不能一边在群里说“已处理”，一边让 CRM 保持原样。重复点击或重复消息触发也应关联到同一个业务请求。
权限与共享范围
共享界面应按访问者身份获取数据。创建者有权查看，并不表示所有频道成员都有同样权限。跨部门频道、临时项目成员和外部合作人员需要分别验证。
验收时让不同权限账号查看同一界面，检查明细、汇总、搜索结果和导出。即使明细被隐藏，汇总数字也可能泄露受限信息；数据范围应从查询端落实，不能只在页面上遮挡。
持续更新与固定报告
日常协作看板需要显示当前状态，经营会议的报告则常需保留当时口径。两种用途可以同时存在：固定报告保存截止时间与内容快照，动态看板继续刷新并标记变化。
接入异常时保留最近有效数据，但醒目标出时点和失败状态。重新恢复后核对漏掉的变更，避免只刷新当前页面却遗漏期间产生的任务。验收应包含权限撤销、连接失效、源记录删除或改名，以及消息修正后再次汇总等情况。
看板保存到频道后，还应指定维护人。项目结束时确认看板转为归档、继续跟踪还是停止刷新，保留必要的历史快照。数据连接失效或负责人离岗时，应有接管方式，避免团队长期引用已经失去更新来源的共享界面。
相关实施可参考经营简报 Agent和写后回读验证，岗位入口与业务系统的连接见企业 Agent 落地。
