CoT 提示看起来高端，上了两天 GitHub 热榜就怒了。

起因很蠢。我在 PromptCube 翻 AI模型讨论 时刷到一个帖子，人家拿 CoT 写代码，跑得飞起。我试着也加上："请逐步推理你的思路。" 结果给我整出一堆"首先...其次...最后..."的废话，然后一个臭长的伪逻辑推理，吓死宝宝了。

直接抄模板不行。那天我在群里跑脚本测试，温度 0.7，CoT 写死，输出直接变臃肿——一个 200 字的问题变出 800 字的瞎扯。最后靠手动砍提示词解决。

CoT 的伪科学热

CoT 翻译过来叫"思维链提示"，也就是让模型说出推理过程。起初看着挺牛：涨知识了一下午。结果第二天实测，直接打脸。

拿一个项目测试为例，prompt 如下：

请你扮演一个资深安全工程师，用思维链方式分析用户注册接口的漏洞。

输出前 50 字还正常，后面开始走神，开始信心满满地胡说八道。比如判断 CSRF 漏洞时，他先是说"需要先确定请求是否依赖 Cookie"，然后紧接着"这一步可以确认..."，然后一本正经地瞎扯了两个没用的判断条件，最后得出"可能存在漏洞"——全凭主观臆测。

实测下来，CoT 在代码生成这种逻辑性强的任务里一点也不靠谱，反而像是给幻觉加了马帔肥。

啥时候 CoT 真的能救你

我承认，有些场合 CoT 确实好用。比如写数学题。

当时群里有人出了一个题：

> 公司有 30 人参加团建，餐费共 1200 元，每个人至少消费 30 元，最多消费 50 元，问是否存在一种分配方案？

直接问 LLM，答案一般。加上 CoT，结果还行。

关键是 CoT 不是用来吹牛的，它是用来引导模型按照一定逻辑顺序拆解问题的。前提得是：逻辑本身是清晰的。

拿代码举例子，调试的时候我试过这样的 prompt：

请一步一步分析以下 Python 代码的潜在类型错误：
def add(a, b):
    return a + b
x = add("123", 456)

模型直接就能指出类型不一致的问题，还能解释为什么 "123" + 456 报错。这种 CoT 是靠谱的，因为推理链本身结构明了、路径清晰。

砍提示词，找回真相

后来我开始主动避开“CoT式写法”，改成直接下判断准则。比如：

你是一个代码审计工具。请找出下面代码中潜在错误，并用一句话说明原因。

效果好很多。输出直接命中，没废话。

其实 CoT 的问题在于，它鼓励模型先“说”，后“做”。但是 LLM 更擅长“做”。说多了，越说越离谱，幻觉就出来了。

最近翻 资源分享 的时候刷到一个开源项目，用结构化 CoT 替代自然语言推理，效果据说不错。我准备抽空试试看。

| CoT 方式 | 优点 | 缺点 | 推荐场景 |
|--------|----|----|------|
| 自然语言推理 | 输出连贯、可读性强 | 易走神、幻觉多 | 教学、解释 |
| 结构化推理 | 输出精准、可控性强 | 不够灵活 | 代码审计、数学题 |
| 模拟少shot推理 | 兼顾两者 | 需要更多调参 | 多任务推理 |

群友也踩过相似坑

上星期群里安静了很久的 Alex 突然戳进来一句："CoT 害死我了"。然后丢了个截图——他让模型写 SQL 查询优化建议，结果模型信心满满地推出一套"优化方案"，运行起来直接锁表。

整个推理过程看着很靠谱，甚至还有“首先，我们检查索引是否命中…”、“其次，考虑使用子查询代替 JOIN…”。但是执行完，数据库直接卡死。最后翻日志才知道，模型根本没考虑到数据量的问题，纯粹在胡编。

我查了一下 行业动态，最近关于 CoT 的论文也开始回避“生成式推理”了，更多转向验证推理路径是否一致。趋势明显：别信它的推理，信它的结论——但前提是你能验证结论。

总结一下踩坑教训

1. CoT 不是万能的，得看任务类型。
2. 推理链越长，幻觉越多，尽量短一些。
3. 不要直接复制网上模板，得结合实际场景调整。
4. 有时候砍掉 CoT，用结构化指令更靠谱。

说白了，别管它怎么叫，能解决问题的提示才是好提示。CoT 固然能装逼，但不能当靠谱助手用。

还是那句话，别怕用简简单直接的 prompt，省得被自己的推理带进幻境。

---

感觉 CoT 是个好东西，但是不能当宝。这么多年过去了，依然记得那天调试出来的臭长推理链，还挺伤心的。

要是你也试过 CoT，或者有更靠谱的替代方案，欢迎丢帖子聊聊看——只是想找个人吐槽而已。