使用习惯
如果你是第一次用 Agent，这份指南帮你更快得到稳定结果。核心心态是：
把 Aurevoy 当成需要你配置、审查的协作者，而不是一次性的答题机器。
有效循环通常是：给对上下文 → 写清目标 → 让它执行并验证 → 把重复规则沉淀到记忆或 Skill → 再处理下一项。
第一次就做好的事
- 配好模型并确认能发送 — 见 快速开始
- 改文件前先导入项目 — 工作区边界比口头「就在这个仓库」更可靠
- 终端命令默认保持关闭，直到你明确需要且信任当前仓库 — 见 权限与审批
- 用小任务热身 — 只读解释、小范围重命名，比一上来「重写架构」更能校准预期
很多「模型不行」其实是工作目录不对、没写权限预期、模型未启用、搜索 / Embedding 未配。
难任务：先计划再动手
需求模糊、跨多个模块、或你自己也说不清步骤时：
- 明确要求 先不要改文件，只输出计划与风险
- 让它 反问你，把模糊点问完
- 你确认计划后再说「按计划实现」
- 实现后要求它 跑相关检查（测试、typecheck、lint——以仓库实际命令为准）
示例开场：
这是一个模糊需求：……。先不要改代码。
请先列出你需要我确认的问题，再给出分步计划与每步风险。
等我确认后再实现。不要停在「生成完」
完成标准写进目标后，还可以在同一对话要求：
- 写或更新相关测试
- 运行你指定的检查命令
- 用
git diff/ 文件列表说明改了什么 - 自查是否越界改了不该动的路径
你是最终 reviewer。重要仓库在让 Agent 大改前，先有 git 分支或备份。
把重复劳动沉淀下来
| 重复内容 | 放哪里 |
|---|---|
| 语言、回复风格、常用目录 | 长期记忆 |
| 某类任务的固定流程与工具偏好 | Skill |
| 某次任务的临时约束 | 写在当条目标里 |
经验法则：同一段提示纠正第二次，就该进记忆或 Skill，而不是继续手打。
Skill 适合「一个岗位一件事」：发布检查清单、日志归类、某框架的改法。描述里写清做什么、何时用，比堆砌边缘情况更重要。
管好对话本身
- 一条对话 = 一个连贯结果；项目可以有很多对话，不要把全部工作塞进一条
- 方向分叉时用 分支，而不是在原线里反复「其实不是这个意思」
- 上下文过长时用
/compact，并把硬约束重申在较新的消息里 - 预算触顶不是惩罚，是保险丝；调整设置或拆任务，见 设置 与 控制任务
扩展能力时保持克制
- MCP：只加能去掉真实手工步骤的连接；不要一上来接满所有工具
- 知识库：只索引你真正会引用的目录；配好 Embedding 再期待语义检索
- 网页搜索：调研类任务再开；注意 Provider 限流与隐私
常见错误清单
- 提示里塞满长期规则，却不写进记忆 / Skill
- 不告诉它如何构建与测试，又抱怨结果不可验证
- 复杂任务跳过计划
- 一上来放开终端与宽松安全策略
- 未用 git 就在主目录并行乱改
- 流程还不稳定就想「全自动无人值守」
- 一条对话从头用到尾，上下文膨胀后质量崩盘
- 把 Agent 当必须盯着逐步点的宏，而不是可并行审查的产出