LM Studio代码开发的系统提示词工程：`temperature`、`context_length`与`stop`词详解

你已经调好了top_p、top_k和repeat_penalty。输出不再无限循环，胡言乱语也少了。但模型仍然跑题、忘记之前的代码，或者不在你想要的地方停下来——

这是另一组旋钮的问题，同样至关重要。

本文介绍控制模型如何理解自身角色、能记住多少内容以及在哪里停止输出的三个参数：temperature、context_length和stop词。

🌡️ `temperature`是什么？

如果说top_p和top_k在筛选哪些词元作为候选，那么temperature控制的是模型从候选中挑选时的确信程度。

把它想象成一个从专注到创意的旋钮：

temperature = 0.0 → 完全确定性。模型始终选择概率最高的词元。相同提示 = 每次相同输出。
temperature = 0.2 → 略微放松。偶尔会考虑第二或第三可能的词元。
temperature = 1.0 → 完全概率化。所有候选词元权重相同——输出不可预测。
temperature > 1.0 → 极度混乱。代码场景绝对避免。

👉 代码开发推荐值：`0.1–0.3`

代码不是创意写作。函数签名、循环、SQL查询——都有正确答案，你需要模型坚定地给出它。temperature过高是为什么你的模型有时返回正确的Python，下一次却返回语法错误Python的原因。

{
  "temperature": 0.2
}

适合稍高（0.4–0.6）的场景： 生成样板代码、文档注释或README章节，这些场景中措辞有些变化是可以接受的。

代码场景不要超过0.7。 你会得到幻觉出来的库名、缩进错误，以及看似合理但无法运行的逻辑。

📏 `context_length`是什么？

context_length（某些界面中称为n_ctx）定义了模型一次能"看到"多少词元——也就是它的工作记忆。

这包括：

你的系统提示词
完整的对话历史
你粘贴进去的文档或代码
模型迄今为止自己的输出

当上下文窗口满了，模型就会开始遗忘开头。对于代码会话来说，这意味着它会忘记你之前的函数定义、已确立的变量名，或者你在系统提示词中解释过的项目约束。

👉 按任务推荐设置：

任务	`context_length`
单函数补全	2,048
文件级代码审查	4,096
多文件重构会话	8,192
大型代码库问答	16,384–32,768

{
  "n_ctx": 8192
}

内存代价： 上下文长度直接决定模型使用多少内存。在8GB机器上，以n_ctx = 32768运行7B模型很可能导致OOM错误或严重的性能下降。实用计算公式：

上下文所需内存 ≈ Q4量化模型的n_ctx × 2字节

所以n_ctx = 8192仅需约16MB用于上下文存储——完全可管理。n_ctx = 32768则需约64MB。模型权重本身占大头，上下文叠加在此之上。

质量悬崖： 在上下文窗口的末端，大多数模型开始失去连贯性——即使技术上仍在窗口内，它们也会"遗忘"开头说的内容。为了可靠的代码辅助，将实际内容保持在设定context_length的70–80%以内。如果设置了n_ctx = 8192，把6000词元作为实际上限。

🛑 `stop`词是什么？

stop词告诉模型："当你在输出中看到这个字符串时，立即停止生成。"

没有它，模型会在逻辑终点之后继续生成——添加额外解释、凭空编造后续代码或重复自己。

{
  "stop": ["```", "# END", "\n\n\n"]
}

为什么这对代码场景格外重要

当你要求模型在代码块内写一个函数时，你希望它在闭合的三重反引号处停下。没有stop词，它通常会继续：

没有stop词：

```python
def calculate_tax(amount):
    return amount * 0.07

你还可以扩展这个函数来处理不同的税率：

def calculate_tax(amount, rate=0.07):
    ...

其实，这里有个更好的版本…


**使用"stop": ["`"]：**

def calculate_tax(amount):
    return amount * 0.07


干净。完成。

### 代码任务常用stop词：

| 使用场景 | stop值 |
|---|---|
| 代码块输出 | ` "`" ` |
| 单函数，无散文 | "\ndef " （在下一个函数定义前停止）|
| 结构化JSON输出 | "}" + 手动计数，或schema验证 |
| Diff/patch输出 | "---" |
| 防止冗长解释 | "\n\n\n" （三个空行）|

---

## ⚙️ LM Studio代码开发完整推荐配置

将本文参数与上一篇top_p/top_k/repeat_penalty的设置合并：

```json
{
  "temperature": 0.2,
  "top_k": 40,
  "top_p": 0.9,
  "repeat_penalty": 1.05,
  "n_ctx": 8192,
  "max_tokens": 2048,
  "stop": ["```", "\n\n\n"],
  "seed": -1
}

🧠 写一个真正适合代码的系统提示词

这三个参数与精心编写的系统提示词结合时会显著增效。系统提示词在任何代码对话开始之前设定模型的角色和约束——它会占用部分context_length，所以要保持简洁。

优秀代码系统提示词的要素：

明确指定语言和风格：

You are a Python 3.11 backend developer. Use type hints on all functions.
Follow PEP 8. Prefer standard library over third-party packages unless necessary.

设定输出格式预期：

When writing code, output only the code block with no explanation before or after,
unless explicitly asked. Use triple backtick fences.

建立项目约束：

This project uses FastAPI 0.111, PostgreSQL 16, and Python 3.11.
No Django. No SQLAlchemy — use raw asyncpg for database queries.

Simplico后端工作实际使用的完整系统提示词：

You are a senior backend engineer. Stack: FastAPI, Python 3.11, PostgreSQL with asyncpg, pgvector.
Always use async/await. Use type hints. Follow PEP 8.
Output code only — no explanations unless asked. Use triple backticks.
If the task is ambiguous, ask one clarifying question before writing code.
Do not hallucinate library names. If unsure about an API, say so.

此提示词消耗约80–100词元——在8192词元上下文中占比极小。这些词元的回报巨大：错误技术栈的答案更少，输出格式更整洁，模型在假设之前会先确认。

面向信创环境的额外约束示例：

本项目运行于信创环境，数据库为达梦DM8，操作系统为麒麟Linux。
不使用MySQL或PostgreSQL特有语法。SQL需兼容DM8方言。
所有第三方依赖须在国产化替代清单内。

🧮 所有参数交互关系总结

参数	控制对象	代码开发推荐值
`temperature`	模型对选择的确信程度	0.1–0.3
`top_k`	考虑的候选词元数量	20–50
`top_p`	包含的概率质量范围	0.85–0.9
`repeat_penalty`	对近期词元重复的抑制	1.05–1.1
`n_ctx`	模型一次能"看到"的量	大多数任务8,192
`stop`	模型停止生成的位置	`""` `+` "\n\n\n"`