java源码实战方法：提示词、素材与细节优化

让 AI 帮忙写 Java 源码，难点通常不在“生成一段代码”，而在于把需求说准确、把项目上下文交完整，并验证结果是否符合运行环境和业务规则。一个看似简短的请求，例如“写个折扣计算器”，可能涉及金额精度、折扣适用范围、空输入处理、舍入规则和异常约定。遗漏其中任何一项，代码都可能看起来合理，实际却不能直接使用。

本文介绍一套可重复的 Java 源码协作方法：先判断任务适不适合交给模型，再整理提示词与素材，生成代码后通过编译、测试和安全检查验证。文中示例使用 Java 17，代码不依赖第三方库，可复制运行。模型输出应视作待审查的候选实现，而不是自动正确的程序。

一、哪些 Java 任务适合用提示词辅助

提示词适合描述边界明确、输入输出较清楚的工作，尤其适用于：

• 小型功能实现：字符串处理、集合转换、金额计算、日期格式化等。前提是规则和异常行为已经确定。
• 代码解释与重构建议：解释方法调用链、指出重复逻辑、提出拆分方案。重构结果仍需与原有行为对照。
• 测试补充：根据公开方法和既有规则列出正常、边界及异常测试案例。
• 框架用法草稿：生成控制器、DTO 或配置类的初稿。需要提供项目使用的框架版本和现有代码风格。
• 错误定位辅助：结合完整异常栈、相关代码和复现步骤，分析可能原因。单独贴一行错误信息，往往不足以判断根因。

以下任务不适合直接照单全收：涉及资金、权限、身份认证、加密协议、生产数据迁移或高并发行为的实现；必须严格遵循法规、标准或内部安全规范的代码；以及依赖未提供的私有 API、业务规则或运行环境的代码。可以让模型帮助整理方案、列出审查点或起草测试，但关键结论要由熟悉系统的人核实。

二、提示词不是“命令”，而是需求规格

提示词的目标不是尽量写长，而是让结果可检验。建议至少说明以下内容：

1. 目标：需要新增、修改、解释还是排查代码？
2. 运行环境：Java 版本、构建工具、框架版本和可用依赖。不要只写“新版 Java”；若项目运行在 Java 17，就明确写 Java 17。
3. 输入与输出：类型、格式、单位、是否允许为空，以及输出的精度或排序要求。
4. 业务规则：适用条件、计算顺序、舍入方式、优先级等。
5. 边界行为：空集合、负数、超范围值、重复数据和非法输入分别如何处理。
6. 交付形式：只返回方法、完整类、测试代码，还是包含运行命令和设计说明。
7. 禁止事项：例如不新增依赖、不修改公开方法签名、不吞异常、不使用浮点数计算金额。

模糊需求应先澄清，而不是让模型替你猜业务规则。例如“金额四舍五入”并不充分：是对每个商品金额分别舍入，还是对订单总额统一舍入？使用哪种舍入模式？输出保留几位小数？这些选择会改变结果。

一个可复用的提示词框架

你是 Java 开发协作者。请先检查需求是否存在影响实现的歧义；有歧义时先提出问题，不要自行补全业务规则。

目标：
[要实现或修改的功能]

环境：
[Java 版本、框架及版本、构建工具、允许使用的依赖]

输入与输出：
[数据类型、格式、单位、输出约定]

业务规则：
[计算逻辑、适用条件、精度和舍入方式]

边界与异常：
[空值、空集合、范围、重复项、非法输入的处理方式]

兼容性约束：
[不得改变的公开 API、已有行为、代码风格]

交付要求：
[需要哪些文件、测试、运行方式和说明]

请给出可编译的实现，并列出你采用的假设。
不要声称代码已经运行或通过测试；如无法验证，请明确说明。

若任务很小，可以简化框架，但不要删掉会改变实现结果的约束。提示词也不宜把“实现代码”和“输出格式”混为一谈：先说清需要什么代码，再说明如何组织回答，可以减少只得到片段、缺少导入或遗漏测试的情况。

三、素材准备：给足上下文，也要控制范围

模型能利用的信息受对话中实际提供的内容限制。准备素材时，重点是提供与任务直接相关、能说明约束的材料，而不是把整个仓库无差别贴进去。

通常有用的素材

