编写有效的提示词
提示词是影响回复质量的最大杠杆。 清晰、具体的请求可以为 AI Assistant 提供帮助所需的信息，而含糊不清的请求会让模型猜测你的意图。 这些指南适用于 聊天 和 agent。
什么样的提示词才算有效
强提示词有一些共同习惯。 下方每条都将弱提示与更强的版本配对，便于对比。
- 明确目标和期望结果
描述你的需求以及什么样的结果算好。
较弱： “修复我的代码。”
没有明确目标和症状，模型只能猜测问题及位置。
较好： “
parseDate函数在DateUtils.kt中对像+02:00这样的带偏移时间戳会抛出异常。 修复该问题并添加测试。”- 提供正确的上下文
附上请求所依赖的文件、错误或符号，而不是凭记忆描述它们。
较弱： “为什么登录没用？”
模型无法知晓你指的是哪些文件或哪个错误。
较好： “登录时有效凭据也返回 401。 请参见附加的
AuthService.kt和堆栈跟踪。 期望结果为 200 响应并返回 token。”- 每次请求只处理一个任务
将大型任务拆分成可逐步审核的小步骤。
较弱： “重构项目，添加测试，修复 bug。”
任务范围过大。 Agent 会失去专注，且结果难以审核。
较好： “将
OrderController中的校验逻辑抽取到新的OrderValidator类中。 不要更改行为。”- 先规划大型任务
对于宽泛的任务，让 agent 在修改代码前先提出方案。
较弱： “重写报表模块，以支持 CSV 和 PDF 导出。”
这是一个包含众多决策的广泛变更，直接写代码会导致结果难以把控。
较好： “在修改任何代码前，先为报表模块添加 CSV 和 PDF 导出的方案概要。 我会在你开始之前先审核。”
- 定义“完成”的含义
请明确名称、测试或格式，用于告知模型任务已完成。
较弱： “让它更快些。”
没有指标、没有终点，无法判断改动是否有效。
较好： “
/search接口处理 10,000 行数据大约需要三秒。 请缩短响应时间，保持现有 API，并说明你的变更。”- 列出你的约束条件
明确需要或避免用到的库、文件或约定。
较弱： “加缓存。”
模型可能选用与你项目不符的库和方法。
较好： “使用现有的 Caffeine 配置在
CacheConfig.kt对UserRepository.findById做缓存，TTL 为五分钟。 不要添加新的依赖。”- 让 agent 验证其工作
告诉 agent 如何确认结果。
较弱： “更新代码，我们就完成了。”
没有检查环节，你和 agent 都无法判断更改是否生效。
较好： “完成更改后，运行
./gradlew test并确保构建通过，然后再完成。”- 迭代
审核回复，并发送有针对性的后续问题，而不是重新开始。
较弱： “不对，再试试。”
盲目重试会丢弃接近正确的部分，也无法为模型提供新的参考。
较好： “开头不错。 保留结构，但要处理空输入并返回空列表，而不是抛出异常。”
常见陷阱
即使是很强的提示词，也可能因为发送方式或处理响应的方式而变弱。 下面这些是最常见的错误，以及如何避免。
发送不完整的请求
写完请求后再发送。 将一个问题拆成几条消息，会让模型只拿到部分上下文，导致结果较弱。 草拟多行提示时，可以增加换行反复编辑，内容完整后再发送请求。 你也可以 附加上下文 ，让模型在一次对话中获取全部所需信息。
在无关任务中反复使用同一聊天
聊天中的每条消息都以之前内容为基础。 在同一会话中新增无关任务时，之前的上下文会残留并影响后续回复。 话题变更时请重新开启会话，这样模型才能在清晰环境下工作。
期望对输出有精确控制
提示词能引导回复，但无法让你完全精确掌控内容。 像“用两句话回答”这样的表达虽有帮助，但并非硬性限制。 若对长度或格式有要求，请通过后续对话进行调整，不要期望一次提示就能完全满足。
在未审核的情况下应用变更
即便模型和 agent 表现得很自信，也可能出错。 请像审核队友工作一样，在接受或提交生成代码和 agent 修改前先检查。 每条回应都视为待验证的草稿，而非最终结果。
复用有效的提示词
当某提示词能持续带来良好效果且经常用到时，可将其保存至 提示词库 ，方便下次直接复用。 若有需每次请求都适用的指导，请定义 项目规则或 agent 指令文件 ，而非每次重复写入提示词。