AI编程半年后，我发现自己不会写需求了：结构化提示词实战

1. 从“AI 写代码”到“我写不出需求”这件事说起

用了半年 AI 编程工具之后，我最大的感受不是“AI 太强了”，而是“我怎么连话都说不清楚了”。这个结论听起来有点反直觉，但如果你真的把 AI 编程助手当成日常主力工具用过一段时间，大概率会有类似的体会。刚开始接触 AI 编程的时候，我和很多人一样，觉得这东西简直是效率神器：写个 Java 工具类、生成一段 SpringBoot 的 Controller、让它帮我补全一个 Maven 依赖配置，几乎都是秒出结果。那段时间我甚至有点膨胀，觉得以后写代码就是“动动嘴皮子”的事。

但真正把 AI 编程用到实际项目里，尤其是用到有一定复杂度的 SpringBoot 后端项目里，问题就暴露出来了。我发现卡住我的根本不是 AI 的能力上限，而是我自己描述需求的能力下限。我经常对着输入框敲了半天，删了又改，改了又删，最后写出来的提示词连我自己都觉得含糊。AI 给我的代码看起来没问题，跑起来却各种边界情况没覆盖、业务逻辑对不上、参数校验缺失。这时候我才意识到，AI 编程提示词的质量，直接决定了 AI 代码生成的质量，而提示词的质量，本质上就是你对自己需求的理解深度。

这篇文章我想聊的就是这个事：为什么用了半年 AI 编程之后，最先卡住的是“不会写需求”，以及我是怎么一步步把这个问题拆开、找到可操作的改进方法的。内容会围绕 AI 编程、Java、SpringBoot 这些实际场景展开，也会提到飞算 JavaAI、Java 代码生成这类工具的使用体会。不管你是刚接触 AI 编程助手的新手，还是已经用了一段时间但总觉得“差点意思”的开发者，应该都能从里面找到一些能直接抄作业的思路。

2. 为什么 AI 编程最先暴露的是需求表达能力

2.1 AI 编程工具的能力边界到底在哪

很多人对 AI 编程工具有一个误解，觉得它像一个“读心术”机器，你随便说一句它就能懂。实际上，目前主流的 AI 编程助手，包括 Cursor、Windsurf、VS Code Copilot、Trae 这些，它们的核心能力是“基于上下文进行概率性补全和生成”。这句话有点绕，我换个说法：AI 不是真的理解你的业务，它是在根据你给的文字、代码上下文、项目结构，去猜你最可能想要什么。

这就意味着，你给的信息越具体、越结构化、越接近真实业务场景，AI 猜中的概率就越高。反过来，如果你只说“帮我写一个用户管理模块”，AI 只能给你一个最通用、最模板化的实现。它不知道你的用户表有哪些字段、不知道你的权限模型是 RBAC 还是 ABAC、不知道你是用 MyBatis 还是 JPA、不知道你有没有分库分表、不知道你的接口要不要做幂等。这些信息你不说，AI 就只能靠默认假设，而默认假设往往和你的真实需求差得很远。

我踩过的一个典型坑是：让 AI 帮我生成一个 SpringBoot 的订单查询接口，我只说了“根据用户 ID 查询订单列表”。AI 给我的代码确实能跑，但它默认返回了所有订单，没有分页、没有状态过滤、没有时间范围筛选，也没有考虑软删除。结果我拿到代码之后，又花了差不多同样的时间把这些逻辑补回去。后来我算了一笔账：如果我一开始就把需求写清楚，AI 一次生成的代码可能能省我 70% 的时间；但因为需求没写清楚，我实际只省了 30%，剩下的时间都花在“返工”上。

2.2 需求表达不清的三种典型表现

我观察自己和身边同事使用 AI 编程的过程，发现“不会写需求”通常有三种典型表现。

