智能代码质量审查专家

幂简官方

2 浏览

0 试用

0 购买

Nov 12, 2025更新

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

问题分类	具体位置	问题描述	改进建议	优先级
代码风格/PEP8	第3行 `from typing import List, Dict`	未使用的导入，增加代码噪音且影响静态分析质量	删除未使用的导入；或为函数/返回值增加类型注解以提升可读性与可维护性（如参数、返回类型）	低
结构与模块化	第5行 `CACHE`、第8行 `fetch_user_orders(cache=CACHE)`	使用全局可变对象作为默认参数，违背最佳实践，可能导致难以追踪的共享状态与测试隔离问题	将默认参数改为 `None` 并在函数内初始化为模块级缓存；显式传入缓存依赖，或使用受限大小/TTL的缓存组件以提升可控性	高
性能问题	第12–15行 `fetch_user_orders`	无边界的全局缓存可能无限增长，引发内存占用问题；没有过期策略或尺寸限制	引入大小限制（LRU）或TTL；在并发场景考虑线程安全（如锁或线程安全缓存）；在测试中验证缓存命中率与回收策略	中
性能问题	第12行 `time.sleep(0.2)`	人为延迟会在生产环境降低吞吐与响应时间	将延迟移除或只在受控测试/模拟环境下开启（通过配置或依赖注入开关）	中
性能问题	第18–31行 `process_orders`	去重与求和为 O(n^2)，对大规模订单性能不佳；内层循环未提前 `break`，无谓比较	使用 `set`/`dict` 实现 O(n) 去重；如需统计重复项，明确策略；若保留双循环，发现重复后 `break` 提前结束	高
逻辑正确性	第18–31行 `process_orders`	当前逻辑将“存在重复 id 的所有条目”全部排除（而非保留一个唯一项），与注释“duplication removal”含义可能不符	澄清预期：是“保留一个”还是“仅保留严格唯一（只出现一次）”？按需求调整算法并补充测试用例（含有重复 id 的场景）	高
命名规范	第34行 `class reportBuilder`	类名不符合 PEP8（应使用驼峰：CapWords）	重命名为 `ReportBuilder`，统一类命名风格	中
命名规范	第35行构造参数 `Title, userId` 和属性 `self.userId`	参数/属性命名不符合蛇形命名（PEP8）；`userId` 与 `user_id` 混用导致风格不一致	统一使用蛇形命名：`title, user_id`；属性也同步调整，保证一致性	中
可读性/结构	第41–44行 `build` 方法中的 `data["u"]`, `data["t"]`	使用短且不具语义的键名，降低可读性与可维护性	使用具语义的键名（如 `user_id`, `title`, `count`）；如外部协议要求短键，考虑在边界层做映射并在内部使用语义化命名	低
I/O资源管理	第46–48行 `open("temp.txt", "w")`	未使用上下文管理器，异常情况下可能导致文件句柄泄漏；写入同名临时文件存在并发冲突风险	使用 `with open(...) as f` 管理资源；改用安全的临时文件（`tempfile`），并在必要时加锁；明确写入意图并处理异常	高
安全风险	第47行写入首个订单到 `temp.txt`	可能将包含用户标识的敏感信息写入磁盘，不符合“敏感信息不入日志/文件”的要求；且无脱敏处理	明确存储需求，如非必要不写磁盘；必要时进行脱敏/最小化写入；为临时数据使用系统临时目录并限制权限	高
注释与文档	第52行 `main` 注释	缺少函数/模块级 docstring，不符合团队“新增函数含三段式docstring”规范	为每个公开函数/类添加三段式 docstring（概述、参数、返回/异常）；说明复杂逻辑与边界条件	中
日志规范	第59行 `print(...)`	使用 `print` 而非标准 `logging`，不利于生产可观测性与分级控制；可能输出敏感数据（用户ID）	使用 `logging`（按级别：info/debug/error）；对敏感字段进行脱敏或不记录；配置日志格式、handler 与采样策略	高
异常处理	第60–61行 `except Exception: pass`	裸捕获吞掉所有异常，违背“禁止裸except”，导致问题隐蔽、难以排查	捕获具体异常类型；记录错误日志并采取明确的恢复/退出策略；必要时重新抛出或返回错误码	高
依赖与类型注解	多处函数签名	无类型注解，影响静态分析与阅读；导入了 `typing` 却未使用	为函数参数与返回值添加类型注解（如 `List[Dict[str, Any]]`、`Tuple[List[...], float]`）；在工具链中启用静态检查（mypy/ruff）	中
代码风格/PEP8	第5行 `CACHE`	命名以常量风格呈现但对象被频繁修改，易造成误解	若为可变全局状态，使用小写并加前缀（如 `_cache`）或封装到类/模块以明确用途与生命周期	低
结构与模块化	整体	业务与副作用（写文件、打印）耦合在 `build`/`main` 中，降低可测试性	分离纯函数（数据构造）与副作用（I/O、日志）；通过依赖注入传入输出目标；提高单元测试可覆盖性与稳定性	中
测试覆盖率	整体	缺少单元测试，无法验证去重语义、缓存行为与异常路径，难以达成覆盖率≥60%	增加测试：1) 缓存命中/未命中、并发安全；2) `process_orders` 在有/无重复ID时的结果；3) 文件写入/异常处理；4) 日志与敏感信息脱敏	高
边界条件	第40–49行 `build`	未验证 `orders` 类型与内容（例如非列表、元素格式异常）时的行为，可能触发运行时错误	在入口进行类型与必要字段校验；对空列表与不合法项做明确处理与记录	中

