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