刷题辅助功能：先确认是否值得用 人工智能

LLM 适合解释思路、提示遗漏条件和生成练习变体，不一定适合每一道题。对规则明确、答案可由本地算法快速得到的问题，直接调用模型可能只增加等待和成本。

用任务特征判断

成本评估至少包含输入输出 token、失败重试、缓存命中率和人工复核时间。不要把某次调用的价格外推为长期成本；模型、提示词和流量分布都会改变结果。

def should_call_model(needs_explanation: bool, has_deterministic_answer: bool) -> bool:
    return needs_explanation and not has_deterministic_answer

上线后抽样检查提示是否正确、用户是否采纳、失败是否安全降级。模型给出的是辅助意见，不应替代学习者自己运行代码和理解证明。

先设定不用模型的出口

产品里应保留明确的“无需调用”分支：题目有确定答案时直接走本地校验，模型超时或输出不合格时返回可操作的下一步，例如提示用户补充测试用例或查看规则说明。把这个出口写进交互和埋点，才能分清用户是真的需要讲解，还是只是在等待一个本可以立即得到的结果。

继续把问题说具体

围绕刷题辅助功能：先确认是否值得用 人工智能，最需要避免的是把一个结果当成全部证据。题解、评测或代码审查都有自己的输入分布：容易的样本、边界样本和错误输入给出的信号并不相同。用任务特征判断、先设定不用模型的出口已经说明了主要做法，补充部分应该把“什么算通过”说得更细，而不是把一次高分或一次构建成功写成质量结论。

实际判断可以从反例开始。对题解就看是否漏掉条件和复杂度，对缓存和算法就看失效、负权或状态转移是否被覆盖，对合并改动则看冲突解决后语义有没有悄悄改变。每次只引入一个能解释的问题，比堆一长串抽象术语更适合读者复现和讨论。

测试名称和断言最好描述行为，而不是描述实现。比如写清“重复请求不会生成两份记录”或“负权输入被明确拒绝”，比断言某个内部变量更耐改。发现失败时，把输入、预期和实际结果放在一起；尚未确认的原因就标注为待查，不要用推测替代结论。

这样积累下来的样例既能防回归，也能反过来约束功能范围。需求变了就新增样例或调整判定规则，旧样例仍保留其背景，文章的判断链条才不会随着一次改版断掉。

容易漏掉的细节

刷题辅助最容易越过的线，是替用户把思考过程做完。合适的输出应当帮助定位卡点，例如提示遗漏的条件、提醒复杂度约束，或要求补充一个反例；当输入信息不足时，直接说明不足比拼出一份貌似完整的题解更诚实。

功能入口也应给用户留出关闭和纠错的空间。题目不适合调用模型、回答偏离题意或用户只想看基础提示时，系统要能退回到普通检索、规则提示或空结果。这样的出口不是功能缺失，而是在不同学习阶段保留选择权。