专业代码审查专家

幂简官方

196 浏览

13 试用

3 购买

Nov 19, 2025更新

本提示词专为代码审查场景设计，通过系统化分析代码结构、命名规范、逻辑完整性和注释质量，帮助审查人员快速识别潜在问题。它结合多维度评估框架，从架构合理性、性能优化、安全防护等角度提供专业建议，确保代码符合团队规范并具备高可维护性。适用于日常代码审查、版本合并前质量检查、新人代码指导等多种开发场景，显著提升审查效率与代码质量。

问题分类	具体位置	问题描述	改进建议	优先级
安全漏洞	get_user 第13行	通过字符串拼接构造SQL，直接拼接外部输入 name，存在严重SQL注入风险	按团队规范改为预编译语句并使用参数化查询；绑定 name 参数，禁止任何形式的字符串拼接；同时仅查询所需列并限制结果为单条记录（利用唯一约束或加限制），可提升安全性与执行计划复用	高
异常处理/日志	get_user 第21-23行	捕获过于宽泛的 Exception，且使用 System.out 打印日志，未提供上下文信息且吞掉异常，易导致问题隐藏	捕获更具体的 SQLException；使用统一的标准日志框架记录（包含SQL、参数脱敏、耗时等上下文）；根据业务选择向上抛出或包装为受检/运行时异常，避免静默失败；禁止 System.out	高
输入校验	构造函数第8行、get_user 第11行、calc 第28行	未对外部输入进行空值与范围校验：Connection 可能为 null；name 可能为空/超长；n 可能为负或过大导致性能/溢出风险	对 Connection 使用非空校验（如显式校验并立即失败）；对 name 做非空、非空白、长度上限校验（与DB字段长度一致）；对 n 设定 [0, 上限] 范围并在越界时拒绝或降级处理	高
命名规范	方法名第11行、参数/变量第8、12、29行、键名第18行	方法名 get_user 使用下划线；参数 c、变量 r/s 语义不清；calc 含义不明确；Map 键 userName 与 username风格不一致	按团队规范改为小驼峰且具备语义：getUser、connection、result、sum 等；统一键名风格（建议 username）；提升可读性与一致性	中
代码逻辑/正确性	get_user 第16-20、24行	使用 while 迭代可能覆盖多行数据；若 username 非唯一返回最后一条；未显式处理“未找到”场景，返回空Map易与异常情况混淆	明确 username 唯一性（DB唯一索引）；读取第一条即返回；对“未找到”与“异常”区分处理（如返回 Optional 或特定状态）；避免结果被覆盖的隐患	中
类型设计/可维护性	get_user 返回类型	使用 Map<String,Object> 弱类型返回，键名硬编码、缺少编译期保障，不利于维护与演进	定义明确的领域模型（如 User{id, username, email}），方法返回 Optional/User；如必须返回Map，至少抽取常量定义键名并保持命名一致	中
架构设计	类级别（持有 Connection；混合职责）	持有长生命周期 Connection 存在线程安全与连接失效风险；仓储类同时包含与数据访问无关的计算逻辑（calc），职责不单一	通过 DataSource/连接池按调用获取连接并托管事务；将 calc 提取到独立的服务/工具类，明确单一职责；提升稳定性和可测试性	中
性能问题	calc 第28-35行	双重循环（n×10000）复杂度高；大 n 时CPU开销大；无任何限速/超时/提前返回策略	评估是否可用数学闭式/预计算替代；至少提取 10000 为常量、评估并降低上限；必要时增加入参上限或并行化/批处理；避免在仓储类中执行重计算	中
正确性问题	calc 第32行	i*j 在 int 上溢出会改变取模结果，导致累加结果不正确；当前仅在最终累加使用 long	在乘法前提升精度，先转为 long 再运算并取模；确保计算语义正确；必要时增加单元测试覆盖大输入边界	中
可读性/魔法数	calc 第31行	内层循环上界 10000 为魔法数，意义不明确	抽取具名常量（如 INNER_LOOP_BOUND），并在注释/Javadoc 中解释来源与业务含义，便于维护与调优	低
文档/注释	公共方法第11、28行	公共方法缺少 Javadoc，不符合团队规范；对输入要求、返回约定与异常无说明	为公共方法补充 Javadoc（含用途、参数、返回、可能抛出的异常与边界行为），明确“未找到”返回策略与异常传播策略	中
风格/导入	第3-4行	使用通配符导入（*），降低可读性与可控性	使用显式导入，便于审查与避免命名冲突；与团队代码风格保持一致	低
稳定性/超时控制	get_user 第14-15行	查询未设置超时，异常情况下可能长时间阻塞	在语句层或数据源层设置查询超时；结合监控记录执行耗时与慢查询，提升故障可观测性	低

