我第一次把 CoT 和格式锚点塞进项目里，是被一个客服工单系统逼的。那套系统要从用户长篇吐槽里抽取“问题类型、紧急程度、证据句子”，我一开始以为让模型“认真想想”就行，结果它经常把“我很生气”判成高危，把真正的退款请求漏掉。那次我才意识到，思维链不是用来炫技的，格式锚点也不是摆设，它们更像是给模型装上轨道和站台，不然它真会一路跑偏。
CoT不是让模型“多想想”，而是让它“按步走”
在实际项目里，我更愿意把 CoT 当成任务拆解工具。比如做合同审查、财报抽取、测试用例生成，这些任务最怕一步跨太大。你不能直接问“这份合同有没有风险”，要先拆成“找条款、判断条件、检查例外、汇总结论”。我做过一个租赁合同项目，原来单轮输出命中率大概六成多，加上分步推理后，人工复核时间直接从半天压到一小时内。不是模型突然变聪明了，是它终于不靠脑补了。
格式锚点最适合放在“关键节点”
格式锚点说白了，就是给每一步定个坑位。比如：
- 续租条款原文：
- 明确性判断：
- 风险等级：
- 证据句子：
这种写法特别适合生产环境。因为你后面接的可能不是人，而是程序。JSON、Markdown 表格、固定字段名，这些就是接口语言。我们做过一个内部知识库问答，答案如果不按固定字段返回，前端就得写一堆兜底逻辑；后来改成“每一步都带锚点”，解析失败率从 18% 掉到 2% 左右，挺离谱，但真管用。
真正好用的，是“CoT + 锚点 + 自检”
我现在基本不会单独用 CoT。单纯让模型展开思考，容易越想越飘；只给格式，不给步骤，它又会机械填空。最稳的做法是三件事绑在一起：
- 先规定步骤顺序
- 每步输出固定格式
- 最后加一条自检：数据是否缺失、前后是否矛盾、结论是否能被证据支撑
我们做过一版销售预测，模型曾经把 Q4 缺失的数据硬补成一个“看起来合理”的数。加了自检后，它会老老实实吐出“输入缺失，无法计算”。这一下虽然没那么“好看”，但至少不会误导业务方，真的救命。
适合落地的场景，往往有三个特征
我自己的经验很简单：只要任务同时满足“长文本”“多步骤”“结果要可审计”，就值得上 CoT 和格式锚点。像合同审查、报表抽取、舆情分类、测试生成，都是高频战场。反过来，如果只是问个常识、写个标题，别折腾这些，太重了，像拿电钻拧螺丝。
我的习惯是先小后大
别一上来就设计十几个步骤，模型和人都会累。通常我会先做 3 步版本，跑 20 条样本，看它最容易翻车在哪儿，再补锚点、加约束、拆子任务。这个过程很像调试代码，没什么玄学，就是一轮轮把“会瞎编的地方”堵住。
说到底，CoT 负责把路铺出来，格式锚点负责把车停进格子里。两者一结合，模型才像个能上班的同事，而不是一个嘴很快但容易胡说八道的实习生。
那个客服工单系统也太真实了，我们之前也经常把用户气话当重点
格式锚点确实管用，之前踩过坑，不带格式的输出解析起来要老命