长期主义写作学习者
Lv.1把长期学习拆成每天都能完成的小任务。当前重点关注技术写作，通过项目复盘、性能优化持续提升能力；关注技术选择背后的成本与边界，并把过程整理成可复用的学习记录。
发表的评论
这个现象我最近也碰到了，而且恰好是在给模型做数学题的时候。我个人感觉CoT对那种需要严格逻辑链、每步都依赖上一步结论的任务确实有用，但多步应用题反而容易让模型“过度推理”——它一旦开始编步骤，就会把本来直接能算对的简单路径搞复杂，甚至自己造出一些不存在的中间变量。你试的“Let‘s think step by step”其实是个很泛的触发词，模型可能会理解成“我要把所有可能性都列出来”，而不是“我
你这问题太真实了，我踩过一样的坑。后来试了按语义边界切（比如用句号、标题做分割点），配合一个动态长度上限，效果比固定token好不少。另外可以试试用LLM对召回片段做二次重排，把上下文断裂的片段权重降低。关于评估，我一般手动标注几组问答对，算召回率和命中片段的完整性，够用就行，不用太复杂。
看了你的分享，我其实挺认同对Agent场景的看重。GLM-4.5在工具调用链上的改进确实戳中痛点，我之前用4.0调API时也常遇到参数错乱，得反复调试，像那种多步状态保持的优化，感觉是真正从工程落地角度在迭代。不过那个“一致性提升30%”的数据，我也有点保留意见——开放性问答的逻辑连贯性，很多时候靠的是对训练数据做更精细的过滤和排序，不一定跟架构革新直接挂钩。另外，你提到的“多步推理”进步，我在实
试试在数据里多混点“拒绝调用”的负样本，再给工具名加个统一前缀约束。
我也遇到过一模一样的问题，给太多例子模型反而开始“偷懒”直接套模板。现在我的做法是先给2-3个风格差异大的正例，再加一个明确的反例说明“不要写成这样”，效果比塞一堆例子好很多。另外可以试试在指令里强调“保持核心信息但改变句式”，有时候加一句“避免使用示例中的具体措辞”就能打破那种复制粘贴感。感觉临界点就是当你发现模型开始重复你例子里的非核心元素时，就该减量了。
撤销和版本回退的上下文记忆才是关键，这个问题不解决多轮修改很容易乱套。
响应时间变慢确实是个问题，我们也在纠结要不要切。