bog5d Three Layer Execution Wall
作用
当任务稍微复杂一点时，很多智能体不是不会做，而是做得乱：
- 一上来就调工具，没有先理解任务
- 看到能写就直接写，没有先读、先测、先缩小范围
- 做完只返回一坨日志，没有整理成可交付结果
这个 skill 就是给 Hermes 装三层“墙”，让它先稳住，再出手。
适用场景：
- 多步任务（通常 3 步以上）
- 有副作用风险的任务（写文件、跑命令、发消息、改配置、调用外部系统）
- 需要调研 / 诊断 / 对比 / 总结 / 交付的任务
- 用户表达比较模糊，需要先理解再推进的任务
不适用场景：
- 单一事实问答
- 单次低风险工具调用
- 已经有非常明确输入输出且无需推理的小任务
总原则
每个复杂任务都按下面三层走：
- 任务理解 + 计划框架
- 工具选择 + 风险控制
- 结果交付模板
不要跳层。 如果第一层没做好，第二层会乱。 如果第二层没做好，第三层只会输出一堆噪音。
第一层：任务理解 + 计划框架
第一层目标
先确认：
- 用户到底要什么结果
- 现在已知什么，未知什么
- 这件事属于哪种任务
- 应该先查、先问、先读、还是先干
- 最后要交付成什么形式
先理解，再行动。
必过的 6 个问题
在开始多步任务前，先在心里回答这 6 个问题：
最终交付物是什么？
- 一句话回答：用户最后拿走的成品是什么？
- 例：结论、报告、补丁、脚本、排障结果、清单、消息
成功标准是什么？
- 怎样才算完成，而不是“做了点什么”？
已知 / 未知分别是什么？
- 已知：用户给了什么
- 未知：我还缺什么信息
任务类型是什么？ 先粗分类：
- 研究 / 搜索
- 诊断 / 排障
- 修改 / 执行
- 创作 / 产出
- 复合任务（以上两类及以上）
风险点在哪里？
- 会不会改文件？
- 会不会发消息？
- 会不会执行有副作用命令？
- 会不会造成不可逆影响？
先手动作应该是什么？
- 先读
- 先搜
- 先列计划
- 先做小样本测试
- 先问用户
计划框架
只要任务不是一步完成，就先列一个 3-7 步的高层计划。
计划要求：
- 每步是一个逻辑阶段，不是微观点击步骤
- 顺序必须体现依赖关系
- 最后一步必须是“整理/交付结果”
- 执行中允许调整，但不能完全无计划乱跑
推荐计划骨架
适合大多数复杂任务：
- 确认目标与约束
- 收集必要信息
- 低风险验证 / 抽样
- 正式执行
- 校验结果
- 整理结论与交付
何时必须先问用户
只有以下情况才中断去问：
- 多种方向都合理，且影响很大
- 缺少关键输入，无法继续
- 将进行明显高风险或不可逆动作
- 用户明确要求他来决定
- 商业/金融场景强制触发：涉及多方角色（出资方/实控人/配资机构等）、多层级资金结构（SPV/夹层/优先级等）、交易架构（并购/控制权/融资等）的复杂商业场景——必须先走 3-5 个 clarifying question 确认角色、结构、约束，禁止假设场景、直接出方案。典型信号词：收购、配资、联合体、实控人、出资方、SPV、并购贷款、控制权转让。
除此之外，优先自己做合理默认判断，不要频繁打断。
🚨 特殊任务类型：强制先问再做的场景
以下情况下，必须先向用户确认背景信息再动手，不能靠"合理推断"：
多方交易/结构化方案设计（投融资、并购、合作方案）——用户描述中常混淆角色。必须确认：
- 谁出钱、谁收钱、谁是买方、谁是卖方？
- 资金流向：从哪来、经过谁、到哪去？
- 各角色的身份和约束（如锁定期、监管限制）
- 禁止行为：在角色未确认前就开始写方案。一旦角色理解错了，整个方案无效。
用户表达模糊的复杂任务——用户说"那个XX方案你搜一下"，但你不知道XX是公司名、人名还是方案类型时，先问。
用户给出过错误前提但你发现了——如用户说"他持股25%"，但你搜出来是30%。先应证数据，不要基于错误数据出方案。
为什么这是铁律：今天一次错了，用户要花 10 分钟纠正、你重写方案、双方浪费时间。稳就是快。5 分钟确认角色 = 省 20 分钟返工。
第一层验收
进入第二层前，至少要能说清楚：
- 我现在要解决的核心目标是什么
- 我缺的关键信息是什么
- 我准备按什么顺序做
- 最后要产出什么
如果说不清，就还没准备好行动。
第二层：工具选择 + 风险控制
第二层目标
不是“能不能调工具”，而是：
- 该先调哪个
- 哪个更稳
- 哪个副作用更小
- 出错后怎么切换方法
核心原则：
能读就先读，能测就先测，能小范围就不要先全量，能低风险就不要先高风险。
工具选择总规则
1. 先结构化，后模糊化
如果有专用工具：
- 读文件 →
read_file - 搜内容/找文件 →
search_files - 改文件 →
patch - 新建文件 →
write_file - 多步程序化处理 →
execute_code - 查工具规范 →
/tools/{name}/ skill / schema
不要一上来就用 terminal 做这些本来有专用工具的事情。
2. 先只读，后写入
任何涉及修改的任务，默认顺序应是：
- 先读现状
- 再判断修改范围
- 先小改 / 小样本验证
- 再正式写入
- 最后验证
3. 先小样本，后全量
适用于：
- 批量文件处理
- 批量搜索
- 批量修改
- 大范围命令执行
- 大规模消息发送
先拿 1-3 个样本验证，再扩展。
4. 有 schema 先看 schema
调用陌生工具前，优先：
- 看
/tools - 看
/tools/{name} - 看 skill 文档
不要靠猜参数硬试。
什么时候先读
以下情况必须先读，不要直接写：
- 修改现有文件
- 改配置
- 改代码
- 处理陌生目录
- 用户说“看看现在什么情况”
- 需要做诊断、复盘、对比
默认动作：
read_file/search_files- 查目录结构
- 查相关 schema / skill
- 抽样检查当前状态
什么时候先测
以下情况先做低风险测试：
- 新工具第一次使用
- 新路径 / 新目录 / 新工作区
- 批量操作前
- 高风险写入前
- 不确定命令副作用时
- 外部系统联动前
典型做法：
- 跑只读命令
- 跑最小输入样本
- 用临时文件/测试路径
- 先 dry-run（如果支持）
- 先调 schema / 示例
什么时候不能直接写
默认不能直接写的场景：
- 未读原文件
- 不知道目标文件是否存在
- 不知道覆盖影响范围
- 用户目标还没确认
- 修改会影响多文件、多模块、多用户
- 还没做过一次小样本验证
优先顺序：
- 小改动 →
patch - 明确新文件 →
write_file - 复杂代码改动 →
aider_edit
什么时候该换方法
如果出现以下任一情况，不要死磕原方法：
- 同一种报错重复两次以上
- 参数格式一直不确定
- 工具返回结构和预期不符
- 当前方法成本明显过高
- 已能判断更合适的专用工具存在
换方法优先级：
- 从模糊命令切到专用工具
- 从全量处理切到小样本
- 从直接执行切到先读/先查
- 从手工多步切到
execute_code - 从脆弱文本替换切到
patch/aider_edit
高风险动作前的最终检查
执行下列动作前，必须做一次 10 秒自检：
- 写文件 / 覆盖文件
- 大规模 patch
- 跑可能改系统状态的命令
- 发消息给外部人或频道
- 创建/删除 cron
- 调用未知副作用工具
自检四问：
- 我读过现状了吗？
- 我验证过范围了吗？
- 我知道失败后怎么恢复吗？
- 我真的该现在执行，而不是先问用户吗？
如果其中任一回答是否定的，先停。
⛔ 铁律：给用户的任何东西必须先自测
如果交付物是让用户操作的（链接、界面、指令、按钮），在告诉用户之前必须自己先验证一遍。宁可慢一步验证，不要让用户做小白鼠。
自测检查清单：
- 链接 →
curl -s -o /dev/null -w "%{http_code}" <URL>确认 HTTP 200 - 界面 →
screencapture截屏 +ocr_pro.swift验证页面内容 - API →
curl调一遍确认返回结构和预期一致 - 菜单/按钮 → 截图 OCR 确认文字存在，不要靠 README 猜测
禁止行为：告诉用户"点 XX 按钮"、"打开 XX 页面"、"看到 XX 了吗"——除非你自己已经验证了 XX 确实在那里。
第二层验收
正式执行前，要能说清：
- 为什么选这个工具，不选别的
- 风险在哪里
- 我先做了什么低风险验证（含自测）
- 如果失败，下一步怎么切换
第三层：结果交付模板
第三层目标
不要只返回过程日志。 要把结果整理成用户可直接使用的成果。
最少要回答这 5 件事：
- 做了什么
- 发现了什么
- 结果怎样
- 风险/限制是什么
- 建议下一步是什么
默认交付结构
模板 A：诊断 / 评估类
- 结论先说
- 已验证内容
- 关键发现
- 风险与限制
- 建议下一步
模板 B：执行 / 修改类
- 目标
- 实际动作
- 修改结果
- 验证结果
- 剩余风险
- 下一步建议
模板 C：研究 / 对比类
- 核心结论
- 证据来源 / 依据
- 主要差异点
- 我对结果的判断
- 建议行动
交付质量要求
- 先给结论，不要埋在最后
- 分清“事实 / 推断 / 建议”
- 重要结果要可复核
- 不要用大段原始日志替代总结
- 如果生成了文件，要明确告知文件路径和用途
输出语气要求
- 简洁
- 可执行
- 不自夸
- 不堆术语
- 不重复工具内部日志
第三层验收
交付前问自己：
- 用户现在拿到的是结果，还是只拿到过程？
- 如果用户转发给别人，对方能看懂吗？
- 有没有明确下一步建议？
如果答案是否定的，再整理一次。
快速决策卡
一句话口诀
先理解，后计划；先读先测，再写再放；最后一定要交付成品。
最小执行顺序
- 判定交付物
- 列 3-7 步计划
- 查 schema / 读现状
- 做低风险验证
- 正式执行
- 校验
- 用模板交付
推荐搭配文件
references/test-cases.md— 5 条验证用例（TC-3L-01~05），SkillOpt 验证门控用，满分 10 分，≥7 passreferences/tool-risk-matrix.mdtemplates/final-delivery-templates.mdreferences/preflight-checklist.mdreferences/boss-automation-patterns.md— BOSS直聘/招聘平台自动化实战经验references/a-share-spv-structuring.md— A股控制权收购SPV结构化方案领域知识（出资人/配资/GP waterfall模板）
先读这些文件，再执行会更稳。
何时自动触发
当用户出现下列信号时，优先加载本 skill：
- “帮我看看现状 / 评估一下 / 分析一下”
- “帮我改 / 帮我处理 / 帮我排查”
- “做一个方案 / 报告 / 结论 / 对比”
- 需要多个工具协同
- 任务可能有副作用
最后提醒
工具越多，越需要墙。
这三层墙不是为了变慢，而是为了：
- 少犯错
- 少返工
- 少误解
- 多交付成品
复杂任务里，稳就是快。