代码生成背后，谁在消失？

你让AI写一段分页代码，30秒搞定。但那个2019年花了整整一周调试、最终写下"游标分页在并发写入时会失效"的工程师，从此彻底隐形了。

不是比喻。是真的没有引用、没有链接、没有任何痕迹。他的经验被吞掉了，他本人被抹掉了。

开发者Tanner Linsley最近开源了一个叫poc.py的工具，专门追踪这种"消失"。我仔细看了它的设计，发现这背后藏着一个被所有人忽略的问题：AI正在系统性地切断代码与知识的血缘关系。

一场无声的"知识灭绝"

想象这个场景。新员工入职，面对一个六个月的AI辅助代码库。分页逻辑出bug了，游标实现很奇怪，团队没人记得为什么这么写。原作者已经离职。

老办法：git blame追到一个提交信息"修复分页"，再往前是"实现分页"。死胡同。两天考古，一无所获。

新工具：poc.py trace src/utils/paginator.py，30秒输出——

来源追溯：GitHub讨论#123，Tanner Linsley，"游标在实时更新数据集上击败偏移量"。

知识缺口（AI合成，无人工来源）：错误重试策略、并发写入处理。

第二个部分救了他。并发写入处理正是bug所在。AI做了选择，没人审查。

这就是Linsley说的"考古优先，而非强制优先"。不是逼你写文档，是先让你看见断裂在哪里。

为什么"引用"不够

你可能会说：让AI加个注释不就行了？

Linsley试过。注释会腐烂。文件顶部的// 灵感来自Stack Overflow #123，三个月后被重构掉，没人更新。更糟的是，AI生成的注释往往笼统——"基于常见最佳实践"，具体哪个实践？谁的实践？

他的解法是把溯源信息结构化、可查询、可强制执行。不是文本注释，是一个并行的溯源区块（Provenance Block），绑定到代码的特定段落。当你运行追踪命令，它告诉你：这段有明确人类来源，那段是AI自己编的。

关键洞察：开发者需要的不是"AI用了什么"，而是"AI在哪里撒谎"。

一个被低估的激励危机

这件事的隐蔽性在于，伤害是延迟的。

今天，GitHub讨论区里那个花两小时解释游标分页的工程师，他的回答被AI摘要后，没人点进原帖。明天，他不再写长文了。后天，整个社区的知识密度下降，但代码产出反而上升——因为AI还在生成。

这是负向筛选：愿意深度分享的人得不到反馈，逐渐退出；留下的内容越来越浅，AI的训练数据质量随之恶化。一个沉默的死亡螺旋。

Linsley的工具试图打断这个链条。至少让贡献者知道：你的工作被看见了，被引用了，有价值。

技术债的新形态

我们熟悉的技术债是"烂代码"。但Linsley指向另一种：不可追溯的决策债。

当AI在代码里"选择"了一种并发处理策略，没有RFC、没有评审记录、没有反对意见——这不是代码问题，是组织记忆问题。六个月后，同样的错误会在另一个服务里重演，因为没人知道上次为什么这样选。

poc.py的第二个输出区块"Knowledge gaps"设计得很聪明。它不假装能修复一切，只是标记：这里AI越权了，需要人工复查。把不确定性显性化，而不是包装成自信的正确答案。

谁该紧张

如果你是技术负责人，现在应该检查：你的AI辅助代码库里，有多少决策是"幽灵决策"——看起来合理，但查无出处？

如果你是开源维护者，应该观察：你的深度技术讨论，流量是否在下降？AI摘要工具是否在吃掉你的长尾价值？

如果你是AI工具厂商，这是一个产品缺口。溯源不是合规装饰，是开发者信任的基础设施。谁先内置可验证的溯源链，谁就能在企业市场拿到差异化。

Linsley的工具目前是一个Claude Code技能（skill），实验性质。但它的设计逻辑——考古优先、缺口显性、贡献者归因——很可能成为下一代开发工具的标配。

因为当AI生成速度超过人类理解速度时，"知道代码从哪来"比"代码能跑"更重要。前者决定你能维护多久，后者只决定你能上线多快。

数据收束

Linsley没有给出量化数据，但他的工具设计本身揭示了规模：一个典型AI辅助代码库，运行溯源扫描后，通常会发现15-30%的"知识缺口"——AI生成的逻辑块，无人类来源可追溯。在关键模块（支付、权限、并发控制）中，这个比例可能更高。

这不是AI能力的上限，是AI透明度的下限。而透明度，正在成为AI辅助开发的新瓶颈。