第一种是颗粒度太粗。比如“帮我做一个登录功能”，这句话在人类开发者之间可能还能靠经验补齐，但 AI 不知道你要的是账号密码登录、手机号验证码登录、还是 OAuth 第三方登录。它也不知道你要不要记住登录状态、要不要图形验证码、密码错误几次锁定、Token 用什么方案。颗粒度太粗的需求，AI 只能给你一个“教学示例级别”的代码，离生产可用还有很远。

第二种是缺少约束条件。AI 生成代码时，如果没有约束，它会倾向于选择最常见、最简单的写法。比如你让它写一个 Java 的日期处理工具，它可能直接用SimpleDateFormat，但这个类不是线程安全的。如果你在需求里加上“要求线程安全、使用 Java 8 时间 API”，结果就完全不一样。约束条件包括技术栈版本、性能要求、安全要求、兼容性要求、代码规范要求等等，这些你不说，AI 不会主动帮你考虑。

第三种是没有验收标准。什么叫验收标准？就是“什么样的情况下这个代码算写对了”。比如你说“帮我写一个分页查询”，那验收标准可能是：传入页码和每页条数，返回总记录数和当前页数据；页码小于 1 时按 1 处理；每页条数超过 100 时按 100 处理；排序字段要做白名单校验防止 SQL 注入。这些验收标准如果你不写进需求里，AI 生成的代码大概率是“能跑但不够健壮”的版本。

2.3 从“写代码”到“写需求”的思维转变

用了半年 AI 编程之后，我最大的思维转变是：以前我花 80% 的时间写代码、20% 的时间想需求；现在应该反过来，花 60% 到 70% 的时间把需求想清楚、写清楚，剩下 30% 到 40% 的时间用来审查和调整 AI 生成的代码。

这个转变一开始很难接受，因为写需求不像写代码那样有“即时反馈”。你写代码，跑一下就知道对不对；你写需求，写完了也不知道好不好，只有等 AI 生成代码之后才能验证。但恰恰是这种“延迟反馈”，让很多人不愿意在需求上花时间，结果就是反复返工。

我后来总结了一个简单的判断标准：如果你把需求描述发给一个不熟悉你项目的 Java 开发者，他能不能在不问你任何问题的情况下，写出和你预期差不多的代码？如果答案是“不能”，那这个需求描述对 AI 来说大概率也不够。这个标准虽然有点苛刻，但确实能帮你快速判断自己的需求表达是否到位。

3. 把需求写清楚的核心方法：结构化提示词拆解

3.1 一个可复用的需求描述模板

经过反复试错，我整理了一个自己一直在用的需求描述模板。这个模板不复杂，但能覆盖大部分 Java 和 SpringBoot 场景下的代码生成需求。模板分为六个部分：背景、目标、输入、输出、约束、验收。

背景部分说明这个功能在什么项目里、解决什么问题。比如“这是一个基于 SpringBoot 的校园考勤管理系统，现在需要新增一个教师请假申请接口”。目标部分说明这个接口要做什么。输入部分说明请求参数有哪些、类型是什么、是否必填。输出部分说明返回结构是什么、包含哪些字段。约束部分说明技术栈、版本、性能、安全等要求。验收部分说明什么样算写对了，包括正常情况和边界情况。

我举个例子。以前我可能会写：“帮我写一个请假申请接口。”现在我会写：“这是一个 SpringBoot 项目，使用 MyBatis-Plus 和 MySQL。需要新增一个教师请假申请接口。请求参数包括教师 ID（Long，必填）、请假类型（枚举，必填）、开始时间（LocalDateTime，必填）、结束时间（LocalDateTime，必填）、请假原因（String，必填，最长 500 字）。返回结构包括申请 ID、申请状态、创建时间。约束：使用 POST 请求，路径为 /leave/apply，需要登录校验，开始时间不能晚于结束时间，同一教师同一时间段不能重复申请。验收：正常申请返回成功；开始时间晚于结束时间返回参数错误；重复申请返回业务异常。”

