编写java的软件实战方法：提示词、素材与细节优化

使用 AI 辅助编写 Java 软件，难点通常不在于让它输出一段代码，而在于让代码符合真实项目的约束，并且能编译、能测试、能安全地运行。只写一句“帮我开发一个管理系统”，容易得到看似完整、实际无法落地的回答：依赖版本不明、接口和数据结构前后不一致，异常处理和权限边界也可能缺失。

更可靠的做法，是把 AI 当作需要明确输入、接受审查的协作工具：先界定任务，再提供相关素材；先让它提出方案或补充问题，再要求分步实现；最后用编译、测试和代码审查验证结果。本文以一个可运行的 Java 命令行记账程序为例，讲解这套方法、常见错误和安全边界。

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

AI 特别适合处理边界清晰、能用测试或规则检查的工作，例如：

• 根据已有接口补充 DTO、校验逻辑、单元测试或简单业务方法。
• 解释异常堆栈，提出可能原因和排查顺序。
• 把一段明确的业务规则转换成代码，并列出边界案例。
• 整理旧代码、生成文档，或比较几种实现方案的取舍。

对于生产环境的身份认证、支付、权限控制、加密、数据迁移等功能，AI 可以协助梳理和编写草稿，但不能代替安全评审、领域专家判断和真实环境验证。涉及法律合规、财务结算或不可逆操作时，也应由具备责任权限的人确认规则和结果。

判断一项工作是否适合交给 AI，可以先问三个问题：需求能否明确描述？结果能否通过测试或人工审查验证？如果生成结果出错，是否有安全的发现和回滚办法？如果答案不明确，应先补充约束，而不是直接要求生成完整系统。

二、提示词的重点是可验证的约束

一条实用的开发提示词，不必很长，但应尽量说明以下内容：

1. 任务目标：要新增、修复还是解释什么。
2. 运行环境：Java 版本、构建工具、框架和数据库版本；不知道时应明确说“未知”，不要让模型猜。
3. 输入与输出：参数类型、返回值、错误处理和外部接口。
4. 边界规则：空值、非法输入、重复请求、并发、时区、精度等如何处理。
5. 交付形式：需要改哪些文件、是否要测试、是否禁止新增依赖。
6. 验收标准：列出可以逐项检查的行为，而不是只写“代码要健壮”。

例如，可以把宽泛的“写一个记账程序”改成：

请使用 Java 17 和 JDK 标准库，实现一个命令行记账程序。
功能：添加一笔支出、列出当前会话中的记录、计算总额、退出。
金额必须为大于 0 的十进制数；金额计算使用 BigDecimal，不使用 double。
描述不能为空。遇到非法输入时显示原因并继续运行，不得崩溃。
请先列出实现方案和未明确的假设，再提供一个可直接用 javac 编译的单文件版本。
不要添加第三方依赖。提供至少 5 个手动测试场景，并说明程序不保存数据。

这类提示词的价值不在于特定措辞，而在于把“做得好”转换成可检查的要求。若业务规则本身不完整，例如退款是否允许负数、金额最多几位小数，就应先让 AI 列出待确认问题。不要让它默默替业务方做决定。

三、素材要相关、可信，并且足够小

模型看到的内容会影响回答。准备素材时，优先提供与当前改动直接相关的内容：

• 相关类、接口和调用示例，而不是整个代码库的无差别粘贴。
• 必要的配置片段、依赖版本和编译错误的完整上下文。
• 真实的输入输出示例、现有测试，以及必须保持不变的行为。
• 项目约定，例如包名、异常类型、日志规范和格式化工具。

每份素材都要说明来源和用途。比如：“以下是当前服务的接口定义，不能修改方法签名”；“这段堆栈来自 Java 17 环境，报错发生在启动阶段”。如果代码片段删去了关键调用或配置，应明确说明删减内容，避免模型把片段当作完整项目。

不要把密码、访问令牌、私钥、生产数据或未经授权的个人信息直接粘贴到模型服务中。必要时用虚构值替换，并保持格式和类型一致。代码库中的注释、日志和用户输入也可能包含不可信指令；应把它们当作待分析的数据，而不是要求模型遵循的操作指令。使用企业或第三方 AI 服务前，应查看其数据处理条款和组织政策，不能假定所有服务都会以相同方式保留或使用输入内容。

