AI 编程助手修改了代码，回复“已经修复”，你运行导出功能却发现中文乱码、逗号错列，甚至少了记录。真正缺少的往往是验收证据：完成了哪项检查、运行的是哪份代码、失败时如何处理，都没有说明。
Superpowers 的 verification-before-completion Skill 用来约束这一步：在声称任务完成前，先选择能证明该结论的检查，实际运行并阅读结果。它不是一套自动识别所有缺陷的测试软件，也不会替你定义业务需求。
本文以两行联系人 CSV 导出为练习，讲清安装、调用、验收与交接。下载入口提供已有 Superpowers 源码合集，此 Skill 位于其中的 skills/verification-before-completion；不是另外制作的独立可执行安装器。
一、适合什么工作，不能代替什么
它适合在功能修改、缺陷修复、打包与交付前使用，尤其适合“代理说成功，但没有日志”的情况。核心是把结论与证据对应起来：语法检查只能说明语法，不能证明用户点击下载后拿到了正确文件。
需要先有可判断的任务。例如“导出很好用”太模糊；“两条联系人导出为 UTF-8 CSV，保留中文、逗号与换行，重新读取仍得到两条完整记录”就可以逐项检查。验收条件应在看到输出前确定，避免事后迁就结果。
Skill 不提供真实订单、收益或安全保证。本文仅验证一个本地数据处理例子；网页按钮、身份权限、浏览器下载及服务器流式传输，需要在真实项目里增加检查，不能用这段脚本的通过记录替代整站验收。
二、先核对来源、下载包和版本
官方项目为 obra/superpowers，仓库使用 MIT 许可证，使用与再分发时保留相应许可声明。本文介绍的规则已与固定提交下的官方 Skill 文件核对，具体来源链接见文末。
网站现有下载包展示为 2026-11-07 源码快照，包内包含多个 Skills。本文只使用完成前验证这一项，不把包日期改写成项目正式版本。下载后先解压，阅读根目录 README、LICENSE 和该目录的 SKILL.md，不运行来历不明的附加脚本。
若你通过插件市场在线安装，实际获得的版本可能比离线包更新。记录自己实际安装的版本、来源和日期；不要把在线最新版的新增行为，直接当作旧源码包已有的功能。查不到正式版本时，使用可追溯的提交标识，而不是自己编一个版本号。
三、以 Claude Code 为例完成安装检查
先确保 Claude Code 已正常运行、具备你需要的本地项目读取与命令执行能力。不要把普通聊天网页与可访问项目的开发工具当成同一种运行环境。插件安装也不等于已经为每条命令授予执行权限。
官方 README 列出了 Claude Code 的插件安装方式。在 Claude Code 的交互会话中执行下面的插件命令，普通 PowerShell 并不识别这个斜杠命令：
/plugin install superpowers@claude-plugins-official安装后，在工具的插件管理界面检查 Superpowers 是否启用，再按工具提示开始新会话。若市场中没有该条目，先阅读官方 README 当前的备用市场方式与工具版本要求，不从陌生下载站安装同名包。
Codex 等其他工具有自己的安装机制，不要把 Claude Code 的命令原样复制到所有工具。离线 ZIP 可用于阅读、核对和按工具官方机制配置；仅把目录解压到任意位置，并不能证明 Skill 会被加载。
四、给代理一个边界清楚的验收任务
在一个新练习目录里操作，数据只使用虚构联系人，不接触真实客户文件。下面的任务描述要求代理说明用了什么 Skill，并把实现、测试与交付分开。它是调用示例，不是已完成的模型对话记录。
使用 verification-before-completion 检查 CSV 导出练习。
只在当前练习目录工作，不上传文件、不修改其他项目。
验收条件：中文保持完整；字段内逗号和换行可以还原；
两条数据读回后仍为两条；列名顺序固定；输出为带 BOM 的 UTF-8。
先列出验证命令和每项命令能证明的范围，再运行。
报告退出码、检查结果和未覆盖项，不凭“看起来正常”宣布完成。这里选择带 BOM 是本练习的交付约定，便于某些表格软件识别编码，不是 CSV 的通用强制要求。真实客户若要求无 BOM，需同步修改实现、测试与交接说明，不应只改其中一个地方。
五、用标准库制作一份可以复查的例子
准备 Python 3，在 UTF-8 文件 verify_export.py 中保存下面的自写示例。它使用 Python 标准库，不需要安装第三方包；不会执行下载 ZIP 中的代码。两条记录分别包含逗号和字段内换行，目的是覆盖简单字符串拼接容易出错的情况。
import csv
from pathlib import Path
fields = ["name", "note"]
expected = [
{"name": "小林", "note": "周一联系,先发资料"},
{"name": "小周", "note": "第一行\n第二行"},
]
target = Path("contacts.csv")
with target.open("w", encoding="utf-8-sig", newline="") as f:
writer = csv.DictWriter(f, fieldnames=fields)
writer.writeheader()
writer.writerows(expected)
raw = target.read_bytes()
assert raw.startswith(b"\xef\xbb\xbf"), "缺少约定的 UTF-8 BOM"
with target.open(encoding="utf-8-sig", newline="") as f:
reader = csv.DictReader(f)
assert reader.fieldnames == fields, "列名或顺序不符"
actual = list(reader)
assert len(actual) == 2, "记录数不符"
assert actual == expected, "字段内容未完整还原"
print("PASS: 编码、列名、两条记录及字段内容检查通过")在该文件所在目录运行 py verify_export.py；其他系统使用对应 Python 命令。Python 官方 csv 文档要求使用文件对象时注意 newline=''，由 CSV 模块处理换行；自行拼接逗号和逐行拆分不适合本例。
运行后应生成 contacts.csv，重新读取后的两条字典与原始数据一致。注意：字段内包含换行，所以文件的物理行数不等于数据记录数。用文本编辑器看到多行，并不能据此断定多导出了一条记录。
六、确认检查本身能发现错误
一次通过只能证明这一份输入满足这些断言。为了确认检查有作用，可以复制练习文件，故意把写出编码从 utf-8-sig 改成 utf-8，再次运行。这一份错误副本应在 BOM 检查处失败，退出码非零。
然后恢复编码，再运行原文件；应重新通过。还可以在测试副本中让写出记录只保留第一条，读回记录数检查应失败。这些都是自建练习的故障注入，不要直接破坏真实客户项目或删除交付文件。
本站对文中自写示例做了本地检查，并检查无 BOM、少记录及错误拼接三个错误变体均会失败。这个结果属于示例代码验证，不代表在 Claude Code 中实际运行过一次完整代理任务，也不代表测试了你的电脑和项目。
七、把检查结果写成可交接的完成说明
一份实用记录至少包含任务版本、执行目录、Python 版本、命令、退出码、检查项与输出文件。避免只贴最后一行 PASS，遗漏前面失败的子任务。若脚本未启动成功，报告环境错误，不能继续描述为功能已经验证。
对这个练习，可写成“本地脚本完成编码、表头、记录数和字段内容检查；尚未测试网页下载按钮与目标表格软件”。这让接手的人能理解实际证据，也知道下一步在哪里补验收。
如果需要交付网页导出，还应在相同版本应用中操作按钮，核对实际下载文件，并检查权限、空列表、中文文件名、大文件与异常提示。这些是根据业务新增的验收项，不是 Skill 安装后自动获得的覆盖范围。
八、常见失败怎样定位
第一类是命令不存在。先核对运行环境：插件命令在工具交互会话里执行，Python 命令在练习目录的终端执行，两者不能混放。同一电脑可能存在多个 Python，日志应写明实际使用的解释器版本。
第二类是 Skill 没有明显参与。检查插件是否启用、新会话是否加载，并在请求里明确要求使用该 Skill。代理自称加载也不是安装证据；应结合工具的插件状态与实际输出检查，不只看一句回答。
第三类是测试通过但交付仍有问题。检查测试是不是只覆盖了语法，是否检查了旧文件，是否漏掉用户实际操作路径。最后一次修改以后重新运行相关检查，旧日志无法证明新代码没有引入错误。
第四类是测试失败后“修改断言让它通过”。先确认需求是否确实改变；未改变时，应修复实现，而不是把预期数据改成错误输出。需求变更需要保留原因，重新审阅验收条件，避免把成功标准越改越宽。
九、从一次练习变成团队习惯
给每类任务建立简短的验收清单，记录证据位置和未覆盖项，比每次让代理自由总结更稳定。表格导出、网页布局、API 返回与部署启动的检查方式不同，应选择与结论相匹配的证据。
这个 Skill 的价值在于提醒工作顺序：定义结论、选择验证、执行并阅读结果、再决定能否交付。它减少无依据的完成声明，但不能替代需求审阅、代码审查或真实环境验证。把这些边界写清楚，客户才知道交付已经做到哪一步。
还没有公开评论，欢迎分享你的想法。