最近在 Hacker News 上看到一个很耐人寻味的问题“你在非编码类工作里用 LLM 吗”在中文技术社区里类似的问题其实更常见有人用大模型写报告、整理会议纪要、翻译文档、做旅行计划也有人拿着同一个模型调试 bug、生成 SQL、写 unit test。同样是 LLM前者几乎不写代码后者却天天和代码打交道。这两类人很可能用过同一个模型但对它的理解和评价完全不同。我自己的判断是LLM 能处理的非编码工作远比大多数人想象中多。甚至可以说编码只是 LLM 能力的一个切片真正让它变得像“通用生产力工具”的恰恰是那些不需要写代码的场景。这篇文章不打算讨论哪种用法更高明而是想把非编码工作这条线拆开来看它到底能解决什么问题怎么从“随便聊聊”变成一套可复用的流程以及落地时最容易踩哪些坑。1. 为什么多数人只把 LLM 当成编码工具1.1 开发者社区的信息茧房你去搜任何一个主流大模型的“使用场景”前几页大概率会被代码生成、代码补全、单元测试、SQL 生成这些内容占满。这不是偶然。最早一批深度使用 LLM 的用户是程序员技术社区里最容易被传播的 demo 也是代码相关。于是“LLM 很擅长写代码”这个印象被反复强化甚至被当成它最核心的价值。但代码场景有一个隐性优势输出可以被机器验证。你让模型写一个排序函数跑一下就知道对不对输出可以用编译器、测试用例、静态检查工具来评判。这种确定性让开发者愿意放心使用也更容易迭代。相比之下非编码任务的输出没有 hard test写得好不好、总结得准不准往往要靠人去看因此早期分享少大家也就默认“不擅长”。这就形成了信息茧房不是 LLM 不擅长处理合同、邮件、会议纪要、知识整理而是这些场景缺少可扩散的“标准答案”所以很少被当作典型案例讲出去。1.2 编码场景的真实优势与隐藏成本编码场景还有一个容易被忽略的便利任务边界通常很清楚。“写一个函数输入是日期字符串输出是格式化后的日期”这是一个完全闭合的问题模型只需要在给定约束里完成翻译。可一旦进入非编码工作任务描述往往模糊得多。“帮我写一封给客户的邮件”没说语气、没说重点、没说篇幅、没说是否需要附带 action items。模型只能猜猜得准不准取决于你会不会把任务说清楚。换句话说编码场景降低了“任务表达”的成本而很多非编码场景的真实难点不在生成而在“需求梳理”和“结果评估”。这也是为什么有人觉得用 LLM 做非编码事情“很鸡肋”不是模型弱而是你还没建立一套人机协作的接口规范。2. 非编码工作里LLM 真正能帮你省下什么2.1 信息处理总结、提取、改写这大概是纯文本工作里最常用的能力。几十页的 PDF 摘要、冗长的调研报告、客户访谈记录、行业政策文件都可以让 LLM 先做一轮结构化提取你再在它基础上检查、补充、调整。实际操作时不要只说“帮我总结一下”而是要给它明确的视角和输出格式。比如“请提取这段材料中的三个核心结论每个结论不超过 50 字并列出对应的原文页码。”“请把这段对话转成会议纪要分‘议题、决定、待办’三部分待办要标出负责人。”“请把这篇文章改写成适合手机端阅读的版本每段不超过 80 字。”这类任务的最大价值不是“省掉阅读”而是降低信息筛选成本。模型可以快速把原始材料压缩成你能快速浏览的中转格式再由你决定哪些信息需要溯源、哪些可以直接使用。2.2 表达与沟通邮件、周报、翻译、润色很多非编码工作者每天大量时间花在文字表达上。邮件怎么开头、周报怎么总结、跨部门消息怎么措辞都会反复斟酌。LLM 在这里相当于一个不会嫌你烦的改稿助手。我在实际使用里比较推荐的流程是先自己写一个粗糙版本再让模型按指定语气和格式改写。这样模型不是在替你思考而是在帮你把“想说的话”调整成“更合适的话”。比如“我写了一封催办邮件现在语气太生硬请改得委婉一些但不要失去重点。”“这是我本周做的事请整理成 5 行以内的周报突出结果而不是过程。”翻译场景更不用多说但有个重要前提领域术语需要你先给它一个术语表。否则同一个词在不同上下文里可能译法完全不同。对于合同、技术文档、产品说明这类高准确率要求的内容一定要让模型在输出后给出它不确定的术语清单你再人工确认。2.3 数据整理格式转换、批量清洗、信息对齐这里说的不是写代码处理数据而是让 LLM 充当流程里的“转换器”。最典型的是非结构化文本与结构化表格之间的转换。比如你有一段用户访谈文本需要整理成带“观点、证据、建议”的表格或者你有一批供应商发来的报价邮件需要提取出产品名、价格、交期合并成对比表又或者你手上有个 CSV 文件需要筛出不符合条件的行并且生成新的 CSV。这些工作都可以用 LLM 完成不一定需要写 Python。但要注意格式类任务对输入格式非常敏感。CSV 的空格、编码、缺列都会导致输出错乱。我的建议是每次处理前先给模型一小段样例让它先复述“你要从哪些字段提取什么”确认理解一致后再上完整数据。千万不要直接丢一个两万行的文件进去然后又问“为什么数不对”。2.4 思考辅助头脑风暴、多角度分析、知识学习这个场景更接近“思考搭档”。你可以让模型为一个新产品起名生成 20 个候选也可以让它扮演一个挑剔的用户给你刚写的方案挑毛病还可以让模型用“小学生能听懂的语言”给你解释一个陌生概念。学习场景尤其值得一试。传统搜索只能给你一堆链接而 LLM 可以按你的知识背景和目的重新组织解释逻辑。比如你问“什么是向量数据库”如果你补充一句“我了解数据库但没有机器学习背景”它的回答方式会完全不同。这个“按需定制解释”的能力放到非编码知识管理里非常实用。不过要注意学习场景最危险的也是幻觉。模型讲得很流畅但细节可能编错。我的习惯是先让它给出一个整体框架再用它给出的框架去找权威资料比对。也就是说LLM 用来搭骨架资料库用来填血肉不要反过来。3. 从“聊天式使用”升级为“可复用工作流”3.1 第一步把模糊需求变成明确的输入输出很多人用 LLM 处理非编码任务失败率高的原因就是需求太模糊。“帮我整理一下”这种指令换作人类同事也会一脸茫然模型更不可能猜中。更有效的方式是先定义输入和输出。拿到一个任务后自己先在心里过一遍输入是什么一段文字、一份 PDF、一段对话、一张表格输出是什么一段总结、一个表格、一封邮件、一个待办清单格式是什么Markdown 表格、纯文本、JSON、CSV质量标准是什么要完整保留所有关键信息还是只保留结论有没有边界比如“只基于我提供的材料不要补充外部知识”。把这些写在提示词里效果通常比反复修改“请更详细一点”要好得多。因为模型缺的不是努力而是约束。3.2 第二步用模板和约束把提示词变成“函数”聊天式使用是一次性的工作流是可复用的。如果你每周都要写周报、每天都要整理会议记录那就不应该每次都从头写提示词而是做成一套固定模板。一个通用模板可以包含这几个部分角色你是一个整理会议纪要的助手。背景/输入这是原始会议记录我放在“【原始内容】”标记后面。任务请输出四部分会议目标、关键决策、待办事项、风险点。格式要求待办事项用 Markdown 表格负责人和截止日期单独成列。约束只基于我提供的内容不要补充没提到的信息如果有信息缺失标为“待确认”。每次使用时只需要把【原始内容】换成新的会议记录即可。这样提示词本身就从“一次性指令”变成了一个“函数”输入变了处理逻辑和输出结构不变。网上有不少人把这类东西叫做“LLM 框架”。其实对非开发者来说不需要接触复杂的 Agent、RAG 或多模态编排一个结构清晰的提示词模板再配合一批固定的检查清单就已经是一个很好用的框架了。3.3 第三步借助脚本或 API 实现批处理如果你既要处理几十个文件又不想手动复制粘贴可以考虑用脚本调用 API 完成批处理。不一定需要很复杂的工程几十行 Python 就能把“读文件 → 调用模型 → 保存输出”整条链路跑通。下面是一个示意结构重点不是代码本身而是流程import json from openai import OpenAI client OpenAI( api_keyyour_api_key, base_urlhttps://api.example.com/v1 ) def process_text(text: str) - str: prompt f 你是一个信息整理助手。 请从以下内容中提取关键结论和待办事项输出为 JSON 格式 {{conclusions: [], action_items: []}} 【原始内容】 {text} resp client.chat.completions.create( modelyour-model-name, messages[{role: user, content: prompt}], temperature0.2 ) return resp.choices[0].message.content if __name__ __main__: raw 这里读取你本地的一个文件内容 result process_text(raw) print(result)这个示例里你不需要纠结具体模型或库的版本落地之前先确认你自己环境中可用的 API 地址、模型名和鉴权方式就行。真正重要的两个点先单条跑通再批量执行。先用一条样例确认输入格式、模型输出和你期望的结构一致再处理全部数据。给每个输出留一个 trace 字段。比如在返回结果里带上输入文件名、处理时间、模型名、原始输出方便出问题时回溯。3.4 一个判断框架什么样的非编码任务适合交给 LLM不是所有任务都适合用 LLM。我一般用三个维度来判断维度更适合 LLM不适合 LLM内容形态长文本、对话、非结构化数据强逻辑计算、精确统计、严格规则判断标准有弹性依赖语言理解必须唯一确定不能有歧义验证难度人工可以快速检查需要机器校验、代码校验隐私风险低敏感、可脱敏高敏感、不可外传如果你要处理的是一个任务需要“从一大段话里找出关键内容”LLM 很合适但如果你要的是“算出这个月所有订单的总额”那就直接用 Excel 或 SQL别绕道。这个框架也回答了开头那个 HN 问题非编码工作里能不能用 LLM取决于你把它用在“理解语言”还是“执行计算”上。绝大多数人对 LLM 失望是因为拿它去做了一件本来就不该由它做的事情。4. 在真实工作里落地会遇到哪些坑4.1 幻觉与事实错误不能验证的内容不能直接交付非编码任务最大的风险不是模型输出得不够快而是它会在流畅的表达里夹带错误信息。尤其当任务是总结、提取、翻译时模型生成的每一句话看起来都很有说服力但关键数字、人名、日期、引用来源都很可能出错。我的原则是模型生成的内容只能当草稿不能当最终交付物。尤其是涉及对外发送的邮件、合同条款、财务数据、法律信息必须经过人工核对。你可以让模型在输出末尾标出“我可能不确定的地方”这会迫使它把事实性风险暴露出来。一个实用技巧是要求模型“只基于我提供的材料回答”。如果它遇到材料里没有的信息要明确说“原文未提及”而不是自己补全。这会显著降低幻觉率。4.2 隐私与数据边界不是所有内容都能放进对话这一点容易被非技术背景的人忽略。你把一份客户合同、一份薪酬表、一份内部战略文档复制进聊天框等于把数据交给了外部服务。不同平台的保存策略不同但任何敏感信息都存在泄露风险。我们在工程里有个基本判断完全公开、无隐私风险的材料可以用公开模型。包含个人信息、商业机密、内部代码、未公开数据的内容必须走私有化部署或本地模型。即使走了本地模型也要注意日志、缓存、模型版本是否能关闭数据回传。如果你需要处理敏感文本至少要先做脱敏把姓名、公司名、具体金额替换成代号处理完再还原。4.3 上下文长度与成本输入越长风险越高很多人以为把整本手册、整个数据库一次性丢给模型就可以。但模型对长上下文的处理并不是无限可靠的。输入越长模型越容易丢失早期内容回答也越容易发散同时调用成本也会快速上升。更稳妥的做法是任务切片。比如一份 100 页的报告不要一次性让它“总结全部”而是先按章节拆成 10 个部分分别总结再把 10 段总结合并成一篇总览。这样每一段输入长度可控输出质量也更稳定。成本方面可以先用小模型或便宜的模型跑测试确认流程稳定后再切换到更强模型。很多非编码任务对模型的推理能力要求并没有想象中高常规总结、提取、改写中档模型就够用了。4.4 排查链路输出不对时先别急着换模型遇到输出质量差的时候先别断言“模型不行”。按下面这个顺序排查看提示词任务描述是否明确有没有给出输出格式有没有让模型知道只能基于什么材料看输入原始文本是否完整有没有因为复制粘贴丢掉换行或特殊符号字段名是否正确看格式要求是不是要求了模型难以直接输出的复杂格式比如多层嵌套 JSON、带图片的表格看上下文匹配模型是不是没有被准确告知“你要从哪个角度处理这份材料”看参数设置temperature 过高会随机过低会保守max tokens 太小会截断输出。看工具限制你用的模型版本、API 地址、上下文窗口是否支持你的输入长度这套链路适用于绝大部分情况。你会发现大多数输出问题最终出在“输入表达不清”而不是模型能力不足。一个常见现象是同一个提示词换一个模型效果差别很大。这是因为模型训练数据、对齐方式和指令遵循能力不同。但不要因为一次输出不满意就频繁换模型先把上述变量固定下来再谈模型对比。5. 怎么把 LLM 的非编码能力嵌入日常流程5.1 选一个高频、低风险任务开始如果你想在真实工作里用起来不需要从知识库管理系统开始也不要一上来就搞复杂工作流。最稳妥的方式是找一个“高频、低风险、输出容易检查”的任务先跑通。我推荐从“会议纪要 待办提取”开始。你只需要把会议对话粘贴进模型让它按固定格式输出结论和待办。这是个低风险任务即使模型提取漏了你也能在人工检查时发现而一旦你习惯了这种“先让模型起草再人工校对”的模式其他任务的迁移成本就会低很多。另一个好的起步任务是“邮件改写”。你写一封草稿让模型按语气、篇幅、对象进行改写。这个任务的输出可以在一分钟内人工判断好坏试错成本极低还能很快建立起你对模型表达能力的体感。5.2 建立自己的提示词库和输出检查清单一段时间之后你会积累不少好用的模板。别让它散落在聊天记录里。建议用 Markdown 文件或笔记软件建一个“提示词 检查清单”库结构可以是这样prompt-library/ ├── meeting-minutes.md ├── email-rewrite.md ├──>