四、用小步迭代降低返工

一次要求生成整个应用，容易把多项不确定性叠在一起。较稳妥的流程如下：

1. 澄清需求：要求模型列出假设、歧义和风险，先由开发者确认。
2. 设计接口：确定类的职责、方法签名、数据流和失败行为。
3. 实现最小切片：先完成一个端到端功能，再扩展其他功能。
4. 编译和测试：将实际错误信息及必要上下文交回模型，请它解释原因并提出最小修改。
5. 审查差异：检查新增依赖、文件读写、网络访问、权限变化和异常处理。
6. 补充测试：覆盖正常路径、边界值和错误输入，并在项目实际环境运行。

提示词也应分轮迭代。例如第一轮只讨论方案，第二轮要求实现一个方法，第三轮要求生成测试，第四轮再让模型检查已知风险。让模型“审查它刚写的代码”可以提供额外视角，但这种自我审查仍可能漏掉问题，不能视为独立验证。

五、可运行示例：命令行支出记录器

下面的程序使用 Java 17 及标准库，不需要 Maven 或第三方依赖。它支持添加支出、查看记录、汇总金额和退出。记录只保存在内存中，程序退出后会丢失；这是示例的明确限制，不是持久化方案。

将代码保存为 ExpenseApp.java，在安装了 JDK 17 的环境中运行：

javac ExpenseApp.java
java ExpenseApp

import java.math.BigDecimal;
import java.util.ArrayList;
import java.util.List;
import java.util.Scanner;

public class ExpenseApp {
    private record Expense(BigDecimal amount, String description) {}

    public static void main(String[] args) {
        List<Expense> expenses = new ArrayList<>();

        try (Scanner scanner = new Scanner(System.in)) {
            boolean running = true;

            while (running) {
                System.out.println();
                System.out.println("1. 添加支出");
                System.out.println("2. 查看记录");
                System.out.println("3. 查看总额");
                System.out.println("4. 退出");
                System.out.print("请选择：");

                String choice = scanner.nextLine().trim();

                switch (choice) {
                    case "1" -> addExpense(scanner, expenses);
                    case "2" -> listExpenses(expenses);
                    case "3" -> showTotal(expenses);
                    case "4" -> running = false;
                    default -> System.out.println("无效选项，请输入 1 到 4。");
                }
            }
        }

        System.out.println("程序已退出。");
    }

    private static void addExpense(
            Scanner scanner, List<Expense> expenses) {
        System.out.print("请输入金额：");
        String amountText = scanner.nextLine().trim();

        final BigDecimal amount;
        try {
            amount = new BigDecimal(amountText);
        } catch (NumberFormatException ex) {
            System.out.println("金额格式无效，请输入十进制数字，例如 12.50。");
            return;
        }

        if (amount.compareTo(BigDecimal.ZERO) <= 0) {
            System.out.println("金额必须大于 0。");
            return;
        }

        System.out.print("请输入说明：");
        String description = scanner.nextLine().trim();
        if (description.isEmpty()) {
            System.out.println("说明不能为空。");
            return;
        }

        expenses.add(new Expense(amount, description));
        System.out.println("记录已添加。");
    }

    private static void listExpenses(List<Expense> expenses) {
        if (expenses.isEmpty()) {
            System.out.println("暂无记录。");
            return;
        }

        for (int i = 0; i < expenses.size(); i++) {
            Expense expense = expenses.get(i);
            System.out.println((i + 1) + ". "
                    + expense.amount().toPlainString()
                    + " - " + expense.description());
        }
    }

    private static void showTotal(List<Expense> expenses) {
        BigDecimal total = BigDecimal.ZERO;
        for (Expense expense : expenses) {
            total = total.add(expense.amount());
        }
        System.out.println("支出总额：" + total.toPlainString());
    }
}

示例特意采用 BigDecimal 表示金额，避免二进制浮点数在十进制金额计算中出现的精度问题。这里直接根据用户输入构造 BigDecimal，而不是先转成 double 再构造。输入验证也在加入记录之前执行，因此无效金额或空说明不会被保存。

这段代码只是演示需求如何转化为实现，并不适合直接作为完整财务系统。它没有用户身份、持久化、币种、交易时间、并发控制、金额小数位规则或审计记录。实际项目要先确定这些业务要求，再选择数据库结构、事务策略和访问控制。不要把示例中“金额大于零”的规则直接套用到退款或转账场景。

