LLM Writing and Me 这个题目可以缩成一句话我怎么让大语言模型真正参与写作而不只是替我编一段漂亮话。过去一年不少写作者开始用 LLM 生成大纲、润色段落、翻译引用、整理采访记录但大多数尝试停在了“打开聊天框、复制粘贴”这一步。真正稳定有效的写作工作流需要把提示词、模型 API、知识检索、版本控制、精度选择和结果验证组合成一条流水线。下面会从我的实际使用环境出发讲清楚 LLM Writing 的完整链路包括模型选型、提示词模板、RAG 知识库、LLM Wiki、Agent 编排、FP16/FP32/BF16 精度问题以及每次输出异常时该怎么排查。如果只是想要一段 AI 文案任何聊天机器人都能满足。但如果你想用 LLM 写技术博客、做课程讲义、整理内部文档甚至维护一个持续更新的私人知识库就需要回答几个问题为什么同一段提示词在不同服务上结果差异很大为什么本地推理显存不够为什么检索到的资料没有被正确引用这些问题的答案恰好构成了一套 LLM Writing 工程化方法。下面按“概念 - 环境 - 实践 - 排错 - 优化”的顺序展开。1. 先拆解 LLM Writing写作任务与技术主线的对应关系1.1 LLM Writing 不是“让 AI 写完整篇文章”在实际项目中LLM Writing 指的不是把写作任务一次性丢给模型而是把“写作”拆成一个个模型真正擅长的子任务。一个完整写作过程至少包括主题脑暴从短需求扩展出多角度选题。提纲生成把主题拆成章节安排论证顺序。初稿生成按提纲逐段产出文本。改写压缩把冗长段落缩短或调整语气。翻译与术语统一在双语项目中保持技术术语一致。校对修正检查错别字、语法、标点和引用格式。这些子任务对模型能力的要求并不相同。脑暴需要发散性温度参数可以调高一些校对需要稳定和精确温度参数要调低最好把待校对文本和规则一起放进上下文。如果不管任务类型都用同一个 800 字提示词、同一个 API 参数产出的质量必然不稳定。下面的表格把常见写作任务、依赖的模型能力和需要配套的技术点做了对应写作任务模型能力依赖需要配套的技术点主题脑暴发散生成、知识广度提示词自由度、温度调高提纲生成结构化组织、逻辑排序输出格式约束、Markdown 模板初稿生成语言组织、上下文保持上下文工程、素材注入改写压缩序列转换、重写示例驱动、单词或字数约束翻译与术语统一跨语言映射术语表、few-shot 示例事实核查与引用检索和上下文定位RAG、引用编号、来源输出多文档摘要长文本理解分块、摘要合并、去重这里的核心判断是LLM Writing 是一个系统不是一次调用。你越早把写作任务拆开越容易定位哪个环节输出不稳定。比如初稿写得不错但事实有误问题通常不在提示词而在素材检索又比如输出总在结尾断掉问题往往在 max_tokens 或上下文截断策略。1.2 我的写作工作流从素材到发布的最小闭环我的技术写作工作流可以简化为下面这条流水线素材收集 - 素材清洗 - 分块 - 向量化 - 向量库 | 需求/选题 - 组装提示词 - 检索增强生成 - 初稿 Markdown - 人工修订 - 发布每一步都有明确产出。素材收集阶段我会把接口文档、旧笔记、源码片段和产品需求整理进同一个目录素材清洗阶段删除无关广告、空行和冗余 HTML 标签分块阶段把长文档切成适合检索的片段向量化阶段用 embedding 模型把文本转成向量检索增强生成阶段把 top k 片段注入提示词让模型基于真实材料输出。这个流程解决了两类问题。第一类是没有来源直接让模型写技术文章它很容易编出不存在的方法名或 API 参数因为模型只能靠训练知识补全。第二类是没有沉淀每篇文章都是一次性 prompt无法复用下个月想写相似主题又要重新构建上下文。引入 RAG 和 LLM Wiki 之后我的历史笔记、已完成文章和所有参考资料都变成了可持续复用的写作素材。2. 运行环境与模型选择API、本地模型和推理引擎怎么搭2.1 API 方式 vs 本地推理方式进入实现之前先要做一次技术选型。LLM Writing 的运行载体主要分两类调用云端 API或者部署本地模型。它们没有绝对优劣只有适不适合当前写作场景。对比维度云端 API本地推理硬件要求低只需网络和 API Key高需要 GPU 或内存足够的 CPU/Mac配置成本低注册账号即可中高需要安装推理框架数据隐私数据出网敏感内容需要评估数据留在本机适合内部文档单次成本按 token 计费主要是硬件电费和折旧模型更新服务方维护升级简单自己拉模型文件版本可锁定可控性部分参数可选依赖服务方可控制精度、上下文、采样参数稳定性依赖网络和服务方限流依赖本机资源可能有 OOM我的建议是先把 API 流程跑通再根据数据敏感度和长期成本决定是否引入本地模型。写作任务对延迟不敏感但对输出稳定性敏感所以无论选哪种方式都要在后端把“模型提示词模板”和“调用参数”固化下来。2.2 本地推理时的精度FP32、FP16、BF16 先搞懂模型权重保存时用多少位来表示一个数值叫精度。本地推理最常见的三种精度是 FP32、FP16 和 BF16。很多模型文件下载页会标注fp16、bf16或q8_0这些后缀直接决定你能不能在当前机器上跑起来。FP32 是单精度浮点数用 1 位符号、8 位指数、23 位尾数表示数值精度高但占用空间大。FP16 是半精度浮点数用 1 位符号、5 位指数、10 位尾数表示数值内存减半但指数范围变小容易出现上溢或下溢。BF16 是 Brain Floating Point用 1 位符号、8 位指数、7 位尾数表示数值指数范围和 FP32 一致但尾数精度更低适合大模型训练和推理。对写作任务来说BF16 和 FP16 都是常用选择。BF16 在大模型场景更稳妥因为它保留了 FP32 的指数范围数值不容易溢出缺点是尾数位少理论上对小数精度要求高的计算会损失细节。写作模型的核心计算是矩阵乘法和 token 概率分布对 FP16 和 BF16 都没有明显障碍真正需要关注的是显存容量。显存占用可以用一个近似公式估算模型权重显存约等于参数量乘以每个参数占用字节数。以 70 亿参数模型为例精度每参数字节7B 模型权重占用典型场景FP324 字节约 28 GB高精度实验FP162 字节约 14 GB多数 GPU 支持良好BF162 字节约 14 GB新 GPU 上更推荐INT81 字节约 7 GB显存受限时使用INT4约 0.5 字节约 3.5 GB消费级设备这只是权重占用实际推理还要加上 KV cache、激活值和框架开销。因此 7B 模型用 FP16 推理建议至少准备 16GB 到 24GB 显存如果只有 8GB可以尝试 INT4 量化或更小的模型。2.3 常用推理框架与配置示例本地推理框架按使用方式可以分为几类Ollama 适合快速体验llama.cpp 适合 CPU 和边缘设备vLLM 适合高吞吐的 API 服务LM Studio 适合 Mac 上的图形化操作。Ollama 的启动方式最简单# 拉取指令模型这里以 llama3.1 为例 ollama pull llama3.1 # 启动本地服务默认 11434 端口 ollama serve # 简单对话测试 ollama run llama3.1 请用三句话解释 RAGOllama 默认提供了 OpenAI 兼容接口写作程序可以直接用chat/completions协议调用from openai import OpenAI client OpenAI( base_urlhttp://localhost:11434/v1, api_keynot-needed, ) response client.chat.completions.create( modelllama3.1, messages[ {role: system, content: 你是一名技术编辑输出要求简洁准确。}, {role: user, content: 把下面段落压缩到 100 字以内...}, ], temperature0.3, max_tokens512, ) print(response.choices[0].message.content)如果使用 vLLM 提供 OpenAI 兼容服务常见启动命令是python -m vllm.entrypoints.openai.api_server \ --model meta-llama/Llama-3.1-8B-Instruct \ --dtype bfloat16 \ --max-model-len 8192启动成功后程序里把base_url指向 vLLM 服务的地址即可。注意不同框架的base_url路径不一定相同常见的是/v1不要漏掉。注意如果你只是做写作任务先不要追求大参数模型。7B 到 14B 的指令模型在自己可接受的硬件上先跑通流程比 70B 模型放不上显存更有实际价值。3. 提示词工程为写作任务建立稳定的输出基线3.1 写作提示词四要素提示词工程不是“把问题写得更客气”而是把模型输出约束到你的工作流需要的格式上。一个稳定的写作提示词至少包含四个部分角色模型以什么身份输出例如“资深技术编辑”。任务这次要完成什么动作例如“压缩、改写、生成提纲”。素材模型必须基于哪些输入可以包含检索结果、用户原文或参考资料。输出约束格式、字数、语气、是否要引用来源。下面是一个可以固化的写作提示词模板你是一名拥有十年经验的技术文档编辑。 你的任务是帮我生成一篇技术博客的“概述”段落。 写作素材 {context} 约束 1. 只能使用素材中出现的信息不要补充任何方法名、版本号和性能数据。 2. 字数控制在 200 到 300 字。 3. 输出为 Markdown 段落不要使用列表。 4. 如果素材不足直接写“素材不足需要补充以下信息...”。关键点在第 1 条和第 4 条。写作类任务最容易出现的问题是幻觉也就是模型把“可能合理的补全”当成事实。明确告诉它“只能使用素材中出现的信息”能显著减少编造第 4 条给模型留了一个“拒绝生成”的出口比让它硬写更安全。3.2 生成参数temperature、top_p、max_tokens 如何配合同一个提示词使用不同采样参数输出风格会完全不同。你需要理解四个常用参数参数作用写作任务推荐值错误表现temperature控制输出随机性0.3 到 0.7过高会产生不相干内容top_p控制候选 token 的累计概率范围0.8 到 0.95过小会导致重复短语max_tokens限制生成的最大 token 数按任务设定过小导致内容被截断presence_penalty / frequency_penalty控制重复内容的惩罚0 到 1过大会导致话题跳跃技术写作建议把 temperature 设为 0.3 到 0.5。脑暴类任务可以调到 0.8 以上但要清楚输出的事实可靠性会下降。max_tokens建议按目标语言和正文长度估算中文一个汉字大约对应 1 到 2 个 token如果你要输出 1000 字max_tokens至少给 1200 到 2000。在 API 调用中这些参数通常是 JSON 里的顶层字段{ model: llama3.1, messages: [ {role: system, content: 你是一名技术编辑。}, {role: user, content: 请改写以下技术段落...} ], temperature: 0.4, top_p: 0.9, max_tokens: 1500 }3.3 用“模板 变量”替代每次即兴提问如果每次写作都临时写提示词很难复现上一次的好结果。更工程化的做法是把提示词存成模板文件用变量填充当前内容。以 Python 为例template 你是资深技术编辑。 请根据素材生成一段技术博客引言。 素材 {context} 输出要求 - 200 字以内 - 只使用素材中的信息 - 输出 Markdown 段落 context \n.join(retrieved_chunks) prompt template.format(contextcontext)这样做有三个好处模板可以放进 Git 仓库做版本管理批量测试时能快速对比不同 prompt 的输出出现质量问题时可以明确知道是哪一版提示词引起的。更严格一点的场景可以要求模型输出 JSON并在程序里校验字段请输出 JSON { title: 标题, summary: 摘要不超过 100 字, outline: [一级标题1, 一级标题2] }模型输出的内容不一定严格合法所以程序侧要做异常处理而不是盲目相信输出。这也是 LLM Writing 工程化和直接用聊天框的重要区别。 LLM写作工程化：从提示词到RAG的完整工作流
LLM Writing and Me 这个题目可以缩成一句话我怎么让大语言模型真正参与写作而不只是替我编一段漂亮话。过去一年不少写作者开始用 LLM 生成大纲、润色段落、翻译引用、整理采访记录但大多数尝试停在了“打开聊天框、复制粘贴”这一步。真正稳定有效的写作工作流需要把提示词、模型 API、知识检索、版本控制、精度选择和结果验证组合成一条流水线。下面会从我的实际使用环境出发讲清楚 LLM Writing 的完整链路包括模型选型、提示词模板、RAG 知识库、LLM Wiki、Agent 编排、FP16/FP32/BF16 精度问题以及每次输出异常时该怎么排查。如果只是想要一段 AI 文案任何聊天机器人都能满足。但如果你想用 LLM 写技术博客、做课程讲义、整理内部文档甚至维护一个持续更新的私人知识库就需要回答几个问题为什么同一段提示词在不同服务上结果差异很大为什么本地推理显存不够为什么检索到的资料没有被正确引用这些问题的答案恰好构成了一套 LLM Writing 工程化方法。下面按“概念 - 环境 - 实践 - 排错 - 优化”的顺序展开。1. 先拆解 LLM Writing写作任务与技术主线的对应关系1.1 LLM Writing 不是“让 AI 写完整篇文章”在实际项目中LLM Writing 指的不是把写作任务一次性丢给模型而是把“写作”拆成一个个模型真正擅长的子任务。一个完整写作过程至少包括主题脑暴从短需求扩展出多角度选题。提纲生成把主题拆成章节安排论证顺序。初稿生成按提纲逐段产出文本。改写压缩把冗长段落缩短或调整语气。翻译与术语统一在双语项目中保持技术术语一致。校对修正检查错别字、语法、标点和引用格式。这些子任务对模型能力的要求并不相同。脑暴需要发散性温度参数可以调高一些校对需要稳定和精确温度参数要调低最好把待校对文本和规则一起放进上下文。如果不管任务类型都用同一个 800 字提示词、同一个 API 参数产出的质量必然不稳定。下面的表格把常见写作任务、依赖的模型能力和需要配套的技术点做了对应写作任务模型能力依赖需要配套的技术点主题脑暴发散生成、知识广度提示词自由度、温度调高提纲生成结构化组织、逻辑排序输出格式约束、Markdown 模板初稿生成语言组织、上下文保持上下文工程、素材注入改写压缩序列转换、重写示例驱动、单词或字数约束翻译与术语统一跨语言映射术语表、few-shot 示例事实核查与引用检索和上下文定位RAG、引用编号、来源输出多文档摘要长文本理解分块、摘要合并、去重这里的核心判断是LLM Writing 是一个系统不是一次调用。你越早把写作任务拆开越容易定位哪个环节输出不稳定。比如初稿写得不错但事实有误问题通常不在提示词而在素材检索又比如输出总在结尾断掉问题往往在 max_tokens 或上下文截断策略。1.2 我的写作工作流从素材到发布的最小闭环我的技术写作工作流可以简化为下面这条流水线素材收集 - 素材清洗 - 分块 - 向量化 - 向量库 | 需求/选题 - 组装提示词 - 检索增强生成 - 初稿 Markdown - 人工修订 - 发布每一步都有明确产出。素材收集阶段我会把接口文档、旧笔记、源码片段和产品需求整理进同一个目录素材清洗阶段删除无关广告、空行和冗余 HTML 标签分块阶段把长文档切成适合检索的片段向量化阶段用 embedding 模型把文本转成向量检索增强生成阶段把 top k 片段注入提示词让模型基于真实材料输出。这个流程解决了两类问题。第一类是没有来源直接让模型写技术文章它很容易编出不存在的方法名或 API 参数因为模型只能靠训练知识补全。第二类是没有沉淀每篇文章都是一次性 prompt无法复用下个月想写相似主题又要重新构建上下文。引入 RAG 和 LLM Wiki 之后我的历史笔记、已完成文章和所有参考资料都变成了可持续复用的写作素材。2. 运行环境与模型选择API、本地模型和推理引擎怎么搭2.1 API 方式 vs 本地推理方式进入实现之前先要做一次技术选型。LLM Writing 的运行载体主要分两类调用云端 API或者部署本地模型。它们没有绝对优劣只有适不适合当前写作场景。对比维度云端 API本地推理硬件要求低只需网络和 API Key高需要 GPU 或内存足够的 CPU/Mac配置成本低注册账号即可中高需要安装推理框架数据隐私数据出网敏感内容需要评估数据留在本机适合内部文档单次成本按 token 计费主要是硬件电费和折旧模型更新服务方维护升级简单自己拉模型文件版本可锁定可控性部分参数可选依赖服务方可控制精度、上下文、采样参数稳定性依赖网络和服务方限流依赖本机资源可能有 OOM我的建议是先把 API 流程跑通再根据数据敏感度和长期成本决定是否引入本地模型。写作任务对延迟不敏感但对输出稳定性敏感所以无论选哪种方式都要在后端把“模型提示词模板”和“调用参数”固化下来。2.2 本地推理时的精度FP32、FP16、BF16 先搞懂模型权重保存时用多少位来表示一个数值叫精度。本地推理最常见的三种精度是 FP32、FP16 和 BF16。很多模型文件下载页会标注fp16、bf16或q8_0这些后缀直接决定你能不能在当前机器上跑起来。FP32 是单精度浮点数用 1 位符号、8 位指数、23 位尾数表示数值精度高但占用空间大。FP16 是半精度浮点数用 1 位符号、5 位指数、10 位尾数表示数值内存减半但指数范围变小容易出现上溢或下溢。BF16 是 Brain Floating Point用 1 位符号、8 位指数、7 位尾数表示数值指数范围和 FP32 一致但尾数精度更低适合大模型训练和推理。对写作任务来说BF16 和 FP16 都是常用选择。BF16 在大模型场景更稳妥因为它保留了 FP32 的指数范围数值不容易溢出缺点是尾数位少理论上对小数精度要求高的计算会损失细节。写作模型的核心计算是矩阵乘法和 token 概率分布对 FP16 和 BF16 都没有明显障碍真正需要关注的是显存容量。显存占用可以用一个近似公式估算模型权重显存约等于参数量乘以每个参数占用字节数。以 70 亿参数模型为例精度每参数字节7B 模型权重占用典型场景FP324 字节约 28 GB高精度实验FP162 字节约 14 GB多数 GPU 支持良好BF162 字节约 14 GB新 GPU 上更推荐INT81 字节约 7 GB显存受限时使用INT4约 0.5 字节约 3.5 GB消费级设备这只是权重占用实际推理还要加上 KV cache、激活值和框架开销。因此 7B 模型用 FP16 推理建议至少准备 16GB 到 24GB 显存如果只有 8GB可以尝试 INT4 量化或更小的模型。2.3 常用推理框架与配置示例本地推理框架按使用方式可以分为几类Ollama 适合快速体验llama.cpp 适合 CPU 和边缘设备vLLM 适合高吞吐的 API 服务LM Studio 适合 Mac 上的图形化操作。Ollama 的启动方式最简单# 拉取指令模型这里以 llama3.1 为例 ollama pull llama3.1 # 启动本地服务默认 11434 端口 ollama serve # 简单对话测试 ollama run llama3.1 请用三句话解释 RAGOllama 默认提供了 OpenAI 兼容接口写作程序可以直接用chat/completions协议调用from openai import OpenAI client OpenAI( base_urlhttp://localhost:11434/v1, api_keynot-needed, ) response client.chat.completions.create( modelllama3.1, messages[ {role: system, content: 你是一名技术编辑输出要求简洁准确。}, {role: user, content: 把下面段落压缩到 100 字以内...}, ], temperature0.3, max_tokens512, ) print(response.choices[0].message.content)如果使用 vLLM 提供 OpenAI 兼容服务常见启动命令是python -m vllm.entrypoints.openai.api_server \ --model meta-llama/Llama-3.1-8B-Instruct \ --dtype bfloat16 \ --max-model-len 8192启动成功后程序里把base_url指向 vLLM 服务的地址即可。注意不同框架的base_url路径不一定相同常见的是/v1不要漏掉。注意如果你只是做写作任务先不要追求大参数模型。7B 到 14B 的指令模型在自己可接受的硬件上先跑通流程比 70B 模型放不上显存更有实际价值。3. 提示词工程为写作任务建立稳定的输出基线3.1 写作提示词四要素提示词工程不是“把问题写得更客气”而是把模型输出约束到你的工作流需要的格式上。一个稳定的写作提示词至少包含四个部分角色模型以什么身份输出例如“资深技术编辑”。任务这次要完成什么动作例如“压缩、改写、生成提纲”。素材模型必须基于哪些输入可以包含检索结果、用户原文或参考资料。输出约束格式、字数、语气、是否要引用来源。下面是一个可以固化的写作提示词模板你是一名拥有十年经验的技术文档编辑。 你的任务是帮我生成一篇技术博客的“概述”段落。 写作素材 {context} 约束 1. 只能使用素材中出现的信息不要补充任何方法名、版本号和性能数据。 2. 字数控制在 200 到 300 字。 3. 输出为 Markdown 段落不要使用列表。 4. 如果素材不足直接写“素材不足需要补充以下信息...”。关键点在第 1 条和第 4 条。写作类任务最容易出现的问题是幻觉也就是模型把“可能合理的补全”当成事实。明确告诉它“只能使用素材中出现的信息”能显著减少编造第 4 条给模型留了一个“拒绝生成”的出口比让它硬写更安全。3.2 生成参数temperature、top_p、max_tokens 如何配合同一个提示词使用不同采样参数输出风格会完全不同。你需要理解四个常用参数参数作用写作任务推荐值错误表现temperature控制输出随机性0.3 到 0.7过高会产生不相干内容top_p控制候选 token 的累计概率范围0.8 到 0.95过小会导致重复短语max_tokens限制生成的最大 token 数按任务设定过小导致内容被截断presence_penalty / frequency_penalty控制重复内容的惩罚0 到 1过大会导致话题跳跃技术写作建议把 temperature 设为 0.3 到 0.5。脑暴类任务可以调到 0.8 以上但要清楚输出的事实可靠性会下降。max_tokens建议按目标语言和正文长度估算中文一个汉字大约对应 1 到 2 个 token如果你要输出 1000 字max_tokens至少给 1200 到 2000。在 API 调用中这些参数通常是 JSON 里的顶层字段{ model: llama3.1, messages: [ {role: system, content: 你是一名技术编辑。}, {role: user, content: 请改写以下技术段落...} ], temperature: 0.4, top_p: 0.9, max_tokens: 1500 }3.3 用“模板 变量”替代每次即兴提问如果每次写作都临时写提示词很难复现上一次的好结果。更工程化的做法是把提示词存成模板文件用变量填充当前内容。以 Python 为例template 你是资深技术编辑。 请根据素材生成一段技术博客引言。 素材 {context} 输出要求 - 200 字以内 - 只使用素材中的信息 - 输出 Markdown 段落 context \n.join(retrieved_chunks) prompt template.format(contextcontext)这样做有三个好处模板可以放进 Git 仓库做版本管理批量测试时能快速对比不同 prompt 的输出出现质量问题时可以明确知道是哪一版提示词引起的。更严格一点的场景可以要求模型输出 JSON并在程序里校验字段请输出 JSON { title: 标题, summary: 摘要不超过 100 字, outline: [一级标题1, 一级标题2] }模型输出的内容不一定严格合法所以程序侧要做异常处理而不是盲目相信输出。这也是 LLM Writing 工程化和直接用聊天框的重要区别。