大家用开源模型写代码时，System Prompt到底该写多细？

我一般只写死约束和输出格式，背景说太细它真会自己加戏。方向偏了直接开新会话，改Prompt容易越描越黑。

我一般只写死约束和风格，思路类任务故意留白，不然它真会一路狂奔。偏了就开新会话，改Prompt常常越描越黑。

我一般是分两层写：硬性约束（语言版本、禁止的库、输出格式）放System里，风格偏好反而丢到第一条user消息里，这样模型不会从头到尾都绷着。过度服从多半是System写太满，把“先给思路再问要不要写码”这种流程控制也塞进去，模型就只会照做不会拐弯。多轮跑偏我倾向于直接开新会话，改Prompt有时救不回来，上下文里的错误示范会一直牵着走。

我一般是分层写：角色和硬约束放System里，比如语言版本、禁用库、输出格式；具体任务细节塞User里，这样模型不会把“给思路”也当成“出全码”。过度服从基本是因为指令里默认了“直接给可运行代码”，加一句“先给方案，等我确认再写代码”会好很多。多轮跑偏我倾向开新会话，旧上下文里错误示范会一直拽着模型走，改Prompt有时候反而越描越黑。

我一般是分两段写，前面固定一段“角色+约束”，后面根据任务临时拼一段“本次目标”。必须写死的只有三样：语言版本、允许/禁止的库、输出形态（是思路还是代码、要不要解释）。其他像项目背景、命名习惯这些，我宁可放在当轮user里，因为放system里模型会当成永久宪法，后面想松绑都难。你说的“过度服从”我太有同感了，Qwen2.5-Coder尤其明显，system里只要提了“完整实现”，它连你没问的测试都给你补上。我的土办法是加一句“默认先给方案，除非我明确说‘写代码’”，能压住大半。多轮跑偏的话，小偏就追加一条纠正，大偏直接开新会话把有效上下文摘出来重喂，硬掰往往越掰越乱。

我也遇到过类似情况，System Prompt写太细确实容易让模型变“死板”，尤其是只想让它给个思路的时候，它非要全给你写完。我现在一般是把必须遵守的硬性约束写清楚，比如禁止用哪些库、代码风格，但具体实现细节就留给它发挥。多轮对话里如果发现跑偏了，我会先试着在下一轮里直接纠正，实在掰不回来就开新会话，省得它被前面的上下文带偏。

我一般是分两层写：固定的编码规范和项目结构放System Prompt，具体任务约束塞user里，这样模型不会把“给思路”也当成“写全码”。颗粒度上，禁用什么库、命名风格、返回格式值得写死，但实现细节别写太满，不然它真会一根筋照做。多轮跑偏我倾向直接开新会话，把之前的好片段捞出来重新喂，改Prompt有时候会越描越乱。

我一般只写“硬约束”，比如不能改的函数签名、必须用的内部库、输出格式要求，风格类的描述反而容易让模型用力过猛。你那个“只想要思路却甩代码”的情况，可以在prompt里加一句“先给方案，我确认后再写代码”，比写一堆风格规则管用。多轮跑偏我基本直接开新会话，把之前有用的上下文压缩成几行重新喂，比在旧对话里纠偏省心。

这个颗粒度的问题我也纠结过挺久，后来发现关键不在于写多细，而在于写什么类型的约束。像项目背景、命名规范、禁用库这种硬性规则，写进去基本只有好处，模型不会因为知道你在用FastAPI就突然抽风。但一旦你开始写“先分析再动手”“给出多种方案对比”这种流程指令，模型就容易变成执行机器，你随口问个思路它给你交作业。我现在的习惯是system里只放不可协商的约束，任务目标尽量放在user消息里，这样同一套system可以适配不同深度的请求。至于过度服从，有个歪招是在system末尾加一句“如果用户只是探讨方案，不要直接输出完整实现”，实测比不加好不少，虽然偶尔还是会漏。多轮跑偏的话我一般先试着在下一轮把偏掉的地方点出来，让它自己修正，实在拉不回来才开新会话，毕竟重开之后之前积累的上下文全丢了也挺可惜的。