before-after（前后验证技能Skill）Skill 是什么？

前后验证技能Skill：用实施前后对比证明阶段真正改变了系统

核心能力：为 Loom 计划生成“前后验证对”，通过捕获实施前状态与实施后状态，证明某个阶段确实改变了系统行为。
关键概念：delta-proof（差异证明），用于区分“功能本来就能用”和“我的阶段让它变得可用”。
输出结构：可生成 before_stage、after_stage、truths、wiring、artifacts 等验证信息，覆盖运行时行为、代码集成与文件产物。
适用人群：使用 Loom 或 AI 编程代理的开发者、技术负责人、测试人员与代码评审者。
注意事项：简单文件存在性检查不必强行使用前后验证；Bug 修复场景的“前/后”方向与新增功能相反，需要特别说明。

该技能叫什么？如何一键安装 AI 技能提升开发效率？

该技能中文名为前后验证技能Skill，也常简称为“前后验证”；英文名为 before-after；技能 ID 为 13522。

它解决的核心问题是：最终状态正确，并不等于本阶段导致了变化。 例如测试通过时，你很难区分“功能本来就已经有效”与“我的阶段使其有效”；Bug 修复后，你也很难区分“Bug 本来就已经被修掉”与“我的修复解决了它”。前后验证技能通过捕获实施前为真的事实、实施后应为真的事实，并把两者配对，形成可执行的 delta-proof（差异证明），让阶段验收从“看结果”升级为“看变化”。

一键安装思路

技能详情中没有提供具体的安装命令、下载链接或价格信息，因此安装入口、命令与权限要求应以官方说明为准。通用安装思路如下：

确认安装前提：所在平台支持 AI 技能或技能市场；当前项目具备可执行的开发环境；存在 Loom 计划或阶段配置；技能可使用读取、Grep、Glob、编辑、写入、Bash 等工具。
找到技能入口：在技能市场、技能中心或平台提供的技能管理入口中搜索 before-after、前后验证 或技能 ID 13522。
执行安装：按平台提供的安装按钮或安装命令将技能安装到当前工作区。若平台支持项目级安装，建议安装到需要使用 Loom 计划的项目中。
确认安装生效：在已安装技能列表中确认 before-after 存在；新建对话或任务，输入触发关键词，例如“前后”“delta 证明”“证明变化”“验证 delta”“实施前”“实施后”，观察是否能生成前后验证结构。
做一次小验证：让技能为一个简单阶段生成 before_stage、after_stage、truths 等内容。若输出包含前后状态、验证命令和集成点描述，说明技能已基本生效。

一键安装的价值在于：把“阶段是否真的产生变化”的验证方法固化到 AI 工作流中，减少人工记忆负担，让开发者在新增命令、端点、模块或修复 Bug 时，快速得到可执行的前后证据对。

该技能的主要功能和特点

生成前后验证对：围绕一个 Loom 阶段，分别捕获实施前状态与实施后状态，形成配对证据。
支持 delta-proof 思维：不仅检查最终状态是否有效，还证明状态转换确实发生。
提供显式前后字段：支持 before_stage 与 after_stage，前者在代理开始工作前运行，后者在代理调用 loom stage complete 时运行。
覆盖多种验证方式：truths 验证运行时行为，wiring 证明代码集成点，artifacts 证明文件存在，acceptance 执行构建、测试、lint 等标准检查。
内置常见场景模板：包括新 CLI 命令、新 API 端点、新模块或库、Bug 修复等场景，便于直接参考。
支持触发关键词调用：如“前后”“前后”“delta 证明”“证明变化”“证明新”“验证 delta”“状态转换”“实施前”“实施后”。
与 Loom 计划集成：可在阶段描述中记录 DELTA PROOF，并把验证配置写入计划 YAML。
提供常见陷阱提示：提醒不要测试过宽、不要捕获不足、不要混淆 Bug 修复方向，也不要在简单文件添加场景中过度使用。