补充说明与整体优化价值

安全：改用参数化查询和规范的异常/日志处理，可彻底消除SQL注入与信息泄露风险。
可维护性：命名规范、领域模型化返回值、Javadoc 完善，将显著提升可读性与团队协作效率。
正确性：修复 calc 的整数溢出与 get_user 多行覆盖问题，确保结果可靠。
性能与稳定性：对 calc 的复杂度控制与数据库查询的超时控制，降低资源风险与线上抖动。
架构：分离数据访问与计算逻辑、避免持久持有 Connection，有助于更清晰的职责划分与连接管理的可靠性。

问题分类	具体位置	问题描述	改进建议	优先级
安全配置	行23-24 (app.run)	在开发脚本中启用 debug=True 且监听 0.0.0.0，会暴露交互式调试器与内部信息，存在严重安全风险；不符合“禁用debug模式”规范。	仅在本地开发使用 debug；生产使用 WSGI 服务器（gunicorn/uwsgi），通过环境变量或配置文件控制 DEBUG=false；避免绑定 0.0.0.0 于开发环境。	高
参数校验	行16 (list_items)	未对查询参数 q 做类型、长度、空值策略校验；接口在异常或非法参数时没有返回明确错误。	明确 q 的类型与长度上限（例如 <=256），定义空字符串策略（禁止空则返回 400；允许则需分页限制）；对非法参数返回 400，包含统一错误结构（code/message）。	高
异常处理	行17-20 (list_items)	使用通配异常 except Exception，掩盖编程错误与运行时问题；与团队规范“禁用通配异常”冲突；同时吞掉错误并返回 200+空列表，误导调用方。	仅捕获预期异常（如 KeyError、TypeError）；在捕获时记录日志，并按语义返回 4xx/5xx；保留未预期异常以便监控告警。	高
逻辑正确性	行18 (list_items)	当 q 为空字符串时，表达式 "" in x["name"] 恒为 True，将返回所有缓存项，可能造成大结果集与性能风险。	明确空查询策略：禁止空查询或强制分页和最大返回条数（limit/offset，默认 limit）；必要时要求 q 至少 N 个字符。	高
性能优化	行18 (list_items)	每次请求对 cache 全表线性扫描，复杂度 O(n)；数据量增大时延迟与内存开销明显。	根据需求选择：建立按 name 的索引（如额外维护 name -> ids 映射，或预存小写字段做不区分大小写匹配）；或迁移到支持查询的存储（如 SQLite/ES）。同时对结果做分页。	中
并发与状态	行4 (cache 全局变量)	使用进程内全局可变字典，线程/多进程下数据一致性与线程安全无法保障；不同 Gunicorn worker 之间不共享数据。	明确数据源：只读场景可在进程启动时构建只读结构；写场景使用外部存储（Redis/DB）或加锁（threading.Lock）；对并发访问策略进行说明与测试。	中
可维护性/副作用	行6 (load_config)	可变默认参数 opts={} 会在多次调用间共享状态，导致配置污染与难以定位的隐式副作用。	将默认参数改为 None，并在函数内初始化新字典；避免跨调用共享状态。	高
可维护性/副作用	行11 (load_config)	使用 opts.update(data) 原地修改入参，增加函数副作用且影响调用方预期。	避免就地修改：返回合并后的新字典；若必须原地更新，需在文档中明确说明副作用。	中
I/O 异常分类	行9-10 (load_config)	文件读取与 JSON 解析未做异常分类处理，FileNotFoundError/PermissionError/JSONDecodeError 均会向上抛出或在调用处被不当吞掉。	在读取配置处进行分类捕获与明确错误消息；将错误上抛或转换为统一错误对象，便于调用方与日志追踪。	高
I/O 超时与健壮性	行9 (load_config)	团队规范要求 I/O 加超时与异常分类；文件 I/O 无原生超时控制，但大文件或网络挂载可能卡顿。	至少做异常分类；限制配置文件大小/行数（读取前检查 stat），指定 encoding='utf-8'；对潜在远程文件场景在调用层增加超时控制（线程/子进程超时或 watchdog）。	中
代码风格/导入	行8 (load_config)	在函数内 import json 违背常规导入置于模块顶部的惯例（PEP8），影响可读性与导入开销。	将 import json 移至文件顶部统一管理。	低
代码风格/空行	行6、14 顶层定义	顶层函数/装饰器间应有两个空行，目前仅一个；与 PEP8 不符。	调整为空行两个，提升可读性与一致性。	低
注释与文档	行6、15（函数）与模块级	缺少 PEP257 规定的模块与函数 docstring；仅有一行注释，无法解释参数约束、返回结构与异常语义。	为模块与每个公开函数补充 docstring，说明参数、返回、异常、并发/副作用；在关键逻辑处补充注释。	中
类型注解	行6、15（函数签名）与 cache	缺少类型注解；团队规范要求关键路径加注解与单元测试。	为函数与全局变量添加类型注解（如 path: str，返回 Dict[str, Any]；list_items 返回 Response）；明确 cache 的键值类型。	中
日志与可观测性	行17-20 (list_items)	异常被吞掉且未记录日志，缺乏故障定位信息。	在捕获的已知异常路径记录结构化日志（请求 id、参数、错误码）；接入监控告警。	中
错误返回规范	行21 (list_items)	无论异常与否总返回 200，客户端难以判定错误；不符合“接口必须返回明确错误”的团队规范。	统一错误响应格式（code/message/details）并返回合适的 HTTP 状态码（4xx/5xx）。	高
数据契约	行18 (list_items)	假定 cache 中每个元素都含 name 字段，缺少结构校验；KeyError 导致不稳定行为。	在进入查询前校验缓存结构或在构建缓存时保证 schema；对异常项进行隔离或过滤，并在日志中统计告警。	中
国际化/一致性	行9 (load_config)	未指定文件编码，跨平台或非 UTF-8 文件可能解码失败。	显式使用 UTF-8 编码，并在文档中约定配置文件编码。	低
架构与可测试性	全局	当前脚本式结构不利于扩展与测试（缺少 app factory、蓝图、配置管理）。	采用应用工厂模式、蓝图拆分路由、配置对象（dev/prod/test 分离），便于注入依赖与单元测试。	中
安全/信息暴露	/items 接口	在无鉴权前提下可能返回整个 cache 的业务数据；若部署到可达网络，存在信息泄露风险。	结合业务需求添加访问控制/速率限制；在默认情况下避免返回全量数据。	中
测试覆盖	全局	缺少单元测试与接口测试，不符合团队“关键路径需加单元测试”。	增加测试用例：load_config 成功/不存在文件/权限不足/JSON 解析失败；list_items 正常/空 q/过长 q/异常项（缺 name）；接口状态码与返回结构校验。	中

