FDE 注意了：跨客户复用经验，别越过项目边界

从上一篇关于客户项目工作环境的文章开始，我们关注的是一名前置部署工程师（Forward Deployed Engineer，FDE）如何在客户交付单元（engagement）里持续调查、实施和验证。

当我们把这个工作方式放大到多个客户项目时，问题很快就变了。上午，工程师还在客户 A 的环境里排查部署问题；下午，客户 B 需要确认一份实施方案；另一个项目又发来消息，等待团队判断一个可能影响交付的系统变更。

这时客户很容易问：“上一个项目不是已经解决过了吗，为什么这次还要重新做？”工程师却知道，客户 A 的版本、网络、权限和业务目标可能都不同。直接复制上一个项目的方案，可能把不适用的假设带进客户 B；完全不复用，又只能重新走一遍已经走过的排查路径。

如果把所有客户资料放进一个“大知识库”，智能体（Agent）也许更容易搜索，却更难判断哪些内容可以使用。客户名称、端点、环境细节和未公开方案，可能随着一次检索进入另一个项目。反过来，如果每个客户项目完全独立，边界清楚了，团队又可能看不见重复发生的问题，也不知道哪些经验值得整理。

所以，多客户 FDE 团队需要同时回答几件事：客户项目如何保持独立，经过验证的经验如何被安全复用，多个项目的风险和注意力如何被及时看见？

我们把 Forma 放进这个场景时，得到的不是一个“把所有项目放在一起”的答案，而是一种分层的工作方式：每个客户项目拥有自己的工作区，团队经验进入另一个实践工作区，多项目的组合状态则通过轻量的外围机制来观察。

可以先记住这条主线：

客户项目事实 → 脱敏证据卡 → 团队实践提案 → 人工审查
→ pattern / guideline / template → 新项目结合当前事实重新验证

跨项目“蒸馏”可以理解为下面这条受边界约束的转换链：

图中，跨项目对照只接收经授权、脱敏的证据卡；客户原始事实仍留在各自项目工作区，自动化最多准备候选，不能越过人工审查，复用产物进入新项目后也必须重新验证。

项目组合观察只提供启动“蒸馏”和分配注意力所需的元数据，不参与复制客户正文。Forma 提供文件、结构、引用、模板和检查；team-practice、证据卡和 portfolio 是团队约定；仓库授权、凭证、通知和组合看板由外部工具与组织机制负责。

需要先说明这篇文章的实践背景：团队已经验证了“项目事实留在项目、经验经过脱敏审查后再抽象、进入新项目后重新验证”这一协作方法；文中的双项目对照是根据这套团队经验整理出的参考示例，用来展示这条流程如何保留环境差异、失败反例和重新验证条件。它不是真实客户生产效果的承诺，也不代表 Forma 已经提供完整的多客户管理能力或自动化蒸馏。其他团队仍需要结合自己的授权模型、交付流程和真实项目逐步验证。

客户 A 的经验，为什么不能直接带给客户 B

单个客户项目中的知识，和团队希望长期复用的经验，并不是同一种东西。

客户项目的环境事实可能记录一个特定版本、一个受限网络、一组认证方式和一条不能直接套用的操作步骤。它对当前项目非常重要，却不一定适用于下一个客户。项目中的 decisions 还可能包含客户特有的取舍、预算约束和未公开的实施安排，更不能因为“看起来有参考价值”就自动共享。

团队实践则需要另一种抽象。它应该回答：某类问题通常有哪些排查方向，某种方案在什么条件下已经验证，哪些做法容易失败，以及什么时候必须停下来重新确认。它不能带着某个客户的环境细节，却必须保留足够的适用条件和证据。

多客户场景中，内容需要按归属分开处理：

因此，本文的核心取舍是让事实、经验和注意力各自归属清楚：上一篇文章讨论客户项目工作环境，本文继续讨论多项目下的关联边界。

先把事实留在各自的项目里

上一篇文章已经说明，客户交付单元可以从独立的 Forma 工作区开始。到了多客户场景，这个决定不只是组织习惯，更是客户边界的一部分。

客户 A 的工程事实、联系人、环境限制、问题记录、决定和操作步骤，应该留在客户 A 的仓库和工作区中。客户 B 有自己的同类结构；两者不是同一知识库里的两个文件夹，而是可以独立检查、在各自授权边界下运行和独立交付的工作单元。

