在上周末刚刚结束的 AES 智能体峰会上，亚马逊云科技 Kiro 中国区负责人 曹阿瞒 提到自己所在的团队不会用“AI 代码占比”来度量成员的效能水平，思码逸创始人兼 CEO 任晶磊则提出团队的目标是“不写一行代码”，获得现场参会者的一致认同。不难看出，“AI 代码占比”这个指标或许在一年前还是一个强有力、也是一个非常直观的指标。但时至今日，当百分之八九十的代码都是 AI 写的，再去看是80%还是90%，意义确实不大了。管理者们逐渐认识到，哪怕算出 AI 代码的占比，也回答不了任何问题，无法直接给 AI 提效成果一个有意义的定论。

一、看似合理的指标，从实现逻辑就不成立

"入库代码 AI 生成占比"的出发点并不复杂：要么希望推动团队多用 AI，要么希望回答"AI 到底有没有带来提效"，再专业一些的，会希望通过行级追踪为审计和合规提供依据。这些问题本身都成立，但关键在于：这个指标是否是一个合适的切入点？

我们的判断是：不是。 而且这个"不是"，从工程实现到业务价值，都有充分的理由。

首先，它无法从代码库反推出来。

AI 本质上是在学习人类写代码，其生成结果同时受到训练数据、提示词以及当前项目代码风格的影响。不同开发者、不同上下文下生成的代码形态差异很大，这使得"仅凭代码产出物判断来源"几乎不可行。

因此，如果要计算这个指标，只能在 AI 修改代码的瞬间进行捕获，提取特征并存储，才能在后续回溯时进行对比。这意味着，相比代码本身（有 Git 作为天然数据源），AI 生成行为需要额外构建一整条数据链路：本地捕获、特征计算、上报、存储、回溯匹配。链路越长，出错概率越大、理解成本越高。

其次，工程成本远超想象。

为了在 commit 时判断"每一行代码是谁写的"，需要引入状态跟踪与多阶段对账机制；而真实开发中的 rebase、cherry-pick 等操作会直接破坏追踪关系，需要额外补偿。

当规模进入真实项目，这个问题很快演变为重计算：以 VS Code 为例，单仓库就需要构建千万甚至上亿级的指纹库。在多仓库与持续增量的场景下，成本进一步放大，本质上依赖服务端与算力体系，而不是一个可以低成本获取的基础数据。

更关键的是，这个问题不仅"贵"，而且很难做到绝对准确。无论是基于 Diff 的归因，还是基于指纹匹配，本质上都是在通过文本特征"推断来源"，而不是记录真实来源。这类方法依赖一系列前提——文本稳定性、跨文件可追踪、一致的字符处理等——一旦被打破，就不可避免地产生误判或漏判。

所以，即便付出这样的成本，这个指标依然难以稳定成立。它既不绝对准确，也不天然易懂。

二、它回答不了你想问的问题

花这么大的代价，换来的指标能解决什么问题？

如果用于审计，结论并不乐观。即便我们知道某一行代码是 AI 生成的，也无法据此做出额外决策。AI 不对代码负责，最终责任仍然在开发者；所有代码在入库前依然需要人工审核，这一点并没有改变。

如果用于回答提效或证明 ROI，这个指标同样站不住脚。AI 写得多，并不等于效率高；AI 写得少，也不代表没有价值。研发效率是一个多因素系统，往往会被理解与验证，或者研发流程里的其他成本所抵消。

如果希望通过这个指标推动团队使用 AI，它甚至连"支点"的作用都很有限。真实的一线情况是，AI 的使用不是线性提升的，而是一个极快完成的习惯迁移：一旦开发者适应了 AI 辅助编程，就不会再回到纯手写代码的模式——就像已经习惯自动挡的人，很少会再回去开手动挡。团队的状态往往不是 30% 或 50%，而是接近 0% 或接近 90%，中间阶段只存在很短的过渡窗口。

这个指标更深层的问题在于：它是有限结果，而不是完整行为。它只能告诉你，最终哪些代码可能是 AI 生成的。但不告诉你开发者是怎么工作的。

三、真正值得关注的，是开发者与 AI 的交互行为

相比之下，有一个指标恰好站在另一个维度：User Prompt 次数。

它不试图推断代码来源，而是直接记录开发者与 AI 的交互行为；不依赖复杂计算，而是天然可采集；不需要解释，就可以直观反映使用频率和工作密度。

更关键的是，它能够真实捕捉 AI 协同开发的核心变化——开发者正在从"写代码的人"，转变为"指挥 AI 完成任务的人"。当一个团队的 Prompt 使用频率持续上升，或者稳定在一个健康区间时，其实已经说明了最重要的一件事：开发者在用，而且愿意用。 这比任何"代码占比"都更直接地反映了 AI 的实际价值。

从实践观察来看，一个开发者，使用Claude Code 等AI辅助编程工具，在一个对外交付、多人协作的中型项目上，连续工作一天（不受其他工作干扰的情况下），大约是 150 次 Prompt，因此可以通过平均 daily prompt 来建立团队参考值。若用户通过 AI 将多次交互沉淀为 Skill，使用次数可能下降，但总效率提升——这种"带宽释放"的变化，User Prompt 能直观体现，而任何代码占比指标都无法反映。

User Prompt 还可以做更深层次的分析：按研发环节分类（方案设计、编码、测试、调试等）、按任务类型分析（技术攻坚、质量保证、学习成长等）、结合 Skill 数据做行为画像与团队洞察。这些维度能够帮助企业全面理解 AI 在研发流程中的实际作用，提供比"AI 代码占比"更丰富、更可操作的洞察。

(AI 原生开发观测指标体系-文末下载PDF)

写在最后

回到投入产出这个最朴素的问题：入库代码 AI 生成占比，需要额外链路、复杂工程、算力投入和一系列隐含假设，却只能得到一个解释空间有限、且可以被更简单指标替代的结果。而 User Prompt 以极低成本，提供了更直接、更稳定、更可扩展的观测能力。

因此，与其执着于回答"代码中有多少是 AI 写的"，不如回到一个更本质的问题：

开发者是否真的在使用 AI，以及这种使用，是否正在成为日常工作的一部分。

在当前阶段，这个问题的答案，远比任何一个复杂的百分比，更有价值。

资料下载：https://fs80.cn/k90hkv