# 把本地 LLM 训练成“先问清楚再动手”的个人实践教程

> 改写后的请求：请基于 XDA 文章《Local LLMs perform so much better when you teach them to ask before they answer》，提炼成一篇面向个人日常使用本地 LLM 的实践教程，包含目标、适用场景、Ollama/Modelfile 配置、可复制提示词、3 个练习案例、验收标准和失败处理。
>
> 改写点：把“个人实践”具体化为“个人日常使用本地 LLM”；把“教程”补全为可执行结构；明确要有命令、模板、案例、验收和故障处理，避免只写成读后感。

## 1. 结论先说

如果你在用本地 LLM，例如 Ollama 上的 Llama、Qwen 或其他本地模型，不要默认让它“猜”你的意图。更稳的做法是：给模型加一条系统规则——遇到编码、写作、编辑、总结等非简单任务时，先问最多 3 个澄清问题，再开始执行。

这不是为了增加流程，而是为了减少返工。尤其是本地模型上下文理解和意图推断弱于云端模型时，先问清楚通常比先答错再修正更快。

## 2. 来源与边界

- 原文：<https://www.xda-developers.com/local-llm-clarifying-questions-system-prompt/>
- 原摘要路径：`/home/lin/.hermes/projects/hermes-gsummary-workflow/runs/outputs/20260525-101459-www.xda-developers.com-local-llm-clarifying-questions-system-prompt-86203-967158760-summary.md`
- 来源性质：个人经验文章，不是严格 benchmark。
- 本教程的定位：把文章里的方法变成个人可执行流程；其中“练习案例、验收标准、失败处理”是实践补充，不是原文逐字内容。

## 3. 适合谁

适合你，如果你：

- 已经在本机跑过 Ollama 或计划跑本地模型；
- 经常让模型做总结、改写、写代码、生成计划；
- 发现本地模型经常“理解偏了”，需要多轮纠正；
- 想把模型变成一个先确认目标的助手，而不是一个急着输出的问答器。

不适合强制启用的场景：

- 简单事实问题，例如“Python 怎么查看版本”；
- 闲聊；
- 明确、低风险、格式固定的请求；
- 你已经提供了完整输入、输出格式和验收标准的任务。

## 4. 最小可用配置

### 4.1 准备 Modelfile

在任意工作目录新建一个名为 `Modelfile` 的文件，无后缀：

```text
FROM llama4

SYSTEM """
When tasked with coding, writing, editing, or summarizing, ask the user up to three targeted clarifying questions. Proceed with the task once you've received answers and understand the prompt fully. If the task is a simple factual question or conversational message, respond directly.
"""
```

如果你本地没有 `llama4`，把第一行替换成你已有的模型，例如：

```text
FROM qwen2.5:7b
```

或：

```text
FROM llama3.1:8b
```

### 4.2 创建自定义模型

在 `Modelfile` 所在目录运行：

```bash
ollama create my-assistant -f Modelfile
```

### 4.3 启动模型

```bash
ollama run my-assistant
```

预期输出：进入交互式对话界面，可以直接输入问题。

如果使用 GUI 客户端，选择刚创建的 `my-assistant` 模型即可。

## 5. 更适合个人实践的中文系统提示词

原文提示词可用，但你可以改成更贴近日常使用的中文版本：

```text
FROM qwen2.5:7b

SYSTEM """
你是我的本地个人助手。

当任务涉及写作、改写、总结、编码、调试、计划制定、资料整理或多步骤执行时，如果用户需求不够明确，请先提出最多 3 个关键澄清问题。

只问会显著影响结果的问题，例如：目标、受众、输出格式、输入范围、限制条件、完成标准。

当问题是简单事实查询、闲聊，或用户已经给出足够明确的目标与格式时，直接回答，不要为了提问而提问。

在收到澄清回答后，再开始执行任务。执行时先给结论，再给必要步骤。
"""
```

创建：

```bash
ollama create my-cn-assistant -f Modelfile
ollama run my-cn-assistant
```

## 6. 练习案例 1：让模型总结文章前先确认输出

### 6.1 模糊输入

```text
帮我总结这篇文章。
```