一个客户项目可以先保留 customers、communications、asks、issues、proposals、decisions、tasks、runbooks 和 verifications，再按需要加入 guidelines 与 engineering。这些目录和对应的 content groups 是面向 FDE 工作的项目约定，不是 Forma 固定提供的内容类型。代码、配置、测试和部署脚本仍然是普通工程资产；需要长期说明的架构决策、使用边界和验证结果，再以 Markdown 条目记录下来。

这种隔离不替代权限管理：仓库访问权、智能体工具范围、备份、凭证和人员权限仍需单独设计。独立仓库提供了更容易审查的物理边界，智能体在客户 A 中工作的默认上下文也只是客户 A 的文件。

客户工单、代码仓库、即时通信（IM）、邮件和会议系统也不必全部迁移到这个工作区。保留在外部系统的信息，可以通过 communications 中的索引条目记录来源、维护人、访问方式和关联关系。外部系统继续作为事实来源，工作区负责为团队成员和智能体保留进入这些信息的路径。

它还有一个容易被忽略的好处：客户项目的仓库本身可以成为交付和审计载体。工程事实、项目规则、框架骨架和工作指引都能通过 Git 记录变化；项目结束时，客户留下的是一份可以继续维护、审查和退出的工作成果，而不是只能留在某个服务端账户里的数据。

在这种用法下，工程师仍可用 forma check --json 检查结构和引用，用 forma workspace health --json 发现健康问题，用 forma view render --json 查看状态；客户之间没有共享可变状态。它牺牲一些“全局搜索”的方便，却换来更清楚的责任边界。

团队实践工作区：经验不是资料回收站

客户项目被隔离之后，团队仍然需要一个地方积累可复用经验。这里可以设计一个团队实践工作区，但要先明确：practice 不是 Forma 原生提供的固定空间，而是团队基于业务需要定义的一层组织方式。

一个刚开始使用的实践工作区不需要复制所有客户项目。它可以先从少量内容开始，例如：

team-practice/
├── overview/                实践路径和导航
├── customers/               最小脱敏客户索引
├── projects/                脱敏项目观察
├── communications/          外部来源索引
├── evidence-cards/          跨项目对照证据
├── verification/            正向、反例和调整后的结果
├── proposals/               待审查的实践候选
├── reviews/                 人工接受、拒绝或调整
├── patterns/                经过审查的条件化实践
├── guidelines/              团队与智能体共同遵守的规则
├── reusable-templates/      可复用的团队形状
├── revalidations/           新项目中的重新验证
├── roles/                   责任元数据
├── portfolio-observation/   轻量项目注意力元数据
└── .forma.md                Forma 工作区入口

当前仓库的团队实践工作区示例把上面的稳定记录类型配置成独立 content groups；每个 group 都有自己的 include pattern、schema、create template 和分区指引。guidelines/practice-partition-contracts.md 以 section-projected Skill 提供完整路由表，但这些 group 和分区仍然是团队约定，不是 Forma 原生的 customer、project、pattern 或 portfolio domain types。

其中，customers 和 projects 是来源索引，应使用脱敏后的稳定标识，而不是客户名称、端点或可传播的原始链接。它们可以记录允许共享的最小摘要、来源工作区、访问边界、项目类型和影响适用性的条件，让实践条目引用 projects/project-a 而不复制客户资料。

这两个分区不能成为客户信息和项目状态的第二真相源：联系人、端点、当前任务、正式决定和实时交付状态仍留在客户项目。只有经过授权、脱敏且确实影响适用性的约束才保留摘要，例如“变更需要书面确认”；回到原项目核对时仍需来源 FDE 或授权审查者使用原项目权限，索引还应记录脱敏状态、审查人和最近核对时间。

一条实践条目不应只有结论，还要说明适用条件、限制、验证来源、维护人和成熟度。团队可以自定义 maturity 枚举，如 proven-once、proven-multi 和 deprecated；它们是管理约定，不是 Forma 内置状态。

实践工作区的价值不在于收集更多资料，而在于让团队可以判断哪些内容已经从一次项目经验变成了可复用的工作方式。没有适用条件、验证依据和失效边界的所谓最佳实践，只是另一种更容易传播的项目笔记。

谁来主持跨项目“蒸馏”

我们把从多个客户项目中提取共同经验的过程称为“蒸馏”。它不是训练或压缩模型，而是从带有客户特征和局部条件的项目事实中保留可迁移的机制、判断路径和验证边界。

这项工作需要有人主持。对我们来说，最合适的是负责跨 FDE 项目协调的角色，也可以由 FDE 负责人、交付负责人或轮值实践维护人承担；他负责发现重复问题和值得比较的成功案例。

