这是一个虚构但很典型的案例：小郑是一位负责服务器、发布流水线、监控告警和故障处理的运维或 SRE，最近手头在忙“完成两台数据库服务器的磁盘扩容”，同时还要准备“推进日志集中采集”。这次小郑需要整理一份给技术负责人的变更方案，决定试试本地大模型选型。

背景

对小郑来说，告警多、脚本杂、变更文档和故障复盘写起来费时，夜间排障时更需要快速理清思路。偏偏这次还遇到一个变数：机房网络计划维护，可能影响夜间批处理任务。变更方案需要尽快交给技术负责人，时间并不宽裕。

第一次尝试：问题出在哪

小郑一开始只写了一句话：

帮我写一份关于“把发布流程迁移到容器化部署”的变更方案。

结果 AI 给出的内容四平八稳却用不上。复盘下来，主要有两个问题：

  • 只看排行榜选模型。
  • 选定后从不复评。

改进后的提示词

小郑按照本地模型选型的思路重写了提示词，核心是评估硬件：内存、显存、存储和是否需要并发使用：

请帮我为以下情况规划本地模型选型：
- 使用者：运维工程师团队，约 5 人偶尔使用
- 主要任务：整理“变更方案”、写摘要、回答内部资料中的问题
- 语言：以中文为主
- 硬件：[描述内存、显卡等]
- 要求：数据不出本地；响应时间可以接受几秒
请：
1. 说明这类任务对模型能力的要求；
2. 给出选择参数规模和量化方式的建议思路；
3. 设计一套用我们自己的样本评估模型的方法；
4. 提醒许可证方面需要确认的问题。
注意：不确定的具体型号和数据不要编造，用“需要查阅官方说明”代替。

结果（示意）

下面的效果为虚构演示，用来说明这类改进通常带来的变化：

示例（虚构）：一家小公司在一台中等配置的服务器上测试了三个候选模型。最大的模型效果最好但响应太慢，最小的模型速度快但摘要经常遗漏要点，最终选择了中等规模的量化版本，在速度和质量之间取得了平衡。

拿到结果后，小郑没有直接转发，而是先检查关键事实和数字，再补上 AI 不知道的背景。

复盘：这次用到的方法

  • 列出候选模型，查看官方介绍、许可证和社区评价。
  • 用自己的真实任务样本测试，记录速度和质量。
  • 比较同一模型不同量化版本的效果和资源占用。
  • 排行榜不代表你的任务表现，一定要用自己的样本测试。

之后小郑发现，同样的方法也适用于另一类场景：需要为某个具体任务找到性价比最高的模型。

复盘时小郑还想到一个问题：模型更新换代很快怎么办？答案是：保留测试样本和评估方法，新模型出现时快速复评即可。

给运维工程师的提醒

让 AI 写的命令先在测试环境执行，并要求它说明每个参数的作用。涉及删除、重启、改权限的命令，必须先确认影响范围并做好回滚准备，不能照抄执行。另外，对话里不要出现服务器 IP、账号口令、证书私钥和内部拓扑。

一个额外的小技巧：多人使用时考虑并发，单人测试的速度不代表多人使用时的速度。

可以复用的经验

这个案例里最值得复用的，不是某一句提示词，而是“先说清背景和标准，再看结果、再修正”的习惯。下次遇到“清理无主的云资源”这类任务，同样适用。

相关阅读