AI 生成题解的三个坑：上下文堆叠、复杂度猜测与缓存污染

LLM 可以帮忙整理题意、解释思路和生成初稿，但它不是复杂度证明器，也不适合承载整份题库。要把它放进算法题解系统，先把模型擅长的语言任务和程序可验证的事实分开。

1. 三个常见误区

把整库资料塞进上下文。长上下文并不等于相关上下文。题干、约束、语言和少量高质量参考资料通常比大量相近题目更有用。

让模型独立给出复杂度结论。对简单循环可以辅助说明，但递归、剪枝和摊销分析需要检查调用关系与不变量。模型给出的结论应被视为候选解释，而非证明。

把每次请求都发给模型。完全相同的题目、语言和提示版本可以缓存；相似问题要谨慎使用语义缓存，避免把一题的答案错误复用到另一题。

2. 结构化上下文比堆文本可靠

检索阶段可提取题目类别、输入范围、要求的语言和已知解法模式，再由编排器构造 Prompt。这样便于审查输入，也能在上下文超限时按优先级裁剪。

type AlgorithmContext struct { Title string Constraints []string Pattern string Language string } func BuildPrompt(c AlgorithmContext, code string) string { return fmt.Sprintf("题目：%s\n约束：%s\n语言：%s\n思路：%s\n待分析代码：\n%s", c.Title, strings.Join(c.Constraints, "; "), c.Language, c.Pattern, code) }

若需要限制长度，应按 token 计数器或模型 API 的实际限制裁剪，不能把“字符数”当作 token 数。

3. 复杂度验证应保留证据

静态分析可以提取循环嵌套、递归调用和数组访问等线索，但一般无法可靠推出任意程序的精确复杂度。更合理的输出是“发现的结构事实”和“需要人工确认的假设”。对关键题目，配合不同规模输入的基准测试与单元测试，检查模型解释是否与代码行为相符。

go test -run '^$' -bench BenchmarkSolution -benchmem ./...

基准结果只适用于当时的机器、Go 版本和输入分布；报告应保留这些条件，不宜直接推广为通用性能结论。

4. 缓存键必须包含版本和隔离维度

缓存至少应包含题目、语言、规范化后的输入、模型与 Prompt 版本。多租户系统还应包含租户或权限范围。对包含用户代码的请求，先评估保留期限与敏感数据风险；无法安全复用时宁可不缓存。

5. 让模型负责解释，让工具负责验证

题解系统可以让模型负责说明和草稿，让检索、测试、静态检查与缓存承担确定性工作。这样既能降低重复调用，也能把“复杂度正确”落到可检查的证据上。