如何写目标
Aurevoy 在提示不完美时也能工作，但清晰的目标会显著提高稳定性——尤其在大仓库、多文件改动或涉及删除 / 联网时。
把每一次发送想成给协作者的任务说明，而不是闲聊开场白。
默认四要素
一个好用的默认结构是四件事（不必机械套模板，但缺一块就容易偏）：
| 要素 | 写什么 | 反例 |
|---|---|---|
| 目标 | 要改变或交付什么 | 「弄一下那个东西」 |
| 上下文 | 相关路径、文件、错误信息、参考文档 | 不说在哪个目录 |
| 约束 | 不要动什么、语言风格、是否允许联网 / 装依赖 | 默认可改全仓库 |
| 完成标准 | 怎样算做完（测试过、列出清单、diff 说明） | 「看着差不多就行」 |
骨架（可复制）
目标：……
上下文：……（路径 / 仓库 / 报错 / 附件）
约束：……（不要删除、只改某目录、使用中文……）
完成标准：……（文件存在、命令通过、输出格式……）弱提示 vs 强提示
偏弱
帮我处理一下图片缺范围、格式、输出位置与是否保留原件。Agent 只能猜。
更好
目标：批量转换截图为 WebP
上下文：目录 ~/Downloads/screenshots，仅处理 .png
约束：质量约 80；输出同目录；不删除原 PNG；不改动其他目录
完成标准：全部转换成功，并在回复里给出转换数量与一两个示例路径偏弱（代码）
加个暗色模式更好
目标：为 packages/web-ui 增加跟随系统的暗色模式开关
上下文：现有样式在 App.css，设置页已有外观相关入口可复用
约束：不要引入新 UI 框架；保持现有浅色为默认；只改 web-ui 与必要 shared 类型
完成标准：切换后主对话与侧栏颜色正确；npm run typecheck 通过；回复附上改动文件列表按场景写
改代码
写清：仓库或项目、相关路径、期望行为、禁止改动的范围、如何验证（命令、页面、用例）。
复杂改动先要求「只读侦查」：
先不要改代码。梳理登录相关调用链，标出入口文件与风险点，给出不超过 8 步的改动计划供我确认。确认计划后再说「按该计划实现」。
文件与整理
写清：源路径、匹配规则、命名 / 覆盖策略、是否保留原件、失败时怎么处理。
调研与写作
写清：问题列表、资料优先级（官方文档优先等）、输出结构（表格字段、标题层级）、语言与篇幅。
若已配置 知识库，写明「根据知识库中关于 X 的文档」，减少胡编。
排错
贴上完整错误信息、复现步骤、已尝试过的操作，以及「不要大范围重构」。
推理深度
输入框可切换推理深度（对支持 thinking / reasoning 的模型生效）：
| 倾向 | 适用 |
|---|---|
| 关 / 低 | 范围小、步骤清楚的任务 |
| 中 | 一般功能改动与排查 |
| 高 / 极高 | 长链路、模糊需求、跨模块推理 |
没有银弹：以任务难度试，而不是永远开最高。
一次一事
- 一条对话对应一个连贯目标；塞满整天杂活会让上下文膨胀、质量下降
- 大任务拆成：侦查 → 实现 → 验证；或完成后新开对话做下一阶段
- 稳定偏好（语言、风格）放进 长期记忆，不要每条消息重复长篇人设
常见错误
- 把本该写进记忆 / Skill 的长期规则每次都堆进提示
- 不说如何验证，导致「改完了」但你无法判断对不对
- 复杂任务不先规划，直接「顺便重构一下」
- 未绑定项目就让它改仓库，路径含糊导致改错位置
- 用一条对话扛整个产品周期，上下文过载后再抱怨模型「忘了」