企业官网建设流程全解析

1. 从"考完试"说起：AI考试到底在考什么

第一次听说"AI考试"这个词，很多人脑子里浮现的可能是让大模型做高考试卷、写作文、解数学题。但我这次参与的"AI考试"完全是另一回事——它考的不是模型本身的知识储备，而是人怎么把AI用起来解决真实任务。说白了，考的是工作流设计能力。

这场考试的形式大致是这样的：给定若干个真实场景任务，比如"从一堆简历里筛出符合岗位要求的候选人""把一份Markdown格式的技术文档转成排版规范的Word""根据一段文字描述生成一张配图"，要求你在限定时间内，用AI工具组合出一套可复现、可交付的流程，最终产出符合质量标准的结果。评分维度不只是"结果对不对"，还包括"流程是否稳定""换个人能不能照着跑通""遇到异常输入会不会崩"。

这就把问题从"模型强不强"拉到了"工作流顺不顺"。我见过太多人用AI的方式还停留在"打开对话框，敲一句话，等结果，不满意就重敲"的阶段。这种方式偶尔能出好结果，但你没法保证第二次、第三次还能复现。而工作流的核心价值恰恰在于把偶然的好结果变成必然的稳定输出。

打个比方：单次对话调AI就像用手抓沙子，抓一把漏一把；工作流则是给沙子装了个漏斗和模具，每次倒进去多少、出来什么形状，都是可控的。考试考的就是你造漏斗和模具的能力。

我研究了一段时间之后，慢慢摸出了一套自己的方法论。这套东西不依赖某个特定平台，换成任何主流工具都能落地。下面我把整个思考过程和实操细节拆开讲，尽量让刚接触的人也能照着搭起来。

2. 工作流和"多问几遍"的本质区别在哪

2.1 单次对话的三个致命伤

先说说为什么"多问几遍"不叫工作流。我总结下来有三个硬伤：

第一是不可复现。同样一句话，今天问和明天问，模型给的答案可能完全不同。温度参数、上下文长度、甚至你前面聊过什么，都会影响输出。你没法跟同事说"你就照我那样问"，因为"那样问"本身就不精确。

第二是不可组合。真实任务往往需要多步：先提取信息，再判断分类，再格式化输出。单次对话里你把这些要求全塞进一个提示词，模型很容易顾此失彼——顾了格式就漏了判断，顾了判断就忘了格式。

第三是不可监控。中间哪一步出了问题，你根本不知道。是提取错了？还是判断逻辑偏了？还是最后格式化时丢了字段？全黑箱。

2.2 工作流把黑箱拆成透明管道

工作流的思路是把一个大任务拆成若干个职责单一的小节点，每个节点只干一件事，节点之间用明确的数据结构传递。这样做的好处是：

• 每个节点可以单独测试、单独调优，出问题能定位到具体环节
• 节点之间的输入输出格式固定，换模型、换工具都不影响整体
• 整个流程可以保存、分享、版本管理，别人能一键复现

我拿"简历筛选"这个场景举例。单次对话的做法是：把简历全文和岗位要求一起丢给模型，说"帮我判断这个人合不合适"。工作流的做法是拆成四步：

1. 信息抽取节点：从简历里结构化提取姓名、学历、工作年限、技能栈、项目经历
2. 硬性条件过滤节点：用规则判断学历、年限是否达标（这步甚至不需要AI，纯代码更快更准）
3. 匹配度评分节点：把岗位要求和候选人信息一起给模型，输出匹配分数和理由
4. 汇总输出节点：把通过筛选的人按分数排序，生成一份表格

你看，拆开之后每一步都清清楚楚。第二步用规则而不是AI，是因为硬性条件用代码判断零误差、零成本；第三步才需要模型的语义理解能力。这种"该用代码用代码，该用模型用模型"的取舍，就是工作流设计的核心功力。

2.3 一个判断标准：能不能交给别人跑

我有个很实用的判断标准：如果你的流程没法交给一个完全不懂AI的同事，让他照着步骤跑出一样的结果，那它就还不是工作流。

这个标准逼着你去消除所有模糊地带。比如"适当调整一下语气"这种指令就不合格，得改成"把正式书面语替换为口语化表达，句子长度控制在20字以内"。再比如"挑几个好的"也不合格，得改成"按匹配分数降序取前5个"。

考试里我最大的收获就是被这个标准反复捶打。很多我自以为说清楚了的地方，换个人一跑就出岔子，回头一看全是模糊指令惹的祸。

3. 我搭工作流时反复用的四层结构

摸索了一段时间后，我发现不管什么场景，工作流基本都能套进一个四层结构里。这不是什么官方框架，是我自己踩坑踩出来的经验总结，但用起来确实顺手。

3.1 输入层：先把"脏数据"洗干净

很多人一上来就急着调模型，结果输入的数据格式乱七八糟，模型再强也救不回来。输入层要做的事就一件：把各种来源的原始数据统一成规范格式。

具体包括：

• 格式统一：PDF、图片、网页、纯文本，先转成纯文本或结构化JSON
• 字段对齐：不同来源的简历字段名可能不一样，统一成一套标准字段
• 异常处理：空值、乱码、超长文本，提前截断或标记

我踩过的一个坑是：有份简历是图片格式，直接丢给文本模型，它"看图说话"编了一堆不存在的内容。后来我在输入层加了一步OCR识别，识别完再让模型处理，准确率立刻上来了。输入层的脏活累活不能省，省了后面全是坑。

3.2 处理层：节点拆分与职责边界

处理层是工作流的主体，核心原则是一个节点只干一件事。我一般按"抽取—判断—生成"三类来划分节点：

