在审一个 take-home 提交（ConvFinQA，Python，改造后净增约 5000 行）时，用 tokenize 模块量化了一下 prose-to-code 比例：整体 0.39（1261 行注释+docstring / 3264 行代码），但按文件拆开看，llm.py 0.53、stats.py 0.62、runner.py 0.22——数字本身不吓人，吓人的是这些数字之间的方差小：绝大多数文件都落在 0.25–0.45 这个窄区间里。
第一反应是”注释写得挺全”，但转念一想：真实人写代码的注释密度从来不是平的。人写注释是跟着风险走的——一段纯数据类、一段 CRUD，人懒得写；一段并发锁、一个容易被下一个人改错的边界条件，人才会突然停下来写一整段”为什么”。所以人写的代码库，密度天然是尖峰分布：聚在几个真正危险的点，其余大片空白。
而这份代码密度是平的。没有哪个文件明显裸、也没有哪个文件明显密。这种平坦度，比数值本身更值得当成信号。
密度均匀本身就是信息：它说明解释的密度是按统一策略施加的，不是逐文件、逐决策做出来的判断。
如果每一处设计决策都配一段”为什么这样做”，读者就无法分辨哪些注释是真正保护性的（防止下一个维护者在不知情的情况下改错一个隐藏假设），哪些只是装饰性的复述。
真正资深工程师留下的注释，之所以有分量，是因为周围是安静的——一冒出注释就意味着”这里有坑”。密度一旦铺满，这种信噪比就被抹平了：所有地方都被标记为”重要”，等于没有任何地方被标记为重要。
不是靠”读起来感觉像不像”，是量化：
import pathlib, io, tokenize
for p in sorted(pathlib.Path("src").rglob("*.py")):
src = p.read_text()
comment = doc = 0
for tok in tokenize.generate_tokens(io.StringIO(src).readline):
if tok.type == tokenize.COMMENT:
comment += 1
if tok.type == tokenize.STRING and tok.string.lstrip("rbuf").startswith(('"""', "'''")):
doc += tok.string.count("\n") + 1
code = sum(1 for l in src.splitlines() if l.strip() and not l.strip().startswith("#"))
print(p, code, comment + doc, (comment + doc) / max(code, 1))
跑完拿到一列 (文件, 比例)。关键不是看这一列的均值，是看这一列的方差/极差。 方差小 → 密度大概率是”策略性铺满”的产物，值得怀疑是不是经过深度人工编辑；方差大、且高密度点恰好对应真正复杂/危险的代码段（并发、边界条件、非直觉的取舍）→ 大概率是人根据实际难度逐处做出的选择。
单看密度可能还不够扎眼，加上篇幅就是另一回事：这次改造净增约 5000 行，背景是一个 30 小时量级的 take-home。单人在这个时间窗口里，逐行手写出这个体量 + 这种统一密度的解释性注释，速度本身就是信号——通常意味着大段生成后没有做深度编辑，而不是”写得快”。
很多招募方现在会问”有没有用 AI 工具，怎么用的”——本意不是抓人，是想看候选人是不是负责任地使用。均匀高密度、大体量的代码，如果不配一段”我在哪些地方做了取舍和精简”的说明，读起来就是”用 AI 生成了体量”，而不是”用 AI 做工具、人来把关判断”。这两者在评审眼里分数天差地别，而密度方差恰好是能替评审快速做出这个判断的量化线索。
Q: 那正确的密度应该是多少？
A: 没有统一数字，这不是本文的重点。重点是方差应该大，而且高密度点应该能被作者自己指认出来——”这里确实容易踩坑”。如果作者说不出哪几处是真正需要注释的，密度多少都没意义。
Q: 这个方法只能用在 Python 上吗？
A: tokenize 是 Python 专属，但思路是语言无关的——任何语言只要能区分”注释 token”和”代码行”，就能算这个比例。Go/Rust 的 AST 工具、tree-sitter 都能做同样的事。
Q: 高密度但方差小，就一定是没经过编辑吗？
A: 不一定，但值得多问一句。也可能是团队规范要求每个 public 函数必须有 docstring（这种情况下密度会天然偏平，但通常整体密度不会像这次一样系统性偏高）。要分辨的话，去读几处”看起来最不需要解释”的注释——如果连那种地方都写了一整段理由，八成是策略铺满，不是规范要求。
Q: 写这段代码的人自己怎么避免这个问题？
A: 写完一段代码后，做一次编辑性删减：把每一条注释问一遍——”如果删掉它，会不会有人在不知情的情况下把这里改错？”删不掉的留下，删得掉的删掉。密度分布应该是尖峰，不是平原。
动手清单：找一段自己（或团队里）AI 辅助写的模块，跑一遍上面那段 tokenize 脚本，按文件列出 prose/code 比例，看方差。如果方差小，回去做一遍”只留下真正保护性注释”的删减，再跑一次——密度方差应该明显变大，且高密度点应该落在你自己也承认”这里确实容易踩坑”的地方。
待验证 / 未想清楚：这个信号在多大程度上是”AI 生成”特有的，还是”任何不熟悉代码库、按模板批量补注释的行为”（比如新人接手一个遗留项目、按 linter 要求批量补 docstring）都会产生类似的平坦分布？需要找几个已知人工编写、但因为规范要求统一加注释的代码库做个对照，才能把”AI 生成”和”规范驱动的统一注释”这两种平坦分布区分开。目前只是直觉上认为前者的平坦度会更极端（因为 AI 没有”这段真的不需要解释”的判断力，规范至少还留有”函数太简单可以豁免”的余地），但没有实测数据支撑。