和普通测试工具相比，它的差异化在于：普通测试更关注“最终是否正确”，前后验证更关注“本阶段是否造成了变化”。二者不是替代关系，而是互补关系。把 truths、wiring 与 acceptance 结合使用，可以获得更强的阶段证明。

如何使用该技能？

第一步：明确阶段目标

先写清楚这个阶段要改变什么。例如：“新增 GET /api/status 端点，实施前返回 404，实施后返回 200 并包含健康状态。”

第二步：写出前状态与后状态

新增功能通常是“前失败、后成功”；Bug 修复通常是“前成功复现 Bug、后失败不再复现”。例如：

阶段目标：新增 GET /api/status
前状态：curl -sf localhost:8080/api/status 返回 404
后状态：返回 200，JSON 中包含 healthy 字段
工作目录：项目根目录

第三步：调用技能生成验证配置

在支持该技能的对话中直接描述需求，例如：“用前后验证技能为这个阶段生成 delta-proof，包含 before_stage、after_stage、truths、wiring 和 artifacts。”技能会结合阶段描述生成结构化验证建议。

第四步：检查生成结果

重点检查四类内容：

before_stage：实施前应运行的命令与预期退出码；
after_stage：实施后应运行的命令与预期退出码；
truths：运行时可观察的行为验证；
wiring：代码是否在入口、路由或模块中完成注册与集成；
artifacts：关键文件是否创建。

示例输出可参考如下结构：

before_stage:
  - command: "curl -sf localhost:8080/api/status"
    exit_code: 1
    description: "实施前端点返回 404，命令失败"

after_stage:
  - command: "curl -sf localhost:8080/api/status | jq -e '.healthy'"
    exit_code: 0
    description: "实施后端点返回健康状态"

truths:
  - "curl -sf -o /dev/null -w '%{http_code}' localhost:8080/api/status | grep -q 200"

wiring:
  - source: "src/routes/mod.rs"
    pattern: "/api/status"
    description: "状态端点在路由中注册"

artifacts:
  - "src/handlers/status.rs"

第五步：执行并记录结果

在实施前运行前置检查，确认当前状态符合预期；实施完成后运行后置检查与 truths。注意所有验证路径相对于 working_dir 解析。若 working_dir: "loom"，则 src/main.rs 会解析为 loom/src/main.rs。

第六步：结合验收命令

把前后验证与 acceptance 结合，例如 cargo test、cargo clippy -- -D warnings。前后验证证明“变化发生”，验收命令证明“代码质量与回归测试通过”。

同类型竞品对比分析

方案名称	定位	核心功能	安装/使用门槛	适用场景	优势与不足
前后验证技能（before-after）	Loom 计划的 delta-proof 生成器	捕获前/后状态，生成 `before_stage`、`after_stage`、`truths`、`wiring`、`artifacts`	需支持 AI 技能平台与可运行项目；安装入口以官方说明为准	新功能、Bug 修复、行为变化、CLI/API/模块新增	优势：直接证明因果变化、结构清晰；不足：需要设计可观察状态，Bug 场景方向易混淆
传统单元测试/集成测试	代码级自动化验证	断言函数、模块或接口在最终状态下正确	需测试框架与用例设计	回归测试、逻辑正确性验证	优势：成熟稳定、可重复；不足：测试通过不等于本阶段造成变化
端到端测试	用户流程验证	模拟真实操作验证系统整体行为	环境依赖较高，维护成本较高	关键业务流程、跨服务链路	优势：接近用户视角；不足：运行慢、易脆弱，难以证明单个阶段 delta
手工验收/代码审查	人工确认变更	运行命令、阅读代码、记录结论	依赖人员经验，难以标准化	早期探索、复杂变更、补充评审	优势：灵活；不足：主观性强、证据弱、不可自动化

从对比可以看出，前后验证技能并不是替代测试框架，而是补上“变化证明”这一层。对于需要严格阶段验收的 Loom 计划，它的结构化程度和因果证明能力更强；对于简单文件添加或纯格式检查，传统测试与手工检查可能更直接。

该技能的典型应用场景与实际体验情况

场景一：后端工程师新增 API 端点