你看，同样一个需求，第二种写法信息量大了很多，AI 生成代码的准确率也会高很多。这个模板不需要你每次都写全，但至少要把输入、输出、约束这三块写清楚，因为这三块是 AI 最容易“猜错”的地方。

3.2 技术栈和版本信息为什么必须写

很多人写 AI 编程提示词的时候，会忽略技术栈和版本信息。但在 Java 和 SpringBoot 生态里，版本差异带来的写法差异非常大。比如 SpringBoot 2.x 和 3.x 在依赖注入、配置属性、Security 配置上都有不少区别。Java 8 和 Java 17 在语言特性上也不一样，比如var关键字、record类型、switch表达式这些。

我遇到过好几次这样的情况：AI 生成的代码用了某个新版本的 API，但我的项目还在用旧版本，结果编译不过。后来我养成了一个习惯，在需求描述的开头就写明：“项目使用 Java 17、SpringBoot 3.2.x、MyBatis-Plus 3.5.x、MySQL 8.0。”这样 AI 生成代码时就会自动避开不兼容的写法。

还有一个容易被忽略的点是构建工具。Maven 和 Gradle 的依赖配置写法完全不同。如果你不说明，AI 可能默认给你 Maven 的 XML 配置，但你的项目用的是 Gradle，那就得手动改。另外，像 Lombok、MapStruct、Hutool 这些常用库，你用不用、用什么版本，也最好提前说明，否则 AI 可能给你生成一堆你不需要的依赖。

3.3 用“输入-处理-输出”模型拆解业务逻辑

对于稍微复杂一点的业务逻辑，我习惯用“输入-处理-输出”模型来拆解。这个模型的好处是强迫你把每个环节都想清楚，而不是笼统地说“帮我实现这个功能”。

输入环节要明确：数据从哪来？是 HTTP 请求、消息队列、定时任务还是其他来源？数据格式是什么？有没有必填校验、格式校验、业务校验？处理环节要明确：核心业务规则是什么？有没有分支逻辑？有没有状态流转？有没有事务要求？输出环节要明确：返回给谁？返回什么结构？成功和失败分别怎么处理？

举个例子，假设你要做一个“将 SpringBoot 项目中的 Word 文档导出功能”，用 Java POI 生成带图表的 Word。如果你只说“帮我用 POI 生成 Word 图表”，AI 可能给你一个很基础的示例。但如果你拆解成：输入是订单数据列表，处理是按月份分组统计销售额，输出是一个包含柱状图的 Word 文档，图表数据来自分组统计结果，文档模板有固定表头。这样 AI 生成的代码就会更贴近你的实际需求。

3.4 约束条件怎么写才不遗漏

约束条件是需求描述里最容易被忽略、但对代码质量影响最大的部分。我一般把约束条件分成五类：技术约束、性能约束、安全约束、兼容约束、规范约束。

技术约束包括框架版本、依赖库、设计模式。性能约束包括响应时间、并发量、数据量级。安全约束包括权限校验、参数校验、SQL 注入防护、敏感数据脱敏。兼容约束包括浏览器兼容、数据库兼容、旧接口兼容。规范约束包括命名规范、注释要求、日志要求、异常处理规范。

这五类约束不需要每次都写全，但你要养成一个习惯：在提交需求之前，快速过一遍这五类，看看有没有遗漏。比如你做的是一个面向公网的接口，那安全约束里的权限校验和参数校验就一定要写。如果你做的是一个内部管理后台的导出功能，那性能约束里的数据量级就要写清楚，否则 AI 可能给你生成一个一次性加载全表数据的代码。

4. 在 Java 和 SpringBoot 场景下的实操演示

4.1 场景设定：一个教师考勤管理系统的接口开发

为了让你更直观地看到“需求写清楚”和“需求写不清楚”的差别，我拿一个具体场景来演示。假设我们在做一个基于 SpringBoot 的校园教职员工考勤管理系统，现在需要开发一个“查询教师月度考勤统计”的接口。

