用 Goose 管理本地服务时划清改写边界

让 AI 帮忙启动本地服务，最容易踩的坑，是它为了让环境跑通，直接修改工具生成的 Dockerfile。眼前的报错可能消失了，下一次生成配置，修复也跟着消失。

作者给 Goose 和 Flisk 划了一条边界：Goose 负责调用命令，Flisk 负责生成环境，修改入口留在 service.json。这套做法没有复杂技巧，但把脚手架创建、启动授权和健康检查分开了，适合正在让 Agent 接管本地开发流程的程序员参考。

先弄清谁执行命令，谁拥有配置

这里的 Goose 是支持桌面端、CLI 和 MCP 的开源 Agent，不是 Goose 编程语言，也不是 pressly 的数据库迁移 CLI。装错工具，就会遇到 goose configure 不存在的问题。

Flisk 则是本地开发 CLI：用 service.json 描述服务，执行 flisk up 后生成 Docker 和 Tilt 配置，在本机启动服务。原文列出的后端语言标识是 python、go、rust、node，默认组合是 Bun + Hono。Goose 是执行这些命令的助手，不能因此把 goose 当成 --language 的合法值。

作者建议固定两者版本，并用 goose --version、flisk --version 和实际安装的二进制 --help 核对命令。原文没有提供具体工具版本；其中的 1.0.0 是后面 recipe 的版本字段。Flisk 的社区规模较小，旧文档还混用过 flisk 和 tdk，复制命令前确认 PATH 上究竟装了什么，很有必要。

更关键的是文件归属。Flisk 会在 service.json 旁生成普通 Dockerfile，还会在 .autogenerated/ 下生成 Tilt、nginx 或 Traefik 配置，以及一份简短的 AGENTS.md。

生成文件出了问题，应该修改 service.json，再让 Flisk 重新生成。

直接修改任一生成的 Dockerfile，都可能在下一次 flisk up 或配置重新生成时被覆盖。

如何让 Agent 记住哪些文件不能改

作者在仓库根目录放置 .gooseignore，用来排除生成目录和敏感文件：

.autogenerated/
**/.autogenerated/**
.env
.env.*
*.pem

要留意前两行：它们覆盖 .autogenerated/，但没有覆盖 service.json 旁边的普通 Dockerfile。因此，还需要在指令里明确禁止修改 Flisk 生成的任何 Dockerfile。

这份约定写在 .goosehints 中：仅用于本地 Docker + Tilt；通过 flisk resource 创建服务；禁止修改生成目录；不接受 --language goose；修改后执行 flisk doctor，再检查 flisk up 输出的健康地址；生产部署不在任务范围内。

这里其实有两层约束。忽略文件减少 Agent 接触某些文件的机会，提示文件解释应该走哪条路径。前者不能替代后者，两者也都不能替代 diff 审查。

作者明确说，忽略规则只是缓解措施，不是保证。他曾在其他技术栈里看到 Agent 为了修好启动故障而改生成文件，但没有给出 Goose 配合 Flisk 的系统性测试结果。

把创建、检查和启动拆成明确步骤

作者用 YAML recipe 固定操作流程。示例文件是 .goose/recipes/flisk-backend.yaml，version 为 1.0.0，启用 builtin 类型的 developer 扩展。

recipe 要求提供 name、stack、language 三个字符串参数；start 可选，默认值是 "no"。执行顺序也写死：创建后端，运行 flisk doctor；检查失败就停止并输出错误；只有 start 为 yes 才允许运行 flisk up。

语言超出 python、go、rust、node 时，Agent 应停止并说明需要 --type bring-your-own，不能编造一个不存在的提供方。

下面的命令把一次创建任务收敛成几个明确参数：

goose run --recipe .goose/recipes/flisk-backend.yaml --params name=orders-api --params stack=shop --params language=go --params start=no

要注意最后的 start=no：这次调用允许创建和检查，没有授权启动服务。

另一个容易忽略的细节是，Goose 会先把 --params 作为文本替换，再解析 YAML。参数含换行可能破坏文件结构。长任务应传文件路径，例如 context_path=/tmp/task.md，再让 Agent 读取文件内容。

原文给出的理想会话是创建 billing 服务：执行 flisk resource billing --type backend --language python --stack shop --yes，随后执行 flisk doctor，然后停下。用户再运行 flisk up shop，并通过 curl -fsS http://api.shop.localhost/api/billing/health 检查服务。

这里的预期健康路径和实际检查结果要分开看。start=no 时，Agent 没有启动服务，自然也没有证明健康接口已经可用。

CI 则采用另一份 recipe：先 flisk config verify，再 flisk up，最后等待健康地址通过。审查任务应保持仓库只读，不能为了让检查变绿而修改 Tiltfile 或生成配置。

我的判断

这套方案最有价值的部分，是把「改哪里」和「做到哪一步」都写清楚。相比一句「启动服务，修好所有报错」，它保留了可审查的修改入口，也减少了 Agent 顺手扩大任务范围的空间。

不过，它依赖一个前提：service.json 和 Flisk 的生成能力足以表达需求。遇到超出支持范围的服务，应该重新选择接入方式，而不是指望提示词补齐工具能力。

原文没有提供成功率、耗时或与其他方案的对照数据，所以这是一套经验性操作规范，不能据此断言 Goose 比其他 Agent 更可靠。文中的「好会话」也更像验收示例，不能当成完整实测记录。

提示词负责说明边界，权限控制和 diff 审查负责检查边界是否被守住。

尤其在 CI 中，「仓库只读」最好由实际执行权限落实。仅在 recipe 里写一句禁止修改，还不等于技术上无法修改。

能拿来做什么

• 给现有 AI 编程仓库补一份生成文件约定，写明配置源、生成命令和禁止修改的位置；使用 Flisk 时，明确将修改入口指向 service.json。
• 在创建 Node 后端等重复任务中，把名称、技术栈和启动开关做成 recipe 参数，默认 start=no，让创建结果先经过检查。
• 将 flisk doctor 与实际健康检查分开验收：前者通过后，再启动服务并访问输出的健康地址，避免把配置检查通过当成服务可用。
• 在 CI 审查任务中保留 flisk config verify、启动和等待健康接口的流程；失败时输出错误供排查，不让 Agent 靠改生成文件消除失败。