Busabase × Goose
Goose 知识库
Goose Recipe 将指令、扩展和参数打包成可复用流程。分享 Recipe 不会分享创建者的完整对话或私人记忆。Busabase 可以保存团队希望跨次运行复用的来源材料和已接受结论。
缺失的一层
流程可复用，结论仍需审核
同一份 Recipe 可以执行很多次，但每次读取的材料、使用的参数和产生的结论都不同。把方法与事实分开，团队才能更新流程，又不覆盖此前的审核决定。
从提议到正式知识
让下一次任务从已接受的知识开始
读取适用的正式记录
先核对来源日期与适用范围，再把与任务有关的正式知识交给 Agent。
带证据提出更新
将新发现整理成字段级改动，附上来源、执行版本和未解决事项，提交 ChangeRequest。
审核具体差异
审核人检查改动与证据，要求修改、批准或拒绝。批准后再由有权限的角色合并。
复用已接受的结论
后续成员与 Agent 读取合并后的状态；主张有变化时提出新修订，保留历史。
值得沉淀的内容
一条客户问题记录，应能脱离原会话独立核查
示例：某客户的导入失败仅发生在特定文件格式下。不要保存一句“导入有问题”，而应保存能被下一位负责人检查的决定包。以下字段是建议设计，不是预装模板。
结论与范围
具体失败条件、受影响客户与版本；没有核实的客户不放进影响范围。
来源与执行版本
文件或工单链接、来源日期、Recipe 修订、参数及本次运行标识。
验证证据
可复现样本、核对结果与未解决问题；不把模型摘要当作原始证据。
决定与有效期
负责人、审核决定、后续行动和复核日期。情况改变时提议修订，不静默覆盖。
选择正确的知识层
Recipe 保存方法，正式记录保存已接受的结论
同一份 Recipe 可以执行很多次，但每次读取的材料、使用的参数和产生的结论都不同。把方法与事实分开，团队才能更新流程，又不覆盖此前的审核决定。
| 知识层 | 最适合保存 | 可信依据 |
|---|---|---|
| Recipe 与扩展配置 | 留在 Goose 的流程文件中，版本化管理指令、参数和所需工具。它解释这次任务怎样运行，不充当当前客户状态。 | Recipe 与扩展配置 |
| 运行材料与输出 | 原始文件留在来源系统，执行记录留在任务历史。正式知识只引用核验所需的文件、日期和片段，不搬运完整对话。 | 运行材料与输出 |
| 团队接受的事实 | 进入 Busabase 的精简记录：明确结论、证据、适用范围、负责人和复核时间。其他 Recipe 复用前仍需检查记录是否适用。 | 审核人检查改动与证据，要求修改、批准或拒绝。批准后再由有权限的角色合并。 |
| Busabase | 示例：某客户的导入失败仅发生在特定文件格式下。不要保存一句“导入有问题”，而应保存能被下一位负责人检查的决定包。以下字段是建议设计，不是预装模板。 | 后续成员与 Agent 读取合并后的状态；主张有变化时提出新修订，保留历史。 |
适用性判断
只提升值得下一次运行继续信任的结果
适合共享审核
适合：多个 Recipe 或成员会复用同一结论；客户问题需要跨周跟踪；事实更新需要明确负责人和证据。方法继续放在 Recipe，Busabase 承接被接受的状态。
用更简单的工具
不适合：一次性整理、纯临时草稿、已由 Git 管理的流程文件，或无人负责审核的输出。Recipe 全量内容和每次运行日志不需要再复制一份。
Goose 知识库 · 常见问题
分享 Recipe 会分享对话历史吗？
不会。官方说明 Recipe 不包含完整对话历史、全局或本地记忆以及个人凭据。
校验 Recipe 就能保证回答正确吗？
不能。校验检查流程结构和配置，不验证一次运行的事实准确性。
Busabase 如何增加审核？
使用合适的凭据连接并验证目标空间，以 changeRequest 权限提交更新提案；审核与合并是独立步骤。
Recipe 更新后，原有结论要全部作废吗？
不必自动作废。检查方法改动是否影响结论与适用范围；对受影响记录提出修订，并保留原来源和审核决定。
怎样避免旧结论被下一次 Recipe 当成当前事实？
为记录标明范围、来源日期和复核时间，在任务指令里要求先查当前来源。过期或有冲突时先提出更新，不沿用旧结论。
从一条经过审核的记录开始
让下一次任务读取有来源、有负责人的知识
先选择一个需要团队复用的结果，定义最小记录与审核人，再通过接入指南验证访问和提议权限。