ChatGPT Connectors适合接哪些公司资料
把 ChatGPT Connectors（现称 apps）讲成企业资料接入策略：先接高频、低风险、权限清楚、能引用回源的公司知识，再谨慎推进 sync、自定义 MCP 和写操作。
先说一个容易混淆的口径：截至 2026 年 7 月，OpenAI 帮助中心已经把 ChatGPT 里的 connectors 统一改称为 apps。旧说法里的 chat connectors、deep research connectors、synced connectors，对应到新说法，大致变成 apps with file search、apps with deep research、apps with sync。功能没有因为改名消失，很多团队也仍然习惯说“连接器”。所以本文沿用标题里的 Connectors，但正文会把它理解为 ChatGPT 里能连接公司工具、搜索资料、引用来源、同步索引或通过 MCP 接入内部系统的 apps。
问题不在于“能不能接”。真正的问题是：公司到底应该先接哪些资料，哪些资料暂时不要接，哪些只能只读接入，哪些可以给写操作，哪些必须等权限和治理成熟后再说。
很多团队一看到连接器，就会想把所有公司资料都接进去：网盘、Slack、邮件、CRM、工单、代码仓库、财务报表、合同、HR 文档。这个冲动很正常，因为公司知识确实散落在太多系统里。OpenAI 对 company knowledge 的介绍也点出了这个痛点：完成工作所需的上下文常常分布在文档、文件、消息、邮件、工单和项目追踪器里，最准确的答案往往横跨多个来源。
但“全部接入”不是成熟策略。ChatGPT 连接器最适合接入的资料，应该满足四个条件：团队经常问、答案需要引用、权限边界清楚、读出来能减少工作摩擦。反过来，如果一类资料权限混乱、事实过期、噪声极高、包含密钥或强隐私信息，贸然接入只会把问题放大。
先理解连接器现在分成几种能力
OpenAI 当前文档把 connectors 纳入 apps 体系。Apps 不只是一类东西，而是一组能力的集合。
第一种是搜索和引用。OpenAI Help Center 对 apps 的说明里提到，apps 可以帮助你从连接的第三方服务里搜索和引用信息，把相关上下文带入对话。这类能力最适合回答“某个政策在哪里写过”“这个客户最近有什么反馈”“项目目标到底改成了什么”。
第二种是 deep research。部分 apps 可以进入 deep research，用于复杂、多来源分析，并给出回到原始来源的引用。这适合长报告、竞品总结、客户反馈汇总、跨部门资料综合，但不适合毫无边界地抓取敏感资料。
第三种是 sync。Apps with sync 会提前索引选定知识来源，让回答更快、质量更稳定。OpenAI 文档给的例子包括查找季度复盘 deck、总结年度 go-to-market 策略。Sync 更像把高价值知识源做成可检索底座，适合稳定、结构较清楚、经常被问到的资料。
第四种是 actions。部分 apps 可以在连接服务里执行动作，例如创建、更新或发送内容。OpenAI 文档强调，默认的 app permissions 会允许自动读取，但对可能产生重大外部影响、暴露敏感信息或难以撤销的动作要求确认。这里的重点是：读和写要分开看。适合搜索的资料，不一定适合开放写操作。
第五种是自定义 MCP apps。OpenAI 的开发者文档说明，如果要把私有数据源做成 data-only app，面向 ChatGPT、deep research 和 company knowledge，通常应实现 read-only 的 search 和 fetch 工具。也就是说，内部系统并不一定非要有漂亮界面；很多公司资料先以“能搜、能取、能引用”的只读方式接入，就已经很有价值。
所以，讨论“接哪些公司资料”时，不要只问系统名，而要问能力类型：这是实时搜索、提前同步、深度研究、只读 MCP，还是带写操作的业务 app？
第一优先级：制度、流程、模板和项目文档
最适合第一批接入的，是公司里“大家经常问、答案相对稳定、可以公开给对应团队看”的文档类资料。
比如员工常用政策、报销流程、采购流程、信息安全手册、品牌语气规范、销售话术模板、产品发布流程、项目复盘模板、会议纪要模板、技术 runbook、客户交付 SOP。这些资料通常有几个共同点：不是高度机密，重复查询频率高，答案需要引用原文，错误成本主要来自“找不到”或“找错版本”。
这类资料适合通过 Google Drive、SharePoint、Box、Dropbox、Confluence、Notion 或内部文档系统接入。具体名称取决于团队实际工具和 OpenAI app directory 中可用的 app。OpenAI 的 company knowledge 资料中多次举例提到 SharePoint、Google Drive、GitHub、Slack、HubSpot 等工具，核心意思不是让每家公司照抄工具清单，而是把分散在工作系统里的上下文带进 ChatGPT，并给出来源引用。
文档类资料的接入原则是：先接“已经被治理过的资料”，不要接“所有人随手扔的网盘根目录”。如果一个共享盘里既有正式政策，又有旧版草稿、私人截图、导出的客户名单和临时备份，先治理目录和权限，再接入 ChatGPT。否则模型检索到旧草稿，反而会制造错误答案。
对这类资料，推荐优先使用 file search 或 sync。因为它们不需要写操作，风险较低，也最能体现 ChatGPT 的价值：帮人从资料海里找到答案，并附上引用，让用户能回到原文确认。
第二优先级：项目、任务和决策记录
第二类适合接入的是项目协作资料：Jira、Linear、Asana、Azure Boards、GitHub Issues、GitLab Issues、ClickUp、Basecamp、Monday.com、Confluence、Compass 等系统里的任务、里程碑、决策记录、需求变更和风险讨论。
这类资料的价值在于“当前状态”。团队问的不是抽象知识，而是：这个项目到底卡在哪里？谁负责下一步？需求为什么改？上周决定了什么？某个 bug 是否已经排期？新同事如何快速理解一个项目？
OpenAI 的 company knowledge 文章提到，company knowledge 可以跨多个来源处理团队目标、客户反馈、项目上下文等问题，并在有冲突或不明确时综合不同来源。项目资料正适合这种场景，因为项目状态经常散落在任务系统、文档、会议纪要和聊天频道里。
但项目资料也要注意边界。第一，任务系统里的权限必须干净。一个工程师不应该因为 ChatGPT 接入了项目系统，就看到自己原本无权访问的法务项目、并购项目或 HR 项目。OpenAI 文档强调 company knowledge 尊重现有权限，用户只会看到自己已有权限能看的内容；企业仍然需要先把源系统权限整理好。
第二，任务资料最好保留原始链接。回答“这个功能为什么延期”时，ChatGPT 的总结只是入口，真正可执行的依据应回到 Jira ticket、Linear issue、PR、会议纪要或决策文档。没有引用的项目总结，很容易变成二手传话。
第三，写操作要慢一点开放。让 ChatGPT 读项目任务、总结风险、生成行动清单，通常是低风险高收益；让它自动创建 issue、改优先级、触发 workflow，就进入动作控制范围，需要管理员审核 action、RBAC、审批提示和撤销流程。
第三优先级：客户、销售和支持资料
客户资料很有价值，也最容易出问题。它适合接入，但不适合无脑全量接入。
适合接入的部分包括：CRM 中的客户阶段、商机摘要、最近互动记录；支持系统里的工单主题、常见问题、投诉分类；客户成功系统里的健康度、续约风险和会议纪要；客服知识库里的标准答复；产品反馈渠道里的用户建议。OpenAI 的 company knowledge 示例里提到，ChatGPT 可以结合 Slack 里的客户讨论、邮件、Google Docs 里的会议记录、Intercom 支持工单来生成客户电话前的 briefing。这正是客户资料接入的典型价值。
但客户资料必须做分层。销售代表可以看自己的客户，不代表所有员工都应该能查所有客户；客户合同可以用于摘要，不代表敏感价格条款可以随意进入普通对话；客服工单可以用于问题归类，不代表个人身份信息可以出现在总结里。
一个实用做法是把客户资料分成三层：
第一层是可广泛搜索的客户知识：产品使用场景、公开案例、常见问题、非敏感反馈主题。
第二层是角色限定资料：商机、续约、支持升级、客户健康度，只给销售、客户成功、支持、产品负责人等对应角色。
第三层是高敏资料：合同、折扣、付款、争议、身份信息、健康信息、法务沟通。默认不接，或只在严格 RBAC、审计、脱敏和明确用途下接。
客户资料的目标不是让 ChatGPT 替代 CRM，而是让它帮人更快理解客户上下文。适合的任务是：客户会议准备、反馈主题汇总、支持风险提示、续约风险摘要、产品路线图输入。不适合的任务是：未经确认自动承诺客户、自动修改价格、自动发送敏感邮件。
第四优先级：沟通系统里的“可复用决策”
Slack、Microsoft Teams、Gmail、Outlook、Google Calendar 这类沟通资料非常诱人，因为真实工作大量发生在消息和邮件里。OpenAI 的资料也把 Slack、邮件、日历、Teams 等作为公司知识的重要来源。ChatGPT Slack app 的帮助文档说明，它可以搜索 Slack 消息、线程和频道，并在启用后在相关时自动引用 Slack 内容；在某些配置下还可执行 Slack actions。
但是沟通系统也是噪声和隐私的高发区。它里面有玩笑、情绪、半成品想法、未确认承诺、私人安排、临时截图、客户敏感信息。把全部聊天接入公司知识，不一定会提升知识质量。
更好的策略是先接“工作频道”和“决策频道”，暂缓私人 DM 和高敏频道。比如项目频道、客户升级频道、事故复盘频道、产品反馈频道、销售协作频道、公告频道。接入目标不是让 ChatGPT 读每一句闲聊，而是帮助团队提取可复用上下文：本周做了什么决定，某个事故根因是什么，客户反馈集中在哪些问题，某个项目最近有哪些阻塞。
邮件和日历也类似。个人邮箱适合个人助手型场景，比如帮我准备会议、总结未读、找某个附件；组织级知识则更适合共享邮箱、客户支持邮箱、项目邮件组和经授权的团队资料。不要把全员个人邮箱当成公司知识库。
沟通系统的接入重点是“用途限定”和“用户授权”。OpenAI 文档说明，用户需要在首次使用时认证各个 app，管理员也能管理 workspace access。企业要在内部政策里讲清楚：哪些频道可用于 ChatGPT，哪些不应接入，哪些输出必须回源验证。
第五优先级：代码、工程知识和运维资料
对研发团队来说，GitHub、GitLab、Azure DevOps、Jira、Linear、Confluence、runbook、架构文档、事故复盘、部署手册都很适合接入。这里的价值不是让 ChatGPT 随便改代码，而是让它理解工程上下文。
适合接入的工程资料包括：公开或内部代码仓库的 README、架构说明、issue、PR、release note、测试说明、部署手册、服务目录、告警 runbook、事故复盘、接口文档。接入后，ChatGPT 可以帮助新人理解代码库、总结某个 PR 的背景、查找相关 issue、准备发布说明、解释某个服务的责任边界。
不适合直接接入的工程资料包括：密钥、token、生产配置、未脱敏日志、数据库 dump、包含用户隐私的错误追踪、SSH key、云账号凭据。它们不应该通过连接器成为普通对话上下文。
工程资料很适合先做只读。即使某些 MCP app 支持写操作，第一阶段也建议让 ChatGPT 读 issue、读 PR、读文档、生成建议，不要直接合并代码、改生产配置或触发部署。OpenAI 的 app permissions 和 action controls 文档都强调，管理员可以配置 app 能做什么，重要动作需要确认或可能被阻止。工程场景里，这个边界尤其重要。
第六优先级：指标、报表和业务分析资料
很多管理者最想接的是指标：销售额、活跃用户、留存、转化率、库存、账单、广告效果、客服响应、产品使用数据。OpenAI release notes 已经提到一些与数据、产品和业务工具相关的 MCP access connectors，例如 Amplitude、Stripe、Hex 等。它们的价值是让 ChatGPT 能围绕业务问题检索事实，而不是只靠人手动粘贴报表。
但指标资料最容易被误读。一个数据表如果没有指标口径、时间范围、过滤条件和权限说明，ChatGPT 很可能给出看似合理但口径错误的总结。接这类资料前，先做三件事：
第一，把指标字典整理清楚。什么是活跃用户，什么是付费客户，退订按哪天算，退款是否扣除，试用账户是否包含。
第二，区分 dashboard 摘要和明细数据。管理层可能只需要看汇总趋势，不应该默认访问交易明细或个人数据。
第三，把高风险动作关掉。查 Stripe 订阅状态和发起退款不是一个风险级别；看广告花费和修改预算也不是一个风险级别。数据类 app 可以先只读，等审计、审批和撤销机制成熟后再开放动作。
哪些资料暂时不要接
并不是所有公司资料都适合进 ChatGPT。
第一类是凭据和密钥。API key、token、SSH key、数据库密码、云账号凭据、证书私钥，默认不应该接入。它们应该在密钥管理系统里，不应该成为自然语言问答材料。
第二类是权限未整理的共享盘。如果一个目录里混有公开资料、机密资料、个人资料、旧版草稿和临时备份，先治理权限和目录，再谈连接器。
第三类是高度敏感的人事、医疗、身份、财务明细。不是永远不能接，而是必须有明确的合规依据、最小权限、脱敏策略、审计日志和用途边界。普通公司知识搜索不应默认覆盖这些资料。
第四类是法律特权、并购、投资、重大人事调整等少数人资料。它们的问题不是“ChatGPT 能不能读”，而是“任何额外读取路径都会扩大风险面”。这类资料应当按专门流程评估。
第五类是未定稿、质量很差或互相冲突的资料。连接器会让资料更容易被引用，但不会自动提高资料质量。把过期资料接入，只会让过期答案生成得更快。
选择接入资料的五个判断问题
团队可以用五个问题来决定优先级。
第一，这类资料是否经常被问？如果一个问题每周都有人问，连接器价值很高；如果一年只查一次，先不要为它复杂化权限。
第二，答案是否需要引用？如果回答必须回到原文确认，比如政策、合同条款、项目决定、客户反馈，适合接入。ChatGPT company knowledge 的一个重要价值就是给出引用和链接，让用户能核对来源。
第三，权限是否已经在源系统里整理好？OpenAI 文档强调 company knowledge 尊重现有权限，但前提是现有权限本身可靠。源系统乱，连接器会放大混乱。
第四，资料是稳定知识还是实时状态？稳定知识适合同步索引；实时状态适合按需搜索或 access connector；业务动作则需要 action controls。
第五，错误成本有多高？如果错误只是让人少走一步路，风险低；如果错误会影响财务、法律、客户承诺、生产系统，就需要更严格的复核和人工审批。
一个稳妥的接入顺序
如果一个公司刚开始用 ChatGPT 连接器，不建议一口气接所有系统。可以按四个阶段推进。
第一阶段，只读接入低风险文档：政策、流程、模板、产品文档、项目公开资料。目标是让员工能快速找到答案，并看到引用。
第二阶段，接入项目和客户上下文：任务系统、客户支持、CRM 摘要、项目频道。目标是让团队能准备会议、做项目同步、总结风险。
第三阶段，引入 sync 和 company knowledge：把高频知识源提前索引，提升速度和质量；让用户在 company knowledge 模式下选择具体 apps，获得带引用的跨来源回答。
第四阶段，评估自定义 MCP apps 和写操作：对内部系统实现 search/fetch，先只读；对确实需要动作的场景，配置 action controls、RBAC、审批提示和审计日志。
这个顺序的好处是，价值和治理一起增长。团队先从“读得更准”开始，再进入“跨系统综合”，最后才进入“让 ChatGPT 代表我行动”。
管理员上线前的检查清单
管理员不需要把连接器当成神秘黑盒，可以把它当成一组可治理的数据入口。
上线前至少检查这些问题：
- 哪些 workspace、角色和用户可以启用这个 app？
- 这个 app 是只读、同步、deep research，还是有写操作？
- 是否支持 action controls？默认允许所有动作、只读动作，还是自定义动作？
- 重要动作是否需要确认？是否存在“Never ask”这类高风险设置？
- 源系统 OAuth scope 是否合理？有没有请求超出用途的权限？
- 回答是否能显示引用和原始链接？
- 是否尊重源系统权限、RBAC 和数据驻留要求？
- 是否需要排除特定文件夹、频道、项目或客户资料？
- 是否有审计路径，能回看谁问了什么、用了哪些来源？
- 是否有关闭、撤销授权、重建索引和处理误答的流程？
OpenAI 的 admin controls 文档说明，Enterprise/Edu 默认 app 关闭，Workspace owners 可以启用 apps 并用 RBAC 分配角色；Business 则由管理员控制 workspace app 和角色范围权限。对支持 Action control 的 apps，管理员还能决定允许全部动作、只读动作或自定义动作。团队上线时应把这些控制真正用起来，而不是只点一个“连接”按钮。
结论：先接能被引用的工作事实
ChatGPT Connectors 最适合接的，不是“所有公司资料”，而是那些能提高工作判断质量的事实源：正式文档、项目状态、客户反馈、任务记录、工程知识、经过治理的沟通资料和有清晰口径的业务指标。
一个简单原则是：先接能被引用的工作事实，再接需要跨系统综合的上下文；先只读，再同步；先搜索和 fetch，再考虑写操作；先用现成 apps，再为专有系统做自定义 MCP；先治理权限，再扩大范围。
如果公司只把连接器当成“把资料喂给 AI”，很容易走向混乱。但如果把它当成“让 ChatGPT 在现有权限边界内检索、引用和综合公司知识”，它就会变成很实用的知识入口。最好的接入策略不是最全，而是让每一次回答都能回到来源、尊重权限、解释边界，并真的减少人的重复查找。