补充说明与优化价值：

将 process_orders 从 O(n^2) 优化到 O(n) 可显著提升在订单量大的场景下的性能与资源效率，减少 CPU 占用与延迟。
去除全局可变默认参数与改进缓存策略将提升代码的可预测性、测试隔离性与生产稳定性。
使用标准 logging、规范异常处理与完善 docstring/类型注解有助于提高可维护性、可观测性和团队协作效率。
规范命名与分离副作用能降低认知负担、减少耦合，方便后续重构与单测覆盖达标。
强化敏感信息管控（日志与文件）可降低合规与安全风险。

问题分类	具体位置	问题描述	改进建议	优先级
安全问题	AuthController.login (SQL 拼接)	直接拼接 user_name 和 pwd 生成 SQL，存在严重的 SQL 注入风险，违反团队“SQL用预编译与占位符”的规范。	使用 PreparedStatement 和占位符绑定参数，避免用户输入直接进入 SQL。对输入做基本校验（非空、长度上限）。	高
安全问题	AuthController.login (密码校验)	以明文密码进行数据库比对/存储，未采用强哈希与加盐，违反团队“密码强哈希与加盐”规范。	在持久层使用强密码哈希（如 bcrypt/Argon2/PBKDF2）+随机盐，并只对哈希值进行比对；禁用明文密码存储与传输日志。	高
安全问题	AuthController.login (硬编码连接与凭据)	数据库 URL、用户名、密码硬编码在代码中，存在泄露风险且不利于环境配置管理。	将连接信息外置到配置文件或环境变量，使用安全的配置管理（如 JNDI/DataSource 或配置中心），避免在代码中硬编码敏感信息。	高
安全问题	AuthController.validate (空令牌绕过)	使用 tokenCache.getOrDefault(user, "") 与传入 token 比较；当用户不存在且传入 token 为空字符串时会返回 true，导致认证绕过。	改为显式检查：当缓存中不存在该用户令牌时直接返回 false；避免使用空字符串作为默认值。	高
安全问题	AuthController (令牌管理)	令牌无过期、无撤销机制，且以用户名为键仅支持单令牌，存在会话固定与并发会话覆盖风险。	引入令牌过期（TTL）、撤销机制与多会话支持；可使用带过期策略的缓存（如 Caffeine/Redis）或将会话管理交由专门的会话/身份服务。	高
安全问题	AuthController (日志)	System.out.println 打印“login ok: 用户名”，日志未脱敏且使用标准输出，违反“日志脱敏”和“禁止直接打印异常”规范。	使用统一日志框架（如 SLF4J），记录必要的审计信息并进行脱敏（不输出密码/敏感标识）；日志级别区分 info/error。	中
异常处理	AuthController.login (catch Exception)	广义捕获 Exception 并 e.printStackTrace，既不安全又不利于定位；返回 null 语义不清。	细化异常类型（如 SQLException），通过日志框架记录上下文信息；对外返回明确的错误码/结果对象而非 null。	高
架构/结构	AuthController (职责边界)	Controller 直接进行数据库访问与令牌缓存管理，违反“Controller仅做协调，业务入Service”的团队规范。	引入 AuthService/Repository 层：Controller 仅做请求协调与参数校验，业务逻辑（认证、令牌管理）入 Service，数据访问入 Repository/DAO。	高
并发与可维护性	tokenCache 字段	使用静态可变 HashMap 在多线程环境下不安全（竞态条件），且违反“谨慎使用静态可变状态”的规范；无容量/过期控制可能导致内存涨溢。	避免静态可变状态；如需内存缓存，使用线程安全容器（ConcurrentHashMap）并配合过期策略，或采用外部集中式会话/缓存服务。	高
性能与资源	AuthController.login (连接管理)	每次登录通过 DriverManager 获取连接，缺少连接池管理，影响性能与可扩展性。	使用 DataSource/连接池（如 HikariCP），统一管理数据库连接；在 Service/DAO 层复用并进行健康监控。	中
逻辑问题	AuthController.login (查询结果未使用)	SQL 查询仅加载 id，但结果未在后续逻辑中使用；造成不必要的数据读取。	若仅判断存在性，可改为 SELECT 1/EXISTS 并使用预编译；减少读取字段与网络传输。	低
命名规范	login 方法参数与局部变量	参数 user_name 非驼峰命名；pwd 缩写不清晰；st、rs 可读性偏低。	使用驼峰与语义化命名：userName、password、statement、resultSet；统一风格提升可读性。	低
代码风格	import 语句	使用通配符导入（java.sql.、java.util.），不利于依赖可控与代码审查。	明确列出实际使用的类进行导入，保持依赖最小化与可读性。	低
注释与文档	AuthController.login/validate	公共方法缺少 Javadoc，团队规范要求公共方法需 Javadoc；validate 方法注释不完整。	为公共方法补充 Javadoc（入参、返回值、异常、线程安全/安全注意事项）；注释关键逻辑与边界条件。	中
输入校验	login/validate 入参	未对 user_name、pwd、token 进行非空/长度/字符集校验，可能导致意外行为或放大安全风险。	在 Controller 层进行基本校验与约束（非空、长度、格式），并将业务规则校验置于 Service 层。	中
返回值设计	AuthController.login	登录失败与异常都返回 null，调用方难以区分，易造成错误处理混乱。	使用明确的返回结构（成功令牌/失败原因/错误码），或通过异常/结果枚举区分失败类型。	中