补充说明与优化价值简述：

安全与异常分级处理直接降低生产事故与数据泄露风险（高价值，高优先）。
参数校验、空查询策略与分页能显著降低内存与 CPU 压力（高价值）。
去除可变默认参数与消除副作用可提升可维护性，避免隐蔽 Bug（高价值）。
类型注解、文档与测试提升可读性与变更安全性，降低新人上手成本（中高价值）。
架构化（工厂/蓝图）与日志体系为后续功能扩展与问题定位提供基础设施（中高价值）。

问题分类	具体位置	问题描述	改进建议	优先级
HTTP响应规范	write、CreateTask、GetTask	响应未显式设置 Content-Type，未按语义设置状态码；依赖默认行为和类型嗅探，易导致客户端误判	在统一响应助手中显式设置 Content-Type 为 application/json; charset=utf-8，且在写入 Body 前调用 WriteHeader。CreateTask 成功应返回 201（同步创建）或 202（异步受理）；GetTask 未找到返回 404，参数缺失返回 400	高
错误处理	write	json.Marshal 返回值与 w.Write 的错误均被忽略，可能导致静默失败或部分写入	检查并处理 json 编码与写入错误；失败时返回 500 和结构化错误信息，并记录日志；避免部分成功	高
请求体大小限制	CreateTask（decoder := json.NewDecoder(r.Body)）	未限制请求体大小，存在内存放大与DoS风险；注释“parse body without size limit”与团队规范冲突	使用 http.MaxBytesReader 对请求体设置合理上限（如 1MB，可配置）；超限返回 413；在注释中明确限制与依据	高
JSON解码健壮性	CreateTask（decoder.Decode(&t)）	未检查解码错误；未禁止未知字段；可能接受多值或畸形JSON，导致脏数据	检查 Decode 错误并按类型区分返回 400/422；启用 DisallowUnknownFields；确保仅解码单个对象（解码后检查是否还有多余数据）	高
并发与数据竞态	全局变量 tasks；CreateTask 中 goroutine 写，GetTask 读	共享 map 未加锁；后台写入与并发读存在数据竞态与崩溃风险（concurrent map read/write）	使用并发安全策略：为 tasks 增加 sync.RWMutex 或使用 sync.Map；或通过 channel/单线程所有权模型；推荐封装为持有锁的存储结构	高
不可控 goroutine	CreateTask（go func(){...}）	Handler 中启动未受控 goroutine，生命周期不受请求上下文约束，违反团队规范，易泄漏/爆炸性增长	避免在 handler 直接启动 goroutine；若必须后台处理，使用受限的工作池/队列并有背压，且与服务生命周期绑定；或改为同步处理并遵循超时控制	高
上下文/可取消 I/O	CreateTask（time.Sleep）	模拟耗时操作不响应 r.Context 取消信号；无法在客户端断开时尽快终止	使耗时流程可取消：在关键点 select <-r.Context().Done()，或将工作提交到支持 Context 的组件；禁止裸 Sleep，不可取消的等待会浪费资源	高
业务一致性	CreateTask（返回“ok”前未持久化）	先返回成功再异步写入，客户端立即查询可能拿不到数据，语义不清晰	明确语义：要么同步创建后返回 201；要么异步受理返回 202 并提供位置/任务ID以供轮询；在注释与接口文档中说明	中
资源与DoS风险	CreateTask（不限并发 + 不限请求体）	大量请求会创建大量 goroutine 与大内存占用，可能导致资源耗尽	配置请求体上限、工作池大小、队列长度与超时；对突发流量实施限速/熔断；监控关键资源指标	高
返回值正确性	GetTask	未检查 id 是否存在；缺失或未命中时返回零值结构和 200，误导客户端	校验 id 非空；查无此任务返回 404 并附带错误信息；保证错误与状态码一致	中
输入校验	CreateTask	未校验 Task.ID、Task.Name 的必填、长度与格式；未处理重复ID	对字段进行必填与长度限制（避免超长键值）；必要时校验字符集；若 ID 冲突，返回 409；在返回体中提供可读错误原因	中
协议与方法校验	CreateTask、GetTask	未校验 HTTP 方法与请求 Content-Type	限制 CreateTask 仅允许 POST，GetTask 仅允许 GET；不符合返回 405 并给出 Allow；校验 Content-Type 为 application/json，不符返回 415	中
导出符号注释	Task、CreateTask、GetTask	导出类型与函数缺少以名称开头的文档注释，违反 Effective Go	为导出符号添加简洁明晰的注释，说明用途、输入输出与状态码语义（特别是同步/异步行为）	低
注释质量	CreateTask（TODO）	TODO 描述与规范相反，且缺乏明确改进方向	更新 TODO 为“设置请求体上限并处理解码错误”等可执行项；为关键逻辑添加注释说明约束与边界情况	低
命名规范	write	名称过于笼统，不体现语义；不利于代码自解释	重命名为 writeJSON 或 respondJSON，以体现 JSON 响应与状态设置职责；在函数注释中声明行为（设置头/状态码/错误格式）	低
错误响应一致性	全部响应	成功返回结构与错误情况下无统一格式，客户端处理复杂	设计统一的响应包（如包含 code、message、data），并在所有路径复用；提升可观测性与前后端协作效率	低
全局可测试性/可维护性	包级变量 tasks	全局可变状态增加耦合、难以单测与扩展（如换存储）	封装存储为接口与实现（内存实现 + 互斥保护），在 handler 通过依赖注入获取；提升可测试性与可替换性	中
观测与可运维性	全部处理路径	缺少关键错误日志与请求追踪信息，不利于排障	在错误路径记录结构化日志，关联请求ID（从上下文或头中提取）；统计解码失败、超限、404 等指标	低

