DeepSeek怎么让代码符合项目规范？

想让DeepSeek生成的代码跟你项目规范严丝合缝？光靠一句“写个函数”可不行——模型默认会按通用教科书式Ja va或Python输出，而你的项目可能要求Google Ja va Style、强制Lombok、禁用ArrayList改用Gua va ImmutableList，甚至所有DTO必须实现Serializable并带固定serialVersionUID。说白了，它得知道你项目长什么样，才能写出能被CI放行的代码。

下面这四步，是经过实战验证的硬功夫，缺一不可。

第一步：注入项目级上下文

在prompt开头就得把项目特征亮明，别只说“Ja va项目”这种废话。比如：

你正在维护一个Spring Boot 3.2 + Ja va 17微服务，模块名是order-service，使用Lombok @Data、@Builder，所有DTO必须实现ja va.io.Serializable，serialVersionUID = 1L；禁止使用原始类型数组，集合统一用List而非ArrayList；日志用slf4j，不许出现System.out.println。

这一步漏掉，它默认会写ArrayList list = new ArrayList<>()，你的Checkstyle规则立刻报错，哭都来不及。

第二步：绑定具体文件路径与已有代码

把待插入位置的前后代码原样粘贴进来，用FIM标记包裹：

<|fim▁begin|>public class OrderValidator {
    private final OrderRepository orderRepository;
    private final UserService userService;

    public OrderValidator(OrderRepository orderRepository, UserService userService) {
        this.orderRepository = orderRepository;
        this.userService = userService;
    }

    // 新增方法位置
<|fim▁|>
<|fim▁end|>}

模型看到这个结构，才会生成符合构造器注入风格、参数命名与已有字段一致（比如userService而非userSvc）、访问修饰符为private的方法体。若只说“写个校验方法”，它可能给你整个static工具方法，直接破坏Spring Bean管理契约。

第三步：强制执行团队规范检查项

有两种方法，可以二选一或者组合使用。

请确保生成代码满足以下4项，否则CI会失败：
① 所有public方法必须有Ja vadoc，含@param和@return；
② 方法体内不得出现magic number，金额相关数字必须定义为private static final BigDecimal；
③ 不得调用Thread.sleep()，需改用ScheduledExecutorService；
④ 所有异常捕获后必须打warn日志，格式为“订单校验失败，orderId={}，原因={}”。

# 示例（已通过SonarQube和Checkstyle）
public BigDecimal calculateTotal(Order order) {
    if (order == null) {
        log.warn("订单为空，无法计算总价");
        return BigDecimal.ZERO;
    }
    return order.getItems().stream()
        .map(item -> item.getPrice().multiply(BigDecimal.valueOf(item.getQuantity())))
        .reduce(BigDecimal.ZERO, BigDecimal::add);
}

示例代码必须来自你自己的项目，且刚通过CI——它会模仿你项目代码里的空格、换行、注释密度、缩进习惯，而不是照搬Stack Overflow的写法。

第四步：启用Gradle插件做落地验证

前面三步再漂亮，编译不过、Checkstyle挂掉、SonarQube标红，全白搭。所以必须做这一步：

• 在build.gradle中配置deepseekCheck任务，指定sourceSet为main，classpath与compileJa va完全一致。
• 执行./gradlew deepseekCheck --scan，查看报告中“Style Violation”类问题是否归零。
• 若仍有PEP8或ImportOrder违规，立即回退到第一步，检查是否遗漏了项目特有的import分组规则（比如com.xxx.*必须在ja vax.*之前）。

这一步不做，前面所有提示词优化都是纸上谈兵。代码跑得起来、规范检查全绿，才是真正的“符合项目规范”。