先看需求写得比较粗的版本：“帮我写一个查询教师月度考勤统计的接口。”这个需求发给 AI，它大概率会给你一个最简单的实现：一个 Controller，一个 Service，一个 Mapper，查询某个教师某个月的考勤记录，然后返回一个列表。但这个结果离生产可用还有距离，因为它没有考虑分页、没有考虑统计维度、没有考虑数据权限、没有考虑空数据处理。

再看需求写得比较细的版本。我会这样写：

“项目背景：SpringBoot 3.2 + MyBatis-Plus + MySQL 8.0 的教职员工考勤管理系统。需求目标：新增一个查询教师月度考勤统计的接口。请求参数：教师 ID（Long，必填）、月份（String，格式 yyyy-MM，必填）、部门 ID（Long，可选，用于数据权限过滤）。返回结构：教师 ID、教师姓名、月份、应出勤天数、实际出勤天数、迟到次数、早退次数、请假次数、缺勤次数。业务规则：应出勤天数按当月工作日计算；实际出勤天数按打卡记录去重统计；迟到和早退按打卡时间与排班时间比较；请假和缺勤按请假记录和打卡记录综合判断。约束：GET 请求，路径 /attendance/monthly-stats；需要登录校验；部门 ID 用于数据权限，非管理员只能查本部门；月份格式不合法返回参数错误。验收：正常查询返回统计数据；月份格式错误返回 400；无权限返回 403；无数据返回空统计而不是 null。”

这个版本的信息量大概是第一个版本的十倍，但写起来其实也就多花五到十分钟。而这五到十分钟，能帮你在后续审查和调整 AI 代码时省下至少半小时。

4.2 用飞算 JavaAI 和通用 AI 助手分别生成代码的对比

我同时用飞算 JavaAI 和通用 AI 编程助手跑过上面这个细化后的需求。飞算 JavaAI 这类专门针对 Java 代码生成的工具，优势在于它对 Java 生态的理解更深，生成的代码结构更符合 SpringBoot 项目的常见分层规范，比如 Controller、Service、ServiceImpl、Mapper、Entity、DTO 这些层的划分比较清晰。通用 AI 助手比如 Cursor 和 Copilot，优势在于灵活，能结合你当前打开的文件和项目上下文，但在纯 Java 代码生成的结构规范性上，有时候不如专用工具稳定。

不过不管是哪种工具，我发现一个共同规律：需求描述越结构化，生成结果的可用率越高。用粗需求的时候，两家工具的生成结果都需要大量修改；用细需求的时候，飞算 JavaAI 大概能一次生成 70% 到 80% 可用的代码，通用助手大概能到 60% 到 70%。剩下的部分主要是业务规则里的细节需要人工确认，比如“工作日”的定义是按国家法定节假日还是按公司日历，这种信息 AI 没法猜，必须你告诉它。

这里插一句关于 Java 代码生成工具的选型建议。如果你做的是标准的 SpringBoot 增删改查，飞算 JavaAI 这类工具的效率确实高，因为它内置了很多模板和规范。但如果你做的是偏底层或者偏算法逻辑的代码，通用 AI 助手可能更合适，因为它的推理能力更强，能处理更复杂的逻辑。我的做法是两者结合：标准业务代码用专用工具，复杂逻辑用通用助手。

4.3 生成结果审查：哪些地方 AI 最容易出错

AI 生成代码之后，审查环节非常关键。我总结了几个 AI 在 Java 和 SpringBoot 场景下最容易出错的地方，你可以重点检查。

第一是空值和边界处理。AI 生成的代码经常忘记处理 null、空集合、空字符串。比如查询统计接口，如果某个月没有任何考勤记录，AI 可能直接返回 null，而不是返回一个所有统计字段为 0 的对象。这种问题在测试环境不容易发现，但到了生产环境就会导致前端报错。

第二是事务和并发。AI 生成的代码有时候会忘记加@Transactional，或者在并发场景下没有考虑锁的问题。比如请假申请接口，如果两个请求同时提交同一时间段的请假，没有做唯一约束或者分布式锁，就可能产生重复数据。

