chinese-code-review

name	chinese-code-review
type	domain-rule
description	中文团队代码审查文化——用建议替代命令、提问替代否定。当收到代码审查反馈或审查他人代码时自动触发。 触发词：代码审查、Code Review、CR、review 代码。
version	1.0.0
author	wta

中文团队代码审查规范

适用于中文技术团队的代码审查场景。

Iron Law

禁止无建设性批评。 每条反馈必须附带理由和示例，不能使用“这样不行”、“不好”等模糊表达。

三级标注

级别	含义	处理方式
[必须修复]	影响功能正确性或安全性	必须修复后才能合并
[建议修复]	改进点，不强制但有实质影响	建议修复，不阻塞合并
[供参考]	可选优化建议	仅记录，无行动要求

沟通原则

用"建议"替代"命令"

不好	好
"改成 X"	"建议改成 X，因为这样可以避免 Y 问题"
"这里不对"	"这里有个潜在问题：当 X 为 null 时会 NPE。建议加空值检查"
"不要用这个模式"	"这个模式在 Z 场景下有问题。考虑用 Y 替代？理由是..."

用"提问"替代"否定"

不好	好
"这样写不行"	"考虑过 Y 方案吗？在处理 X 场景时 Y 可能更健壮"
"你没考虑边界情况"	"当输入为 X 时，这段代码的行为是什么？"

每条建议附带理由和示例

[建议修复] extractUserData 方法可以用对象解构简化可读性。

当前：
function extractUserData(user) {
  const name = user.name;
  const email = user.email;
  const role = user.role;
  return { name, email, role };
}

建议：
function extractUserData({ name, email, role }) {
  return { name, email, role };
}

理由：参数解构在函数签名处就声明了依赖的字段，更清晰且更短。

审查清单

• 每个 [必须修复] 附带具体修复建议和代码示例
• 每条建议附带理由（为什么这是问题）
• 正面反馈优先：先肯定做得好的地方，再提出改进
• 关注代码而非人：用“这段代码”而非“你写的代码”

审查完成自检

• 所有反馈都遵循三级标注体系？
• 每条建议都有理由和示例？
• 使用了建设性语言（建议/提问）而非命令/否定？
• 提供了正面反馈（做得好的地方）？
• 反馈关注代码而非人？