一个全局助手，最后会变成谁都不满意
销售希望 AI 多给几种推进建议，客服需要严格按政策回复，交付团队关心项目状态和技术细节，管理层则只想看汇总结果。企业把这些需求都叠加到一份提示词里，系统确实能回答更多问题，但每次回答都要先猜用户属于哪个角色，配置之间还可能互相冲突。
更大的风险是权限。客服不应该看到销售报价底表，销售也不应该直接读取其他客户的交付记录。即使知识库做了基础权限，如果工具、缓存和历史对话仍然全局共用，隔离仍可能被绕开。
把共用和专属拆成四层配置
第一层是公司主体、品牌名称和基础服务事实，所有部门使用同一口径；第二层是部门知识范围，例如客服政策、销售资料和交付手册；第三层是工具权限，包括查询、写入、发送和审批；第四层是输出模板与审核要求。四层分别维护，任何变化都能知道影响范围。
用户身份不能只靠一句“我是销售”来判断。系统应从登录账号、岗位、部门和具体项目取得权限上下文，必要时再由人工确认。提示词可以帮助表达风格，但不应该承担真正的访问控制。
- 共同事实只保留一份主来源，部门只补充自己的业务范围。
- 读取、建议、写入、发送和审批权限分别设置。
- 配置发布要有版本、负责人和回退方式，避免改一处全局失控。
部门差异应体现在任务里，不是只换一句称呼
真正的部门配置包括常用任务、必填字段、资料来源、禁止动作和交接方式。客服处理客户问题时，输出要带政策依据和转人工条件；销售生成跟进建议时，要把客户阶段和下一步负责人写清；交付团队则需要项目编号、版本状态和风险项。
如果只是把“你是客服”换成“你是销售”，底层数据和工具仍然混在一起，体验不会真正改善。部门模板需要由一线员工参与试用，看看他们是否能用现有语言找到任务，而不是让每个人记住一套系统术语。
隔离设计要覆盖日志、缓存和导出
权限测试不能只看页面上能不能点开。还要检查检索结果、上下文缓存、操作日志、导出文件和错误消息是否泄露其他部门或客户信息。一个接口返回了多余字段，即使前端没有展示，也不代表数据已经安全隔离。
配置变化后做一次跨部门回归测试：销售是否仍能使用自己的资料，客服是否拿不到不该看的报价，交付是否保留必要的项目工具权限。把这些检查写进发布清单，比出问题后靠员工截图报告更稳妥。
验收标准是互不干扰，也能保持共同口径
试点时让不同部门用相近问题提问，检查答案是否符合各自任务，又没有混入其他部门的私有资料。再故意修改一个部门的输出模板，看其他部门是否被意外影响。测试账号离职、转岗和临时项目授权，确认配置和权限都会及时变化。
好的企业 AI 不是每个人看到完全一样的答案，而是在共同事实基础上，根据岗位提供合适的工作路径。底座可以共用，责任、资料和动作权限必须分清，系统才有可能从一个演示助手变成多个可持续使用的业务工具。
要点总结
- 不一定。可以共用技术底座，但将知识、工具、模板和权限按部门隔离，减少重复建设。
- 不能。提示词只能表达规则，真正的权限应由账号、服务端策略和工具层共同控制。
- 公司主体、品牌、基础服务和统一合规口径适合共用，部门流程、客户资料和操作权限应单独管理。
参考来源说明
本文围绕“同一套 AI 系统服务不同部门，配置不能只靠一份全局提示词”展开，结合 5 份公开资料及一路凯歌在“企业 AI 服务”方向的执行经验整理，重点看它对官网可引用结构、FAQ 设计和后续获客复盘的影响。