第一章：安装不是胜利，稳定才是胜利
你可以 10 分钟装好环境，但你无法 10 分钟得到稳定系统。稳定来自于可复现配置、明确验证标准和故障可定位能力。
所以 Day 2 的标准不是“跑起来”，而是“可重复跑起来”。你今天做的每个配置记录，都是未来排错时节省出来的时间。
“安装不是终点，首条任务可用才是。”
章节导读
今天你会第一次感受到“系统上线”的真实重量：它不再是 Demo，而是要对结果负责。
今天的关键词是“闭环”：安装成功不算成功，能稳定执行真实任务才算。
你要避免“一次装完所有东西”。先跑通一个最小路径，后续再扩展平台和技能。
⏱ 阅读 + 实操约 45-60 分钟
故事主线
第二章：为什么首条任务要尽量“无聊”
许多人喜欢拿复杂任务验证 AI，结果常常是失败后无法判断是模型问题、工具问题还是提示词问题。更好的策略是先拿“无聊但明确”的任务建立基线。
例如“按优先级总结邮件”这类任务，可评估、可比对、可复查。一旦它稳定，后续再升级到复杂链路会容易很多。
第三章：配置文档是你的保险丝
高手和新手最大的差别不是谁更会配，而是谁更会写文档。你今天写下的 `.env.example`、版本号和启动命令，会在未来某次故障时救你一命。
把“我记得怎么配”换成“团队都能复现”，你的系统才真正有工程属性。
今天的真实场景
很多人 Day 2 会陷入“装好了就很兴奋”，但到了晚上发现助手没有完成任何工作。根因通常是没有任务闭环标准。
你今天的关键动作是：安装完成后立刻用真实任务验证，不做“闲聊验证”。
对话片段
你：请把今天 10 封未读邮件按紧急程度排序，并给我一个 30 秒处理建议。
助手：已按 P0/P1/P2 分类，先处理客户投诉与付款异常，其余合并批量回复。
今天你将完成
- 安装路径选择：本地 / 云端的取舍
- 模型密钥配置与安全处理
- 首条任务的验证标准
核心概念详解
最小可用优先
先做到“可用”，再追求“好看、全面、复杂”。
配置显式化
配置项一定要文档化，便于迁移和排错。
任务验证优先于闲聊
不要用“你好吗”测试，用真实工作任务测试。
知识卡片
最小可用路径
先跑通一条最简单业务流程，再扩展复杂能力。
为什么重要：复杂系统先求“可用”，能显著降低排错成本。
配置显式化
将关键参数、版本、命令写入可共享文档。
为什么重要：防止“只在我机器上可以跑”的隐性风险。
任务验收标准
用可量化条件判定任务是否成功。
为什么重要：避免“感觉还行”的伪成功。
一个典型工作流示例
| 时间 | 动作 | 结果 |
|---|---|---|
| 00:05 | 安装完成 | CLI 可调用且版本正确 |
| 00:15 | 模型连通 | 凭据校验通过，无鉴权错误 |
| 00:25 | 首条任务 | 得到结构化可用结果 |
| 00:40 | 文档沉淀 | 完成 .env.example 与启动说明 |
实操步骤
步骤 1：安装并确认 CLI 可用
以当前官方推荐命令为准，优先使用可追溯来源。
npx openclaw@latest --help完成判定：能看到命令帮助，且无环境依赖报错。
步骤 2：配置模型凭据（本地环境变量）
敏感信息不入库，统一走环境变量。
export OPENAI_API_KEY="<your_key>"完成判定：健康检查不再提示缺失密钥。
步骤 3：发出首条真实任务
直接使用 Day 1 里定义的任务，不要临时换题。
完成判定：输出内容可直接用于工作，不需要大改。
可复制 Prompt 模板
请根据以下输入生成今天晨报：
- 邮件重点：...
- 会议安排：...
- 昨日异常：...
输出为：优先级清单 + 风险提醒 + 下一步动作。今日交付物
- 可运行实例
- 一条通过验证的真实任务日志
- .env.example（脱敏）
常见误区
- 密钥写进仓库
- 一次接入多个平台
- 只测聊天不测任务
验收清单
- ✓CLI 可用
- ✓模型连通
- ✓首任务完成并可复现
FAQ
Q：本地和云端怎么选？
A：先看你对稳定在线的需求。想 24/7 运行优先云端；先试验可先本地。
Q：首任务总是跑偏怎么办？
A：先固定输出格式，再逐步补充约束，不要一次写太多要求。
参考资料
明日预告
Day 3 会让助手“像你团队里的人”，输出风格和决策边界稳定下来。
🐾 旁白：小结：你要追求的是“可交付结果”，不是“能对话”。