AI 使用礼仪

用不用 AI 不是问题，隐瞒用了哪一部分才是。披露不是忏悔，是让对方知道该用多大力度审查。

披露的粒度

「整段生成」和「只用来润色」的风险完全不同。前者需要逐行核对逻辑，后者只需要看表达是否走样。

场景	披露方式
提交	PR 描述或 Co-authored-by trailer
PR	说明哪些文件由 AI 起草
文档	注明初稿或校对来源
面试测评	事先确认是否允许

GitHub 会识别 Co-authored-by: trailer 并标注共同作者，但邮箱需要对应账号。记录 AI 使用更适合写在 PR 描述里，能说清具体范围。

团队与合规

• 项目可能有比公司更严格的 AI 政策
• 合规、数据驻留、出口管制都可能限制模型选择
• 不要把内部代码、密钥、客户数据贴进公共模型
• 生成代码的许可证来源要核实，避免把不明来源的片段带进仓库
• 不确定就先问，不要先用了再解释
• 明确禁止时不要偷偷用，被发现的代价远大于省下的时间

违规通常不是技术问题，而是信任问题。一次侥幸通过审查，可能让整个团队失去使用工具的余地。

学习与测评

学习阶段把全程外包给模型，练到的是提示词技巧和审查能力，不是任务本身。目的如果是练习，过程就是目标。

• 先自己写一版，再让模型挑问题
• 让模型解释思路，而不是直接给答案
• 用测试和最小复现验证生成的代码
• 测评默认不允许外部工具，除非明确说了可以
• 有些公司允许在面试中使用，但会观察你如何使用

面试题考的是你的判断力。用 AI 代答即使没被当场发现，入职后的第一周也会暴露。

提交与 PR 里的记录

## AI 使用说明

- 初稿：模型生成 `sync.py` 的骨架
- 人工：重写重试与幂等逻辑，补了三个测试
- 未使用：配置解析、迁移脚本

这段说明让 reviewer 知道该重点看哪里，也避免把「能跑」误当成「可靠」。

最终标准很简单：你能解释每一行，被问到时能说清哪部分是生成的、为什么这样改。做不到就不要提交。

审查 AI 产出

模型会编造不存在的函数、参数和包名，语法正确不代表能运行。生成代码进入仓库前，按普通外部代码的标准检查。

• 依赖和 API 是否真实存在，版本是否匹配
• 错误路径有没有处理，还是只覆盖了成功分支
• 测试是否验证行为，而不是复述实现
• 许可证来源是否清楚，片段是否来自不兼容的项目
• 删掉多余抽象，模型倾向于生成看起来完整的结构
• 在无凭据的沙箱里先跑一遍，观察它访问了哪些外部资源
• 记录使用的模型与版本，方便复现异常行为
• 把模型的解释复述一遍，再决定信不信

最危险的不是明显错误，而是合理但微妙的偏差：差一错误、时区处理、并发假设。这些只能靠测试和逐行阅读发现，模型的自述不能作为证据。

审查成本要算进任务时间。生成只花一分钟，核对可能花一小时；如果时间预算里没有这一小时，产出就只是把风险往后推。

什么时候不该用

有精确答案的问题查文档比问模型快，也更可靠。命令行参数、正则语义、API 签名这类内容，模型可能给出过时或编造的版本。

• 需要复现线上状态时用调试器和日志
• 大段机械改写写脚本，比逐次提示稳定
• 涉及密钥和客户数据时不要出网
• 需要承担后果的决定自己判断

模型适合缩小搜索空间，不适合当最终依据。把它当成一个速度很快但从不核对的同事，你会自然保留验证步骤。