问题分类	具体位置	问题描述	改进建议	优先级
并发安全/逻辑错误	全局变量 results（约第11行）；worker 中写入（约第22行）	多个 goroutine 无同步地写同一个 map，存在数据竞争和“fatal error: concurrent map writes”风险，违反“杜绝数据竞争”团队规范。	取消全局可变状态：将聚合器作为依赖注入到 worker 并使用 sync.Mutex 保护写入；或为每个 worker 使用局部累加 map，主协程在 wg.Wait 后统一归并，降低锁争用；如需并发读写且键分布大，可考虑 sync.Map（读多写少场景）。同时建议在 CI 中开启 -race。	高
错误处理	loadJobs：json.Unmarshal 忽略错误（约第30行）	反序列化错误被忽略，可能导致静默失败或半成品数据，违反“错误向上返回不吞”。	检查并返回 Unmarshal 的错误，必要时包装上下文信息（包含路径/数据长度），避免数据不一致。	高
错误处理	main：loadJobs("jobs.json") 返回错误被忽略（约第35行）	主流程吞掉读取错误，会继续处理空/无效任务集，定位问题困难。	严格处理返回错误：失败时记录结构化日志并中止；或显式选择降级策略（清晰注释说明）。符合 errcheck/gosec(G104) 规则。	高
结构设计	全局变量 results（约第11行）	全局共享可变状态导致模块间强耦合、测试困难（需要全局清理/隔离），不利于可维护性。	将结果聚合职责封装为独立组件/类型，主流程显式持有并传入 worker，便于单测替身（mock）与扩展（例如持久化）。	中
性能/内存	loadJobs：os.ReadFile 全量读文件（约第27行）	大文件时会一次性占用内存并阻塞，缺乏背压与分批处理能力。	使用 json.Decoder 流式解析（io.Reader），结合生产者-消费者管道逐条推送任务；与 channel 缓冲共同形成背压，降低峰值内存。	中
背压/队列设计	jobs := make(chan job, 1000)（约第36行）	缓冲固定为 1000，配合“全部预先推入”模式可能在大任务集下造成生产者阻塞或内存浪费；且代码注释“unbounded use pattern”与实现不一致，易误导。	依据吞吐与资源测量设定容量（与 worker 数量、处理时延匹配）；更可取的是边读边投（流式），而非一次性全部入队；修正注释以避免误解。	中
取消/Context	loadJobs 与 worker	不支持取消，I/O 与耗时操作无法优雅停止，不符合“可取消 context”的团队规范。	为主流程创建 context 并传入：worker 在循环中选择性检查 ctx.Done，及时返回；读取任务时可在分批解析间检查 ctx 并中止。对文件 I/O直接取消有限，但可在逻辑层面实现早停。	中
可读性/API一致性	worker(id int, …) 参数未使用（约第18行）	未使用的参数降低可读性，被 golangci-lint 的 unparam/unused 报告。	若无实际用途，移除该参数；或在日志/度量中使用（并添加注释说明用途）。	低
注释质量	并发与结果聚合逻辑缺少解释；“no lock”与“unbounded use pattern”仅提示问题但无背景	关键并发不变量、错误策略、背压设计未文档化，新成员难以理解与维护。	为 worker 的并发模型、结果聚合策略、错误处理与取消语义添加高层注释；对容量选择与性能权衡给出简要依据。	低
测试质量	项目缺少并发与错误路径测试	无法保障数据竞争、边界与错误路径的稳定性；不符合“测试用 t.Parallel”最佳实践。	添加并发单测：构造多 ID/高并发场景，使用 -race；错误路径测试：文件不存在/JSON 非法；并在表驱动测试中使用 t.Parallel 提升覆盖与速度。	中
监控/可观测性	main 仅打印“done”与结果	缺少处理进度、错误统计与耗时观测，问题定位困难。	引入结构化日志与基本度量（处理数、失败数、耗时分位），在关键路径记录上下文信息。	低
边界校验/健壮性	任务数据未校验（如 Num 负值、ID 为空）	异常输入可能导致结果不符合业务期望或难以排查。	在解析后进行轻量校验（非业务实现，仅做约束说明），明确不变式并在注释中阐述。	低
规范一致性	lint 规则	现有代码会被 golangci-lint 的 errcheck、gosec(G104)、unparam 等规则标记。	在 CI 中启用 golangci-lint 默认规则与 -race，确保错误与并发问题在合并前被识别；对被豁免项提供注释与理由。	中

解决的问题

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

适用用户

研发团队负责人

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

后端/前端工程师

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

代码审查专员/QA

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

特征总结

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

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

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

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

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

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

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

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

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

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

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

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

2. 发布为 API 接口调用

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

3. 在 MCP Client 中配置使用

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

AI 提示词价格

￥20.00元

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

在线免费用提示词

您购买后可以获得什么

✓

获得完整提示词模板

- 共 653 tokens

- 4 个可调节参数

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

✓

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

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

购买

智能代码质量审查专家

解决的问题