• 相关类及调用方，尤其是方法签名、DTO、接口和异常类型。
• 当前测试和预期结果。测试能展示业务规则，也能暴露“看起来像需求、实际没有定义”的部分。
• 构建文件中与任务有关的 Java、框架和插件版本信息。
• 最小可复现的输入、实际输出、期望输出及完整异常栈。
• 需要保持的命名、包结构和已有代码风格。

粘贴素材前要做脱敏。真实密钥、访问令牌、数据库密码、客户信息和生产数据都不应进入提示词。日志也可能包含邮箱、手机号、内部地址或请求内容；先检查并替换为虚构值。脱敏时保留结构和类型即可，例如把真实令牌替换为 REDACTED_TOKEN，而不是把敏感值原样发送。

代码上下文过少，模型容易虚构不存在的类或方法；上下文过多，重要约束又可能被淹没。适合的做法是从调用点、被调用接口和相关测试开始，逐步补充。若项目有多个模块，应标明代码所属模块和包名，不要只给孤立的文件名。

四、实战：生成一个有明确边界的金额计算器

下面用订单折扣计算作为示例。先把规则写清楚：

• 使用 Java 17，不引入第三方依赖。
• 最多处理 100 个订单项；空列表视为金额为零。
• 商品单价使用非负 BigDecimal，每项数量为 1 到 10000。
• 单价最多两位小数，且不高于 1,000,000.00；折扣率范围为 0 到 1，最多两位小数。
• 先汇总未折扣金额，再计算一次折扣，折扣金额使用 HALF_UP 舍入到两位小数。
• 对非法参数抛出 IllegalArgumentException，不返回看似正常的默认金额。

这些限制是本示例自行定义的业务边界，不是 Java、JVM 或 BigDecimal 的固定上限。真实项目应根据业务、接口契约和资源预算重新确定。尤其要注意，数量上限不等于金额上限：数量、单价和折扣率都需要分别验证。

将以下内容保存为 DiscountCalculator.java：

import java.math.BigDecimal;
import java.math.RoundingMode;
import java.util.List;
import java.util.Objects;

public class DiscountCalculator {
    private static final int MAX_ITEMS = 100;
    private static final int MAX_QUANTITY = 10_000;
    private static final BigDecimal MAX_UNIT_PRICE =
            new BigDecimal("1000000.00");
    private static final BigDecimal ZERO =
            new BigDecimal("0.00");
    private static final BigDecimal ONE =
            new BigDecimal("1.00");

    public record OrderItem(BigDecimal unitPrice, int quantity) {
    }

    public record Result(BigDecimal subtotal, BigDecimal discount,
                         BigDecimal total) {
    }

    public static Result calculate(List<OrderItem> items,
                                   BigDecimal discountRate) {
        Objects.requireNonNull(items, "items must not be null");
        Objects.requireNonNull(discountRate,
                "discountRate must not be null");

        if (items.size() > MAX_ITEMS) {
            throw new IllegalArgumentException(
                    "items must contain at most " + MAX_ITEMS + " entries");
        }
        validateRate(discountRate);

        BigDecimal subtotal = ZERO;
        for (int i = 0; i < items.size(); i++) {
            OrderItem item = Objects.requireNonNull(
                    items.get(i), "items[" + i + "] must not be null");
            validateItem(item, i);

            BigDecimal lineTotal = item.unitPrice()
                    .multiply(BigDecimal.valueOf(item.quantity()));
            subtotal = subtotal.add(lineTotal);
        }

        BigDecimal discount = subtotal.multiply(discountRate)
                .setScale(2, RoundingMode.HALF_UP);
        BigDecimal total = subtotal.subtract(discount)
                .setScale(2, RoundingMode.UNNECESSARY);

        return new Result(subtotal, discount, total);
    }

    private static void validateItem(OrderItem item, int index) {
        BigDecimal price = item.unitPrice();
        if (price == null) {
            throw new IllegalArgumentException(
                    "items[" + index + "].unitPrice must not be null");
        }
        if (price.compareTo(ZERO) < 0
                || price.compareTo(MAX_UNIT_PRICE) > 0) {
            throw new IllegalArgumentException(
                    "items[" + index + "].unitPrice is out of range");
        }
        if (price.scale() > 2) {
            throw new IllegalArgumentException(
                    "items[" + index + "].unitPrice must have at most 2 decimals");
        }
        if (item.quantity() < 1 || item.quantity() > MAX_QUANTITY) {
            throw new IllegalArgumentException(
                    "items[" + index + "].quantity is out of range");
        }
    }