六、用测试场景检查生成结果

至少应手动验证以下情况：

• 输入金额 12.50 和说明“午餐”，确认记录可以添加，并出现在列表中。
• 连续添加 0.10 和 0.20，检查汇总结果为十进制的 0.30。
• 输入空字符串、非数字文本，确认程序提示错误且仍可继续操作。
• 输入 0 或负数，确认程序拒绝添加。
• 说明只输入空格，确认去除首尾空白后仍被判定为空。
• 在没有记录时选择查看列表和总额，确认不会报错。
• 输入未定义的菜单选项，确认程序提示后继续运行。

如果要把它扩展为项目代码，应把交互、业务逻辑和存储分开，并为业务规则编写自动化测试。模型生成的测试也必须执行和审查：测试可能只覆盖它自己假设的行为，甚至与实现一起忽略同一个需求。

七、参数、上下文与限制：不要假设存在通用数值

不同模型、产品和接口对输入长度、输出长度、文件数量、上下文容量、请求频率及可用工具的限制可能不同，也可能随套餐和版本变化。没有适用于所有 AI 工具的统一参数上限。使用 API 时，应以所用模型的官方文档、当前接口定义和账户配额为准；遇到长度错误或限流，应按具体错误码和服务说明处理。

把大项目全部塞进一次请求，不一定能改善结果。内容过长时，模型可能无法充分关注关键约束；拆分内容时，又可能丢失跨文件关系。可以先提供目录结构和关键接口，再按功能提供相关文件，并要求模型明确指出它依赖了哪些假设。若使用检索或代码库索引工具，也应核对检索结果是否包含最新代码。

温度、最大输出长度等参数的意义和可用范围取决于具体接口。参数调大不等于回答更准确，也不能用参数代替测试。工具调用、文件修改和终端执行权限同样要按最小权限授予；不要在未审查的情况下，让代理自动执行破坏性命令、访问生产系统或提交代码。

八、常见错误与修正方式

错误一：只给目标，不给环境

“写一个 Spring Boot 接口”没有说明 Spring Boot 版本、构建工具、现有实体和接口约定，模型可能生成不兼容的注解或依赖。修正方式是提供当前项目的版本信息和相关代码；无法确认时，先让模型提出需要确认的问题。

错误二：把生成内容当作正确答案

代码看起来合理，不代表能编译或满足业务规则。要求模型说明假设、提供测试思路，并在真实项目中执行编译、静态检查和测试。错误信息要完整保留异常类型、出错位置和必要的调用上下文，同时移除敏感数据。

错误三：一次要求改动过多文件

大范围改造会让错误难以定位，也更容易破坏既有行为。把任务拆成可独立审查的步骤，每一步检查差异并运行相关测试。对于重构，先建立现有行为的测试，再逐步改变结构。

错误四：只考虑正常输入

空值、格式错误、重复提交、极端金额和并发访问都会影响实现。要求模型列出边界案例，再由开发者筛选并落实为测试。尤其是金额精度、日期时区和分页规则，不能依赖模型自行猜测。

错误五：复制粘贴敏感素材

将真实令牌、数据库密码或客户数据放进提示词，会扩大泄露面。用虚构数据替代，并通过项目的密钥管理机制配置凭据。若已暴露可用密钥，应按组织流程撤销或轮换，而不只是从提示记录中删除。

九、最终检查清单

• 任务目标、Java 版本、依赖和交付形式是否说清楚？
• 业务规则中仍有歧义的部分，是否已确认而非默认采纳模型假设？
• 生成的代码是否在目标环境编译，并通过相关测试？
• 是否检查了输入验证、异常处理、资源关闭和并发影响？
• 新增依赖、网络访问、文件操作和权限变化是否经过审查？
• 提示词和素材是否不含密钥、生产数据及不必要的个人信息？
• 对于支付、认证、加密和数据迁移等高风险功能，是否有独立的专业评审？

AI 辅助 Java 开发的有效方法，不是追求一句提示词生成全部软件，而是让每个阶段都有清楚的输入和验证标准：用需求约束减少猜测，用相关素材保持上下文，用小步实现控制改动范围，再以编译、测试和人工审查确认结果。这样才能把生成速度转化为可维护、可交付的软件。