这次我们不聊具体模型不聊部署脚本先聊一个在 LLM 应用开发里越来越绕不开的问题AI 写的代码功劳算谁的最近技术社区里有一个说法叫Dont credit the LLM翻译过来就是“不要把功劳归给大语言模型”。它不是在否认 LLM 的生产力而是在提醒一件事当 AI 辅助开发成为常态代码的版权归属、提交记录、学术署名、团队绩效不能用一句“这是 GPT 写的”就含糊过去。这个理念直接关系到你的项目能不能进开源仓库、论文能不能过审、公司代码能不能合规商用。这篇文章把这个问题拆开讲清楚。我会先解释 Dont credit the LLM 的背景和核心逻辑再落到工程实践提交记录怎么写、文档怎么署名、开源合规怎么做、团队协作怎么设计流程。面向的是已经在用 LLM 写代码、写文档、做分析的技术人员以及需要在团队里制定 AI 使用规范的负责人。1. 核心观点速览维度说明核心理念LLM 是辅助工具代码与内容的最终责任和功劳应归于人类作者适用对象使用 LLM 辅助编程的开发者、技术团队、学术作者、开源维护者主要场景Git 提交、代码评审、学术论文、开源许可、团队绩效、内容发布争议焦点LLM 生成内容的版权归属、许可合规、学术诚信、署名规范常见误区把 LLM 当共同作者、用 LLM 生成代码后不做审查、忽视开源许可证推荐做法保留人工审查与修改记录、明确标注 AI 辅助范围、建立团队使用规范这个表把核心信息列出来了下面逐个展开。2. 为什么会有 Dont credit the LLM 的讨论这个问题不是凭空出现的。它来自几个真实的技术和法律交叉场景。2.1 学术论文与署名规范2023 年起多个学术期刊和会议组织陆续更新政策明确大型语言模型不能被列为论文作者。原因很直接作者要对内容的准确性、原创性和伦理责任负责而 LLM 无法承担责任。如果你在一篇论文里写了“本文由 ChatGPT 和作者共同完成”这不符合学术规范。正确的做法是在方法或致谢部分说明使用了哪些 AI 工具、用在哪一步、如何验证了输出。署名仍然是人。2.2 开源许可证与版权归属这是工程上最实际的坑。LLM 训练数据里包含大量开源代码这些代码有不同的许可证MIT、Apache 2.0、GPL、AGPL 等。LLM 生成的新代码可能无意中复现了某个 GPL 项目的关键逻辑一旦你把它放进自己的商业项目就面临许可证污染风险。所以“这是 AI 生成的我没有抄袭”并不构成法律上的免责理由。代码的最终责任在你不在模型。2.3 团队绩效与工程管理如果团队里所有开发者都在用 Copilot 或 ChatGPT 辅助写代码那绩效怎么算代码提交记录里全是 Generated by Copilot 显然不合理。工程管理的核心是AI 工具降低的是打字成本不降低设计、决策、责任成本。2.4 语义上的误导Dont credit the LLM 还有一层意思是不要让 LLM 成为你不思考的借口。一个常见现象是开发者把需求直接丢给 LLM然后把输出原样提交。代码能跑但没人理解它为什么这样写。这种“AI 驱动开发”在项目规模小的时候还行一旦进入复杂系统就变成灾难。3. LLM 辅助开发中的角色边界要落地 Dont credit the LLM先要清楚 LLM 在开发流程里到底扮演什么角色。3.1 LLM 是“增强器”而非“作者”我把 LLM 在开发中的角色分为四级级别角色人类参与度责任归属L1代码补全高逐行审查人类开发者L2函数/模块生成中高需要理解并修改人类开发者L3架构方案建议中需要验证和取舍人类开发者L4全流程自动生成低需要全面评审人类开发者但风险最高不管是哪一级最终的责任人都是人。LLM 不参与需求评审不背线上故障的锅也不对用户数据安全负责。3.2 人类负责什么需求拆解把业务问题转化为 LLM 能理解的提示词和验收标准。方案选型判断 LLM 给出的技术方案是否适合当前系统架构。代码审查逐行检查生成代码的边界条件、错误处理、安全性。测试验证补充单元测试、集成测试、回归测试。合规审查确认引入的依赖、算法和训练数据不违反许可证。3.3 LLM 负责什么初稿生成把思路快速变成可运行的代码雏形。模式匹配从训练数据中找到常见问题的解决方案。文本改写优化注释、文档、错误信息的表达。代码翻译在不同语言和框架之间做转换。知识检索在对话中提供 API 用法、算法说明等参考信息。这个边界划分可以帮你判断哪些环节可以放心交给 LLM哪些环节省不了。4. 代码归属与提交记录的工程实践落实到日常开发Dont credit the LLM 最直接的表现是Git 提交记录怎么写。4.1 不要在提交信息里把 LLM 写成作者错误示范git commit -m Add user login module # 作者是 AI这个提交记录没有意义 git commit --authorChatGPT chatgptopenai.com -m Add user login module正确做法是提交者始终是实际负责的人类开发者可以在提交信息里标注 AI 辅助范围。git commit -m Add user login module - Implement JWT authentication - Add password hashing with bcrypt - Write unit tests for login service AI-assisted: ChatGPT was used to draft the initial JWT middleware. Reviewed and modified by 你的名字.这样既保留了 AI 使用痕迹又明确人类进行了审查和修改。4.2 使用 Conventional Commits 规范如果你的团队使用 Conventional Commits建议加一个可选的ai-assisted标记。feat(login): add JWT authentication middleware AI-assisted: true Reviewed-by: your-name这个标记可以用于后续的数据分析统计哪个模块 AI 辅助比例高、哪个模块需要更多人工审查。4.3 配置 Git Template 统一提交格式团队层面可以用 Git 提交模板强制要求填写 AI 辅助信息。创建.gitmessage文件# 提交类型: feat / fix / docs / style / refactor / test / chore type(scope): subject # 正文描述 # AI 辅助情况必填: none / draft / review AI-Assisted: draft # 审核人必填 Reviewed-by:然后配置到 Gitgit config commit.template .gitmessage这样每次提交都会提醒开发者填写 AI 使用情况和审核人。4.4 代码评审中检查什么使用 LLM 辅助开发的代码评审重点应该增加以下内容是否有未理解的魔法值LLM 生成的代码里常有硬编码数字。边界条件是否覆盖输入为空、并发冲突、网络超时这些场景。安全漏洞提示词注入、SQL 注入、路径遍历。许可证冲突引入的第三方库和复制来的代码块是否符合项目许可证。是否有冗余逻辑LLM 有时会生成重复的 check 和 fallback。5. 文档、论文与博客的署名规范代码之外文档和内容的署名同样适用 Dont credit the LLM。5.1 技术文档的 AI 辅助标注团队内部技术文档建议统一格式。页头可以加一个元信息块--- title: 支付服务架构设计 author: 张三 ai_tool: ChatGPT / Claude ai_usage: 用于生成初稿框架人工完成架构选型和细节修订 updated: 2025-01-15 ---这样既不掩盖 AI 辅助的事实也不把功劳归于工具。5.2 对外发布内容的规范对外发布的博客、白皮书、产品说明建议在文末加一段声明本文采用 AI 辅助写作。AI 工具用于资料整理和初稿生成所有内容的准确性、技术判断和最终表述由作者负责。这个声明不降低你的专业度反而体现对读者负责。5.3 学术论文的处理方式按主流学术规范执行不要将 LLM 列为作者。在 Methods 或 Acknowledgements 中说明使用的 AI 工具和技术细节。如果使用了 LLM 生成图表、代码或分析结果要明确标注。提交前务必核对目标期刊或会议的具体政策。一个常见模板是Acknowledgement: During the preparation of this work, the authors used [Tool Name] to assist with literature summarization and code implementation. After using this tool, the authors reviewed and edited the content and take full responsibility for the final publication.6. 开源项目中的 LLM 生成代码合规这是最容易踩雷的部分。LLM 生成的代码不是凭空出现的它基于训练数据而训练数据里包含大量受许可证保护的开源代码。6.1 许可证分层风险评估场景风险等级说明完全手写的代码低不涉及 LLM 生成逻辑LLM 生成通用代码片段循环、排序、IO低属于常见的、不受版权保护的表达LLM 生成有特定业务逻辑的代码中可能复现了某个开源项目的实现LLM 完整生成一个模块高需要重点审查从 LLM 对话中复制了大段开源项目代码极高需要确认原项目的许可证6.2 实操合规流程第一步启用代码扫描工具。可以用 grep 或更专业的工具搜索可疑代码段# 搜索是否有可疑的版权声明残留 grep -rniE copyright|license|all rights reserved src/ | head -50第二步记录所有 LLM 辅助生成的代码范围建立审计追踪。第三步对高风险代码段进行重写。LLM 生成的代码如果可能来自 GPL 项目最稳妥的做法是重新实现只保留思路不保留具体实现。第四步发布前检查项目依赖树# 查看所有依赖及其许可证 pip-licenses --formatjson | jq .[] | {Package, License}6.3 公司内部合规建议如果你在公司里维护内部项目建议和法务团队确认三点公司是否有统一的 AI 使用政策。员工使用外部 LLM 服务时是否允许上传内部代码。生成代码的版权归公司还是个人合同中是否有约定。这些不能想当然。7. 团队协作中的工作流设计单独一个人实践 Dont credit the LLM 不难难的是在团队里推行。下面是一套可以参考的工作流。7.1 建立 AI 使用规范文档一个团队 AI 使用规范应该包含这些内容# 团队 AI 辅助开发规范 ## 允许使用的工具 - GitHub Copilot经公司批准 - ChatGPT / Claude不得上传内部敏感代码 ## 必须人工完成的事项 - 需求分析与验收标准制定 - 架构设计评审 - 安全相关代码的最终确认 - 合规审核 ## 必须标注 AI 辅助的任务 - Git 提交信息中标注 - PR 描述中说明 AI 使用范围 - 文档中记录 AI 工具类型 ## 禁止事项 - 将 AI 工具列为代码作者 - 未经审查直接合入 LLM 生成的代码 - 向外部 LLM 服务提交客户的个人信息7.2 PR 模板加入 AI 信息字段在 GitHub 或 GitLab 的 Pull Request 模板里增加两行## AI 辅助说明 - [ ] 本 PR 未使用 AI 辅助 - [ ] 本 PR 使用了 AI 辅助在下方说明范围和工具 AI 工具: AI 使用范围: 人工审查情况:这个字段的价值在于它让评审者知道哪些代码需要更仔细地看尤其是安全相关代码。7.3 代码评审中的 AI 专项检查建议在评审清单里增加一个专门的 AI 检查区- [ ] 代码中是否存在不理解的逻辑要求作者解释。 - [ ] 是否使用了正确的错误处理LLM 生成的代码经常吞掉异常。 - [ ] 是否有合理的测试覆盖LLM 生成的测试代码常常只覆盖 happy path。 - [ ] 是否引入不必要的依赖LLM 倾向于用额外库解决简单问题。7.4 用自动化工具辅助审计如果你想统计团队中 AI 辅助代码的比例可以写一个简单的脚本分析提交信息import subprocess import re from collections import Counter def analyze_ai_usage(): log subprocess.run( [git, log, --format%s%n%b%n---, -100], capture_outputTrue, textTrue ) commits log.stdout.split(---) ai_commits [] for c in commits: if re.search(rAI[- ]?[Aa]ssisted, c): ai_commits.append(re.search(r^.$, c.strip(), re.M).group(0)) print(fTotal commits: {len([x for x in commits if x.strip()])}) print(fAI-assisted commits: {len(ai_commits)}) if __name__ __main__: analyze_ai_usage()7.5 能力建设把 LLM 当“结对编程搭档”我建议团队把 LLM 的使用定位成“同事”而不是“自动代码生成器”。具体来说让开发者先写注释和伪代码再让 LLM 生成实现。要求开发者在提交前能解释每一段新代码的作用。在代码评审中不是只看“对不对”而是问“为什么这样写”。这样可以防止出现“代码生成率挺高但没人懂系统”的情况。8. 常见误区与排查建议这块是我观察到的常见问题整理成一张排查表。问题现象可能原因排查方式解决方案PR 里出现大段未修改的 LLM 生成代码开发者直接复制粘贴查看提交历史确认是否有逐行审查记录要求开发者重构并写清修改逻辑提交作者是 Copilot 或 ChatGPTGit 配置错误git log --format%an检查重置 author 配置提交者必须是实际作者开源项目收到许可证质询生成的代码与 GPL 项目相似使用代码比对工具检查重写相关代码段记录追溯过程论文投稿被要求补充 AI 使用声明未按期刊政策披露查看投稿规范在 Methods 和 Acknowledgements 补充说明团队提交信息混乱无法统计 AI 使用情况缺少统一规范检查 git log 和 commit 模板引入 Conventional Commits AI 标注开发者对自己提交的代码无法解释完全信任 LLM 输出代码评审中追问实现细节先写设计文档再生成代码商业项目引入 GPL 依赖LLM 推荐了被污染的库pip-licenses或license-checker检查移除或替换为兼容许可证的库8.1 关于“无法解释代码”的排查这个现象最容易在小团队里出现。解决方法是建立“代码答辩”制度每次评审让提交者在评审会上口头解释至少三个关键函数的设计意图。如果解释不清楚就说明他还没有真正掌握这段代码不能合入。8.2 关于“许可证污染”的排查如果你发现项目里混入了可疑代码第一步定位来源。git log --follow -p path/to/suspicious_file第二步搜索版权声明。grep -rn copyright path/to/suspicious_file第三步评估风险。如果是个人项目问题不大如果是商业项目需要法务介入。第四步重写或移除。重写时不要简单改变量名要重新设计实现方案。9. 最佳实践总结把前面内容压缩成一组可以直接执行的最佳实践。9.1 个人开发者每个提交都明确自己承担代码责任。在提交信息中记录 AI 辅助程度none / draft / review。对生成代码做两轮审查一轮看逻辑一轮看安全。不在技术简历上写“X% 代码由 AI 生成”没有意义。对外发布内容时注明 AI 辅助范围。9.2 团队负责人制定 AI 使用规范文档明确允许和禁止的事项。在 PR 模板中增加 AI 辅助说明字段。评审重点从“代码质量”扩展到“代码与作者理解度”。定期抽查提交记录确保信息一致。与法务确认外部 LLM 服务的合规边界。9.3 开源维护者明确项目的 AI 生成代码接受政策。在 CONTRIBUTING 文档中说明使用 AI 辅助生成代码时贡献者必须负责审查和合入。不强制要求贡献者披露 AI 使用情况但如果代码被质询贡献者要能解释来源。对许可证高风险提交设置额外的人工审查环节。9.4 内容创作者论文遵循目标期刊的 AI 披露政策。博客和公众号文章在末尾添加 AI 辅助声明。包含代码示例时确认代码的许可证可接受。不把“AI 生成”作为内容质量不佳的借口。10. 下一步可以做的事Dont credit the LLM 不是一个口号它应该在具体的地方落地。我建议你按这个顺序推进检查最近的 Git 提交看看是否有作者信息混乱的提交。为自己的项目建立一份AI_USE.md文档记录 AI 使用原则。如果你的团队还没有规范先起草一页纸的规则不用太长能执行就行。给 PR 模板加上 AI 辅助说明字段。在评审清单里增加一条开发者必须能解释自己提交的核心代码。如果你在推进过程中发现LLM 生成的代码我改了还要不要标注这类边界问题我的建议是标注成本很低信任成本很高。在你无法明确区分哪些代码确实完全脱离 LLM 影响时宁可多标注一点也不要隐瞒。最后说一句LLM 是你工具箱里一个非常顺手的工具但项目记录里、论文署名处、开源许可证清单上始终应该是你的名字。这不是保守是一种更健康的工程文化工具负责提速人负责负责。 Don‘t credit the LLM：AI辅助开发的代码归属与合规实践指南
这次我们不聊具体模型不聊部署脚本先聊一个在 LLM 应用开发里越来越绕不开的问题AI 写的代码功劳算谁的最近技术社区里有一个说法叫Dont credit the LLM翻译过来就是“不要把功劳归给大语言模型”。它不是在否认 LLM 的生产力而是在提醒一件事当 AI 辅助开发成为常态代码的版权归属、提交记录、学术署名、团队绩效不能用一句“这是 GPT 写的”就含糊过去。这个理念直接关系到你的项目能不能进开源仓库、论文能不能过审、公司代码能不能合规商用。这篇文章把这个问题拆开讲清楚。我会先解释 Dont credit the LLM 的背景和核心逻辑再落到工程实践提交记录怎么写、文档怎么署名、开源合规怎么做、团队协作怎么设计流程。面向的是已经在用 LLM 写代码、写文档、做分析的技术人员以及需要在团队里制定 AI 使用规范的负责人。1. 核心观点速览维度说明核心理念LLM 是辅助工具代码与内容的最终责任和功劳应归于人类作者适用对象使用 LLM 辅助编程的开发者、技术团队、学术作者、开源维护者主要场景Git 提交、代码评审、学术论文、开源许可、团队绩效、内容发布争议焦点LLM 生成内容的版权归属、许可合规、学术诚信、署名规范常见误区把 LLM 当共同作者、用 LLM 生成代码后不做审查、忽视开源许可证推荐做法保留人工审查与修改记录、明确标注 AI 辅助范围、建立团队使用规范这个表把核心信息列出来了下面逐个展开。2. 为什么会有 Dont credit the LLM 的讨论这个问题不是凭空出现的。它来自几个真实的技术和法律交叉场景。2.1 学术论文与署名规范2023 年起多个学术期刊和会议组织陆续更新政策明确大型语言模型不能被列为论文作者。原因很直接作者要对内容的准确性、原创性和伦理责任负责而 LLM 无法承担责任。如果你在一篇论文里写了“本文由 ChatGPT 和作者共同完成”这不符合学术规范。正确的做法是在方法或致谢部分说明使用了哪些 AI 工具、用在哪一步、如何验证了输出。署名仍然是人。2.2 开源许可证与版权归属这是工程上最实际的坑。LLM 训练数据里包含大量开源代码这些代码有不同的许可证MIT、Apache 2.0、GPL、AGPL 等。LLM 生成的新代码可能无意中复现了某个 GPL 项目的关键逻辑一旦你把它放进自己的商业项目就面临许可证污染风险。所以“这是 AI 生成的我没有抄袭”并不构成法律上的免责理由。代码的最终责任在你不在模型。2.3 团队绩效与工程管理如果团队里所有开发者都在用 Copilot 或 ChatGPT 辅助写代码那绩效怎么算代码提交记录里全是 Generated by Copilot 显然不合理。工程管理的核心是AI 工具降低的是打字成本不降低设计、决策、责任成本。2.4 语义上的误导Dont credit the LLM 还有一层意思是不要让 LLM 成为你不思考的借口。一个常见现象是开发者把需求直接丢给 LLM然后把输出原样提交。代码能跑但没人理解它为什么这样写。这种“AI 驱动开发”在项目规模小的时候还行一旦进入复杂系统就变成灾难。3. LLM 辅助开发中的角色边界要落地 Dont credit the LLM先要清楚 LLM 在开发流程里到底扮演什么角色。3.1 LLM 是“增强器”而非“作者”我把 LLM 在开发中的角色分为四级级别角色人类参与度责任归属L1代码补全高逐行审查人类开发者L2函数/模块生成中高需要理解并修改人类开发者L3架构方案建议中需要验证和取舍人类开发者L4全流程自动生成低需要全面评审人类开发者但风险最高不管是哪一级最终的责任人都是人。LLM 不参与需求评审不背线上故障的锅也不对用户数据安全负责。3.2 人类负责什么需求拆解把业务问题转化为 LLM 能理解的提示词和验收标准。方案选型判断 LLM 给出的技术方案是否适合当前系统架构。代码审查逐行检查生成代码的边界条件、错误处理、安全性。测试验证补充单元测试、集成测试、回归测试。合规审查确认引入的依赖、算法和训练数据不违反许可证。3.3 LLM 负责什么初稿生成把思路快速变成可运行的代码雏形。模式匹配从训练数据中找到常见问题的解决方案。文本改写优化注释、文档、错误信息的表达。代码翻译在不同语言和框架之间做转换。知识检索在对话中提供 API 用法、算法说明等参考信息。这个边界划分可以帮你判断哪些环节可以放心交给 LLM哪些环节省不了。4. 代码归属与提交记录的工程实践落实到日常开发Dont credit the LLM 最直接的表现是Git 提交记录怎么写。4.1 不要在提交信息里把 LLM 写成作者错误示范git commit -m Add user login module # 作者是 AI这个提交记录没有意义 git commit --authorChatGPT chatgptopenai.com -m Add user login module正确做法是提交者始终是实际负责的人类开发者可以在提交信息里标注 AI 辅助范围。git commit -m Add user login module - Implement JWT authentication - Add password hashing with bcrypt - Write unit tests for login service AI-assisted: ChatGPT was used to draft the initial JWT middleware. Reviewed and modified by 你的名字.这样既保留了 AI 使用痕迹又明确人类进行了审查和修改。4.2 使用 Conventional Commits 规范如果你的团队使用 Conventional Commits建议加一个可选的ai-assisted标记。feat(login): add JWT authentication middleware AI-assisted: true Reviewed-by: your-name这个标记可以用于后续的数据分析统计哪个模块 AI 辅助比例高、哪个模块需要更多人工审查。4.3 配置 Git Template 统一提交格式团队层面可以用 Git 提交模板强制要求填写 AI 辅助信息。创建.gitmessage文件# 提交类型: feat / fix / docs / style / refactor / test / chore type(scope): subject # 正文描述 # AI 辅助情况必填: none / draft / review AI-Assisted: draft # 审核人必填 Reviewed-by:然后配置到 Gitgit config commit.template .gitmessage这样每次提交都会提醒开发者填写 AI 使用情况和审核人。4.4 代码评审中检查什么使用 LLM 辅助开发的代码评审重点应该增加以下内容是否有未理解的魔法值LLM 生成的代码里常有硬编码数字。边界条件是否覆盖输入为空、并发冲突、网络超时这些场景。安全漏洞提示词注入、SQL 注入、路径遍历。许可证冲突引入的第三方库和复制来的代码块是否符合项目许可证。是否有冗余逻辑LLM 有时会生成重复的 check 和 fallback。5. 文档、论文与博客的署名规范代码之外文档和内容的署名同样适用 Dont credit the LLM。5.1 技术文档的 AI 辅助标注团队内部技术文档建议统一格式。页头可以加一个元信息块--- title: 支付服务架构设计 author: 张三 ai_tool: ChatGPT / Claude ai_usage: 用于生成初稿框架人工完成架构选型和细节修订 updated: 2025-01-15 ---这样既不掩盖 AI 辅助的事实也不把功劳归于工具。5.2 对外发布内容的规范对外发布的博客、白皮书、产品说明建议在文末加一段声明本文采用 AI 辅助写作。AI 工具用于资料整理和初稿生成所有内容的准确性、技术判断和最终表述由作者负责。这个声明不降低你的专业度反而体现对读者负责。5.3 学术论文的处理方式按主流学术规范执行不要将 LLM 列为作者。在 Methods 或 Acknowledgements 中说明使用的 AI 工具和技术细节。如果使用了 LLM 生成图表、代码或分析结果要明确标注。提交前务必核对目标期刊或会议的具体政策。一个常见模板是Acknowledgement: During the preparation of this work, the authors used [Tool Name] to assist with literature summarization and code implementation. After using this tool, the authors reviewed and edited the content and take full responsibility for the final publication.6. 开源项目中的 LLM 生成代码合规这是最容易踩雷的部分。LLM 生成的代码不是凭空出现的它基于训练数据而训练数据里包含大量受许可证保护的开源代码。6.1 许可证分层风险评估场景风险等级说明完全手写的代码低不涉及 LLM 生成逻辑LLM 生成通用代码片段循环、排序、IO低属于常见的、不受版权保护的表达LLM 生成有特定业务逻辑的代码中可能复现了某个开源项目的实现LLM 完整生成一个模块高需要重点审查从 LLM 对话中复制了大段开源项目代码极高需要确认原项目的许可证6.2 实操合规流程第一步启用代码扫描工具。可以用 grep 或更专业的工具搜索可疑代码段# 搜索是否有可疑的版权声明残留 grep -rniE copyright|license|all rights reserved src/ | head -50第二步记录所有 LLM 辅助生成的代码范围建立审计追踪。第三步对高风险代码段进行重写。LLM 生成的代码如果可能来自 GPL 项目最稳妥的做法是重新实现只保留思路不保留具体实现。第四步发布前检查项目依赖树# 查看所有依赖及其许可证 pip-licenses --formatjson | jq .[] | {Package, License}6.3 公司内部合规建议如果你在公司里维护内部项目建议和法务团队确认三点公司是否有统一的 AI 使用政策。员工使用外部 LLM 服务时是否允许上传内部代码。生成代码的版权归公司还是个人合同中是否有约定。这些不能想当然。7. 团队协作中的工作流设计单独一个人实践 Dont credit the LLM 不难难的是在团队里推行。下面是一套可以参考的工作流。7.1 建立 AI 使用规范文档一个团队 AI 使用规范应该包含这些内容# 团队 AI 辅助开发规范 ## 允许使用的工具 - GitHub Copilot经公司批准 - ChatGPT / Claude不得上传内部敏感代码 ## 必须人工完成的事项 - 需求分析与验收标准制定 - 架构设计评审 - 安全相关代码的最终确认 - 合规审核 ## 必须标注 AI 辅助的任务 - Git 提交信息中标注 - PR 描述中说明 AI 使用范围 - 文档中记录 AI 工具类型 ## 禁止事项 - 将 AI 工具列为代码作者 - 未经审查直接合入 LLM 生成的代码 - 向外部 LLM 服务提交客户的个人信息7.2 PR 模板加入 AI 信息字段在 GitHub 或 GitLab 的 Pull Request 模板里增加两行## AI 辅助说明 - [ ] 本 PR 未使用 AI 辅助 - [ ] 本 PR 使用了 AI 辅助在下方说明范围和工具 AI 工具: AI 使用范围: 人工审查情况:这个字段的价值在于它让评审者知道哪些代码需要更仔细地看尤其是安全相关代码。7.3 代码评审中的 AI 专项检查建议在评审清单里增加一个专门的 AI 检查区- [ ] 代码中是否存在不理解的逻辑要求作者解释。 - [ ] 是否使用了正确的错误处理LLM 生成的代码经常吞掉异常。 - [ ] 是否有合理的测试覆盖LLM 生成的测试代码常常只覆盖 happy path。 - [ ] 是否引入不必要的依赖LLM 倾向于用额外库解决简单问题。7.4 用自动化工具辅助审计如果你想统计团队中 AI 辅助代码的比例可以写一个简单的脚本分析提交信息import subprocess import re from collections import Counter def analyze_ai_usage(): log subprocess.run( [git, log, --format%s%n%b%n---, -100], capture_outputTrue, textTrue ) commits log.stdout.split(---) ai_commits [] for c in commits: if re.search(rAI[- ]?[Aa]ssisted, c): ai_commits.append(re.search(r^.$, c.strip(), re.M).group(0)) print(fTotal commits: {len([x for x in commits if x.strip()])}) print(fAI-assisted commits: {len(ai_commits)}) if __name__ __main__: analyze_ai_usage()7.5 能力建设把 LLM 当“结对编程搭档”我建议团队把 LLM 的使用定位成“同事”而不是“自动代码生成器”。具体来说让开发者先写注释和伪代码再让 LLM 生成实现。要求开发者在提交前能解释每一段新代码的作用。在代码评审中不是只看“对不对”而是问“为什么这样写”。这样可以防止出现“代码生成率挺高但没人懂系统”的情况。8. 常见误区与排查建议这块是我观察到的常见问题整理成一张排查表。问题现象可能原因排查方式解决方案PR 里出现大段未修改的 LLM 生成代码开发者直接复制粘贴查看提交历史确认是否有逐行审查记录要求开发者重构并写清修改逻辑提交作者是 Copilot 或 ChatGPTGit 配置错误git log --format%an检查重置 author 配置提交者必须是实际作者开源项目收到许可证质询生成的代码与 GPL 项目相似使用代码比对工具检查重写相关代码段记录追溯过程论文投稿被要求补充 AI 使用声明未按期刊政策披露查看投稿规范在 Methods 和 Acknowledgements 补充说明团队提交信息混乱无法统计 AI 使用情况缺少统一规范检查 git log 和 commit 模板引入 Conventional Commits AI 标注开发者对自己提交的代码无法解释完全信任 LLM 输出代码评审中追问实现细节先写设计文档再生成代码商业项目引入 GPL 依赖LLM 推荐了被污染的库pip-licenses或license-checker检查移除或替换为兼容许可证的库8.1 关于“无法解释代码”的排查这个现象最容易在小团队里出现。解决方法是建立“代码答辩”制度每次评审让提交者在评审会上口头解释至少三个关键函数的设计意图。如果解释不清楚就说明他还没有真正掌握这段代码不能合入。8.2 关于“许可证污染”的排查如果你发现项目里混入了可疑代码第一步定位来源。git log --follow -p path/to/suspicious_file第二步搜索版权声明。grep -rn copyright path/to/suspicious_file第三步评估风险。如果是个人项目问题不大如果是商业项目需要法务介入。第四步重写或移除。重写时不要简单改变量名要重新设计实现方案。9. 最佳实践总结把前面内容压缩成一组可以直接执行的最佳实践。9.1 个人开发者每个提交都明确自己承担代码责任。在提交信息中记录 AI 辅助程度none / draft / review。对生成代码做两轮审查一轮看逻辑一轮看安全。不在技术简历上写“X% 代码由 AI 生成”没有意义。对外发布内容时注明 AI 辅助范围。9.2 团队负责人制定 AI 使用规范文档明确允许和禁止的事项。在 PR 模板中增加 AI 辅助说明字段。评审重点从“代码质量”扩展到“代码与作者理解度”。定期抽查提交记录确保信息一致。与法务确认外部 LLM 服务的合规边界。9.3 开源维护者明确项目的 AI 生成代码接受政策。在 CONTRIBUTING 文档中说明使用 AI 辅助生成代码时贡献者必须负责审查和合入。不强制要求贡献者披露 AI 使用情况但如果代码被质询贡献者要能解释来源。对许可证高风险提交设置额外的人工审查环节。9.4 内容创作者论文遵循目标期刊的 AI 披露政策。博客和公众号文章在末尾添加 AI 辅助声明。包含代码示例时确认代码的许可证可接受。不把“AI 生成”作为内容质量不佳的借口。10. 下一步可以做的事Dont credit the LLM 不是一个口号它应该在具体的地方落地。我建议你按这个顺序推进检查最近的 Git 提交看看是否有作者信息混乱的提交。为自己的项目建立一份AI_USE.md文档记录 AI 使用原则。如果你的团队还没有规范先起草一页纸的规则不用太长能执行就行。给 PR 模板加上 AI 辅助说明字段。在评审清单里增加一条开发者必须能解释自己提交的核心代码。如果你在推进过程中发现LLM 生成的代码我改了还要不要标注这类边界问题我的建议是标注成本很低信任成本很高。在你无法明确区分哪些代码确实完全脱离 LLM 影响时宁可多标注一点也不要隐瞒。最后说一句LLM 是你工具箱里一个非常顺手的工具但项目记录里、论文署名处、开源许可证清单上始终应该是你的名字。这不是保守是一种更健康的工程文化工具负责提速人负责负责。