如果模型直接输出长摘要，说明澄清规则没有生效或不够强。

### 6.2 期望的澄清问题

模型应该问类似问题：

```text
为了更准确总结，请确认：
1. 你希望摘要多长：一句话、要点列表，还是详细版？
2. 面向谁：自己快速理解、团队分享，还是写成教程？
3. 是否需要保留可执行建议或只保留文章观点？
```

### 6.3 你的回答样例

```text
面向我自己快速理解，控制在 300 字以内，用要点列表，保留可执行建议。
```

### 6.4 验收标准

合格输出应满足：

- 不超过 300 字；
- 使用要点列表；
- 区分“文章观点”和“我的下一步”；
- 不擅自扩展到无关主题。

### 6.5 失败处理

如果模型仍直接输出：

1. 把系统提示词里的“请先提出最多 3 个关键澄清问题”提前到第一段。
2. 增加反例：`不要在任务目标、受众、格式不明确时直接输出最终答案。`
3. 重新创建模型：

```bash
ollama create my-cn-assistant -f Modelfile
```

## 7. 练习案例 2：让模型写代码前先确认边界

### 7.1 模糊输入

```text
写一个脚本帮我监控服务器。
```

这个请求非常危险，因为“监控什么、怎么告警、多久运行一次、运行在哪台机器”都不明确。

### 7.2 期望的澄清问题

```text
我需要先确认 3 点：
1. 你要监控哪些指标：CPU、内存、磁盘、进程、端口，还是服务可用性？
2. 脚本运行环境是什么：Linux shell、Python，是否允许安装依赖？
3. 告警方式是什么：只打印日志、写文件、企业微信 Webhook，还是邮件？
```

### 7.3 你的回答样例

```text
只监控本机磁盘使用率，用 Python 标准库，不安装依赖。超过 85% 时打印一行告警，先不要发外部通知。
```

### 7.4 预期输出形态

模型应该输出一个最小 Python 脚本，而不是复杂监控系统：

```python
import shutil

THRESHOLD = 85
PATH = "/"

def main() -> None:
    usage = shutil.disk_usage(PATH)
    used_percent = usage.used / usage.total * 100
    if used_percent >= THRESHOLD:
        print(f"WARN disk usage {used_percent:.1f}% on {PATH}")
    else:
        print(f"OK disk usage {used_percent:.1f}% on {PATH}")

if __name__ == "__main__":
    main()
```

运行：

```bash
python3 disk_check.py
```

### 7.5 验收标准

- 不安装第三方依赖；
- 不写入系统目录；
- 不发送外部通知；
- 只检查 `/` 分区；
- 输出包含 `OK` 或 `WARN`。

### 7.6 失败处理

如果模型直接给出很大的监控平台方案，说明它没有遵守 KISS：

```text
请回到最小版本：只用 Python 标准库，只检查磁盘使用率，只打印结果，不要引入数据库、Web 服务或告警平台。
```

## 8. 练习案例 3：让模型制定计划前先确认目标

### 8.1 模糊输入

```text
帮我制定一个学习 AI Agent 的计划。
```

### 8.2 期望的澄清问题

```text
我需要确认：
1. 你的目标是会使用 Agent 工具，还是会自己开发 Agent？
2. 你每周能投入多少时间？
3. 你偏向 Python 实战、论文/理论，还是产品应用？
```

### 8.3 你的回答样例

```text
目标是能自己做一个本地小 Agent；每周 5 小时；偏 Python 实战，不看太多论文。
```

### 8.4 预期计划结构

模型应输出类似：

```text
第 1 周：搭建环境，跑通 Ollama + Python 调用。
第 2 周：实现一个只读文件问答工具。
第 3 周：加入任务拆解和执行日志。
第 4 周：做一个个人资料整理 Agent，并加失败处理。
```

每周都应包含：

- 目标；
- 操作步骤；
- 练习任务；
- 验收标准；
- 常见失败处理。

### 8.5 验收标准

合格计划不是书单，而是可执行路线：

- 每周有明确产物；
- 每个产物能在本机验证；
- 不要求一开始接入外部 API；
- 不默认让 Agent 写入重要文件或执行破坏性命令。

