为 AI 时代重构开发者技术栈：我们为什么在此时下注？
我们关注的投资方向：为AI时代重建开发者工具栈
我们关注的投资方向：为AI时代重建开发者工具栈AI / ML软件基础设施与安全洞察写
GitHub是为人类编写代码的世界而构建的。那个世界正在迅速终结。
上个月，谷歌宣布其公司内部75%的新代码现在由AI生成。根据2025年Stack Overflow开发者调查，84%的开发者正在使用或计划使用AI工具。
工程角色的内涵正在发生巨大变化，然而工程师用来管理代码的工具：git、PR、代码审查、文档，却一成不变。裂痕已经开始显现。HashiCorp创始人、GitHub第1299号用户Mitchell Hashimoto宣布，在连续使用18年后，他将把自己的项目迁出GitHub。他的不满在于可靠性，而非AI；但这表明软件开发的基础已经准备好被重建。AI创作正是那个推动变革的催化剂。
我们看到，为AI时代构建新型工程工具的巨大窗口已经打开。我们正在积极寻找那些重新构想新时代工具的团队。
真正出了什么问题
Git的设计围绕着一个简单的思维模型：一个人做出决策，编写一些代码，并留下一条解释原因的提交信息。围绕它发展起来的整个代码审查文化：PR评论、责任标注、变更日志规范，都假设存在一个你可以，如果需要，拍拍肩膀问”你为什么这么做？”的人。
当人类参与减少时，Git模型就崩溃了，尤其是当作者是Claude Code/Codex/Cursor或在CI中运行的自定义AI智能体时。代码仍然会进入PR，通过lint检查，甚至可能通过代码审查，但许多曾经隐含或可追溯的信息现在都消失了。
提示词消失了。对于AI生成的代码来说，最丰富的意图产物就是生成它的提示词：工程师要求什么，他们指定了哪些约束，他们向模型提供了什么上下文。在AI世界中，这段历史在会话结束的瞬间就蒸发了。六个月后，当有人需要理解某个特定架构决策的原因时，已经无迹可寻。来自AI智能体的提交信息告诉你的都是你已经知道的东西（”特性：实现用户认证模块”），只留下一个差异对比、一个模糊的工单链接，以及运气好时一份AI生成的README。消失的不仅仅是提示词：会话中积累的理解也一并消失了。这在大型代码库中尤为严重，AI智能体被迫分片工作，它们理解当前任务所需的内容，却从未看到自己的更改如何与系统的其他部分交互。每个新会话，无论是同一个工程师、不同的工程师，还是另一个AI智能体，都是从零开始。
目前，很难区分哪些是人类编写的，哪些是AI智能体生成的。大多数代码库现在都是混合状态：有些文件被AI智能体大量修改，有些由人类修改，还有一些是两者交替修改。git blame显示的是执行git commit的人，而不是其中的代码是否由AI生成。一些工具试图揭示这一点：Claude Code默认会在提交信息中添加”Co-Authored-By: Claude”尾部标记，但它无法在压缩合并后干净地保留，而且最多只能提供提交级别的信号，而非行级别的信号。实际上，一旦PR合并，这个信号就消失了。这对于调试、安全审查以及任何试图在六个月后理解代码库的人来说都至关重要。佐治亚理工学院的Vibe安全雷达追踪到，仅在2026年第一季度，就有56个CVE可归因于AI生成的代码，超过了2025年全年的总数——而且其中大多数最初都是通过了审查的代码。
开发者们仍然不信任AI的输出。Stack Overflow 2025年的调查揭示了一个值得注意的现象：46%的开发者积极质疑AI工具的准确性，而只有33%的人信任它们。尽管采用率在攀升，但信任度同比却下降了11个百分点。45%的人表示，调试AI生成的代码比他们自己编写代码耗时更长。代码交付速度更快了，但对其的信心却没有跟上。
社区层面也在瓦解。GitHub不仅仅是一个存储代码的地方。Issues、PR和提交历史是开源项目沟通和吸引贡献者的方式。社交层有可以被质疑并会回应的人类作者。AI正在用噪音淹没GitHub：由不理解代码库的AI智能体提交的issue、缺乏人类上下文的PR、技术上准确但语义空洞的提交历史。维护者报告说，分类工作正变得难以管理。信噪比正在恶化，而我们没有工具来解决这个问题。
CLAUDE.md 问题
团队已经开始自行解决上下文问题。在任何工程师重度使用Claude Code或Codex的代码库里翻一翻，你都会找到像CLAUDE.md、AGENTS.md、AI_CONTEXT.md这样的文件。基本上就是为AI智能体编写的README。它们写下了这样的规则：不要碰遗留的认证模块，始终使用内部HTTP客户端，这是迁移模式，这是你在接触这个服务之前需要知道的五件事。
这些文件是有效的。当它们准确时，能显著改善AI智能体的输出。问题在于，没有工具能让它们与实际代码库保持同步。因此它们会逐渐偏离。做出的决策没有反映在上下文文件中。服务被弃用了，但文档仍然引用它们。建立了新的模式，但AI智能体却不知道。没有人更新这个文件，因为这不是任何一个人的职责。
在规模上，本可以让AI智能体高效工作的上下文层变成了一种负担：每个会话中都植入了自信但错误的指令。而基于过时上下文运行的AI智能体会让本已不稳定的局面雪上加霜。
重建开发者工具栈：机遇
解决这些问题最雄心勃勃的版本可能是一个新的GitHub：一个从零开始构建的平台，假设相当一部分代码是由AI智能体生成的，并将来源、会话上下文和归属作为一等公民。对于有人来说，从头开始是一个巨大的机会。
我们最感兴趣的四个领域：
将提示词和会话捕获作为平台原语。 AI编写代码的生成上下文，即提示词、模型、尝试过和被拒绝的方案，需要持久地保存在某个地方，并与产生的提交相关联。这是构建一切的基础层：没有它，就无法进行有意义的归属、审查或审计。我们正在寻找将其构建为组织级基础设施的团队，而不是作为单个AI智能体工具中的一个功能。
为AI智能体生成的差异对比重建代码审查。 现有的PR审查流程并非为AI生成代码的数量或性质而设计。一个能够识别哪些代码块是由AI智能体生成的、知道产生它们的提示词上下文，并在审查体验中原生呈现这些信息的平台，将使工程团队能够施加适当的审查力度，而不会拖慢一切。开发者即使每天都在使用AI输出，却对其缺乏信任，这既是审查工具的问题，也是模型质量的问题。
在代码库级别进行上下文管理。 CLAUDE.md模式有效，但无法扩展。正确的解决方案是将AI智能体上下文视为一个一等平台产物：版本化、与代码库同步、在每个会话开始时可用，无需手动维护。对于管理大型代码库的CTO来说，这决定了AI智能体是能随时间累积价值，还是会因为总是从零开始而陷入瓶颈。
社区和贡献基础设施。 随着AI用噪音淹没开源社区，维护者需要能够大规模管理贡献质量、区分信号与AI生成的噪音、并保留用于协作软件开发的人类沟通层的工具。
这只是我们关注的四个领域。这个领域还处于早期阶段，我们非常乐意与那些从不同角度看待问题的创始人交流。
