AI 复杂度解释开发短记：先验证题目约束

AI 复杂度解释开发短记：先验证题目约束

复杂度推导出错，常见原因不是模型不会写公式，而是上下文缺了输入范围、语言约束或已有结论。来源版本不同、题意冲突时，更多检索片段只会让模型更容易挑到错误前提。要解决的是“它依据了什么”。

生成前可以把必须存在的事实列成字段，例如题目版本、输入上限、目标语言、待分析的算法以及已知限制。字段缺失时，接口应直接返回待补充项，或只给出带条件的分析，不能默认补全。检索结果也应保留来源和版本；如果题面改过，但索引还指向旧版本，后面的推导没有可靠基础。

回答中最好把假设显式写出来。例如，只在边权非负时讨论 Dijkstra；递归深度取决于输入规模和语言的栈限制；同一段循环代码在不同数据结构下，单次操作代价可能不同。这样读者能判断结论能否迁移到自己的题目，而不是把一个大 O 记号当成无条件答案。

一个反例是题目存在负权边，回答却默认使用 Dijkstra 并给出看似完整的复杂度。表达流畅不代表前提成立。另一个容易遗漏的情况是读取输入的开销：当题目要求逐行解析大文件时，只分析核心循环也可能低估实际成本。接口应把“前提不满足”视为正常结果，说明需要什么信息，或列出可选算法及其适用条件。

生成后，把结论与代码中的循环、递归和数据结构使用交给规则或人工抽样复核。规则不必替代完整证明，但至少可以检查是否提到了必要前提、是否把负权图和 Dijkstra 放在一起、是否遗漏递归终止条件。对于无法自动判断的题目，标记为“需人工确认”比生成确定结论更诚实。

验证可准备一组固定题目，覆盖嵌套循环、递归、不同图权重和大输入。每次记录题目版本、检索来源、模型版本和失败类别；比较提示词或检索策略时使用同一题集。验收不看单条回答是否漂亮，而看前提遗漏、算法误用和无法解释结论的比例是否下降。