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

让 AI 帮忙写 Java，难点通常不在“生成一段代码”，而在于把需求说清楚、给对上下文，并判断结果是否真的能运行、符合项目约定且没有引入隐患。只给一句“帮我写个订单计算功能”，得到的代码可能语法正确，却漏掉金额精度、边界输入、异常处理和现有系统接口。

本文介绍一套可重复的源码协作方法：先定义任务和约束，再提供必要素材，分阶段生成与审查，最后用编译、测试和代码检查验证结果。示例使用标准 Java 编写金额计算器，不依赖第三方库，可直接编译运行。本文讨论的是如何使用 AI 工具辅助 Java 开发；不同工具的上下文长度、文件读取方式和隐私策略各不相同，具体能力应以所用工具的说明为准。

一、先判断任务是否适合交给 AI

AI 较适合处理目标明确、输入输出可描述、结果可以验证的源码任务，例如：

• 为已有方法补充单元测试或边界测试；
• 根据明确的数据结构编写 DTO、转换器或小型工具类；
• 解释一段 Java 代码的控制流程、异常路径和复杂度；
• 在已说明版本和依赖的前提下，重构重复逻辑；
• 审查代码中可见的空值处理、资源关闭和输入校验问题。

下面这些工作不应仅凭 AI 输出直接上线：认证授权、支付与账务、加密实现、生产数据库迁移、并发控制、隐私数据处理，以及涉及监管或合同义务的业务规则。AI 可以协助列出问题和草拟实现，但必须由熟悉系统的人核对设计，并通过测试、代码审查和适当的安全评估。

还要区分“生成代码”和“验证代码”。模型生成的代码并不天然经过编译，也不代表运行行为、性能和安全性已经验证。对具体版本、第三方库行为或框架配置有疑问时，应检查官方文档或项目源码，不要把模型的回答当作权威版本说明。

二、把需求写成可检查的提示词

有效提示词不是堆砌“高质量、健壮、优雅”等形容词，而是让任务具有明确边界。一个实用结构包括以下内容：

1. 目标：要新增、修改、解释还是审查什么？
2. 环境：JDK 版本、构建工具、框架版本和已有依赖是什么？
3. 输入与输出：参数类型、返回值、格式及允许范围是什么？
4. 业务规则：规则按什么顺序应用？边界值如何处理？
5. 约束：能否新增依赖、修改公共接口或变更数据库结构？
6. 交付物：需要完整文件、补丁、测试、说明，还是只要审查意见？
7. 验证方式：要提供哪些测试命令、测试用例或编译结果？

例如，不要只写“写一个折扣计算方法”。可以改成：

请为 Java 8 项目编写一个无第三方依赖的金额计算类。
输入：非负商品金额、折扣率；金额保留两位小数，采用 HALF_UP。
折扣率范围为 [0, 1]，0 表示不打折，1 表示免费。
返回折后金额，不处理税费、优惠券或多商品合计。
非法输入使用 IllegalArgumentException。
不修改公共 API，不使用 double 计算金额。
请输出完整源码、可运行的 main 示例，以及至少 5 个边界测试。
如果需求有未定义之处，先列出假设，不要自行扩展业务规则。

这个提示词把“折扣”拆成了可以核对的规则，并明确了不在范围内的功能。尤其是“1 表示免费”这类语义，不能指望模型自动猜中。若业务实际上采用“折扣 0.8 表示八折”，就应明确写出。

三、准备素材：给上下文，不是给越多越好

AI 能否贴合项目，常常取决于它是否看到了正确的上下文。按任务提供素材，比一次性粘贴整个仓库更有效。

1. 说明项目环境

提供 JDK 版本、框架和相关依赖版本、构建命令，以及项目使用的代码风格。例如，Java 8 项目不能默认采用较新 JDK 才支持的语法；Spring 项目也不应让 AI 凭空假设某个 Spring Boot 版本或配置方式。

2. 只给相关代码和接口

