AI 复杂度解释开发短记先验证题目约束复杂度推导出错常见原因不是模型不会写公式而是上下文缺了输入范围、语言约束或已有结论。来源版本不同、题意冲突时更多检索片段只会让模型更容易挑到错误前提。要解决的是“它依据了什么”。生成前可以把必须存在的事实列成字段例如题目版本、输入上限、目标语言、待分析的算法以及已知限制。字段缺失时接口应直接返回待补充项或只给出带条件的分析不能默认补全。检索结果也应保留来源和版本如果题面改过但索引还指向旧版本后面的推导没有可靠基础。回答中最好把假设显式写出来。例如只在边权非负时讨论 Dijkstra递归深度取决于输入规模和语言的栈限制同一段循环代码在不同数据结构下单次操作代价可能不同。这样读者能判断结论能否迁移到自己的题目而不是把一个大 O 记号当成无条件答案。一个反例是题目存在负权边回答却默认使用 Dijkstra 并给出看似完整的复杂度。表达流畅不代表前提成立。另一个容易遗漏的情况是读取输入的开销当题目要求逐行解析大文件时只分析核心循环也可能低估实际成本。接口应把“前提不满足”视为正常结果说明需要什么信息或列出可选算法及其适用条件。生成后把结论与代码中的循环、递归和数据结构使用交给规则或人工抽样复核。规则不必替代完整证明但至少可以检查是否提到了必要前提、是否把负权图和 Dijkstra 放在一起、是否遗漏递归终止条件。对于无法自动判断的题目标记为“需人工确认”比生成确定结论更诚实。验证可准备一组固定题目覆盖嵌套循环、递归、不同图权重和大输入。每次记录题目版本、检索来源、模型版本和失败类别比较提示词或检索策略时使用同一题集。验收不看单条回答是否漂亮而看前提遗漏、算法误用和无法解释结论的比例是否下降。