第三是SQL 性能和索引。AI 生成的 MyBatis-Plus 查询条件，有时候会写出全表扫描的 SQL，比如在like查询里用%keyword%这种前置模糊匹配。如果你不审查，到了数据量大的时候就会出问题。

第四是安全校验。AI 生成的代码经常缺少权限校验和参数校验。比如查询接口没有校验当前用户是否有权限查看目标教师的数据，或者排序字段没有做白名单校验，导致 SQL 注入风险。

第五是版本兼容。前面提到过，AI 可能用了你项目里没有的依赖或者不兼容的 API。这个在编译阶段就能发现，但如果你用的是动态语言或者脚本，可能要到运行时才发现。

4.4 从生成代码到可上线代码的补全清单

AI 生成的代码要变成可上线的代码，通常还需要补一些东西。我整理了一个自己的补全清单，每次生成代码之后都会过一遍。

• 参数校验：是否加了@Valid或手动校验，必填字段、格式、长度、范围是否覆盖。
• 异常处理：是否统一走了全局异常处理器，业务异常和系统异常是否区分。
• 日志记录：关键入口和出口是否打了日志，日志级别是否合理，敏感信息是否脱敏。
• 权限校验：接口是否有权限注解或手动校验，数据权限是否过滤。
• 事务控制：写操作是否加了事务，事务传播行为是否合理。
• 缓存处理：热点数据是否加了缓存，缓存 key 和过期时间是否合理。
• 幂等处理：重复提交场景是否有幂等控制。
• 单元测试：核心逻辑是否有测试覆盖，边界情况是否测到。

这个清单看起来长，但实际操作起来，熟练之后过一遍也就几分钟。关键是养成习惯，不要直接把 AI 生成的代码提交到主分支。

5. 常见问题与排查技巧实录

5.1 AI 生成的代码跑不起来怎么办

这是最常见的问题。我的排查顺序一般是：先看编译错误，再看依赖问题，再看配置问题，最后看逻辑问题。

编译错误通常是因为版本不兼容或者 API 用错了。这时候把错误信息直接贴回给 AI，让它基于错误信息修正，通常能解决大部分问题。依赖问题常见于 Maven 或 Gradle 配置，AI 可能给你加了一个不存在的依赖版本，或者依赖冲突。这时候用mvn dependency:tree看一下依赖树，找到冲突的包，手动排除。

配置问题常见于 SpringBoot 的application.yml或application.properties。AI 生成的配置项可能和你的项目不一致，比如数据库连接、端口、日志路径。逻辑问题最难排查，因为代码能跑但结果不对。这时候我一般会加日志，把关键中间结果打出来，对比预期值和实际值。

5.2 需求描述写多细才算够

这个问题我被问过很多次。我的答案是：细到“一个不熟悉你项目的 Java 开发者能照着写出差不多的代码”为止。但这个标准有点抽象，我换一个更可操作的说法：如果你把需求描述里的每一句话都当成一个验收点，AI 生成的代码能通过这些验收点，那就算够了。

比如你写“开始时间不能晚于结束时间”，这就是一个验收点。你写“同一教师同一时间段不能重复申请”，这也是一个验收点。你写“返回结构包含申请 ID、状态、创建时间”，这还是一个验收点。验收点越多、越具体，需求描述就越细。当然，也不是越细越好，太细了会限制 AI 的发挥，而且写起来也累。我的经验是，核心业务规则和边界情况一定要写，实现细节可以适当留给 AI。

5.3 怎么判断 AI 生成的代码能不能直接用

我一般用三个标准来判断。第一，能不能通过编译和基本测试。第二，核心业务逻辑对不对。第三，边界情况有没有处理。

第一个标准是底线，编译不过肯定不能用。第二个标准需要你对照需求描述逐条检查，看看 AI 有没有漏掉或者理解错。第三个标准最容易被忽略，但恰恰是生产环境和测试环境的区别所在。我建议你专门准备一组边界测试用例，比如空值、极值、并发、重复提交，每次 AI 生成代码之后都跑一遍。