修改方法时，至少提供该方法所在类的必要部分、调用方、相关 DTO 或接口，以及已有测试。涉及异常约定时，给出项目中的自定义异常定义或相似实现。若只贴孤立方法，AI 可能会猜测字段名称、空值语义和事务边界。

3. 提供可复现的失败信息

报错时，优先提供精简后的编译错误或堆栈、触发输入、预期结果和实际结果。堆栈通常要保留异常类型和相关业务代码行；无关日志可以删掉。不要把“运行失败”当作完整问题描述。

4. 保护敏感信息

向外部工具提交代码前，按组织规则确认数据处理方式和授权范围。默认不要粘贴口令、访问令牌、私钥、生产数据、客户个人信息或可识别内部环境的凭据。需要复现问题时，用虚构值替代，并检查代码片段和日志中是否夹带密钥。删除聊天记录不一定等于数据已从服务端删除，保留与训练策略要以具体工具的政策为准。

四、示例：编写可运行的金额计算器

以下示例假定使用 JDK 8 或更新版本，不需要 Maven、Gradle 或第三方依赖。我们把规则限制在单笔金额与折扣率计算，不扩展到税、优惠叠加或币种转换。金额使用 BigDecimal，避免用二进制浮点数直接表示货币金额。

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

public final class DiscountCalculator {

    private static final BigDecimal ZERO = BigDecimal.ZERO;
    private static final BigDecimal ONE = BigDecimal.ONE;
    private static final int MONEY_SCALE = 2;

    private DiscountCalculator() {
        // Utility class
    }

    public static BigDecimal calculate(
            BigDecimal amount,
            BigDecimal discountRate) {

        Objects.requireNonNull(amount, "amount must not be null");
        Objects.requireNonNull(discountRate, "discountRate must not be null");

        if (amount.compareTo(ZERO) < 0) {
            throw new IllegalArgumentException("amount must not be negative");
        }

        if (discountRate.compareTo(ZERO) < 0
                || discountRate.compareTo(ONE) > 0) {
            throw new IllegalArgumentException(
                    "discountRate must be between 0 and 1");
        }

        BigDecimal multiplier = ONE.subtract(discountRate);
        return amount.multiply(multiplier)
                .setScale(MONEY_SCALE, RoundingMode.HALF_UP);
    }

    public static void main(String[] args) {
        BigDecimal amount = new BigDecimal("19.99");
        BigDecimal rate = new BigDecimal("0.15");

        BigDecimal result = calculate(amount, rate);
        System.out.println(result); // 16.99

        checkEquals(
                new BigDecimal("19.99"),
                calculate(new BigDecimal("19.99"), BigDecimal.ZERO));

        checkEquals(
                new BigDecimal("0.00"),
                calculate(new BigDecimal("19.99"), BigDecimal.ONE));

        checkEquals(
                new BigDecimal("1.01"),
                calculate(new BigDecimal("1.00"), new BigDecimal("0.01")));

        checkThrows(
                () -> calculate(new BigDecimal("-1.00"), BigDecimal.ZERO));

        checkThrows(
                () -> calculate(new BigDecimal("10.00"),
                        new BigDecimal("1.01")));

        System.out.println("All checks passed.");
    }

    private static void checkEquals(BigDecimal expected, BigDecimal actual) {
        if (expected.compareTo(actual) != 0) {
            throw new AssertionError(
                    "Expected " + expected + " but got " + actual);
        }
    }

    private static void checkThrows(Runnable action) {
        try {
            action.run();
        } catch (IllegalArgumentException expected) {
            return;
        }
        throw new AssertionError("Expected IllegalArgumentException");
    }
}

将代码保存为 DiscountCalculator.java，在文件所在目录执行：

javac DiscountCalculator.java
java DiscountCalculator

正常情况下会打印折后金额和 All checks passed.。这组检查使用 Java 自带的断言式辅助方法，不依赖测试框架，因此可以直接运行。正式项目中仍建议使用项目已有的 JUnit 等测试框架，并按构建系统运行测试。

