大模型调用与工程实践概览

这一篇算是一个「总纲」，后续可以把其中的某些小节拆成独立文章。

1. 一个典型的大模型调用链

从工程视角看，大致会包含：

1. 请求入口
   • Web 前端 / 后端接口 / CLI 脚本等；
2. 请求预处理
   • 拼接 Prompt、加入系统指令、控制温度等参数；
3. 模型调用
   • 直连官方 API，或通过自己搭的中间层（如代理服务）转发；
4. 结果后处理
   • 解析结构化输出、纠错、补充检验；
5. 落库与监控
   • 记录输入 / 输出 / 耗时 / 错误日志，作为后续优化的依据。

很多问题其实不是出在「模型本身」，而是出在这些环节的设计不清晰。

2. Prompt 相关的几个实践点

1. 角色说明要具体
   比如「你是一个熟悉 Linux 与网络排错的运维工程师」，比单纯的「技术专家」更有约束力。

2. 输入信息结构化
   尽量用列表 / 表格 / JSON 来传递上下文，而不是一大段口语堆在一起。

3. 明确输出格式
   要求模型使用固定结构输出，比如：

   1. 问题原因：
   2. 建议排查步骤：
   3. 注意事项：

或者直接要求返回 JSON，方便程序再处理。

对话中累积上下文 对于多轮问题，可以在后端显式维护「对话历史」，必要时做压缩或摘要。

3. 日志与观测 为了后续调优，建议在调用链里记录：

请求时间、耗时、模型名称；

Prompt（必要时做脱敏处理）；

模型输出（同样注意隐私与安全）；

错误类型（超时、限流、解析失败、业务异常……）。

这些数据可以用来：

统计模型的平均响应时间、错误率；

回溯某次「回答离谱」时的上下文；

迭代 Prompt 设计和参数设置。

4. 和传统系统打交道 在现有系统中接入大模型时，比较常见的方式有：

作为「智能助手」嵌在某个页面里；

在后台做批处理（例如批量生成报告草稿、摘要）；

作为一个可选的「建议模块」，由人来最终确认。

工程上需要注意：

幂等性：同一请求是否会被重复发送？会不会重复写入结果？

限流与熔断：不要让上游的流量尖峰直接砸在模型服务上；

回退策略：模型服务不可用时，系统是否还有可用的降级方案。

5. 未来打算写的子主题 后续可以把下面这些内容各拆一篇：

简单的 RAG（检索增强生成）工程实践；

向量数据库（如 Milvus / Qdrant / pgvector）的基本使用笔记；

工具调用 / 代码执行代理的一些实验记录；

如何为大模型服务加上监控、告警和简单的「健康检查」页面。

---

接下来你需要做的事（一步清单）

1. 打开 GitHub 仓库 civi-wiki；

2. 依次编辑这些文件，把内容全部替换成上面给你的版本：

   • package.json
   • src/.vuepress/config.ts
   • src/.vuepress/theme.ts
   • src/README.md
   • src/about/README.md
   • src/dev/README.md
   • src/dev/vuepress-basic.md
   • src/law/README.md
   • src/law/internship-notes.md

3. 每个文件改完点一次 Commit changes（或者全改完一起提交也可以）；

4. 提交到 main 分支后，Cloudflare Pages 会自动重新构建；

5. 构建完成后，用你的自定义域名打开，看一下：

   • 顶部导航变成「首页 / 系统 & 开发 / 大模型随笔 / 关于」；
   • 侧边栏里每个栏目都有内容可以点进去浏览。

如果你之后想再继续扩展，比如给「大模型随笔」再加几篇单独文章，我也可以直接帮你设计新的文件名 + 完整 Markdown 内容，你只要照着创建即可。 ::contentReference[oaicite:0]{index=0}