主题阅读3：从技能迭代到系统治理——AI 工具真正可用的三层递进

🎯 核心洞察

当 AI 模型本身已经足够强，真正的瓶颈转向系统设计。这三篇文章从三个层次揭示：

• 技能需要自我迭代闭环 — 静态 Prompt 会退化
• 系统需要严苛的治理框架 — 防呆机制 > 道德约束
• 最好的自主系统恰恰是约束最强的 — Autoresearch 范式

问题：提示词半衰期

你之前写好的一个完美 Prompt（比如放在 SKILL.md 里），跑着跑着效果就变差了。这不是玄学，而是因为：

• 底层的模型偷偷更新了
• 用户的输入习惯漂移了
• 业务的上下文代码改了

如果 Agent 的技能只是一堆写死的文本，它就像一个没有版本更新、没有用户反馈通道的 V1.0 软件，注定会被淘汰。

破局点：先搞定"埋点"与"可观测性"

很多人一上来就想让 AI "自动修改自己的代码"，这太扯了。第一步应该是建立观测系统。

就像我们做产品必须看漏斗和转化率一样，Agent 在调用某个技能时，必须把"输入了什么、调了哪个技能、结果是对是错、为什么错"统统记录下来。

只有当"失败"变成了可以追踪的数据日志，而不是单纯的一句"感觉最近 AI 变笨了"，系统才有优化的抓手。

不要迷信全自动，先跑通"半自动闭环"

正确的姿势是：

1. 先收集数据 — 结构化记录每一次失败
2. 人肉复盘（Inspect & Amend） — 定期把失败的 case 捞出来看，手动修改策略或 Prompt
3. 灰度测试 — 改完之后跑一下指标，看看新版本是不是真的比老版本好，不好还能随时回滚（Rollback）

1. 上下文治理：别把"知识库"当"契约"塞给它

上下文的痛点不是"装不下"，而是噪音太大。你给的信息越多，它越找不到重点。

必须区分"契约（Contract）"和"上下文（Context）"：

• 契约（如 CLAUDE.md）— 绝对不能违背的"宪法"，必须极简（控制在 2.5K tokens 以内）
• 上下文 — 按需加载。当它需要写代码时，再去读特定文件；当它处理你的特定卡片时，再去检索那个项目的背景

2. 工具设计的原则：防呆机制（Foolproof）

靠"自然语言约束"的做法是非常脆弱的。给 Agent 的工具必须是"无法用错的（强制性的）"。

3. Prompt 缓存：架构的"第一性原理"

大模型的 API（尤其是 Claude）有上下文缓存机制。如果你的 System Prompt（也就是前缀）保持绝对静态不变，后续调用的成本和延迟会大幅降低。

不要为了图省事，在每次对话开头动态注入今天的日期、或者临时微调一句指令。这会瞬间打爆缓存，让原本便宜快速的系统变得又慢又贵。系统级的 Prompt 必须像磐石一样稳定。

4. 验证闭环：没有验收标准，就不要自动化

这是从"玩具"到"生产力"的分水岭。

如果你让 AI 去处理一批笔记，但你心里并没有一个明确的、可通过代码或 checklist 检查的"成功标准（DoD）"，那你本质上是在"赌博"。一旦出错，由于没有验证拦截，错误就会被写入你的系统，造成二次污染。

核心哲学：最严格限制的系统最自由

Andrej Karpathy 的 Autoresearch 框架完美印证了这一点：让 AI Agent 在夜间无人值守的情况下，自动修改模型训练代码，自己跑实验、看结果、决定是否保留新代码。

三文件法则（严苛约束）

1. prepare.py（数据与评判标准）— 物理锁死。AI 绝对不能修改，防止它为了刷高分去偷偷降低考试难度（防作弊）
2. train.py（执行域）— AI 唯一可以修改的地方（锁定搜索空间）
3. program.md（人类宪法）— 人类用纯文本写的硬约束指南，定义了 AI 实验的方向和边界

三大物理约束

1. 裁判与运动员必须物理隔离 — 如果让 AI 既负责执行，又负责评估，它为了"刷分"一定会去篡改评判标准
2. 时间与资源的物理熔断 — 每次实验强制限制在 5 分钟。放弃理论最优，追求"单位时间内的 ROI"
3. 极低的试错成本 — 指标变好就保留（Git Commit），变差就无脑回滚（Git Revert）。因为失败代价极低且完全可逆，AI 才敢于且能够进行长期自主的试错