节点之间的数据传递我强烈建议用结构化格式（JSON最通用），而不是自然语言。自然语言传递信息，下一个节点还得重新理解一遍，既慢又容易出错。JSON传过去，字段名就是字段名，值就是值，清清楚楚。

3.3 输出层：格式固定，减少"最后一公里"的意外

输出层最容易被忽视，但它决定了你的工作流能不能直接交付。我的经验是：输出格式一定要用模板固定死，不要让模型自由发挥。

比如生成Word文档，我会先用模板定义好标题样式、段落间距、字体字号，模型只负责填内容，格式由模板保证。这样出来的文档每次都是统一的，不会这次标题大下次标题小。

再比如生成表格，我会在提示词里明确给出表头和列的顺序，甚至给出一个示例行。模型照着填就行，不会自己发明新列。

3.4 反馈层：让工作流自己发现问题

这是很多人不做但特别有价值的一层。反馈层的思路是：在关键节点加校验，发现异常就回退或告警。

举个简单例子：简历筛选工作流里，如果某个候选人的匹配分数是空的，或者格式不对，反馈层就标记这条记录，让人工复核。而不是让一条坏数据悄悄流到最终结果里。

再比如生成文档的工作流，输出前检查一下字数、段落数是否在合理范围，超出范围就重新生成或提示。这种"自检"机制能挡掉大部分低级错误。

4. 几个真实场景的拆解与参数取舍

光讲结构有点虚，我拿三个考试里遇到的真实场景，把参数和取舍讲透。

4.1 简历筛选：规则和模型的分工线画在哪

这个场景前面提过，这里重点讲分工线怎么画。

我的原则是：能用确定性规则判断的，绝不交给模型。学历是否达标、工作年限是否够、是否具备某个证书，这些用代码判断，准确率100%，成本几乎为零。模型只负责那些需要语义理解的部分，比如"项目经历和岗位的相关性""技能栈的深度"。

具体参数上，我做了这些设置：

• 硬性条件过滤：学历、年限、必备技能，用代码判断，不通过直接淘汰
• 匹配度评分：让模型输出0-100分，并给出评分理由
• 评分维度拆解：把匹配度拆成"技能匹配""经验匹配""行业匹配"三个子项，分别打分再加权

为什么要拆子项？因为直接让模型给一个总分，它的评分标准会飘。拆成子项后，每个子项的定义更清晰，评分更稳定。加权系数根据岗位调整，比如技术岗技能权重高，管理岗经验权重高。

提示：让模型输出评分理由非常重要。理由不只是给人看的，它还能帮你发现模型的判断逻辑有没有跑偏。如果理由和分数对不上，说明这个节点的提示词需要调。

4.2 Markdown转Word：为什么不能一步到位

这个场景看起来简单，但坑特别多。很多人想一步到位：把Markdown丢给模型，说"转成Word"。结果出来的文档格式乱七八糟，标题层级丢了，代码块变成普通文本，表格错位。

我的做法是拆成三步：

1. 解析节点：把Markdown解析成结构化的AST（抽象语法树），标题、段落、列表、代码块、表格各归各类
2. 映射节点：把AST节点映射到Word的样式（标题1对应Heading 1，代码块对应等宽字体段落）
3. 渲染节点：用文档生成库按映射关系渲染出Word文件

这三步里，模型其实只在第二步的"样式选择"上帮点忙，比如判断某个段落该用引用样式还是普通样式。真正核心的解析和渲染，用现成的库比模型靠谱得多。

我踩过的坑是：一开始想全用模型做，结果每次输出的格式都不一样，根本没法用。后来改成"库为主、模型为辅"，稳定性立刻上来了。这个教训很值钱：不是所有环节都适合用AI，该用传统工具的地方就用传统工具。

4.3 图片生成：提示词工程和工作流的配合

图片生成场景里，工作流的价值在于把模糊需求翻译成精确提示词。

用户给的原始需求往往很模糊，比如"要一张科技感的配图"。直接丢给图片模型，出来的东西全凭运气。我的工作流是这样：

1. 需求解析节点：把模糊需求拆成"主体""风格""色调""构图"四个维度
2. 提示词生成节点：每个维度生成具体的描述词，比如"主体：一台笔记本电脑""风格：极简科技风""色调：蓝紫渐变""构图：居中对称"
3. 提示词组装节点：按图片模型要求的格式组装成完整提示词
4. 生成与筛选节点：生成多张，按预设标准筛选

这里的关键是把主观需求结构化。结构化之后，每次生成的图风格就稳定了，不会这次冷色调下次暖色调。

参数上，我一般生成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用在它擅长的地方，把规则用在规则擅长的地方，整体效果最好，成本最低。

第三，工作流的价值在于"可交付"。一个工作流如果只有你自己能跑，那它的价值有限。能交给别人跑、能稳定复现、能应对异常，才真正有价值。这也是我判断一个工作流好不好的核心标准。

第四，别追求一步到位。我见过太多人想搭一个"完美工作流"，结果卡在第一步迟迟不动。正确的做法是先搭一个能跑通的最小版本，然后在使用中不断迭代。我的很多工作流都是从一个粗糙的版本开始，跑了几个月才慢慢打磨成现在这样。

第五，记录比记忆重要。工作流里的每个参数、每个提示词、每次改动，都值得记下来。因为过一段时间你肯定会忘，忘了就得重新试，重新试就得重新踩坑。养成记录的习惯，能省下大量重复劳动。

这套方法论我还在持续打磨，每次遇到新场景都会有新体会。但核心思路是稳定的：拆解任务、明确职责、结构化传递、加校验、留后路。把这几点做到位，大部分场景的工作流都能搭得又稳又好用。