04 · 配置、Rules 与自定义命令
基于官方 OpenCode Config、Rules、Commands 教程，面向新手讲清配置、规则和命令各自沉淀什么经验。
OpenCode 的长期价值来自配置系统。一次性提示词只能解决一次问题；配置、rules 和 commands 能把经验固化成项目约定。
先理解：三者分工
配置负责“OpenCode 怎么运行”。比如默认模型、provider、权限、agent、MCP server、主题和项目级设置。
Rules 负责“Agent 在这个项目里应该遵守什么”。比如包管理器、禁止目录、测试命令、代码风格和发布红线。
Commands 负责“把重复任务变成 slash command”。比如 review 当前 diff、解释某个模块、生成 release note、检查迁移风险。
不要混用。运行参数进配置，长期约束进 rules，重复流程进 commands。
怎么判断放全局还是项目
全局配置适合个人偏好，例如默认模型、主题、快捷键。
项目配置适合团队约定，例如默认 agent、MCP server、权限、命令和 rules。只要不包含密钥，项目级配置应该尽量版本化。
密钥不应该进项目配置。provider key、token、账号信息应该走 /connect、环境变量或凭据系统。
Rules 什么时候写
当你反复提醒 OpenCode 同一条规则时，写进 rules。
适合写入的内容包括：项目使用什么包管理器、哪些目录不能改、测试命令是什么、命名和错误处理约定、安全红线、修改前要读哪些文档。
不要把一次性任务写进 rules。rules 越短、越稳定，越容易被模型遵守。
Commands 什么时候写
当你反复执行同一个流程时，写成 command。
比如 review 当前改动、解释模块、生成迁移计划、写发布说明、检查安全风险。
Command 适合把固定检查维度写进去，让每次运行都带同样标准。它比临时 prompt 稳定，也比 rules 更适合流程。
推荐沉淀顺序
先用 TUI 跑几轮真实任务。
把反复出现的注意事项放进 rules。
把反复出现的任务流程放进 commands。
把需要不同权限或角色的任务拆成 agents。
把可复用能力包沉淀成 skills 或 plugins。
OpenCode 的开放配置不是为了把所有东西都配置满，而是为了让真实经验有地方沉淀。
新手常见坑
- 配置里写 API key。
- rules 太长，像项目百科。
- commands 太宽，变成另一个万能 prompt。
- 把一次性任务写进 rules，后面污染所有任务。
- 只写 rules，不配 permissions，误以为安全边界已经生效。
- 改了项目配置但没让团队 review。
怎么验收
你能说清每条长期规则为什么存在。
你能用一个 slash command 稳定完成重复任务。
你能确认项目配置不含密钥。
你能让 OpenCode 在同一任务中自动遵守 rules，而不是每次重新提醒。
你能删除某条 command 或 rule，并知道会影响哪些流程。