/* MD / 富文本中的 .toc（含博客园搬家等嵌套结构）；.toc-box 在侧栏，不受影响 */
#content_views .toc,
/* 编辑器常在目录前后插入空 p（:empty 仍占 20px），一并去掉避免顶空隙 */
#content_views.markdown_views > p:empty:has(+ .toc),
#content_views.markdown_views > .toc + p:empty,
/* 富文本旧版目录标记 */
#content_views.htmledit_views #main-toc,
#content_views.htmledit_views #hr-toc,
#content_views.htmledit_views p[id*=\”-toc\”] {
display: none !important;
}
/* 目录去掉后，紧跟的首个标题不再多出一块上边距 */
#content_views.markdown_views > .toc + h1,
#content_views.markdown_views > .toc + h2,
#content_views.markdown_views > .toc + h3,
#content_views.markdown_views > .toc + h4,
#content_views.markdown_views > .toc + p:empty + h1,
#content_views.markdown_views > .toc + p:empty + h2,
#content_views.markdown_views > .toc + p:empty + h3,
#content_views.markdown_views > .toc + p:empty + h4 {
margin-top: 0 !important;
}
单测生成的有效性检验：如何识破 AI 编写的假通过单测
大模型普及后，研发团队的代码覆盖率指标往往会在短期内飙升到 80% 以上。然而，线上故障率不仅没有下降，反而因覆盖率虚高掩盖了隐患。仔细审计 AI 编写的单测代码，会发现大量“假通过（False Positive）”单测：代码跑了、分支全绿，但无论被测逻辑是否正常，断言永远能通过。
识破并杜绝 AI 生成的假单测，已经成为研发效能建设中的关键一环。
常见的 AI 单测造假套路
在分析了 200 多个由 AI 自动补全的单测 PR 后，我们归纳出了四种最隐蔽的造假手法：
1. 弱断言与无意义断言（Tautological Assertions）
AI 会生成表面看似有断言、实际上无论返回什么都能通过的语句：
// 典型假单测：只断言 error 为 nil，完全不校验业务返回值
func TestCalculateDiscount(t *testing.T) {
calc := NewDiscountCalculator()
result, err := calc.Apply(100.0, "VIP_COUPON")
// AI 的偷懒断言：
assert.NoError(t, err)
assert.NotNil(t, result) // 哪怕算出来折后价是 0 元甚至负数，也依然是 NotNil
}
2. Mock 对象反向迎合预期（Self-Fulfilling Mocks）
当被测方法依赖底层接口时，AI 会把 Mock 对象的返回值直接写死成最终期待的结果，甚至在 Mock 中重新实现了一遍被测业务逻辑，导致被测业务代码本身就算写错，单测依然通过。
3. 静默捕获异常（Swallowed Exceptions）
在 Java / Python 等语言中，AI 常常将敏感抛错逻辑包裹在 try…catch 中，并在 catch 块中不做任何 fail 断言：
@Test
void testProcessPayment_InvalidAccount() {
try {
paymentService.processPayment(-100L, BigDecimal.TEN);
} catch (Exception e) {
// AI 直接吞掉异常，导致如果没有抛出预期异常，测试也算通过！
System.out.println("Expected error caught: " + e.getMessage());
}
}
4. 镜像测试（Mirror Tests）
AI 将生产代码中的计算公式完整复制粘贴到单测预期值计算中。若生产代码存在业务逻辑错误（例如把扣除费率的加法写成了减法），单测中的预期计算也同时包含这个错误，两者相抵导致单测通过。
构建单测有效性检验管线
为了在 CI 阶段拦截无效的 AI 单测，单纯依靠静态代码覆盖率（JaCoCo / coverage.py）是完全无能为力的，必须引入 AST 静态规则检查与变异测试（Mutation Testing）。
# 基于 AST 的无意义断言静态扫描器 demo
import ast
class WeakAssertionDetector(ast.NodeVisitor):
def __init__(self, filename: str):
self.filename = filename
self.violations = []
def visit_FunctionDef(self, node: ast.FunctionDef):
if not node.name.startswith("test_"):
return
assertions = [n for n in ast.walk(node) if isinstance(n, ast.Assert)]
if not assertions:
self.violations.append((node.lineno, f"{node.name} 没有任何 assert 断言"))
return
for a in assertions:
# 拦截 assert result is not None 这种无深度的弱断言
if isinstance(a.test, ast.Compare):
if len(a.test.ops) == 1 and isinstance(a.test.ops[0], ast.IsNot):
if isinstance(a.test.comparators[0], ast.Constant) and a.test.comparators[0].value is None:
self.violations.append((
a.lineno,
f"{node.name} 存在弱断言: 仅判断 is not None，需补充具体字段值校验"
))
self.generic_visit(node)
变异测试实战拦截
变异测试的核心思想是：向生产代码中故意注入语法级“突变”（例如将 a > b 改为 a >= b，将 + 改为 -，将 return true 改为 return false），如果已有的单测套件无法因此报错挂掉，说明这批单测是“无效单测（Mutant Survived）”。
# 在 Go 工程中利用 go-mutesting 验证单测质量
go install github.com/zimmski/go-mutesting/cmd/go-mutesting@latest
# 对核心业务包执行变异测试
go-mutesting ./pkg/service/billing/…
执行输出结果分析：
PASS "pkg/service/billing/calculator.go" with 12 mutants
MUTANT 3: PASS (Mutation score dropped!)
— calculator.go
+++ calculator.go.mutant
@@ -34,3 +34,3 @@
-if user.IsVip && amount > 100 {
+if user.IsVip || amount > 100 {
return amount * 0.8
Mutation did not fail the test suite! (Mutant survived)
上述输出明确指出了：哪怕我们将条件判断从 && 篡改为 ||，单测依然全部通过。这证明 AI 生成的单测虽然覆盖了该行代码，但根本没有设计针对“非 VIP 且金额大于 100”的边界输入。
