DeepSeek代码评审提示词：痛点写作技巧与实战案例

首先明确一点——标题必须精准命中开发者日常调试时反复遭遇的痛点。不是泛泛的“提升代码质量”，而是“空指针检查遗漏”“合并后CI管道断裂”“日志埋点缺失导致故障回溯困难”这类可观测、可复现的具体问题。简而言之，标题应包含可验证的行为与后果，让读者一眼就产生共鸣：“这不就是我刚踩过的坑吗？”

将代码评审中实际遭遇的缺陷直接提炼为提示词标题，效果立竿见影。开发者不会认为你在推销通用模板，而是觉得你在帮助他们解决眼前的具体难题。具体行为、错误类型、实际后果——三者缺一不可。不能只写“加强评审”，而应写“边界校验缺失导致用户输入非法字符串时服务panic”。

用「问题现象+触发场景」组合造标题

操作很简单，分四步走：
第一步：打开最近三次被驳回的PR页面，逐条审视reviewer的驳回理由；
第二步：筛选出至少出现两次的描述，例如“缺少边界校验”“未处理异步超时”“硬编码测试环境域名”；
第三步：将描述与典型上下文拼接，形成“缺少边界校验→用户输入非法字符串时服务panic”这样的短句；
第四步：删除所有修饰词和动词，仅保留名词性主干——最终标题为“非法字符串输入导致panic”。简洁、直接、一目了然。

避免抽象形容词，强制替换为可观察结果

实用的替换原则如下：
“不规范” → 替换为“Git提交信息不含JIRA ID”；
“易出错” → 替换为“调用方未判空时SDK直接抛出NPE”；
“可读性差” → 替换为“同一业务逻辑在3个文件中分散实现且命名不一致”。
注意，凡出现“较”“略”“相对”“可能”等模糊限定词，一律删除。越具体越有力，越模糊越令人困惑。

从线上事故反推标题关键词

更狠的一招：调出最近一次P0级故障的根因报告，直接定位到代码层缺陷那一行。提取“动词+宾语”结构，例如“覆盖了原有缓存key生成逻辑”。然后剥离技术细节，仅保留影响范围，改写为“缓存key重复导致脏数据”。
你会发现，这种从真实事故中提炼出的标题，比凭空想象的“优化缓存设计”精准得多——每个词都能在代码库中找到对应实例，而非凭空捏造的形容词。