角色与痛点：后端工程师新增 /api/status 端点，测试通过后仍难以证明该端点不是之前就存在。
使用方式：记录“前：请求返回 404；后：返回 200 且 JSON 包含健康字段”，并补充路由注册的 wiring。
实际体验：这种场景效果直观，前后命令容易观察。需要注意的是，验证时应确保服务已启动、端口固定、环境干净，否则前后状态可能受环境影响。

场景二：CLI 工具开发者新增命令

角色与痛点：工具开发者新增 loom verify 命令，希望证明命令是本阶段注册的，而非已有命令。
使用方式：使用“前：loom verify --help 失败；后：帮助成功并能运行验证逻辑”的前后对。
实际体验：CLI 场景通常比较容易落地，因为帮助命令、退出码和标准输出都便于断言。建议同时检查命令注册位置与实现文件，避免只验证帮助文本。

场景三：维护者修复 Bug

角色与痛点：维护者修复“空计划导致崩溃”的 Bug，但担心 Bug 可能已被其他改动意外修复。
使用方式：创建复现器，记录“前：复现器成功触发问题；后：复现器不再触发问题”，并验证防御代码已加入。
实际体验：Bug 修复场景最容易被误解，因为“复现器成功”代表 Bug 存在，“复现器失败”才代表 Bug 消失。实际使用时应在阶段描述中明确写出这种反转关系，并使用超时命令避免无限循环。

场景四：库作者新增模块

角色与痛点：库作者新增重试模块，编译通过并不代表模块已从入口导出并被业务代码使用。
使用方式：验证导入可用、目标测试通过，并通过 wiring 检查 pub mod retry 与业务模块中的导入关系。
实际体验：模块场景上手难度中等，单靠 cargo check 可能不足，最好结合针对性测试与集成点检查。整体来看，该技能在“行为可观察、集成点明确”的场景中效果最好；对于简单文件存在性检查，应优先使用 artifacts，避免过度设计。

该技能能为用户带来的价值

第一，它提升了阶段验收的可信度。通过前后状态配对，团队可以更清楚地区分“最终可用”与“本阶段使其可用”，减少误判和返工。

第二，它降低了验证设计门槛。技能内置新命令、新端点、新模块、Bug 修复等模板，开发者不需要从零思考“该怎么证明变化”，只需补充阶段目标与可观察状态。

第三，它把验证证据结构化。before_stage、after_stage、truths、wiring、artifacts 等字段让验证结果可读、可审、可复用，便于代码评审和知识沉淀。

第四，它带来可量化的管理抓手。团队可以统计每个阶段是否至少包含一组前后证据、是否覆盖运行时行为与集成点，从而持续提升 delta-proof 覆盖率。

长期来看，前后验证技能帮助团队形成“先定义变化，再实施，再用证据验收”的工作习惯，把 AI 编程从“生成代码”推进到“生成可验证的变更”。

常见问题 FAQ

Q1：前后验证技能怎么安装？
A：可在支持 AI 技能的平台中搜索 before-after、前后验证 或技能 ID 13522，按平台入口安装到当前工作区。具体安装命令、权限与入口以官方说明为准。

Q2：这个技能收费吗？
A：技能详情未提供价格信息，是否收费取决于所在平台或服务方案，请以官方说明为准。

Q3：它和单元测试、集成测试有什么区别？
A：单元测试和集成测试主要验证最终状态是否正确；前后验证额外要求捕获实施前状态，证明本阶段确实造成了变化。两者应结合使用，而不是互相替代。

Q4：哪些人适合使用？
A：适合使用 Loom 计划或 AI 编程代理的开发者、后端工程师、CLI 工具作者、库维护者、测试人员和代码评审者，尤其适合需要严格阶段验收的团队。

Q5：为什么 Bug 修复的前后方向是反的？
A：因为 Bug 修复要证明“问题之前存在、之后消失”。实施前，复现器成功说明 Bug 存在；实施后，复现器失败说明 Bug 不再触发。测试通常也应修复前失败、修复后通过，并通过 wiring 证明防御代码已加入。