这次我们不看新的模型架构而是回到一个非常实际的问题LLM 除了写代码还能不能干点别的Hacker News 上有人发帖问“Do you use LLMs for non-coding related work?”评论区几乎变成了一场大型生产力工具分享会。很多人以为 LLM 就是结对编程助手但真正高频使用的场景反而在代码之外写邮件、整理会议纪要、做数据分析、翻译文档、批合同、整理知识库。这篇文章把 HN 讨论里最有价值的用法整理成一套可执行方案。先讲清楚 LLM 做非编码任务的适用边界再给本地部署与云端 API 两条技术路线然后是分组实测用例、Python 调用模板、批量任务脚本和问题排查清单。无论你是想用 Ollama 跑本地模型还是想通过 API 接入现有工作流这篇都能直接参考。1. 核心能力速览LLM 非编码任务到底能做什么能力项说明任务类型文本生成、摘要、分类、改写、翻译、结构化抽取、问答、角色扮演、会议纪要、数据分析辅助输入形式纯文本、Markdown、HTML、PDF 文本层、CSV、JSON、OCR 结果输出形式Markdown、JSON、CSV、表格映射、纯文本部署方式云端 APIOpenAI、通义、DeepSeek 等或本地推理Ollama、LLaMA.cpp、vLLM硬件要求本地跑需按模型而定8G 显存可试 7B 量级纯 API 模式无显存要求接口能力几乎所有主流推理框架都暴露 HTTP API可接入自动化脚本批量任务支持建议用目录扫描 队列 失败重试的方式实现适合场景文档处理、内容整理、信息抽取、翻译、知识库问答、轻度数据分析不适合场景需要精确计算的数学运算、实时低延迟交互、涉及敏感隐私的未授权数据处理从 HN 讨论和工程实践看LLM 非编码工作最稳定的应用是“非结构化文本到结构化信息的转换”。代码生成需要高确定性模型偶尔会“一本正经地胡说”但邮件分类、合同条款抽取、会议纪要整理这类任务天然容忍一定错误率而且可以用模板约束输出格式效果非常稳定。2. 适用场景与使用边界2.1 高频实用场景文档摘要与重写长文压缩成要点、技术文章转口语化表达、新闻通稿转周报。信息结构化抽取从简历、合同、发票、客户留言中抽取出姓名、金额、日期、条款等字段输出 JSON。会议纪要整理把语音转写文本清洗成“结论 待办 负责人”三段式。多语言翻译技术文档、邮件、产品说明的初翻和术语一致性检查。知识库问答基于内部文档做 RAG实现“问自己公司文档”的问答机器人。数据清洗辅助把脏乱的 CSV 字段变成统一格式用 LLM 写 Python 代码来清洗。角色模拟与文案头脑风暴营销文案、短视频脚本、面试模拟等。2.2 不明显但真实有效的用法HN 评论区里有人提到一个非常实用的用法用 LLM 把“模糊的需求”翻译成“采购清单”。比如“我想给家里装个监控”LLM 会列出设备方案、带宽要求、安装位置建议把问题描述给模型它输出清单然后人工去电商平台核实。这种用法本质上是在用 LLM 做信息检索与方案初筛。还有人用来写英文邮件的委婉拒绝用中性语调改写冲突性表达这在跨文化沟通中非常有用。2.3 边界与风险不要用 LLM 做精确计算金额累加、日期推算、编号校验交给代码。不要用 LLM 处理未经授权的隐私数据合同、简历、医疗信息必须脱敏后才可调用云端 API。不要直接采信输出LLM 可能生成查不到来源的引用、错误法律条款、虚构的文献。商用场景必须人工复核。不要混淆“生成”与“事实”模型输出的是概率文本不是数据库查询结果。3. 本地部署与云端 API两条技术路线怎么选3.1 路线对比对比项云端 API本地推理硬件门槛无仅需网络建议 16G 内存 8G 显存起步部署难度低注册拿 Key 就能用中需要装运行环境、下模型单次成本按 token 计费电费 硬件折旧数据安全数据离开本机需脱敏数据不出本机模型质量可调用 70B 以上大模型常见为 7B/14B完全不可同日而语批量任务适合但需控制速率适合无速率限制3.2 本地部署通用流程以 Ollama 为例如果你希望数据不出本机或者想体验本地推理Ollama 是目前最简单的方式。# 安装后启动服务默认端口 11434 ollama serve # 下载一个 7B 模型 ollama pull qwen2.5:7b # 命令行直接对话 ollama run qwen2.5:7b 帮我总结这段文本...Ollama 自带 OpenAI 兼容 API启动后可以直接用/v1/chat/completions接口调用这个设计对后续脚本接入非常友好。如果你的机器显存不够Ollama 也可以纯 CPU 推理只是速度会慢不少。显存占用以实际模型和上下文长度为准7B 模型 int4 量化大约需要 4-6G 显存但具体数值要在本机实测。3.3 云端 API 通用流程以 OpenAI 兼容接口为例pip install openaifrom openai import OpenAI client OpenAI( api_keyyour-api-key, base_urlhttps://your-endpoint.com/v1 # 本地 Ollama 可填 http://127.0.0.1:11434/v1 ) response client.chat.completions.create( modelqwen2.5:7b, # 云端按实际开通的模型名填写 messages[ {role: system, content: 你是一个信息抽取助手只输出 JSON。}, {role: user, content: 从下面这段客户留言中抽取姓名、联系电话和诉求\n张三说他上周买的鼠标右键失灵希望尽快换新电话是13800001111。} ], temperature0.2 ) print(response.choices[0].message.content)这段代码同时适用于本地 Ollama 和云端 API区别只在base_url和model两个参数。这是后面所有测试用例的基础。4. 非编码任务系统测试清单CSDN 读者习惯了“上测试用例”的思路。这里给出一套针对非编码任务的分组测试清单每一组都包含输入、操作和判定标准。4.1 文本摘要测试目的确认模型能把长文本压缩成指定结构的短文本。输入示例请把下面这段会议记录压缩成 3 条要点每条不超过 20 字 项目组今天确认了Q3上线计划前端本周提测后端接口下周一联调 运营需要在8月20日前完成页面文案整体回归预计需要3天。预期结果输出 3 条简洁要点不遗漏“前端提测”“后端联调”“文案提交”三个关键事项。判定成功要点数正确、信息完整、没有多余解释。失败排查如果模型输出大段话说明 system prompt 没有约束格式在 system 中加入“只输出列表不要解释”即可。4.2 结构化输出测试目的确认模型能返回可解析的 JSON。输入示例{ instruction: 抽取发票关键信息输出JSON格式, text: 开票日期2025年6月1日购买方北京某科技有限公司金额12800.50元税额1664.07元 }预期输出{ invoice_date: 2025-06-01, buyer: 北京某科技有限公司, amount: 12800.50, tax: 1664.07 }判定成功json.loads()可直接解析字段完整。失败排查模型偶尔会输出 Markdown 代码块包裹的 JSON需要在脚本中做容错处理去掉json标记后解析。通用做法是正则提取第一个{到最后一个}之间的内容。4.3 翻译与术语一致性测试目的确认模型在指定术语表条件下保持术语统一。输入示例将下面中文翻译为英文注意将“降本增效”统一翻译为 cost efficiency improvement不要使用其他译法 本季度我们重点推进降本增效通过自动化手段实现了显著的成本节约。预期结果两个“降本增效”都采用指定译法。判定成功翻译结果中术语完全一致无同义词替换。4.4 分类与打标测试目的验证模型对多类别文本的分类准确率。输入示例# 在 Python 中构造分类测试 categories [投诉, 咨询, 建议, 无关] texts [ 你们的软件昨天崩溃了三次太差了, 请问这个功能要收费吗, 建议增加夜间模式对眼睛友好一些。 ] # 将分类列表和文本一起发给模型要求返回标签列表 JSON判定成功三条文本分别被分为“投诉”“咨询”“建议”。失败排查如果分类边界模糊让模型“只输出一个类别名称不要解释”降低 temperature 到 0。4.5 长文本处理测试目的确认模型在长上下文下不会丢失开头信息。测试方法准备 3000 字以上的合同文本要求模型提取第 5 页的某个条款内容。判定成功条款内容与原文一致没有混淆。失败排查如果模型丢失信息先确认上下文窗口是否足够本地部署时如果显存不够减小num_ctx或换长上下文版本模型。4.6 批量文件夹处理测试目的验证批量任务在实际目录中的稳定性。操作步骤# 建立目录结构 mkdir -p test_input test_output test_log # 放入 10 个 txt 文件内容可以是新闻、邮件、会议记录等预期结果脚本逐个处理文件输出到test_output每个文件一个摘要日志记录成功/失败状态。5. 接口 API 与批量任务脚本LLM 做大文件批处理的意义在于不需要人盯在电脑前一条条复制粘贴。写好脚本后放一文件夹文件跑完看结果即可。5.1 Python 批量摘要脚本下面脚本适用于任意 OpenAI 兼容 API。注意包含失败重试与目录扫描。import os import json import time from openai import OpenAI client OpenAI( api_keyyour-api-key, base_urlhttp://127.0.0.1:11434/v1 # 本地 Ollama ) INPUT_DIR test_input OUTPUT_DIR test_output LOG_FILE test_log/batch.log def summarize(text: str) - str: resp client.chat.completions.create( modelqwen2.5:7b, messages[ {role: system, content: 你是文档摘要助手输出不超过100字的中文摘要。}, {role: user, content: text[:3000]}, # 按需截断 ], temperature0.3, timeout60, ) return resp.choices[0].message.content def main(): os.makedirs(OUTPUT_DIR, exist_okTrue) os.makedirs(test_log, exist_okTrue) with open(LOG_FILE, w, encodingutf-8) as log: for fname in os.listdir(INPUT_DIR): if not fname.endswith(.txt): continue src os.path.join(INPUT_DIR, fname) dst os.path.join(OUTPUT_DIR, fname.replace(.txt, _summary.txt)) if os.path.exists(dst): continue # 断点续跑 try: with open(src, encodingutf-8) as f: content f.read() result summarize(content) with open(dst, w, encodingutf-8) as f: f.write(result) log.write(f[OK] {fname}\n) log.flush() except Exception as e: log.write(f[FAIL] {fname}: {e}\n) log.flush() time.sleep(2) time.sleep(1) # 简单限速 if __name__ __main__: main()脚本设计要点输出文件已存在则跳过支持断点续跑不用每次从头开始。失败写入日志但不中断跑完统一看test_log/batch.log。每次请求间隔 1 秒避免本地服务过载或云端限流。文本截断到 3000 字符防止上下文溢出真实场景按你的上下文窗口调整。5.2 批量任务队列设计如果文件数量较多建议在脚本基础上增加队列文件而不是用一个for循环硬跑。简单做法如下。{ tasks: [ {file: input/001.txt, status: pending}, {file: input/002.txt, status: pending}, {file: input/003.txt, status: failed, retry_count: 1} ] }脚本启动时读取队列只处理pending和failed且重试次数小于 3 的任务。每处理一个更新状态。这样即使中途断电也不会丢失进度。5.3 curl 快速接口自测如果你不想写 Python先用 curl 确认接口通不通更直接。curl http://127.0.0.1:11434/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen2.5:7b, messages: [{role: user, content: 用一句话总结LLM适合做什么}], temperature: 0.3 }返回结果在choices[0].message.content字段中。这个测试通过后说明服务正常可以接入任何语言写的脚本。6. 资源占用与性能观察方法“跑得动吗”和“跑多快”是两个完全不同的问题。这里给出通用的观察方法具体数字需要按你的硬件实测。6.1 显存与内存观察启动 Ollama 后模型加载进内存/显存。观察方法# 实时查看 GPU 占用 nvidia-smi -l 2 # 查看进程内存占用 top -p $(pgrep -f ollama)如果出现显存不足模型会回退到 CPU 推理速度明显下降。你可以通过日志确认推理设备。更稳妥的做法是先跑一条短文本观察显存占用和响应时间再逐步增加上下文长度。6.2 哪些因素影响速度模型参数量7B 快14B 慢70B 需要多卡或大内存。量化级别Q4 量化比 FP16 快且省显存但质量略降。上下文长度输入越长首 token 延迟越大。并发请求并发过高时显存不足会排队或报错。批处理大小文本分类等简单任务可以调大batch_size摘要任务通常逐条处理。6.3 如何降资源占用换更小的量化模型比如qwen2.5:7b-instruct-q4_K_M。限制最大生成长度max_tokens512避免模型长篇大论。减小num_ctx到 4096够用即可。关闭浏览器、桌面环境等不必要的显存消耗。6.4 端口与进程管理Ollama 默认端口 11434。如果端口被占用可通过环境变量修改启动后可通过lsof -i:11434检查端口监听情况。跑完批任务后注意检查是否有残留进程避免下次启动端口冲突。7. 常见问题与排查方法问题现象可能原因排查方式解决方案启动后服务无法访问端口被占用或服务未启动检查日志和lsof -i:11434更换端口或重启服务模型加载失败模型文件未下载或损坏查看 Ollama 日志重新执行ollama pull显存不足报错模型大于显存容量nvidia-smi看占用换小模型、加量化、减小上下文API 返回 404模型名写错或未拉取执行ollama list确认使用正确的模型名API 返回 401云端 Key 无效检查 Key 权限和余额重新生成 Key 或调整服务地址批量任务跑到一半卡住网络超时或并发过高查看日志中的超时报错增加 timeout 和重试次数降低并发模型输出格式不符合预期prompt 约束不足检查 system prompt明确要求“只输出 JSON”并给出输出样例中文翻译质量差基础模型偏英文使用中文优化模型选择 qwen 或中文微调模型本地推理很慢CPU 推理或显存不足回退查看日志确认设备减量化、减上下文或换 GPU输出结果与事实不符模型幻觉交叉对比原文增加引用约束要求输出原文片段批量脚本断点后重复处理没有输出文件跳过逻辑检查代码逻辑增加“已存在则跳过”的判断8. 最佳实践与使用建议先小参数跑通再上全量。不要上来就丢 500 个合同进去批量跑。先拿 3 个样本文件测通全流程确认输出质量稳定后再扩展批量任务。保留一套最小可运行配置。在项目目录下建一个README记录 API 地址、模型名、上下文限制、常用 prompt 和批处理命令。这样一个月后回来看不用重新摸索。模型、输入、输出三者分目录管理。llm-workbench/ ├── models/ # 模型配置文件、量化说明 ├── input/ # 原始文件 ├── output/ # 处理结果 ├── logs/ # 运行日志 ├── scripts/ # Python 脚本 └── prompts/ # 常用 prompt 模板批量任务必须带日志和失败重试。没有日志的批任务等于抛硬币跑挂了不知道挂在哪个文件上。参考上面脚本中的日志设计。接口服务要限制访问范围。如果是本地 Ollama默认监听 127.0.0.1 即可不要暴露到公网。需要远程访问时用内网穿透或防火墙白名单避免 API 被滥用。涉及人脸、声音、版权素材时必须确认授权。如果 LLM 处理的内容包含个人信息、商业机密或受版权保护的素材务必先确认是否有权使用云端 API 场景更要注意数据出境问题。发布或商用前做效果复核。LLM 生成的内容不保证事实正确特别是合同条款、财务数据、法律建议类输出必须由人工复核后再使用。9. LLM 非编码任务 vs 传统脚本怎么选很多 CSDN 读者熟悉的正则表达式、字符串匹配和规则引擎在某些场景下比 LLM 更合适。维度传统脚本LLM精确匹配强弱偶发幻觉模式固定强写一次跑一万次弱需要反复调 prompt语义理解弱强长尾表达弱规则覆盖不全强能处理没见过的说法部署成本低中到高可解释性高低判断标准如果数据格式是“千篇一律”的用正则如果是“千奇百怪”的用 LLM。更实际的做法是混合先用正则做硬校验无法命中的再交给 LLM 判断。10. 总结与下一步这篇文章的核心观点只有一个LLM 最强的生产力优势不在代码生成而在“把非结构化信息变成可用结构”。从邮件分类到合同抽取从会议纪要整理到知识库问答这些工作不需要 100% 的编程准确率而是需要语义理解能力恰好是 LLM 最擅长的事。建议你先做的三件事安装 Ollama 并拉取一个 7B 模型跑通命令行对话。用文章里的 Python 脚本把本地一个文件夹的 txt 文件批量生成摘要验证目录扫描、断点续跑和日志记录。找一个你日常工作里“固定格式但内容多变”的任务比如日报汇总、客服留言分类设计一个 prompt 并测试输出格式。最容易踩的坑是 prompt 输出格式不稳定。所以第一批测试任务一定要优先验证输出格式能否被json.loads()解析再谈准确率。后面可以继续扩展的方向包括接入 RAG 做内部知识库问答、用 MCP 连接外部工具、用 Agent 编排多步任务、在 ComfyUI 外挂 LLM 做图像生成提示词优化。这些方向都建立在先跑通基础接口的基础上。先把上面的批量摘要脚本跑起来后续再按需扩展。