AI时代开发者身份危机：“我做的”还是“Claude做的”？

在Hacker News的一个讨论帖中，一位用户提出了一个看似简单却直指人心的问题：为什么人们总说“我做的”，而不是“Claude做的”？ 这个帖子获得了14个点赞和31条评论，虽然数据不算惊人，但讨论的深度触及了AI时代开发者身份认同的核心矛盾。

问题的本质：创作者归属感的动摇

当Claude、GPT等大语言模型能够生成大量代码时，开发者与作品之间的传统纽带正在被重新定义。过去，“我做的”意味着从构思到实现的完整过程，开发者亲手编写每一行代码，调试每一个bug，这种劳动投入天然赋予了归属感。

但现在，当AI能够根据自然语言描述生成完整功能模块时，“我做的”这句话的含义变得模糊。是构思了需求算“做”？还是审查并修改了AI生成的代码算“做”？抑或只有逐行手写才算“做”？

HN评论区的讨论揭示了这种焦虑：它不是关于技术能力的争论，而是关于身份认同的困惑。 开发者群体长期以来将“创造”视为核心价值，当这个价值被AI部分替代时，用“我做的”来宣示主权，成了一种心理防御机制。

工具与创作者：AI的定位困境

在评论区中，一个反复出现的类比是：如果我用计算器算出了一个结果，我说“我算出来的”，这合理吗？ 大多数人认为合理。那么为什么用AI写代码就不合理？

这个类比有它的局限。计算器只是执行了数学运算，而AI参与了从需求理解到代码结构的决策过程。但类比也有它的洞见：工具的使用本身就包含创造性。 摄影师不会说“是相机拍的”，建筑师不会说“是CAD画的”，但他们都承认工具在创作中的角色。

关键在于对“创造性贡献”的界定。如果你向Claude提供了详细的需求、架构约束、业务逻辑，然后审查并修正了它的输出，那么你确实做了创造性工作。如果你只是说“给我写个登录页面”然后直接复制粘贴，那创造性的确更多来自AI。

创造性贡献的界定在认知科学和知识产权领域有着更深的讨论。哲学家们通常将创造性分为几个层次：概念性创造（提出新想法或新问题）、结构性创造（设计实现路径或架构）和执行性创造（具体实现细节）。在传统软件开发中，这三者往往由同一人完成，因此归属清晰。但AI的介入打破了这种统一性——AI可以独立完成执行性创造，甚至在给定充分上下文时也能参与结构性创造。这使得“我做的”这一表述需要重新锚定在哪个层次上。法律上，美国版权局已明确表示，纯AI生成的作品不受版权保护，但人类对AI输出进行“有意义的修改或编排”后可以主张版权。这为“我做了多少才算我的”提供了法律维度的参考，也解释了为什么开发者需要主动参与审查和修改，而不仅仅是被动接受AI输出。

透明度与诚实：行业需要新的表述规范

讨论中另一条线索是：是否应该更诚实地标明AI的贡献？ 有人指出，在学术写作中，使用AI辅助需要声明；在开源社区，明确标注AI生成代码也正在成为规范。

但这带来了现实困境。如果一个项目90%的代码由AI生成，开发者只做了10%的调整，他能否说“我做的”？如果他不说“我做的”，又该如何表述？这不仅仅是语义问题，还涉及职业声誉、知识产权和商业价值。

有人认为，与其争论“谁做的”，不如建立更细致的贡献描述体系。就像电影有导演、编剧、摄影师的分工，软件开发也可以区分“需求定义者”“代码审查者”“AI操作者”等角色。

贡献描述体系在学术界已有先例可循。学术论文中的“作者贡献声明”（CRediT）将研究贡献分为14类角色，包括概念化、方法论、软件、验证、形式分析等，每位作者需明确标注自己的具体贡献。这种体系之所以有效，是因为它不争论“谁最重要”，而是承认不同角色的必要性。软件开发可以借鉴这一模式，建立类似的贡献分类法。例如，在代码仓库的提交信息中标注“AI生成，人工审查”或“人机协作原型”，在项目文档中记录AI参与的范围和程度。这不仅解决了归属表述问题，还提供了可追溯的审计线索，对维护代码质量和法律合规都有实际价值。GitHub已经开始在提交信息中支持Co-authored-by标签，这为标注AI贡献提供了技术基础设施。

实用主义视角：客户和雇主关心什么？

从市场角度看，客户和雇主真正关心的是结果的质量和交付的可靠性。他们大概率不关心代码是手写还是AI生成，只要满足需求、没有法律风险即可。

但这不意味着归属问题不重要。对开发者个人而言，归属感直接影响职业满足感和学习动力。 如果所有代码都由AI完成，开发者的技能如何成长？成就感从何而来？

也许答案在于重新定义“开发”这个行为本身。未来的开发者可能更像产品经理加代码审查员的混合体，核心能力从编写语法转向定义问题、设计约束和验证结果。

职业声誉的构建机制在AI时代正在发生微妙变化。传统上，开发者通过开源贡献、技术博客、会议演讲等方式积累声誉，这些活动都假设代码是个人能力的直接证明。但当AI能快速生成高质量代码时，声誉的信号价值被稀释了。这导致两个后果：一是雇主开始更看重问题定义和系统设计能力，因为这些更难被AI替代；二是开发者需要寻找新的信号机制，例如展示如何优雅地约束AI、如何验证AI输出的正确性、如何设计人机协作流程。一些公司已经在面试中增加“AI协作能力”的评估环节，要求候选人解释如何拆解问题、如何设计提示、如何审查AI代码。这种转变意味着，职业声誉的基础正在从“我能写什么”转向“我能让AI写出什么，以及我能保证它正确”。

文化适应期：我们正在经历语言滞后

HN这个帖子最有价值的洞察可能是：语言滞后于技术实践。 我们仍然在使用工业时代的词汇（“我做的”）来描述信息时代的协作方式（人类与AI共同生成）。

这种滞后会随着时间自然缓解。当AI辅助开发成为常态，新的表述方式会出现。就像现在没人会说“我用IDE做的”，IDE已经内化为开发环境的一部分。AI也终将如此。

但在过渡期，这种身份焦虑是真实的。它提醒我们：技术变革不只是工具的变化，更是意义系统的重构。 如何描述自己的工作，最终取决于我们如何理解自己在创造过程中的位置。

对于开发者来说，或许更务实的问题是：与其纠结如何宣称归属，不如思考如何在与AI协作中保持不可替代的价值——问题定义能力、系统设计判断力、对业务边界的敏感度。这些是Claude们无法独自完成的，也是“我做的”最终可以坦然成立的理由。

语言滞后是技术社会学中的一个经典现象。语言学家发现，当新技术出现时，人们倾向于用旧词汇描述新实践，直到新词汇自然涌现。例如，“无马马车”（horseless carriage）最终被“汽车”（automobile）取代，“无线电报”被“广播”取代。这种滞后不是简单的词汇问题，而是反映了认知框架的惯性——我们通过旧概念理解新事物，直到新概念成为共识。在AI辅助开发领域，我们现在使用的“我做的”就像“无马马车”一样，是用否定或模糊的方式描述一个本质上不同的东西。未来可能会出现更精确的术语，例如“AI辅助开发”“人机共构”或“提示工程产出”，这些术语将更准确地反映创作过程的混合性质。过渡期的焦虑是正常的，但历史表明，语言最终会追上实践。