# Three Layer Execution Wall

> 为复杂任务建立三层执行墙：先做任务理解与计划，再做工具选择与风险控制，最后输出成品级交付。适用于调研、诊断、代码修改、系统排障、方案撰写、多工具联动等 3 步以上任务。

- Skill: `bog5d/three-layer-execution-wall` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add bog5d/three-layer-execution-wall`
- Raw SKILL.md: https://api.skillmd.com/api/skills/bog5d/three-layer-execution-wall/raw
- Safety review: PASS (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: bog5d (https://skillmd.com/u/bog5d)
- Updated: 2026-08-19
- Page: https://skillmd.com/skills/bog5d/three-layer-execution-wall

---


# Three Layer Execution Wall

## 作用

当任务稍微复杂一点时，很多智能体不是不会做，而是**做得乱**：

- 一上来就调工具，没有先理解任务
- 看到能写就直接写，没有先读、先测、先缩小范围
- 做完只返回一坨日志，没有整理成可交付结果

这个 skill 就是给 Hermes 装三层“墙”，让它先稳住，再出手。

适用场景：

- 多步任务（通常 3 步以上）
- 有副作用风险的任务（写文件、跑命令、发消息、改配置、调用外部系统）
- 需要调研 / 诊断 / 对比 / 总结 / 交付的任务
- 用户表达比较模糊，需要先理解再推进的任务

不适用场景：

- 单一事实问答
- 单次低风险工具调用
- 已经有非常明确输入输出且无需推理的小任务

---

## 总原则

每个复杂任务都按下面三层走：

1. **任务理解 + 计划框架**
2. **工具选择 + 风险控制**
3. **结果交付模板**

不要跳层。
如果第一层没做好，第二层会乱。
如果第二层没做好，第三层只会输出一堆噪音。

---

# 第一层：任务理解 + 计划框架

## 第一层目标

先确认：

- 用户到底要什么结果
- 现在已知什么，未知什么
- 这件事属于哪种任务
- 应该先查、先问、先读、还是先干
- 最后要交付成什么形式

**先理解，再行动。**

## 必过的 6 个问题

在开始多步任务前，先在心里回答这 6 个问题：

1. **最终交付物是什么？**
   - 一句话回答：用户最后拿走的成品是什么？
   - 例：结论、报告、补丁、脚本、排障结果、清单、消息

2. **成功标准是什么？**
   - 怎样才算完成，而不是“做了点什么”？

3. **已知 / 未知分别是什么？**
   - 已知：用户给了什么
   - 未知：我还缺什么信息

4. **任务类型是什么？**
   先粗分类：
   - 研究 / 搜索
   - 诊断 / 排障
   - 修改 / 执行
   - 创作 / 产出
   - 复合任务（以上两类及以上）

5. **风险点在哪里？**
   - 会不会改文件？
   - 会不会发消息？
   - 会不会执行有副作用命令？
   - 会不会造成不可逆影响？

6. **先手动作应该是什么？**
   - 先读
   - 先搜
   - 先列计划
   - 先做小样本测试
   - 先问用户

## 计划框架

只要任务不是一步完成，就先列一个 3-7 步的高层计划。

计划要求：

- 每步是一个逻辑阶段，不是微观点击步骤
- 顺序必须体现依赖关系
- 最后一步必须是“整理/交付结果”
- 执行中允许调整，但不能完全无计划乱跑

### 推荐计划骨架

适合大多数复杂任务：

1. 确认目标与约束
2. 收集必要信息
3. 低风险验证 / 抽样
4. 正式执行
5. 校验结果
6. 整理结论与交付

## 何时必须先问用户

只有以下情况才中断去问：

- 多种方向都合理，且影响很大
- 缺少关键输入，无法继续
- 将进行明显高风险或不可逆动作
- 用户明确要求他来决定
- **商业/金融场景强制触发**：涉及多方角色（出资方/实控人/配资机构等）、多层级资金结构（SPV/夹层/优先级等）、交易架构（并购/控制权/融资等）的复杂商业场景——**必须先走 3-5 个 clarifying question 确认角色、结构、约束**，禁止假设场景、直接出方案。典型信号词：收购、配资、联合体、实控人、出资方、SPV、并购贷款、控制权转让。

除此之外，优先自己做合理默认判断，不要频繁打断。

### 🚨 特殊任务类型：强制先问再做的场景

以下情况下，**必须先向用户确认背景信息再动手**，不能靠"合理推断"：

1. **多方交易/结构化方案设计**（投融资、并购、合作方案）——用户描述中常混淆角色。必须确认：
   - 谁出钱、谁收钱、谁是买方、谁是卖方？
   - 资金流向：从哪来、经过谁、到哪去？
   - 各角色的身份和约束（如锁定期、监管限制）
   - **禁止行为**：在角色未确认前就开始写方案。一旦角色理解错了，整个方案无效。

2. **用户表达模糊**的复杂任务——用户说"那个XX方案你搜一下"，但你不知道XX是公司名、人名还是方案类型时，先问。

3. **用户给出过错误前提但你发现了**——如用户说"他持股25%"，但你搜出来是30%。先应证数据，不要基于错误数据出方案。

**为什么这是铁律**：今天一次错了，用户要花 10 分钟纠正、你重写方案、双方浪费时间。稳就是快。5 分钟确认角色 = 省 20 分钟返工。

## 第一层验收

进入第二层前，至少要能说清楚：

- 我现在要解决的核心目标是什么
- 我缺的关键信息是什么
- 我准备按什么顺序做
- 最后要产出什么

如果说不清，就还没准备好行动。

---

# 第二层：工具选择 + 风险控制

## 第二层目标

不是“能不能调工具”，而是：

- 该先调哪个
- 哪个更稳
- 哪个副作用更小
- 出错后怎么切换方法

核心原则：

> 能读就先读，能测就先测，能小范围就不要先全量，能低风险就不要先高风险。

## 工具选择总规则

### 1. 先结构化，后模糊化

如果有专用工具：

- 读文件 → `read_file`
- 搜内容/找文件 → `search_files`
- 改文件 → `patch`
- 新建文件 → `write_file`
- 多步程序化处理 → `execute_code`
- 查工具规范 → `/tools/{name}` / skill / schema

不要一上来就用 `terminal` 做这些本来有专用工具的事情。

### 2. 先只读，后写入

任何涉及修改的任务，默认顺序应是：

1. 先读现状
2. 再判断修改范围
3. 先小改 / 小样本验证
4. 再正式写入
5. 最后验证

### 3. 先小样本，后全量

适用于：

- 批量文件处理
- 批量搜索
- 批量修改
- 大范围命令执行
- 大规模消息发送

先拿 1-3 个样本验证，再扩展。

### 4. 有 schema 先看 schema

调用陌生工具前，优先：

- 看 `/tools`
- 看 `/tools/{name}`
- 看 skill 文档

不要靠猜参数硬试。

## 什么时候先读

以下情况必须先读，不要直接写：

- 修改现有文件
- 改配置
- 改代码
- 处理陌生目录
- 用户说“看看现在什么情况”
- 需要做诊断、复盘、对比

默认动作：

- `read_file` / `search_files`
- 查目录结构
- 查相关 schema / skill
- 抽样检查当前状态

## 什么时候先测

以下情况先做低风险测试：

- 新工具第一次使用
- 新路径 / 新目录 / 新工作区
- 批量操作前
- 高风险写入前
- 不确定命令副作用时
- 外部系统联动前

典型做法：

- 跑只读命令
- 跑最小输入样本
- 用临时文件/测试路径
- 先 dry-run（如果支持）
- 先调 schema / 示例

## 什么时候不能直接写

默认**不能直接写**的场景：

- 未读原文件
- 不知道目标文件是否存在
- 不知道覆盖影响范围
- 用户目标还没确认
- 修改会影响多文件、多模块、多用户
- 还没做过一次小样本验证

优先顺序：

- 小改动 → `patch`
- 明确新文件 → `write_file`
- 复杂代码改动 → `aider_edit`

## 什么时候该换方法

如果出现以下任一情况，不要死磕原方法：

- 同一种报错重复两次以上
- 参数格式一直不确定
- 工具返回结构和预期不符
- 当前方法成本明显过高
- 已能判断更合适的专用工具存在

换方法优先级：

1. 从模糊命令切到专用工具
2. 从全量处理切到小样本
3. 从直接执行切到先读/先查
4. 从手工多步切到 `execute_code`
5. 从脆弱文本替换切到 `patch` / `aider_edit`

## 高风险动作前的最终检查

执行下列动作前，必须做一次 10 秒自检：

- 写文件 / 覆盖文件
- 大规模 patch
- 跑可能改系统状态的命令
- 发消息给外部人或频道
- 创建/删除 cron
- 调用未知副作用工具

自检四问：

1. 我读过现状了吗？
2. 我验证过范围了吗？
3. 我知道失败后怎么恢复吗？
4. 我真的该现在执行，而不是先问用户吗？

如果其中任一回答是否定的，先停。

## ⛔ 铁律：给用户的任何东西必须先自测

如果交付物是让用户操作的（链接、界面、指令、按钮），在告诉用户之前必须自己先验证一遍。宁可慢一步验证，不要让用户做小白鼠。

**自测检查清单**：
- 链接 → `curl -s -o /dev/null -w "%{http_code}" <URL>` 确认 HTTP 200
- 界面 → `screencapture` 截屏 + `ocr_pro.swift` 验证页面内容
- API → `curl` 调一遍确认返回结构和预期一致
- 菜单/按钮 → 截图 OCR 确认文字存在，不要靠 README 猜测

**禁止行为**：告诉用户"点 XX 按钮"、"打开 XX 页面"、"看到 XX 了吗"——除非你自己已经验证了 XX 确实在那里。

## 第二层验收

正式执行前，要能说清：

- 为什么选这个工具，不选别的
- 风险在哪里
- 我先做了什么低风险验证（含自测）
- 如果失败，下一步怎么切换

---

# 第三层：结果交付模板

## 第三层目标

不要只返回过程日志。
要把结果整理成用户可直接使用的成果。

最少要回答这 5 件事：

1. **做了什么**
2. **发现了什么**
3. **结果怎样**
4. **风险/限制是什么**
5. **建议下一步是什么**

## 默认交付结构

### 模板 A：诊断 / 评估类

1. 结论先说
2. 已验证内容
3. 关键发现
4. 风险与限制
5. 建议下一步

### 模板 B：执行 / 修改类

1. 目标
2. 实际动作
3. 修改结果
4. 验证结果
5. 剩余风险
6. 下一步建议

### 模板 C：研究 / 对比类

1. 核心结论
2. 证据来源 / 依据
3. 主要差异点
4. 我对结果的判断
5. 建议行动

## 交付质量要求

- 先给结论，不要埋在最后
- 分清“事实 / 推断 / 建议”
- 重要结果要可复核
- 不要用大段原始日志替代总结
- 如果生成了文件，要明确告知文件路径和用途

## 输出语气要求

- 简洁
- 可执行
- 不自夸
- 不堆术语
- 不重复工具内部日志

## 第三层验收

交付前问自己：

- 用户现在拿到的是结果，还是只拿到过程？
- 如果用户转发给别人，对方能看懂吗？
- 有没有明确下一步建议？

如果答案是否定的，再整理一次。

---

# 快速决策卡

## 一句话口诀

> 先理解，后计划；先读先测，再写再放；最后一定要交付成品。

## 最小执行顺序

1. 判定交付物
2. 列 3-7 步计划
3. 查 schema / 读现状
4. 做低风险验证
5. 正式执行
6. 校验
7. 用模板交付

---

### 推荐搭配文件

- `references/test-cases.md` — 5 条验证用例（TC-3L-01~05），SkillOpt 验证门控用，满分 10 分，≥7 pass
- `references/tool-risk-matrix.md`
- `templates/final-delivery-templates.md`
- `references/preflight-checklist.md`
- `references/boss-automation-patterns.md` — BOSS直聘/招聘平台自动化实战经验
- `references/a-share-spv-structuring.md` — A股控制权收购SPV结构化方案领域知识（出资人/配资/GP waterfall模板）

先读这些文件，再执行会更稳。

---

# 何时自动触发

当用户出现下列信号时，优先加载本 skill：

- “帮我看看现状 / 评估一下 / 分析一下”
- “帮我改 / 帮我处理 / 帮我排查”
- “做一个方案 / 报告 / 结论 / 对比”
- 需要多个工具协同
- 任务可能有副作用

---

# 最后提醒

工具越多，越需要墙。

这三层墙不是为了变慢，而是为了：

- 少犯错
- 少返工
- 少误解
- 多交付成品

复杂任务里，**稳就是快**。