主持不等于集中接管资料：来源项目 FDE 仍对项目事实、客户边界和脱敏结果负责，领域负责人审查技术判断。智能体只能在已授权、已脱敏材料内比较差异、寻找缺失证据和起草候选，不能扫描全部客户仓库或替团队决定哪些信息可以跨界。

这个协调角色需要持续做好几件事：

• 从项目复盘、重复问题和组合观察信号中发现候选，邀请参与项目的 FDE 对齐机制、条件、路径和证据。
• 追问哪些步骤是必要条件，哪些只是偶然选择，哪些失败路径和差异必须保留。
• 决定结果应该成为 pattern、工作指引、模板、基础技术架构代码，还是产品改进信号，并指定维护人、成熟度和重新验证条件。
• 收集每次“蒸馏”的反馈，把提问方式、脱敏规则、证据要求和审查标准写回 guideline。

这样，跨项目协调者拥有流程责任，而不是所有客户事实的默认访问权。

“蒸馏”本身也会产生值得沉淀的经验。主持者可以把启动条件、证据卡结构、对照方法、敏感信息边界、产物选择和成熟度规则写成 guideline，明确何时只能生成候选、何时必须停下，以及什么内容必须由人审查。

刚开始时，智能体只应辅助人工主持整理已授权的证据卡、生成对照表和标出缺失信息；协调者负责确认结论，并把接受、退回或撤销的原因反馈到 guideline、schema、template 和检查规则中。

输入结构、判断规则和审查边界稳定后，团队可以让重复问题、项目复盘或组合观察信号触发智能体，在允许访问的脱敏材料中准备证据卡、完成对照、检查敏感信息并在 proposals 中创建候选。跨客户自动化应停在候选阶段，提升为正式 pattern、工作指引、模板或基础代码仍需人工确认。

团队怎样完成一次跨项目“蒸馏”

经验复用不应该从“让智能体搜索所有客户项目”开始，而应先让经验在来源项目中完整走完，再由人和智能体准备审查过的候选。比如受限网络中的接口问题，应先在项目中留下客户事实、communications、issues、decisions、runbooks 和工程验证，再由实践工作区通过 projects、evidence-cards 和 verification 保留可比较的脱敏输入。

当团队后来发现类似问题在其他项目中也出现时，才有必要讨论它是否值得进入实践工作区。真正的“蒸馏”不是把几份项目总结合并起来，也不是寻找出现次数最多的句子，而是把项目并排比较，找出决定结果的共同机制和差异条件。

每个来源项目可以准备一张脱敏证据卡，只回答同一组问题：现象、环境条件、行动、验证证据、失败路径和未确认判断。原始事实仍留在客户项目中，证据卡只提供可比较的输入。

证据卡是团队为“蒸馏”自定义的知识形状，不是 Forma 原生内容类型。当前示例把它放进独立的 evidence-cards content group，并为 projects、communications、verification、reviews、patterns 和 revalidations 分别定义 schema、template 和路由。团队可以为证据卡定义字段，把现象、条件、行动、验证证据、失败尝试、未知项、来源链接和负责人变成固定结构；再用 guideline 规定“只读取已授权的来源”“发现敏感信息时停止”“缺少验证证据时不得提交结论”。这样，协调者收到的是一组结构一致、可以比较和检查的输入。

比较时，我们通常关注这些方面：

这一步最重要的技巧，是寻找不变量，同时保留差异条件。例如，三个项目最后都检查了代理、证书链和认证方式，这还不足以得出“所有接口问题都按这个顺序处理”的结论。团队还需要看清：什么现象触发了这条排查路径，哪些项目因产品版本不同跳过了某一步，又是什么证据排除了产品逻辑问题。

完成对照之后，团队再沿着下面的路径推进：

1. 创建实践提案：在 proposals 中记录候选问题、来源项目、对照结果和仍需审查的风险。
2. 把特例改写成条件：删除客户名称、端点、账号和个人信息，把“客户 A 当时这样处理”改写成“满足哪些条件时，可以先检查什么”。
3. 把结论改写成判断路径：同时写出入口信号、建议顺序、分支条件、停止条件和验证方法，而不是只留下最终答案。
4. 保留反例和未知项：失败尝试、不同结果和暂时无法解释的差异不能为了让结论整齐而被删掉，它们决定了经验的使用边界。
5. 选择合适的产物：稳定的问题识别方式可以形成 pattern，重复执行的步骤可以形成工作指引或模板，经过验证的通用代码可以进入基础技术架构，跨项目重复暴露的缺口则可以成为产品信号。
6. 确定成熟度并重新验证：由负责成员审查脱敏结果、技术边界和复用风险；进入新项目后仍要结合当前环境事实重新验证，再决定提升、维持还是降低成熟度。

