这是一个 SasaDaily 假设案例。
不是 Atlassian 公布的真实客户成效。
假设有一家 6 人 B2B SaaS 公司：
- 1 名 Product Manager
- 2 名 Engineer
- 1 名 Marketing
- 1 名 Customer Support
- 1 名 Operations／Founder
公司每两周发布一次产品更新。
真正耗时间的事情，却不只是写 Code。
而是每次功能准备上线后，
同一段背景要一直重新讲。
一个功能，为什么要讲四次？
例如工程团队正在开发：
新版客户权限管理。
工程师在 Jira 里已经讨论：
为什么要改？
哪些客户受影响？
有哪些 Known Issues？
哪一部分延后？
哪一个限制不能在 Launch 时承诺？
工程完成后，
Product Manager 接着要刷新一份：
Launch Brief。
Marketing 再问一次：
「这次到底改了什么？」
客服又问：
「如果客户说旧权限不能用了，要怎么回答？」
Founder 周会再问：
「目前 Release Risk 到底在哪？」
六人公司不大，
但同一组 Context 仍然可能被：
工程 → Product → Marketing → Support → Management
刷新五次。
这就是典型的：
Work about work。
第一步：产品经理先和 Rovo 把工程 Context 整理完整
假设团队本来就使用：
Jira、
Confluence。
产品经理先在 Rovo Chat 问：
「整理目前新版权限功能的 Release Status，分成已完成、Blocker、Known Risk、还需要决定的事情。」
Rovo 可以根据这位用户本来有权限查看的 Jira／Confluence Context 协助整理。
这一步先不做任何外部动作。
只创建一条清楚的：
Release Thread。
里面留下：
为什么做？
目前做到哪？
什么还没完成？
哪些是已决定？
哪些只是 Proposal？
这条 Chat 开始成为这次 Release 的工作 Context。
第二步：不另开新对话，直接 @专门 Agent
整理到 Marketing 阶段时，
产品经理不需要：
Copy 整段内容，
再开一个新 Agent，
重新解释一次。
新版 Rovo Chat 可以直接在目前 Thread：
@mention 专门 Agent。
假设团队有一个：
Launch Planning Agent。
它进入目前对话时，
可以取得这个 Thread 已经累积的：
- Context
- Decisions
- Artifacts
然后接着整理：
Launch Message。
Target Audience。
FAQ Draft。
Internal Checklist。
真正节省的不是：
AI 少打几个字。
而是：
第二个 Agent 不用重新学第一次 Agent 已经知道的事情。
第三步：Marketing 不拿摘要，直接接手完整 Chat
Marketing 接手时，
以前 Product Manager 可能要另外写：
「工程目前状态如下……」
但 Summary 有个问题。
它容易把过程压掉。
例如：
工程原本考虑方案 A，
后来因 Security Risk 改成方案 B。
如果 Summary 只留下：
「最后使用方案 B。」
Marketing 很可能不知道：
方案 A 为什么不能再提。
新版 Rovo Chat 可以直接 Share Chat。
Marketing 接手后，
可以沿着原本的 Discussion 继续工作。
所以交接的不只是：
Final Answer。
还包括：
Why。
这对跨部门工作非常重要。
但 Marketing 不会因为 Share Chat 就取得工程机密
这个案例里一定要保留一条界线。
假设原本 Engineering Manager 能看到：
Private Security Jira Issue。
Marketing 没有权限。
分享 Chat，
不代表 Marketing 因此取得这张 Issue 的完整访问权。
Atlassian 明确表示：
Shared Chat 仍然 Permissions-aware。
所以：
Context 可以交接。
Access 不会跟着升级。
如果 Marketing 完成工作真的需要那份数据，
应该正式调整原数据权限。
而不是把 Share Chat 当成绕过 Access Control 的方法。
第四步：客服直接接同一条产品脉络
Launch 前，
Customer Support 也需要知道：
客户可能问什么？
哪些问题已经修好？
哪些还只是 Known Limitation？
哪些回答不能承诺？
以前通常又做一份：
Support Brief。
这次可以让客服直接接手 Shared Chat，
再拉进：
Support Knowledge Agent。
Agent 根据目前 Context 协助整理：
- FAQ Draft
- Known Issue List
- Escalation Condition
- Support Reply Draft
但正式对客户说什么，
尤其涉及：
退款、
SLA、
补偿、
Feature Delivery Date，
不能只因为 AI 已经整理好就直接送出。
这些仍然保留：
Human Gate。
第五步：每周都做的 Sprint Summary，不要再重新 Prompt
这家公司每星期五还有一件固定工作：
Founder 要看 Weekly Update。
过去 Product Manager 每周都要重新叫 AI：
读 Jira。
找本周完成。
整理 Blocker。
列下周 Priority。
找需要主管决定的事项。
如果每周都重新教一次，
就代表这其实已经是一个：
固定 Workflow。
新版 Rovo Chat 可以把它创建成：
Custom Skill。
例如：
Weekly Leadership Update Skill。
固定规则包含：
- 本周完成
- Blocker
- 下周 Priority
- 需要决策事项
- 没有证据的事情不得自行补完
每次只另外指定：
哪一个 Board。
哪个日期范围。
哪一个 Release。
这样才是真正把：
Prompt
变成：
团队工作方法。
哪些事情适合让 Rovo 做？
把整个 Release Workflow 拆开，
AI 适合先处理：
读取既有 Jira／Confluence Context
↓
整理 Release Status
↓
保留 Decisions 与 Open Questions
↓
把 Specialist Agent 拉进同一 Thread
↓
产生 Marketing Brief Draft
↓
产生 Support FAQ Draft
↓
产生 Weekly Status Draft
↓
把重复流程做成 Custom Skill
这些工作的共同点是：
整理、转换、交接、草拟。
哪些一定留下给人？
这家公司的 Human Gate 则设置在：
正式 Release Date
Production Deploy
Pricing Change
客户 SLA／交期承诺
退款／补偿
公开 Marketing Claim
Security Incident 对外说法
删除或大幅修改正式 Jira／Confluence Records
为什么？
因为这些事情做错，
不只是：
「AI Summary 不太好看。」
而是真的会：
影响客户、
影响金钱、
影响 Production、
形成公司承诺。
Atlassian 的 Skills 对部分会修改数据的 Consequential Actions 会要求 Confirmation。
但公司仍然应该自己定义：
什么事情即使平台没有拦，也必须人工批准。
假设能省多少时间？
这里只做保守的假设。
假设两周一次 Release，
每次跨部门交接原本需要：
Product → Marketing：45 分钟
Product → Support：45 分钟
Engineering → Product 补背景：45 分钟
周报刷新：45 分钟
不同 Agent 重复输入 Context：30 分钟
合计：
210 分钟。
也就是：
3.5 小时／每次 Release Cycle。
假设使用 Rovo Chat 后，
Share Chat、@Agent 与 Custom Skill 把大量重复整理拿掉，
但仍保留人工 Review，
每次降到：
2 小时。
理论上减少：
1.5 小时／Cycle。
如果一个月两次 Release：
约 3 小时／月。
这个数字并不惊人。
但不要忘记这是一家只有 6 人的小公司。
真正应该记录的不是：
「AI 一个月帮我们省了几十小时。」
而是四个更实际的 KPI：
交接前后花多少时间？
同一个背景重讲几次？
因 Context 遗失造成多少返工？
Human Review 又花多少时间？
如果没有改善，
Custom Skill 再漂亮也没有 ROI。
还可以再量一个指针：Handoff Rework
例如这家公司过去每月发生：
6 次跨部门重新确认。
像是：
「这不是已经决定了吗？」
「Marketing 怎么还在用旧版本？」
「客服不知道这功能延后了？」
如果共享 Context 后，
降到：
2 次。
这可能比单纯省 3 小时更有价值。
因为 Release 最大成本，
有时候不是整理那 30 分钟。
而是：
有人拿错 Context 做了错的事情。
Memory 也不要变成永久垃圾桶
新版 Rovo 可以让用户查看与修改 Memory。
这家公司可以让它记住：
周报习惯用 Bullet Points。
客户数据不能进公开 Draft。
某些固定 Project Naming Rules。
但不要把：
这星期临时 Delay 一天，
这次客户特殊要求，
暂时性的 Bug 状态
全部当成长期 Memory。
否则：
今天省掉重新解释，
下个月却开始被旧 Context 干扰。
所以 Memory 也要定期问：
这件事下个月还成立吗？
不成立，
就不要当长期规则。
这个案例真正省的是「交接成本」
Rovo Chat 这次更新如果只看表面，
好像只是：
Memory、
@Agent、
Share Chat、
Custom Skill
四个新功能。
但对这家 6 人 SaaS 公司来说，
它们其实都在处理同一件事情：
不要让同一份工作，每换一个人就重新开始。
工程做过的 Context，
Product 接得到。
Product 做过的决策，
Marketing 接得到。
Marketing 准备 Launch 时的背景，
Support 接得到。
每周都重复的整理方法，
下一周也接得到。
AI 真正进入企业后，
下一个效率瓶颈很可能不是：
AI 写得不够快。
而是：
AI、同事与部门之间，工作接不起来。
如果你也想知道自己的工作里，哪一步最适合先交给 AI，留言「流程」。
今天，和 AI 一起进步一点。
每天学会一个 AI 技巧。
每天节省一点时间。
每天提升一点能力。
SasaDaily，陪你一起成长。
推荐阅读
AI 商业案例｜2026/09/18：7 人软件集成公司怎么用 Claude Code Projects？API／Web／Mobile 平行改版，共享规格变更，Merge／Deploy 仍由人批准
AI 商业案例｜2026/09/03：5 人物业管理公司怎么用 Workspace Studio？租客报修自动整理搬档，维修承诺前由人批准