备注与优化价值说明：

遵循 HTTP 响应规范（状态码、内容类型）能显著降低客户端兼容性问题与调试成本。
加强解码与输入校验从源头阻断脏数据和畸形请求，减少后续故障传播。
并发安全与受控并行是避免线上不稳定与崩溃（concurrent map write/read）的关键，高优先级处理。
上下文可取消与受控后台任务能在超时/断连场景节省资源，提升系统韧性。
封装全局状态与统一错误格式有助于维护与扩展，提升长期可维护性与团队协作效率。

解决的问题

把繁琐、主观、易遗漏的代码评审，变成一份标准化、可执行的改进清单。通过多维度审查（命名与规范、逻辑完整性、注释质量、性能与安全）快速定位问题、明确优先级、给出可落地建议，帮助团队更快通过合并请求、加速迭代、降低线上风险，并为新人提供清晰的成长指引。无需改造流程，输入代码即可获得专业级审查报告，显著提升审查效率与交付质量，促使试用与付费转化。

适用用户

研发团队负责人

用它设定统一审查标准，获取跨项目质量雷达；合并前看问题优先级，集中资源处理高风险项，提升交付稳定性。

后端/前端工程师

提交前自检命名、逻辑与边界，定位性能与安全隐患；减少被打回次数，加快评审通过与上线速度。