例如，实践工作区中的一条模式条目可以写成：

模式条目：受限网络中的出站接口排查

- 适用条件：客户环境限制出站访问，接口调用出现连接或证书相关异常
- 建议顺序：确认代理路径、证书链、认证方式，再判断是否涉及产品逻辑
- 验证来源：已脱敏的多个客户项目条目
- 已知限制：不同网络策略和产品版本需要重新验证
- 成熟度：proven-multi
- 维护人：负责 FDE 实践审查的成员

这条模式没有复制任何一个客户的端点或凭证，却保留了可以帮助下一位工程师开始调查的条件、顺序和限制。智能体可以依据证据卡生成初稿、标出项目之间的共同点和冲突点，也可以检查候选条目是否缺少适用条件或验证依据；最终的抽象是否成立，仍然需要参与项目的 FDE 共同确认。

实践工作区里的经验不会自动变成客户 B 的事实，最多只能成为调查起点；当前环境和正式决定仍以客户 B 的工作区为准。Forma 当前不提供跨工作区共享可变状态，经验复用必须显式说明带入内容、适用理由和审查依据。

可运行示例：双项目对照

仓库提供了一个团队实践工作区示例，把这条蒸馏链做成了一个最小可运行示例。证据卡只引用工作区内的 projects/p-042 和 projects/p-051，并保留环境差异、失败反例和重新验证理由：P-042 是 staging-like asynchronous queue，在加入 replay protection 并使用匹配的窗口后通过验证；P-051 是 production-like burst/retry，直接沿用不完整的生产假设时无法通过，调整窗口并加入 replay protection 后才通过。因此可复用的是“检查环境、窗口、重放行为、运行匹配 profile、再验证”的诊断顺序，不是一个跨项目通用的 120 秒阈值。

要开始体验，先按照仓库中的 Installing Forma 安装已发布的 Forma CLI，并确认命令可用：

forma --version

然后从上面的 GitHub 页面获取示例项目并进入 examples/fde-team-practice-workspace 目录。这个示例是根据我们团队在多客户项目中积累的经验整理出的参考实现，不是可以直接复制的标准模板；请根据自己的授权边界、证据要求、角色分工和成熟度规则调整，或者从零开始搭建一个适合自己的最小实践工作区。

浏览示例时，VS Code 扩展是可选的：可以安装 Forma for VS Code；如果不安装扩展，就在示例目录中运行 forma serve，通过 webapp 浏览和维护工作区。

接着用你熟悉的 Agent 打开示例项目。如果 Agent 尚未安装 forma-cli skill，可以先查看 skills.sh 上的 forma-cli skill 页面，或在示例目录中运行：

npx skills add https://github.com/choral-io/choral-forma --skill forma-cli

安装完成后，让 Agent 先按项目中的分区指引读取工作区，然后发送下面的提示词：

请先读取当前工作区的 Forma 配置、入口条目和分区指引，简短介绍这个团队实践工作区：它如何保存脱敏经验、主要分区分别负责什么、哪些内容仍需人工审查，以及我可以从哪里开始。只读，不修改文件。

复用之前，先问“这是谁的事实”

多项目场景下，智能体最容易犯的错误不是“完全找不到资料”，而是找到了一段看起来相关、实际上属于另一个客户的资料。

因此，团队需要把边界写进工作指引，而不是只依赖每位工程师临场提醒。一个客户项目的工作指引可以要求智能体：

• 先读取当前工作区的客户事实、communications、asks、issues、decisions 和适用的 runbooks，再回答环境或方案问题。
• 不主动扫描其他客户工作区，也不把当前项目的事实写入实践工作区。
• 使用团队实践时，说明它来自哪个已审查条目，并同时列出当前项目仍需验证的条件。
• 发现客户名称、端点、凭证、个人信息或未公开方案时，停止复制并请求人工确认。
• 对“团队通常这样做”和“这个客户已经确认这样做”保持明确区分。

这些规则同时写给人和智能体，帮助双方在项目之间保持同一条判断路径；但工作指引不是权限系统或保密审查的替代品，仓库授权、工具访问范围和敏感信息策略仍需确定性机制与人工责任保证。

多项目真正难的还有注意力

