需求写得太细效果反而更差的原因是什么？有没有改善的方法？

[shendaowu]

我听说好像主要是指令过多 LLM 遵循指令的效果就会降低，还有就是子需求可能相互矛盾。我知道拆分是一个方法，但是我太想拆，麻烦。让 LLM 拆？或者换模型？但是如果能用免费的方法缓解我是不会用付费模型的。

后面都是没什么大用的内容了，可以不看。

想到这个问题的起因是我最开始用一个详细的精确到执行步骤的需求文档让 DeepSeek 生成代码结果效果很差，用一个更精简的反而效果很好。另外生成代码之前我让 DeepSeek 根据需求文档生成技术文档了。我感觉我这个情况可能主要是需求有矛盾多一些。那个带执行步骤的需求文档我让 DeepSeek 找了好几次矛盾和不清晰的地方，我没把所有的全改完就让 DeepSeek 生成代码了，某些矛盾的地方我根本就看不懂。

解释一下我为什么那么懒不去自己试。主要是这东西对我来说太难太耗时了，之前我为了实现一个靠 Service Worker 缓存请求的功能我花了非常多的时间，差点就放弃了。顺便说一下 Service worker 是 DeepSeek 在什么时候推荐给我的，我之前的实现方法又麻烦效果又不是特别好。虽然我对失败的忍受能力还行，但是我判断目标是否能实现的能力挺差的，基本都是试几次不行就感觉行不通了。也许我应该多问问能不能实现？但是别人好像最多只能提供能不能实现的信息，谁会闲着没事帮我实现，我自己能不能靠 LLM 实现还是需要靠自己试。

[AEDaydreamer]

我认为现在的推理模型直接把 goal 说明白然后带上相应的 context+criteria 效果反而好一点. 说的太详细局部代码没问题, scope 稍微大一点反而容易限制模型发挥.

[JoeJoeJoe]

不是你的问题, 也不是需求太细的问题, 可能仅仅是 DeepSeek 的问题.

我现在都是 GPT 先行, 后面再让 DeepSeek 找补.

[zizon]

你多看 DeepSeek 的 CoT.它对 reasoning 有些过于细节.
很多你表述上略模糊的点它都要评审推导.

比如 把小函数 inline 了.
它会对那些调用多次的小函数反复思考要不要 inline.
一边是强调用户的遵从字面意思(指令强跟随),一方面又再考虑结合工程实现想用户的真实意图(指令意图展开).

[shendaowu]

@zizon 我最近的尝试都没开深度思考。我忘了有这选项了。可能是之前感觉开不开没多少区别就不怎么用，然后就忘了。现在想想更可能是当时我提示词写得太烂了。看到你提到的 CoT 才想起来这东西能提高效果。以后我再开深度思考试试吧。