当AI吃掉你的代码，谁还记得为什么这样写？

你刚接手一个项目，翻到一个奇怪的游标分页实现。问同事，没人记得。看提交记录，只有"修复分页"四个字。原来的工程师已经离职——这种考古现场，AI时代的开发者每天都在经历。

被AI抹掉的痕迹

每次让AI写代码，消失的不是代码本身，而是代码背后的来龙去脉。

GitHub上那个花了两小时解释"为什么游标分页比偏移量更适合实时更新数据"的讨论串。Stack Overflow上2019年那个调试了一整周、最终记录下并发写入场景下方案失效的答主。团队半年前写的RFC，确立了这套模式——AI悄无声息地复制了它，却从不提这些名字。

AI消化了全部。创造它们的人，什么都没得到。

不是哲学意义上的"虚无"。是实打实的：代码库里没有引用。新开发者无法追溯设计决策。原作者收不到任何信号，不知道自己的付出是否被看见。

长此以往，这些人会停止贡献。既然AI会把详细的技术讨论总结成无人问津的碎片，谁还愿意维护那些讨论串？

这是AI辅助开发的隐性成本，至今没人量化。一位开发者决定做点什么。

考古优先，而非强制

他做了一个叫poc.py的工具。核心场景很具体：新成员加入团队，面对六个月AI堆积的代码库，在分页逻辑里撞上一个bug——游标实现很特殊，团队里没人记得为什么这么写，原设计者已离开。

老办法：两天考古。git blame指向一条写着"修复分页"的提交，再往前是"实现分页"。死胡同。

新办法：运行poc.py trace src/utils/paginator.py，三十秒后看到：

来源追溯：src/utils/paginator.py
────────────────────────────────────────────────────────────
　[高置信度] @tannerlinsley，GitHub
　　　　　　游标分页讨论串
　　　　　　https://github.com/TanStack/query/discussions/123
　　　　　　核心洞察：游标在实时更新场景下优于偏移量

知识缺口（AI合成，无人类来源）：
　• 错误重试策略——未引用人类来源
　• 并发写入处理——AI自行选择

开发者立刻知道模式从何而来，更关键的是：哪些部分没有可追溯的人类来源。第二块信息救了命——并发写入处理正是bug所在，AI做了一个没人审查的选择。

工具的逻辑是：先考古，再谈强制。

把人类知识链焊进代码

这个叫proof-of-contribution的技能，是给Claude Code（Anthropic的AI编程工具）设计的插件。目标是在AI辅助的代码库里，保住人类知识的链条。

核心设计很朴素：每个AI生成的产物，都要系回激发它的人类知识。不是文件头顶一条没人看的注释，而是结构化、可查询、可强制执行的记录，与代码并存。

技能激活后，Claude会自动给每个输出附加"来源声明块"。格式固定，机器可读，也给人看。

这不是简单的"AI生成内容打标签"。它区分了两件事：哪些决策有明确的人类来源，哪些是AI的即兴发挥。后者往往是技术债务的温床。

工具还埋了一个反直觉的洞察：强制引用在现阶段不现实，但"让缺失暴露出来"本身就有价值。当开发者看到"并发写入处理——AI自行选择"时，自然会警惕。这种可见性，比任何代码审查清单都直接。

为什么这事值得盯紧

这个工具指向一个被低估的结构性问题：AI正在重塑知识生产的激励链条。

开源社区运转了二十年的隐性契约是——我分享知识，获得声誉、反馈、职业机会。AI把这个链条切断了。贡献者变成无名的训练数据，而数据消费者甚至不知道自己消费了什么。

短期看，效率飙升。长期看，源头枯竭。

这位开发者的解法不是对抗AI，而是给AI的输出"上户口"。让每一条代码都能回答：你从哪来？谁教你的？哪些部分是你自己编的？

这个思路可以延伸。如果代码需要来源声明，产品设计决策呢？数据标注呢？医学诊断建议呢？任何AI辅助的产出，只要涉及人类知识的蒸馏，都可能需要类似的追溯机制。

技术层面，这要求AI系统输出结构化元数据，而非纯文本。组织层面，这需要把"可追溯性"纳入工程规范，像测试覆盖率一样被度量。生态层面，这需要平台重新设计声誉分配——让原始贡献者在AI分发中仍能获益。

目前proof-of-contribution还是个人项目，代码开源。它的真正价值可能是示范效应：证明在AI吞噬一切的时代，"记住来源"本身可以成为产品特性。

GitHub上那个游标分页的讨论串，发布于2021年，至今获得3400多个点赞，被引用进27个技术方案。这是人类专家留下的痕迹。当AI把它们变成无声的默认选项时，我们需要工具来重新看见这些名字——不是为了怀旧，是为了在bug出现时，知道该问谁，或者至少知道没人问过。