名称: 代码审查开发者 描述: 上下文感知路由到代码审查指南。在审查拉取请求、提供代码反馈或讨论审查标准时使用。
代码审查开发者(智能路由器)
目的
上下文感知路由到代码审查指南。帮助您按照项目标准进行彻底、可操作的代码审查。
何时自动激活
- 审查拉取请求或代码变更
- 关键词:代码审查、PR审查、审查代码、拉取请求、批准、问题
- 讨论审查评论或反馈
🚨 关键规则(切勿违反)
- 保持简洁和可操作 - 仅报告实际问题,无噪音
- 无表扬部分 - 无“优势”或“无问题”陈述
- 无设计建议 - 您无法看到视觉设计(内边距、外边距、颜色)
- 引用文件:行号 - 始终包括问题的具体位置
- 如果干净,只需批准 - “✅ 已批准 - 未发现问题”(仅此!)
- 检查 CLAUDE.md - 根据项目约定进行审查
📋 快速审查工作流程
1. 阅读变更
- 理解PR的意图
- 彻底检查文件差异
2. 对照 CLAUDE.md 检查
- 本地化:使用
Loc常量? - 生成文件:未编辑生成代码?
- 代码风格:遵循Swift最佳实践?
- 测试:重构时更新了?
3. 查找实际问题
仅当存在问题时包括部分:
- 错误/问题 - 逻辑错误、潜在bug
- 最佳实践 - 违反 CLAUDE.md 指南
- 性能 - 实际性能问题
- 安全 - 实际安全漏洞
4. 格式化您的审查
如果干净:
✅ **已批准** - 未发现问题
关键: 批准时,仅输出上一行。无额外解释、无列出PR内容、无表扬。仅批准行。
如果发现问题:
## 错误/问题
**ChatView.swift:45**
潜在竞争条件当...
---
⚠️ **次要问题** - 修复竞争条件
⚠️ 常见错误避免
假设UI移除后代码未使用
场景: PR移除菜单按钮但保留 menu 参数
❌ 错误:
“menu参数现在未使用,应移除”
✅ 正确:
检查menu是否在其他地方使用:
- 长按上下文菜单?
- 双UX模式(按钮+长按)?
- 多个消费者?
示例:
// menu() 在两个地方使用
.toolbar { Menu { menu() } } // 可见按钮(已移除)
.contextMenu { menu() } // 长按(仍在!)
建议移除前:
- [ ] 在文件中搜索所有使用
- [ ] 检查双UX模式
- [ ] 理解每个标志的目的
- [ ] 如果不确定,询问设计意图
不理解条件标志
场景: 组件有 allowMenuContent 和 allowContextMenuItems
❌ 错误:
“这些标志目的相同,合并它们”
✅ 正确:
它们控制不同的UI元素:
- allowMenuContent: 可见按钮
- allowContextMenuItems: 长按菜单
- 可以独立启用/禁用
标记正确重新生成的文件
场景: PR包括对生成文件的更改(例如,Generated/FeatureFlags.swift)。
❌ 错误:
“编辑了生成文件而不是运行代码生成”
(假设对生成文件的任何更改都是违规)
✅ 正确: 检查对应的源文件是否也在PR差异中:
| 生成文件 | 源文件 |
|---|---|
Generated/FeatureFlags.swift |
FeatureDescription+Flags.swift |
Generated/Strings.swift |
.xcstrings 文件 |
Generated/ImageAssets.swift |
Assets.xcassets 文件夹 |
Modules/*/Generated/ |
模板或注解源文件 |
正确工作流程模式:
PR包含:
├── FeatureDescription+Flags.swift(源 - 已更改)
└── Generated/FeatureFlags.swift(生成 - 也已更改)
→ 这是正确的!开发者编辑了源并运行了 `make generate`
实际违规模式:
PR包含:
└── Generated/FeatureFlags.swift(生成 - 已更改)
(无对应源文件更改)
→ 这是错误的!开发者手动编辑了生成文件
标记生成文件编辑前:
- [ ] 检查对应的源文件是否在差异中
- [ ] 如果源文件更改 → 重新生成是合适的,非违规
- [ ] 如果仅生成文件更改 → 标记为违规
🎯 审查部分(仅当存在问题时包括)
错误/问题
逻辑错误、需要修复的潜在bug
格式:
**FileName.swift:123**
错误描述及为什么是问题。
最佳实践
违反Swift/SwiftUI约定或CLAUDE.md指南(仅代码质量,非设计)
格式:
**FileName.swift:45**
使用硬编码字符串而不是Loc常量。
性能
实际性能问题(非理论)
格式:
**ViewModel.swift:89**
循环中的N+1查询 - 在大数据集上会导致性能问题。
安全
实际安全漏洞
格式:
**AuthService.swift:34**
在UserDefaults中存储凭据 - 应使用Keychain。
📊 总结格式
以状态表情结束一句话:
✅ **已批准** - 遵循指南的干净实现
⚠️ **次要问题** - 修复硬编码字符串和竞争条件
🚨 **主要问题** - 认证流程中的关键安全漏洞
🔍 分析检查清单
最终确定审查前:
- [ ] 对照CLAUDE.md约定检查
- [ ] 验证本地化(无硬编码字符串)
- [ ] 检查生成文件编辑
- [ ] 查找竞争条件
- [ ] 验证测试/模拟在重构时更新
- [ ] 建议移除前搜索所有使用
- [ ] 仅包括有实际问题的部分
- [ ] 无设计/UI建议(内边距、外边距、颜色)
- [ ] 引用每个问题的具体文件:行号
- [ ] 以状态表情摘要结束
📚 完整文档
完整指南: .claude/CODE_REVIEW_GUIDE.md
涵盖:
- 核心审查规则
- 常见分析错误(带示例)
- 审查部分和格式
- 完整检查清单
CI/自动化: .github/workflows/pr-review-automation.md
GitHub Actions集成:
- 上下文变量(REPO, PR_NUMBER, COMMIT_SHA)
- 有效运行器和Xcode版本
- 审查评论策略
- 如何通过
ghCLI发布审查
💡 快速参考
检查什么
来自 CLAUDE.md:
- [ ] 无硬编码字符串(使用
Loc常量) - [ ] 无生成文件编辑(
// Generated using...) - [ ] 测试/模拟在重构时更新
- [ ] 新功能的功能标志
- [ ] 无空白修剪
- [ ] 使用异步/等待而非完成处理程序
代码质量:
- [ ] Swift最佳实践(guard, @MainActor)
- [ ] 适当的错误处理
- [ ] 生产代码中无强制解包
- [ ] 内存泄漏(需要时使用weak/unowned)
不要评论什么
- ❌ 设计/UI间距(内边距、外边距)
- ❌ 颜色或视觉外观
- ❌ 表扬或“优势”部分
- ❌ “无问题”陈述
- ❌ 理论性能问题
- ❌ 不在CLAUDE.md中的风格偏好
🎓 示例审查
示例1:干净PR
✅ **已批准** - 未发现问题
仅此!绝对无其他。甚至在GitHub评论中也是如此。
❌ 错误(太啰嗦):
✅ **已批准** - 未发现问题
PR正确实现了每聊天通知覆盖:
- 添加了带适当订阅键的强制列表属性
- effectiveNotificationMode(for:) 方法正确优先...
✅ 正确:
✅ **已批准** - 未发现问题
示例2:次要问题
## 最佳实践
**ChatView.swift:34**
使用硬编码字符串“Send Message”而不是本地化常量。
应为:`Text(Loc.sendMessage)`
**ChatViewModel.swift:89**
重命名 `sendMessage()` 为 `send()` 后测试未更新。
更新 `ChatViewModelTests.swift` 以使用新方法名称。
---
⚠️ **次要问题** - 修复硬编码字符串和更新测试
示例3:关键问题
## 错误/问题
**AuthService.swift:45**
在UserDefaults中存储密码(第45行)。这是安全漏洞。
应使用Keychain:`KeychainService.store(password, for: key)`
---
🚨 **主要问题** - 修复密码存储安全漏洞
🔗 相关技能与文档
- ios-dev-guidelines →
IOS_DEVELOPMENT_GUIDE.md- 检查的Swift/iOS模式 - localization-developer →
LOCALIZATION_GUIDE.md- 验证无硬编码字符串 - code-generation-developer →
CODE_GENERATION_GUIDE.md- 验证无生成文件编辑
导航: 这是一个智能路由器。详细审查标准和常见错误,请始终参考 .claude/CODE_REVIEW_GUIDE.md。
CI/自动化: 参见 .github/workflows/pr-review-automation.md 以获取GitHub Actions集成。