1. 技能演化层（监控静默退化）

• Event_Total & Event_Success_Rate — 处理事件总数与业务定义上的成功率
• Skill_Version_ID — 当前节点调用的核心 Prompt 或 SOP 的精确版本追踪
• Failure_Attribution_Tag — 结构化的失败归因（格式损坏 / 逻辑死循环 / 工具调用崩溃）

2. 工程边界层（监控上下文与防呆机制）

• Token_Consumption & Cache_Hit_Rate — Token 消耗量与前缀缓存命中率（命中率骤降意味着上下文噪音正在污染系统）
• Validation_Block_Count — 输出结果被系统的"强校验规则"打回重做的轮数
• Human_Fallback_Count — 触发强制性"求助人工"工具的频次

3. 沙盒约束层（监控预算与系统可逆性）

• Timeout_Terminations — 因触达硬性物理上限而被强制熔断的任务数
• State_Rollback_Count — 因验证失败或运行结果劣化，系统触发回滚到上一个稳定状态的次数
• ROI_Delta — 单位时间或单位算力成本内，核心指标的相对提升率

短期（本周）：Dashboard 数据提取自动化

目标：从 LCM 自动提取任务，追加到 task-log.json

方案：

1. 写一个 Python 脚本 extract-tasks-from-lcm.py
2. 读取 LCM 数据库，按 session 提取任务
3. 用 LLM 判断每个 session 的"任务类型"和"详情"
4. 生成新的 task-log 条目
5. 人工审查 → 确认 → 追加到 task-log.json

评估指标：

• 召回率：提取的任务数 / 实际任务数
• 准确率：正确分类的任务数 / 提取的任务数

中期（本月）：加入失败告警

目标：Cron 任务失败时，自动通知到 Discord

方案：

• 修改 cron 任务的 delivery 配置
• 失败时发送到 #太子接旨 频道
• 包含失败原因、日志链接

长期（下月）：Dashboard 演化为"可观测组件"

目标：Dashboard 不只是"展示数据"，还能"监控自己"

方案：

• 加入"数据质量"指标（多少任务是估算的、多少是精确的）
• 加入"用户行为"追踪（哪些筛选器最常用、哪些任务最受关注）
• 加入"演化历史"展示（v1 → v6 的变化轨迹）

五个关键洞察

1. "拒绝者"比"应声虫"更值钱 — 企业真正需要的是能质询推理、暴露风险、说"不"的制度性 AI（AI 董事、AI 审计、AI 风控）
2. 垂直专用永远胜过通用商品化 — 真正的竞争力来自"流程工程"，把行业 Know-how 编码进系统
3. 技术升级≠组织升级的陷阱 — 给每个员工配 ChatGPT 只是换了工具，真正的价值在于重新定义流程、角色、决策机制
4. 协同是硬需求，不是可选项 — 制度级 AI 必须定义智能体的角色、边界、交互协议，建立"智能体管理"体系
5. 从"节省时间"到"放大收入"是生死线 — 只有能直接驱动收入、命中率、成交额的制度级 AI，才有持久议价权

1. 给 AI 建立"错题本"

在 Obsidian 里建一个专门的 AI_Bugs.md。每次 AI 搞砸了，不要只在对话框里纠正，要把这个错误记录下来，并且提炼成一条规则。每个月花 20 分钟复盘这个错题本，把你提炼的规则统一更新到你的核心 Prompt 里。

2. 真正用好 CLAUDE.md（极简宪法）

在你处理笔记的文件夹下，建一个 CLAUDE.md。里面绝对不要放具体的笔记内容或长篇大论的背景，只写最强硬的底线规则。例如：

3. 设置"安检门"与"隔离区"

• 安检门（强约束） — 在 Prompt 结尾加上强制的"自检"环节："在最终输出卡片之前，你必须先在 <thought> 标签里自我检查：1. 是否包含了人名？2. 字数是否符合要求？检查无误后，再输出最终卡片。"
• 隔离区（防回滚灾难） — 让 AI 永远先把生成的卡片写到一个名为 00_Inbox_Temp 的临时文件夹里。你每天花 5 分钟扫一眼，没问题再拖进正式的 Obsidian 知识库