我用 DeepSeek 大概半年多了，主力是 DeepSeek-V3 和 R1。说实话，一开始我也把它当"查资料的工具"用，问点概念、让它写点小函数。后来有一次我让它帮我重构一个 800 行的 Spring Boot Service 类，结果它给我的代码把事务边界全搞错了——我才意识到，问题不在模型，在于我提问的方式。
（实测）同样一个模型，换一种问法，输出质量能差出两个级别。下面这 10 个 Prompt 技巧，都是我在这半年里反复踩坑后总结出来的，不是网上那种"请扮演专家"的套话。每一条我都会告诉你它解决过什么实际问题。
这篇文章是 2026 AI 编程工具与大模型终极指南 的 Cluster 文章，如果你还没看过那篇，建议先看，能帮你把 DeepSeek 放进整个 AI 工具图谱里。
90% 的人用 AI 的方式是：帮我写个用户注册接口。这种问法，模型只能给你一个最通用的、没人会用的模板。
我现在的标准提问结构是：
你是一个有 10 年经验的 Java 后端工程师。
【上下文】我在做一个 Spring Boot 3.2 项目，ORM 用 MyBatis-Plus，
数据库是 MySQL 8.0，用户表 user 已经存在（字段：id, phone, password, created_at）。
【任务】写用户注册接口，要求手机号校验、密码 BCrypt 加密、入库。
【约束】
1. 不要写 Controller，只写 Service + Mapper
2. 校验失败抛业务异常 BizException，不要返回 false
3. 给我关键注释，但别写废话注释
（实测）改成这种结构后，它第一次给的代码就基本能跑，事务、异常处理都在点子上。关键在于约束这一栏——你明确告诉它"不要什么"，比告诉它"要什么"还重要。
这是我觉得最值钱的一个技巧。
很多人直接把需求甩给模型，模型为了"显得能干"就硬答，结果方向偏了还浪费时间。我的做法是在 prompt 末尾加一句：
在开始写代码之前，如果有任何模糊的地方，先列成问题问我，
我回答完你再动手。如果需求已经足够清晰，直接开始。
（实测）上个月我让它设计一个积分系统的接口，加了这句后它反问我"积分是否允许为负"“过期策略是滚动还是固定到期”“并发扣减要不要用乐观锁”——这三个问题我自己一开始都没想全。模型这一反问，等于帮我做了一次需求评审。
观点：模型反问的质量，其实是你需求清晰度的镜子。它问得越具体，说明你的上下文给得越扎实。
DeepSeek 对中文范例的理解比对英文描述还灵敏。当你想要某种特定格式或风格时，别描述，直接给样例：
把下面的日志按这个格式总结：【示例】
时间：14:32
级别：ERROR
组件：HikariPool
问题：连接池耗尽，活跃连接数 10/10
建议：检查是否有连接泄漏，或调大 maximum-pool-size
待处理日志：
14:35:22 [http-nio-8080-exec-3] WARN o.h.engine.jdbc.spi.SqlExceptionHelper - SQL Error: 1205
14:35:22 [http-nio-8080-exec-3] ERROR o.h.engine.jdbc.spi.SqlExceptionHelper - Lock wait timeout exceeded
（实测）给一个范例后，它对后续每条日志的处理都稳定在这个格式，不会跑偏。这招在做日志分析、数据清洗、格式转换时特别好用。
DeepSeek-R1 是带推理过程的，但 V3 默认不会展示思考。遇到复杂逻辑（多表关联、算法题、排查问题），我会显式要求它分步推理：
请一步步分析这个 N+1 查询问题： 1. 先定位是哪段代码触发的 2. 分析为什么会产生 N+1 3. 给出至少两种解决方案并对比优缺点 4. 推荐其中一种，说明理由
把你的分析过程写出来，不要直接跳到结论。
（实测）加不加"把分析过程写出来"这一句，结果差很多。让它写过程，等于强制它把中间步骤算清楚，最后结论才靠谱。直接要结论的话，它容易跳步出错。
当你要让它处理一段长文本（比如一份配置文件、一段报错堆栈）时，一定要用分隔符把内容包起来，否则它会把指令和内容搞混：
请分析下面这段 application.yml 里的配置问题。---配置开始---
spring:
datasource:
url: jdbc:mysql://localhost:3306/db
hikari:
maximum-pool-size: 50
minimum-idle: 50
---配置结束---
要求：指出连接池配置的不合理之处，并说明在什么 QPS 下会出问题。
（实测）用 ---配置开始--- 这种显式标记后，它不会再把配置里的 maximum-pool-size 当成我的指令来理解，分析准确率明显提高。处理报错堆栈、代码片段时我都这么干。
很多时候我不是要它直接给答案，而是要它的输出能被代码处理。这时强制 JSON 格式：
分析下面这条 SQL 的性能问题，输出 JSON，字段： - problem: 核心问题（一句话） - severity: high/medium/low - reason: 为什么慢 - rewrite: 优化后的 SQL - expected_gain: 预期提升SQL: SELECT * FROM orders WHERE DATE(created_at) = '2026-07-10';
只输出 JSON，不要任何额外文字。
（实测）"只输出 JSON，不要任何额外文字"这一句很关键，否则它喜欢在 JSON 前后加一堆解释。配合 Spring Boot 里用 Jackson 解析，能直接把 DeepSeek 的输出塞进对象，实现"AI 出建议 → 代码自动应用"的链路。
生成的代码别直接用，让模型自己先审一遍：
你刚才写的这段代码，现在请你以资深 Code Reviewer 的身份重新审视，检查： 1. 有没有线程安全问题 2. 异常处理是否完整 3. 有没有潜在的 NPE 4. 命名是否清晰
逐条说明发现的问题和修复方案，最后给出修订后的完整代码。
（实测）这个"自我 review"步骤帮我抓出过好几次隐性 bug，尤其并发问题和空指针。模型自己审自己，比它第一次生成时认真得多——因为第一次它在"生产"，第二次它在"挑错"，任务模式不同。
让模型一次性"设计+实现+测试"一个完整模块，几乎必翻车。我的做法是分轮：
每轮都把上一轮的输出作为上下文喂回去（或者用多轮对话续着问）。
（实测）我重构一个订单状态机时，分成 4 轮，最终代码几乎没改就上了线。而之前让它一次写完的版本，我得花两小时返工。观点：人和 AI 的协作方式，应该是"小步快跑"，不是"一句话甩锅"。
DeepSeek 的中文输出有个毛病——爱说"在当今快速发展的XXX时代""如下所示"这种废话。直接在 prompt 里封杀：
要求：
- 不要写"在当今""随着...的发展"这类套话
- 不要用"如下所示"开头
- 不要给无关背景介绍
- 代码块外只保留必要的一两句说明，能不说就不说
（实测）这几条加上以后，输出干净了一大截，直接能贴进文档用。写技术博客、写接口文档时这一招尤其有用。
最后一招是元层面的。当你不知道怎么描述一个需求时，让模型帮你把需求说清楚：
我想让你帮我做一件事：从一堆混乱的 MySQL 慢查询日志里找出最值得优化的 3 条。 但我不知道怎么把这件事描述清楚。
请你先帮我写一段完整的 Prompt（提问词），
让另一个 AI 能准确完成这个任务。
写完后告诉我，这段 Prompt 里哪些设计点是你特别用心的。
（实测）它给的 Prompt 通常比你一开始写的更结构化、更周全。然后你拿这个 Prompt 去问，效果直接上台阶。本质上这是把模型当"需求分析师"用，它写 prompt 的能力往往强于直接干活。
值得，而且比换工具更值得。
这半年我用下来有个明确观点：同一个 DeepSeek，不同问法，产出差距能达到 5-10 倍。很多人抱怨"AI 写的代码不能用"，根子不在模型笨，在于提问太糙。这 10 个技巧不需要任何额外成本，今天就能用上。
如果你只记一条，我建议记第 2 条——让它先反问再回答。这一条改变了我和 AI 协作的整体节奏，从"它瞎猜我瞎改"变成"它帮我澄清需求，我确认后它干活"。
下一篇我会写 程序员必备的 AI Prompt 模板：Java/Spring Boot/MySQL 场景合集，把上面这些技巧固化成可以直接抄的模板。如果你想看 DeepSeek 在编程工具链里的定位，也可以看 Claude Code 深度评测，两个工具我都在用，定位其实不一样。
| # | 技巧 | 一句话 |
|---|---|---|
| 1 | 角色+上下文+约束 | 三件套替代"帮我写个XX" |
| 2 | 让它先反问 | 需求澄清比直接答更值钱 |
| 3 | Few-shot 范例 | 给范例胜过描述 |
| 4 | 思维链 | 复杂问题让它想出声 |
| 5 | 分隔符隔离 | 长文本用标记包起来 |
| 6 | 输出结构化 JSON | 方便程序消费 |
| 7 | 自我校验 | 让它 review 自己的代码 |
| 8 | 任务拆多轮 | 小步快跑别一次性塞满 |
| 9 | 否定式约束 | 封杀套话废话 |
| 10 | 反向 Prompt | 让它帮你写 Prompt |