先让模型看懂项目，不急着训练
模型写出的代码能够运行，却不一定像你们团队写的：命名可能不同，错误处理可能另起一套，还可能引入项目从未使用的依赖。所谓“教模型项目风格”，通常不是重新训练模型，而是把现有约定和合适的例子交给它，作为本次任务的参考。
第一圈的目标很小：让模型按项目已有写法，完成一处容易检查的修改。先不要要求它整理整个仓库，也不要把所有文件一次塞进去。
挑三类样例，比堆满仓库更有效
从近期维护、团队认可的代码中挑选样例。旧文件可能保留过时写法，不能因为存在于仓库里，就默认值得模仿。
- 一份同类功能：展示目录位置、命名和职责划分。
- 一份错误处理：展示失败如何返回、记录或交给上层。
- 一份相关测试：展示测试命名、数据准备和断言习惯。
提交前删去密钥、客户信息和内部敏感数据。只提供完成任务所需的内容，不要为了说明风格上传完整业务数据。
把“照着写”改成五条明确约定
可以在仓库里保存一份简短的协作说明，写清命名方式、文件位置、错误处理、依赖限制和测试要求。规则应能检查，例如“新增输入校验沿用现有校验函数”，比“代码要优雅”更有用。
再写清冲突时的处理方式：优先遵守当前目录的明确约定；发现样例互相矛盾时先提问，不自行统一全仓库。协作说明不会自动被所有工具读取，需要确认工具的加载方式，必要时主动提供。
用一个小任务完成第一次试跑
第一次可以这样布置任务：“为现有查询增加空输入校验。先阅读同目录实现和相关测试，列出准备遵守的三条约定，再给出最小修改。不要新增依赖，不要调整无关格式；信息不足时先问。”
先检查它复述的规则，再允许修改。这样能尽早发现误解，而不是等整段功能完成后返工。模型声称遵守规范，并不代表实际改动已经符合规范。
检查差异，把反馈变成可复用规则
验收时分开看两件事：功能是否正确，写法是否一致。运行项目已有的测试和格式检查，再查看改动是否出现无关重命名、新依赖或额外抽象。无法运行检查时，应要求模型明确标注，而不是宣称通过。
反馈尽量具体：“这里应复用现有错误类型，请参考同目录的创建流程。”比“不像我们的代码”更容易执行。反复出现的问题，再补进协作说明；一次性的业务要求，留在当前任务里。
更换模型时，继续使用同一份风格清单
需要试用不同模型时，可以考虑本站提供的按量付费模型中转服务，并注册账户开始一次小任务。保持样例、规则和验收条件一致，观察哪个模型更少偏离项目约定。中转服务方便接入，但不能替代上下文准备和人工审查；真正可复用的成果，是仓库里那份清楚、短小、持续更新的风格清单。