长上下文代码评审的错觉：模型读完仓库，不等于读懂变更半径
结算服务把状态枚举从 SUCCESS 改成 SETTLED，代码智能体一次读完仓库，修改了 14 个文件，补齐了单元测试，PR 评审也没有发现明显问题。
上线后，客服后台仍按 SUCCESS 查询，已结算订单显示成“处理中”；离线报表把新状态归入未知值，风控补偿任务重复触发。仓库里该改的代码大多改了，真正漏掉的是仓库之外的变更半径。
长上下文解决了阅读量，没有解决工程事实
模型上下文越来越长，确实能一次读取更多文件、接口和测试。但软件系统的真实关系并不全部写在同一个仓库：还有运行时调用、消息订阅、数据仓库 SQL、低代码报表、人工运营规则和历史兼容客户端。
“模型读完了”很容易制造一种评审错觉：因为它能解释每一段代码，人们就默认它理解整个系统。实际上，解释文件属于静态理解；判断某个枚举会影响哪些真实消费者，属于证据驱动的变更分析。
变更半径要由四种图叠加
第一层是静态依赖：符号调用、接口定义、Schema、配置和生成代码。第二层是运行关系：过去 14 天真实 Trace 中哪些服务走过这个分支。第三层是数据血缘：字段进入哪些主题、宽表、报表和离线任务。第四层是业务责任：它是否涉及金额、权限、客户承诺或不可逆动作。
可以先建立一个极简的风险排序器，不把全部希望寄托在模型的自然语言判断上：
from dataclasses import dataclass
@dataclass
class ImpactNode:
name: str
static_distance: int
observed_calls: int
data_consumers: int
money_or_auth: bool
recent_incidents: int
def impact_score(node: ImpactNode) -> float:
proximity = 12 / max(node.static_distance, 1)
runtime = min(node.observed_calls, 10000) ** 0.25
lineage = node.data_consumers * 4
critical = 25 if node.money_or_auth else 0
history = min(node.recent_incidents, 3) * 8
return proximity + runtime + lineage + critical + history
这个分数不是“智能预测”，而是把团队已经拥有的证据排成优先级。权重需要用历史事故校准；没有运行数据的节点不能当作零风险，应标记为“证据缺失”。
让模型生成用例之前，先给它一个影响清单
针对状态枚举变更，输入不应只有 diff。还要提供：下游消费者清单、过去真实状态序列、字段血缘、兼容窗口、P0 业务不变量和可用测试环境。让模型针对每个影响节点提出“风险假设—验证方式—需要的证据”，而不是直接吐出 200 条用例。
例如客服后台应验证新旧状态在兼容期内都能正确显示；报表应验证 SETTLED 计入已结算口径；补偿任务应验证未知状态不会默认重试；旧客户端应得到兼容映射或明确升级提示。
测试选择必须允许反证
如果系统声称某个消费者“不受影响”，应记录排除依据：它没有订阅该主题，还是 Trace 里没观察到调用？前者接近确定性证据，后者只是采样期内没看到，可信度不同。
可以把每个测试选择保存成结构化决策：
DECISION = {
"change": "SettlementStatus.SUCCESS -> SETTLED",
"consumer": "risk-compensation-job",
"risk": "未知状态被当成失败并重复补偿",
"evidence": ["consumer schema", "14-day trace", "incident-2026-041"],
"test": "replay_success_and_settled_events",
"oracle": "只产生一次补偿决策，最终账务不变",
"owner": "risk-qa",
}
未来测试平台会从用例库转向“变更证据库”
当编码智能体能快速改几十个文件，测试团队的瓶颈不再是生成脚本，而是判断哪些风险值得验证、哪些证据足以放行。平台应围绕一次变更聚合 diff、依赖图、Trace、血缘、事故和测试结果，让人能回答：这次修改可能影响谁，哪些已经验证，哪些仍然未知。
模型在这里最适合做三件事：从多源证据提出候选影响，把事故语言映射到可执行验证，解释为什么某项风险需要人工决策。金额、权限、状态终态和副作用仍由确定性规则裁决。
测试工程师的新位置
长上下文不会让测试失去价值，反而会淘汰“以阅读文件数量为能力上限”的工作。测试开发要掌握代码依赖、可观测性、数据血缘、风险建模和自动化门禁，成为变更证据的组织者。
模型能读完整个仓库，是代码理解的起点；团队能证明一次变更的真实影响半径，才是发布决策的终点。在 AI 驱动研发里，后者会比生成更多用例更稀缺。
