这是一个 SasaDaily 假设商业案例。

不是 Anthropic 官方客户，也不是已公开的真实导入成果。

假设一家 7 人企业软件集成公司，团队组成是：

  • 1 位老板／技术主管
  • 1 位 Project Manager
  • 3 位软件工程师
  • 1 位 Mobile Engineer
  • 1 位 QA

公司替中小企业串接 ERP、会员系统、付款、Web 与 Mobile App。

表面上看，工程师最花时间的是写 Code。

但只要遇到一个跨系统改版，真正麻烦的常常是：

五个地方都要改，而且每个人都要知道其他人改了什么。

假设今天客户要淘汰旧 API

例如客户准备禁用原本的：

v1 Customer API

改成新的 v2。

这不是把一支 API 换掉就结束。

它可能同时牵涉：

  • Backend Service
  • Web 后台
  • Mobile App
  • Automated Tests
  • API Documentation
  • Deployment Order

以前团队可能这样做：

PM 先跟 Backend Engineer 说一次。

再跟 Web Engineer 说一次。

再重新解释给 Mobile Engineer。

Backend 做到一半发现字段改名，再回头通知其他人。

Web 已经先按照旧规格写完，又要重新修改。

等所有人做完，才开始问：

到底哪个 PR 要先 Merge？

Claude Code Projects 想改的，就是这段协调工作。

第一步：人先定 Goal，不先叫 AI 乱改

团队创建一个 Claude Code Project。

先写清楚：

目标：淘汰 v1 Customer API，让 API、Web、Mobile 全部改用 v2。

同时放入：

  • API Repository
  • Web Repository
  • Mobile Repository
  • Migration 说明
  • Client Requirements
  • Project Instructions

但团队另外写三条不能省略的规则：

Production 不得自动 Deploy。

Database Migration 运行前一定停。

涉及 Auth、Payment 或客户数据结构的修改一定由技术主管确认。

AI 可以帮忙做很多事，但决定权先画清楚。

第二步：Coordinator 先拆工作

Anthropic 对新版 Projects 的设计，就是让最上层 Claude 负责 Scope、Delegate 与协调 Threads。

在这个假设案例里，Coordinator 可能把工作拆成：

Thread A

检查 API Repository，找出所有 v1 Endpoint 与替代方式。

Thread B

修改 Web Repository 里的 v1 Calls。

Thread C

修改 Mobile Repository。

Thread D

更新 Automated Tests。

Thread E

整理 Migration Documentation。

这几条工作可以同时前进。

工程师不需要自己开五个 Claude Code Session，再一直切窗口看谁做到哪里。

第三步：规格改变放进 Shared Memory

做到一半，API Engineer 发现：

原本文档里的：

customer_total

最后决定改成：

lifetime_value

而且 Mobile App 旧版还需要两周兼容期。

这种信息如果只留在某一条 Chat，后面很容易出事。

新版 Claude Code Projects 的每一条 Thread 都会使用，也能贡献同一个 Shared Memory。

在这个假设 Workflow 里，团队可以把：

  • 字段名称变更
  • 兼容期限
  • Release Date
  • 某功能取消原因
  • 哪个服务修改前一定要找谁

留在同一个 Project Context。

所以后面的 Thread 不必每次从头重新交代。

但要注意：

Shared Memory 不等于 Code 自动同步。

每一条 Thread 还是在自己的 Branch 与 Repository Copy 工作。

第四步：每条 Thread 自己改、自己测

Anthropic 官方说明，连接 Repository 后，Thread 可以：

  • 修改 Code
  • 运行 Tests
  • 开 Pull Request

所以假设 Web Thread 完成后，可以先：

改 Code

→ 跑 Tests

→ 开 PR。

Mobile Thread 也可以在自己的 Branch 做同样流程。

这时候真正省下来的，不一定只是打字速度。

而是原本：

「一个做完，下一个人才开始」

开始变成：

可以平行的工作同时往前。

第五步：Coordinator 整理，但不替人按 Production

假设最后五条 Threads 都完成。

Coordinator 可以协助整理：

  • 哪些 PR 已完成
  • Tests 是否通过
  • 哪些工作互相依赖
  • 哪一个 PR 应该先 Merge
  • 还有什么未解问题

但团队没有把最后决策交出去。

Human Gate 仍然保留在：

① Architecture

新的 API 设计是否真的符合客户需求。

② Merge

多个 Branch 最后是否能安全集成。

③ Database Migration

正式数据结构要不要变更。

④ Auth／Payment

涉及登录、权限、付款不能只看 AI 说「测试通过」。

⑤ Production Deploy

最后上线仍由技术主管批准。

这一点很重要。

因为 Anthropic 也明确说明：

如果两条 Threads 修改到同一段 Code，还是可能产生正常的 Merge Conflict。

Coordinator 可以帮你管理 AI，

但不代表 Software Engineering 的风险因此消失。

假设 ROI 怎么算？

这里不用「AI 帮你省 80% 开发时间」这种没有依据的数字。

只算一个比较容易量化的东西：

跨人员协调时间。

假设这家公司每周平均有 3 个跨 Repository 的 Change Requests。

原本每周花在：

  • 重新解释 Context
  • 同步规格
  • 查各人进度
  • 整理 Handoff
  • 确认 Merge 顺序

总共约：

6 小时／周。

导入这套 Workflow 后，假设降低到：

3.5 小时／周。

理论上少掉：

2.5 小时／周。

一个月以四周计算：

约 10 小时／月。

如果用假设内部综合工程时间成本：

NT$900／小时

计算，

理论时间价值约：

NT$9,000／月。

但这不能直接理解成公司每月多赚 NT$9,000。

因为还要扣掉：

  • Claude 使用成本
  • 额外 QA
  • Code Review
  • Merge Conflict 处理
  • 导入与学习成本
  • AI 产生错误后的返工

所以真正该追踪的 KPI 不是「开了几个 Agent」。

而是：

Handoff 时间有没有下降？

返工有没有增加？

PR Lead Time 有没有缩短？

Production Incident 有没有上升？

这个案例真正改变的是什么？

以前团队的流程比较像：

人分工作

→ 人重复讲 Context

→ 每个人各自做

→ 人追进度

→ 人重新集成。

Claude Code Projects 想把它改成：

人定目标与边界

→ Coordinator 拆工作

→ 多 Threads 平行运行

→ Shared Memory 保留共同 Context

→ AI 整理结果

→ 人 Review

→ 人批准 Merge／Migration／Deploy。

AI 真正适合接手的，不一定是「整个软件项目」。

反而可能是中间大量、重复的：

拆工作、搬 Context、追进度、整理结果。

最后真正会影响客户、数据与 Production 的决定，仍然留在人手上。

如果你也想知道自己的工作里，哪一步最适合先交给 AI，留言「流程」，我可以先帮你看看从哪一步开始。

今天，和 AI 一起进步一点。

每天学会一个 AI 技巧。

每天节省一点时间。

每天提升一点能力。

SasaDaily，陪你一起成长。

推荐阅读

AI 商业案例｜2026/09/11：6 人 SaaS 团队怎么用 Qodo？Coding Agent 改完先独立 Review，Production 决策仍由人批准

AI 商业案例｜2026/09/07：5 人网站维护团队怎么用 Qwen Code？项目规则分开记、多个 Agent 分工，正式上线仍由人批准

AI 商业案例｜2026/08/24：6 人网站代营运团队怎么用 Slack Code？客户小改版直接变 Plan、Preview 与 Review，上线仍由人批准