审查意见看起来专业，并不等于每一条都适合当前项目。有的指出真实缺陷，有的会破坏业务约定，还有的只说“优化排序”，却没有说明按什么规则排序。让AI一口气全部修改，往往会把正确的行为也改掉。

知行之外 · mywwx.com

Receiving Code Review是Superpowers中的一项Skill，重点是先理解反馈、对照代码与需求核实，再逐项处理。本篇围绕一个物料编号规范化函数，完成“接受正确意见、拒绝错误建议、澄清模糊要求”的练习，最后得到可执行测试和审查决策记录。

这是一项开发工作方法，不是自动保证代码正确的检测器。下文示例与测试为本站编写并在本地运行；助手按Skill思路组织工作的对话是建议模板，不冒充已在你的Claude Code环境调用成功。

一、先确认来源、版本与适用环境

官方项目是obra/superpowers，目标文件为skills/receiving-code-review/SKILL.md。本文核对已有资源包对应的固定提交22f0b463e7a5e579904dd6211a520321035526f7，并沿用页面所示的2026-11-07源码快照。它不是对最新发布版本的宣称。

资源表中的下载入口复用本站已有Superpowers整包，包含多项Skill，不是一个新制作的独立安装包。读取时定位到receiving-code-review目录，保留仓库README与MIT许可证；不需要为了这篇练习重新上传或删除网盘文件。

准备支持Skill或插件的开发助手，以及能够运行Python 3的本地环境。本文以Claude Code的官方插件渠道说明安装入口；其他工具应查看仓库对应说明，不能把Claude Code命令直接当作通用终端命令。

Skill文件本身是Markdown工作说明，不是Python库。用pip安装一个同名包，不能据此证明安装了这项Skill，也不要运行下载包里不理解的脚本来“激活”它。

二、安装后检查是否真的加载

在Claude Code会话内使用官方README给出的插件命令：

/plugin install superpowers@claude-plugins-official

该命令属于Claude Code插件入口，不是在PowerShell或系统终端执行的命令。若已经安装Superpowers，先查看插件状态，不必重复添加第二个市场。

确认启用后新开会话，要求助手说明当前是否能读取receiving-code-review技能。不要只凭它回答“我知道这个方法”就认定加载成功；需要检查工具自身提供的技能可用信息，或它明确引用实际加载的技能内容。

不同版本和工作环境可能改变安装入口，以官方README和当前插件界面为准。若无法加载，仍可以学习下文的审查过程，但应记录“按方法人工执行”，不要把它写成插件运行成功。

三、把业务约束放在代码之前

建立一个空练习目录。约定本次函数只规范一个物料编号，规则如下：

• 输入必须是字符串，非字符串应抛出TypeError。
• 去掉首尾空白，但保留中间的字符与空格。
• 编号前导零必须保留，不能把0012转换为12。
• 大小写和连字符有业务含义，ab-01不能自动变成AB01。
• 去掉首尾空白后不能为空，空编号抛出ValueError。
• 排序不属于这个单值函数的职责，本次没有排序要求。

这些是本练习明确给出的业务约定，不是所有公司通用的物料编码标准。真实项目若使用不区分大小写的编号，应先修改已确认的规范与测试，不能机械照搬本篇。

先把规范保存为requirements.md，再将下面的起始代码保存为codes.py。它故意没有处理首尾空白，供审查时定位问题：

def normalize_code(value):
    if not isinstance(value, str):
        raise TypeError("code must be str")
    if not value:
        raise ValueError("code must not be empty")
    return value

四、完整阅读三条反馈，先不修改

准备三条模拟审查意见：第一条，“输入两侧有空格，建议去掉”；第二条，“数字编号统一转成整数，便于保持格式一致”；第三条，“顺便把排序优化一下”。

前两条看起来都与格式有关，实际结论相反。首尾空白处理符合规范；整数转换会丢掉前导零，也无法处理ab-01。第三条连输入集合、排序位置和排序规则都没有说明。

把反馈连同规范发给助手：

请使用 receiving-code-review 的方法检查以下审查意见。
先完整阅读 requirements.md、codes.py 和三条反馈，不修改文件。
逐条列出：反馈含义、对应规范、需要核实的证据、建议决策。
若有不明确的意见，请先提出具体问题，等待我确认。
不要因为审查者语气肯定就直接采纳，也不要把建议当作新需求授权。

官方Skill强调遇到不清楚的反馈先澄清。本练习应先询问：“排序针对哪个列表，按字符串还是数值顺序，是否属于这次修改？”在确认前，不应一边猜排序含义一边修改其他相关代码。

五、澄清范围后再形成决策

为使练习继续，给出明确回复：“排序意见暂缓，不属于本次；仅修复符合原规范的首尾空白问题，保留其他行为。”这句话是练习中的假定业务方答复，不是AI替真实客户作决定。