代码审查专员/QA

一键生成结构化问题清单，按严重程度分派修复；缩短人工排查时间，提高覆盖率与一致性。

特征总结

• 一键生成可读的审查报告，按优先级归类问题，帮助团队快速锁定最需修复的环节

• 自动对照团队编码规范，检查命名、格式与注释，轻松输出明确的改进清单与示例

• 深入分析逻辑与边界条件，及时发现异常处理缺口，降低上线后隐藏故障风险

• 智能识别性能瓶颈与资源浪费，给出可落地优化路径，帮助显著提升响应与稳定性

• 聚焦常见安全风险模式，提前预警越权、注入与不安全依赖，守住关键合规底线

• 评估模块划分与依赖关系，指出架构不合理处，助力重构与技术债治理更有方向

• 支持按场景快速切换审查重点，适配日常评审、合并前把关与新人代码辅导

• 以业务影响解释每条建议价值，促成团队共识与高效协作，减少反复沟通成本

• 可输入特定关注点与规范约定，精准定制审查视角，避免泛评与无效结论

如何使用购买的提示词模板

1. 直接在外部 Chat 应用中使用

将模板生成的提示词复制粘贴到您常用的 Chat 应用（如 ChatGPT、Claude 等），即可直接对话使用，无需额外开发。适合个人快速体验和轻量使用场景。

2. 发布为 API 接口调用

把提示词模板转化为 API，您的程序可任意修改模板参数，通过接口直接调用，轻松实现自动化与批量处理。适合开发者集成与业务系统嵌入。

3. 在 MCP Client 中配置使用

在 MCP client 中配置对应的 server 地址，让您的 AI 应用自动调用提示词模板。适合高级用户和团队协作，让提示词在不同 AI 工具间无缝衔接。

AI 提示词价格

￥30.00元

先用后买，用好了再付款，超安全！

在线免费用提示词

您购买后可以获得什么

✓

获得完整提示词模板

- 共 653 tokens

- 4 个可调节参数

{ 代码内容 } { 编程语言 } { 审查重点 } { 团队规范 }

✓

获得社区贡献内容的使用权

- 精选社区优质案例，助您快速上手提示词

购买

专业代码审查专家

解决的问题