审查用户修改的代码(diff/PR),提供最佳实践建议,分析方案性价比并输出代码评分。使用...
修改代码评审(Modified Code Review)是一项面向实际任务的技能,主要用于对用户修改的代码进行评审,给出最佳实践建议、修改方案性价比分析,并输出代码评分;用户要求「review 我修改的代码」「审查修改」「代码评审」;
若用户未指定:先看 git status。它将相关步骤、工具调用和结果整理方式集中到统一流程中,帮助使用者更快完成目标并减少重复操作。从功能定位来看,该技能强调把分散的操作要求整理成清晰、可复用的处理流程,使用户能够围绕既定目标快速准备输入、选择执行方式并获得结构化结果。
实际使用前应先确认任务范围、数据来源、运行环境、必要权限和关键参数,再依据技能说明逐步执行;若输入条件不完整,应先补齐信息或采用保守配置,避免因错误假设导致结果偏离需求。执行过程中需要关注工具调用是否成功、接口或依赖是否可用、输出格式是否符合预期,并对异常提示、缺失字段和边界情况进行处理;涉及批量任务时,还应保存进度,避免中断后重复操作。
对用户修改的代码进行评审,给出最佳实践建议、修改方案性价比分析,并输出代码评分。
git status / git diff 或当前打开/选中的文件按以下维度分析修改,并给出结论与建议:
| 维度 | 关注点 |
|---|---|
| 正确性 | 逻辑是否正确、边界与异常是否考虑、是否有明显 bug |
| 可读性 | 命名、结构、注释是否清晰,是否符合项目风格 |
| 可维护性 | 是否易扩展、是否过度耦合、重复代码 |
| 性能 | 是否有不必要的计算、内存/请求是否合理 |
| 安全 | 输入校验、敏感数据、XSS/注入等 |
| 测试 | 关键路径是否有测试、用例是否合理 |
对主要修改方案做「性价比」评估:
先列 Blockers,再给评分——有 Blocker 时评分仅供参考,不能用分数掩盖必须修的问题。
| 分数区间 | 等级 | 含义 |
|---|---|---|
| 90–100 | A 优秀 | 可直接合并,仅有个别小建议 |
| 75–89 | B 良好 | 整体达标,有若干改进点 |
| 60–74 | C 合格 | 能用但建议按优先级修复/优化 |
| 40–59 | D 需改进 | 存在明显问题,建议修改后再合 |
| 0–39 | E 不达标 | 存在严重问题,需重构或重做 |
评分需结合:正确性权重最高,其次可维护性/可读性,再考虑性能与安全。
按以下结构组织回复(可用中文):
## 修改代码评审报告 ### 一、改动概览 - 涉及文件与变更类型 - 主要改动摘要(1–3 句) ### 二、评审结论(按维度) - 正确性:… - 可读性:… - 可维护性:… - 性能:… - 安全:… - 测试:… ### 三、最佳实践建议 - [必须改] … - [建议改] … - [可选优化] … ### 四、修改方案性价比 - 方案/建议 1:收益 vs 成本 → 性价比结论 - (其他主要方案按需) ### 五、代码评分 - **Blockers(必须改,不改不能合)**:…(无则写"无") - **分数**:XX / 100(等级:X) - **一句话总结**:…
相关专题
热门下载
相关下载
精品课程
共6课时 | 54.7万人学习
共89课时 | 134.1万人学习
共49课时 | 82.5万人学习
最新文章