此时决策记录应包含三行独立结论。第一条接受，证据是带首尾空白的编号应规范化；第二条不采纳，证据是0012和ab-01必须原样保留；第三条已澄清为暂缓，当前不新增排序功能。

对外说明可以简洁写：“已核实前导零具有含义，因此保留字符串；本次仅处理首尾空白并补充回归检查。”不需要先夸奖审查者，也不需要用情绪化措辞反驳。判断依据应当落到规范、输入例子和运行证据上。

六、先用测试证明问题存在

将下面文件保存为test_codes.py。它只使用Python标准库，不需要安装测试框架。

import unittest
from codes import normalize_code


class CodeTests(unittest.TestCase):
    def test_trim(self):
        self.assertEqual(normalize_code(" 0012 \n"), "0012")

    def test_leading_zero(self):
        self.assertEqual(normalize_code("0012"), "0012")

    def test_case_and_hyphen(self):
        self.assertEqual(normalize_code("ab-01"), "ab-01")

    def test_internal_space(self):
        self.assertEqual(normalize_code("A B"), "A B")

    def test_empty(self):
        with self.assertRaises(ValueError):
            normalize_code("")

    def test_blank(self):
        with self.assertRaises(ValueError):
            normalize_code(" \t\n")

    def test_non_string(self):
        for value in (None, 12, True):
            with self.subTest(value=value):
                with self.assertRaises(TypeError):
                    normalize_code(value)


if __name__ == "__main__":
    unittest.main()

运行python -m unittest -v。对本篇起始代码，test_trim和test_blank应失败，其余方法通过。测试总共七个方法，其中非字符串方法还有三个子用例。不要把预期失败隐藏起来，也不要把“没有语法错误”当作业务检查通过。

七、只修复确认过的行为

将codes.py替换为以下实现，再运行同一条命令：

def normalize_code(value):
    if not isinstance(value, str):
        raise TypeError("code must be str")
    code = value.strip()
    if not code:
        raise ValueError("code must not be empty")
    return code

本地验证中，修改后七个测试方法全部通过。修复去掉首尾空白后再检查空串，因此空白输入不再漏过；它没有引入int转换、大小写转换或排序。

这里的strip会处理Python定义的首尾空白字符。如果真实业务只允许去除普通空格，或者要求拒绝制表符，应调整规范与测试，不能把更宽的处理范围默默带入生产。

再次查看文件差异，确认没有顺手修改其他模块。若助手额外增加数据库、日志上报或批量接口，先让它说明与本次缺陷的关系；没有对应需求时撤回这些扩展。

八、交付证据与常见排错

交付时保留原始反馈、澄清答复、逐条决策、修改差异，以及两次测试输出。起始失败证明检查能抓住缺陷，修复通过证明当前实现满足这一组已写出的规则；它们都不能证明所有业务情况已被覆盖。

若提示找不到codes模块，检查两个文件是否在同一目录，并在该目录运行命令。若测试意外全通过，检查是否早已使用修复版，不要补写虚假的失败日志。若前导零消失，搜索是否在函数外的CSV读取或数据库字段转换阶段发生了数值化。

若真实审查意见与已有架构决定冲突，先带证据确认。Skill提供的是核实、澄清和逐项实施的顺序，最终是否改变业务规则仍由有权限的人决定。把这套记录留在项目里，下一位维护者才知道为什么某条“看起来更简洁”的建议没有被采用。

九、把这次练习变成团队可复用的记录

可以建立一个简短的审查记录文件，每条意见分别填写原文、理解后的要求、相关约束、验证方法、决策和处理状态。对“已处理”的意见，附上修改位置及实际运行输出；对“暂缓”的意见，写明是谁确认暂缓、还缺什么信息，而不是把未完成项删掉。

例如第二条整数转换建议，记录中应直接保留0012这一反例，以及规范中“前导零具有业务含义”的依据。日后如果团队确实决定迁移编码格式，可以据此评估数据库、导入文件和显示界面需要一起调整，而不是只改一个函数让新旧数据不一致。

审查者也可能给出新的事实，证明原有规范理解有误。此时应该核对证据并纠正判断，不要为了维护先前的拒绝结论继续争辩。先更新确认过的要求，再调整测试和实现，最后说明行为发生了什么变化。Skill强调技术核实，并不意味着默认反对所有外部反馈。

对于真实仓库，还需要运行与修改有关的项目检查，而非只运行本文七个小测试。若编号会进入订单导出，至少检查导出后前导零仍然存在；若编号会用于查询，还要确认查询条件保留原有大小写规则。这些检查应依据实际调用位置制定，不能凭空声称整个系统已通过回归。

最终交付的价值是让下一位维护者可以重现判断：他能看到需求、反例、改动和运行结果，知道哪些行为已经检查，哪些仍在范围之外。

官方资料

• Receiving Code Review：本文核对的固定提交
• Superpowers：安装与使用说明
• Superpowers：MIT许可证
• Python：unittest标准库