Claude Code代码审查提示词：请求错误依据与复现条件

核心概括： 委托代码审查时，与其说“找很多问题”，不如说明按照什么行为标准审查哪些修改。结果需要文件位置、发生条件、用户影响与确认依据。以下提示词与计算函数，是作者编写的审查练习示例，并非实际仓库审查结果。

1. 先规定审查范围与正常行为

先写审查的是当前修改、特定文件，还是某功能完整流程。使用Git时，比较基准也应在实际仓库规定。笼统请求“全部代码审查”，可能混合旧问题、本次修改问题与风格偏好。

正常行为可以用简短输入、输出示例说明。搜索功能应明确“搜索词为空时显示全部列表，还是只显示提示”。不规定画面所需结果，同一实现也会按不同标准评价。有现有设计文档与测试时，也应提供位置。

2. 基本代码审查提示词示例

이번 변경을 코드 리뷰해 줘. 파일은 아직 수정하지 마.
검토 범위: [실제 변경 파일 또는 비교 기준]
요구 동작: [입력과 기대 결과]
우선 확인: 잘못된 결과, 예외 처리, 기존 기능의 회귀.
스타일 선호만으로 문제를 만들지 마.
각 지적은 아래 형식으로 적어 줘.
- 파일과 위치
- 어떤 입력 또는 상태에서 발생하는지
- 사용자에게 어떤 영향이 있는지
- 코드·테스트·실행 결과 중 확인 근거
- 실제로 확인한 문제인지, 아직 확인할 가설인지
실행하지 않은 테스트는 실행했다고 쓰지 마.

审查与修改是不同工作，因此可以先阅读指出的问题，选择有效问题后请求修改。仅凭代码外观难以判断的问题，需要确认调用路径与实际数据条件。此格式目的在于收集判断所需信息，而不是增加问题数量。

3. 虚构示例：审查折扣金额函数

设想一个接收商品金额与折扣百分比，计算最终金额的函数。审查标准为“金额不小于0，折扣百分比为0到100，明确处理无效输入”。10,000韩元打20%折扣，预期金额8,000韩元。这是为说明直接计算的值，并非代码运行结果。

• 正常范围：10,000韩元、20%时，是否符合规定预期值。
• 边界值：如何处理0%与100%折扣。
• 无效值：负数、空值与非数字值的处理。
• 连接流程：画面接收的字符串在哪里转为数字。
• 显示规则：在哪里处理小数与四舍五入。

函数本身没有问题，输入转换或画面显示仍可能出错。反过来，如果函数只接收外部已验证输入，也可能无须重复添加全部防御逻辑。审查应包含“这个输入实际能否进入”的条件确认。

4. 将问题区分为事实、假设与改善建议

应区分“空数组发生异常”的实际复现结果，与“空数组可能发生异常”的代码解释。没有运行日志，却写成前者时，应询问用什么命令与输入确认。环境不能执行时，可以将确认方法作为建议留下。

Anthropic的Claude Code推荐工作方式也说明提供验证标准、独立审查结果的方向。审查回答不应视为正确答案列表，而应对照每项问题的代码路径与影响。即使说明具体，也可能有错误假设。

审查后，宜对每项记录“已复现”“需要进一步确认”“当前需求范围外”等状态。与其为修复无依据问题而复杂化代码，不如先确认发生条件，选择必要修改。

5. 修改后用相同条件再次确认

修复问题后，应同时确认原复现条件与正常条件。只阻止无效折扣，却让正常20%输入也失败，就产生另一回归。相关测试与命令应遵循实际项目方式，也应区分只生成测试名称与实际执行通过。

完成报告可以整理为“修改文件、问题原因、已执行验证、剩余确认事项”。官方工作示例也逐步处理测试与修改审查。为避免读者猜测报告没有的验证已经执行，应要求明确列出未执行项目。

6. 区分修改审查与需求审查

寻找当前修改引入的错误，与确认计划全部要求是否实现，问题不同。前者重点阅读修改前后代码路径与回归，后者将计划项目与实现、验证依据配对。写明类型，才能将“功能存在，但缺少一个条件”也分类为有效问题。

截至确认日，官方推荐文档也介绍了由独立子代理审查当前diff的内置/code-review功能。不要先假定所有审查方式相同，应先规定目的是确认修改错误还是对照计划。调用功能本身，不能证明问题复现或全部要求满足。

7. 在虚构代码中完整追踪问题依据

