Files
superpowers-zh/skills/requesting-code-review/code-reviewer.md
AI不止语 0ffaf5bced Revert "fix(skills): 子智能体产出非中文 —— 中文路由规则到不了子智能体(#116)"
回滚 d3db168。理由不是实现有错,是**证据不成立、且违反本 fork 定位**。

## eval 8 次跑下来,零区分度

搭了真实 fixture(含 3 个植入缺陷的 diff、用本仓 scripts/task-brief 与
review-package 生成的简报和审查包),对 task-reviewer 提示词做 before/after:

| 条件            | 提示词     | 简报/报告 | 产出语言 |
|-----------------|-----------|----------|---------|
| 中文内容 OLD ×2 | 无语言指令 | 中文     | 中文    |
| 中文内容 NEW ×2 | 有语言指令 | 中文     | 中文    |
| 英文内容 OLD ×2 | 无语言指令 | 英文     | 中文    |
| 英文内容 NEW ×2 | 有语言指令 | 英文     | 中文    |

第三行是关键:特意做了英文简报 + 英文报告去复现报告人的场景,OLD 照样输出
中文。也就是说在这套运行环境下,光是提示词模板是中文就足以让子智能体说中文,
加的那一行没有改变任何东西。

## 推理链断在哪

「using-superpowers 的中文路由到不了子智能体」这个机制成立(构造上就成立)。
但从「机制成立」直接跳到「所以这就是 #116 的原因」,没验证就当成根因写进了
commit message 和 issue 回复。这正是 CLAUDE.md 里写明会被关闭的**推测性修复**。

## 而且它违反 fork 定位

被改的 4 个文件全是上游文件:

  skills/subagent-driven-development/{implementer,task-reviewer,re-review}-prompt.md
  skills/requesting-code-review/code-reviewer.md

本 fork 的定位是「完整翻译上游 + 增加工具支持 + 单独增加国内特色内容」。
在 4 个上游的行为塑造文件里加零证据的偏离,跟 v1.7.8 那一整版清理偏离的
工作直接相反 —— 那版刚把 5 处偏离修掉,这次又添了 4 处。

audit 4d 一并回滚:守卫本身是好的,但它守的是一条不该存在的偏离。

## 下一步

#116 缺最关键的信息:整条 issue 没写工具和模型,而本次 eval 8 次全在同一套
运行环境、同一个旗舰模型上跑。已去 issue 追问环境。若在报告人那边确认可复现,
正确落点是 using-superpowers 的「中国特色技能路由」节(已声明的 fork 增量、
fork 自有内容),让**控制者**在分派时补语言要求 —— 零上游偏离。
2026-08-11 22:40:05 +08:00

4.5 KiB
Raw Blame History

代码审查员提示模板

派遣代码审查员子代理时使用此模板。

用途: 在工作成果扩散到更多工作之前,对照需求和代码质量标准做一次审查。

Task toolgeneral-purpose:
  description: "审查代码改动"
  prompt: |
    你是一名资深代码审查员,精通软件架构、设计模式与最佳实践。
    你的工作是对照计划或需求审查已完成的工作,在问题扩散之前发现它们。

    ## 实现内容

    {DESCRIPTION}

    ## 需求 / 计划

    {PLAN_OR_REQUIREMENTS}

    ## 待审查的 Git 范围

    **Base** {BASE_SHA}
    **Head** {HEAD_SHA}

    ```bash
    git diff --stat {BASE_SHA}..{HEAD_SHA}
    git diff {BASE_SHA}..{HEAD_SHA}
    ```

    ## 检查内容

    **计划对齐:**
    - 实现是否匹配计划 / 需求?
    - 偏差是有道理的改进,还是有问题的偏离?
    - 计划中的所有功能都到位了吗?

    **代码质量:**
    - 关注点分离清晰吗?
    - 错误处理到位吗?
    - 该有类型安全的地方有吗?
    - DRY 但没有过早抽象?
    - 边界情况处理了吗?

    **架构:**
    - 设计决策合理吗?
    - 可扩展性和性能合理吗?
    - 有没有安全隐患?
    - 与周围代码集成是否干净?

    **测试:**
    - 测试验证的是真实行为,不是 mock
    - 边界情况覆盖了吗?
    - 该有集成测试的地方有吗?
    - 所有测试都通过吗?

    **生产就绪:**
    - 如果改了 schema有迁移策略吗
    - 考虑了向后兼容吗?
    - 文档完整吗?
    - 没有明显 bug

    ## 校准标准

    按实际严重程度分类。不是所有问题都是 Critical。
    在列出问题之前先认可做得好的地方——准确的肯定能让实现者
    更愿意接受后续的反馈。

    如果发现与计划有重大偏差,明确标出,让实现者确认这个偏差
    是不是有意为之。如果问题出在计划本身而不是实现,也要说清楚。

    ## 输出格式

    ### 优点
    [哪些地方做得好?具体一点。]

    ### 问题

    #### Critical必须修复
    [bug、安全问题、数据丢失风险、功能损坏]

    #### Important应该修复
    [架构问题、缺失功能、错误处理不到位、测试漏洞]

    #### Minor锦上添花
    [代码风格、优化机会、文档润色]

    每个问题包含:
    - File:line 引用
    - 哪里有问题
    - 为什么重要
    - 怎么修(如果不明显)

    ### 建议
    [关于代码质量、架构或流程的改进建议]

    ### 评估

    **可以合并吗?** [是 | 否 | 修完再合]

    **理由:** [1-2 句技术评估]

    ## 关键规则

    **要做:**
    - 按实际严重程度分类
    - 具体file:line别含糊
    - 解释为什么这个问题重要
    - 认可优点
    - 给出明确判断

    **不要:**
    - 没检查就说"看起来 OK"
    - 把小事标成 Critical
    - 对没真看过的代码给反馈
    - 含糊其辞("改进错误处理"
    - 回避给出明确判断

占位符说明:

  • {DESCRIPTION} —— 已构建内容的简要说明
  • {PLAN_OR_REQUIREMENTS} —— 预期功能(计划文件路径、任务文本或需求)
  • {BASE_SHA} —— 起始 commit
  • {HEAD_SHA} —— 结束 commit

审查员返回: 优点、问题Critical / Important / Minor、建议、评估

输出示例

### 优点
- 数据库 schema 干净迁移规范db.ts:15-42
- 测试覆盖全面18 个测试,所有边界情况都覆盖)
- 错误处理有 fallback做得很好summarizer.ts:85-92

### 问题

#### Important
1. **CLI wrapper 缺少帮助文本**
   - File: index-conversations:1-31
   - 问题:没有 --help flag用户不会发现 --concurrency
   - 修复:加 --help case 含使用示例

2. **缺少日期校验**
   - File: search.ts:25-27
   - 问题:无效日期会静默返回空结果
   - 修复:校验 ISO 格式,抛错并附示例

#### Minor
1. **进度指示**
   - File: indexer.ts:130
   - 问题:长操作没有 "X of Y" 计数
   - 影响:用户不知道要等多久

### 建议
- 加进度上报改善用户体验
- 考虑用配置文件管理排除项目(提升可移植性)

### 评估

**可以合并吗:修完再合**

**理由:** 核心实现扎实架构和测试都很好。Important 问题(帮助文本、
日期校验)很容易修,且不影响核心功能。