“让我尝试在问题描述中把页面名称放在最前面…”“让我尝试在问题描述中只写页面名称…”“让我尝试在问题描述中把页面名称放在冒号后面…”第34次了。而文档里白纸黑字写得清清楚楚。背景AI统筹员工小飞要派发一个任务。派发前要先写任务MD文件Markdown文档MD不合格派发就会被check_md.py拦截。小飞开始写MD。被拦截。改。又被拦截。再改。11分钟34次迭代。手机聊天记录里全是 cd /vol1/1000/ai-team-collab/app/scri... ✏️ Writing /vol1/1000/workspace/claw-sync/task/D... 已编辑 让我尝试在问题描述中把页面名称放在最前面: ✏️ Writing ... 已编辑 让我尝试在问题描述中只写页面名称:它像一只在迷宫里撞墙的老鼠——每次撞墙就换一个角度再撞。就是不抬头看地图。问题check_md在拦截什么被拦截的原因是MD格式不合格。而格式要求早就写在skill文档里task-dispatch-workflow项目信息 / 问题描述 / 涉及文件 / 修复方案 / 验收标准 / 验证方法——六段齐全涉及文件必须是真实存在的绝对路径- /vol1/1000/...验收标准必须可执行grep/curl命令具体数值不能写功能正常根因分析必须真实root_cause_analyze.py验证后写入禁止待补充这些规则文档里有。小飞没读。它选择的是试错。改措辞 → 再试 → 再改措辞 → 再试。11分钟里它尝试的把页面名称放前面/放后面/放冒号后——全是在错误的维度上打转。根因AI的试错优先倾向LLM大语言模型有一个隐蔽的倾向遇到报错先试错不先读文档。为什么因为对LLM来说试一次的成本极低几秒钟生成一段新MD而读文档的成本看起来高要打开文件、读几十行、理解结构。它天然选择低成本高反馈的路径——撞墙 → 调整 → 再撞。但试错在【规则明确】的场景里是灾难check_md的规则是确定性的六段式/绝对路径/可执行验收试100次也不会撞对——除非先看规则。用户出手一句话点醒凌晨1:31用户发来一条消息“加载派发机制的规范去看啊”小飞这才开始读skill Reading skill dispatch-guide读完立刻写对一次通过。类比不看说明书装家具买了个书架说明书就在箱子里。你嫌麻烦不看直接上手装——装反了拆。再装又反了再拆。折腾一小时浑身是汗家具店都关门了。这时候有人递过来说明书——三分钟装完。34次试错不如3分钟读文档。修复让读文档成为AI的默认动作我们给AI员工加了三条硬约束1. HEARTBEAT.md 开头写明遇到 check_md 拦截 → 第一步是读取 skill 文档的 MD 模板章节 禁止连续修改MD超过2次 2. 派发规范 skill 在 hermes/skills/ 里随产品分发拷贝确保每个AI员工都能读到 3. task-monitor 增加MD修改次数检测——同一任务MD修改超过N次自动提示请加载规范文档以及一个给所有AI系统开发者的建议给你的AI配文档优先铁律——遇到校验失败第一反应是读规则文档而不是再试一次。经验总结AI的试错成本感是扭曲的——它觉得再试一次很便宜所以疯狂试错但规则明确的场景试错是负收益文档要随产品分发到AI能读到的位置——skill拷进hermes/skills/不读是AI的错读不到是你的错校验器要给出为什么——check_md拦截时报缺少验收标准太笼统报验收标准必须是可执行命令第5行才能引导AI改对限制连续试错次数——超过阈值强制去读文档比放任它撞墙有效人一句话的指导胜过AI一百次试错——这也是为什么我们的系统里统筹角色人类可介入始终保留尾声每一个都不是AI不聪明而是系统设计没有给AI一条看得见的正确路径。把规则写进文档、把文档放到AI嘴边、让失败可观测、让默认值不炸——AI系统才真正开始靠谱。