把 AI 嵌进业务，而不是「用一下 AI」

用 Camila（一个由 AI 运营的独立业务部门）串起全部模块 · 2026-06

PART 1 · 案例Camila：一个由 AI 运营的独立业务部门

Camila 是我们墨西哥业务里负责批发客户（B 端）的 AI。如果只看 WhatsApp，她像个客服；但准确的定位是一个独立的业务部门。关键在于：Meta 广告投放和 Shopify 交易/售后不是挂在她旁边的外部模块，而是她的双手 —— 同一个 AI 体系直接操作广告预算、生成优惠券、处理售后。获客、转化、成交、售后、度量，整个部门由 AI 运营；一位真人同事 Natalia 做质检；我只看日报。

flowchart LR
    subgraph DEPT["Camila 业务部门 — 同一个 AI 体系直接操作"]
        direction LR
        A["Meta 广告投放
获客之手
调预算 · 管系列"] --> B["WhatsApp 对话
转化 · 部门主体"]
        B --> S["Shopify
交易之手
成交 · 售后 · 优惠券"]
        S --> AN["业务数据分析
CPA · GMV · 复购"]
    end
    AN -.->|"反哺投放预算"| A
    AN -.->|"反哺话术实验"| B
    N["Natalia 真人质检
批注 + 打分 + 接管"] -.-> B

下面按这条链路逐段拆开。

1.1 前端获客：Meta 广告直接「打进」对话

批发客户的源头是 Facebook / Instagram 上的 Click-to-WhatsApp 广告：客户点广告，打开的不是落地页，而是直接跳进和 Camila 的 WhatsApp 对话 —— 广告的落地页就是对话本身。这带来一个根本差别：广告买来的不是「点击」，而是「一段从第一句话起就进入记忆系统的对话」，后面每一步都可归因。

投放管理做三件事：

• 预算与系列管理 —— 管理 Meta 广告系列和日预算；
• 每日 CPA 报表 —— 把广告花费和当天新增的 WhatsApp / TikTok 私信对话对齐，算出「每个新客户对话的获客成本」，昨日 + 近 7 日两个口径，天天看趋势；
• 客户优先级标签 —— 按获客成本和线索质量自动给客户打优先级，同步到团队表格 —— AI 和真人都知道先服务谁。

重要的是操作权属：投放不是「人看报表再去广告后台点」的外部流程，而是 camila-architect（3.2 会讲的群里架构师）可以直接接管的操作 —— 调预算、开关系列，在 Lark 群里说一句话就执行。广告是这个部门自己的「获客之手」。

1.2 一条客户消息的完整旅程

客户发来一句「¿Tienen precio de mayoreo?」（有批发价吗），背后发生的事：

sequenceDiagram
    participant C as 客户 (WhatsApp)
    participant W as Camila Worker
(云端程序)
    participant D as D1 数据库
(记忆)
    participant L as Claude 大模型
    participant N as Natalia
(真人质检)

    Note over C: 从 Meta 广告点进来
(Click-to-WhatsApp)
    C->>W: 新消息到达 (webhook 推送)
    W->>D: 读取该客户档案 + 历史消息
(最近30条原文 + 更早的摘要)
    W->>D: 读取知识库补丁 kb_patches
(教练每天更新的话术)
    W->>L: 拼装完整上下文 → 请求回复
    L-->>W: 生成回复文本
    W->>W: 红线检查 (veto rules)
    W->>D: ⚠️ 先把回复写进数据库
    W->>C: 再通过 WhatsApp API 发出
    D->>N: 对话同步到 CRM 后台展示
    N->>D: 逐条批注 + 打分
(反馈落库 → 次日教练实验的原料)
    Note over W,N: 复杂场景: Camila 主动标记转人工
AI 暂停回复 + 群通知,真人接管

三个值得注意的细节：

• 每次回复都要重新「喂」全部上下文 —— 客户档案、历史对话、业务知识，一样不能少。原因见 Part 2。
• 先写库、再发送 —— 哪怕发送失败，数据库里也有完整记录，审计层随时能还原「AI 到底说了什么、想说什么」。
• 真人就在旅程里，不在旅程外 —— Camila 发出的每条回复都出现在 CRM 后台，Natalia 的批注和打分回流数据库，成为次日自动实验的原料（见 1.5）；遇到自己拿不准的场景，Camila 会主动暂停、转人工接管。AI 不是替代人，而是把人放到杠杆最高的位置：质检和关单。

1.3 后端成交与度量：Shopify + 业务数据分析

对话谈成之后，批发客户在我们的 Shopify 批发站下单成交。Shopify 这一侧同样是「手」而不只是数据源 —— camila-architect 直接接管交易侧操作：谈妥价格 → 直接生成优惠券发给客户；售后问题（退换、补发、改单）→ 直接在 Shopify 处理，不需要转人工走后台。客户感受到的是「和一个能拍板、能办事的业务员谈生意」，不是「和一个只会转接的客服聊天」。

同时，订单数据增量同步进 D1 数据库，在闭环里起双向作用：

• 向前喂给 Camila，让她「懂业务」 —— 商品、库存、订单数据同步进来之后，客户问「LL001 黑色 M 码有货吗」「我上次订的发了没」，Camila 查的是真实数据，不是凭模型「印象」作答。这是客服 AI 和业务 AI 的分水岭：她回答的不是「话术」，是「事实」；
• 向后做度量，把一切换算成钱 —— GMV、首单转化率、30/90 天复购、客户终身价值（CLV）。其中最关键的一环是用真实成交反向校准 AI 的判断：AI 当初给某个线索打了 8 分，90 天后他实际买了多少？打分和成交对不上，评分模型就要修。样品单也单独追踪（样品 → 正式订单的转化率）。

度量的结果流向两处：每天早上的日报邮件（给我看），以及反哺两个上游 —— 投放端按 CPA 和成交质量调预算，对话端的话术实验用 GMV 当裁判（1.5 的 PDCA）。没有这一段，前面的一切只是「聊天」；有了它，每条广告、每段对话、每次话术实验都能换算成钱。

1.4 不是一个 AI，是一个「岗位分层」的团队

真正让这套系统能长期运转的，不是那个回消息的 AI，而是围着它的一整套分层。每一层节奏不同、职责不同，就像一家公司（这些层全部以 Cloudflare Worker 的形态跑在云上，基础设施在 3.5 展开）：

关键区分：Watcher 问「系统还活着吗」，Auditor 问「业务决策做对了吗」。一个是秒级的健康检查，一个是天级的质量审计——混在一起就两头做不好。

模型选择也按层分：一线 L0/L1 用 Sonnet（快、便宜、扛得住消息量），L3/L4 教练和审计用 Opus（更强的推理，但每天只跑一次，贵得起）。

1.5 自我进化：每日 PDCA 循环

Camila 不是部署完就不动了。每天早上（墨西哥时间 8 点多），审计层自动跑一轮完整的 PDCA（计划-执行-检查-处理），像一个永不疲倦的运营经理：

stateDiagram-v2
    direction LR
    Plan: Plan 计划
    Do: Do 执行
    Check: Check 检查
    Act: Act 处理

    [*] --> Plan
    Plan --> Do : 从真人反馈聚类 +
KPI 信号生成 0-3 个实验假设
    Do --> Check : 写入话术补丁
实验窗口默认 14 天
    Check --> Act : 对比实验组 KPI vs 基线
    Act --> Plan : 进入下一轮
    Act --> KEPT : 提升达标 → 保留
版本号 +1 (如 v3.42→v3.43)
    Act --> ROLLED_BACK : 负向 → 自动回滚
5 分钟内生效

• 真人在环：Natalia 每天给 Camila 的回复写批注、打差评，这些反馈被自动聚类，成为下一轮实验假设的来源。
• 话术有版本号：每次实验被「保留」，系统提示词整体快照一份、版本号 +1 —— 像发软件版本一样管理 AI 员工的话术，出问题可以回滚到任何历史版本。
• 我与系统的接触面 = 每天一封邮件：线索漏斗、团队记分卡、在跑的实验、健康告警，全部浓缩在一封日报里。我不看代码、不看后台，看邮件就够了。

1.6 管理方式：每个 AI worker 有自己的「工号」

所有 AI worker 都遵守一条硬规则：1 个项目管理工单 ↔ 1 个 worker（我们用 Linear，类似 Jira）。回消息的 Operator 有自己的工单，监控的 Watcher 有自己的工单，教练、审计各有各的。任何改动都挂在对应工单下，部署脚本会强制校验这个绑定关系。

好处：每个 AI 员工的「人事档案」完整可查 —— 它为什么存在、改过什么、出过什么事故、谁批准的 —— 全在它的工单时间线上。AI 团队规模化之后，这就是组织的可追溯性。（Linear 的完整角色 —— 台账 + 工作协议 —— 在 3.7 展开。）

PART 2 · 基础知识对话、Session、Memory —— 为什么架构长这样

很多人以为 ChatGPT「记得」前面聊了什么。其实不是模型在记，是应用程序把前面所有消息存了下来，每次提问时整段重发。理解了这一点，下面四个概念就清楚了。

2.1 对话（Conversation）= 一个消息数组

所谓「对话」，在工程上就是一个列表：[客户说A, AI答B, 客户说C, AI答D, ...]。模型每次收到的输入 = 系统指令 + 这个列表 + 最新一条消息。模型输出一条回复，应用把它追加进列表，循环往复。对话的「连续感」完全是应用层制造的假象。

2.2 Session = 给对话一个身份标识

Camila 同时和几百个客户聊天，怎么不串线？答案是每个对话有一个唯一标识 —— 在我们这里就是客户的手机号（chat_id）。消息进来，按手机号去数据库捞出「这个客户」的档案和历史，拼上下文。Session 没有「结束」的概念：客户哪怕半年后再发消息，按手机号一查，历史还在，对话无缝续上。

2.3 Session 维持 = 滚动窗口 + 摘要

问题来了：老客户聊了 500 条消息，难道每次都把 500 条全发给模型？不行 —— 又贵又慢，而且上下文太长模型反而抓不住重点。我们的方案：

• 最近 30 条原文保留，逐字发给模型；
• 更早的历史压缩成一段滚动摘要（也是用模型生成的），存在客户档案里；
• 每积累 20 条新消息，摘要自动刷新一次。

效果：无论客户聊了 50 条还是 5000 条，每次发给模型的上下文体积基本恒定 —— 成本可控、速度稳定、重点不丢。

2.4 Memory = 两种完全不同的记忆

「记忆」这个词经常被混着用，但工程上必须拆成两层，存储和更新机制完全不同：

把这两层分开的价值：改「培训手册」不会污染任何客户的对话历史；反过来，单个客户的特殊情况也不会变成全局规则。教练层每天产出的改进，全部走第②层，改话术不用改代码、不用重新部署。

2.5 把基础知识对上架构决定

到这里可以把因果链完整连起来了 —— 每个架构决定都是从「模型无状态」这个事实推出来的：

PART 3 · 实施层MA + Lark：把 Agent 装进团队的群里

前面讲的 Camila 是「面向客户」的 AI。这一部分讲面向团队内部的 AI 怎么部署 —— 也就是把一个 agent 直接装进飞书（Lark）群里，团队成员像 @ 一个同事一样 @ 它。这是目前整套体系里实施杠杆最大的一块。

3.1 什么是 MA（Managed Agents）

MA = Anthropic 托管的云端常驻 agent 运行时。和普通的「调一次 API、答一句话」不同，MA 是一个有持续会话、有长期记忆（memory store）、能调工具（跑命令、查数据库）的 agent 实例，常驻在 Anthropic 云上，不占我自己的任何机器。

但 MA 本身没有「脸」—— 团队成员不可能去调 API。所以中间需要一座桥：

flowchart LR
    N["团队成员
Lark 群 · 手机即可"] -->|"@机器人 发消息"| WH["Lark Webhook"]
    WH --> B["桥接 Worker
camila-architect-bot"]
    B <-->|"SSE 流式连接"| MA["MA 云端会话
常驻 agent + 长期记忆"]
    MA --> T["tools 接口
取证据 / 查数据"]
    T --> D[("D1 数据库
话术补丁·对话·审计日志")]
    MA -->|"写视图 / 改数据
白名单 + 审计"| CRM["crm.felyfit.com"]
    B -->|"回帖到群线程"| N

桥接 Worker（一个轻量云函数）做四件事：

• 身份验证 —— 只有白名单成员（我 + 指定同事）能唤起 agent；
• 线程 ↔ 会话映射 —— Lark 群里每个话题线程对应一个 MA 会话，存在 KV 里。同一线程里追问，agent 记得前文；开新线程，就是新会话。这天然解决了「群里多个话题互相串」的问题；
• 流式转发 —— 把群消息推给 MA，把 MA 的回答流式贴回群线程（先放一个 🤔 表情表示在想，10~30 秒后回帖）；
• 暴露工具 —— agent 可以回调一组 /tools/* 接口去拉证据：查对话记录、列话术补丁、看审计日志。

3.2 部署在群里的「架构师」：camila-architect

用这座桥部署的第一个团队级 agent 叫 camila-architect（L5 架构师层的化身）。它住在一个私有 Lark 群里，群成员是我和 Natalia（负责质检 Camila 的真人同事）。它的职责不是回客户消息，而是治理 Camila 本身：

• Natalia 在群里反馈「Camila 这类回复不对」→ architect 拉出相关对话证据、定位是哪条话术规则的问题；
• architect 起草话术补丁 → 我在群里批准 → 它直接执行写库，补丁 5 分钟内生效，并自动建工单追踪 14 天评估期；
• 写补丁前它会先做「红线预检」—— 检查新话术会不会被一线 worker 的输出红线静默拦截（这是真实事故换来的教训）；
• 它还直接持有业务操作权 —— Meta 投放（调预算、开关系列）、Shopify 售后处理、优惠券生成，都能在群里一句话执行。Part 1 说 Camila 部门有「双手」，操作入口就是这里。

注意这意味着什么：业务流程的迭代本身，也变成了在聊天里完成的事。提需求、看证据、批准、上线、回滚，全程不开电脑，在手机 Lark 上点几下。

3.3 案例：把 CRM 权限开放给 architect

最近（2026-06）我做了一个更激进的授权：把 CRM 系统（crm.felyfit.com，团队看客户、接管对话用的后台）的配置和数据权限开放给了 architect。开放的是两类能力，各带各的安全栅栏：

这个案例想说明的实施层逻辑是：MA 桥接到 Lark 之后，「改系统」的门槛从工程师降到了任何业务成员。过去 Natalia 想要一个新报表，要提需求 → 排期 → 我写代码 → 部署，周期以天计；现在她在群里说一句话，秒级上线。而我作为 owner 的控制力没有丢 —— 因为权限不是「全开」，而是白名单 + 审计 + 版本快照 + 一键回滚这套栅栏精确圈定的。复杂业务流程的迭代速度，就是这样提上来的。

3.4 两种部署架构：本地桥 vs 云端 MA —— 怎么选

把 agent 装进群，实际上有两条路。我两条都在用：架构 A（本地桥）是我自己起步的方式 —— 每个 Lark 群对应我电脑上的一个工作目录（cwd），桥接到本机跑的 Claude Code 进程；架构 B（云端 MA）就是上面 camila-architect 的方式。它们不是新旧之分，而是适用场景不同：

flowchart LR
    subgraph A["架构 A · 本地桥"]
        direction LR
        GA["Lark 群"] --> BA["桥接"] --> PC["自己的电脑
Claude Code 进程
每群 = 一个工作目录"]
        PC --> FS[("本地一切资源
代码仓库·文件·技能库")]
    end
    subgraph B["架构 B · 云端 MA"]
        direction LR
        GB["Lark 群"] --> BB["通用桥接 Worker
+ 群→agent 注册表"] --> MB["MA 云端常驻
每群 = 沙箱+记忆库"]
        MB --> TB[("精确圈定的资源
工具白名单·数据库绑定")]
    end

怎么选 —— 问自己三个问题：

• 群里的工作是什么形状？「对话 + 查数据 + 改配置」型 → B 足够且更稳；需要深度动代码、动文件的 → A，或者把所需能力逐个做成工具接口再上 B；
• 谁在依赖它？只有自己用，挂半天无所谓 → A 没问题；团队每天的工作流靠它 → 必须 B；
• 权限敏感吗？群成员能接触的数据需要按群隔离（财务群 ≠ 研发群）→ B 的沙箱模型天然合适。

我的实际答案是混合：个人和开发群留在架构 A（cwd + 本地全能力不可替代），团队和业务群走架构 B。而且这也是一条自然的演进路径 —— 用 A 快速验证「这个群装个 agent 到底有没有价值」，验证成立、开始有人依赖它了，再迁到 B 规模化。两边的桥接逻辑（webhook、白名单、线程↔会话映射）是同构的，迁移成本主要在把本地能力改造成云端工具接口。

3.5 整个系统跑在哪：Cloudflare 是这套架构的「身体」

讲到这里需要专门停一下，介绍承载这一切的基础设施。除了大模型本身（Anthropic）和团队协作面（飞书），整个系统的「身体」全部跑在 Cloudflare 一家上 —— 几十个 worker、数据库、密钥、文件存储、定时器、公开站点、内部后台的门禁，一个账号全包：

为什么选它（给朋友的选型参考，四个理由按重要性排）：

• 零运维 —— 没有服务器这个概念。没有机器要打补丁、要重启、要扩容；一个人运营几十个服务成为可能。这和 Part 2 的设计哲学完全咬合：Worker 本身无状态（随时销毁重建），状态全在 D1 —— 数据库是唯一事实，任何组件挂掉都不丢记忆；
• 和「AI 写代码」天配。一个 worker = 一个代码文件 + 一份配置，Claude Code 一条命令部署，秒级上线。部署单元小而标准，AI 从生成到上线的摩擦趋近于零 —— 3.8 的「管理中心」模式之所以可行，一半功劳在这里；
• 全家桶零胶水。Worker 直连 D1 / KV / R2（原生绑定），没有网络配置、连接串、防火墙规则要管；
• 成本结构。按用量计费，这套几十个 worker + 数据库 + 存储 + 定时器的系统，月账单是「几美元到几十美元」量级 —— 比租一台云服务器还便宜。

朋友常问：为什么不是 AWS / 自建服务器？AWS 当然能做，但配置面大（网络、权限、实例运维），适合有专职运维团队的公司；自建服务器则直接违反「无单点」原则 —— 我们的本地桥（3.4 架构 A）就是教训来源。Cloudflare 的取舍是：能力上限低一点（单次执行时长、CPU 有限制，跑不了重计算），换运维成本趋近于零。对一支 AI 员工舰队来说，标准化和零运维比峰值算力重要得多 —— 重计算的部分本来就在 Anthropic 的云上（模型推理），Cloudflare 只需要做好「轻而多」的编排层。

3.6 让 agent 动起来：cron 是整个系统的心跳

这意味着架构里所有看起来「自动」的行为 —— 每 5 分钟同步消息、每天早上跑审计发日报、定期检查健康 —— 没有一件是 agent「自己想起来要做」的。每一个自动行为背后，都有一个定时器在按节拍踢它一脚。定时器（cron / launchd）是整个体系里和数据库同等重要的基础设施：

「机器人触发机器人」值得单独说：装在群里的 agent（架构 A/B 都一样）只在被 @ 时才工作 —— 它自己没有日程表。怎么让它每天定时做例行工作？我的做法是再部署一个定时机器人：它由 cron 驱动，按节拍在群里发出触发消息（@ 目标 agent +「开始今天的 XX 例行」），把对方叫醒。在群成员看来，就是两个机器人在固定时间自动接力干活 —— 实际上是一个有心跳的简单机器人，在给一个有大脑的 agent 当闹钟。

这里有一条设计原则：心跳和大脑分离。定时器只负责「什么时候叫醒谁」，不携带任何业务逻辑；业务判断全部在 agent 里。好处是两边可以独立演化 —— 改业务不用碰定时器，调节拍不用碰业务。

把两个底层事实放在一起，整个架构的根就出来了：模型无状态 → 数据库给它记忆；模型被动 → 定时器给它心跳。剩下的一切都是在这两根支柱上搭出来的。

3.7 Linear：AI 舰队的工单系统 —— 组织台账 + 工作协议

1.6 提过每个 worker 有「工号」，这里把 Linear（类似 Jira 的项目管理工具）在体系里的完整角色讲透。它表面上是个任务板，实际承担两个谁也替代不了的职能：

职能一：组织台账 —— 唯一编号与 worker / workflow 一一对应。每张 issue 有全局唯一编号（如 FEL-83），每个部署上云的 worker 必须绑定唯一一张 issue 作为它的「户口」，1:1 硬绑定：

• 部署脚本强制校验这个绑定 —— 没绑定工单的 worker 部署直接失败，从机制上杜绝「无主程序」；
• worker 的云端控制台链接固定挂在 issue 的资源区，双向可查：拿到任何编号能沿父子链解析出对应的 worker，看到任何 worker 能找到它的完整档案；
• 价值在规模化时显现：几十个 worker 在跑，没有台账很快会出现「没人记得这东西为什么存在」的孤儿程序。有了 1:1 绑定，每个 AI 员工的人事档案 —— 为什么创建、改过什么、出过什么事故、谁批准的 —— 全在它工单的时间线上。

职能二：工作协议 —— 需求从 issue 进，结果从 comment 出。issue 同时是人和 AI 之间的「需求交接面」，双方各守一半：

flowchart LR
    A["创始人
在 issue 正文写需求
(正文只有我能改)"] --> B["agent 接单
读正文 + 历史 comment
+ 父工单上下文"]
    B --> C["状态转 In Progress
开始干活"]
    C --> D["关键节点写 comment
(带证据,不是打卡)"]
    D --> E["完成: 写验收 comment
做了什么 / 怎么验证 / 改了哪里"]
    E --> F["状态转 Done"]
    F -.->|"我随时打开 issue
就知道做到哪了"| A

• 需求侧（我的领域）：issue 正文（description）是创始人写源头想法的地方，agent 只读不改 —— 需求的原始意图永远不会被 AI「润色」走样；
• 执行侧（agent 的领域）：agent 从 issue 读取工作（正文 + 全部历史 comment + 父工单上下文），状态转 In Progress；过程中在关键节点写 comment（附证据：数据查询结果、实测记录），完成时写验收 comment（做了什么 / 怎么验证的 / 改了哪些文件），状态转 Done；
• 大需求拆解：跨多个 worker 的需求，agent 先发 plan comment 等我批准，再拆成子工单挂到各 worker 的「户口」下，逐个完成、回需求 issue 勾清单 —— 本文档自己就是这么管理的（一张 issue，五轮 comment 迭代）；
• 诚实原则：关错了重开并说明原因；之前的 comment 错了就发新 comment 修正，不删历史 —— 时间线完整可追溯。

最后点一个和 Part 2 呼应的本质：issue 时间线其实是又一种外置记忆 —— 跨会话、跨 agent 的「工作记忆」。模型无状态，对话会结束、session 会过期，但 issue 不会。换一个全新的 agent（甚至换一个模型），读一遍 issue 就能无缝接上上下文继续干。对话给 agent 的是短期记忆，数据库给的是业务记忆，Linear 给的是工作记忆 —— 三层缺一不可。

3.8 创始人的管理中心：Claude Code

最后一个问题：上面这一切 —— 桥接 Worker、MA agent、CRM 工具、数据库表、几十个定时任务 —— 是谁开发和维护的？答案是：没有工程团队。全部由我在 Claude Code（终端里的 agent 客户端）里用对话生成、部署和管理。

flowchart LR
    W["创始人
用业务语言描述意图"] <--> CC["Claude Code
管理中心 / L5 驾驶舱"]
    CC -->|"生成代码 + 一键部署"| F["云端舰队
几十个 worker + MA + 定时任务"]
    CC -->|"建工单 / 绑定 / 写进展"| L["项目管理
每个 worker 一张工单"]
    CC -->|"查数 / 审计 / 复盘"| D[("数据库 D1")]
    F -->|"日报 / 告警"| W

Claude Code 在这套体系里扮演的就是 L5 架构师层的驾驶舱，管理闭环全部在同一个对话界面里完成：

• 生成 —— 我用业务语言说「给 Camila 加一个客户分层标签」，它产出 worker 代码、数据库变更、部署脚本；
• 部署 —— 它自己执行部署命令推上云端，部署完按规则验证「真的产出了业务数据」才算完成；
• 治理 —— 每个 worker 绑定一张工单（3.2 说的「工号」）、部署前过门禁检查（代码已提交、危险模式扫描）、部署后回归验证老功能 —— 这些规则写在一份它每次开工都必读的规则文件里，相当于公司的「工程制度」，约束的对象是 AI 而不是人；
• 复盘 —— 出问题时我在对话里描述现象，它直接查数据库、查日志、定位根因、修复、再把教训写回知识库。

所以创始人的角色发生了本质变化：不是「会用 AI 工具的管理者」，而是「一个人 + 一个管理中心 agent，运营一支 AI 员工舰队」。我的产出物不再是代码，而是两样东西：用语言表达清楚的业务意图，和沉淀下来的制度（规则文件 + 知识库）。Claude Code 负责把意图变成部署，把教训变成制度。这也回答了一个朋友们常问的问题 —— 「你们技术团队多少人？」：写代码的是 AI，管 AI 的也是 AI，我只管业务。

PART 4 · 推广研发型团队怎么用：MA + Lark 群管理研发流程

Camila 是「客服业务流程」的例子，但这套模式不挑业务。如果你的公司是研发驱动的（大量需求讨论、技术决策、实验、评审），同样的 MA + Lark 群结构可以直接套用 —— 而且研发流程可能是比客服更适合的场景，因为研发最大的痛不是「干活慢」，而是过程资产全散落在聊天记录、会议和个人脑子里，无法分析、无法复盘、无人推进。

4.1 核心思路：让研发工作「全程留存在体系内」

把每个研发小组的 Lark 群装上一个 agent，从此这个群同时是三样东西：

4.2 层级映射：Camila 的骨架 → 研发流程

4.3 落地清单（从零到跑起来）

先按 3.4 选好架构：起步验证用本地桥（A）也完全可以，下面按企业级的云端 MA（B）写：

• 第 1 步 — 建一个 Lark 应用（机器人），拉进研发群；
• 第 2 步 — 部署桥接 Worker：webhook 收群消息、白名单验身份、线程↔会话映射、流式转发（这是唯一需要写的「胶水代码」，几百行）；
• 第 3 步 — 创建 MA agent + 长期记忆库，系统指令里写清楚它的角色、团队的术语表、它能调哪些工具；
• 第 4 步 — 建沉淀数据库（几张表：决策、需求事件、阻塞、反馈），把代码仓库 / 文档 / 日历的同步接上（L0）；
• 第 5 步 — 加每日 cron：审计 + 主动反馈发群（L4），跑顺之后再加流程改进实验层（L3）。

顺序很重要：先让「留存 + 可问」跑起来建立信任，再开「主动反馈」，最后才是「自动改流程」。每多开一层权限，配一层栅栏（白名单、审计、回滚）—— 这是 Part 3 CRM 案例验证过的节奏。

PART 5 · 复制同一套模式，跑了四条线

这套「分层 + 数据库记忆 + 每日 PDCA + 工单绑定」的模式不是为 Camila 一个定制的，同样的骨架已经复制到四条业务线，只换领域逻辑：

三句话总结

• AI 不是工具，是员工 —— 给它岗位（分层）、记忆（数据库）、绩效（PDCA）、工号（工单绑定），它才能长期可靠地干活。
• 一切设计源自两个底层事实 —— 模型无状态（不记得任何事 → 记忆外置到数据库，才有窗口、摘要、补丁注入）；模型被动（不会自己醒来 → 一切「自动」都来自 cron / launchd / 机器人触发机器人这些定时心跳）。
• 架构一旦成型，复制成本极低 —— 第二条、第三条业务线只是换领域知识，骨架不变。
• MA + Lark 群是团队侧的入口 —— agent 装进群里之后，业务成员用说话就能迭代系统（权限靠白名单 + 审计 + 回滚圈定），研发团队则把整个研发过程留存进体系、随时可分析、由 agent 主动推进。
• 创始人只需要一个管理中心 —— Claude Code 是 L5 驾驶舱：生成、部署、治理、复盘全在一个对话界面里完成。写代码的是 AI，管 AI 的也是 AI，创始人管业务和制度。
• 基础设施零运维 —— 整个「身体」跑在 Cloudflare 上（函数 + 数据库 + 存储 + 定时器一个账号全包），没有服务器要管，月成本几十美元量级，AI 生成的代码秒级部署。

常见追问

Q：AI 答错了怎么办？

三道防线：发送前的红线检查（veto rules）拦截高危内容；真人 Natalia 每日抽查打分；审计层每天复盘全量对话并把错误聚类成改进实验。错误不可能为零，但每个错误都会变成第二天的训练材料。

Q：为什么不直接用现成的客服 SaaS？

SaaS 给你的是固定的「记忆和进化机制」。自己掌握数据库 + 提示词版本 + PDCA 循环，意味着 AI 员工的每一点进步都沉淀成自己的资产，且四条线共享同一套骨架，边际成本趋近于零。

Q：成本多少？

一线回复用中档模型（量大但单次便宜），深度复盘用旗舰模型（贵但每天只跑一次）。整体远低于一个全职客服的工资，而且 24 小时在线、永不离职、每天变聪明一点。