## 9. 个人提示词使用规则

你可以把下面这段作为日常对话前缀，尤其适合没有写进 Modelfile 的临时会话：

```text
如果我的请求不够明确，请先问最多 3 个澄清问题。只问会影响执行结果的问题。若可以根据常识安全默认处理，请直接执行，并说明你的默认假设。
```

更严格一点：

```text
在开始执行前，请判断这个请求是否需要澄清。
- 简单事实问题：直接回答。
- 多步骤任务、写作、编码、总结、计划：若目标、输入范围、输出格式或验收标准不明确，先问最多 3 个问题。
- 如果你选择不提问，请先用一句话说明你的默认理解。
```

## 10. 一周实践路线

### 第 1 天：只改一个模型

- 选一个常用本地模型；
- 创建 `my-cn-assistant`；
- 用 3 个模糊问题测试它是否会提问。

验收：至少 2 个复杂任务触发了澄清问题。

### 第 2 天：测试总结任务

- 输入一篇文章；
- 故意不说明长度和格式；
- 看模型是否先问输出要求。

验收：模型问到了长度、受众或格式。

### 第 3 天：测试写代码任务

- 输入“帮我写一个脚本”；
- 检查模型是否先问运行环境、限制和输出。

验收：模型没有直接生成复杂代码。

### 第 4 天：测试计划任务

- 输入“帮我做一个学习计划”；
- 检查模型是否问目标、时间和偏好。

验收：计划能落到每周产物。

### 第 5 天：收集失败样本

记录 3 类失败：

- 不该问时问了；
- 该问时没问；
- 问题太泛，没有帮助。

### 第 6 天：微调系统提示词

根据失败样本补充规则，例如：

```text
如果用户已经给出目标、输出格式、限制条件和验收标准，不要再提问，直接执行。
```

### 第 7 天：固定个人模板

保留一个稳定版本的 `Modelfile`，以后只小幅修改。

## 11. 常见问题与处理

### 问题 1：模型每次都问，太烦

原因：系统提示词过度强调“先问”。

处理：加入直接回答条件：

```text
如果问题是简单事实查询、闲聊、翻译短句、解释概念，或用户已经明确给出输出要求，请直接回答。
```

### 问题 2：模型问的问题太空泛

坏例子：

```text
请问你有什么具体要求？
```

好例子：

```text
请确认输出长度、目标受众和是否需要可执行步骤。
```

处理：要求它只问“会改变执行结果”的问题。

### 问题 3：模型问完后仍然跑偏

处理：让模型复述任务理解：

```text
在正式执行前，请先用一句话复述你对任务目标、输出格式和限制条件的理解。
```

### 问题 4：本地模型不稳定

处理顺序：

1. 缩短系统提示词；
2. 用更明确的中文指令；
3. 减少一次性任务复杂度；
4. 换更强的本地模型；
5. 对高价值任务使用“澄清 → 复述 → 执行 → 自检”四步。

## 12. 最终可复制模板

如果你只想保留一个版本，用这个：

```text
FROM qwen2.5:7b

SYSTEM """
你是我的本地个人助手。你的目标是减少误解和返工，而不是急着输出。

当任务涉及写作、改写、总结、编码、调试、计划制定或多步骤执行时，请先判断信息是否足够。

如果目标、输入范围、输出格式、限制条件或验收标准不明确，请先提出最多 3 个关键澄清问题。只问会影响结果的问题。

如果问题是简单事实查询、闲聊，或用户已经给出足够明确的要求，请直接回答，不要为了提问而提问。

收到澄清回答后，先用一句话复述你的理解，再执行任务。输出时先给结论，再给必要步骤。
"""
```

创建命令：

```bash
ollama create personal-assistant -f Modelfile
ollama run personal-assistant
```

## 13. 成功标准

你不需要追求“模型每次都问问题”。真正的成功标准是：

- 简单问题直接答；
- 模糊复杂任务先问；
- 澄清问题不超过 3 个；
- 问题具体、可回答；
- 回答后模型能按目标、格式、限制执行；
- 返工次数下降。

一句话原则：让本地 LLM 不再靠猜，而是先把任务边界问清楚。