LLM 不止写代码：用 Python 打造非编码任务自动化工作流

如果你同时关注开发效率和个人知识管理最近大概率刷到过 Hacker News 上的一个热议问题“Do you use LLMs for non-coding related work?”。这个问题的评论区非常有意思很多开发者发现LLM 带来的最大收益并不在“写代码”这一件事上而是在写文档、整理邮件、提炼信息、准备汇报、做研究综述这些每天都要花大量时间的“非编码工作”上。这篇文章我不想再重复“LLM 能帮助你写代码”这种老生常谈而是想认真讨论一件事作为一个技术人如何把 LLM 真正用到与编码无关的日常工作里并且让这些任务跑成可复用、可验证、可维护的流程。文章会先从场景和边界讲起再给出一套可以直接照搬的 Python 调用模板最后讲解常见的坑和工程建议。读完你可以马上挑选一个非编码任务做成一个小工具而不是继续把 LLM 当成一个偶尔打开的网页对话框。1. 这篇文章真正要解决的问题我们每天的工作其实只有一小部分是写代码。开会、读文档、回消息、整理需求、写周报、做复盘、看竞品、查资料……这些任务大量占据时间却又没有现成的 IDE 帮你自动补全。传统思路是“找个模板”“复制粘贴改一改”或者干脆手工一遍遍重写。真正的问题是这类任务大部分是“语言任务”而 LLM 最擅长的恰恰是语言理解和生成。这篇文章的第一个目标是帮你建立“非编码任务也能流程化”的判断力。不是所有任务都适合交给 LLM但适合的任务如果做成了固定流程每天的节省是真实可见的。第二个目标是给出可落地的操作路径。我会用 Python 写几个最小示例包含会议纪要生成、邮件信息提取、文档风格改写这三个典型场景。这三个示例覆盖了 LLM 在非编码任务中的三个核心能力总结、抽取、改写。第三个目标是帮你避开最常见的坑。比如输出不稳定、格式不对、幻觉内容、API 调用失败、敏感信息泄露、成本失控。这些坑如果不提前处理很容易让你用完一次之后就放弃。所以这篇文章不是“LLM 入门科普”而是一份面向技术人的“非编码任务自动化实操笔记”。不管你是后端、前端、算法工程师还是测试、运维、技术管理都能从中找到值得迁移到自己的工作里的思路。2. LLM 的核心能力为什么它能处理非代码任务要理解为什么 LLM 能处理非编码任务需要先放下“它是个编程助手”的刻板印象。LLM 训练时的语料来自书籍、网页、论文、对话、论坛这些内容的主体并不是代码而是自然语言。它本质上是一个“世界知识在语言空间的压缩模型”。虽然它没有真正的理解力和行动力但它具备强大的语言模式识别和生成能力。具体来说它能在非编码任务里发挥四类能力。第一是总结归纳。给它一大段语音转写、会议记录或者长文它能把信息压缩成要点、结论、行动项。这一步的价值在于把“阅读和理解”的时间从 30 分钟压缩到 1 分钟。第二是信息抽取。从一堆非结构化文本里抽取日期、产品名、客户情绪、风险点、结构化字段。这和代码无关但和后续数据处理高度相关。第三是改写润色。同一段话你可以让它改成正式周报版本、面向领导的浓缩版本、面向客户的礼貌版本。这在写邮件、写需求、写 PRD 时非常实用。第四是转换与分类。判断一封邮件是否重要、一段用户评论是好评还是差评、一段内容属于哪个主题。这是传统 NLP 分类任务的天然替代品。要注意LLM 不等同于搜索引擎。搜索引擎是“找到已有的正确答案”LLM 是“根据概率生成合理的回答”。所以它更适合那些没有唯一标准答案、更依赖语言表达能力、更看重“生成过程”的任务。但如果任务是精确计算、事实查证、实时数据查询直接使用 LLM 很容易翻车应该把这类任务交给代码和工具。我们可以用一张表来快速判断一个非编码任务是否适合 LLM。任务类型典型例子是否适合交给 LLM原因长文压缩会议纪要、论文导读适合语言归纳能力强能显著省时间结构化抽取从邮件中提取订单号和日期较适合需要配合校验和少量代码多版本改写周报、邮件、宣传文案适合输出质量高可控性强事实查证某公司融资额是多少不适合容易幻觉需要外部检索工具精确计算报销金额、统计数字不适合应直接写代码或用计算器实时数据当前股价、天气不适合没有实时信息除非接 API有了这个判断框架你就知道哪些任务值得投入时间去自动化哪些任务应该继续使用传统方法。3. 非编码任务的使用场景与边界在实际工作里非编码任务可以粗分成几个高频场景。每个场景都有不同的 prompt 设计策略和验证方式。3.1 会议纪要与行动项提取这是很多人第一个尝到甜头的场景。语音转文字工具或视频会议平台已经能生成长文本但从中提炼出“谁负责什么、什么时候完成、下一轮同步时间”仍然很累。LLM 可以把长文本转换为 Markdown 格式的会议纪要并且按“结论、待办、风险”结构输出。这里的关键不是简单地贴一段 prompt而是要让输出格式稳定。做法是在 prompt 里明确给出输出模板并且使用低温度参数比如temperature0.1。这样模型不会发挥太多输出高度可预测。3.2 非结构化信息抽取另一个典型场景是“一堆邮件/评论/PDF 里找关键字段”。比如你负责客户反馈汇总每天要读几十封邮件提取客户名称、问题分类、优先级。你可以写一个 Python 脚本把邮件正文传给 LLM让它输出 JSON 结构化结果然后由代码进一步处理。这个任务表面上是“文本处理”实际是“从文本到数据的转换”。它非常适合和现有业务系统结合自动判断工单类型、自动设置优先级、自动分配处理人。但要注意抽取结果必须经过规则校验否则一个幻觉出来的日期可能导致后面整个数据链路出问题。3.3 文档与文案的多版本改写技术人经常要写文档但同一份内容可能需要出现在不同场合。给客户看的要通俗给老板看的要简洁给团队看的要完整。手工改很费时间。LLM 可以基于同一份输入按不同 persona 生成不同版本。使用示例中会给出一个具体的函数让你只改一个target_style参数就能切换。这个场景的收益不只是“快”而是你敢于快速迭代。以前写一段话改三遍需要很久现在可以让 LLM 生成 5 个候选你从中挑选或组合质量往往更高。3.4 研究、学习与知识整理读论文、读技术博客、读竞品公告想快速知道“核心讲什么、和自己有什么关系”。LLM 可以当做一个“阅读代理”你先让它给你一份结构化摘要再决定是否深入阅读原文。更进一步可以把历史文档、笔记、邮件放进本地知识库用 RAG检索增强生成的方式围绕自己的资料进行问答。这已经超出了“聊天工具”的范畴变成一个个人知识管理模块。当然边界同样清晰。它不擅长处理实时、精确和需要专业判断的任务。在法律、医疗、财务等强监管场景LLM 生成的内容只能作为初稿必须由专业人员进行复核。我建议在 prompt 里明确写“以下内容仅为协助草拟不构成专业意见”这既是伦理要求也是保护自己的好习惯。4. 环境准备与前置条件下面进入实操。为了让示例能够在本地直接跑通我选择使用 Python 3.9 和一个兼容 OpenAI API 协议的客户端。这样无论是调用在线服务还是本地部署模型的接口代码都不会有太大差别。4.1 安装依赖建议创建一个新的虚拟环境避免依赖冲突。mkdir llm-daily-work cd llm-daily-work python -m venv venv source venv/bin/activate # Windows 下使用 venv\Scripts\activate然后安装必要的包。pip install openai python-dotenv requests这里openai是官方 Python 库它不只可以调用 OpenAI 服务也兼容大量本地框架和第三方平台暴露的 OpenAI 格式接口。python-dotenv用来读取.env文件中的密钥和配置避免把密钥写死在代码里。4.2 配置模型接口在项目根目录创建一个.env文件LLM_API_KEYyour-api-key-here LLM_BASE_URLhttps://your-api-endpoint/v1 LLM_MODELgpt-3.5-turbo如果你使用本地 Ollama可以通过ollama serve启动的默认地址http://localhost:11434/v1作为LLM_BASE_URL。例如LLM_API_KEYollama LLM_BASE_URLhttp://localhost:11434/v1 LLM_MODELqwen2.5:7b注意具体模型名称和接口地址以你实际环境为准这里不写死版本。只要该接口兼容 OpenAI 的/chat/completions协议下面的代码就可以直接使用。4.3 配置文件读取我们编写一个简单的配置文件读取模块方便后面所有脚本复用。# config.py import os from dotenv import load_dotenv load_dotenv() LLM_API_KEY os.getenv(LLM_API_KEY) LLM_BASE_URL os.getenv(LLM_BASE_URL) LLM_MODEL os.getenv(LLM_MODEL) if not all([LLM_API_KEY, LLM_BASE_URL, LLM_MODEL]): raise ValueError(请在 .env 文件中配置 LLM_API_KEY, LLM_BASE_URL, LLM_MODEL)从安全角度看不要把密钥直接写在代码或提交到 Git 仓库。.env文件应该加入.gitignore并且只保留本地使用。5. 核心流程拆解把非编码任务变成长效工作流很多非编码任务自动化失败不是因为模型不够强而是因为没有把任务当成一个“软件工程问题”来设计。如果只是复制粘贴一个 prompt那不叫工作流。一个可复用的工作流至少包含五个环节。5.1 任务定义先明确任务的输入、输出和验收标准。比如“会议纪要生成”的输入是一段发言文本输出是 Markdown 格式的纪要验收标准是“待办部分每一条都有负责人和截止时间”。这一步决定 prompt 怎么写。5.2 Prompt 设计Prompt 不是简单的“帮我整理一下”。我建议固定结构角色 任务目标 输入内容 输出格式 约束条件 示例。对于非编码任务角色信息很重要。比如“你是一位有 10 年经验的 Technical Program Manager”模型会顺着这个约束改变用词和结构。5.3 模型调用调用的时候要设置合适的参数。抽取、总结类任务使用低温度比如0.1创意、改写类任务可以使用0.7。max_tokens应该根据输出长度预估避免中间被截断。如果输出是 JSON建议在 prompt 里明确要求输出纯 JSON不要带解释文字。5.4 输出校验模型输出不能直接进入业务系统。先用代码检查格式JSON 能不能解析、必填字段是否存在、日期格式是否正确、枚举值是否在预期范围内。校验不过就重试一次或丢弃。5.5 结果集成最后一步是把输出写入文件、数据库、IM 机器人或者调度系统。这也是自动化真正产生价值的地方。很多人的 LLM 任务停在“网页对话框里生成一段文字”并没有集成到工作台里。正确的做法是让 Python 脚本定时读取文件、调用 LLM、处理结果、发送到指定位置整个过程不需要人工打开浏览器。6. 完整示例与代码实现下面给出三个可以直接运行的示例。每个示例都包含一个独立的 Python 文件你可以在llm-daily-work目录下创建。6.1 示例 1会议纪要自动生成这个脚本接受一个会议录音转写文本文件输出一份包含“会议主题、关键结论、待办事项、风险问题”的 Markdown 文档。# meeting_summarizer.py import config from openai import OpenAI client OpenAI( api_keyconfig.LLM_API_KEY, base_urlconfig.LLM_BASE_URL, ) def build_prompt(transcript: str) - str: return f 你是一位技术团队的项目经理擅长从会议记录中提取关键信息。 请根据下面的会议记录生成结构化纪要使用 Markdown 格式。 输出结构 ## 会议主题 一句话概括会议主题 ## 关键结论 - 结论1 - 结论2 ## 待办事项 - [ ] 负责人张三事项xxx截止时间本周五 - [ ] 负责人李四事项xxx截止时间下周一 ## 风险问题 - 风险描述 要求 1. 待办事项必须包含负责人和截止时间 2. 不要补充原记录中不存在的内容 3. 如果信息不足请在对应部分写“信息不足” 会议记录 {transcript} def generate_meeting_notes(transcript: str) - str: response client.chat.completions.create( modelconfig.LLM_MODEL, messages[ {role: system, content: 你是严谨的会议纪要整理助手。}, {role: user, content: build_prompt(transcript)}, ], temperature0.2, ) return response.choices[0].message.content if __name__ __main__: with open(meeting_transcript.txt, r, encodingutf-8) as f: transcript f.read() notes generate_meeting_notes(transcript) with open(meeting_notes.md, w, encodingutf-8) as f: f.write(notes) print(会议纪要已生成到 meeting_notes.md)代码里的build_prompt函数负责把输入文本包装成指令。提示词里明确给出了输出结构、待办格式和约束条件模型基本不会跑偏。6.2 示例 2客户邮件信息抽取这个脚本从多封邮件中抽取结构化字段并输出 JSON 数组方便后续写入表格或数据库。# email_extractor.py import json import config from openai import OpenAI client OpenAI( api_keyconfig.LLM_API_KEY, base_urlconfig.LLM_BASE_URL, ) def build_extract_prompt(emails: list[str]) - str: email_text \n---邮件分隔线---\n.join(emails) return f 你是一个客户支持系统助手。请从下列邮件中抽取信息并输出 JSON 数组。 每条 JSON 对象字段 - customer_name: 客户姓名如果没有则填 null - email_date: 邮件日期格式为 YYYY-MM-DD如果没有则填 null - category: 问题分类只能取值 [询价, 售后, 投诉, 合作, 其他] - priority: 优先级只能取值 [高, 中, 低] - summary: 不超过20字的问题摘要 要求 1. 输出必须是合法的 JSON 数组不要包含额外的解释 2. 如果没有相关信息对应字段填 null 3. 不要编造邮件中不存在的内容 邮件内容如下 {email_text} def extract_emails(emails: list[str]) - list[dict]: response client.chat.completions.create( modelconfig.LLM_MODEL, messages[ {role: system, content: 你是信息抽取助手只输出 JSON。}, {role: user, content: build_extract_prompt(emails)}, ], temperature0, ) content response.choices[0].message.content # 去掉可能的 json 围栏 content content.strip().removeprefix(json).removeprefix().removesuffix().strip() return json.loads(content) if __name__ __main__: sample_emails [ 主题关于产品报价\n日期2025-06-10\n张三发来邮件询问订购100台服务器的价格。, 主题售后问题\n日期2025-06-11\n李四反馈设备使用一周后出现频繁重启希望尽快处理。, ] result extract_emails(sample_emails) print(json.dumps(result, ensure_asciiFalse, indent2)) with open(email_extracted.json, w, encodingutf-8) as f: json.dump(result, ensure_asciiFalse, indent2, fpf)这段示例最需要注意的地方是json.loads之前的清理逻辑。很多模型在输出 JSON 时会习惯性加上json围栏如果不去除代码会直接报错。不同模型生成的围栏格式略有差异建议用.strip()配合removesuffix处理。6.3 示例 3文档多风格改写这个脚本接收同一段原文生成“正式周报风格”“客户沟通风格”“技术团队内部风格”三个版本。# doc_rewriter.py import config from openai import OpenAI client OpenAI( api_keyconfig.LLM_API_KEY, base_urlconfig.LLM_BASE_URL, ) def rewrite_document(original: str, style: str) - str: prompt f 请将下面的内容改写成{style}。 要求 1. 保留原意不添加新的信息 2. 用词专业但不要过度堆砌术语 3. 分段清晰逻辑流畅 4. 直接输出改写后的内容不要解释 ## 原始内容 {original} response client.chat.completions.create( modelconfig.LLM_MODEL, messages[ {role: system, content: 你是资深的中文文档编辑专家。}, {role: user, content: prompt}, ], temperature0.7, max_tokens1024, ) return response.choices[0].message.content if __name__ __main__: source 我们团队本周完成了支付模块的改造因为旧接口存在严重的超时问题导致用户投诉增多。 目前已上线新的网关延迟从平均3秒降到了800毫秒。下周准备处理退款流程的自动化 预计需要和财务系统联调。 styles [正式周报风格, 面向客户的汇报风格, 技术团队内部复盘风格] for style in styles: print(f {style} ) print(rewrite_document(source, style)) print()这个示例的temperature设置到了 0.7因为它是生成类任务需要一定的语言变化。但max_tokens要控制好否则长文本可能会截断。如果你希望输出长度稳定可以在 prompt 中增加“字数控制在 X 字以内”这样的约束。这三个示例覆盖了总结、抽取、改写三类任务。你可以把它们当作模板替换输入和 prompt 就能适配到自己的业务里。7. 运行结果与效果验证我们先用示例 2 来验证整体流程。在项目根目录执行python email_extractor.py预期输出是一个 JSON 数组类似[ { customer_name: 张三, email_date: 2025-06-10, category: 询价, priority: 中, summary: 询问100台服务器报价 }, { customer_name: 李四, email_date: 2025-06-11, category: 售后, priority: 高, summary: 设备频繁重启希望处理 } ]如何判断成功首先脚本没有抛异常JSON 成功打印。其次每条记录的字段都是预期的枚举值没有出现“待定”“高优先”这类不在枚举里的值。最后摘要长度符合预期且没有编造邮件中不存在的信息。对于会议纪要生成运行后打开meeting_notes.md检查三点第一待办事项是否都有负责人和截止时间。如果模型没有按格式输出可以回到 prompt 里增加“待办事项必须以- [ ] 负责人xxx事项xxx截止时间xxx格式列出”这一条。第二是否有幻觉信息。会议记录里没有提到的人名或数字不应该出现。如果出现应降低温度或增加一句“只能基于会议记录不能补充外部知识”。第三Markdown 结构是否完整。如果## 风险问题缺失可能是输入文本太短也可能是模型在 response 中途被截断。这时可以检查finish_reason如果因为max_tokens截断应调大max_tokens。一个更严格的验证方法是经常准备几个“黄金测试样本”。把自己手写的理想输出保存在一个固定文件里每次修改 prompt 或模型后跑一遍样本对比输出。这一步虽然会增加一点维护成本但能保证工作流的稳定性值得投入。8. 常见问题与排查方法实际运行过程中最常见的不是算法问题而是调用细节和环境问题。我把高频问题整理成下表方便直接查阅。问题现象可能原因排查方式解决方案调用接口报 401 错误API key 错误或校验失败检查.env中配置和是否为测试密钥更新正确密钥确认接口要求的鉴权前缀请求超时模型较大或网络不稳定查看请求耗时调整timeout参数增加超时时间或切换更快的模型实例返回 JSON 解析失败模型输出包含 Markdown 围栏或额外文字打印原始内容确认围栏格式用正则清理json等噪音后再解析输出中文乱码终端编码问题检查控制台编码设置环境变量PYTHONIOENCODINGutf-8抽取结果字段不在枚举内Prompt 约束不够强查看实际输出观察模型是否忽略枚举在 prompt 中给出枚举示例并增加“只能输出枚举值”的强约束结果幻觉严重温度过高或任务不适合 LLM降低温度改用小模型先测试把需要事实准确的部分改为规则校验和外部工具本地部署显存不足模型参数量超出显卡显存查看启动日志和nvidia-smi显存占用使用量化模型或改调用远程 APIComfyUI 和 LLM 是否必须部署在同一台机器误解两者集成方式确认 LLM 是否以 HTTP 服务形式暴露不需要只要 ComfyUI 能访问到 LLM 的 API 地址即可物理机器可以分离关于最后一条我想单独解释一下。ComfyUI 这类图形化工作流工具需要“调用 LLM”时它本质上只是向某个 HTTP 服务发送请求。这个服务可以运行在本机也可以运行在其他服务器。只要网络能够访问到对应端口无论是否同一台电脑都不影响。唯一需要注意的是如果 LLM 在远程服务器要确认接口地址、鉴权方式和防火墙都配置正确。如果两者都在本机通常是为了避免敏感数据外传或者降低网络时延但并不是必须。9. 最佳实践与工程建议当你已经能跑通上面的示例后接下来可以让这套流程变得更可靠、更可控。这里分享一些我在实际项目中沉淀下来的建议。9.1 把 Prompt 当代码来管理Prompt 不是聊天时随口说的话它应该进入版本控制。建议把每个任务的 Prompt 模板单独放在一个prompts/目录比如meeting_summary.txt、email_extract.txt。修改 Prompt 后提交代码保留历史版本。这样当你发现某个输出在十天后劣化了可以快速对比是哪一次 Prompt 变更导致的。9.2 用温度参数区分任务类型温度是控制“冒险程度”的参数。抽取、分类、总结类任务温度设为 0 或 0.1保证输出稳定改写、生成、头脑风暴类任务温度设为 0.7 左右增加表达多样性。如果你希望得到多个候选方案可以连续调用多次然后把结果聚合并对比。9.3 对输出做“业务校验”不要直接信任模型输出。一个健壮的流程应该是“LLM 生成初稿 代码校验 人工兜底”。比如邮件抽取结果必须通过字段枚举校验日期必须通过datetime.strptime校验JSON 必须通过解析。校验失败时可以做一次自动重试或进入人工处理队列。这样可以避免个别错误污染整个下游数据。9.4 注意敏感信息和数据隔离很多非编码任务会涉及客户信息、内部文档、薪酬绩效等敏感内容。在使用外部 API 前务必确认数据是否允许发送到服务端。如果不允许建议使用本地部署模型或者对文本做脱敏处理后再调用。在 prompt 中尽量不要附带真实姓名、身份证号、密钥等数据。输出内容在正式使用前也应该经过人工抽查。9.5 控制成本与延迟非编码任务通常不是一次性的而是每天定时执行所以成本需要提前评估。对于重复性高、格式固定的任务可以优先选择小尺寸模型或者给输入内容做截断处理。比如只把前 2000 字发给模型而不是发送整封长邮件。日志里增加每次调用的 token 数和耗时能帮你及时发现成本波动。9.6 结合工具而非完全替代工具LLM 负责“语言分析和生成”传统代码负责“计算、检索、执行”。比如你要分析几十封邮件可以先写 Python 脚本读邮件、清理数据再调用 LLM 抽取最后用 Pandas 或 Excel 生成报表。这种“LLM 脚本”的混合架构比让 LLM 自己从头处理到尾更稳定、更容易调试。10. 总结与后续学习方向非编码工作也是知识工作而知识工作里最高频的动作就是“阅读、写作、提取、整理”。LLM 恰好在这几个动作上表现得足够好所以它不应该只活在代码补全的框框里。这篇文章的核心观点是不要把它当成一个“写代码工具”而是一个可以嵌入日常任务流程的“语言计算引擎”。你下一步最值得做的事情是找出一个你每周都要重复三次以上的非编码任务哪怕只是“把零散笔记整理成周报”。把它写成一个小脚本跑通第一版然后持续优化 prompt 和校验逻辑。这个过程并不需要多复杂的工程架构只需 50 到 100 行 Python 就能落地。如果有精力继续深入我建议按这个顺序学习先掌握 Prompt 工程的基础和常见模式然后了解 LangChain 或 LlamaIndex 等框架如何简化调用与知识库集成再结合 RAG 做个人知识库问答最后试试本地部署模型解决数据安全和离线需求。每一步都能和今天讲的非编码场景自然衔接。把这些工具真正嵌入到工作流程里之后你会发现所谓“ AI 改变工作方式”不是发生在你写代码的那 20% 时间里而是发生在另外 80% 的日常琐事里。