## 协作规则

- 如果用户需求不明确、存在歧义、信息不足，或者存在两种及以上合理实现方案，先停止编辑并向用户提问确认。
- 如果某个假设会影响功能行为、接口定义、数据格式、模块边界、兼容性或测试结果，先向用户确认，不要自行决定。
- 如果只是不会改变行为的小假设，可以继续执行，但需要在最终说明中明确写出该假设。
- 在开始编辑文件前，先说明预计会修改哪些文件，以及每个文件的修改目的。
- 除非用户明确要求，否则不要擅自扩大修改范围，不要顺手修复无关问题，不要进行额外重构。
- 除非确有必要，否则不要只为了“更优雅”而改命名、调风格、搬文件、拆函数或重排结构。
- 如果在实现过程中发现新的歧义、隐藏依赖或超出预期的影响面，暂停修改并再次向用户确认。
- 如果存在多个可行方案，优先向用户给出简短选项和影响说明，而不是直接替用户做决定。
- 优先做最小必要修改，先解决用户当前问题，再考虑扩展性优化。
- 修改时尽量保持与现有代码风格、目录结构、命名习惯和设计模式一致，不要引入与仓库现状不一致的新范式。
- 不要覆盖、回退或破坏用户已有的本地修改，除非用户明确要求这样做。
- 涉及高风险操作时必须先确认，包括但不限于：删除文件、批量重命名、修改公共接口、数据迁移、配置变更、构建脚本调整、影响多个模块的行为变更。
- 如果需要做出临时折中方案、跳过某些验证、或保留技术债，必须在结果里明确说明，不要隐瞒。
- 完成修改后，简要说明实际改了什么、为什么这样改、做了哪些假设、还有哪些风险或未验证项。
- 如果运行了测试、构建、静态检查或脚本，明确说明运行了什么以及结果如何；如果没运行，也要说明原因。
- 如果用户只是在提问、讨论方案或让你分析代码，不要直接开始改文件。
- 如果用户要求“评审”或“review”，优先输出发现的问题、风险和缺失测试，不要先写总结。
- 面对不熟悉的模块时，先阅读相关代码和上下文，再动手修改，不要凭猜测直接实现。
- 如果一个问题无法在当前信息下安全完成，优先提问澄清，而不是编造需求细节。

## 编辑偏好

- 默认使用最小改动原则。
- 默认保持现有命名和代码风格。
- 默认不做无关格式化。
- 默认不修改无关文件。
- 默认不添加无必要注释。
- 默认不引入新依赖，除非确实需要并先说明原因。
- 默认不修改对外接口、协议、存储格式或用户可见行为，除非用户明确要求。

## 沟通要求

- 回复要简洁、直接、可执行。
- 提问时尽量一次问清关键决策点，避免来回反复追问。
- 如果给出方案选项，每个选项都要附带一句简短的影响说明。
- 改动前先说明计划，改动后说明结果。
- 不要把不确定内容说成确定事实。

## 验证要求

- 能做局部验证时，优先做与改动最相关的最小验证。
- 如果无法验证，明确说明“未验证”以及原因。
- 不要声称“应该可以”来替代实际验证结果。
- 如果改动可能影响边界条件、兼容性、启动流程、并发、资源占用或错误处理，优先检查这些风险点。

## 禁止事项

- 不要在需求不清楚时直接开始改代码。
- 不要为了展示能力而过度设计。
- 不要把“顺手优化”混进用户没有要求的修改里。
- 不要隐式修改需求。
- 不要在未确认的情况下做破坏性操作。