对话档案 D06 · 自动巡检与自愈体系（10-24~11-02）
一句话：这是一个用 253 个一模一样的对话，硬生生把「看一眼网站死没死」这件事从口头指令逼成五行计划任务的过程——最贵的部分不是 0.99 亿 token，而是每次都在重新加载同一套上下文。
一、这段对话怎么走的
| 阶段 | 用户要求 | 产出 | 卡点 |
|---|---|---|---|
| 10-14 域名哨兵 | 只检测 natapp 域名是否变化，变了发邮件 | natapp/check-domain.mjs，解析 JSON 输出、changed 为真则发信 | 只看域名，站点本身挂了完全无感 |
| 10-15~10-17 双判定 | 网站的「健康状态」和域名变化一起看 | health-check.mjs，输出 siteOk / domainChanged 两个字段 | 起初 siteOk 是看进程在不在，进程活着但端口没响应也算健康 |
| 10-18~10-21 重启脚本化 | 「坏了就自动重启」，且顺序不许乱 | stop.ps1 + 启动脚本 + wait-ready.mjs | 顺序错了就端口冲突，重启完没等待就复检会误判失败 |
| 10-21 架构从一站变三站 | 门户 3000 + 词汇站 3001 + 隧道 | 巡检项从 2 个变 3 个，模板文字随之加长 | 架构一旦变，253 条历史模板全部失效，用户只能改模板再发一遍 |
| 10-24~10-30 高频巡检 | 每 2 小时巡检、每 6 小时重启 | 16 天里几乎每天 12–18 个自动会话 | 任务列表被同一标题刷满，人工任务被淹掉 |
| 10-30 22:49 收口 | 总结经验、写成固定代码、转后台任务、删前台任务 | selfheal.mjs + 5 个计划任务（KaoyanPortal / KaoyanNextServer / KaoyanNotes / KaoyanNatapp / KaoyanSelfHeal）+ 唯一启动器 ops/launch.ps1 | 这套东西后来变成了「双轨并存」的隐患，直到 11-10 才彻底清干净 |
需要说明一处口径：任务标注的时间窗是 10-24~11-02，但实际会话落在 10-14 16:48 至 10-30 22:49 之间，11-01 与 11-02 没有新增自愈会话——那两天大概率是计划任务已经接管、不再经过对话触发。
二、用户的关键原话
原话一（10-14 首条，最早的那颗种子）
「检测 natapp 内网穿透隧道的域名是否发生变化，变化时发送邮件通知用户。执行步骤：1. 用 Bash 运行检测脚本：
cd "C:/Users/cag/WorkBuddy/2026-10-11-06-00-16/kaoyan-vocab/natapp" && node check-domain.mjs（node 用系统 node，路径C:\Program Files\nodejs\node.exe或 PATH 中的 node）。2. 解析脚本输出的 JSON：若cha…」
点评：这条指令的质量在今天看依然很高——它不描述「意图」，而是把可执行路径、解释器选择、输出协议全部写死。代价是它把一个本该由调度器承担的职责，交给了「人每次手动发一遍」。
原话二（10-30 的成熟版模板）
「检测考研学习导航门户（3000）、词汇站（3001）和 natapp 隧道的健康状态，坏了就自动重启，域名变了就发邮件通知。（2026-10-21 门户架构：3000=门户 portal/server.js（nat…」」
点评：一句话里塞进了三件事、三个端口、一份架构注脚。用户已经意识到 AI 会记错环境，所以开始把架构文档嵌进指令里——这正是上下文膨胀的直接来源：为了保证单次正确，不得不在每条消息里重复整个世界的状态。
原话三（重启模板，共出现 50 次）
「重启考研词汇网站的服务器和 natapp 隧道。按以下顺序严格执行：1. 停止旧进程…… 2. 启动网站服务器……」
点评：「按以下顺序严格执行」出现 50 次。这句话本身是用户对 AI 跳步的防御性反应，但它也说明：顺序约束应该被固化进脚本，而不是固化进措辞。
原话四（10-30 22:49，整套体系的转折点）
「现在任务列表有很多网站自愈检测与恢复的任务。总结经验，写成固定代码，然后转成后台任务。最后，将这些前台任务，删除，否则会影响正常任务的回顾和查看。」
点评：这是全篇最有价值的一句。用户不是被 AI 说服的，而是被自己的任务列表逼出来的——他看见刷屏，立刻判断「这套机制放错了层」。这条消息单独花了 559 万 token，但它是这 0.99 亿里唯一把钱变成资产的一笔。
三、成本与效率
| 指标 | 数值 | 折算 |
|---|---|---|
| 会话数 | 253 | — |
| 总 token | 99,139,000（0.99 亿） | 单会话均 391,854，约 39 万 |
| 用户消息 | 207 条 | 单条均 478,932，约 48 万；平均每会话 0.82 条，即多数会话只有 1 条 |
| 工具调用 | 1,402 次 | 单会话均 5.54 次，单条消息均 6.77 次 |
| 折算单价 | 约 39 万 token / 次巡检 | 每次换来的结论通常是「三项目全绿」四个字 |
把这组数字摊开看，问题非常清楚：207 条消息里有 200 条左右是「发一条、看结果、关掉」。它们没有任何推理需求，只需要执行；但每一次都从零加载一份完整架构说明、脚本路径、端口表和历史结论。1402 次工具调用里，绝大多数是 curl 加一次 Get-NetTCPConnection——这种活本该由 schtasks 在 session 0 里做，成本接近零。
按天看更刺眼：10-19 单日 16 个会话烧掉 900 万 token，10-20 又是 16 个会话 900 万。这意味着在体系「已经能用」的那一周，每天仍有一千万 token 花在重复确认「还活着」上。
四、曲折点与评判
1. 判活标准错了三轮（★★）
第一版看域名，第二版看进程，第三版才改成端到端：端口 HTTP 200 + natapp 日志 status=online + 公网 http 200 三条同时成立。前两版都属于「指标选错」，而错误的指标比没有指标更糟——它会给出绿色的假信号，让真正的故障拖到用户手动发现。
2. 模板复用被误当成自动化（★★）
253 个会话的模板文字高度一致，看起来像「已经自动化了」。但模板复用只省了用户打字的时间，一点没省 AI 的上下文。真正的自动化是 selfheal.mjs 里那段 30 分钟循环，它跑起来之后不再产生任何会话——这才是成本归零。
3. 双轨并存，用户自己发现并要求收口（★★★★）
前台 2 小时巡检和后台计划任务并行跑了两周，两套逻辑会互相打架：前台刚重启完，后台的 30 分钟巡检又杀一次。用户在 10-30 明确要求「删除前台任务，否则会影响正常任务的回顾和查看」。这一判断是对的，而且是他自己下的——AI 在整整两周里没有主动提过一次这件事。
五、提示词与流程改进
改进一：把「每次都贴的模板」换成一次调用
反例（重复 200 次）：
检测门户（3000）、词汇站（3001）和 natapp 隧道的健康状态，坏了就自动重启……（后附 600 字架构与脚本路径）
正例（一次）：
用
kaoyan-site-healthskill 跑一次完整体检，只回一行结论：portal/vocab/tunnel = OK|FAIL。FAIL 时再展开。
改进二：把「坏了」翻译成阈值
反例：
坏了就自动重启，域名变了就发邮件通知
正例：
连续 2 次探测（间隔 60s）非 200 才算坏；重启后 90s 内必须恢复 200，否则升级为人工告警。域名与上次记录不同则写
outbox/，不要直接发信。
「坏了」不可判定，AI 只能自己定义，于是每次定义都可能不一样。
改进三：调度交给系统，AI 只做异常诊断
反例：用对话当调度器，2 小时唤醒一次 AI。
正例：计划任务跑 selfheal.mjs；只有它连续失败 3 次，才唤起一个会话做根因分析。
六、可复用结论
- 定式任务一旦写成脚本，就必须断掉对话触发这条路，否则自动化只是把成本从「人」搬到「token」。
- 判活要判端到端链路（端口 + 隧道 + 公网），判进程等于没判。
- 自动化的边际成本不会随时间下降，除非每次的上下文也一起变小——0.99 亿 token 就是没做这件事的账单。