From 3f6ffd5d4dfa8ffdf9e5dd6983bbd1fbd02f1889 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?AI=E4=B8=8D=E6=AD=A2=E8=AF=AD?= <12096460+jnMetaCode@users.noreply.github.com> Date: Sat, 8 Aug 2026 07:03:52 +0800 Subject: [PATCH] =?UTF-8?q?fix(skills):=20=E5=AE=9A=E4=BD=8D=E6=A0=B8?= =?UTF-8?q?=E6=9F=A5=20=E2=80=94=E2=80=94=20=E8=A1=A5=E5=9B=9E=204=20?= =?UTF-8?q?=E5=A4=84=E3=80=8C=E4=B8=8D=E6=98=AF=E5=A2=9E=E9=87=8F=E3=80=8D?= =?UTF-8?q?=E7=9A=84=E5=AF=B9=E4=B8=8A=E6=B8=B8=E5=81=8F=E7=A6=BB?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 按「我们只是翻译上游 + 增加更多工具支持」这个定位做逐层核查，结果发现 4 处偏离**不属于增量，而是缺失或漏同步**。核查方法与结论都记在下面。 ## 核查方法 1. 文件级：上游 skills/ 与我们逐文件比对，分出「仅上游有」「仅我们有」 2. 内容级：14 个翻译 skill 各自比对标题数（排除代码围栏）、表格行数、列表项数 3. 逐个追查每处差异的来源：是声明过的 fork 增量，还是漏译/漏同步 ## 修掉的 4 处 ① antigravity-tools.md 上游有、我们没有 而 installer 里明明支持 Antigravity —— 该工具用户拿不到任何工具映射。 影响是实质的：Antigravity 没有 todo 工具（manage_task 管的是后台进程）， 没这份映射，所有说「创建待办」的 skill 在它上面都会走偏。 已翻译补入，并在 using-superpowers 的平台适配清单里按上游同序列出。 ② finishing-a-development-branch 漏同步 3 个 commit C 块时我的 commit 清单不全，漏了 fbb6dba / bcfe798 / 9dff1a9。其中 9dff1a9 是**行为变更**：上游把菜单从 4 个选项减为 3 个，删掉了「丢弃这份 工作」这一项，丢弃改为只在人类伙伴明确提出时才走的独立小节；基础分支 判定也从盲跑 merge-base 改为「先确认，合并到错分支代价很高」。 我们的文件已把 D 块修复织进旧结构，故照上游当前状态整体重译 —— 上游 main 已含全部 4 个 commit，一次到位。已断言 D 块修复完整保留 （WORKTREE_PATH 仅在步骤 2 计算一次 + 那条显式警告）。 ③ writing-plans 漏译整节 上游有 Task Right-Sizing 与 Bite-Sized Task Granularity 两节，我们只有后者。 缺的那节讲的是任务边界怎么划（能独立承载一轮测试循环、值得一个全新 审查者把关的最小单元），已补译为「任务粒度定界」。 ④ writing-skills 三个问题 - 漏译 H2 整节 Match the Form to the Failure（让形式匹配失败类型）—— 内容是「哪类基线失败该用哪种形式」，含禁令在塑形类问题上会反噬的实测结论 - 漏译 H3 Micro-Test Wording Before Full Scenarios（先做措辞微型测试） - 编号缺陷：两个连续小节都编号为 4（应为 4、5） - 节名仍是过时的「Claude 搜索优化（CSO）」，上游早已改名 Skill Discovery Optimization (SDO)，正文两处引用一并同步 ## 核查后的定位现状 纯增量部分（符合定位）： - 6 个 fork 专属 skill：chinese-* ×4 + mcp-builder + workflow-runner - 3 个 fork 专属 references：copilot / hermes / qoder（我们支持的 harness，上游不支持或已删） - using-superpowers 的「中国特色技能路由」一节 14 个翻译 skill 的标题数现在 13 个与上游精确一致，唯一例外是 using-superpowers（+1，即上面那节声明过的增量）。 ## 仍存在、需维护者决定的一处（本提交未动） executing-plans 有一个 fork 自加的「步骤 3：处理常见异常」（上游只有 3 步， 我们是 4 步），内容是测试失败三分诊断、依赖缺失、指令不清的处理； 另外 Remember 多一条「每个任务单独提交，commit message 引用任务编号」。 这两处是内容层面的自主增补，不在「翻译 + 工具支持」的定位之内。它们本身 有用，但会让每次上游改动该节都要人工调和。留给维护者判断是保留（并在 README 里声明）还是回归上游。 验证：audit.sh 152 pass / 0 warn / 0 fail、verify-release.sh 90 pass / 0 fail --- .../finishing-a-development-branch/SKILL.md | 211 +++++------------- skills/using-superpowers/SKILL.md | 1 + .../references/antigravity-tools.md | 14 ++ skills/writing-plans/SKILL.md | 4 + skills/writing-skills/SKILL.md | 37 ++- 5 files changed, 112 insertions(+), 155 deletions(-) create mode 100644 skills/using-superpowers/references/antigravity-tools.md diff --git a/skills/finishing-a-development-branch/SKILL.md b/skills/finishing-a-development-branch/SKILL.md index 9a056ae..bf665a2 100644 --- a/skills/finishing-a-development-branch/SKILL.md +++ b/skills/finishing-a-development-branch/SKILL.md @@ -1,6 +1,6 @@ --- name: finishing-a-development-branch -description: 当实现完成、所有测试通过、需要决定如何集成工作时使用——通过提供合并、PR 或清理等结构化选项来引导开发工作的收尾 +description: 当实现完成、所有测试通过、需要决定如何集成这份工作时使用 version: "1.0.0" license: MIT metadata: @@ -8,44 +8,29 @@ metadata: tags: [git, workflow] --- -# 完成开发分支 +# 收尾一个开发分支 ## 概述 -通过提供清晰的选项并执行所选工作流来引导开发工作的收尾。 - **核心原则：** 验证测试 → 检测环境 → 展示选项 → 执行选择 → 清理。 -**开始时宣布：** "我正在使用 finishing-a-development-branch 技能来完成这项工作。" +**开始时宣告：** "我正在使用 finishing-a-development-branch 技能来收尾这份工作。" -## 流程 +## 步骤 1：验证测试 -### 步骤 1：验证测试 +运行项目的完整测试套件（`npm test` / `cargo test` / `pytest` / `go test ./...`）。 -**在展示选项之前，验证测试通过：** - -```bash -# 运行项目的测试套件 -npm test / cargo test / pytest / go test ./... -``` - -**如果测试失败：** +**如果测试失败**，报告失败并停下——菜单是在测试全绿之后才出现的： ``` -测试失败（ 个失败）。必须先修复才能继续： +测试失败（ 个）。完成之前必须先修： -[显示失败信息] - -在测试通过之前无法进行合并/PR。 +[展示失败详情] ``` -停止。不要继续到步骤 2。 - **如果测试通过：** 继续步骤 2。 -### 步骤 2：检测环境 - -**在展示选项之前，先确定工作区状态：** +## 步骤 2：检测环境 ```bash GIT_DIR=$(cd "$(git rev-parse --git-dir)" 2>/dev/null && pwd -P) @@ -59,51 +44,44 @@ WORKTREE_PATH=$(git rev-parse --show-toplevel) | 状态 | 菜单 | 清理 | |------|------|------| -| `GIT_DIR == GIT_COMMON`（普通仓库） | 标准 4 个选项 | 无 worktree 可清理 | -| `GIT_DIR != GIT_COMMON`，命名分支 | 标准 4 个选项 | 按来源判断（见步骤 6） | -| `GIT_DIR != GIT_COMMON`，分离 HEAD | 收敛 3 个选项（无合并） | 无清理（由外部管理） | +| `GIT_DIR == GIT_COMMON`（普通仓库） | 标准 3 个选项 | 无 worktree 可清理 | +| `GIT_DIR != GIT_COMMON`，命名分支 | 标准 3 个选项 | 按来源判断（见步骤 6） | +| `GIT_DIR != GIT_COMMON`，分离 HEAD | 收敛为 2 个选项（不含合并） | 由外部管理——原地别动 | -### 步骤 3：确定基础分支 +## 步骤 3：确定基础分支 -```bash -# 尝试常见的基础分支 -git merge-base HEAD main 2>/dev/null || git merge-base HEAD master 2>/dev/null -``` +基础分支就是这份工作从哪儿分出来的那个——通常在计划里、对话里，或者分支的 upstream 里已经写明了。如果还不知道，就问："这个分支是从 <你的最佳猜测> 分出来的，对吗？"**合并之前先确认：合并到错误的基础分支，代价很高。** -或者询问："这个分支是从 main 分出来的——对吗？" +## 步骤 4：展示选项 -### 步骤 4：展示选项 - -**普通仓库和命名分支 worktree —— 准确展示以下 4 个选项：** +**普通仓库和命名分支 worktree——精确展示这 3 个选项：** ``` 实现已完成。你想怎么做？ -1. 在本地合并回 +1. 本地合并回 2. 推送并创建 Pull Request -3. 保持分支现状（我稍后处理） -4. 丢弃这项工作 +3. 保留分支不动（我稍后自己处理） 选哪个？ ``` -**分离 HEAD —— 准确展示以下 3 个选项：** +**分离 HEAD——精确展示这 2 个选项：** ``` -实现已完成。你在分离 HEAD 上（由外部管理的工作区）。 +实现已完成。你当前处于分离 HEAD（由外部管理的工作区）。 1. 作为新分支推送并创建 Pull Request -2. 保持现状（我稍后处理） -3. 丢弃这项工作 +2. 保持原样（我稍后自己处理） 选哪个？ ``` -**不要添加解释** —— 保持选项简洁。 +**照原文展示菜单**——简洁，每个选项都来自上面的列表。**丢弃工作只在你的人类伙伴明确提出时才发生**（见下方"如果你的人类伙伴要求丢弃这份工作"）。等他们回答；集成与否是他们的决定。 -### 步骤 5：执行选择 +## 步骤 5：执行选择 -#### 选项 1：本地合并 +### 选项 1：本地合并 ```bash # 切到主仓库根目录，保证 CWD 安全 @@ -116,164 +94,95 @@ git pull git merge # 在合并结果上验证测试 - - -# 合并成功之后再：清理 worktree（步骤 6），然后删除分支 +<测试命令> ``` -然后：清理 worktree（步骤 6），再删除分支： +如果测试在**合并结果**上失败：停下，把 worktree 和分支原地留着，去排查——什么都还没推送，所以这次合并是本地的、可恢复的。 + +一旦合并结果全绿：清理 worktree（步骤 6），然后删除分支： ```bash git branch -d ``` -#### 选项 2：推送并创建 PR +### 选项 2：推送并创建 PR ```bash -# 推送分支 git push -u origin # 从分离 HEAD 出发时，在远端指定新分支名： # git push origin HEAD:refs/heads/ - -# 创建 PR -gh pr create --title "" --body "$(cat <<'EOF' -## 摘要 -<2-3 条变更要点> - -## 测试计划 -- [ ] <验证步骤> -EOF -)" ``` -**不要清理 worktree** —— 用户在 PR 反馈迭代时还需要它存活。 +然后用**代码托管平台**（forge）的工具针对 <base-branch> 创建 pull/merge request——有 CLI 就用它，没有就用推送时大多数平台会打印出来的创建 URL——遵循仓库里已有的 PR 模板与约定（如果有），并把 URL 报告给你的人类伙伴。 -#### 选项 3：保持现状 +**保留 worktree**——你的人类伙伴要在那里根据 PR 反馈继续迭代。 + +### 选项 3：保持原样 报告："保留分支 <name>。工作树保留在 <path>。" -**不要清理工作树。** +### 如果你的人类伙伴要求丢弃这份工作 -#### 选项 4：丢弃 - -**先确认：** +**这条路只作为对"明确要求把工作扔掉"的响应而存在。** 先确认： ``` 这将永久删除： - 分支 <name> -- 所有提交：<commit-list> -- 工作树 <path> +- 所有 commit：<commit 列表> +- 位于 <path> 的工作树 -输入 'discard' 确认。 +输入 'discard' 以确认。 ``` -等待精确的确认。 - -确认后： +等待**这个精确的**确认词。收到之后： ```bash MAIN_ROOT=$(git -C "$(git rev-parse --git-common-dir)/.." rev-parse --show-toplevel) cd "$MAIN_ROOT" ``` -然后：清理 worktree（步骤 6），再强制删除分支： +然后清理 worktree（步骤 6），再强制删除分支： ```bash git branch -D <feature-branch> ``` -### 步骤 6：清理工作区 +## 步骤 6：清理工作区 -**只对选项 1 和 4 执行。** 选项 2 和 3 始终保留 worktree。两个调用方都已经切到主仓库根目录了 —— 移除 worktree 必须从 worktree 外面执行 —— 因此这里使用**步骤 2 里捕获的** `GIT_DIR` / `GIT_COMMON` / `WORKTREE_PATH`，也就是那次目录切换之前的值。 +**只对选项 1 和已确认的丢弃执行。** 选项 2 和 3 始终保留 worktree。两个调用方都已经切到主仓库根目录了——移除 worktree 必须从 worktree 外面执行——因此这里使用**步骤 2 里捕获的** `GIT_DIR` / `GIT_COMMON` / `WORKTREE_PATH`，也就是那次目录切换之前的值。 > ⚠️ **不要在这里重新计算这些值。** 此刻 `git rev-parse --show-toplevel` 返回的是主仓库根目录，不是 worktree 路径 —— 溯源判断会永远匹配不上，清理会静默空转，随后分支删除还会因为 worktree 仍挂着而失败。 **如果 `GIT_DIR == GIT_COMMON`：** 普通仓库，无 worktree 可清理。结束。 -**如果 `WORKTREE_PATH` 在 `.worktrees/` 或 `worktrees/` 之下：** 这是 Superpowers 创建的 worktree —— 我们负责清理。 +**如果 `WORKTREE_PATH` 在 `.worktrees/` 或 `worktrees/` 之下：** 这是 Superpowers 创建的 worktree——我们负责清理： ```bash git worktree remove "$WORKTREE_PATH" git worktree prune # 自愈：清理任何过期的注册记录 ``` -**否则：** 这个工作区由宿主环境（harness）管理。**不要**移除它。如果你的平台提供了工作区退出工具，用它。否则原样保留工作区。 +**否则：** 这个工作区归宿主环境所有——原地别动。如果你的平台提供了工作区退出工具，用它。 ## 快速参考 | 选项 | 合并 | 推送 | 保留工作树 | 清理分支 | |------|------|------|-----------|---------| -| 1. 本地合并 | ✓ | - | - | ✓ | -| 2. 创建 PR | - | ✓ | ✓ | - | -| 3. 保持现状 | - | - | ✓ | - | -| 4. 丢弃 | - | - | - | ✓（强制） | +| 1. 本地合并 | 是 | - | - | 是 | +| 2. 创建 PR | - | 是 | 是 | - | +| 3. 保持原样 | - | - | 是 | - | +| 丢弃（仅在明确要求时） | - | - | - | 是（强制） | -## 常见错误 +## 常见的合理化借口 -**跳过测试验证** - -- **问题：** 合并损坏的代码、创建失败的 PR -- **修复：** 在提供选项前始终验证测试 - -**开放式问题** - -- **问题：** "接下来该做什么？" → 含糊不清 -- **修复：** 准确展示 4 个结构化选项（分离 HEAD 时是 3 个） - -**为选项 2 清理 worktree** - -- **问题：** 删掉用户 PR 迭代还需要的 worktree -- **修复：** 只在选项 1 和 4 时清理 - -**先删分支再删 worktree** - -- **问题：** `git branch -d` 失败，因为 worktree 还引用着该分支 -- **修复：** 先合并，再删 worktree，最后删分支 - -**在 worktree 内部跑 `git worktree remove`** - -- **问题：** 当 CWD 在被删除的 worktree 内时，命令静默失败 -- **修复：** 跑 `git worktree remove` 前先 `cd` 到主仓库根目录 - -**清理 harness 拥有的 worktree** - -- **问题：** 移除 harness 创建的 worktree 会造成幻影状态 -- **修复：** 只清理 `.worktrees/` 或 `worktrees/` 下的 worktree - -**丢弃时不确认** - -- **问题：** 意外删除工作成果 -- **修复：** 要求输入 'discard' 确认 - -## 红线 - -**绝不：** - -- 在测试失败时继续 -- 合并前不验证合并结果上的测试 -- 不确认就删除工作成果 -- 未经明确请求就强制推送 -- 在确认合并成功之前移除 worktree -- 清理不是你创建的 worktree（按来源判断） -- 在 worktree 内部跑 `git worktree remove` - -**始终：** - -- 在提供选项前验证测试 -- 展示菜单前检测环境 -- 准确展示 4 个选项（分离 HEAD 时是 3 个） -- 选项 4 要求输入确认 -- 只在选项 1 和 4 时清理 worktree -- 移除 worktree 前 `cd` 到主仓库根目录 -- 移除后跑 `git worktree prune` - -## 集成 - -**被以下技能调用：** - -- **subagent-driven-development**（步骤 7）- 所有任务完成后 -- **executing-plans**（步骤 5）- 所有批次完成后 - -**配合使用：** - -- **using-git-worktrees** - 清理由该技能创建的工作树 +| 借口 | 现实 | +|------|------| +| "测试这个会话早先通过过" | 在**你即将集成的那棵树上**跑测试套件。一次绿色运行只能证明它当时跑的那棵树。 | +| "他们显然是想合并的" | 集成是你人类伙伴的决定。把菜单摆出来，然后等。 | +| "他们看起来对这个功能收工了——我提议丢弃吧" | 菜单就是原文那样，不多不少。丢弃只在你的人类伙伴用明确的话提出时才发生。 | +| "'嗯，删掉吧'算确认了" | 只有输入 `discard` 这个词才授权删除。 | +| "PR 已经开了，worktree 现在是碍事的垃圾" | PR 反馈要在那个 worktree 里修。它得留到工作落地为止。 | +| "另外那个 worktree 看着像过期的——我顺手也清了" | 只清理 `.worktrees/` 或 `worktrees/` 之下的 worktree。其余的都属于宿主环境。 | +| "合并结果的失败大概是偶发的" | 合并结果失败会让一切停下。在你排查期间，分支和 worktree 原地不动。 | +| "基础分支明显就是 main" | 确认分叉点，或者直接问。合并到错误的基础分支，代价很高。 | +| "推送被拒了——force-push 一下就好" | 推送被拒意味着远端动过了。去排查；只有在你人类伙伴明确要求时才 force-push。 | diff --git a/skills/using-superpowers/SKILL.md b/skills/using-superpowers/SKILL.md index 9b4def3..a9cdd44 100644 --- a/skills/using-superpowers/SKILL.md +++ b/skills/using-superpowers/SKILL.md @@ -60,6 +60,7 @@ metadata: - Codex：`references/codex-tools.md` - Pi：`references/pi-tools.md` +- Antigravity：`references/antigravity-tools.md` - Copilot CLI：`references/copilot-tools.md` - Hermes Agent：`references/hermes-tools.md` - Qoder：`references/qoder-tools.md` diff --git a/skills/using-superpowers/references/antigravity-tools.md b/skills/using-superpowers/references/antigravity-tools.md new file mode 100644 index 0000000..952e3e8 --- /dev/null +++ b/skills/using-superpowers/references/antigravity-tools.md @@ -0,0 +1,14 @@ +# Antigravity CLI（`agy`）工具映射 + +Skills 说的是动作（"分派一个子智能体"、"建一条待办"、"读一个文件"）。在 Antigravity CLI（`agy`）上，这些动作对应下面这些工具。 + +| Skill 请求的动作 | Antigravity CLI 等价工具 | +|----------------|----------------------| +| 分派子智能体（`Subagent (general-purpose):` 模板） | `invoke_subagent`，配一个内置的 `TypeName` —— 全能力工作用 `self`，只读调研用 `research` | +| 任务跟踪（"建一条待办"、"标记完成"） | 一个 **task artifact** —— 用 `write_to_file` 并带上 `IsArtifact: true` 与 `ArtifactType: "task"`（见下方[任务跟踪](#任务跟踪)）。**不是** `manage_task`，那个是管后台进程的。 | + +## 任务跟踪 + +Antigravity **没有 todo 工具**（`manage_task` 管的是后台进程 —— `list`／`kill`／`status`／`send_input` —— 它**不是**清单工具）。当某个 skill 说要创建待办清单或跟踪任务时，改为维护一个 **task artifact**：一份用 `write_to_file` 保存的 markdown 清单（`IsArtifact: true`、`ArtifactMetadata.ArtifactType: "task"`），过程中用 `replace_file_content` ／ `multi_replace_file_content` 来编辑。 + +任何多步任务一开始，就创建这个 task artifact，把你计划里的每一步都列上。每完成一步，就编辑该 artifact 把它标记为完成（`- [x]`）。计划有变就更新清单。**保持它是最新的** —— 它是"还剩什么没做"的唯一事实来源；一旦对话变长，每开始一步之前先重读它。 diff --git a/skills/writing-plans/SKILL.md b/skills/writing-plans/SKILL.md index ec722fc..704209a 100644 --- a/skills/writing-plans/SKILL.md +++ b/skills/writing-plans/SKILL.md @@ -38,6 +38,10 @@ metadata: 此结构决定了任务分解。每个任务应产出独立的、有意义的变更。 +## 任务粒度定界 + +一个任务是**能独立承载自己那一轮测试循环、且值得一个全新审查者把关**的最小单元。划任务边界时：把搭建、配置、脚手架和文档这些步骤，折进那个真正需要它们的交付物所在的任务里；只在「审查者有可能否掉这个任务、同时批准它旁边那个」的地方才拆开。每个任务都以一个**可独立测试的交付物**结束。 + ## 小步骤任务粒度 **每步是一个操作（2-5 分钟）：** diff --git a/skills/writing-skills/SKILL.md b/skills/writing-skills/SKILL.md index a9838ae..0516a1c 100644 --- a/skills/writing-skills/SKILL.md +++ b/skills/writing-skills/SKILL.md @@ -103,7 +103,7 @@ skills/ - `description`：第三人称，仅描述何时使用（不是做什么） - 以"Use when..."开头，聚焦于触发条件 - 包含具体的症状、场景和上下文 - - **绝不总结技能的流程或工作流**（参见 CSO 章节了解原因） + - **绝不总结技能的流程或工作流**（参见 SDO 章节了解原因） - 尽量控制在 500 字符以内 ```markdown @@ -141,7 +141,7 @@ description: Use when [具体的触发条件和症状] ``` -## Claude 搜索优化（CSO） +## 技能发现优化（SDO） **发现至关重要：** 未来的 Claude 需要找到你的技能 @@ -279,7 +279,7 @@ wc -w skills/path/SKILL.md - `creating-skills`、`testing-skills`、`debugging-with-logs` - 主动的，描述你正在进行的操作 -### 4. 交叉引用其他技能 +### 5. 交叉引用其他技能 **编写引用其他技能的文档时：** @@ -460,6 +460,23 @@ pptx/ **以上所有都意味着：部署前测试。无例外。** +## 让形式匹配失败类型 + +在写指导内容之前，先给基线失败**归类**。能让某一类失败变得无懈可击的形式，用在另一类上会**可测量地反噬**。 + +| 基线失败 | 正确的形式 | 错误的形式 | +|---|---|---| +| 压力之下跳过/违反规则（明知故犯） | 禁令 + 合理化借口表 + 红线（见下方"让技能经受住合理化的考验"） | 软性建议（"优先……"、"考虑……"） | +| 遵守了，但产出的**形状**不对（提示词臃肿、结论被埋、复述规格） | 正面配方或契约：直接说明产出**是什么** —— 它由哪些部分组成、按什么顺序 | 禁令清单（"不要复述"、"绝不旁白"） | +| 在他们**本来就会产出**的东西里漏掉了必需元素 | 结构性手段：在他们要填的模板里放一个 REQUIRED 字段或占位槽 | 在模板附近写散文式提醒 | +| 行为**应当取决于某个条件** | 挂在可观察谓词上的条件句（"如果简报存在，就引用它"） | 无条件规则 + 一堆例外条款 | + +**为什么禁令在"塑形"类问题上会反噬：** 在存在竞争性激励时（比如"让提示词自包含"），智能体会**跟"不要 X"讨价还价**。在针对分派提示词指导做的同题措辞对照测试里，禁令组产出的不想要的内容明显**多于**配方组（两组分布完全分离），甚至比"完全不给指导"的对照组还差 —— 请对你自己的场景做微型测试，别想当然，但**永远不要把禁令当默认选择**。配方留不下可讨价还价的空间：产出要么符合所说的形状，要么不符合。 + +**无论你选哪种形式，都适用的规则：** +- **不要加"视情况"从句。** "不要 X，除非它很重要"会重新打开谈判 —— 在同一批措辞测试里，给一个胜出的配方追加**一条**"视情况"从句，就把它从稳定退化成了飘忽。真正的例外要表达成**它自己的**条件句，挂在可观察的谓词上。 +- **豁免条款不会限定作用域。** "这条长度限制不适用于代码块"，照样会压制代码块。如果产出里有一部分必须豁免，就**重构结构让规则碰不到它**，而不是写豁免。 + ## 让技能经受住合理化的考验 执行纪律的技能（如 TDD）需要抵抗合理化。智能体很聪明，在压力下会找到漏洞。 @@ -526,7 +543,7 @@ pptx/ **以上所有都意味着：删除代码。用 TDD 重新开始。** ``` -### 更新 CSO 以包含违规症状 +### 更新 SDO 以包含违规症状 在描述中添加：你即将违反规则时的症状： @@ -557,6 +574,18 @@ description: use when implementing any feature or bugfix, before writing impleme 智能体找到了新的合理化借口？添加明确的反驳。重新测试直到无懈可击。 +### 先做措辞微型测试，再跑完整场景 + +完整的压力场景是最后一道关卡，但它每轮迭代都又慢又贵。先用**微型测试**验证措辞本身： + +1. **每次调用一个全新上下文的样本** —— 一次裸 API 调用，或者没有 API 权限时用一个单发子智能体。system prompt 放**这条指导实际会存在的真实上下文**（完整的 skill 或提示词模板，不是把指导单独拎出来）；user message 放一个会**诱发该失败**的任务。 +2. **永远带一个"不给指导"的对照组。** 如果对照组根本没表现出那个失败，那就没什么可修的 —— 停下，别写这条指导。 +3. **每个变体至少 5 次重复。** 单个样本会骗人。 +4. **每一条被标记的命中都要人工读一遍。** 想用程序打分可以，但模板回声和被引用的反例会**伪装成命中**；只看自动计数会同时高估失败和成功。 +5. **方差本身就是一个指标。** 指导真正生效时，多次重复会收敛到同一种形状。5 次重复出现 5 种不同解读，说明这个措辞**没有约束力** —— 先收紧形式，别急着加字。 + +微型测试验证的是**措辞**；对纪律执行类技能，它**不能替代**压力场景。 + **测试方法论：** 参见 @testing-skills-with-subagents.md 了解完整的测试方法： - 如何编写压力场景 - 压力类型（时间、沉没成本、权威、疲惫）