示例里的关键细节

• 用字符串创建金额：new BigDecimal("19.99") 能直接表达十进制数。new BigDecimal(19.99) 会把 double 的二进制近似值带入计算，通常不是想要的十进制结果。
• 用 compareTo 判断数值：BigDecimal.equals 还会比较 scale，因此 1.0 与 1.00 用 equals 判断可能不相等；compareTo 比较数值大小。
• 先定义舍入规则：示例在最终金额处保留两位小数，并采用 HALF_UP。真实结算可能需要其他舍入模式或在每个商品行先舍入，应按业务和法规要求确定，不能直接照搬。
• 显式校验范围：折扣率允许 0 和 1，不允许小于 0 或大于 1。示例只防止空值和非法范围，未规定金额的最大值、币种或小数位数输入策略。

注意，BigDecimal 不会自动替业务决定金额规则。输入是字符串、JSON 数字还是数据库字段，金额最多有几位小数，负数是否代表退款，舍入是在行项目还是汇总后进行，都需要在需求和接口中明确。

五、分阶段提示，比一次要求“写完所有代码”更稳

对稍复杂的任务，可以把协作过程拆成几个小回合。每一步都让结果可检查，降低模型在大段代码中悄悄补入假设的风险。

1. 先梳理规则：要求列出输入、输出、边界、未明确事项和异常语义。暂时不生成代码。
2. 确认设计：检查接口、数据流、状态变化和依赖范围。对不确定规则先补充说明。
3. 生成最小实现：要求只修改指定类或方法，明确是否允许新增文件、依赖和公共 API。
4. 补充测试：覆盖正常值、最小值、最大值、空值、非法值和舍入边界等适用情形。
5. 审查差异：让 AI 按需求逐条核对改动，指出未覆盖的场景和可能的副作用。
6. 本地验证：运行编译、测试、静态检查和必要的集成测试；根据实际错误再提供最小复现信息。

如果要求 AI 修改仓库，提示词应限制改动范围，并要求说明每个文件为什么要改。工具若支持查看差异，应审阅实际 diff，而不是只看文字总结。删除文件、修改构建配置、添加依赖、改变数据库结构等操作要单独核对。

六、如何要求代码审查与细节优化

“帮我优化一下”没有明确目标。优化可能指可读性、运行时间、内存占用、并发能力，也可能意味着 API 行为变化。先限定优化目标和不可改变的行为，再要求给出证据和差异。

例如：

请审查下面的 Java 实现，不要先改代码。
按以下类别输出：
1. 与需求不符或会导致错误的行为；
2. 空值、边界值和异常处理；
3. 线程安全与资源生命周期（仅在相关时）；
4. 可读性或性能建议，并说明依据。
每条注明对应代码位置、触发条件和建议。
不要声称已运行测试；如需更多上下文，请列出具体缺失信息。
最后提供最小修改方案，并说明是否改变公开接口或行为。

审查性能时，代码片段通常不足以证明哪种实现更快。复杂度分析可以帮助筛选问题，但实际性能还受输入规模、JVM、硬件、数据分布和调用方式影响。性能敏感场景应使用可复现基准测试，不要仅凭“看起来少创建了对象”就断定更快。

审查并发代码时，要提供共享状态的范围、线程模型、调用方和一致性要求。只看到一个方法，往往无法判断同步是否充分、事务边界是否正确。类似地，审查资源关闭需要知道资源由谁创建和持有；不能机械地把每个对象都放进 try-with-resources。

七、参数限制和安全边界

AI 工具本身通常存在输入长度、文件数量或上下文容量限制，但具体限制取决于产品、模型、套餐和接入方式，不能用一个固定数字概括所有工具。较长的上下文可能无法完整处理，也可能让关键约束被大量背景淹没。实用做法是只提供与任务相关的文件，先给摘要和入口，再按需补充调用链。