知识隔离解决了“什么内容可以被看到”，却没有自动解决“现在应该先处理什么”。因此，团队可以在外围增加一个轻量的项目组合观察层（portfolio），但它不应成为所有项目的第二真相源，也不应被描述成 Forma 的内置能力。

这个观察层只汇总必要元数据和链接：

这个示例给出了这个观察层的最小结果：portfolio-observation/engagement-syn-001.md 只记录 ENG-SYN-001、projects/p-042 和 projects/p-051、阶段 review、阻塞类别 external-confirmation、健康状态 passed 及维护角色 portfolio-observer。它不复制客户事实或 evidence card 正文；这些仍在项目和证据分区中。这个条目只帮助负责人判断“应该关注哪里”，不会自动创建 proposal、把候选提升为 pattern 或授予访问权。

经验复用不能代替当前判断

已验证的实践不能绕过当前项目调查：同一方案在不同网络、权限和业务目标下可能得出不同结果。因此，工作指引应写成检查条件、尝试条件和停止信号，客户项目的环境事实、工程验证和 decisions 具有更高优先级。proven-multi 只表示团队在多个项目中看到过相似机制，并保留验证范围和限制；环境变化时仍可能降级为 deprecated。

Forma 在多客户协作中的位置

Forma 的位置是划清客户事实、团队实践和项目注意力的边界并组织工程上下文；Git、CI、工单、沟通和项目管理工具继续负责版本、构建、正式请求、协作和通知。权限、凭证、实时聊天、任务推送、跨项目值班和外部系统双向同步仍由外围机制负责，智能体不能替成员确认哪些内容可以共享或发布。

其他团队如何开始

我们自己的实践已经稳定下来，但其他团队不必一次复制完整结构。更实际的起点，是挑选两个问题类型有一定重复的客户项目，分别建立工作区并观察哪些内容值得进入团队实践。

第一步，确保每个项目都有最小结构和检查规则，让模板从真实工作中长出来；第一次记录事实，再次出现时比较差异，结构和步骤稳定后才提炼为实践提案、模板或工作指引。

第二步，写出“蒸馏”规则：启动信号、主持人、来源证据、脱敏要求、比较方法、适用条件、成熟度和撤回条件，并放进实践工作区的 guideline。

第三步，建立只汇总元数据的项目观察表，先看负责人、阻塞、临近事项、最近更新时间和检查结果，不必一开始制作完整看板。

引入时记录从项目状态开始工作的时间、重复排查、上下文错误造成的返工、候选接受或撤回原因及维护成本；这些信号帮助新团队判断扩展、缩小还是调整设计，而不是证明实践普遍有效。

可以从下面这句话开始与智能体协作：

请先检查当前客户项目的 Forma 工作区结构和健康状态，读取分区契约以及与客户项目工作、外部信息索引和敏感信息处理有关的工作指引。然后根据当前项目中的 customers、communications、asks、issues、proposals、decisions、tasks、runbooks、engineering 和 verifications，生成一份只读工作摘要：当前状态、已确认事实、未决事项、环境限制、可参考的团队实践和需要人工确认的风险。不要读取其他客户工作区，不要修改文件。

这条提示词要求智能体围绕当前项目工作，并在使用团队实践时保留来源、适用条件和重新验证要求；团队可据此调整结构定义、模板和工作指引。

多客户交付需要的，不是一个更大的资料库

上一篇文章讨论的是 FDE 如何在客户项目工作环境中工作。本文再向外扩展一步：当项目数量增加，Forma 的价值不在于把所有客户变成一个共享上下文，而在于让隔离、复用和注意力分配各自拥有清楚的边界。

客户工作区让事实留在发生的地方，实践工作区留下经过审查的经验，外围组合机制帮助团队看见注意力缺口。经验不会自动跨客户传播，智能体也不会因看过一个项目而获得另一个项目的授权。

Forma 目前处于公开预览（Public Preview）阶段。对于还没有采用这套方法的 FDE 团队，更合适的起点是先在真实项目中验证单个工作区，再逐步建立实践工作区和组合观察机制，而不是一开始就把它包装成一个完整的多客户管理平台。

想了解 Forma 的产品文档、设计决策和实际工作区，可以从 Forma GitHub 仓库 开始。

相关内容可以继续阅读 《FDE 利器：用 Forma 管理客户项目上下文的全生命周期》、《从 knowledge-workflow 到 Forma：为不同领域定义知识的形状》 和 《从文档到知识资产：让团队在工作中持续积累专业知识》。