    private static void validateRate(BigDecimal rate) {
        if (rate.compareTo(ZERO) < 0 || rate.compareTo(ONE) > 0) {
            throw new IllegalArgumentException(
                    "discountRate must be between 0 and 1");
        }
        if (rate.scale() > 2) {
            throw new IllegalArgumentException(
                    "discountRate must have at most 2 decimals");
        }
    }

    public static void main(String[] args) {
        List<OrderItem> items = List.of(
                new OrderItem(new BigDecimal("19.90"), 2),
                new OrderItem(new BigDecimal("5.50"), 1));

        Result result = calculate(items, new BigDecimal("0.10"));
        System.out.println("subtotal=" + result.subtotal());
        System.out.println("discount=" + result.discount());
        System.out.println("total=" + result.total());

        if (!new BigDecimal("45.30").equals(result.subtotal())
                || !new BigDecimal("4.53").equals(result.discount())
                || !new BigDecimal("40.77").equals(result.total())) {
            throw new AssertionError("unexpected calculation result");
        }
    }
}

在 JDK 17 环境中，可运行：

javac DiscountCalculator.java
java DiscountCalculator

预期输出为：

subtotal=45.30
discount=4.53
total=40.77

示例中使用字符串构造 BigDecimal，而不是 new BigDecimal(0.1)。后者接收的是二进制浮点数，可能把无法精确表示的浮点误差带入金额计算。这里的舍入规则同样不是普遍适用的财务规范，而是由示例需求指定；上线前应和业务、财务规则保持一致。

如何用提示词让生成结果更可靠

把前述需求与工程素材交给模型后，可要求它分阶段输出，而不是一次要求“写好全部代码”：

请按以下顺序协助实现订单折扣计算器：
1. 先把需求整理成可验证的规则，并指出仍需确认的歧义。
2. 不新增依赖，使用 Java 17 和 BigDecimal。
3. 按已确认规则提供一个可编译的完整类。
4. 补充正常、空输入、边界值和非法参数的测试建议。
5. 说明金额舍入发生在哪一步，以及为什么。
不要擅自把异常改成返回 0，也不要假设代码已在本机运行。

如果模型给出的代码与项目习惯不符，应继续提出具体修改，例如“将入口方法改为实例方法，保持现有接口签名”，而不是笼统地说“优化一下”。每轮只聚焦一类问题，例如先修编译错误，再处理业务边界，最后讨论命名与结构，比较容易判断改动是否引入回归。

五、验证流程：生成代码之后还要做什么

第一步：编译并检查版本

先确认实际 JDK 和构建配置，再编译代码。Java 记录类（record）属于较新的语言特性；如果项目版本低于 Java 16，示例就不能原样编译，需要改用普通类。只在本机用较新 JDK 编译成功，并不能证明项目指定的目标版本也能通过。

Maven 或 Gradle 项目应通过项目自己的构建命令编译，而不只是复制代码到独立文件验证。插件配置、编译目标和依赖版本都可能影响结果。

第二步：逐条核对规则

不要只看输出是否“差不多”。核对空集合、折扣为零、折扣为一、单价上限、数量上限、三位小数单价、负单价、空参数和列表元素为 null 等情况。测试应依据需求规格，而不是反过来把模型生成的实现当作规格。

本示例提供了一个简单的运行断言，用于验证核心结果，但它不等同于完整测试套件。项目中可使用已有的测试框架补充测试；若项目没有测试依赖，也可以通过独立验证代码或构建配置进行测试，不必为了示例随意引入依赖。

第三步：检查 API、异常和副作用

确认生成代码没有悄悄改变公开方法签名、返回值含义或异常约定。检查是否修改了传入集合、写入文件、发出网络请求、读取环境变量，或引入了未要求的依赖。对已有系统来说，副作用和兼容性问题往往比算法本身更容易造成故障。

第四步：检查复杂度和资源边界

对外部输入要考虑输入长度、集合大小、循环次数、嵌套深度和对象创建量。边界应结合接口容量、业务约定与资源预算设计。上面的 100 个订单项只是明确写出的示例限制，不代表适用于所有订单系统的通用值，也不代表 JVM 的参数限制。不要把模型给出的数字当成平台保证。

六、参数限制和安全用途：把能力边界说准确

提示词本身没有统一的固定字数上限