5.4 提示词写不好，有没有偷懒的办法

有。如果你实在不知道怎么把需求写清楚，可以先用 AI 帮你把需求“问清楚”。具体做法是：你先写一个粗需求，然后让 AI 反问你十个问题，你再根据这些问题补充需求描述。这个方法我经常用，尤其是面对不熟悉的业务领域时。

比如你写“帮我做一个订单导出功能”，AI 可能会问你：导出格式是什么？数据量大概多少？要不要分页导出？要不要异步导出？导出字段有哪些？有没有权限要求？你回答完这些问题，需求描述自然就细化了。这个方法的本质是借助 AI 的提问能力，帮你补全自己没想到的细节。

5.5 常见问题速查表

6. 我个人的一些实操心得

6.1 建立自己的需求描述模板库

我现在维护了一个自己的需求描述模板库，按场景分类，比如“增删改查接口”“统计查询接口”“导出接口”“定时任务”“消息消费”。每次遇到新需求，先找最接近的模板，改一改就能用。这个习惯帮我省了很多时间，也让我写需求的速度越来越快。

模板库不需要很复杂，用 Markdown 文件或者笔记软件就行。关键是持续积累，每次遇到 AI 生成结果不理想的情况，就回头看看是不是需求描述模板里缺了什么东西，然后补进去。时间长了，你的模板库会越来越完善，写需求也会越来越轻松。

6.2 把 AI 当成一个需要详细交接的同事

这个心态转变很重要。很多人把 AI 当成一个“许愿机”，觉得说一句就能得到完美结果。但更准确的心态是：AI 是一个能力很强但完全不熟悉你项目的同事，你需要像给新同事交接工作一样，把背景、目标、输入、输出、约束、验收都说清楚。

一旦你用这个心态去写需求，很多之前觉得“不用说”的东西，你就会主动写进去。比如你会主动说明项目用的框架版本、数据库类型、代码规范、异常处理方式。这些信息对 AI 来说都是“上下文”，上下文越完整，生成结果越靠谱。

6.3 定期复盘 AI 生成代码的返工原因

我每个月会花半小时复盘一下这个月 AI 生成代码的返工原因。大部分返工都可以归到几类：需求描述不清、边界情况没写、技术栈信息缺失、业务规则理解错。找到高频原因之后，我就在需求描述模板里针对性地补充。

比如我发现“边界情况没写”是高频返工原因，就在模板里加了一个“边界情况”小节，强制自己每次都要写。这个复盘习惯看起来有点麻烦，但长期来看，它能让你的 AI 编程效率持续提升，而不是一直停留在“能用但不好用”的阶段。

6.4 不要放弃读代码和写代码的能力

最后说一个可能有点反直觉的观点：用 AI 编程越多，越不能放弃自己读代码和写代码的能力。因为 AI 生成的代码需要你审查，审查的前提是你能看懂。如果你看不懂 AI 生成的代码，你就没法判断它对不对、好不好、有没有隐患。

而且，AI 生成的代码往往是“平均水准”的代码，它不会主动帮你做架构设计、不会帮你做性能优化、不会帮你做安全加固。这些还是需要你自己来判断和决策。所以我的做法是：把 AI 当成一个高效的“代码初稿生成器”，但最终的架构决策、关键逻辑、安全审查，还是自己来。这样既能享受 AI 带来的效率提升，又不会让自己的技术能力退化。

这个内容后续还可以这样扩展：比如针对不同的 AI 编程工具，分别整理一套需求描述的最佳实践；或者针对 SpringBoot 项目里的不同模块，比如安全认证、数据访问、消息队列，分别整理需求描述模板。如果你也在用 AI 编程，不妨从今天开始，试着把下一个需求写得更细一点，看看 AI 生成代码的质量会不会有变化。