代码所有权

「AI 写的」不是免责理由。你 merge 的代码你负责——线上故障、许可证纠纷、安全事件，问责对象是 工程师与团队，不是 Copilot。本课建立 所有权意识 与 许可证审查 要点。

学习目标

• 说清 merge 后责任链：作者 → reviewer → 运维
• 了解 AI 生成代码的版权与许可证基本风险
• 将所有权与 git-merge、PR 文化对齐

责任链

作者（含 AI 辅助）→ Reviewer Approve → CI 绿 → merge → 生产责任
         ↑_________________|
              任一环节可拦下

问题	谁答
这段逻辑为何这样写？	作者
测了哪些边界？	作者
Approve 后线上 bug？	作者 + reviewer（按团队 RACI）
AI 编错了方法名？	仍是作者——审查义务在人

ai-review：AI 不能 Approve PR。

「AI 写的」在 PR 里怎么写

透明 不转移责任，只 帮助 reviewer 聚焦：

## AI usage
- Copilot：样板 DTO
- Cursor：Service 草稿；我改了事务边界与异常类型

与 ai-workflow 的 PR 模板一致。

许可证与合规

• 训练数据可能含 开源代码；生成片段偶与公开 repo 相似
• 商业项目：了解公司 AI 工具政策（是否允许云端、数据留存）
• 引入大段生成代码时：必要时 人工 diff 与已知许可证库 或法务流程

禁止：把客户源码、密钥 paste 进未授权 SaaS（见 ai-security）。

所有权与测试

可证明正确 是所有权的一部分：

• 无测试的 merge = 把风险推给下游
• test-pyramid 思维：关键路径必须有自动化兜底

CodeRoadMap 内容所有权

讲义维护者对 事实错误、错误链接、抄袭 负责：

• AI 起草 → 你 核对仓库与官方文档
• commit message 可写 AI-assisted draft, human reviewed

练习

• 写一段 PR「AI usage」：诚实标注辅助范围
• 列出 merge 前你的 个人 ownership 清单（≥5 条）
• 阅读 git-remote 中 PR 与保护分支说明

小结

工具无责，签字有人。 下一课讲 质量门禁——用 CI 与测试把所有权制度化。