FORWARD DEPLOYED ENGINEERING
让 AI 落地交付可见、可验收、可负责
Busabase 是面向 Forward Deployed Engineer（前线部署工程师 / AI 落地工程师）和 AI 实施团队的交付工作台。它把责任人、进行中的工作和真实结果放在同一个地方，让客户在接收交付前，看见并判断实际的数据、文档和应用。
交付不该是黑箱
每一步都要回答：谁负责、做到哪、结果是什么
Agent 说“做完了”，不是验收。只有责任人、范围、当前状态、证据、审核人和最终接受的版本都清楚可见，FDE 交付才真正可信。
01 · 责任明确
先确定负责人和验收标准
在 Agent 开始前，把每条工作流绑定到具体负责人、明确范围和完成定义。
02 · 过程可见
看见进度、阻塞和下一步决策
提议中、待审核、已接受、运营中的工作一目了然，不用从聊天记录和会议里拼进度。
03 · 结果可查
验收真实工作，不听 Agent 自述
直接打开记录、文档、文件、差异、来源和 AirApp；证据始终与结果放在一起。
04 · 交接可追
明确客户最终接受了什么
接受的版本、审核人、历史和运营界面会一直保留，实施团队离场后仍然可用。
一条可视化交付链路
01
定义负责人 + 验收标准
02
执行Agent 工作 + 当前状态
03
检查真实结果 + 证据 + 差异
04
接受审核人 + 决策 + 历史
05
运营数据 + 流程 + 应用
一个工作区，承接所有交付物
Agent 产出不再散落成一堆文件
研究进入 Doc，业务对象和决策进入有类型的记录，原始资料留在 Drive，跑通的方法沉淀成 Skill，专用界面成为 AirApp。它们共享同一份客户上下文和历史。
这样，交接就不再是一份总结文档。客户拿到的是一个能查看、运营、扩展，也能继续连接其他 Agent 的系统。
客户最终留下什么
一层不会随着项目结束而消失的交付系统
| FDE 交付物 | 沉淀位置 | 后续价值 |
|---|---|---|
| 业务事实和运营状态 | Bases | 类型化记录、关系、视图和 API |
| 研究、决策和操作手册 | Docs + Drive | 上下文与原始证据长期相连 |
| Agent 跑通的方法 | Skills | 跨 Agent、跨会话重复执行 |
| 人真正使用的界面 | AirApps | 实时仪表盘、审核台或专用业务工具 |
FDE 团队能看见什么
一张持续更新的项目作战图
- 每项交付物和关键决策由谁负责
- 哪些工作正在提议、阻塞、审核或已接受
- 结果由哪些证据和原始资料支持
- 下一步需要客户做什么决定
客户能够确认什么
一次建立在真实结果上的交接
- 双方同意的范围和验收标准
- 实际的数据、文档、Skill 和应用
- 每次关键变更由谁提交、由谁审核
- 最终进入运营系统的是哪个版本
FDE 团队常问的问题
Busabase 是 AI 部署运行时吗？
不是。Agent 和自动化仍运行在你选择的环境里。Busabase 负责让交付可负责：共享上下文、可见进度、可检查结果、审核、历史，以及最终留给客户的运营界面。
Busabase 如何避免 FDE 交付变成黑箱？
工作会以记录、文档、文件、Skill 和应用呈现。关键变更带有差异、来源、作者、状态、审核人和决策，客户验收的是实际结果，而不是一条进度汇报。
所有 Agent 结果都必须人工审批吗？
不需要。只为有后果的写入设置门槛。草稿和缓存可以保持轻量；客户事实、公开内容、业务决策和下游系统会读取的记录，需要明确验收。
项目交接后会留下什么？
已接受的数据、文档、证据、可复用 Skill、完整历史和 AirApp 都留在工作区。客户可以继续运营，也可以在之后接入其他兼容 Agent。
从黑箱交付到共同事实
让所有人看见谁负责、改了什么、最终接受了什么
从一份真实交付物开始，让它完整走过 Busabase 的交付闭环。