1. 从考完试说起AI考试到底在考什么第一次听说AI考试这个词很多人脑子里浮现的可能是让大模型做高考试卷、写作文、解数学题。但我这次参与的AI考试完全是另一回事——它考的不是模型本身的知识储备而是人怎么把AI用起来解决真实任务。说白了考的是工作流设计能力。这场考试的形式大致是这样的给定若干个真实场景任务比如从一堆简历里筛出符合岗位要求的候选人把一份Markdown格式的技术文档转成排版规范的Word根据一段文字描述生成一张配图要求你在限定时间内用AI工具组合出一套可复现、可交付的流程最终产出符合质量标准的结果。评分维度不只是结果对不对还包括流程是否稳定换个人能不能照着跑通遇到异常输入会不会崩。这就把问题从模型强不强拉到了工作流顺不顺。我见过太多人用AI的方式还停留在打开对话框敲一句话等结果不满意就重敲的阶段。这种方式偶尔能出好结果但你没法保证第二次、第三次还能复现。而工作流的核心价值恰恰在于把偶然的好结果变成必然的稳定输出。打个比方单次对话调AI就像用手抓沙子抓一把漏一把工作流则是给沙子装了个漏斗和模具每次倒进去多少、出来什么形状都是可控的。考试考的就是你造漏斗和模具的能力。我研究了一段时间之后慢慢摸出了一套自己的方法论。这套东西不依赖某个特定平台换成任何主流工具都能落地。下面我把整个思考过程和实操细节拆开讲尽量让刚接触的人也能照着搭起来。2. 工作流和多问几遍的本质区别在哪2.1 单次对话的三个致命伤先说说为什么多问几遍不叫工作流。我总结下来有三个硬伤第一是不可复现。同样一句话今天问和明天问模型给的答案可能完全不同。温度参数、上下文长度、甚至你前面聊过什么都会影响输出。你没法跟同事说你就照我那样问因为那样问本身就不精确。第二是不可组合。真实任务往往需要多步先提取信息再判断分类再格式化输出。单次对话里你把这些要求全塞进一个提示词模型很容易顾此失彼——顾了格式就漏了判断顾了判断就忘了格式。第三是不可监控。中间哪一步出了问题你根本不知道。是提取错了还是判断逻辑偏了还是最后格式化时丢了字段全黑箱。2.2 工作流把黑箱拆成透明管道工作流的思路是把一个大任务拆成若干个职责单一的小节点每个节点只干一件事节点之间用明确的数据结构传递。这样做的好处是每个节点可以单独测试、单独调优出问题能定位到具体环节节点之间的输入输出格式固定换模型、换工具都不影响整体整个流程可以保存、分享、版本管理别人能一键复现我拿简历筛选这个场景举例。单次对话的做法是把简历全文和岗位要求一起丢给模型说帮我判断这个人合不合适。工作流的做法是拆成四步信息抽取节点从简历里结构化提取姓名、学历、工作年限、技能栈、项目经历硬性条件过滤节点用规则判断学历、年限是否达标这步甚至不需要AI纯代码更快更准匹配度评分节点把岗位要求和候选人信息一起给模型输出匹配分数和理由汇总输出节点把通过筛选的人按分数排序生成一份表格你看拆开之后每一步都清清楚楚。第二步用规则而不是AI是因为硬性条件用代码判断零误差、零成本第三步才需要模型的语义理解能力。这种该用代码用代码该用模型用模型的取舍就是工作流设计的核心功力。2.3 一个判断标准能不能交给别人跑我有个很实用的判断标准如果你的流程没法交给一个完全不懂AI的同事让他照着步骤跑出一样的结果那它就还不是工作流。这个标准逼着你去消除所有模糊地带。比如适当调整一下语气这种指令就不合格得改成把正式书面语替换为口语化表达句子长度控制在20字以内。再比如挑几个好的也不合格得改成按匹配分数降序取前5个。考试里我最大的收获就是被这个标准反复捶打。很多我自以为说清楚了的地方换个人一跑就出岔子回头一看全是模糊指令惹的祸。3. 我搭工作流时反复用的四层结构摸索了一段时间后我发现不管什么场景工作流基本都能套进一个四层结构里。这不是什么官方框架是我自己踩坑踩出来的经验总结但用起来确实顺手。3.1 输入层先把脏数据洗干净很多人一上来就急着调模型结果输入的数据格式乱七八糟模型再强也救不回来。输入层要做的事就一件把各种来源的原始数据统一成规范格式。具体包括格式统一PDF、图片、网页、纯文本先转成纯文本或结构化JSON字段对齐不同来源的简历字段名可能不一样统一成一套标准字段异常处理空值、乱码、超长文本提前截断或标记我踩过的一个坑是有份简历是图片格式直接丢给文本模型它看图说话编了一堆不存在的内容。后来我在输入层加了一步OCR识别识别完再让模型处理准确率立刻上来了。输入层的脏活累活不能省省了后面全是坑。3.2 处理层节点拆分与职责边界处理层是工作流的主体核心原则是一个节点只干一件事。我一般按抽取—判断—生成三类来划分节点节点类型职责常用手段注意事项抽取类从非结构化文本里提取结构化信息模型JSON Schema约束字段定义要精确避免模型自由发挥判断类分类、打分、过滤规则优先模型兜底能用代码判断的绝不用模型生成类产出最终文本、图片、文件模型模板输出格式用模板固定减少模型自由度节点之间的数据传递我强烈建议用结构化格式JSON最通用而不是自然语言。自然语言传递信息下一个节点还得重新理解一遍既慢又容易出错。JSON传过去字段名就是字段名值就是值清清楚楚。3.3 输出层格式固定减少最后一公里的意外输出层最容易被忽视但它决定了你的工作流能不能直接交付。我的经验是输出格式一定要用模板固定死不要让模型自由发挥。比如生成Word文档我会先用模板定义好标题样式、段落间距、字体字号模型只负责填内容格式由模板保证。这样出来的文档每次都是统一的不会这次标题大下次标题小。再比如生成表格我会在提示词里明确给出表头和列的顺序甚至给出一个示例行。模型照着填就行不会自己发明新列。3.4 反馈层让工作流自己发现问题这是很多人不做但特别有价值的一层。反馈层的思路是在关键节点加校验发现异常就回退或告警。举个简单例子简历筛选工作流里如果某个候选人的匹配分数是空的或者格式不对反馈层就标记这条记录让人工复核。而不是让一条坏数据悄悄流到最终结果里。再比如生成文档的工作流输出前检查一下字数、段落数是否在合理范围超出范围就重新生成或提示。这种自检机制能挡掉大部分低级错误。4. 几个真实场景的拆解与参数取舍光讲结构有点虚我拿三个考试里遇到的真实场景把参数和取舍讲透。4.1 简历筛选规则和模型的分工线画在哪这个场景前面提过这里重点讲分工线怎么画。我的原则是能用确定性规则判断的绝不交给模型。学历是否达标、工作年限是否够、是否具备某个证书这些用代码判断准确率100%成本几乎为零。模型只负责那些需要语义理解的部分比如项目经历和岗位的相关性技能栈的深度。具体参数上我做了这些设置硬性条件过滤学历、年限、必备技能用代码判断不通过直接淘汰匹配度评分让模型输出0-100分并给出评分理由评分维度拆解把匹配度拆成技能匹配经验匹配行业匹配三个子项分别打分再加权为什么要拆子项因为直接让模型给一个总分它的评分标准会飘。拆成子项后每个子项的定义更清晰评分更稳定。加权系数根据岗位调整比如技术岗技能权重高管理岗经验权重高。提示让模型输出评分理由非常重要。理由不只是给人看的它还能帮你发现模型的判断逻辑有没有跑偏。如果理由和分数对不上说明这个节点的提示词需要调。4.2 Markdown转Word为什么不能一步到位这个场景看起来简单但坑特别多。很多人想一步到位把Markdown丢给模型说转成Word。结果出来的文档格式乱七八糟标题层级丢了代码块变成普通文本表格错位。我的做法是拆成三步解析节点把Markdown解析成结构化的AST抽象语法树标题、段落、列表、代码块、表格各归各类映射节点把AST节点映射到Word的样式标题1对应Heading 1代码块对应等宽字体段落渲染节点用文档生成库按映射关系渲染出Word文件这三步里模型其实只在第二步的样式选择上帮点忙比如判断某个段落该用引用样式还是普通样式。真正核心的解析和渲染用现成的库比模型靠谱得多。我踩过的坑是一开始想全用模型做结果每次输出的格式都不一样根本没法用。后来改成库为主、模型为辅稳定性立刻上来了。这个教训很值钱不是所有环节都适合用AI该用传统工具的地方就用传统工具。4.3 图片生成提示词工程和工作流的配合图片生成场景里工作流的价值在于把模糊需求翻译成精确提示词。用户给的原始需求往往很模糊比如要一张科技感的配图。直接丢给图片模型出来的东西全凭运气。我的工作流是这样需求解析节点把模糊需求拆成主体风格色调构图四个维度提示词生成节点每个维度生成具体的描述词比如主体一台笔记本电脑风格极简科技风色调蓝紫渐变构图居中对称提示词组装节点按图片模型要求的格式组装成完整提示词生成与筛选节点生成多张按预设标准筛选这里的关键是把主观需求结构化。结构化之后每次生成的图风格就稳定了不会这次冷色调下次暖色调。参数上我一般生成4张候选图然后按主体清晰度风格一致性构图合理性三个维度打分选最高分。这个筛选步骤可以人工做也可以让视觉模型做看你对自动化的要求。5. 踩过的坑和对应的解法这部分是我觉得最有价值的内容因为都是真金白银换来的教训。5.1 上下文超长导致的信息丢失工作流跑长文档时最容易遇到的就是上下文超长。模型处理到后面前面的信息就忘了导致输出前后矛盾。我的解法是分段处理摘要传递。把长文档切成若干段每段单独处理处理完生成一个摘要下一段处理时把前面的摘要带上。这样既控制了单次输入的上下文长度又保证了信息的连贯性。具体切分策略按语义边界切不要按固定字数硬切。比如按章节切、按段落切保证每段是完整的语义单元。硬切会把一句话切成两半模型理解起来就费劲了。5.2 节点之间的信息衰减工作流节点多了之后信息会在传递过程中衰减。第一个节点提取了10个字段传到第五个节点可能只剩5个了中间不知道在哪丢了。解法是在每个节点加输入输出日志。每个节点处理前后都把数据打印出来跑一遍就能看到哪个节点丢了信息。这个习惯帮我定位了无数问题。另外节点之间的数据结构要显式定义不要用模型自己看着办的方式传递。显式定义意味着每个字段都有名字、有类型、有是否必填的标记传丢了立刻能发现。5.3 模型自作主张改了格式这个坑特别隐蔽。你明明规定了输出JSON模型有时候会加个好的以下是结果的前缀或者把JSON包在Markdown代码块里导致解析失败。解法有三层提示词层面明确说只输出JSON不要任何其他文字解析层面解析前先做清洗去掉可能的前缀、代码块标记校验层面解析失败就重试重试还失败就标记异常我一般会设置重试次数为2-3次。超过次数还失败说明这个节点的提示词有问题得回去改。5.4 成本失控什么时候该用便宜模型工作流跑起来之后成本是个绕不开的问题。如果每个节点都用最强的模型成本会高得吓人。我的策略是按节点重要性分配模型抽取类节点用中等模型即可因为任务相对简单判断类节点用强模型因为判断质量直接影响结果生成类节点看输出质量要求要求高的用强模型要求一般的用中等模型这样搭配下来成本能降一半以上质量几乎不受影响。不是所有环节都需要最强模型把好钢用在刀刃上。6. 让工作流真正跑得久的维护心得搭起来只是第一步能长期稳定跑才是本事。分享几个维护上的心得。6.1 版本管理每次改动都留痕工作流是会不断迭代的。今天调个提示词明天换个模型后天加个节点。如果不做版本管理出了问题你都不知道是哪个改动引起的。我的做法是每次改动都记录改了什么、为什么改、改完效果如何。用简单的文本文件记就行不用上复杂的工具。关键是养成习惯。另外重要的工作流我会保留一个稳定版新改动先在测试版上跑验证没问题再合并到稳定版。这样不会因为一次冒进的改动把整个流程搞崩。6.2 异常处理给每个节点留后路工作流跑久了什么奇怪输入都会遇到。空值、超长文本、格式错误、编码问题防不胜防。我的原则是每个节点都要有异常处理输入不符合预期标记异常跳过或走默认逻辑模型输出解析失败重试重试失败标记异常下游节点收到异常数据拒绝处理向上游报错异常数据不要让它悄悄流过去一定要显式标记。我一般会在数据结构里加一个status字段正常是ok异常是error并附带错误信息。这样最终输出时能一眼看出哪些记录有问题。6.3 定期回归测试别让改动引入新问题工作流改多了很容易出现改好了A弄坏了B的情况。定期跑一遍回归测试很有必要。我的做法是准备一组标准测试用例覆盖正常情况、边界情况、异常情况。每次改动后跑一遍看结果是否符合预期。测试用例不用多十几个就够关键是覆盖到位。这套测试用例也是我考试时的秘密武器。因为考试要求流程可复现我提前准备好了测试用例现场跑一遍就能证明流程是稳定的。7. 关于AI工作流我现在的几个真实判断聊了这么多技术细节最后说几个我自己的判断不一定对但都是实操后的真实感受。第一工作流的天花板不在模型在设计。同样的模型不同的人搭出来的工作流效果能差好几倍。差距不在模型调用技巧而在任务拆解、节点划分、数据流转这些设计层面的功夫。这部分能力靠的是对业务的理解和对细节的把控不是靠追新模型。第二能用规则的地方别用AI。这是我反复强调的一点。AI擅长的是模糊判断和语义理解不擅长精确计算和格式转换。把AI用在它擅长的地方把规则用在规则擅长的地方整体效果最好成本最低。第三工作流的价值在于可交付。一个工作流如果只有你自己能跑那它的价值有限。能交给别人跑、能稳定复现、能应对异常才真正有价值。这也是我判断一个工作流好不好的核心标准。第四别追求一步到位。我见过太多人想搭一个完美工作流结果卡在第一步迟迟不动。正确的做法是先搭一个能跑通的最小版本然后在使用中不断迭代。我的很多工作流都是从一个粗糙的版本开始跑了几个月才慢慢打磨成现在这样。第五记录比记忆重要。工作流里的每个参数、每个提示词、每次改动都值得记下来。因为过一段时间你肯定会忘忘了就得重新试重新试就得重新踩坑。养成记录的习惯能省下大量重复劳动。这套方法论我还在持续打磨每次遇到新场景都会有新体会。但核心思路是稳定的拆解任务、明确职责、结构化传递、加校验、留后路。把这几点做到位大部分场景的工作流都能搭得又稳又好用。