一句话看懂：一位长期主张在 Git 提交中把 Claude Code 列为共同作者的开发者，如今公开改变了立场，理由是这种做法会稀释开发者对代码质量的责任感。这个转变折射出 AI 辅助编程从“新鲜事物”走向“默认工具”后，行业对署名、责任和透明度的重新校准。
事件核心：发生了什么
开发者 Indradhanush Gupta 在个人博客上发文，宣布不再让 Claude Code 以共同作者身份出现在他的 Git 提交中。过去一年多，他一直坚持在 AI 辅助生成的代码提交里添加 Claude Code 作为共同作者，并鼓励他人效仿，初衷是让代码审查者清楚知道这部分工作由大模型参与完成。但现在他认为，既然使用大模型已经是工作场景中的普遍预期，继续在每次提交上留下 AI 署名反而显得多余——就像木匠不会把锯子的名字刻在作品上一样。
他进一步指出，把 LLM 列为共同作者，实际上为开发者推卸责任提供了出口：当代码出问题时，可以归咎于“模型不够小心”。他强调，如果工作署的是自己的名字，就应该承担全部责任，无论底层工具是搜索引擎、代码片段网站，还是大模型。文章发布后，他在 Bluesky 上的相关讨论也引起了 Hacker News 社区的注意，这成为他撰写本文的直接契机。
为什么重要
这并非一个孤立的态度转变，而是 AI 编程工具普及后，开发者社区正在形成的新的责任共识。一年前，Claude Code、GitHub Copilot 等 AI 编程助手刚进入主流视野时，在提交信息里标注 AI 参与被视为一种“透明”的加分项；但当这些工具成为日常开发的基础设施，这种标注反而变成了噪音，甚至模糊了真正的问责链条。
更值得关注的是他提出的例外场景：在评估不同模型表现时、或当 AI 作为 PR 的主要创建者而人类只做审查时，添加 AI 署名仍有其价值。这意味着署名规则将变得更加场景化，而非一刀切。对于整个 AI 辅助开发领域来说，这是从“炫耀用了 AI”到“默认 AI 就在那里、但人类要对结果负责”的成熟化信号。
对用户/开发者/创作者的影响
对开发者而言，最直接的启发是重新审视自己的提交规范：如果你正在做开源项目或企业代码库，可以在 README 或项目文档里一次性声明 AI 使用情况，而不是逐条提交添加署名。对团队负责人和代码审查者来说，应更关注代码质量本身，而不是是否有 AI 参与标记——审查机制不应该因为“这是 AI 写的”而放松标准。
AI 工具推荐
想把多个 AI 模型放在一个入口？
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。
推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。
对使用 AI 工具进行内容创作或技术写作的人，这个观点同样适用：如果一段文案或代码以你的名义发布，你就要对它的准确性负全责，而不是把“AI 生成”当作免责声明。对于企业采购 AI 编程工具的决策者，这也提供了一个参考角度：工具的效率固然重要，但团队是否建立了与 AI 协作后的责任制度，可能同样影响长期的生产力与质量。
值得关注的后续
目前公开信息显示，Gupta 是个人开发者，其观点不代表任何公司立场，但这可能引发更多技术团队讨论自己的 AI 署名政策。接下来可以观察三点：第一，主流开源项目是否会出现类似的关于 AI 署名的规范讨论，甚至形成社区共识；第二，Claude Code、GitHub Copilot 等工具是否会在产品层面提供更灵活的署名设置，比如一键生成“AI 使用声明”而非逐次添加共同作者；第三，企业开发团队是否会把这套思路纳入内部代码审查规范，形成对 AI 辅助提交的统一处理方式。
