最近在折腾一个自动化脚本需要批量处理一批文档然后生成对应的分析报告。我试了几个方案要么配置太复杂要么输出格式不灵活。后来看到有人提到 ChatGPT 的 Work 模式说它能把多轮对话变成一个可复用的工作流。我一开始没太在意觉得不就是把聊天记录保存下来吗直到我真正用 Work 模式把一个复杂的文档处理任务跑通才意识到它的价值远不止“保存对话”那么简单。很多人把 ChatGPT 当作一个即问即答的聊天机器人问一个问题得到一个答案然后结束。这在处理简单、独立的任务时没问题。但当你面对一个需要多步骤、有上下文依赖、并且需要反复执行类似流程的任务时这种“单次对话”的模式就显得力不从心了。你需要记住上一步做了什么手动把上一步的输出复制粘贴到下一步的输入里还要确保每次的指令格式一致。这个过程不仅繁琐而且极易出错。ChatGPT 的 Work 模式本质上解决的就是这个问题它把一次性的、线性的对话变成了一个结构化的、可重复执行的“工作流”或“脚本”。这听起来可能有点抽象但它的实际影响是让你从“每次都要重新教 AI 做事”的重复劳动中解放出来转向“定义好流程让 AI 自动执行”的更高阶协作。1. 从“聊天”到“工作流”理解 Work 模式的本质转变要理解 Work 模式的价值首先要跳出“聊天”的思维定式。传统的 ChatGPT 对话是状态短暂的。你关闭网页对话历史虽然保存但那个包含了上下文、角色设定和临时指令的“会话状态”就结束了。下次即使打开同样的历史记录你也需要重新建立上下文或者手动复制粘贴关键信息。Work 模式引入了一个核心概念可复用的对话模板。你可以把它想象成编程中的一个函数。你定义好这个函数的输入参数初始提示词、系统指令、用户消息模板、处理逻辑多轮对话的固定结构和输出格式。之后你只需要更换输入数据就能批量“调用”这个函数得到结构化的输出。1.1 Work 模式解决了哪类具体问题根据我的使用体验以下几类任务特别适合用 Work 模式来优化结构化内容生成比如你每周都需要根据一堆产品数据生成一份包含市场趋势、竞品分析和行动建议的周报。在 Work 模式里你可以创建一个“周报生成器”工作流。第一步让 AI 提取数据中的关键指标第二步基于指标分析趋势第三步结合趋势给出建议。每次只需输入新的数据表格就能自动走完这三步输出格式统一的周报草稿。多步骤信息处理例如从一篇长文章中提取核心观点然后将观点翻译成另一种语言最后再根据翻译内容生成一个社交媒体帖子。手动操作需要三次独立的对话并且要传递中间结果。在 Work 模式中你可以把“提取-翻译-生成”这三步固化下来一次性完成。标准化问答与审核客服常见问题模板、代码审查清单、内容合规性检查等。你可以建立一个审核工作流输入待检查的文本AI 会按照预设的多个维度如语法、逻辑、合规点依次检查并输出结果列表。1.2 一个关键认知Work 模式不是“魔法”而是“流程封装”很多人期待 Work 模式能“一键解决所有问题”这是不现实的。它的核心价值在于“封装”和“复用”。你依然需要清晰地定义每一步要做什么给出明确的指令并设计好步骤之间的信息传递。它的优势在于一旦你花时间调试好一个高效的工作流后续的每一次执行都是低成本、高一致性的。这就像你写了一个 Shell 脚本来自动化部署。第一次写脚本可能花了你一小时比手动部署还慢。但之后每次部署你只需要运行这个脚本几秒钟就完成了。Work 模式就是给 ChatGPT 的交互过程写“脚本”。2. 实战构建你的第一个文档分析工作流理论说再多不如动手试一次。我们以一个具体的场景为例分析一批技术博客文章提取其核心主题、技术栈关键词并评估其内容深度入门/进阶/专家级。在普通聊天模式下你可能需要这样操作复制第一篇博客内容问“请提取这篇文章的核心主题。”复制 AI 回复的主题再问“这篇文章提到了哪些技术栈关键词”最后再问“你认为这篇文章的内容深度如何” 然后对第二篇、第三篇博客重复上述所有步骤。下面我们看看如何在 Work 模式中将其固化。2.1 创建工作流与定义系统角色首先进入 ChatGPT 界面找到创建或管理 Work 的入口具体位置可能因版本更新而变化通常在侧边栏或设置中。创建一个新的 Work。第一步也是最重要的一步是设定清晰的“系统指令”。这相当于定义了这个工作流的全局角色和任务边界。系统指令示例 你是一个技术内容分析师。你的任务是按步骤分析用户提供的技术博客文章。请严格遵循以下步骤执行并在每个步骤后等待我的确认或提供下一步所需的输入。最终输出一个结构化的 JSON 格式结果。这个系统指令明确了角色技术内容分析师、任务分析博客和模式分步骤、结构化输出。2.2 设计多轮对话步骤接下来不是直接开始聊天而是规划对话的步骤。在 Work 模式中你可以预先添加多个“消息块”并设定它们的类型用户/助手和内容。我们可以设计三个步骤步骤一用户消息请分析以下技术博客文章提取其最核心的1个主题。 文章内容 {{article_content}}这里{{article_content}}是一个变量占位符。这是 Work 模式的关键功能之一。执行工作流时你需要为这个变量提供实际值。步骤二用户消息基于上述文章和已提取的主题列出文中提到的所有技术栈关键词如编程语言、框架、工具等最多10个。注意这里指令中提到了“上述文章”和“已提取的主题”。在 Work 模式运行时AI 是能看到整个对话上下文的因此它知道“上述”指的是什么。步骤三用户消息综合主题和关键词判断这篇文章的内容深度。请从以下三个级别中选择其一 - 入门级面向新手介绍基础概念和简单操作。 - 进阶级需要一定前置知识探讨实现原理、最佳实践或中等复杂度方案。 - 专家级涉及底层机制、架构设计、性能优化或前沿探索。 请简要说明理由。2.3 定义输出与执行最后你需要告诉 AI 最终如何呈现结果。可以在最后一步或者通过系统指令来要求。最终输出要求可放在系统指令或最后一步 请将以上三步的分析结果整合以如下 JSON 格式输出{ core_topic: 提取的核心主题, tech_keywords: [关键词1, 关键词2, ...], content_depth: { level: 入门级/进阶级/专家级, reason: 判断理由 } }工作流设计完成后保存。当你需要分析一篇新文章时你只需要打开这个工作流。在运行界面将变量{{article_content}}替换为真实的博客文本。点击运行。AI 会自动按步骤执行并最终输出一个结构化的 JSON 对象。这才是效率的飞跃你不再需要手动分三次提问、复制粘贴中间结果。你定义了一次流程之后就是“输入文章 - 获得结构化报告”的自动化操作。3. 进阶技巧让工作流更可靠、更强大一个能跑通的工作流只是开始。要让它在实际工作中可靠、高效地运行还需要考虑以下几个进阶问题。3.1 处理长文本与上下文管理技术博客文章可能很长超出模型的单次上下文限制。直接抛入长文本可能导致截断或分析不全。解决方案预处理摘要可以在工作流外部先用一个简单的提示词让 AI 对长文进行摘要再将摘要输入工作流。或者在工作流内部第一步就增加一个“生成摘要”的环节。分块处理对于需要全文分析的任务可以设计工作流先对文章进行分块如按章节然后对每一块执行分析最后再有一个步骤来汇总各块结果。这需要更复杂的设计但能处理任意长度的文档。明确指令在系统指令中要求 AI“如果输入文本过长请专注于开头引言、各级标题和结论段落进行分析以获取核心信息。”3.2 提高输出的一致性与准确性AI 的输出可能存在波动性同一篇文章运行两次提取的关键词可能略有不同。解决方案细化指令不要只说“提取关键词”。改为“提取文中明确提及的、具体的软件技术名称如‘Python’、‘React’、‘Docker’、‘Kubernetes’。忽略泛指的词汇如‘系统’、‘工具’、‘平台’。”提供示例在系统指令中给出一个例子One-shot/Few-shot Learning让 AI 模仿输出格式和风格。后处理校验对于要求极高的场景可以将工作流的输出作为初稿再添加一个“人工校验或AI二次校验”的步骤。例如让另一个 AI 角色检查提取的关键词是否都确实在原文中出现过。3.3 工作流的参数化与批量处理真正的威力在于批量处理。你可能有几十上百篇文章需要分析。操作思路确保工作流高度参数化就像上面的例子只有{{article_content}}是变量。其他指令都应固化。准备输入数据将多篇文章内容整理成一个列表如 CSV 文件每行一篇文章。通过 API 调用这是实现自动化的关键。ChatGPT 提供 API你可以写一个简单的脚本Python 等读取你的文章列表。为每一篇文章构建一个 API 请求请求中包含了你的整个工作流定义系统消息、对话历史和当前文章的变量值。发送请求接收并解析返回的 JSON 结果。将结果保存到数据库或文件中。# 概念性示例代码非直接可运行 import openai import json # 你的工作流定义简化表示 workflow_messages [ {role: system, content: 你是技术内容分析师...}, {role: user, content: 请分析以下文章...\n{{article}}}, # ... 更多步骤 ] def analyze_article(article_text): # 将变量替换为实际文章 messages [msg if msg[content].find({{article}}) -1 else {role: msg[role], content: msg[content].replace({{article}}, article_text)} for msg in workflow_messages] response openai.ChatCompletion.create( modelgpt-4, # 或你使用的模型 messagesmessages, temperature0.2, # 降低随机性提高一致性 ) # 解析返回的 JSON 结果 result_text response.choices[0].message.content # 这里假设 AI 返回的是纯 JSON 字符串 try: return json.loads(result_text) except: return {error: result_text} # 批量处理 articles [文章1内容, 文章2内容, ...] all_results [] for article in articles: result analyze_article(article) all_results.append(result) # 可选添加延迟以避免速率限制通过 API 批量调用你就能实现全自动的、大规模的内容分析流水线。4. 避坑指南与长期使用思考Work 模式很强大但如果不注意一些细节很容易踩坑或者觉得它“不好用”。4.1 常见问题与排查输出格式不稳定AI 有时可能不严格按照你要求的 JSON 格式输出而是输出一段文字。对策在指令中强烈要求例如“你必须且只能输出一个合法的 JSON 对象不要有任何额外的解释、前缀或后缀。” 同时在代码中做好异常处理如果解析 JSON 失败可以记录原始输出以便调试。变量替换失败执行时发现变量{{var}}没有被替换。对策检查工作流编辑界面确认变量名书写一致包括大小写。确保在执行界面正确地为变量赋值。如果是通过 API 调用确保你的替换逻辑正确。上下文混淆在多轮复杂工作流中AI 可能会搞错步骤之间的信息归属。对策简化工作流设计避免过多的分支和循环当前 Work 模式对复杂逻辑支持有限。在每一步的指令中明确引用所需的信息例如“基于第一步中提取的主题进行如下分析...”。Token 消耗与成本工作流步骤越多对话越长消耗的 Token 就越多API 调用成本越高。对策优化指令去除冗余描述。对于长文本输入考虑先进行本地预处理如提取关键段落。对于非关键步骤可以考虑使用更经济的模型如果支持。4.2 Work 模式 vs. 自定义GPTs vs. API直接编程你可能会有疑问Work 模式、OpenAI 的 GPTs 功能以及直接用 API 编程有什么区别该如何选择特性ChatGPT Work 模式OpenAI GPTs直接调用 API 编程上手难度低在聊天界面内可视化配置中需要配置指令、知识库、动作高需要编程能力灵活性中适合线性、多步骤对话流程中高可以结合知识库和外部动作极高可实现任意复杂逻辑复用与分享中可在账户内复用分享可能受限高可发布给他人使用高代码本身易于分享和版本管理自动化程度低依赖手动触发或简单调度中可通过 API 或界面触发极高可集成进任何系统全自动调度适用场景个人或小团队将常用复杂对话流程化构建具有特定知识和能力的 AI 助手并对外提供企业级应用需要稳定、高性能、定制化的 AI 集成如何选择如果你是个人用户只是想把自己在 ChatGPT 里经常重复的一套提问方法保存下来Work 模式是最快、最直接的选择。如果你想构建一个功能更完整、可以对外分享的专用助手比如一个代码评审助手内置了代码规范知识并且不想写代码那么GPTs更合适。如果你需要将 AI 能力深度集成到自己的软件系统、后台服务或批量数据处理管道中追求完全的掌控力、自动化调度和成本优化那么直接使用 API 并编写程序是唯一的选择。Work 模式可以作为一个很好的原型设计工具帮你验证流程然后再用代码实现。4.3 长期价值从使用工具到设计流程最终ChatGPT Work 模式带给我的最大启发不是多了一个功能而是思维模式的转变。它促使我们从一个被动的“工具使用者”转变为一个主动的“流程设计者”。以前我们遇到问题思考的是“我怎么向 AI 提问才能得到答案”。现在我们可以思考“这个问题可以分解为哪几个标准步骤每个步骤的输入输出是什么如何把它们串联成一个稳定可靠的流程”这种思维不仅适用于 ChatGPT也适用于我们使用其他软件、管理项目、甚至处理日常工作。它关乎的是如何将隐性的、依赖个人临场发挥的经验转化为显性的、可重复、可优化、可移交的标准化流程。这或许才是 AI 时代我们最需要培养的核心能力之一。Work 模式正是练习这种能力的一个绝佳沙盒。