个人试用顺手，不代表直接放进团队就没问题。代码是否会发送到外部、生成内容如何审查、许可证风险谁负责、日志能不能追踪，这些最好在推广前说清楚。
我们会把自动补全和自动修改分开管理：补全可以宽松些，跨文件修改必须走测试和评审。密钥、生产配置、客户数据所在目录则直接排除。
规则不需要很长，但要让新人知道哪些可以放心用，哪些必须停下来问。
一页纸的团队约定就够起步
先划分三类代码：可以正常使用助手的公开或普通业务代码；需要脱敏后才能使用的内部逻辑；禁止发送到外部服务的密钥、客户数据和核心算法。把目录和文件类型落实到编辑器配置里，不能只靠成员每次记得。供应商的数据保留与训练选项也由管理员统一确认。
生成代码仍按普通代码处理：作者对正确性负责，必须通过测试、静态检查和评审。跨文件修改、依赖升级、数据库迁移等高影响动作，要求助手先给计划和改动范围，再由人确认。不要把“AI 生成”当成可以降低评审标准的来源标签，也不必在每一行纠结作者是谁。
团队可以每月收集几类数据：节省最多的任务、常见错误、误发敏感信息的险情、许可证或安全问题。根据真实记录调整规则，而不是一次写成厚厚的制度。目标是让大家知道什么时候放心用、什么时候停下来核实，以及出了问题由谁处理。