不同模型、产品和 API 对上下文容量、单次输入长度、输出长度及请求大小可能有不同限制，也可能随版本、账户配置或服务端规则变化。不能笼统地声称某个提示词“最多支持固定多少字”。使用具体服务时，应查看当前产品或 API 文档；超出限制时，应按相关文档缩短输入、拆分任务或调整请求。把仓库源码切成多个片段逐次讨论时，要保留文件路径和上下文索引，避免片段之间失去关联。

“上下文窗口”也不等于模型能理解任意长度的项目代码，更不意味着传入的内容都会被同等关注。优先提供最相关的代码、约束和测试结果。若需要模型处理大量文件，应使用经过权限控制的代码检索或项目分析流程，而不是把所有内容拼成一个提示词。

代码生成不是安全证明

模型生成的代码可能存在输入校验不足、越权访问、注入、敏感信息泄露、错误的密码学用法或不安全的默认配置。涉及安全的代码应按项目安全规范进行审查和测试，必要时由专业人员复核。不能仅凭“没有明显问题”或“生成代码已经解释过”就认定安全。

对 SQL，优先使用参数化查询，避免把未经可信处理的数据拼接进语句；对文件操作，应明确允许访问的目录并核查规范化后的路径；对日志，不要记录密码、令牌或敏感个人信息。使用模型处理源码前，也要了解所用服务的隐私、数据留存和访问策略，并遵循组织规定。是否可以发送某段代码，取决于服务条款和组织政策，不能仅由提示词决定。

如果模型提供了看似具体的漏洞编号、标准条款或框架行为，应回到可信的官方文档、项目依赖信息或安全公告核实。模型可能混淆版本、遗漏前置条件，或者把推测写成事实。

七、常见错误及改进方式

• 只写“帮我写 Java 代码”。没有输入、输出和边界规则，模型只能猜。改为提供方法签名、样例和约束。
• 不写运行环境。生成结果可能使用项目不支持的语法或 API。明确 Java 版本、框架版本及构建工具。
• 把样例当成完整规则。一个正常输入通常无法说明空值、重复项或舍入方式。补充边界条件，并标出尚未确定的问题。
• 期待模型自动了解仓库。除非所用工具确实接入了仓库且相关文件可用，否则模型不知道本地代码。提供必要文件或让工具在明确范围内检索。
• 把浮点类型用于精确金额。double 适合许多近似数值计算，但不能直接当作十进制金额的精确表示。金额计算应按业务选择合适的十进制或最小货币单位表示，并明确舍入规则。
• 让代码吞掉异常。用默认值掩盖失败会让调用方无法发现数据问题。应根据接口约定返回明确错误、抛出约定异常，或在边界层进行有记录的转换。
• 只检查“能编译”。编译通过不代表业务逻辑正确、兼容性安全或没有漏洞。还要跑测试，检查边界、权限和副作用。
• 一轮要求完成大型重构。改动范围太大时，难以核对行为变化。先拆成可审查的小步骤，每一步明确允许修改的文件和验收条件。
• 把模型给出的事实当作权威。依赖版本、API 参数上限和安全结论都可能过时。针对具体版本查官方文档并用实际构建验证。

八、把过程沉淀为可复用规范

团队可以为常见任务准备提示词模板，但模板应帮助补充信息，而不是替代需求评审。建议固定记录：目标、项目版本、相关文件、公开 API、业务规则、边界输入、预期测试和禁止修改的区域。若需求有未决项，应显式标为“待确认”，不要让生成代码掩盖不确定性。

代码审查也可以设置清晰的检查项：是否编译、是否覆盖边界、是否符合依赖和版本约束、是否引入副作用、是否暴露敏感信息、是否有足够测试。让 AI 先生成候选实现，再让它按这些检查项做自查，能帮助发现遗漏；但自查仍不能代替独立测试和人工审查，因为同一模型可能在实现和复核时重复同一种错误。

结语

高质量的 Java 源码提示词，本质上是一份简明、可验证的需求说明：定义环境、数据、规则、异常和交付物；准备足够但经过脱敏的项目素材；生成后通过项目构建、测试和安全审查确认结果。模型适合加快草稿生成、解释和案例枚举，不负责替你决定未定义的业务规则，也不能保证代码可编译、正确或安全。

从小而清楚的任务开始，把每次生成都当作一次需要验证的代码变更。随着提示词、测试案例和审查规则逐步沉淀，AI 才能稳定地融入 Java 开发，而不是成为新的、不透明的错误来源。