Atlassian Rovo Dev：企业研发知识协作的治理边界
Rovo Dev 处于 Atlassian 的企业 AI 与协作体系中；落地关键是连接器权限、知识边界与人工审批，而非默认开放全部企业信息。
Atlassian Rovo Dev enterprise-ai developer-tools knowledge-management Rovo Dev 处于 Atlassian 的企业 AI 与协作体系中；落地关键是连接器权限、知识边界与人工审批，而非默认开放全部企业信息。
1. 产品定位
Atlassian 将 Rovo 作为连接组织知识、搜索、聊天与代理能力的产品体系，并在其产品更新中介绍 Rovo Dev。[S1][S2] 对研发团队，合理定位是辅助理解 Jira、Confluence、代码与服务文档之间的关系，或协助起草任务和技术说明。它不应被视为知识库的权限旁路，也不应替代负责人对需求、变更或合规结论的确认。
2. 先定义知识范围
试点前建立一份允许连接的空间清单：例如公开工程规范、已归档的架构决策和指定项目的 Jira 任务。人事、法务、财务、客户合同、事故复盘、密钥记录和受限研发资料默认排除。每个空间指定数据所有者、更新责任人和敏感级别。这样做的目标不是让回答“知道得更多”，而是确保它只能在调用者原本有权访问的资料范围内提供帮助。
3. 身份、连接器与权限
连接器按最小范围授权，并使用组织单点登录与团队分组；离职、转岗和外部协作者变更应能及时收回访问。不要用共享管理员账号建立连接，也不要因排障临时授予全局浏览权限后遗忘撤销。上线前分别用普通研发成员、项目管理员和无权限用户测试同一个问题，确认搜索与引用结果遵守源系统权限，且被拒绝时不会暴露标题、摘要或存在性。
4. 研发协作场景
首批用例选择可人工复核的工作：汇总某项目的已批准决策、根据已关闭 issue 起草变更说明、列出服务文档的缺口，或将会议纪要转为待确认的 Jira 草稿。输出必须带原始页面或工单引用，方便读者回到来源。不要让 Rovo Dev 自动创建高优先级事故、修改 sprint、分配人员或关闭工单；这些动作会改变团队承诺，应留给具备业务上下文的人执行。
5. 回答质量与过期信息
企业知识的主要风险往往不是模型幻想，而是旧规范被准确地检索出来。为关键问题建立黄金问答集，覆盖当前架构、弃用接口、权限流程和紧急联系人；评审回答的来源正确性、时效性、遗漏和不当外推。资料有冲突时，系统应指出冲突并请求确认，而不是选择看似权威的一份。为重要 Confluence 页面和项目决策写明所有者及复核日期。
6. 不可信内容与提示注入
任何被索引的页面、工单描述和附件都可能含有“忽略规则”“导出资料”一类文字。此类内容只能作为待解释的业务资料，不能改变系统权限、工具调用范围或数据披露规则。对可触发行动的工作流，先展示拟执行对象、字段和影响，再由有权限的人确认。安全团队应定期放入模拟恶意页面，验证代理不会跨空间检索、泄露引用内容或执行越权动作。
7. 隐私与数据留存
明确查询、对话、引用、反馈和连接器日志分别保存在哪里、保存多久、谁可导出。对个人信息、客户名、访问令牌和事件细节制定脱敏规则；不能因“用于改进体验”而无限期保存全部提示词。员工应知道哪些工作区已接入以及如何报告不当回答。若某空间取消接入，验证索引、缓存、派生摘要和权限令牌的处理都符合组织的数据删除要求。
8. 运营监控
按空间和用例观察检索失败、无来源回答、权限拒绝、用户纠错、过期引用与敏感数据举报。将这些指标反馈给内容所有者和平台管理员，而不只追求使用次数。出现权限异常或高风险泄露报告时，先禁用相关连接器或行动能力，再保留最小必要证据进行调查。每项告警都要有业务责任人、响应时限和恢复前检查清单。
9. 验收与扩展
试点验收覆盖：授权用户可获得带引用的有效回答；无权用户不能通过提问猜出受限资料；过期和冲突资料能被标识；含恶意指令的内容不会改变行为；管理员能暂停连接并导出审计记录。仅当这些检查、隐私评审和团队反馈均通过后，才增加新的知识空间或写入型流程。每增加一个连接器都视为一次新的数据边界变更。
10. 来源与更新时间
本文依据 Atlassian 的 Rovo 产品页及其官方更新说明。[S1][S2] 产品能力与企业版配置可能调整，实际权限以组织的 Atlassian 管理设置和源系统 ACL 为准。上线前应重新核对当前可用连接器、日志和数据治理选项。