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