我之前带过几个刚入门的同事做同一个项目。同样的 AI 编程工具有人一天写 500 行代码、完成 3 个功能点有人花了半天连一个接口都没调通。区别在哪不是谁更聪明不是谁打字更快——差在问问题的能力。你在网上看到的各种AI 编程效率提升 10 倍的案例大部分不是因为那个工具更厉害而是写案例的人会问问题。反过来那些觉得AI 也没多好用的人十有八九问题出在提问方式上——不是 AI 不行是你没让它行。同一个需求不同的结果先看一个真实的例子。需求很简单用 Python 写一个函数从 Excel 文件里读取客户数据发邮件通知。常规的提问差用 python 读取 excel 文件发邮件。AI 给了你一个最基本的方案用openpyxl读 Excel用smtplib发邮件。代码能用但你一眼就看出来有问题——没有错误处理、邮件格式是纯文本、附件不会加、多个收件人不会区分。你又要修修补补十分钟。好的提问好帮我写一个 Python 脚本 - 从 input.xlsx 读取客户数据列姓名、邮箱、购买产品、金额 - 根据金额是否大于 1000给对应的客户发不同模板的邮件 - 大客户金额1000HTML 邮件含感谢文案增值服务推荐 - 普通客户纯文本邮件含产品使用提示 - 邮件正文要动态替换客户名和产品名 - 发送后输出发送成功的邮箱列表和发送失败的邮箱列表 - 加日志每条日志带时间戳 Excel 可能含空行读取时跳过。邮箱格式不对的也跳过但记录到日志里。结果完全不同。AI 生成了一个接近生产级别的脚本包含了 Excel 读取、邮件模板引擎、收件人过滤、错误处理、日志记录。这就是好问题跟差问题的差距。不是 AI 的差距是你把需求说清楚了的差距。很多人觉得自己问得已经够清楚了但放到 AI 的视角看看全是坑。你问写一个发邮件的函数AI 不会自己去猜你的收件人从哪里来、邮件正文怎么写、用哪个邮箱服务器、附件要不要、出了异常怎么办。它只能选一个最常见的做法。而这个最常见的做法通常不是你想要的因为每个项目的需求都是独特的。好的提问者不是问题多的人而是能把模糊的需求翻译成 AI 能理解的精确指令的人。这个能力本身就是一个程序员的分水岭——顶级工程师能把改个什么东西变成一段无需追问的精确需求普通工程师说半天对方还是不明白。AI 只是把这种差距放大了 10 倍。为什么差问题最坑人差问题更隐蔽的坑在于它给你的答案看起来能用。你执行了那个脚本发现没有错误处理你感觉还行再加几行就好了。但等你把错误处理加完、异常逻辑补上、邮件格式改成 HTML、再加上日志——你花的时间可能比从头写还要多。AI 给的差答案干扰性比没有 AI 还强。ta 给了你一个立刻能用但不够好的答案你花了更多时间在修补这个半成品上。所以我的原则是与其花两分钟给 AI 一个模糊的问题然后花二十分钟修修补补不如花五分钟写一个精确的 prompt让 AI 一次性输出你真正需要的东西。这点时间的投入后面的收益是几十倍的。万能提问公式场景 目标 约束 输出问过上百次问题之后我总结了一个四步提问公式适用于几乎所有 AI 编程工具——Claude Code、Codex、Cursor都一样。第一步给场景告诉 AI 你当前在做什么。让 AI 理解上下文而不是从零猜测。我正在做一个 Spring Boot 3 的后端项目使用 JPA MySQL。 当前在写订单模块的 Service 层。第二步定目标告诉 AI 你需要什么。需求要具体帮我优化一下这种话对 AI 没有任何意义。需要实现一个订单取消功能。用户取消订单后更新订单状态为 CANCELLED、恢复商品库存、如果已支付需要退款。第三步列约束把限制条件说清楚。技术栈、性能要求、安全策略——这些不说 AI 会按一般人的方式去做。- Spring Boot 3.2 Java 17 - 使用 Transactional 保证原子性 - 退款调用外部 PaymentService需要 try-catch 处理失败情况 - 每个操作打日志区分 INFO 和 WARN - 不要用 Autowired 字段注入用构造方法注入第四步定输出告诉 AI 你期望输出的形式。接口签名、文件命名、注释风格——AI 默认给的你不一定满意。输出格式 - 三个文件OrderCancelService.java接口、OrderCancelServiceImpl.java实现、OrderCancelServiceTest.java测试 - 每个公开方法加 JavaDoc - 测试覆盖正常取消、已取消订单再次取消、退款失败这 3 个场景四步连起来就是完整的 prompt【场景】我正在做一个 Spring Boot 3 的后端项目使用 JPA MySQL当前在写订单模块的 Service 层。 【目标】需要实现一个订单取消功能。用户取消后更新订单状态为 CANCELLED、恢复商品库存、如果已支付需退款。 【约束】Spring Boot 3.2 Java 17用 Transactional 保证原子性退款调用 PaymentService 并 try-catch 处理失败。 【输出】三个文件接口、实现、测试。每个方法加 JavaDoc。测试覆盖 3 个场景。如果你希望每次提问都不用写这么多字把项目和工具的通用约束写到 CLAUDE.md参考上一篇文章然后每次都只写目标和特殊约束就够了。不同场景的最佳提问姿势不同的编程场景提问的侧重点不一样。我把常见场景的提问模板列出来。场景一写功能这是最常见的场景。重点是把想要的行为描述清楚不能有歧义。模板实现 [功能名称]需要做什么。 输入xxx输出xxx。 边界情况xxxx的情况应该怎么处理。例子实现一个用户注册接口。 前端传 username、password、email 三个字段。 注册时校验 username 不能重复password 用 bcrypt 加密。 邮箱非必填不填则不发送验证邮件。 注册成功返回 201 和用户信息失败返回 400 和错误原因。场景二修 Bug修 Bug 的关键是复现步骤。没有复现步骤AI 只能猜。模板在 [环境/模块] 遇到了一个 Bug 表现xxxx 触发条件xxxx 期望xxxx 自己排查到的线索xxxx例子在 Chrome 浏览器上用户登录后点击我的订单页面白屏。 控制台报错TypeError: Cannot read properties of undefined (reading length)。 查看 network 发现是 /api/orders 接口返回的数据中 orders 字段为 null。 以前 orders 字段返回的是空数组升级后端接口后改成了 null。场景三重构重构的要点是守住业务不变。告诉 AI 哪些不能改比告诉它怎么改更重要。模板重构 [文件名/模块名]。 目标xxxx提升可读性/性能/可维护性。 限制不能改的——xxxx接口签名/返回格式/业务逻辑。 额外要求重构后跑测试 xxxx。例子重构 OrderService 里的 calculateTotal 方法这个方法有 150 行。 目标拆成不超过 20 行的小方法把价格策略提取到单独的策略类。 限制方法签名不能改输入输出不能变、金额精度不能丢、已有的测试不能挂。场景四调试调试就是告诉 AI 你看到了什么让它判断原因和解决方案。关键是把完整的错误信息和上下文给到 AI。模板[贴错误信息/截图描述] 出问题的代码 [贴代码] 项目配置[技术栈版本] 出现频率必现/偶现例子Caused by: org.hibernate.LazyInitializationException: could not initialize proxy [com.example.order.entity.Order#123] - no Session 代码 Order order orderRepository.findById(123L).orElse(null); System.out.println(order.getItems().size()); // 这一行报错 项目Spring Boot 3.2 JPA MySQL Controller 里直接查 Entity没有启用 Open-in-view踩过的最深的坑——问 AI 优化我觉得自己踩过最深的坑就是问优化。帮我把这段代码优化一下。十个 AI 有九个会给你来一个泛泛的优化建议——用 Stream API 替换 for 循环、把 if-else 改成 switch——这些优化有时候是负优化。Stream 在简单的遍历场景下比 for 循环慢 3 倍改 switch 只是语法层面变了性能根本没提升。所谓的优化没有具体的目标AI 只能给你做语法糖优化而不是真正的性能优化。正确的问法是这段代码在数据量为 10 万条时执行时间约 2 秒。帮我优化目标数据量 10 万时执行时间 500ms。给出具体的指标AI 才知道你到底要优化什么。两个进阶技巧技巧一给 AI 设角色AI 的角色设定对输出质量影响巨大。不同角色的 AI 输出风格完全不一样。你是一个有 10 年经验的 Spring Boot 架构师代码要经过 code review 级别的质量考验。你是一个安全工程师帮我审查这段代码有没有安全漏洞。你是一个刚加入团队的新手开发者请用最简单直接的方式实现这个功能。设角色不只是一个小技巧它让 AI 调用不同的知识分布去完成你的任务。架构师角色关注的是可扩展性和维护性安全角色关注的是输入校验和 SQL 注入新手角色关注的是简单易懂。技巧二反向提问有时候你应该让 AI 来问你。我现在要在 OrderService 里加一个批量订单导出的功能。 但是可能有几个细节我没想到。先列出你需要的所有信息和要考虑的边界情况我来补充。然后你再开始写代码。AI 会问你这几个问题导出的文件格式分页还是全量数据量大时的处理策略文件上传到哪权限控制导出失败的重试机制时区问题很多你没想到的边界情况AI 会先想到。而且这种做法的一个好处是——你在审 AI 的问题不是 AI 在猜你的需求。前者你很容易判断对错后者你很难判断。技巧三用分步确认代替一步到位写单测或者重构这种偏复杂的工作不要指望 AI 一次搞定全部。我自己用的方法是两步确认法第一步让 AI 出计划我要重构 OrderService 的价格计算方法。你先不要改任何代码只出一个重构方案列出你要改的文件、改动的内容范围、每个改动的理由。看完方案后我批注或修改计划然后发给 AI第二步确认计划后执行以上方案我同意了。请按方案执行执行完后跑测试验证。这种先出计划、确认后再执行的做法能让 AI 的错误率降低一半以上。原因很简单——在计划阶段发现错误比执行阶段发现错误容易得多。AI 出的计划你看一眼就知道合不合理而 AI 直接改完的代码你可能要仔细 debug 才发现有问题。技巧四教 AI 你的话术如果你经常跟同一个 AI 配合可以试试建立一套快捷指令。这些快捷指令放在 CLAUDE.md 里每次 AI 都会读到。例如在 CLAUDE.md 里写当我要求写接口时表示要生成完整的 RESTful API 代码包含 Controller、Service、DTO、Validator、单元测试。 当我要求看代码时表示要分析代码质量给出可读性、性能、安全三个维度的评估。 当我要求改 bug时表示要先定位问题根因、列出复现步骤、再修代码。这样你用简短的指令就能让 AI 完成复杂的任务不用每次都把完整需求再写一遍。既省了 token 又减少了你的打字量。说回开头那个问题。为什么同样的工具有人效率翻倍有人半天出不来不是 AI 工具的区别。真正拉开差距的是提需求的能力。你用 AI 的终极目标不是让工具更聪明而是让自己更懒——但懒的前提是你得把需求说清楚。你说清楚了AI 才能替你干你说不清楚你就得替 AI 收拾烂摊子。一个好问题值 10 行代码。一个好架构师值 1000 个差问题。下次用 AI 之前花 30 秒想想这个问题我把需求说清楚了吗 福利时间私信回复「666」我送你一份《AI编程工具大礼包》- Cursor / Copilot / Codex 对比表PDF- 10 个程序员专属 Prompt 模板- AI Debug 万能提问公式