对话档案 D09 · AI 使用方式的自我评价（11-10）
一句话：三条消息、746 万 token，让 AI 把自己两个月的行为数据翻了个底朝天，得出一份 7.6 分的自评——而这份自评里最关键的那个数字（工具调用与 token 相关 r=0.998），恰好解释了 D06 那 0.99 亿 token 是怎么烧掉的。
一、这段对话怎么走的
| 阶段 | 用户要求 | 产出 | 卡点 |
|---|---|---|---|
| 元认知任务 | 「获取过往任务中我的指令，总结出我是如何利用 ai 的，并加以评价……给出评价/打分和建议」 | 扫描本机全部 266 个会话，去重出 73 条人工指令、12 个主工作会话，算出四类指令模式与三项相关性 | 口径必须先定：含不含自动化巡检会话，差 99M token；报告最终声明「已剔除自动化巡检与后台任务通知」 |
| 报告成型 | 无追加要求，自主完成 | AI使用复盘报告.html（约 16KB）+ 三张 PNG 长图（最大 1.86MB），含四维评分、反例正例对照、7 条改进建议 | headless Edge --print-to-pdf 退出码 0 却不产文件，最终改为 HTML 交付、由用户 Ctrl+P |
| 截图交付 | 「把这个 html 截图出图片的格式」 | 1.86MB 主图 + 3 张分页 PNG | 泄漏的 headless msedge 进程污染环境（历史最多残留 17 个） |
| 白皮书 | 「同样的，总结过往的任务，将本机情况、用户风格、运行环境、失败经验、交互经验总结成白皮书」 | WorkBuddy交接白皮书.md（约 19KB，7 章，25 条失败经验表）+ HTML 版 | Windows / PowerShell 版本差异、被拦的命令、被挡的端口段，全靠历史会话里翻出来 |
这次会话最特别的地方：产出物在四小时后被用户自己引用，成了 D07 的首条指令附件。也就是说，它不只是复盘，它变成了下一轮工作的输入。
二、用户的关键原话
原话一（任务定义，一次说全）
「获取过往任务中我的指令，总结出我是如何利用 ai 的，并加以评价，对我的描述清晰度，任务完成度，以及消耗 token 和表达的关系进行总结，并给出评价/打分和建议。」
点评：一句话点了四个交付项——行为模式、三个评价维度、token 与表达的关系、可执行的建议。这是「元认知提问」这一类指令里质量最高的一条，因为它不是问「我用得好不好」，而是要求把「好不好」拆成可量的几项。它唯一没给的是权重：四个维度各占多少分，是 AI 自己定的。
原话二（最短的一条，只做形式转换）
「把这个 html 截图出图片的格式」
点评：完全没有上下文，全靠在会话里已经建立的指代关系。这类指令在长会话里风险很高——如果中途被摘要压缩过，「这个 html」指向谁就可能丢失。这次没出问题，是因为它紧跟在产物生成之后。
原话三（把复盘升级成资产）
「同样的，总结过往的任务，将本机情况，用户风格，运行环境，失败经验，交互经验总结成白皮书。方便我在新一轮任务中交付白皮书，减少 ai 需要自行探索的各种环境问题和交互效率低下的问题。」
点评：「方便我在新一轮任务中交付」这句是整段的题眼。它明确了白皮书的用途不是给自己看，而是作为给下一个 AI 的输入。正因为有这句，白皮书才采用了「命令铁律速查」「失败经验按代价排序」这种面向执行者而非读者的写法——它读起来像交接文档，不像总结。
三、成本与效率
| 指标 | 数值 | 折算 |
|---|---|---|
| 总 token | 7,468,611 | 输入 7,421,524 / 输出 47,087，输入:输出 ≈ 157:1 |
| 用户消息 | 3 条 | 单条均 2,489,537，约 249 万 |
| 工具调用 | 84 次 | 单条均 28 次；API 请求 80 次 |
| 时长 | 约 22 分钟 | 15:37 至 15:59 |
| 产出 | 16KB HTML 报告 + 3 张 PNG（合计约 3.2MB）+ 19KB 白皮书 | 约 39 万 token / 千字成品 |
157:1 的输入输出比在这一篇里是合理的：任务本身就是「读 266 个会话、写 1 份报告」，读取量天然远大于产出量。84 次工具调用里有相当一部分是 node -e 跑统计脚本——这类调用的上下文成本很高，但每次都能产出硬数字，属于把钱花在计量上。
真正值得对照的是报告自己算出来的账：
| 报告结论 | 数值 | 与本系列的关系 |
|---|---|---|
| 指令长度 ↔ 会话 token | r = 0.19（几乎无关） | 用户多写字几乎免费 |
| 工具调用数 ↔ 会话 token | r = 0.998（强相关） | 成本 = 轮数 × 上下文，正是 D06 的病根 |
| 指令长度 ↔ 追问轮数 | r = 0.71 | 大工程返工多，不是写得长导致 |
| 单次请求平均上下文 | 133K token，98% 命中缓存 | 缓存降单价，但不降体量 |
| 一条指令的平均触发 | 48.7 次工具调用 | 对比 D06 的 6.77 次/消息，自动巡检反而是「轻」的 |
| 单会话最高消耗 | 237M token / 1,810 次工具调用 | 与 D07 的 71M 同属「混装」类 |
四、曲折点与评判
1. 让 AI 评价使用者，且给出了可复核的口径（★★★★★）
这类任务最容易做成拍脑袋的「你很好，继续加油」。这次能站住，靠的是三件事：先声明统计口径（266 个会话、剔除自动化、73 条去重指令）；给出相关系数而不是形容词；每条建议都配了「现在的写法 / 建议写法」对照。评分 7.6 也不算讨喜分数——「表达↔成本效率」只给 5.5，是这份报告里最不留情面的一项，而它恰好指向用户最不愿承认的地方：字写得再多也不省钱，返工才费钱。
2. 三条消息装了两件不同的事（★★）
第二条只是「截图」，属于轻量收尾；第三条却开启了一个全新的大任务（白皮书）。从 token 看，白皮书那段占了相当比重，但它与复盘报告共享同一批原始数据——读一遍 jsonl，出两份产物，这个复用是合理的。真正的问题在交付形态：报告先做 HTML，再要求截图，于是撞上了 headless Edge 不产文件的老坑。如果一开始就说「要能直接看的图片」，路径会短很多。
3. 复盘结论没有被立刻执行（★★★）
报告明确写了「单会话 ≤50 次工具调用、≤150K 上下文，超出就切」，也点名了那个 237M / 1810 次调用的会话。但四小时后开的 D07，依然是一个 563 次工具调用、71M token 的混装会话。诊断是对的，执行力没跟上——这不是 AI 的问题，是「知道」和「做到」之间的常规落差。
五、提示词与流程改进
改进一：给评分维度定权重
反例：
给出评价/打分和建议
正例：
按描述清晰度 30%、任务完成度 30%、成本效率 25%、工程化复用 15% 加权，总分 10 分制。每个维度必须给一条原始指令作为证据，没有证据的维度标「数据不足」。
没有权重，四个维度的分数就无法横向比较，也无法在下一轮复评时对齐。
改进二：先定口径，再跑统计
反例：直接让 AI「总结过往任务」，它得自己决定含不含自动化会话——一进一出就是 99M token 的差别。
正例：
统计范围：2026-10-01 至 11-14，排除标题含「健康状态/重启/natapp」的自动巡检会话，只统计人工指令。先报「总会话数 / 排除数 / 纳入数」三个数字，我确认后再往下算。
改进三：交付形态前置
反例：先做 HTML，再说「截图成图片」。
正例：
直接产出可直接分发的形态（单文件 HTML 或 PNG 长图），不要先做网页再转换。
六、可复用结论
- 让 AI 评价自己，是单位成本回报最高的一类任务——746 万 token 换来一条可长期复用的纪律（成本 = 轮数 × 上下文），它比任何一次具体开发都更值钱。
- 字数是免费的，轮数和上下文才是账单：r=0.19 与 r=0.998 这一对数字，应该贴在每个长会话的开头。
- 复盘要产出可交付资产，而不是可阅读的报告：白皮书后来被 D07 直接当输入用，这才让这次会话的价值翻倍。