进一步具体说明前述折扣案例。下方JavaScript代码是练习用虚构代码，没有实际项目运行结果。假设画面将“20%”转成数字20传入。若另一设计传入0.2，判断就不同，因此应先规定输入契约。

function finalPrice(price, discountPercent) {
  return price * (1 - discountPercent);
}

按照规定契约，代入10,000与20，公式为10,000 × (1 − 20)，得到−190,000，与所需8,000不同。这是直接代入公式的计算，而不是代码运行日志。问题描述与其写“折扣函数异常”，不如写“契约接收百分比数值20，但缺少比例转换，正常输入也变为负数”，更能明确原因与条件。

即使修正公式将百分比除以100，也不会自动规定输入拒绝、小数与货币显示。例如，999韩元打15%折扣，算术结果为849.15韩元。实际销售金额是四舍五入还是舍去，应按项目需求决定。提供标准，避免审查者按个人偏好更改金额政策。

이 함수의 입력 계약은 할인 비율을 0~100 숫자로 받는 것입니다.
호출부에서 실제로 이 계약을 지키는지 먼저 추적해 줘.
10,000 / 20% 사례의 식과 기대값 차이를 설명해 줘.
실행 로그가 없으면 '정적 검토와 계산으로 판단'이라고 표시해 줘.
입력 검증·반올림 정책은 기존 문서에서 확인하고,
근거가 없으면 별도 결정 사항으로 남겨 줘.

8. 减少误报的问题与分类

例如，有人指出“字符串输入可能失败”，但调用处已经转换数字并检查范围，就应继续查看该输入能否到达函数。不要根据未确认路径持续堆加防御代码，应追踪调用位置与数据转换，再决定是否采纳。这是确认发生条件的流程，而不是忽略错误。

리뷰 지적 2번을 다시 검토해 줘.
주장한 입력이 외부에서 해당 함수까지 오는 호출 경로를 제시해 줘.
중간 검증이 있다면 그 파일과 조건을 확인해 줘.
현재 코드로 발생할 수 없는 가정이면 지적을 철회하고 이유를 적어 줘.
검토 범위에서 호출부를 찾지 못했다면 '추가 확인 필요'로 남겨 줘.
같은 이유를 표현만 바꿔 여러 지적으로 나누지 마.

阅读报告时，也应分别看影响大小与依据层级。支付结果错误可能影响很大，但发生路径尚未确认时，也要记录状态。不能只凭“严重”标签改为已复现问题。反过来，复现小而简单，也不能认定用户影响小。

9. 只修复选定问题并比较结果

选择有效问题后，修改请求中也应加入保留行为。折扣函数修正单位转换，与重设计整个画面，是不同范围。有相关测试时，应遵循原执行步骤；没有时，可先明确核心输入预期结果，规定确认方法。不能编造项目没有的测试命令，并写成运行结果。

채택한 지적: [번호와 원인]
수정 범위: 할인 비율 변환과 직접 관련된 코드.
유지 조건: 기존 화면·공개 함수 입력 형식 유지.
검증 기준: 정상 20%, 경계 0%와 100%, 기존 입력 거부 정책.
실제 프로젝트의 검증 명령을 근거 파일에서 찾아 사용해 줘.
완료 보고에는 변경 파일, 해결한 원인, 실행 명령과 결과,
실행하지 못한 항목·이유를 나눠 적어 줘.
검증 중 다른 문제가 나오면 이번 수정과 관련 여부를 구분해 줘.

最后重新阅读diff，确认是否有请求范围外修改。显示“测试通过”时，应确认哪些测试在什么环境执行，保留金额显示等仍未确认项目。一项测试通过的观察，是该测试范围的依据，不能扩大为整体服务全部输入都正常。

测试未执行，也能接受审查吗？

可以进行阅读代码条件与调用路径的静态审查。结果应注明未执行，留下用什么输入确认什么内容。环境问题无法运行时，相比一句“审查失败”，分开静态确认项目与剩余行为确认，更方便下一位接手。

常见问题与错误处理

审查说没有问题，就结束了吗？ 应查看确认范围与是否执行。风格问题太多怎么办？ 明确标准，优先功能错误与需求违反。可以同时委托自动修复吗？ 明确选定问题与修改范围，修复后确认相同条件的验证结果。

官方来源与确认日期

• Claude Code最佳实践
• 常见工作流程

官方文档确认日期：2026年10月3日。画面与提供条件之后可能变化。