第一轮配置优先级
第一轮配置只看四类：模型与认证、工作区路径、网关访问边界、首个通道所需最小字段。除此之外的大多数字段都可以晚一点再处理。
1. 模型与认证
如果模型访问条件都不成立，后面的运行行为没有讨论价值。
先确认：
- 你已经知道当前准备用哪个 provider 或模型；
- 认证信息已经准备好，而不是边填边猜；
- 至少有一条最小请求链路能跑通。
如果你现在连模型认证都还不稳，不要先去研究 cron、hooks、群组策略或第二个平台。
2. 工作区与目录
工作区路径、可写目录和运行上下文会直接影响状态、日志和后续恢复能力。
这一层至少要回答清楚：
- 文件到底落在哪；
- 当前用户对这些目录是否可写；
- 以后排查时你会去哪里看状态、日志和会话痕迹。
3. 网关访问与认证
这一层决定谁能访问、如何访问，以及你后面做排查时能不能稳定看到状态。
结合 docs 里的配置原则，第一轮重点不是把所有 gateway.* 字段都学完，而是先搞清楚：
- 当前实例是本地访问，还是已经准备远程访问；
- 是否已经设置合理的认证边界；
- 是否知道改完后该用什么命令确认状态。
如果你还在本机上调通第一轮链路，就不要过早把访问面放大。
4. 首个通道的最低必需项
只在你已经准备接平台时处理，而且只填必需项，不要一开始就把全部策略都打开。
例如第一次接 Telegram、Discord 或飞书时，先保留：
- 平台侧最小凭据；
- OpenClaw 侧最小必需字段；
- 一条最小可验证链路。
不要把白名单、复杂群组策略、多账号路由和第二个平台一起塞进首轮配置。
现在不用优先处理什么
这些内容通常不是第一轮配置的主入口：
- 第二个平台的接入字段；
- 高级路由、白名单和复杂群组策略；
- 还没有真实需求的扩展能力；
- 只在 docs reference 里才会用到的细粒度字段。
很多人第一次配置越改越乱，不是因为不会配，而是把“以后可能会用到的能力”提前成了“现在必须处理的配置”。
一个够用的配置顺序
如果你现在只想按最短路径推进，顺序可以固定成：
- 模型与认证；
- 工作区与目录；
- 网关访问与认证；
- 首个通道最小字段；
- 改完立刻做最小验证。
这个顺序的价值在于：前一层没站稳，就不要把问题往后一层转嫁。
常见错误或风险
- 一次同时改模型、目录、认证和通道；
- 还没稳定启动，就进入复杂配置；
- 把“我不知道先改哪类”误解成“我要先去看全部 schema”；
- 还没决定第一个平台，就提前铺开多个入口。