百万上下文的验证重点，不是把更多代码塞进提示词，而是确认模型能否在长距离、分散且相互关联的信息中，找到正确依据并完成可复核的工程任务。上下文窗口描述的是可接收信息的范围，不等于模型能同等准确地利用其中每一段内容。
评测应从真实代码库中的可复现任务开始：选取已知缺陷、功能修改或测试补充，固定代码版本、任务描述和验收条件，再比较模型输出与预期结果。判断问题定位时，不能只看它是否指出相关文件，还要核对原因是否成立、证据是否对应；判断代码修改时，要检查接口约定、架构约束和边界条件是否被遵守；测试补充则要看测试是否覆盖需求，而不只是数量是否增加。
要单独验证“长上下文是否有用”，可把完成同一任务所需的信息分散在不同位置，观察模型能否准确引用关键约束，并在最终实现中落实。还应设置信息缺失或相互冲突的情形，检查模型是否指出不确定之处，而不是自行补全。若任务变长后回答变得笼统、漏掉约束，或引用了并不存在的代码依据，窗口再大也不能视为有效理解。
结果记录应超出“答对或答错”：包括修改是否通过项目原有测试、引入何种错误、人工返工量、重复任务表现是否稳定，以及实际调用消耗。与团队当前流程对照时，保持任务和验收标准一致，才能判断模型带来的是真实收益还是演示效果。评测宜从低风险任务开始；涉及生产代码，仍须保留人工审查、权限控制和回滚准备。