提示词中指定“Java 8”只能约束回答意图，不能保证生成结果一定兼容 Java 8；应使用对应 JDK 实际编译。依赖版本、API 可用性、平台行为和安全配置也都要核对。若代码涉及反射、序列化、文件路径、SQL、命令执行、网络请求或用户输入，应按项目威胁模型审查，不能因为 AI 说“已安全处理”就省略验证。

安全方面，AI 不能替代静态分析、依赖漏洞扫描、渗透测试或人工安全审查。对 AI 生成的代码，至少检查输入校验、权限检查、敏感信息日志、错误信息暴露、资源耗尽风险和第三方依赖来源。采用何种检查工具，应结合项目语言版本、构建方式和组织流程确定。

八、常见错误及修正方式

错误一：只描述功能名，不说明行为

“写一个分页接口”没有页码从 0 还是 1 开始、默认页大小、最大页大小、排序规则和越界处理等信息。修正方法是逐项写明，并标注未定义部分，避免让 AI 默默替业务做决定。

错误二：让 AI 一次完成跨层重构

同时要求修改控制器、服务、数据库、缓存和前端接口，容易产生不一致的字段与假设。先划定改动范围，按层拆分；每一步运行测试，并审阅差异。

错误三：把“能编译”当作“符合需求”

编译只能发现部分语法和类型问题，无法证明业务逻辑正确。为每条业务规则设计测试，尤其验证上下界、空值、重复请求和失败路径。

错误四：遗漏项目现有约定

AI 可能引入项目未使用的库、另一套异常风格或不兼容的 Java 语法。提供同类代码、格式要求和禁止事项，并检查新增依赖及构建文件变化。

错误五：把输出中的示例当成已验证结果

代码注释、测试输出和“已通过测试”的文字，都不能代替真实执行。没有实际运行时，应把结果视为待验证假设。让 AI 明确区分它推断的内容和实际执行的内容。

错误六：输入敏感日志或真实用户数据

为排查问题而直接复制生产堆栈、请求体和配置，可能暴露口令或个人信息。先脱敏，使用合成样例复现；确认工具与组织的使用政策允许后，再提交必要内容。

九、可以复用的 Java 源码任务模板

下面的模板适合新增小功能或修改已有实现。使用前删除不适用项，并用具体事实替换方括号内容。模板不能代替需求评审，但可以减少遗漏。

任务： [新增/修改/解释/审查什么]

项目环境：
- JDK：[版本]
- 框架与依赖：[版本，或说明无额外依赖]
- 构建命令：[例如 mvn test / ./gradlew test]
- 代码风格或项目约定：[相关说明]

上下文：
- 相关文件与接口：[粘贴必要片段]
- 当前问题及复现步骤：[输入、预期、实际、错误信息]
- 已有测试：[相关测试或说明没有]

行为要求：
- 输入：[类型、范围、空值语义]
- 输出：[类型、格式、舍入或排序规则]
- 业务规则：[按顺序列出]
- 异常行为：[异常类型及触发条件]

限制：
- [允许或禁止修改的文件、公共 API、依赖、数据库结构]
- [兼容性、性能或安全要求]
- 不要猜测未定义的业务规则；列出问题或清楚标记假设。

交付：
- [完整文件或最小 diff]
- [测试与边界用例]
- [运行命令]
- 说明每项改动及其影响
- 若未实际运行编译或测试，明确写出未验证。

结语：把 AI 输出纳入工程验证

Java 源码实战的关键，不是寻找一句万能提示词，而是把需求变成可验证的约束，把相关素材准确地交给工具，并把生成、审查、测试和集成分开处理。明确版本、接口、异常和边界，能减少猜测；提供最小上下文，能让回复更聚焦；编译与测试，才能确认代码在真实项目中是否成立。

对于示例金额计算器，真正值得复用的不是某个方法，而是工作方式：先限定业务范围，再规定数值语义，编写可直接运行的检查，并明确哪些规则仍需业务确认。对 AI 生成的任何源码都采用同样标准，才能把它当作开发助手，而不是未经验证的代码来源。