最近 Hacker News 上有个讨论热度不低的帖子Ask HN: Do you use LLMs for non-coding related work?翻译过来就是除了写代码你会把 LLM 用在哪些正经干活的地方程序员对 LLM 的默认印象通常停留在 Copilot、Cline、Cursor 这类写代码工具上。但真实使用场景里LLM 被拿去做邮件草稿、翻译、会议纪要、报销单抽取、Excel 清洗、知识库整理、测试数据生成的案例一点都不少。这篇博客就从这个问题出发把 LLM 非编码应用的典型场景、接入方式、接口调用、批量任务、资源占用和排查方法整理成一份可以照着做的清单。文章偏工程视角不聊太多概念重点放在怎么用、怎么验证、怎么避坑。1. 核心能力速览LLM 非编码工作流能做什么先说结论LLM 在非编码方向的核心价值是把非结构化信息转成结构化结果或者把一种文本形式转成另一种文本形式。这跟写代码时“把需求转成代码”是同一类能力只是输出对象变了。能力项说明典型任务文本摘要、翻译改写、邮件/周报润色、会议纪要整理、信息抽取、表格清洗、OCR 结果二次修正、知识库问答、语音转写结果整理输入形式纯文本、PDF、Word、Excel、图片 OCR 结果、语音转写文本、网页正文输出形式摘要文本、结构化 JSON、Markdown 文档、标签字段、翻译结果、检索答案使用方式网页对话、API 调用、本地推理、RAG 知识库、自动化脚本、批量任务队列推荐环境API 方式基本无硬件门槛本地推理需要 GPU 或大内存 CPU具体以模型版本为准是否支持批量任务可以API 和本地推理都适合做目录批量处理关键是做好限速和重试是否支持接口 API主流模型服务都提供 OpenAI 兼容接口本地推理框架通常也支持适合场景个人知识管理、运营文案、数据分析、文档处理、信息归档、多语言沟通不适合场景需要严格事实核对、实时性要求极高、有明确隐私合规要求的场景从功能看这篇文章会覆盖的实操内容包括API 调用、本地部署、RAG 知识库搭建、批量任务脚本、功能验证方法、显存和性能观察方式。如果你现在只想把某个重复性文本工作交给 LLM可以直接跳到第 4 节和第 6 节。2. 典型非编码场景与使用边界很多人觉得 LLM 只有在编程任务里才有确定性其实非编码场景同样可以做得比较稳只是要对“稳”有正确预期。2.1 适合用 LLM 的场景文本摘要与会议纪要把长文档、会议转写稿、采访录音转文字后的内容压缩成结构化结论。这类任务对格式要求低对事实完整度要求高适合用 LLM 先出初稿再人工复核。翻译与本地化技术文档、产品文案、邮件往来。相比传统翻译工具LLM 能同时保持术语一致性和语气统一配合术语表效果更好。信息抽取与表单处理从邮件中抽出发票号、金额、日期从简历中抽出姓名、岗位、工作年限从合同中抽出关键条款。这类任务最适合输出 JSON方便后续进数据库。Excel / CSV 数据清洗把“混在一起的姓名和手机号”拆成两列把“2024年8月5日”统一变成“2024-08-05”LLM 能按描述直接生成处理脚本也能直接输出清洗后的数据片段。知识库问答与个人 Wiki 整理把本地文档做成 RAG 知识库后可以像聊天一样搜资料、做内容关联。常见的落地方式是 Obsidian LLM 插件或者自建一套向量库 问答服务。邮件与消息回复根据上下文草拟回复、调整语气、压缩篇幅。这里注意能帮你写不等于能替你判断发送前把关必须人来做。2.2 不适合用 LLM 的场景需要 100% 准确计算的场景金额计算、日期核对、库存盘点直接交给普通 LLM 有风险。强事实核查场景医疗建议、法律判例引用、新闻发布LLM 可能一本正经编造出处。实时性要求极高的场景股价监控、服务器告警判断LLM 的延迟和不确定性不适合做唯一决策源。敏感个人信息处理身份证号、银行卡号、病历、未成年人信息等未经脱敏和授权不要直接上传到在线模型服务。2.3 使用边界与合规提醒非编码任务往往涉及别人写的内容比如客户邮件、公司合同、内部会议录音。使用前先确认两点你是否有权处理这些数据数据是否允许发送到外部 API。本地部署可以降低数据外传风险但不能把“本地”当成“可以随便用他人数据”的理由。涉及人脸、声音、具体个人身份信息时还要遵守个人信息保护相关要求。3. 环境准备与前置条件非编码 LLM 应用的部署方式比纯编码场景更灵活核心是先分清你用 API 还是本地推理。3.1 API 方式的准备清单如果使用在线模型服务本地只需要一个能跑脚本的环境。操作系统Windows / macOS / Linux 均可。Python3.10 或更高版本。依赖库requests、openai、pandas、pypdf。网络能正常访问模型服务接口代理设置需要按公司网络策略调整。API Key从模型服务商控制台创建注意不要提交到 Git 仓库。这个方式对硬件没有要求普通办公电脑就能跑通。3.2 本地推理方式的准备清单如果数据不能出内网或者要做高频批量处理可以考虑本地推理。操作系统Linux 优先Windows 需要提前确认 GPU 驱动和运行环境。Python3.10 或更高版本。CUDA / 显卡驱动NVIDIA 显卡建议提前装好官方驱动50 系显卡等新硬件需要确认推理框架是否已适配。推理框架按项目文档选择常见的是llama.cpp、Ollama、vLLM、Transformers。模型文件需要单独下载模型权重模型格式和量化版本要和推理框架匹配。磁盘空间模型文件通常从几 GB 到几十 GB 不等需要提前确认磁盘剩余空间。内存或显存具体占用以模型参数、量化位数和上下文长度为准不要轻信某个固定数字先跑一次才知道。如果本机只有 CPU也不是不能用选小模型或量化模型响应速度会慢一些但文本摘要、简单抽取这类任务仍然能跑。3.3 通用环境检查命令先确认 Python 和 GPU 驱动是否正常python --version nvidia-smi再把依赖装上pip install requests openai pandas pypdf如果是在内网环境pip安装失败时要先检查镜像源或离线安装包。4. 接入与部署方式API、本地推理、知识库与工作流接入方式决定了你后续怎么调、怎么维护。我建议先选 API 把流程跑通再考虑本地化。4.1 直接调用 OpenAI 兼容 API现在的模型服务大多提供 OpenAI 兼容接口。下面是一个最小调用示例先用它验证连通性import requests api_url https://your-api-endpoint/v1/chat/completions api_key your-api-key payload { model: your-model-name, messages: [ {role: user, content: 把下面这段会议记录整理成三条行动项\n1. 张三说下周要完成数据库迁移\n2. 李四提到客户反馈登录页加载慢\n3. 王五建议周五前给出测试方案} ], temperature: 0.3 } headers { Authorization: fBearer {api_key}, Content-Type: application/json } response requests.post(api_url, jsonpayload, headersheaders, timeout120) print(response.json())返回结果一般长这样{ choices: [ { message: { role: assistant, content: 1. 张三下周完成数据库迁移\n2. 李四跟进客户登录页加载缓慢问题\n3. 王五周五前输出测试方案 } } ] }如果返回401说明 API Key 或鉴权方式不对返回404检查接口地址和模型名返回429说明触发了限流需要加等待或重试。4.2 本地推理接入以 Ollama 这类常见本地推理工具为例流程是安装服务、拉取模型、调用本地接口。# 启动本地模型服务 ollama pull qwen3:8b ollama run qwen3:8b如果服务已启动接口地址通常是http://localhost:11434也可以直接用 OpenAI 兼容路径请求curl http://localhost:11434/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen3:8b, messages: [ {role: user, content: 把这段文字翻译成英文今天下午三点开会} ] }启动后要注意显存占用。可以使用nvidia-smi查看 GPU 进程也可以用ollama ps查看当前加载的模型占用。如果显存不够优先换更小的模型或使用量化版本也可以把部分层 offload 到 CPU。4.3 RAG 知识库接入非编码场景里RAG 是把 LLM 从“聊天工具”变成“业务工具”的关键。简单理解就是先把你的文档切块、向量化存到向量库用户提问时先检索相关片段再让 LLM 基于片段回答。一个通用流程是用pypdf读取 PDF 文本。按 500 到 800 字切成片段。调用 embedding 接口生成向量。把向量存入向量数据库。提问时检索 Top-K 片段拼进 prompt。from pypdf import PdfReader reader PdfReader(contract.pdf) text \n.join(page.extract_text() for page in reader.pages) # 按固定长度切块生产环境建议用专用切分器 chunk_size 600 chunks [text[i:ichunk_size] for i in range(0, len(text), chunk_size)] for i, chunk in enumerate(chunks): print(fchunk {i}: {chunk[:50]}...)注意PDF 里的扫描件需要先做 OCR否则extract_text()只能拿到空白。图片型 PDF 先过 OCR再把 OCR 结果交到 RAG 流程。4.4 工作流编排与 MCP如果你想把 LLM 接进自己的工具链可以关注 MCPModel Context Protocol这类标准化接口。它解决的是“LLM 怎么读取本地文件、调用外部工具、访问数据库”的问题。比如你写一个 MCP 服务把内部文档、Excel 数据源、甚至 ComfyUI 的图像生成接口包一层LLM 就能统一调度这些资源。MCP 不一定要求所有模型都跑在同一台电脑上。ComfyUI 和 LLM 可以分开部署比如 LLM 负责提示词生成和结果评价ComfyUI 在另一台 GPU 机器上负责出图中间走 HTTP 接口或消息队列。分开部署的好处是资源隔离缺点是延迟更高、接口对接更复杂。5. 功能测试与效果验证跑通只是第一步真正决定能不能用的是输出质量。下面给出一套通用验证流程。5.1 摘要与会议纪要测试测试目的确认 LLM 能把长文本压缩成有结构的要点。输入一个会议记录片段今天讨论了用户反馈的问题。登录页加载时间太长 用户多次投诉。张三建议做静态资源缓存李四提出 可以先做接口耗时监控王五说需要在下周三前给出 优化方案。会上还提到数据库迁移计划可能要顺延。运行一个摘要 promptprompt f 请把下面的会议记录整理成三条行动项每条包含负责人、截止时间和动作。 会议记录 {meeting_text} 判断标准是否提取出“登录页加载慢”这个核心问题。是否把张三、李四、王五的动作分清楚。是否保留“下周三前给出优化方案”这个时间点。如果有遗漏可以补充“不要遗漏时间点”这类指令或者改用结构化输出让模型返回 JSON。5.2 信息抽取与 JSON 输出测试测试目的确认模型能按固定 schema 输出字段。prompt 从下面的邮件中抽取字段返回 JSON { invoice_number: 发票号, amount: 金额, due_date: 截止日期, supplier: 供应商 } 邮件内容 关于发票 INV-2024-0815金额为 12000 元请于 2024-09-30 前完成支付。 供应商为北京华信科技有限公司。 预期输出{ invoice_number: INV-2024-0815, amount: 12000, due_date: 2024-09-30, supplier: 北京华信科技有限公司 }判断成功的标准字段名和返回 JSON 完全匹配。金额不要带多余货币符号或按你要求预留格式。日期格式统一。如果抽出的字段不稳定建议在 prompt 里给出示例输出也就是 few-shot。一次给一个典型例子错误率会明显下降。5.3 翻译与术语一致性测试测试目的确认多语言沟通场景下术语不被随意替换。可以让模型先使用你提供的术语表再开始翻译。例如prompt 翻译下面的技术说明文档遇到产品名、项目代号时保持原文不翻译。 缩写直接保留。 文档 用户可以在设备管理页面查看设备的运行状态、网络连接和固件版本。 判断标准产品名、专有名词是否保留。中文长句是否被切分得更符合目标语言习惯。数值、单位、日期是否保持一致。5.4 批量文档测试批量测试可以从 3 到 5 个样例开始不要一上来跑 1000 个文件。样例要覆盖正常数据、边界数据、错误数据。例如抽发票字段时至少准备一张模糊图片、一张缺字段图片、一张正常图片。只有这三种情况都通过再扩展数量。6. 接口 API 与批量任务非编码任务的日常使用最后大概率要落在脚本和批处理上。下面给出一个通用批量处理方案。6.1 目录批量任务示例假设你有一个input/目录里面全是待整理的文章或会议纪要文本需要把所有文件转成统一格式的摘要并输出到output/目录。import os import json import time import requests API_URL https://your-api-endpoint/v1/chat/completions API_KEY your-api-key def summarize_text(text: str) - str: payload { model: your-model-name, messages: [ {role: user, content: f请用 200 字以内总结下面内容\n{text}} ], temperature: 0.3 } headers { Authorization: fBearer {API_KEY}, Content-Type: application/json } for attempt in range(3): try: resp requests.post(API_URL, jsonpayload, headersheaders, timeout120) resp.raise_for_status() return resp.json()[choices][0][message][content] except Exception as e: print(fattempt {attempt 1} failed: {e}) time.sleep(2 ** attempt) return os.makedirs(output, exist_okTrue) for filename in os.listdir(input): if not filename.endswith(.txt): continue with open(os.path.join(input, filename), r, encodingutf-8) as f: content f.read() result summarize_text(content) with open(os.path.join(output, filename.replace(.txt, _summary.md)), w, encodingutf-8) as f: f.write(result) print(fdone: {filename})这个脚本做了三件值得参考的事失败重试、指数退避、输出独立目录。批量任务看起来简单真正跑起来最容易出问题的是限流和文件编码。6.2 批量任务配置化如果任务量大建议把参数抽到配置文件里比如 YAMLinput_dir: ./input output_dir: ./output model: your-model-name temperature: 0.3 max_retries: 3 timeout: 120 concurrency: 2然后在脚本里用yaml.safe_load读取避免把路径和 API 参数写死在代码里。6.3 异步队列与失败重试当任务数量到几千条时用concurrent.futures并发请求要谨慎容易触发限流。更稳妥的做法是做一个任务队列记录每个文件的处理状态失败则重新入队。最简单的方式是先把所有文件名写到一个task.jsonl每完成一行就追加写结果。{file: 001.txt, status: pending} {file: 002.txt, status: done, result: ...}处理时发现status不是done就重新执行。这个模式不用引入复杂框架但对排查大规模任务很有用。7. 资源占用与性能观察资源占用是本地部署最容易踩坑的地方先说结论不要直接照搬别人报的显存数字不同模型、不同量化、不同上下文长度差别很大。7.1 显存占用怎么看本地推理时用nvidia-smi看显存占用nvidia-smi重点看Memory-Usage和Processes。同一个模型跑长文本时显存占用会明显上升因为 KV Cache 和上下文长度正相关。如果出现CUDA out of memory优先降低上下文长度或者换更小的模型。7.2 CPU 推理与 GPU 推理差异CPU 推理不是不能用但速度会差很多。对非编码场景如果只是偶尔处理几封邮件CPU 推理可以接受。如果是批量处理几百个 PDF建议上 GPU 或改用 API。需要观察的指标有单次请求延迟从发出请求到拿到完整响应的耗时。首 token 延迟对长文档摘要影响不大但对交互式问答影响明显。吞吐量每分钟能处理多少条文本。内存占用CPU 模式主要看内存GPU 模式主要看显存。7.3 降低资源占用的方法使用量化模型比如 4bit 或 8bit。控制输入长度提前做文本切块。减少并发数避免多个请求同时占显存。清空历史会话长对话会持续占用上下文窗口。GPU 显存不足时把部分层放到 CPU但速度会下降。7.4 端口冲突与进程残留本地推理服务启动后如果再次启动同一端口会报address already in use。排查方式# Linux / macOS lsof -i :11434# Windows PowerShell netstat -ano | findstr 11434找到占用进程后确认是不是旧服务再决定关闭或换端口。不要直接kill -9所有进程避免把其他服务也带掉。8. 常见问题与排查方法以下是本地部署和 API 调用最常见的几类问题。问题现象可能原因排查方式解决方案API 返回 401API Key 错误或未配置检查请求头 Authorization重新生成 API Key避免提交到 GitAPI 返回 429触发限流查看响应头 Retry-After增加重试间隔或降低并发本地模型启动很慢模型较大或首次加载观察启动日志和磁盘 IO换量化模型增加内存或显存显存不足模型过大或上下文过长nvidia-smi查看占用换小模型、降上下文、加 offload输出 JSON 格式不固定prompt 没有约束或模型能力不足打印原始返回内容使用 JSON mode加 few-shotPDF 抽取不到文字PDF 是扫描件打开 PDF 看是否图片先用 OCR 再进入 RAG 流程批量任务中途卡住单条请求超时查看日志中正在处理的文件加超时与重试使用任务队列中文摘要质量差提示词信息不足检查原始输入和输出补充领域背景加输出格式要求端口被占用上一个服务未退出lsof -i或netstat关闭旧进程或修改启动端口内网安装依赖失败PyPI 源不可达查看 pip 错误信息配置内网镜像或离线安装包排查的基本原则先看日志再复现最小用例不要在大批量任务里调试。比如 JSON 输出不稳定先用一条固定 prompt 在网页端或脚本里复现确认模型行为后再改参数。9. 最佳实践与使用建议非编码 LLM 应用能不能落地很多时候不是模型能力问题而是工程习惯问题。先跑最小用例不要一开始就搭建完整 RAG 平台。先把一个文件、一个 prompt 跑通确认返回结果符合要求再往上加功能。保留一套最小可运行配置写好一个requirements.txt和一个示例脚本保证新机器能快速复现。不然三个月后你自己也忘了当初怎么配的。输入、中间结果、输出分目录管理建议分成input/、processed/、output/、logs/。批量任务出问题时能快速定位是哪个文件处理失败。批量任务一定加日志和重试记录每一条任务的状态、请求时间、错误信息重试采用指数退避。接口服务要限制访问范围如果对内网提供 API不要让服务暴露到公网给接口加鉴权否则容易被人扫到盗刷额度。涉及人脸、声音、版权素材时必须确认授权非编码任务经常处理带人名的文本、合同、会议录音这些数据不是“公开素材”。使用前确认授权输出结果也要注意是否包含敏感信息。发布或商用前要做效果复核LLM 生成的摘要、翻译、抽取结果不能直接作为正式交付物。至少做一次抽样人工核对抽到的错误率决定能不能上线。用结构化输出降低下游解析成本信息抽取任务优先让模型返回 JSON而不是返回一段带标题的文本否则后处理会非常痛苦。不要把多条业务规则塞进一个 prompt尽量让每条 prompt 只做一件事。比如“先抽取字段再翻译”会让错误率上升。拆成两步每步单独验证。10. 总结与下一步回到 HN 那个问题人们确实在用 LLM 做大量非编码相关的工作而且做得比较深的用户普遍不是把 LLM 当成聊天框而是把它当成一个被提示词、接口和脚本约束过的文本处理服务。这篇文章值得你带走的两点一是先明确任务类型文本摘要、信息抽取、格式转换、知识库问答对应不同的接入方式二是先跑通最小用例再上批量整个过程要保留日志和可复现配置。如果你现在刚想动手建议从“把一份 PDF 转成结构化 JSON”开始。这是最难也最容易出效果的任务跑通之后邮件、Excel、会议记录的处理都会顺很多。下一步可以继续扩展的方向是接入 RAG 做长期知识库、用 MCP 把内部系统串起来、加异步队列处理千条级任务。每一步都不难关键是先跑通第一个。 LLM非编码应用实战：从API调用到RAG知识库与批量任务
最近 Hacker News 上有个讨论热度不低的帖子Ask HN: Do you use LLMs for non-coding related work?翻译过来就是除了写代码你会把 LLM 用在哪些正经干活的地方程序员对 LLM 的默认印象通常停留在 Copilot、Cline、Cursor 这类写代码工具上。但真实使用场景里LLM 被拿去做邮件草稿、翻译、会议纪要、报销单抽取、Excel 清洗、知识库整理、测试数据生成的案例一点都不少。这篇博客就从这个问题出发把 LLM 非编码应用的典型场景、接入方式、接口调用、批量任务、资源占用和排查方法整理成一份可以照着做的清单。文章偏工程视角不聊太多概念重点放在怎么用、怎么验证、怎么避坑。1. 核心能力速览LLM 非编码工作流能做什么先说结论LLM 在非编码方向的核心价值是把非结构化信息转成结构化结果或者把一种文本形式转成另一种文本形式。这跟写代码时“把需求转成代码”是同一类能力只是输出对象变了。能力项说明典型任务文本摘要、翻译改写、邮件/周报润色、会议纪要整理、信息抽取、表格清洗、OCR 结果二次修正、知识库问答、语音转写结果整理输入形式纯文本、PDF、Word、Excel、图片 OCR 结果、语音转写文本、网页正文输出形式摘要文本、结构化 JSON、Markdown 文档、标签字段、翻译结果、检索答案使用方式网页对话、API 调用、本地推理、RAG 知识库、自动化脚本、批量任务队列推荐环境API 方式基本无硬件门槛本地推理需要 GPU 或大内存 CPU具体以模型版本为准是否支持批量任务可以API 和本地推理都适合做目录批量处理关键是做好限速和重试是否支持接口 API主流模型服务都提供 OpenAI 兼容接口本地推理框架通常也支持适合场景个人知识管理、运营文案、数据分析、文档处理、信息归档、多语言沟通不适合场景需要严格事实核对、实时性要求极高、有明确隐私合规要求的场景从功能看这篇文章会覆盖的实操内容包括API 调用、本地部署、RAG 知识库搭建、批量任务脚本、功能验证方法、显存和性能观察方式。如果你现在只想把某个重复性文本工作交给 LLM可以直接跳到第 4 节和第 6 节。2. 典型非编码场景与使用边界很多人觉得 LLM 只有在编程任务里才有确定性其实非编码场景同样可以做得比较稳只是要对“稳”有正确预期。2.1 适合用 LLM 的场景文本摘要与会议纪要把长文档、会议转写稿、采访录音转文字后的内容压缩成结构化结论。这类任务对格式要求低对事实完整度要求高适合用 LLM 先出初稿再人工复核。翻译与本地化技术文档、产品文案、邮件往来。相比传统翻译工具LLM 能同时保持术语一致性和语气统一配合术语表效果更好。信息抽取与表单处理从邮件中抽出发票号、金额、日期从简历中抽出姓名、岗位、工作年限从合同中抽出关键条款。这类任务最适合输出 JSON方便后续进数据库。Excel / CSV 数据清洗把“混在一起的姓名和手机号”拆成两列把“2024年8月5日”统一变成“2024-08-05”LLM 能按描述直接生成处理脚本也能直接输出清洗后的数据片段。知识库问答与个人 Wiki 整理把本地文档做成 RAG 知识库后可以像聊天一样搜资料、做内容关联。常见的落地方式是 Obsidian LLM 插件或者自建一套向量库 问答服务。邮件与消息回复根据上下文草拟回复、调整语气、压缩篇幅。这里注意能帮你写不等于能替你判断发送前把关必须人来做。2.2 不适合用 LLM 的场景需要 100% 准确计算的场景金额计算、日期核对、库存盘点直接交给普通 LLM 有风险。强事实核查场景医疗建议、法律判例引用、新闻发布LLM 可能一本正经编造出处。实时性要求极高的场景股价监控、服务器告警判断LLM 的延迟和不确定性不适合做唯一决策源。敏感个人信息处理身份证号、银行卡号、病历、未成年人信息等未经脱敏和授权不要直接上传到在线模型服务。2.3 使用边界与合规提醒非编码任务往往涉及别人写的内容比如客户邮件、公司合同、内部会议录音。使用前先确认两点你是否有权处理这些数据数据是否允许发送到外部 API。本地部署可以降低数据外传风险但不能把“本地”当成“可以随便用他人数据”的理由。涉及人脸、声音、具体个人身份信息时还要遵守个人信息保护相关要求。3. 环境准备与前置条件非编码 LLM 应用的部署方式比纯编码场景更灵活核心是先分清你用 API 还是本地推理。3.1 API 方式的准备清单如果使用在线模型服务本地只需要一个能跑脚本的环境。操作系统Windows / macOS / Linux 均可。Python3.10 或更高版本。依赖库requests、openai、pandas、pypdf。网络能正常访问模型服务接口代理设置需要按公司网络策略调整。API Key从模型服务商控制台创建注意不要提交到 Git 仓库。这个方式对硬件没有要求普通办公电脑就能跑通。3.2 本地推理方式的准备清单如果数据不能出内网或者要做高频批量处理可以考虑本地推理。操作系统Linux 优先Windows 需要提前确认 GPU 驱动和运行环境。Python3.10 或更高版本。CUDA / 显卡驱动NVIDIA 显卡建议提前装好官方驱动50 系显卡等新硬件需要确认推理框架是否已适配。推理框架按项目文档选择常见的是llama.cpp、Ollama、vLLM、Transformers。模型文件需要单独下载模型权重模型格式和量化版本要和推理框架匹配。磁盘空间模型文件通常从几 GB 到几十 GB 不等需要提前确认磁盘剩余空间。内存或显存具体占用以模型参数、量化位数和上下文长度为准不要轻信某个固定数字先跑一次才知道。如果本机只有 CPU也不是不能用选小模型或量化模型响应速度会慢一些但文本摘要、简单抽取这类任务仍然能跑。3.3 通用环境检查命令先确认 Python 和 GPU 驱动是否正常python --version nvidia-smi再把依赖装上pip install requests openai pandas pypdf如果是在内网环境pip安装失败时要先检查镜像源或离线安装包。4. 接入与部署方式API、本地推理、知识库与工作流接入方式决定了你后续怎么调、怎么维护。我建议先选 API 把流程跑通再考虑本地化。4.1 直接调用 OpenAI 兼容 API现在的模型服务大多提供 OpenAI 兼容接口。下面是一个最小调用示例先用它验证连通性import requests api_url https://your-api-endpoint/v1/chat/completions api_key your-api-key payload { model: your-model-name, messages: [ {role: user, content: 把下面这段会议记录整理成三条行动项\n1. 张三说下周要完成数据库迁移\n2. 李四提到客户反馈登录页加载慢\n3. 王五建议周五前给出测试方案} ], temperature: 0.3 } headers { Authorization: fBearer {api_key}, Content-Type: application/json } response requests.post(api_url, jsonpayload, headersheaders, timeout120) print(response.json())返回结果一般长这样{ choices: [ { message: { role: assistant, content: 1. 张三下周完成数据库迁移\n2. 李四跟进客户登录页加载缓慢问题\n3. 王五周五前输出测试方案 } } ] }如果返回401说明 API Key 或鉴权方式不对返回404检查接口地址和模型名返回429说明触发了限流需要加等待或重试。4.2 本地推理接入以 Ollama 这类常见本地推理工具为例流程是安装服务、拉取模型、调用本地接口。# 启动本地模型服务 ollama pull qwen3:8b ollama run qwen3:8b如果服务已启动接口地址通常是http://localhost:11434也可以直接用 OpenAI 兼容路径请求curl http://localhost:11434/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen3:8b, messages: [ {role: user, content: 把这段文字翻译成英文今天下午三点开会} ] }启动后要注意显存占用。可以使用nvidia-smi查看 GPU 进程也可以用ollama ps查看当前加载的模型占用。如果显存不够优先换更小的模型或使用量化版本也可以把部分层 offload 到 CPU。4.3 RAG 知识库接入非编码场景里RAG 是把 LLM 从“聊天工具”变成“业务工具”的关键。简单理解就是先把你的文档切块、向量化存到向量库用户提问时先检索相关片段再让 LLM 基于片段回答。一个通用流程是用pypdf读取 PDF 文本。按 500 到 800 字切成片段。调用 embedding 接口生成向量。把向量存入向量数据库。提问时检索 Top-K 片段拼进 prompt。from pypdf import PdfReader reader PdfReader(contract.pdf) text \n.join(page.extract_text() for page in reader.pages) # 按固定长度切块生产环境建议用专用切分器 chunk_size 600 chunks [text[i:ichunk_size] for i in range(0, len(text), chunk_size)] for i, chunk in enumerate(chunks): print(fchunk {i}: {chunk[:50]}...)注意PDF 里的扫描件需要先做 OCR否则extract_text()只能拿到空白。图片型 PDF 先过 OCR再把 OCR 结果交到 RAG 流程。4.4 工作流编排与 MCP如果你想把 LLM 接进自己的工具链可以关注 MCPModel Context Protocol这类标准化接口。它解决的是“LLM 怎么读取本地文件、调用外部工具、访问数据库”的问题。比如你写一个 MCP 服务把内部文档、Excel 数据源、甚至 ComfyUI 的图像生成接口包一层LLM 就能统一调度这些资源。MCP 不一定要求所有模型都跑在同一台电脑上。ComfyUI 和 LLM 可以分开部署比如 LLM 负责提示词生成和结果评价ComfyUI 在另一台 GPU 机器上负责出图中间走 HTTP 接口或消息队列。分开部署的好处是资源隔离缺点是延迟更高、接口对接更复杂。5. 功能测试与效果验证跑通只是第一步真正决定能不能用的是输出质量。下面给出一套通用验证流程。5.1 摘要与会议纪要测试测试目的确认 LLM 能把长文本压缩成有结构的要点。输入一个会议记录片段今天讨论了用户反馈的问题。登录页加载时间太长 用户多次投诉。张三建议做静态资源缓存李四提出 可以先做接口耗时监控王五说需要在下周三前给出 优化方案。会上还提到数据库迁移计划可能要顺延。运行一个摘要 promptprompt f 请把下面的会议记录整理成三条行动项每条包含负责人、截止时间和动作。 会议记录 {meeting_text} 判断标准是否提取出“登录页加载慢”这个核心问题。是否把张三、李四、王五的动作分清楚。是否保留“下周三前给出优化方案”这个时间点。如果有遗漏可以补充“不要遗漏时间点”这类指令或者改用结构化输出让模型返回 JSON。5.2 信息抽取与 JSON 输出测试测试目的确认模型能按固定 schema 输出字段。prompt 从下面的邮件中抽取字段返回 JSON { invoice_number: 发票号, amount: 金额, due_date: 截止日期, supplier: 供应商 } 邮件内容 关于发票 INV-2024-0815金额为 12000 元请于 2024-09-30 前完成支付。 供应商为北京华信科技有限公司。 预期输出{ invoice_number: INV-2024-0815, amount: 12000, due_date: 2024-09-30, supplier: 北京华信科技有限公司 }判断成功的标准字段名和返回 JSON 完全匹配。金额不要带多余货币符号或按你要求预留格式。日期格式统一。如果抽出的字段不稳定建议在 prompt 里给出示例输出也就是 few-shot。一次给一个典型例子错误率会明显下降。5.3 翻译与术语一致性测试测试目的确认多语言沟通场景下术语不被随意替换。可以让模型先使用你提供的术语表再开始翻译。例如prompt 翻译下面的技术说明文档遇到产品名、项目代号时保持原文不翻译。 缩写直接保留。 文档 用户可以在设备管理页面查看设备的运行状态、网络连接和固件版本。 判断标准产品名、专有名词是否保留。中文长句是否被切分得更符合目标语言习惯。数值、单位、日期是否保持一致。5.4 批量文档测试批量测试可以从 3 到 5 个样例开始不要一上来跑 1000 个文件。样例要覆盖正常数据、边界数据、错误数据。例如抽发票字段时至少准备一张模糊图片、一张缺字段图片、一张正常图片。只有这三种情况都通过再扩展数量。6. 接口 API 与批量任务非编码任务的日常使用最后大概率要落在脚本和批处理上。下面给出一个通用批量处理方案。6.1 目录批量任务示例假设你有一个input/目录里面全是待整理的文章或会议纪要文本需要把所有文件转成统一格式的摘要并输出到output/目录。import os import json import time import requests API_URL https://your-api-endpoint/v1/chat/completions API_KEY your-api-key def summarize_text(text: str) - str: payload { model: your-model-name, messages: [ {role: user, content: f请用 200 字以内总结下面内容\n{text}} ], temperature: 0.3 } headers { Authorization: fBearer {API_KEY}, Content-Type: application/json } for attempt in range(3): try: resp requests.post(API_URL, jsonpayload, headersheaders, timeout120) resp.raise_for_status() return resp.json()[choices][0][message][content] except Exception as e: print(fattempt {attempt 1} failed: {e}) time.sleep(2 ** attempt) return os.makedirs(output, exist_okTrue) for filename in os.listdir(input): if not filename.endswith(.txt): continue with open(os.path.join(input, filename), r, encodingutf-8) as f: content f.read() result summarize_text(content) with open(os.path.join(output, filename.replace(.txt, _summary.md)), w, encodingutf-8) as f: f.write(result) print(fdone: {filename})这个脚本做了三件值得参考的事失败重试、指数退避、输出独立目录。批量任务看起来简单真正跑起来最容易出问题的是限流和文件编码。6.2 批量任务配置化如果任务量大建议把参数抽到配置文件里比如 YAMLinput_dir: ./input output_dir: ./output model: your-model-name temperature: 0.3 max_retries: 3 timeout: 120 concurrency: 2然后在脚本里用yaml.safe_load读取避免把路径和 API 参数写死在代码里。6.3 异步队列与失败重试当任务数量到几千条时用concurrent.futures并发请求要谨慎容易触发限流。更稳妥的做法是做一个任务队列记录每个文件的处理状态失败则重新入队。最简单的方式是先把所有文件名写到一个task.jsonl每完成一行就追加写结果。{file: 001.txt, status: pending} {file: 002.txt, status: done, result: ...}处理时发现status不是done就重新执行。这个模式不用引入复杂框架但对排查大规模任务很有用。7. 资源占用与性能观察资源占用是本地部署最容易踩坑的地方先说结论不要直接照搬别人报的显存数字不同模型、不同量化、不同上下文长度差别很大。7.1 显存占用怎么看本地推理时用nvidia-smi看显存占用nvidia-smi重点看Memory-Usage和Processes。同一个模型跑长文本时显存占用会明显上升因为 KV Cache 和上下文长度正相关。如果出现CUDA out of memory优先降低上下文长度或者换更小的模型。7.2 CPU 推理与 GPU 推理差异CPU 推理不是不能用但速度会差很多。对非编码场景如果只是偶尔处理几封邮件CPU 推理可以接受。如果是批量处理几百个 PDF建议上 GPU 或改用 API。需要观察的指标有单次请求延迟从发出请求到拿到完整响应的耗时。首 token 延迟对长文档摘要影响不大但对交互式问答影响明显。吞吐量每分钟能处理多少条文本。内存占用CPU 模式主要看内存GPU 模式主要看显存。7.3 降低资源占用的方法使用量化模型比如 4bit 或 8bit。控制输入长度提前做文本切块。减少并发数避免多个请求同时占显存。清空历史会话长对话会持续占用上下文窗口。GPU 显存不足时把部分层放到 CPU但速度会下降。7.4 端口冲突与进程残留本地推理服务启动后如果再次启动同一端口会报address already in use。排查方式# Linux / macOS lsof -i :11434# Windows PowerShell netstat -ano | findstr 11434找到占用进程后确认是不是旧服务再决定关闭或换端口。不要直接kill -9所有进程避免把其他服务也带掉。8. 常见问题与排查方法以下是本地部署和 API 调用最常见的几类问题。问题现象可能原因排查方式解决方案API 返回 401API Key 错误或未配置检查请求头 Authorization重新生成 API Key避免提交到 GitAPI 返回 429触发限流查看响应头 Retry-After增加重试间隔或降低并发本地模型启动很慢模型较大或首次加载观察启动日志和磁盘 IO换量化模型增加内存或显存显存不足模型过大或上下文过长nvidia-smi查看占用换小模型、降上下文、加 offload输出 JSON 格式不固定prompt 没有约束或模型能力不足打印原始返回内容使用 JSON mode加 few-shotPDF 抽取不到文字PDF 是扫描件打开 PDF 看是否图片先用 OCR 再进入 RAG 流程批量任务中途卡住单条请求超时查看日志中正在处理的文件加超时与重试使用任务队列中文摘要质量差提示词信息不足检查原始输入和输出补充领域背景加输出格式要求端口被占用上一个服务未退出lsof -i或netstat关闭旧进程或修改启动端口内网安装依赖失败PyPI 源不可达查看 pip 错误信息配置内网镜像或离线安装包排查的基本原则先看日志再复现最小用例不要在大批量任务里调试。比如 JSON 输出不稳定先用一条固定 prompt 在网页端或脚本里复现确认模型行为后再改参数。9. 最佳实践与使用建议非编码 LLM 应用能不能落地很多时候不是模型能力问题而是工程习惯问题。先跑最小用例不要一开始就搭建完整 RAG 平台。先把一个文件、一个 prompt 跑通确认返回结果符合要求再往上加功能。保留一套最小可运行配置写好一个requirements.txt和一个示例脚本保证新机器能快速复现。不然三个月后你自己也忘了当初怎么配的。输入、中间结果、输出分目录管理建议分成input/、processed/、output/、logs/。批量任务出问题时能快速定位是哪个文件处理失败。批量任务一定加日志和重试记录每一条任务的状态、请求时间、错误信息重试采用指数退避。接口服务要限制访问范围如果对内网提供 API不要让服务暴露到公网给接口加鉴权否则容易被人扫到盗刷额度。涉及人脸、声音、版权素材时必须确认授权非编码任务经常处理带人名的文本、合同、会议录音这些数据不是“公开素材”。使用前确认授权输出结果也要注意是否包含敏感信息。发布或商用前要做效果复核LLM 生成的摘要、翻译、抽取结果不能直接作为正式交付物。至少做一次抽样人工核对抽到的错误率决定能不能上线。用结构化输出降低下游解析成本信息抽取任务优先让模型返回 JSON而不是返回一段带标题的文本否则后处理会非常痛苦。不要把多条业务规则塞进一个 prompt尽量让每条 prompt 只做一件事。比如“先抽取字段再翻译”会让错误率上升。拆成两步每步单独验证。10. 总结与下一步回到 HN 那个问题人们确实在用 LLM 做大量非编码相关的工作而且做得比较深的用户普遍不是把 LLM 当成聊天框而是把它当成一个被提示词、接口和脚本约束过的文本处理服务。这篇文章值得你带走的两点一是先明确任务类型文本摘要、信息抽取、格式转换、知识库问答对应不同的接入方式二是先跑通最小用例再上批量整个过程要保留日志和可复现配置。如果你现在刚想动手建议从“把一份 PDF 转成结构化 JSON”开始。这是最难也最容易出效果的任务跑通之后邮件、Excel、会议记录的处理都会顺很多。下一步可以继续扩展的方向是接入 RAG 做长期知识库、用 MCP 把内部系统串起来、加异步队列处理千条级任务。每一步都不难关键是先跑通第一个。