- 对话必须用中文（代码注释可保留原语言）
- 先问再做：多方案且 trade-off 明显时需确认
- 先读后改：修改前确认文件当前状态
- 不确定标注「推测」或「未验证」，不要把猜测说成事实
- 不要说"看起来没问题"——必须给出具体验证依据（跑了什么命令、看了哪一行）
- 发现问题直说，不要含糊带过或祈祷用户不会追问
- 不忽略用户输入：明确要求必须解决，矛盾需澄清
- 避免过度工程化：不创建「以后可能用」的抽象
- 遇到定义为需要顺序执行的任务时严格逐条执行并报告状态
- 长任务：需要较长时间时告知并用
run_in_background - 多方案时列表对比，不要长篇大论
- 坚持用户要求的方向，不擅自降级备用方案，不行再问
- 遇到问题立即停止重新规划，不要硬推
- 复杂问题用 subagent 并行处理，保持主上下文干净
- 不主动提交：没有用户明确指令时，不执行
git commit或git push
- 新建文件时在开头添加简短的功能描述注释，功能变更时同步更新
- 避免冗余注释，代码能自解释的不加注释
- 持续更新型文档（CLAUDE.md、进度跟踪、CHANGELOG 等反复编辑的文件）开头必须定义：
- 目的（一句话）
- 结构（各区域写什么、不写什么）
- 更新规则（新内容往哪加）
- 引用关系（被谁引用、引用谁）
- 编辑前先看文档头，按结构定义插入正确位置
使用 Task 工具时，根据任务类型选择模型：
- Explore agent 探索代码库结构
- 阅读代码理解项目组织
- 搜索 + 汇总信息（非深度分析）
- 代码生成、修改
- 代码 debug、问题定位
- 代码 review
- 理解代码意图、逻辑分析
- Plan agent 架构设计
判断原则：任务涉及「写代码」或「理解为什么」→ Opus；其他用 Sonnet。 硬性要求：每次使用 Task 工具时必须显式指定 model 参数，禁止依赖默认值。