尧图网页设计 
1. 从“用 AI 写文章”到“搭一套 LLM 写作工作流”先交代一下这篇文章的由来。最近半年我一直在折腾用 LLM 辅助写技术博客、整理项目笔记和管理碎片化知识。一开始只是打开网页版对话窗口把需求丢进去让模型直接输出一篇长文后来发现这种方式生成的文字表面通顺但里面经常出现概念偏差、版本信息过时、示例代码跑不通等问题。真正把 LLM 当成“写作工具”来用和把它当成“对话玩具”来玩体验完全不同。这篇文章想记录的是我从“调用 API 写一段文字”到“搭建一套完整 LLM 写作与知识管理工作流”的实践过程。内容会覆盖 LLM 的基本概念、本地部署与远程 API 的选型、fp16 / fp32 / bf16 精度对生成结果的影响、RAG 知识库如何帮助写作、Agent 与 MCP 怎么扩展写作能力以及我踩过的坑和最终沉淀下来的工程建议。如果你正在做 AI 应用开发或者想用 LLM 提升自己的写作和知识管理效率这篇文章应该能帮你少走一些弯路。学完之后你会对“LLM 写作”这件事有一个更系统的认知它不只是让 AI 帮你打字而是一套由模型、上下文、知识库、工具链和校验流程组成的系统工程。1.1 什么是 LLM 写作LLM全称 Large Language Model也就是大语言模型。我们平时接触到的 ChatGPT、Claude、文心一言、通义千问、DeepSeek、Kimi 等产品背后都依赖 LLM 来理解和生成文本。LLM 写作就是利用这类模型完成内容创作任务包括但不限于根据关键词或标题生成文章初稿把零散的技术笔记整理成结构化教程对已有文档进行摘要、扩写、改写辅助生成代码注释、README、接口文档将口语化描述转换成正式的技术说明不过真正用 LLM 写作的人很快会发现一个问题直接对话生成的内容常常缺少“上下文记忆”。你在一篇文章里提到的技术栈、项目背景、代码版本模型在下一次对话里可能就忘了。所以后来大家开始研究 RAG检索增强生成、Agent智能体、MCP模型上下文协议这些概念本质上都是为了解决同一个问题如何让 LLM 在写作时能够访问到你自己的知识库、项目文档和外部工具。1.2 为什么需要一套工作流而不是直接让 AI 生成如果只是写一篇 1000 字的小短文直接打开对话窗口让 AI 生成完全够用。但如果是写一篇 5000 字以上的技术教程、项目复盘或学习笔记情况就不一样了。第一技术文章对准确性要求高。模型很容易在版本号、API 参数、依赖关系这些细节上“一本正经地胡说八道”。如果你没有把真实的技术文档、代码片段作为上下文提供给模型它就只能靠训练数据里的记忆去推断出错概率很高。第二技术写作有固定的结构要求。CSDN 上的技术长文通常需要背景介绍、环境准备、核心语法、实战案例、常见问题、最佳实践这些模块。直接让 AI 生成它可能会写出一篇结构完整的文章但内容往往是“万金油”式的通用模板缺少你自己项目的细节。第三效率问题。如果你每次写文章都要从头开始向 AI 解释项目背景、技术栈、版本信息那还不如自己直接写。所以一个成熟的 LLM 写作工作流应该是这样的把个人知识库、项目文档、常用写作模板都存好让 LLM 在写作时自动检索相关内容生成初稿后再由人工校验和修改。2. 环境准备与版本说明在开始搭建 LLM 写作工作流之前先花一点时间梳理需要准备的环境和工具。因为 LLM 领域发展非常快框架版本经常更新这里我不会把某个具体版本写死而是给出选型思路。2.1 操作系统与运行环境我日常使用的环境是 Windows 11 WSL2Ubuntu 22.04同时也在 macOS 上跑过一些实验。如果你的机器只有 Windows建议装一个 WSL2因为很多 AI 相关的开源工具链对 Linux 的兼容性更好。当然纯 Windows 环境也能做只是遇到编译类依赖时会麻烦一些。GPU 方面如果只想体验 LLM API完全不需要本地显卡如果要做本地部署和推理建议至少有一张 8GB 显存以上的 NVIDIA 显卡。显存不够的话可以考虑量化模型或者把推理服务部署到云服务器上。2.2 编程语言与依赖管理LLM 应用开发目前最主流的语言是 Python生态最完善。我本地使用的 Python 版本是 3.10。当然现在 Java 生态里也有 Spring AI 这样的框架适合已经有 Java 后端团队的项目使用。本文的示例以 Python 为主核心代码会尽量做到开箱即用。依赖管理工具推荐使用uv或poetry比 pip 更清晰。如果你不熟悉这些工具直接用 pip 也可以关键是保证依赖隔离不要把所有包都装到全局环境里。# 创建虚拟环境Python 3.10 示例 python3.10 -m venv .venv source .venv/bin/activate # 安装核心依赖 pip install openai pip install langchain pip install chromadb pip install pymupdf2.3 模型 API 与本地模型选型LLM 写作工作流里模型是核心。我的建议是如果条件允许优先使用商业 API稳定性和生成质量都有保障如果涉及敏感数据或者希望完全离线再考虑本地模型。在 API 选择上OpenAI 的接口格式几乎成了行业标准大多数国产模型和开源模型的 API 服务比如 DeepSeek、通义千问、智谱 GLM都兼容 OpenAI 的接口协议。这意味着你只需要修改base_url和api_key就可以无缝切换不同模型服务商。下面是调用 OpenAI 兼容接口的通用写法# 文件路径llm_client.py from openai import OpenAI client OpenAI( base_urlhttps://api.example.com/v1, # 替换为你的模型服务地址 api_keyyour-api-key, # 替换为你的 API Key ) response client.chat.completions.create( modelgpt-4o-mini, messages[ {role: system, content: 你是一名资深技术博客作者擅长用清晰的结构讲解技术概念。}, {role: user, content: 请写一篇关于 Python 装饰器的基础教程包含代码示例。} ], temperature0.7, max_tokens2000, ) print(response.choices[0].message.content)如果你选择本地部署目前比较活跃的开源模型包括 Llama 3、Qwen 2.5、DeepSeek、Mistral 等。推理框架可以用 Ollama、vLLM、llama.cpp。以 Ollama 为例安装后只需要几条命令就能把模型跑起来# 启动 Ollama 服务 ollama serve # 拉取模型并运行以 qwen2.5 为例 ollama pull qwen2.5:7b ollama run qwen2.5:7b2.4 示例项目目录结构为了让后面的实战部分更清晰这里先给出本文示例项目的目录结构llm-writing-workshop/ ├── .env # 环境变量配置 ├── requirements.txt # Python 依赖 ├── config/ │ └── settings.yaml # 配置文件 ├── data/ │ ├── knowledge/ # 个人知识库文档 │ └── output/ # 生成文章输出目录 ├── src/ │ ├── llm_client.py # LLM API 客户端封装 │ ├── knowledge_base.py # 知识库索引与检索 │ ├── writer.py # 写作工作流核心逻辑 │ └── mcp_client.py # MCP 客户端示例 └── scripts/ └── run_writer.py # 命令行入口这个结构不算复杂但足够承载一套最小可运行的 LLM 写作工作流。后面我会一步步把每个文件的核心代码写出来。3. 核心概念拆解精度、上下文与编排框架在正式写代码之前先解释几个在 LLM 写作和 LLM 应用开发中高频出现的关键概念。这些概念直接影响你写出来的程序能不能用、生成质量高不高。3.1 fp16、fp32、bf16 精度问题详解如果你只是调用 API精度问题基本不用关心模型服务商已经帮你处理好了。但如果你在本地推理、微调或部署模型精度选择直接决定显存占用、推理速度和生成质量。先解释一下这几个概念fp32Float32单精度浮点数用 32 位表示一个数值。精度最高但显存占用也最大。fp16Float16半精度浮点数用 16 位表示一个数值。显存占用减半推理速度更快但数值范围较小可能出现精度溢出。bf16BFloat16另一种 16 位浮点格式保留了 fp32 的指数范围但尾数精度降低。它的优势是数值范围与 fp32 接近训练时更稳定因此在大模型训练中经常使用。用一个表格来对比精度类型位宽显存占用数值范围适用场景fp3232位最高大训练精度敏感场景、CPU 推理fp1616位一半较小GPU 推理加速、显存受限场景bf1616位一半与 fp32 接近大模型训练、混合精度训练在本地部署 LLM 时你经常会看到模型文件带有.fp16.bin、.bf16.safetensors这样的后缀。如果显存比较紧张还可以考虑 INT8 或 INT4 量化进一步压缩模型体积但量化程度越高生成质量损失的风险也越大。实际使用中的建议很简单如果你的显卡显存充足比如 24GB 以上且追求最佳生成质量优先选 bf16 或 fp16如果显存只剩 8GB建议选择 4bit 量化模型配合 Ollama 这类推理工具能在普通消费级显卡上跑起来。3.2 上下文长度与写作一致性写技术长文时最影响生成质量的不是模型智商而是上下文长度。模型一次能处理的 token 数量有限超过限制就必须截断或忘记前文内容。上下文长度和写作任务的关系很直接一篇文章越长、涉及的技术点越多就越需要“把关键信息放在上下文中”。比如你要写一篇 Spring AI MCP RAG Agent 的教程如果只给模型一个标题它生成的内容大概率是泛泛而谈但如果你把项目配置文件、核心代码、依赖版本、运行日志都塞进上下文它就能写出贴合你项目的文章。所以LLM 写作工作流的第一个核心思路是通过 RAG 检索的方式把与当前写作主题相关的内容动态注入上下文而不是把整个知识库都塞给模型。3.3 为什么 LLM 应用需要编排框架很多人会有疑问我直接调用 OpenAI SDK 也能做 LLM 应用为什么还要用 LangChain、LlamaIndex、Spring AI 这类编排框架我的理解是编排框架解决的是“多步骤、多工具、多记忆”的复杂度问题。如果只是一个简单的问答机器人直接用 SDK 就够了。但如果是 LLM 写作工作流你需要把用户输入的标题或主题转换成检索查询词从知识库中检索相关文档把检索结果和写作模板拼装成 Prompt调用 LLM 生成初稿把初稿按模板格式化输出记录写作历史和反馈用于后续迭代这些步骤之间的逻辑编排、异常处理、状态管理如果全部手写代码会非常繁琐。框架的价值就是把流程抽象成“链Chain”或“图Graph”让你可以快速搭建和替换组件。不过我个人的建议是不要为了用框架而用框架。如果你的流程只有两步直接写代码更可控。等流程复杂到一定程度再引入框架会舒服很多。4. 搭建一套本地 LLM 辅助写作环境这一节开始进入实战。我会带你搭一个最小可用的 LLM 写作环境包含配置文件、API 客户端封装、知识库索引和命令行入口。4.1 创建项目结构与配置文件首先创建项目目录和配置文件。# 文件路径config/settings.yaml model: provider: openai_compatible base_url: https://api.example.com/v1 api_key_env: LLM_API_KEY model_name: gpt-4o-mini temperature: 0.7 max_tokens: 3000 knowledge_base: data_dir: data/knowledge embedding_model: text-embedding-3-small vector_db_dir: data/vector_store writing: max_context_chars: 8000 output_dir: data/output在.env文件中写入 API Key# 文件路径.env LLM_API_KEYyour-api-key-here4.2 封装 LLM API 客户端接下来封装一个统一的客户端方便后续调用。这里兼容 OpenAI 格式这样模型服务商可以随时切换。# 文件路径src/llm_client.py import os from dotenv import load_dotenv from openai import OpenAI import yaml load_dotenv() def load_config(): with open(config/settings.yaml, r, encodingutf-8) as f: return yaml.safe_load(f) class LLMClient: def __init__(self, config_pathconfig/settings.yaml): config load_config() model_cfg config[model] self.client OpenAI( base_urlmodel_cfg[base_url], api_keyos.getenv(model_cfg[api_key_env]), ) self.model_name model_cfg[model_name] self.temperature model_cfg[temperature] self.max_tokens model_cfg[max_tokens] def chat(self, system_prompt, user_prompt): response self.client.chat.completions.create( modelself.model_name, messages[ {role: system, content: system_prompt}, {role: user, content: user_prompt}, ], temperatureself.temperature, max_tokensself.max_tokens, ) return response.choices[0].message.content if __name__ __main__: client LLMClient() result client.chat( 你是一名严谨的技术文档工程师。, 请用一段话解释什么是 RAG。 ) print(result)运行方式python src/llm_client.py如果一切正常你会在终端看到模型生成的关于 RAG 的解释。这里需要注意base_url和api_key需要按实际服务商替换。4.3 构建个人知识库检索模块知识库是 LLM 写作工作流里最值得花时间做的部分。它的作用是把你的文档、笔记、代码片段向量化在写作时检索出最相关的内容注入上下文。核心思路先读取文档切分为文本块再调用 Embedding 模型向量化存入向量数据库。写作时对用户主题做同样的向量化然后做相似度检索。# 文件路径src/knowledge_base.py from pathlib import Path import chromadb from openai import OpenAI import os from dotenv import load_dotenv load_dotenv() class KnowledgeBase: def __init__(self, data_dirdata/knowledge, persist_dirdata/vector_store): self.client OpenAI() # 使用默认环境变量或者传入 base_url self.data_dir Path(data_dir) self.persist_dir persist_dir self.chroma_client chromadb.PersistentClient(pathpersist_dir) self.collection self.chroma_client.get_or_create_collection(my_knowledge) def add_document(self, file_path): 把单个文档读入并写入向量库。 content Path(file_path).read_text(encodingutf-8) chunks self._split_text(content, chunk_size800, overlap100) embeddings self._embed_texts(chunks) ids [f{Path(file_path).stem}_{i} for i in range(len(chunks))] self.collection.add( idsids, embeddingsembeddings, documentschunks, metadatas[{source: str(file_path)} for _ in chunks] ) def add_directory(self): 批量添加目录下的所有 txt/md 文件。 for ext in [*.txt, *.md]: for file_path in self.data_dir.rglob(ext): print(f正在索引: {file_path}) self.add_document(file_path) def search(self, query, top_k3): 检索与 query 最相关的文档片段。 query_embedding self._embed_texts([query])[0] results self.collection.query( query_embeddings[query_embedding], n_resultstop_k ) return results[documents][0] def _split_text(self, text, chunk_size, overlap): 简单按长度切分文本保留部分重叠避免切断语义。 chunks [] start 0 while start len(text): end start chunk_size chunks.append(text[start:end]) start end - overlap return chunks def _embed_texts(self, texts): 调用 Embedding API 向量化。 response self.client.embeddings.create( modeltext-embedding-3-small, inputtexts ) return [item.embedding for item in response.data] if __name__ __main__: kb KnowledgeBase() kb.add_directory() results kb.search(Spring AI 集成方法) for i, doc in enumerate(results): print(f--- 检索结果 {i1} ---) print(doc[:500])这段代码实现了一个最小可用的 RAG 检索模块。实际项目中你还需要考虑更完善的文本切分策略、重复文档去重、增量更新等问题但核心流程已经完整了。4.4 实现写作编排从主题到成稿写作编排是整个工作流的大脑。它的工作流程是接收写作主题根据主题从知识库检索相关内容把检索结果拼接到写作 Prompt 中调用 LLM 生成初稿将初稿保存到输出目录# 文件路径src/writer.py from pathlib import Path from src.llm_client import LLMClient from src.knowledge_base import KnowledgeBase class LLMWriter: def __init__(self): self.llm LLMClient() self.kb KnowledgeBase() def write_article(self, topic): 根据主题生成技术文章。 context_docs self.kb.search(topic, top_k3) context_text \n\n.join(context_docs) system_prompt ( 你是一名资深技术博客作者。你的文章结构严谨、解释清晰、代码准确。 你会根据提供的参考资料进行写作确保不编造事实。 文章风格适合发布在技术社区语言简练但完整。 ) user_prompt f 请根据以下主题撰写一篇技术文章 【写作主题】 {topic} 【可参考的项目资料】 {context_text} 【写作要求】 1. 文章结构要包含背景介绍、核心概念说明、环境准备、实战示例、常见问题、最佳实践。 2. 代码示例必须完整且格式正确。 3. 如果资料不足以支持某个结论需要在文章中说明。 4. 总字数控制在 3000 字左右。 print(正在调用模型生成文章初稿请稍候...) article self.llm.chat(system_prompt, user_prompt) return article def save_article(self, topic, content): safe_topic .join(c for c in topic if c not in r\/:*?|).strip() output_dir Path(data/output) output_dir.mkdir(parentsTrue, exist_okTrue) output_path output_dir / f{safe_topic}.md output_path.write_text(content, encodingutf-8) print(f文章已保存到: {output_path}) if __name__ __main__: writer LLMWriter() article writer.write_article(LLM 写作工作流的最佳实践) writer.save_article(LLM 写作工作流的最佳实践, article)运行以下命令查看效果python scripts/run_writer.py需要说明的是这个工作流生成的初稿质量高度依赖知识库内容。如果你没有往data/knowledge目录里放足够的资料检索结果为空模型就只能凭空发挥输出质量自然不稳定。4.5 结合 Web 抓取扩展写作素材写技术文章时经常需要参考最新的官方文档、GitHub README 或技术社区文章。你可以用 Python 写一个简单的网页内容抓取函数把抓到的内容处理后存入知识库供后续写作检索使用。# 文件路径src/web_fetcher.py import requests from bs4 import BeautifulSoup def fetch_web_content(url, max_chars5000): 抓取网页正文内容并截断到指定长度。 headers { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 } try: resp requests.get(url, headersheaders, timeout10) resp.encoding resp.apparent_encoding or utf-8 soup BeautifulSoup(resp.text, html.parser) for tag in soup([script, style, nav, footer, aside]): tag.decompose() text soup.get_text(\n, stripTrue) return text[:max_chars] except Exception as e: print(f抓取失败: {url}, 错误: {e}) return if __name__ __main__: content fetch_web_content(https://example.com/docs) print(content[:500])然后你可以把这个内容写入知识库kb KnowledgeBase() kb.add_document(data/knowledge/example.md)通过这种方式你的知识库会不断生长写作素材越来越丰富模型生成的文章也就越来越贴合你的实际需求。5. 用 Agent 思维改造写作流程前面实现的写作编排是线性的检索、拼 Prompt、生成、保存。这个流程对固定模板的文章很有效但遇到需要多步推理、多次调用外部工具的场景就不够用了。比如你想让 LLM 先分析写作主题再自动搜索相关资料再对比多个来源再撰写文档。这就需要引入 Agent 的概念。5.1 Agent 在写作场景中的典型工作方式Agent 可以理解为一个“能自主决定下一步做什么”的 LLM 应用。它不再只是回答你的问题而是会进行一系列思考决定需要调用什么工具观察工具返回结果再继续下一步。在写作场景里Agent 可以做的事情包括判断当前写作主题是否需要更多资料决定是调用知识库检索、Web 搜索还是文档抓取工具在生成初稿前先列出文章大纲并让用户确认生成文章后自动进行格式校验和事实核查实现一个完整的 Agent 框架需要不少代码但在最小场景下你可以用简单的“循环调用”来模拟 Agent 行为让 LLM 输出一个 JSON 格式的动作指令然后你的代码根据指令执行对应工具再把结果返回给模型。# 文件路径src/agent_demo.py import json from src.llm_client import LLMClient from src.knowledge_base import KnowledgeBase from src.web_fetcher import fetch_web_content def run_writing_agent(topic): llm LLMClient() kb KnowledgeBase() # 第一轮让模型决策需要什么工具 decision_prompt f 你是一个写作助手 Agent。针对写作主题“{topic}”你需要决定接下来的行动。 请输出一个 JSON 对象格式如下 {{ need_knowledge: true, need_web: false, reason: 简要说明理由 }} 注意只需要输出 JSON不要输出其他内容。 decision_text llm.chat(你是严谨的 AI Agent 决策器。, decision_prompt) try: decision json.loads(decision_text) except json.JSONDecodeError: print(模型未输出合法 JSON回退为默认行为) decision {need_knowledge: True, need_web: False} # 第二轮根据决策收集资料 context_parts [] if decision.get(need_knowledge): results kb.search(topic, top_k2) context_parts.extend(results) if decision.get(need_web): web_content fetch_web_content(https://example.com/search?q topic) context_parts.append(web_content) context_text \n\n.join(context_parts) # 第三轮生成最终文章 article llm.chat( 你是一名技术写作专家。, f基于以下资料撰写主题为「{topic}」的技术文章\n\n{context_text} ) return article if __name__ __main__: result run_writing_agent(RAG 在知识库中的应用) print(result)这个例子虽然简陋但它展示了 Agent 写作的核心逻辑模型不再是直接生成最终答案而是先通过“思考”决定工具调用策略再由代码执行工具最后综合上下文生成内容。5.2 MCP 如何扩展 LLM 的工具调用能力MCP全称 Model Context Protocol即模型上下文协议。它解决的是 LLM 与外部系统连接时的协议统一问题。在没有 MCP 之前你想让 LLM 连接数据库、调用 Git、读取本地文件、操控浏览器都需要为每个工具单独编写适配代码。MCP 让这些工具以标准化的方式暴露给模型大大降低了集成成本。在实际写作工作流中MCP 可以帮你实现这些能力连接本地笔记软件直接读取 Obsidian 中的笔记调用翻译工具让 LLM 写作时自动完成中英对照连接代码仓库让 LLM 读取项目源码来写技术文档调用浏览器工具让 LLM 抓取网页内容作为写作素材如果你对 MCP 感兴趣可以先从官方的 Python SDK 入手写一个最简单的 MCP 客户端连接一个远程服务。这里给出一个参考代码框架# 文件路径src/mcp_client.py # 注意MCP 生态更新较快以下代码为示意请以官方 SDK 文档为准。 import asyncio async def main(): # 伪代码连接一个 MCP 服务并调用工具 # client await mcp_client.connect(http://localhost:8080/mcp) # tools await client.list_tools() # result await client.call_tool(fetch_web_content, {url: https://example.com}) print(MCP 客户端示例) if __name__ __main__: asyncio.run(main())这里的要点是MCP 的核心价值在于标准化它并不改变 LLM 的能力上限但能大幅降低工具集成的复杂度让开发者可以用一套协议连接各种各样的外部系统。6. 常见问题与排查思路在搭建和运行 LLM 写作工作流时我遇到过不少问题。下面整理几个高频问题并给出排查思路。问题现象常见原因解决思路调用 API 返回 401 错误API Key 无效或未正确加载检查环境变量是否正确设置打印os.getenv(LLM_API_KEY)确认生成文章内容空洞、泛泛而谈知识库未构建或检索结果为空检查data/knowledge是否有文档执行知识库索引脚本打印检索结果确认相关度中文乱码或编码报错文件读写编码不一致统一使用encodingutf-8读取网页内容时用apparent_encoding检测上下文超长报错一次注入知识库内容过多通过max_context_chars限制或优化文本切分逻辑减少检索返回块数模型输出不稳定同一主题两次生成差异大temperature 设置偏高技术文档建议将 temperature 调低到 0.3~0.5提高确定性本地推理时显存不足模型精度选择不当使用 bf16 或 INT4 量化模型减少上下文长度或换用更小的模型向量数据库查询返回乱码文本切分跨度过大语义不完整优化_split_text的重叠参数或使用语义切分工具API 调用超时网络原因或模型响应过长设置合理的超时时间拆分长文生成任务为多段生成针对“LLM 文本向量 API 未配置”这个常见问题我单独说明一下。很多初学者在跑 RAG 代码时只配置了对话模型的 API Key却忽略了 Embedding 模型的配置。解决办法是确认你的模型服务商是否提供 Embedding API并在.env中配置对应的 Key。如果使用的是兼容 OpenAI 格式的服务一般需要在环境变量中设置OPENAI_API_KEY或者在代码中显式传入api_key参数。7. 最佳实践与工程建议写完一套可运行的 LLM 写作工作流之后有些事情值得在正式项目中格外注意。7.1 知识库设计要面向场景不要试图把所有资料都塞进知识库。准确地说知识库应该围绕你的高频写作主题来组织。比如你经常写 Java 后端教程就把 Spring 相关的项目结构、版本兼容性、核心配置单独维护你经常写 Python 数据处理文章就把常用库的用法和踩坑记录整理成独立文档。文本切分同样需要针对场景调整。短文档适合较小的切分块长文档需要更大的块和重叠区域。如果切分太碎语义容易断裂如果切分太大检索精度会下降。建议先跑几个测试观察实际检索结果再评估。7.2 Prompt 设计是质量上限模型能力只是质量下限Prompt 决定质量上限。同一个模型用不同的 Prompt 写技术文章效果差别会非常大。我在实践中的经验是明确告诉模型它是什么角色明确文章的目标读者明确写作时必须使用的参考资料明确不能编造事实明确输出格式和结构要求必要时给出正面示例和反面示例7.3 生成内容必须人工校验LLM 写作生成的内容和真正可发布的内容之间永远隔着一道人工校验的门槛。尤其是技术文章版本号、运行结果、代码示例必须逐字核对。我在实践中会这样做先让模型生成初稿把文章中的代码片段摘出来在自己的环境里全部运行一遍对不确认的技术细节做二次检索确认无误后再排版发布7.4 安全与权限边界如果你的 LLM 写作工作流涉及公司项目文档或敏感信息务必注意安全边界不要把内部文档直接发送到外部 API 服务优先选择私有化部署的模型或国内合规的模型服务对知识库做权限分级不同角色只能检索对应目录API Key 不要硬编码在代码中统一放在环境变量或密钥管理服务中涉及自动化工具调用时遵循最小权限原则避免给 Agent 过高的系统操作权限7.5 版本管理与可维护性LLM 相关依赖更新非常频繁一个看似弱小的版本升级就可能带来行为变化。建议把requirements.txt中的依赖版本锁死定期手动升级并做回归测试。同时将知识库文档纳入 Git 管理方便追溯每次内容变更。8. 下一步学习建议文章写到这里一条从“用 LLM 对话”到“搭建 LLM 写作工作流”的路线已经比较清晰了。如果你希望继续深入我建议按下面的顺序去学习熟悉 Prompt Engineering 的基本技巧这是所有 LLM 应用的基础理解 RAG 的完整流程从向量化到召回、重排、注入上下文掌握 Embedding 模型和向量数据库的基本原理学习 Agent 的核心循环思考、调用工具、观察结果、再决策了解 MCP 协议尝试把常用的外部工具统一接入关注量化推理和精度问题如果打算本地部署模型最后一定要多做项目在实践中积累“哪些方案真正好用”的经验我还想特别提一下最近比较热门的“LLM Wiki”思路。很多人开始把自己的知识库、学习笔记、项目文档组织成类似 Wiki 的结构再配合 RAG 和写作 Agent建立一套个人知识管理系统。这种方式非常适合技术博主和开发人员因为它把“输入知识”和“输出文章”打通了。如果你也打算在自己的机器上从零搭建这套体系建议从最基础的开始先把一个能调通 LLM API 的最小脚本跑起来再逐步加入知识库检索、Agent 编排、MCP 工具集成。不要一上来就追求完整的大而全系统迭代式开发才是长期能坚持下去的方式。我在这个项目里最大的感受是LLM 写作并不是“让 AI 替你写文章”而是“让 AI 帮你把素材整理得更快、把初稿写得更全、把结构搭得更稳”。真正决定文章质量的依然是你自己的知识积累、判断力和对细节的校验。希望这篇文章的搭建思路和代码示例能给你一些启发后面折腾出属于自己的 LLM 写作工作流时也欢迎回来分享你的经验和踩坑记录。 从AI对话到LLM写作工作流：RAG、Agent与MCP实战指南
1. 从“用 AI 写文章”到“搭一套 LLM 写作工作流”先交代一下这篇文章的由来。最近半年我一直在折腾用 LLM 辅助写技术博客、整理项目笔记和管理碎片化知识。一开始只是打开网页版对话窗口把需求丢进去让模型直接输出一篇长文后来发现这种方式生成的文字表面通顺但里面经常出现概念偏差、版本信息过时、示例代码跑不通等问题。真正把 LLM 当成“写作工具”来用和把它当成“对话玩具”来玩体验完全不同。这篇文章想记录的是我从“调用 API 写一段文字”到“搭建一套完整 LLM 写作与知识管理工作流”的实践过程。内容会覆盖 LLM 的基本概念、本地部署与远程 API 的选型、fp16 / fp32 / bf16 精度对生成结果的影响、RAG 知识库如何帮助写作、Agent 与 MCP 怎么扩展写作能力以及我踩过的坑和最终沉淀下来的工程建议。如果你正在做 AI 应用开发或者想用 LLM 提升自己的写作和知识管理效率这篇文章应该能帮你少走一些弯路。学完之后你会对“LLM 写作”这件事有一个更系统的认知它不只是让 AI 帮你打字而是一套由模型、上下文、知识库、工具链和校验流程组成的系统工程。1.1 什么是 LLM 写作LLM全称 Large Language Model也就是大语言模型。我们平时接触到的 ChatGPT、Claude、文心一言、通义千问、DeepSeek、Kimi 等产品背后都依赖 LLM 来理解和生成文本。LLM 写作就是利用这类模型完成内容创作任务包括但不限于根据关键词或标题生成文章初稿把零散的技术笔记整理成结构化教程对已有文档进行摘要、扩写、改写辅助生成代码注释、README、接口文档将口语化描述转换成正式的技术说明不过真正用 LLM 写作的人很快会发现一个问题直接对话生成的内容常常缺少“上下文记忆”。你在一篇文章里提到的技术栈、项目背景、代码版本模型在下一次对话里可能就忘了。所以后来大家开始研究 RAG检索增强生成、Agent智能体、MCP模型上下文协议这些概念本质上都是为了解决同一个问题如何让 LLM 在写作时能够访问到你自己的知识库、项目文档和外部工具。1.2 为什么需要一套工作流而不是直接让 AI 生成如果只是写一篇 1000 字的小短文直接打开对话窗口让 AI 生成完全够用。但如果是写一篇 5000 字以上的技术教程、项目复盘或学习笔记情况就不一样了。第一技术文章对准确性要求高。模型很容易在版本号、API 参数、依赖关系这些细节上“一本正经地胡说八道”。如果你没有把真实的技术文档、代码片段作为上下文提供给模型它就只能靠训练数据里的记忆去推断出错概率很高。第二技术写作有固定的结构要求。CSDN 上的技术长文通常需要背景介绍、环境准备、核心语法、实战案例、常见问题、最佳实践这些模块。直接让 AI 生成它可能会写出一篇结构完整的文章但内容往往是“万金油”式的通用模板缺少你自己项目的细节。第三效率问题。如果你每次写文章都要从头开始向 AI 解释项目背景、技术栈、版本信息那还不如自己直接写。所以一个成熟的 LLM 写作工作流应该是这样的把个人知识库、项目文档、常用写作模板都存好让 LLM 在写作时自动检索相关内容生成初稿后再由人工校验和修改。2. 环境准备与版本说明在开始搭建 LLM 写作工作流之前先花一点时间梳理需要准备的环境和工具。因为 LLM 领域发展非常快框架版本经常更新这里我不会把某个具体版本写死而是给出选型思路。2.1 操作系统与运行环境我日常使用的环境是 Windows 11 WSL2Ubuntu 22.04同时也在 macOS 上跑过一些实验。如果你的机器只有 Windows建议装一个 WSL2因为很多 AI 相关的开源工具链对 Linux 的兼容性更好。当然纯 Windows 环境也能做只是遇到编译类依赖时会麻烦一些。GPU 方面如果只想体验 LLM API完全不需要本地显卡如果要做本地部署和推理建议至少有一张 8GB 显存以上的 NVIDIA 显卡。显存不够的话可以考虑量化模型或者把推理服务部署到云服务器上。2.2 编程语言与依赖管理LLM 应用开发目前最主流的语言是 Python生态最完善。我本地使用的 Python 版本是 3.10。当然现在 Java 生态里也有 Spring AI 这样的框架适合已经有 Java 后端团队的项目使用。本文的示例以 Python 为主核心代码会尽量做到开箱即用。依赖管理工具推荐使用uv或poetry比 pip 更清晰。如果你不熟悉这些工具直接用 pip 也可以关键是保证依赖隔离不要把所有包都装到全局环境里。# 创建虚拟环境Python 3.10 示例 python3.10 -m venv .venv source .venv/bin/activate # 安装核心依赖 pip install openai pip install langchain pip install chromadb pip install pymupdf2.3 模型 API 与本地模型选型LLM 写作工作流里模型是核心。我的建议是如果条件允许优先使用商业 API稳定性和生成质量都有保障如果涉及敏感数据或者希望完全离线再考虑本地模型。在 API 选择上OpenAI 的接口格式几乎成了行业标准大多数国产模型和开源模型的 API 服务比如 DeepSeek、通义千问、智谱 GLM都兼容 OpenAI 的接口协议。这意味着你只需要修改base_url和api_key就可以无缝切换不同模型服务商。下面是调用 OpenAI 兼容接口的通用写法# 文件路径llm_client.py from openai import OpenAI client OpenAI( base_urlhttps://api.example.com/v1, # 替换为你的模型服务地址 api_keyyour-api-key, # 替换为你的 API Key ) response client.chat.completions.create( modelgpt-4o-mini, messages[ {role: system, content: 你是一名资深技术博客作者擅长用清晰的结构讲解技术概念。}, {role: user, content: 请写一篇关于 Python 装饰器的基础教程包含代码示例。} ], temperature0.7, max_tokens2000, ) print(response.choices[0].message.content)如果你选择本地部署目前比较活跃的开源模型包括 Llama 3、Qwen 2.5、DeepSeek、Mistral 等。推理框架可以用 Ollama、vLLM、llama.cpp。以 Ollama 为例安装后只需要几条命令就能把模型跑起来# 启动 Ollama 服务 ollama serve # 拉取模型并运行以 qwen2.5 为例 ollama pull qwen2.5:7b ollama run qwen2.5:7b2.4 示例项目目录结构为了让后面的实战部分更清晰这里先给出本文示例项目的目录结构llm-writing-workshop/ ├── .env # 环境变量配置 ├── requirements.txt # Python 依赖 ├── config/ │ └── settings.yaml # 配置文件 ├── data/ │ ├── knowledge/ # 个人知识库文档 │ └── output/ # 生成文章输出目录 ├── src/ │ ├── llm_client.py # LLM API 客户端封装 │ ├── knowledge_base.py # 知识库索引与检索 │ ├── writer.py # 写作工作流核心逻辑 │ └── mcp_client.py # MCP 客户端示例 └── scripts/ └── run_writer.py # 命令行入口这个结构不算复杂但足够承载一套最小可运行的 LLM 写作工作流。后面我会一步步把每个文件的核心代码写出来。3. 核心概念拆解精度、上下文与编排框架在正式写代码之前先解释几个在 LLM 写作和 LLM 应用开发中高频出现的关键概念。这些概念直接影响你写出来的程序能不能用、生成质量高不高。3.1 fp16、fp32、bf16 精度问题详解如果你只是调用 API精度问题基本不用关心模型服务商已经帮你处理好了。但如果你在本地推理、微调或部署模型精度选择直接决定显存占用、推理速度和生成质量。先解释一下这几个概念fp32Float32单精度浮点数用 32 位表示一个数值。精度最高但显存占用也最大。fp16Float16半精度浮点数用 16 位表示一个数值。显存占用减半推理速度更快但数值范围较小可能出现精度溢出。bf16BFloat16另一种 16 位浮点格式保留了 fp32 的指数范围但尾数精度降低。它的优势是数值范围与 fp32 接近训练时更稳定因此在大模型训练中经常使用。用一个表格来对比精度类型位宽显存占用数值范围适用场景fp3232位最高大训练精度敏感场景、CPU 推理fp1616位一半较小GPU 推理加速、显存受限场景bf1616位一半与 fp32 接近大模型训练、混合精度训练在本地部署 LLM 时你经常会看到模型文件带有.fp16.bin、.bf16.safetensors这样的后缀。如果显存比较紧张还可以考虑 INT8 或 INT4 量化进一步压缩模型体积但量化程度越高生成质量损失的风险也越大。实际使用中的建议很简单如果你的显卡显存充足比如 24GB 以上且追求最佳生成质量优先选 bf16 或 fp16如果显存只剩 8GB建议选择 4bit 量化模型配合 Ollama 这类推理工具能在普通消费级显卡上跑起来。3.2 上下文长度与写作一致性写技术长文时最影响生成质量的不是模型智商而是上下文长度。模型一次能处理的 token 数量有限超过限制就必须截断或忘记前文内容。上下文长度和写作任务的关系很直接一篇文章越长、涉及的技术点越多就越需要“把关键信息放在上下文中”。比如你要写一篇 Spring AI MCP RAG Agent 的教程如果只给模型一个标题它生成的内容大概率是泛泛而谈但如果你把项目配置文件、核心代码、依赖版本、运行日志都塞进上下文它就能写出贴合你项目的文章。所以LLM 写作工作流的第一个核心思路是通过 RAG 检索的方式把与当前写作主题相关的内容动态注入上下文而不是把整个知识库都塞给模型。3.3 为什么 LLM 应用需要编排框架很多人会有疑问我直接调用 OpenAI SDK 也能做 LLM 应用为什么还要用 LangChain、LlamaIndex、Spring AI 这类编排框架我的理解是编排框架解决的是“多步骤、多工具、多记忆”的复杂度问题。如果只是一个简单的问答机器人直接用 SDK 就够了。但如果是 LLM 写作工作流你需要把用户输入的标题或主题转换成检索查询词从知识库中检索相关文档把检索结果和写作模板拼装成 Prompt调用 LLM 生成初稿把初稿按模板格式化输出记录写作历史和反馈用于后续迭代这些步骤之间的逻辑编排、异常处理、状态管理如果全部手写代码会非常繁琐。框架的价值就是把流程抽象成“链Chain”或“图Graph”让你可以快速搭建和替换组件。不过我个人的建议是不要为了用框架而用框架。如果你的流程只有两步直接写代码更可控。等流程复杂到一定程度再引入框架会舒服很多。4. 搭建一套本地 LLM 辅助写作环境这一节开始进入实战。我会带你搭一个最小可用的 LLM 写作环境包含配置文件、API 客户端封装、知识库索引和命令行入口。4.1 创建项目结构与配置文件首先创建项目目录和配置文件。# 文件路径config/settings.yaml model: provider: openai_compatible base_url: https://api.example.com/v1 api_key_env: LLM_API_KEY model_name: gpt-4o-mini temperature: 0.7 max_tokens: 3000 knowledge_base: data_dir: data/knowledge embedding_model: text-embedding-3-small vector_db_dir: data/vector_store writing: max_context_chars: 8000 output_dir: data/output在.env文件中写入 API Key# 文件路径.env LLM_API_KEYyour-api-key-here4.2 封装 LLM API 客户端接下来封装一个统一的客户端方便后续调用。这里兼容 OpenAI 格式这样模型服务商可以随时切换。# 文件路径src/llm_client.py import os from dotenv import load_dotenv from openai import OpenAI import yaml load_dotenv() def load_config(): with open(config/settings.yaml, r, encodingutf-8) as f: return yaml.safe_load(f) class LLMClient: def __init__(self, config_pathconfig/settings.yaml): config load_config() model_cfg config[model] self.client OpenAI( base_urlmodel_cfg[base_url], api_keyos.getenv(model_cfg[api_key_env]), ) self.model_name model_cfg[model_name] self.temperature model_cfg[temperature] self.max_tokens model_cfg[max_tokens] def chat(self, system_prompt, user_prompt): response self.client.chat.completions.create( modelself.model_name, messages[ {role: system, content: system_prompt}, {role: user, content: user_prompt}, ], temperatureself.temperature, max_tokensself.max_tokens, ) return response.choices[0].message.content if __name__ __main__: client LLMClient() result client.chat( 你是一名严谨的技术文档工程师。, 请用一段话解释什么是 RAG。 ) print(result)运行方式python src/llm_client.py如果一切正常你会在终端看到模型生成的关于 RAG 的解释。这里需要注意base_url和api_key需要按实际服务商替换。4.3 构建个人知识库检索模块知识库是 LLM 写作工作流里最值得花时间做的部分。它的作用是把你的文档、笔记、代码片段向量化在写作时检索出最相关的内容注入上下文。核心思路先读取文档切分为文本块再调用 Embedding 模型向量化存入向量数据库。写作时对用户主题做同样的向量化然后做相似度检索。# 文件路径src/knowledge_base.py from pathlib import Path import chromadb from openai import OpenAI import os from dotenv import load_dotenv load_dotenv() class KnowledgeBase: def __init__(self, data_dirdata/knowledge, persist_dirdata/vector_store): self.client OpenAI() # 使用默认环境变量或者传入 base_url self.data_dir Path(data_dir) self.persist_dir persist_dir self.chroma_client chromadb.PersistentClient(pathpersist_dir) self.collection self.chroma_client.get_or_create_collection(my_knowledge) def add_document(self, file_path): 把单个文档读入并写入向量库。 content Path(file_path).read_text(encodingutf-8) chunks self._split_text(content, chunk_size800, overlap100) embeddings self._embed_texts(chunks) ids [f{Path(file_path).stem}_{i} for i in range(len(chunks))] self.collection.add( idsids, embeddingsembeddings, documentschunks, metadatas[{source: str(file_path)} for _ in chunks] ) def add_directory(self): 批量添加目录下的所有 txt/md 文件。 for ext in [*.txt, *.md]: for file_path in self.data_dir.rglob(ext): print(f正在索引: {file_path}) self.add_document(file_path) def search(self, query, top_k3): 检索与 query 最相关的文档片段。 query_embedding self._embed_texts([query])[0] results self.collection.query( query_embeddings[query_embedding], n_resultstop_k ) return results[documents][0] def _split_text(self, text, chunk_size, overlap): 简单按长度切分文本保留部分重叠避免切断语义。 chunks [] start 0 while start len(text): end start chunk_size chunks.append(text[start:end]) start end - overlap return chunks def _embed_texts(self, texts): 调用 Embedding API 向量化。 response self.client.embeddings.create( modeltext-embedding-3-small, inputtexts ) return [item.embedding for item in response.data] if __name__ __main__: kb KnowledgeBase() kb.add_directory() results kb.search(Spring AI 集成方法) for i, doc in enumerate(results): print(f--- 检索结果 {i1} ---) print(doc[:500])这段代码实现了一个最小可用的 RAG 检索模块。实际项目中你还需要考虑更完善的文本切分策略、重复文档去重、增量更新等问题但核心流程已经完整了。4.4 实现写作编排从主题到成稿写作编排是整个工作流的大脑。它的工作流程是接收写作主题根据主题从知识库检索相关内容把检索结果拼接到写作 Prompt 中调用 LLM 生成初稿将初稿保存到输出目录# 文件路径src/writer.py from pathlib import Path from src.llm_client import LLMClient from src.knowledge_base import KnowledgeBase class LLMWriter: def __init__(self): self.llm LLMClient() self.kb KnowledgeBase() def write_article(self, topic): 根据主题生成技术文章。 context_docs self.kb.search(topic, top_k3) context_text \n\n.join(context_docs) system_prompt ( 你是一名资深技术博客作者。你的文章结构严谨、解释清晰、代码准确。 你会根据提供的参考资料进行写作确保不编造事实。 文章风格适合发布在技术社区语言简练但完整。 ) user_prompt f 请根据以下主题撰写一篇技术文章 【写作主题】 {topic} 【可参考的项目资料】 {context_text} 【写作要求】 1. 文章结构要包含背景介绍、核心概念说明、环境准备、实战示例、常见问题、最佳实践。 2. 代码示例必须完整且格式正确。 3. 如果资料不足以支持某个结论需要在文章中说明。 4. 总字数控制在 3000 字左右。 print(正在调用模型生成文章初稿请稍候...) article self.llm.chat(system_prompt, user_prompt) return article def save_article(self, topic, content): safe_topic .join(c for c in topic if c not in r\/:*?|).strip() output_dir Path(data/output) output_dir.mkdir(parentsTrue, exist_okTrue) output_path output_dir / f{safe_topic}.md output_path.write_text(content, encodingutf-8) print(f文章已保存到: {output_path}) if __name__ __main__: writer LLMWriter() article writer.write_article(LLM 写作工作流的最佳实践) writer.save_article(LLM 写作工作流的最佳实践, article)运行以下命令查看效果python scripts/run_writer.py需要说明的是这个工作流生成的初稿质量高度依赖知识库内容。如果你没有往data/knowledge目录里放足够的资料检索结果为空模型就只能凭空发挥输出质量自然不稳定。4.5 结合 Web 抓取扩展写作素材写技术文章时经常需要参考最新的官方文档、GitHub README 或技术社区文章。你可以用 Python 写一个简单的网页内容抓取函数把抓到的内容处理后存入知识库供后续写作检索使用。# 文件路径src/web_fetcher.py import requests from bs4 import BeautifulSoup def fetch_web_content(url, max_chars5000): 抓取网页正文内容并截断到指定长度。 headers { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 } try: resp requests.get(url, headersheaders, timeout10) resp.encoding resp.apparent_encoding or utf-8 soup BeautifulSoup(resp.text, html.parser) for tag in soup([script, style, nav, footer, aside]): tag.decompose() text soup.get_text(\n, stripTrue) return text[:max_chars] except Exception as e: print(f抓取失败: {url}, 错误: {e}) return if __name__ __main__: content fetch_web_content(https://example.com/docs) print(content[:500])然后你可以把这个内容写入知识库kb KnowledgeBase() kb.add_document(data/knowledge/example.md)通过这种方式你的知识库会不断生长写作素材越来越丰富模型生成的文章也就越来越贴合你的实际需求。5. 用 Agent 思维改造写作流程前面实现的写作编排是线性的检索、拼 Prompt、生成、保存。这个流程对固定模板的文章很有效但遇到需要多步推理、多次调用外部工具的场景就不够用了。比如你想让 LLM 先分析写作主题再自动搜索相关资料再对比多个来源再撰写文档。这就需要引入 Agent 的概念。5.1 Agent 在写作场景中的典型工作方式Agent 可以理解为一个“能自主决定下一步做什么”的 LLM 应用。它不再只是回答你的问题而是会进行一系列思考决定需要调用什么工具观察工具返回结果再继续下一步。在写作场景里Agent 可以做的事情包括判断当前写作主题是否需要更多资料决定是调用知识库检索、Web 搜索还是文档抓取工具在生成初稿前先列出文章大纲并让用户确认生成文章后自动进行格式校验和事实核查实现一个完整的 Agent 框架需要不少代码但在最小场景下你可以用简单的“循环调用”来模拟 Agent 行为让 LLM 输出一个 JSON 格式的动作指令然后你的代码根据指令执行对应工具再把结果返回给模型。# 文件路径src/agent_demo.py import json from src.llm_client import LLMClient from src.knowledge_base import KnowledgeBase from src.web_fetcher import fetch_web_content def run_writing_agent(topic): llm LLMClient() kb KnowledgeBase() # 第一轮让模型决策需要什么工具 decision_prompt f 你是一个写作助手 Agent。针对写作主题“{topic}”你需要决定接下来的行动。 请输出一个 JSON 对象格式如下 {{ need_knowledge: true, need_web: false, reason: 简要说明理由 }} 注意只需要输出 JSON不要输出其他内容。 decision_text llm.chat(你是严谨的 AI Agent 决策器。, decision_prompt) try: decision json.loads(decision_text) except json.JSONDecodeError: print(模型未输出合法 JSON回退为默认行为) decision {need_knowledge: True, need_web: False} # 第二轮根据决策收集资料 context_parts [] if decision.get(need_knowledge): results kb.search(topic, top_k2) context_parts.extend(results) if decision.get(need_web): web_content fetch_web_content(https://example.com/search?q topic) context_parts.append(web_content) context_text \n\n.join(context_parts) # 第三轮生成最终文章 article llm.chat( 你是一名技术写作专家。, f基于以下资料撰写主题为「{topic}」的技术文章\n\n{context_text} ) return article if __name__ __main__: result run_writing_agent(RAG 在知识库中的应用) print(result)这个例子虽然简陋但它展示了 Agent 写作的核心逻辑模型不再是直接生成最终答案而是先通过“思考”决定工具调用策略再由代码执行工具最后综合上下文生成内容。5.2 MCP 如何扩展 LLM 的工具调用能力MCP全称 Model Context Protocol即模型上下文协议。它解决的是 LLM 与外部系统连接时的协议统一问题。在没有 MCP 之前你想让 LLM 连接数据库、调用 Git、读取本地文件、操控浏览器都需要为每个工具单独编写适配代码。MCP 让这些工具以标准化的方式暴露给模型大大降低了集成成本。在实际写作工作流中MCP 可以帮你实现这些能力连接本地笔记软件直接读取 Obsidian 中的笔记调用翻译工具让 LLM 写作时自动完成中英对照连接代码仓库让 LLM 读取项目源码来写技术文档调用浏览器工具让 LLM 抓取网页内容作为写作素材如果你对 MCP 感兴趣可以先从官方的 Python SDK 入手写一个最简单的 MCP 客户端连接一个远程服务。这里给出一个参考代码框架# 文件路径src/mcp_client.py # 注意MCP 生态更新较快以下代码为示意请以官方 SDK 文档为准。 import asyncio async def main(): # 伪代码连接一个 MCP 服务并调用工具 # client await mcp_client.connect(http://localhost:8080/mcp) # tools await client.list_tools() # result await client.call_tool(fetch_web_content, {url: https://example.com}) print(MCP 客户端示例) if __name__ __main__: asyncio.run(main())这里的要点是MCP 的核心价值在于标准化它并不改变 LLM 的能力上限但能大幅降低工具集成的复杂度让开发者可以用一套协议连接各种各样的外部系统。6. 常见问题与排查思路在搭建和运行 LLM 写作工作流时我遇到过不少问题。下面整理几个高频问题并给出排查思路。问题现象常见原因解决思路调用 API 返回 401 错误API Key 无效或未正确加载检查环境变量是否正确设置打印os.getenv(LLM_API_KEY)确认生成文章内容空洞、泛泛而谈知识库未构建或检索结果为空检查data/knowledge是否有文档执行知识库索引脚本打印检索结果确认相关度中文乱码或编码报错文件读写编码不一致统一使用encodingutf-8读取网页内容时用apparent_encoding检测上下文超长报错一次注入知识库内容过多通过max_context_chars限制或优化文本切分逻辑减少检索返回块数模型输出不稳定同一主题两次生成差异大temperature 设置偏高技术文档建议将 temperature 调低到 0.3~0.5提高确定性本地推理时显存不足模型精度选择不当使用 bf16 或 INT4 量化模型减少上下文长度或换用更小的模型向量数据库查询返回乱码文本切分跨度过大语义不完整优化_split_text的重叠参数或使用语义切分工具API 调用超时网络原因或模型响应过长设置合理的超时时间拆分长文生成任务为多段生成针对“LLM 文本向量 API 未配置”这个常见问题我单独说明一下。很多初学者在跑 RAG 代码时只配置了对话模型的 API Key却忽略了 Embedding 模型的配置。解决办法是确认你的模型服务商是否提供 Embedding API并在.env中配置对应的 Key。如果使用的是兼容 OpenAI 格式的服务一般需要在环境变量中设置OPENAI_API_KEY或者在代码中显式传入api_key参数。7. 最佳实践与工程建议写完一套可运行的 LLM 写作工作流之后有些事情值得在正式项目中格外注意。7.1 知识库设计要面向场景不要试图把所有资料都塞进知识库。准确地说知识库应该围绕你的高频写作主题来组织。比如你经常写 Java 后端教程就把 Spring 相关的项目结构、版本兼容性、核心配置单独维护你经常写 Python 数据处理文章就把常用库的用法和踩坑记录整理成独立文档。文本切分同样需要针对场景调整。短文档适合较小的切分块长文档需要更大的块和重叠区域。如果切分太碎语义容易断裂如果切分太大检索精度会下降。建议先跑几个测试观察实际检索结果再评估。7.2 Prompt 设计是质量上限模型能力只是质量下限Prompt 决定质量上限。同一个模型用不同的 Prompt 写技术文章效果差别会非常大。我在实践中的经验是明确告诉模型它是什么角色明确文章的目标读者明确写作时必须使用的参考资料明确不能编造事实明确输出格式和结构要求必要时给出正面示例和反面示例7.3 生成内容必须人工校验LLM 写作生成的内容和真正可发布的内容之间永远隔着一道人工校验的门槛。尤其是技术文章版本号、运行结果、代码示例必须逐字核对。我在实践中会这样做先让模型生成初稿把文章中的代码片段摘出来在自己的环境里全部运行一遍对不确认的技术细节做二次检索确认无误后再排版发布7.4 安全与权限边界如果你的 LLM 写作工作流涉及公司项目文档或敏感信息务必注意安全边界不要把内部文档直接发送到外部 API 服务优先选择私有化部署的模型或国内合规的模型服务对知识库做权限分级不同角色只能检索对应目录API Key 不要硬编码在代码中统一放在环境变量或密钥管理服务中涉及自动化工具调用时遵循最小权限原则避免给 Agent 过高的系统操作权限7.5 版本管理与可维护性LLM 相关依赖更新非常频繁一个看似弱小的版本升级就可能带来行为变化。建议把requirements.txt中的依赖版本锁死定期手动升级并做回归测试。同时将知识库文档纳入 Git 管理方便追溯每次内容变更。8. 下一步学习建议文章写到这里一条从“用 LLM 对话”到“搭建 LLM 写作工作流”的路线已经比较清晰了。如果你希望继续深入我建议按下面的顺序去学习熟悉 Prompt Engineering 的基本技巧这是所有 LLM 应用的基础理解 RAG 的完整流程从向量化到召回、重排、注入上下文掌握 Embedding 模型和向量数据库的基本原理学习 Agent 的核心循环思考、调用工具、观察结果、再决策了解 MCP 协议尝试把常用的外部工具统一接入关注量化推理和精度问题如果打算本地部署模型最后一定要多做项目在实践中积累“哪些方案真正好用”的经验我还想特别提一下最近比较热门的“LLM Wiki”思路。很多人开始把自己的知识库、学习笔记、项目文档组织成类似 Wiki 的结构再配合 RAG 和写作 Agent建立一套个人知识管理系统。这种方式非常适合技术博主和开发人员因为它把“输入知识”和“输出文章”打通了。如果你也打算在自己的机器上从零搭建这套体系建议从最基础的开始先把一个能调通 LLM API 的最小脚本跑起来再逐步加入知识库检索、Agent 编排、MCP 工具集成。不要一上来就追求完整的大而全系统迭代式开发才是长期能坚持下去的方式。我在这个项目里最大的感受是LLM 写作并不是“让 AI 替你写文章”而是“让 AI 帮你把素材整理得更快、把初稿写得更全、把结构搭得更稳”。真正决定文章质量的依然是你自己的知识积累、判断力和对细节的校验。希望这篇文章的搭建思路和代码示例能给你一些启发后面折腾出属于自己的 LLM 写作工作流时也欢迎回来分享你的经验和踩坑记录。