凌晨2点，显示器还亮着。
你盯着屏幕上AI返回的那段代码陷入了沉思——这玩意儿吧，不能说毫不相关，只能说跟你的需求差了十万八千里。你让它写个用户管理的REST API，它给你生成了一个计算器；你让它修复一个空指针异常，它给你重写了一个全新的类。
你忍不住仰天长叹：这AI，怎么就听不懂人话呢？
别急着怪AI。
大概率是你的Prompt没写对。
今天咱们就好好聊聊，怎么写Prompt，才能让OpenCode这类AI编码助手精准理解你的需求，真正帮你干活。
为什么你的AI总是“听不懂人话”？
在正式讲技巧之前，咱们先搞清楚一个问题：AI为什么有时候会答非所问？
大模型到底在“干”什么
先说一个基本认知：大模型本质上是一个超级“文字接龙”。
它并不真正“理解”你的意思，而是在根据训练数据预测——下一个字最可能是什么。
想象一下，你输入“请帮我写一个Java的for循环”，模型会在它的“知识库”里找最可能的后续内容。可能它训练数据里“for (int i=0; i<n; i++)”出现频率最高，于是就给你输出了这个。
听起来有点low？但这就是大模型的工作原理。
Prompt的作用，就是引导这个“接龙”走向正确的方向。
你给出的信息越清晰、越具体，模型就越容易找到正确的“接龙路径”。
AI的“幻觉”与“对齐”问题
除了不会“真正思考”，AI还有一个致命问题：它会一本正经地胡说八道。
这种现象有个高大上的名字叫“幻觉”(Hallucination)。
举个例子，你让它解释一个不存在的API，它可能会煞有介事地给你编一段代码和文档，看起来跟真的一样。这就是“幻觉”——AI在“创造”它不知道的东西。
那“对齐”(Alignment)又是啥？
简单说，就是让AI的输出“对齐”到人类期望的方向。你说“帮我写段代码”，AI理解成“帮我写段正确的代码”——这就是对齐。
Prompt写得好不好，直接决定了AI能不能对齐到你的需求。
根据相关研究报告，使用结构化提示词的开发者比普通用户获得满意结果的概率显著更高，专业设计的提示词可以将AI生成代码的正确率大幅提升。
换句话说：Prompt写对了，效果能翻倍。
好Prompt的四大支柱
说了这么多原理，该上干货了。
一个好的Prompt，必须满足四个条件。我总结了四个关键词，凑成一句话就是：清晰具体完整有序。
1. 清晰 (Clear)
模糊是Prompt的第一杀手。
来看看对比：
❌ 模糊版：
帮我优化一下这段代码
✅ 清晰版：
优化这个方法的性能，减少循环次数
模糊的Prompt就像跟同事说“帮我看一下那个文件”——鬼知道你指的是哪个。
2. 具体 (Specific)
光清晰还不够，还得具体。
❌ 泛泛而谈：
写一个分页功能
✅ 具体到位：
写一个Spring Boot的分页查询接口，使用Pageable参数，返回Page对象，包含totalElements和content字段
具体，意味着你给出了足够的约束条件，AI能精准定位。
3. 完整 (Complete)
有时候不是AI不懂，是你没把话说全。
❌ 信息不全：
写个接口获取用户列表
✅ 完整描述：
基于Spring Boot 3.x，写一个GET /api/users接口，返回用户列表，支持page和size参数，使用JWT认证
必要的背景信息一定要给全：技术栈、参数、返回值、约束条件......
4. 有序 (Organized)
信息要组织有序，AI才能更好地理解。
❌ 混乱堆砌：
那个用户模块的代码帮我改一下，还有测试用例也要，加上日志记录，异常处理
✅ 分条列项：
任务：
1. 修改UserService的getUserById方法，添加空值检查
2. 为上述方法编写单元测试，覆盖正常和异常场景
3. 添加业务日志记录，使用SLF4J
记住这个口诀：清(Clear)楚(Specific)完(Complete)有(Organized)序，首字母连起来就是CSCO。
十大实战技法
重头戏来了。
下面是经过无数开发者验证的Prompt技巧，学会了你也能写出“神级Prompt”。
技法一：结构化Prompt模板
这是最核心的技巧，没有之一。
结构化Prompt就像一份完整的任务说明书，AI照着做就行：
## 角色
你是一个拥有10年经验的Java后端架构师，擅长高并发系统设计和性能优化。
## 任务背景
我们正在开发一个电商平台的用户模块，当前使用单体架构，计划逐步迁移到微服务。
## 具体任务
为用户模块设计REST API规范，包含以下功能：
- 用户注册
- 用户登录（JWT）
- 用户信息查询
- 用户信息修改
## 技术要求
- 框架：Spring Boot 3.x
- 数据库：MySQL
- 认证：JWT
- 遵循RESTful规范
## 输出格式
用Markdown表格输出API清单，包含：接口路径、请求方法、请求参数、响应格式
为什么结构化有效？
因为它把“做什么”、“谁来做”、“做到什么程度”说得明明白白，AI不需要猜。
技法二：角色扮演法
让AI扮演特定角色，能激活它相关的“知识子空间”。
❌ 普通写法：
帮我写一个排序算法
✅ 角色扮演：
你是一个算法工程师，请用Java实现一个高效的排序算法，需要：
1. 时间复杂度优于O(n log n)
2. 适合大规模数据
3. 给出复杂度分析和适用场景
常用角色库：
| 角色 |
适用场景 |
| Java架构师 |
系统设计、技术选型 |
| 代码审查员 |
代码审查、Bug分析 |
| 测试工程师 |
测试用例编写 |
| 技术写手 |
文档撰写 |
进阶玩法：角色+经验+风格
你是一个有15年经验的Java专家，曾在阿里、字节等大厂工作，擅长把复杂概念讲得通俗易懂。请用口语化的方式解释Java虚拟线程的原理。
技法三：任务分解法
复杂任务一口气说完，AI容易晕。拆成小步骤，效果完全不同。
❌ 一步到位：
帮我写一个完整的用户管理系统，包括注册、登录、信息管理、权限控制，还要有单元测试
✅ 分步执行：
Step 1：先设计
分析这个需求，设计数据库表结构，输出ER图和建表SQL
Step 2：再实现
基于刚才的表结构，写User实体类和对应的Repository
Step 3：后测试
为Service层编写单元测试，使用JUnit5和Mockito
为什么分步有效？
因为每一步都有明确的目标，AI不会迷失在复杂的任务海洋里。
技法四：输出格式控制
你希望AI用什么格式输出？直接说。
## 输出要求
1. 用JSON格式返回，包含code、message、data字段
2. 代码用Java编写，使用Spring Boot注解风格
3. 注释要用中文
4. 每个方法不超过50行
常用格式指令：
技法五：上下文引用 (@文件)
OpenCode有一个超级强大的功能：@文件引用。
这个功能允许你直接把项目里的代码“喂”给AI，让它基于真实的上下文工作。
@UserService.java
帮我分析这个类有什么性能问题
@/src/main/java/com/example/config/
检查这个目录下的配置是否符合Spring Boot最佳实践
@的几种用法：
| 语法 |
说明 |
@文件名 |
引用当前目录下的文件 |
@/完整路径 |
引用任意路径的文件 |
@*.java |
引用匹配的所有Java文件 |
@#函数名 |
引用特定函数 |
这个技巧的价值在于：AI不再是无头苍蝇，它能“看”到真实的代码。
技法六：示例引导法 (Few-shot)
给AI一个例子，让它照着学。
这招在代码生成时特别管用。
帮我写一个DTO类，要求：
示例：
```java
@Data
public class UserDTO {
private Long id;
private String name;
private String email;
}
请按照上述格式，为Order订单创建OrderDTO，包含：orderId, orderNo, totalAmount, createTime字段
**为什么有效？**
因为示例提供了一个“锚点”，AI会参照这个模式生成类似的内容。
**正例vs反例**：
```markdown
# 正例（推荐）
请用流畅的技术散文风格撰写，段落之间要有逻辑衔接
# 反例（避免）
不要用晦涩的学术语言，不要有错别字，不要...
少用“不要xxx”，多用“要xxx”。
技法七：约束条件设置
明确告诉AI什么不能做，有时候比告诉它做什么更重要。
## 约束条件
1. 禁止使用Thread.sleep()
2. 异常必须抛出业务异常，不能生吞
3. 方法返回值不能为null
4. 接口必须添加Swagger注解
5. 禁止使用 SELECT * 查询
这些约束就像“安全边界”，让AI在正确的轨道上运行。
技法八：迭代优化技巧
别指望一口吃个胖子。
更好的方式是：先让AI干一版，然后根据结果逐步优化。
第一轮：粗略框架
先帮我写一个接口的骨架，不用具体实现
第二轮：填充细节
现在把业务逻辑填进去，参考UserService的写法
第三轮：完善异常处理
最后添加异常处理和日志记录
这种“渐进式”的方法，比一次性给出一个复杂Prompt效果好得多。
技法九：思维链提示 (Chain of Thought)
让AI“先想后做”，分析推理过程再给答案。
请先分析这个问题，然后给出解决方案：
1. 列出可能导致这个Bug的原因
2. 分析每个原因的概率
3. 给出最可能的修复方案
问题：用户登录后token会过期，但刷新token接口返回401错误
这招特别适合：
技法十：逆向提示法
告诉AI“什么是错的”，让它避开这些坑。
请帮我写一个缓存方案，但要注意：
- 不要使用本地缓存做分布式场景
- 不要把敏感信息存入缓存
- 缓存穿透、击穿、雪崩都要有应对措施
在某些场景下，告诉AI“别做什么”比告诉它“做什么”更有效。
OpenCode专属技巧
说完通用技巧，再聊几个OpenCode特有的玩法。
配合Build/Plan模式使用
OpenCode有两种工作模式：Plan模式和Build模式。
- Plan模式：适合详细规划，Prompt可以写长一点
- Build模式：适合执行具体任务，Prompt可以简洁一点
# Plan模式下
请详细分析这个需求，输出：
1. 技术方案设计
2. 数据库设计
3. 接口设计
4. 风险评估
# Build模式下
帮我把UserController的getUserById方法改成返回UserDTO
利用Skill扩展能力
OpenCode支持自定义Skill，可以把常用的Prompt封装成固定指令。
比如你可以创建一个 review-code Skill：
# review-code
你是一个代码审查专家，请从以下几个维度审查代码：
1. 代码规范
2. 潜在Bug
3. 性能问题
4. 安全风险
然后直接用 /review-code 调用，省时省力。
AGENTS.md项目级配置
AGENTS.md是OpenCode的“项目宪法”，在里面定义的规范会被所有会话遵循。
# 项目规范
## 代码风格
- 使用Spring Boot 3.x
- 遵循阿里巴巴Java开发规约
- 方法必须有Javadoc注释
## 命名规范
- Controller以Controller结尾
- Service以Service结尾
- VO/DTO/BO后缀必须明确
## 异常处理
- 使用自定义业务异常
- 全局异常处理器统一处理
有了AGENTS.md，AI从“陌生人”变成“自己人”。
实战案例
光说不练假把式，来两个真实案例。
案例一：从0到1生成规范代码
需求：生成一个用户管理的REST API
V1 (❌模糊)：
帮我写个用户API
V2 (✅具体)：
帮我写一个Spring Boot的用户增删改查API
V3 (✅✅专业)：
## 角色
你是资深Java后端工程师
## 任务
为用户模块编写REST API，包含：
- POST /api/users - 用户注册
- GET /api/users/{id} - 获取用户信息
- PUT /api/users/{id} - 更新用户信息
- DELETE /api/users/{id} - 删除用户
## 技术要求
- Spring Boot 3.x + MyBatis Plus
- 使用DTO进行数据传输
- 密码使用BCrypt加密存储
- 添加Swagger文档注解
## 输出
每个接口写出Controller、Service、Mapper层代码
效果对比：
| 版本 |
质量 |
可用性 |
| V1 |
低 |
几乎不可用 |
| V2 |
中 |
需要大量修改 |
| V3 |
高 |
基本可直接使用 |
案例二：复杂Bug修复
场景：线上出现订单重复支付问题
分阶段Prompt：
阶段1：分析问题
@OrderService.java
@PaymentController.java
分析可能导致重复支付的代码路径，特别关注：
1. 异步回调处理
2. 前端重试机制
3. 数据库事务边界
阶段2：定位根因
基于以上分析，最可能的问题是什么？请给出代码级别的定位
阶段3：修复方案
请生成修复代码，确保：
1. 使用分布式锁防止并发
2. 添加幂等性校验
3. 返回明确的错误信息
效果：通过这种分阶段的方式，AI不再是“盲人摸象”，而是有条理地帮你解决问题。
常见误区与避坑指南
误区一：指令越多越好
❌ 错误做法：
你必须非常认真地对待这个任务，仔细思考每一步，确保代码高质量，使用最佳实践，遵循所有规范，考虑性能、安全、可维护性...
✅ 正确做法：
用Spring Boot最佳实践实现这个功能
原因：指令太多，AI反而不知道重点在哪。抓住核心要求即可。
误区二：同时扮演多个角色
❌ 错误做法：
你既是Java专家，又是前端大牛，还是数据库优化大师...
✅ 正确做法：
你是一个有10年经验的Java架构师，负责后端设计
原因：角色多了会混乱，一次只定一个主角。
误区三：给太多无关信息
❌ 错误做法：
我今天早上吃了包子，下午喝了个咖啡，晚上想写个功能...
✅ 正确做法：
编写一个定时任务，每天凌晨2点清理7天前的订单数据
原因：无关信息会干扰AI的“注意力”。
误区四：期望太模糊
❌ 错误做法：
帮我优化一下代码，写得好一点
✅ 正确做法：
优化这个方法的性能，目标：单次查询从500ms降到50ms以内
原因：“好一点”是主观的，“50ms”是客观的。
进阶之路
必读资源
如果你想深入学习Prompt工程，以下资源值得一看：
- Prompt Engineering Guide (promptingguide.ai) - 最系统的提示工程教程
- Learn Prompting (learnprompting.org) - 全球首个提示工程指南
实践建议
- 建立自己的Prompt模板库：把常用的Prompt结构保存下来，下次直接套用
- 从今天开始有意识地优化：每次用AI编码助手时，尝试用更好的Prompt
- 记录效果好的Prompt：复盘是进步的最好方式
写在最后
回到开头的问题：为什么AI总是“听不懂人话”？
现在你应该有答案了：不是AI笨，是你没说清楚。
Prompt的本质是人与AI的沟通桥梁。你说得越清楚，AI理解得越精准。
与其花时间抱怨AI不好用，不如花时间研究怎么写好Prompt。
好的Prompt，是AI时代的核心竞争力。
学会了这些技巧，AI编码助手就能从“玩具”变成“神器”。当然，如果你想和更多同行交流Prompt心得或分享实战经验，像云栈社区这样的开发者社区是个不错的选择。去试试吧。
发表于 12 小时前
|
查看: 4|
回复: 0
