更新： 本文为历史参考而保留。公开的配方食谱提交计划已经结束，我们不再接受新的配方提交。
你已经用了几周、也许几个月的 goose。你有几十次成功的会话，你在里面请求帮助写博客、做代码审查、写文档或做数据分析。每次你都想“我不是已经做过这个了吗？”，但从来没去查。听起来熟悉吗？
我自己有一百多次 goose 会话，以及同样多兆字节的对话数据。我坐在一座潜在自动化的金矿上。一位同事建议了一件聪明的事：“如果 goose 能分析你的会话并自动构建配方呢？”等等，等等，等等！！基于我自己的会话历史创建一个个性化食谱？好，请！让我们构建一个“食谱生成器”配方！
更新： 本文为历史参考而保留。公开的配方食谱提交流程已经结束，我们不再接受新的配方投稿。
还记得你第一次学做饭吗？你大概从炒蛋或吐司这种简单食谱开始。但最终你会想做更复杂的东西，比如有好几道菜的一整顿晚餐。goose 里的子配方就是这样：每份配方可以独立运行，完成一项专门任务，而主配方编排它们如何运行。
让我们一起探索 goose 子配方！你将学会如何编排多个 AI 模型、协调任务，并构建工作流，让你成为 goose 的「主厨」用户。
更新： 本文作为历史记录保留。公开的 Recipe Cookbook 提交计划已经结束，我们不再接受新的配方提交。
还记得人们靠在邻居之间传递手写卡片来分享食谱吗？你信任奶奶的苹果派食谱，因为你认识奶奶。但当陌生人开始在网上分享食谱时会发生什么？你需要有人先试吃。
这正是我们面对 goose 配方时的挑战。我们在构建一本社区食谱，让你可以放心试用其他用户的 goose 配方，并确信它们是安全的。但我们需要一种方法，确保每个配方都可以安全运行。
作为 goose 用户，我们有两种主要方式向 AI 助手提供持久上下文：.goosehints 文件和 Memory 扩展 MCP 服务器。今天，我会分享我的 .goosehints 文件里有什么，为什么其中一些大概应该移到 Memory 扩展，以及你如何做这个选择。
goose 没有手，没有眼睛，也没有空间感，但它能开一辆漫游车！
我看到了 Deemkeen 的一段演示视频，他用 goose 控制一辆 Makeblock mbot2 漫游车，使用「向前/向后开」「蜂鸣」「向左/向右转」这类自然语言命令，由基于 Java 的 MCP 服务器和 MQTT 驱动。
受到启发，也很兴奋想更进一步，我教漫游车旋转、闪烁彩色灯光，并帮我征服世界！
开发团队可以像运动队那样运作。每个成员有自己的角色，一份共享的战术手册帮助协调努力。让我们看看 AI 驱动的「战术」如何构成你的开发团队的起步「战术手册」，帮助处理常见技术任务。你可以配合 goose 使用配方，借助模型上下文协议（MCP）让自己更有生产力。
作为开发者，我们一直在寻找构建更高效、可扩展、智能应用的方法。多年来，RESTful API 一直是我们连接服务的首选。下面是一些你可以把 AI 智能体和 MCP 集成进现有 API 基础设施的方式，让它更聪明、更高效、更容易维护。
