企业官网建设流程全解析

前段时间总有朋友拿着一张网上的AI课程表来问我：这个路线图靠谱吗？我看了一眼，Prompt工程、RAG、Agent、微调……列得倒是齐全，但仔细一看，全是“用某某平台做某某功能”的操作步骤，一个问题都没解答：这些东西到底是怎么组合成一个能稳定交付的系统的？这也就是我今天想写的主题——ai-engineering-from-scratch。我不是来给你背课程大纲的，我想聊的是从零开始搭建AI工程能力时，真正决定成败的几个关卡，以及我实际动手做项目时踩过、也填平过的那些坑。如果你正准备在业务里落地AI，或者想让自己的AI技能从“能聊天”升级到“能交付”，这篇内容应该能让你少走不少弯路。

1. 先想清楚一个问题：你搞的是“AI调用”，还是“AI工程”

很多人的第一个AI项目，是拿着一个大模型API，写一个能让用户提问、模型回答的页面。这当然算接触了AI，但它顶多算“接口调用”，离“工程”还有一段距离。我见过不少人卡在这一步，觉得自己学了半年怎么还在原地踏步，原因只有一个：没有建立工程视角。

1.1 一个撕开差距的真实案例

2024年我帮朋友做过一个小项目：提取客户发的邮件里的订单信息，写入他们的ERP系统。最开始我们用最“快乐”的方法——把邮件全文塞给大模型，提示词里写“把订单号、金额、客户名提取出来”，然后解析返回的JSON。结果头两个星期，我们都在干同一件事：调提示词。

今天发现模型把“金额”识别成了“含税金额”，明天发现地址里有公寓号就多出个字段，后天又发现退货邮件也被当作订单。每次修完都觉得“这次应该行了”，每次都被新的边缘情况打脸。后来我把这套流程彻底重构，只做了一件事：把任务拆成“判断是否为有效订单→提取结构化字段→按规则校验→异常人工介入”四步，每一步有独立的提示词、独立的校验逻辑、独立的失败策略。从那以后，项目才真正稳定下来。

这件事给我的教训很深刻，AI工程的核心不是让模型“更聪明”，而是让系统在模型没那么聪明的时候也能兜得住。

1.2 “AI工程”和“AI调用”到底差在哪

简单来说，调用是问一次拿一次结果，工程是把很多次调用组织起来，做成一个可靠、可维护、可度量的流程。两者之间的差别也很大：

这也是为什么很多人在网上抄了“高质量提示词”，放到自己业务里照样翻车。因为提示词只是工程里最小的一环，系统设计、流程编排、校验兜底才是真正决定成败的东西。

1.3 为什么“抄提示词”永远学不会AI工程

我见过一位朋友，花了大量时间收集各种提示词模板，什么“律师式提示词”“CEO式提示词”“Step-by-Step万能公式”，攒了满满一个笔记库。但他做一个实际的报销单识别工具时，还是被字段错乱、格式不统一折磨得够呛。

真相是：提示词工具是人类思维方式的载体，不是咒语。同样是要求模型输出JSON，如果你的上游数据既有PDF又有图片、既有中文发票又有英文收据，你得先处理格式统一和内容抽取，而不是指望一句“请以JSON输出”解决所有问题。AI工程是把整个链路当成一个流水线来设计，每个环节解决一个问题，每类异常都有处理预案。

2. 提示词工程：把需求翻译成模型能执行的“工程说明书”

很多人觉得提示词工程就是“会说话的艺术”，但站在工程角度，它更像是写需求文档：目标清晰、边界明确、验收有标准。好的提示词不是让模型“发挥”，而是让模型在限定范围内“执行”。

2.1 一个好用的结构化提示词框架

我平时写生产级提示词，基本都会包含五块：角色、任务目标、输入输出格式、约束条件、示例。以一个“从微信聊天记录里提取客户跟进状态”的任务为例，提示词会是这样：

角色：你是一位客户运营助理，擅长从销售聊天记录中提取关键状态信息。 任务目标：根据提供的聊天记录片段，提取以下字段： - customer_attitude：客户态度（积极/中性/消极） - next_action：客户或销售明确约定的下一步动作 - concern：客户提到的主要顾虑（若没有则填“无”） 输出格式：仅输出JSON，形如： {"customer_attitude":"积极","next_action":"下周三发送报价单","concern":"对交付周期有疑虑"} 约束条件： - 只依据聊天记录中的原文判断，禁止脑补。 - 若字段信息不存在，使用空字符串或“无”。 - 若聊天记录不属于客户沟通场景，输出{"valid":false}。 聊天记录： {这里放原始文本}

这个框架看起来平淡无奇，但工程上非常有用。角色设定减少风格漂移；任务目标决定了提取哪些字段；输出格式让下游程序能直接解析；约束条件把边界问题挡在源头；示例则起到“锚定”作用，让模型知道你想要的JSON长什么样。这五个部分，缺哪个都会在特定场景里出问题——我有一次偷懒没写约束条件，模型居然把“希望尽快收到货”脑补成了“已投诉物流”，差点让运营同事直接打电话去道歉。

2.2 上下文管理和Token预算：工程化必过的第一关

生产环境里，你不可能永远只把“一小段文本”塞进模型。真实情况往往是：客户历史记录、商品信息、物流状态、聊天记录全要作为上下文。这时候，Token预算就成了硬约束。

我自己的实践是给上下文分档：优先放系统级指令，然后是当前任务输入，最后才是历史信息。历史信息再按时间衰减和相关性过滤，只保留最近几条或命中关键词的片段，而不是把全部文本一股脑塞进去。这块有两个实操经验：

• 用Tokenizer先估算长度。OpenAI和各家模型都提供了Tokenizer工具，先估算输入Token，再设定预分配的上限，比如上限8000 Token时，系统指令给1000，当前输入给5000，历史信息压缩在2000以内。
• 超长内容分批处理。真正长的内容（比如整本手册、几十页聊天记录），先做章节切分，再逐段提取摘要，最后合并摘要。直接全文硬塞，成本暴涨不说，模型对中间内容的注意力往往也是衰减的。

2.3 提示词也要版本管理

这个习惯可能很多人没有，但在生产项目里极其重要。我见过最痛的一次事故：运营同事为了“让模型更详细一点”，直接在后台把提示词改了一句，结果当天的客服智能质检全都跑偏，报表数据乱成一团。原因很简单——没有人追踪提示词什么时候被改过、被谁改过、为什么改。

从那以后，我把所有提示词都当成代码来管：放进Git仓库，每次修改走评审，发布时打版本号。提示词文件和对应的评测用例放同一个目录，哪个版本配哪份用例一目了然。这个习惯救了我好几次，尤其当模型厂商升级底层模型之后，同样的提示词表现可能完全不一样，能快速回滚到上一版就格外重要了。

2.4 几种常见的“答非所问”，其实是提示词设计问题

模型答非所问，很多人第一反应是“模型不行”，但排查下来经常是提示词设计有漏洞：

• 任务目标模糊。比如“分析这段话”，模型不知道你要的是情感倾向、主题分类还是行动建议，自然只能给你一段泛泛而谈。
• 缺乏约束条件。模型会默认补充它觉得合理的信息，导致输出带上了“脑补内容”。
• 输出格式与下游不匹配。有的模型对JSON格式理解得好，有的模型更容易输出带注释的代码块，都要在评测环节确认清楚。
• 示例太少或太偏。一个示例能帮模型定调，但如果示例场景和实际输入差异太大，反而会把模型带偏。

这些问题的共同根源是：提示词没有把“验收标准”讲清楚。工程化提示词的闭环，不是写出来、测一次、部署上线，而是持续根据失败样本更新约束和示例，每一次线上翻车都是提示词迭代的养料。

3. Agent：从“一问一答”到“多步任务闭环”

如果说提示词工程是地基，那Agent就是在这块地基上盖出来的房子。单次调用只能完成一个动作，但真实业务几乎都是多步骤任务：查资料、做判断、调工具、校验结果、产出报告。这就是为什么要引入Agent。

3.1 为什么单次调用搞不定真实业务

拿我们做的“自动竞品情报站”为例。用户输入“帮我看看最近一周xx赛道有什么值得关注的产品动态”，如果只调一次大模型，它要么凭训练数据里的旧信息瞎编，要么只能给出毫无依据的泛泛而谈。真实解决方案必须做几步：先去资讯源抓取内容、过滤和本文相关的关键词、逐篇提取要点、合并相似事件、最后生成一份周报。每一步都是独立的调用，这些步骤之间还有先后依赖。

单次调用是一个点，Agent是把这个点串成一条线的编排器。这也是为什么聊Agent工作时，业内有人会提到“harness engineering（驾驭工程）”——重点是怎么把模型的能力“装进”一个可控的执行框架里，而不是让模型自由发挥。

3.2 Agent的骨架：规划器、工具集、记忆、执行器

我习惯用一个生活化的类比来解释Agent结构：它就像一个由项目经理带领的实习生小组。

• 规划器：项目经理，负责把大目标拆成小任务，决定先干什么、后干什么。
• 工具集：实习生手里的工具箱，比如搜索引擎、数据库查询、文件读写、API调用。
• 记忆：项目组的白板和资料架，用来记录已经做了什么、查到了什么、下一步要做什么。
• 执行器：真正调用模型、解析结果、决定下一步循环的“手脚”。

理论上你可以用LangChain这类框架快速搭一套Agent，但我实践下来建议：一开始别急着上框架，先用简单的代码把“规划→执行→检查→重试”这个循环跑通，理解每一步的数据长什么样，再决定要不要引框架。否则框架的抽象会把问题藏起来，调试的时候你会非常痛苦。

3.3 工具调用的工程细节：格式契约、错误恢复、防循环

Agent必然要调用工具，而工具调用是工程坑的重灾区。我在项目里遇到过三个特别典型的问题：

第一，格式契约不一致。模型返回的“工具调用参数”很可能是JSON字符串，但如果模型多了一个换行、一个尾逗号，或者把参数名改了，程序直接崩掉。我现在的做法是，在提示词里给定严格的JSON Schema，同时调用后马上做一次“参数修正”，解析失败就触发一次retry，并附带错误信息让模型重新生成。

第二，错误恢复。工具调用失败（比如搜索接口超时、数据库连接断开），Agent不能干等着，必须有降级策略：重试一次，换另一个工具试一次，再不行就向用户说明“这一步没取到数据，以下内容基于已有信息生成”。这个逻辑写起来不难，但很多初版Agent完全没有，一遇到小故障就整个任务失败。

第三，防循环。模型在Agent里很容易陷入“反复调用工具就是不产出结果”的循环，每次调用还要花Token，成本肉眼可见地涨。我通常会设置两个硬性保险：最大迭代次数（比如10步），以及单任务Token上限。超过阈值直接终止，输出当前已获得的中间结果并提示人工接手。

工具调用的JSON Schema示例大致长这样：

{ "name": "search_web", "description": "搜索互联网并返回与关键词相关的新闻标题、链接和摘要", "parameters": { "type": "object", "properties": { "query": {"type": "string", "description": "搜索关键词，尽量精确"}, "time_range": {"type": "string", "enum": ["1d", "7d", "1m"]} }, "required": ["query"] } }

这段Schema本身就是一种“和模型签订的契约”，定义得越严格，模型越不容易跑偏。

3.4 多AI协作的两种模式：串行流水线与并行会诊

有人工智能项目往往会走到“多模型配合”这一步。我常用的有两种模式：串行流水线和并行会诊。串行流水线适用于任务有明显先后关系，比如“信息抽取→摘要生成→报告改写”，每一步交给不同的模型或同一模型的不同角色提示词。并行会诊则适用于需要多角度判断的场景，比如让两个模型分别做“风险识别”和“机会识别”，再把结果合并给第三个模型做冲突消解和总结。

这个思路来源于一个很朴素的直觉：一只模型处理所有事，就像一个人既当客服又当财务又当产品经理，角色切换越多越容易乱。反而是“专人专事”的结构，每个环节可控、可测、可替换，整体稳定性高很多。

4. 工程化的四块硬骨头：评测、成本、可观测性、模型路由

AI项目能不能长期运行，拼的不是Demo效果，而是这四个问题有没有认真解决。

4.1 评测集：没有黄金标准，所有优化都是自我感动

这是我踩过最大的坑之一。早期做一个文本分类工具，每次改完提示词都觉得“效果变好了”，但拿给同事看，人家问“好在哪？你拿多少测试样本做过统计？”我当时一句话答不上来。后来老老实实建了一个评测集，从那以后，AI工程才算真正有了“方向盘”。

评测集不用一开始就做得很大。我的经验是：第一批人工标注50到100条代表性样本就够了，覆盖正常情况、边界情况和典型错误情况。每条样本包含输入、期望输出、可选的关键理由。每次迭代提示词或改流程，都在这个固定集上跑一遍，算准确率、看失败案例分布，再决定改哪里。

为了不让评测变成“跑一次记个数”，我还做了一个极简的回归脚本，大致逻辑是：

for case in eval_set: result = run_agent(case.input) if normalize(result.output) != normalize(case.expected): failures.append({case, result}) report = {"pass_rate": pass_rate, "failures": failures}

这个脚本现在是我所有AI项目的“守门员”，改动之前跑一遍，心里有底。

4.2 成本和延迟的权衡：大模型不是唯一解药

很多AI项目从Demo走向生产时，第一个撞上的南墙是账单。用最强模型跑所有任务，效果是没话说，但成本让老板心疼。

我一般会先给任务分个级：简单任务（如判断、分类、抽取）用小参数模型就足够；复杂任务（如长文总结、多步推理）才用大模型。举个例子，一个智能客服项目里，80%的简单问答走快速模型，响应延迟大概1秒，单次成本几乎可以忽略；剩下20%的复杂问题才走大模型，成本高但只占总调用量的小头。整体算下来，成本比全都用大模型下降了60%以上，而用户可感知的回答质量几乎没有区别。

这里还有一个小技巧：把大模型的输出缓存起来。对于相同或高度相似的问题，先查缓存，命中就直接返回，既不花钱又只有几毫秒延迟。缓存命中率在工作流固定的项目里往往能到30%以上。

4.3 可观测性：给Agent加“行车记录仪”

Agent是多步运行的系统，一旦结果不对，你很难一眼看出是规划错了、工具调用错了还是模型理解错了。我的经验是：从第一天就给Agent加上“过程日志”，核心是把每一步的以下信息记录下来：

• 当前步骤名称
• 模型输入摘要（提示词前300字）
• 模型输出全文
• 工具调用参数和返回结果
• 各步骤耗时和Token消耗
• 最终结果和人工标注的满意度

这些信息合在一起就像一个行车记录仪，出了问题可以回放整个过程，定位到底哪一环跑了偏。有一回我们的竞品情报Agent生成了一份离谱报告，我打开日志一看，发现是搜索工具返回了乱码内容，模型没有识别出来，直接基于乱码做了总结。没有日志的话，光看结果根本猜不到这个原因。

4.4 模型路由：让简单任务用便宜模型，复杂任务用强模型

模型路由听起来高级，落地其实就是一个前置判断逻辑：评估当前请求的复杂度，再决定用哪个模型。

比如我常用两步判断法：先用一个极快的模型给请求打标签——这是“简单问答”“信息抽取”还是“复杂分析”；然后根据标签路由到大模型或小模型。也可以让用户主动选择“快速模式”和“深度模式”。这套逻辑的本质是：不把昂贵算力浪费在简单请求上，也不让复杂问题被弱模型糊弄过去。路由层本身不复杂，但它对成本控制和响应速度的影响，比优化十个提示词都明显。

5. 从零到一完整走一遍：做一个自动竞品情报站

前面讲了不少方法论，可能有点干，我用一个完整的、我实际做过的项目把它们串起来，你就能看到每一块是怎么咬合在一起的。

5.1 需求拆解：一个“高大上”目标，拆成五个可执行子任务

最开始的需求只有一句话：“我要一个自动追踪竞品动态的机器人。”这句话没法直接写提示词。我把它拆成五个环节：

1. 采集：从指定资讯源抓取文章标题和链接。
2. 过滤：判断文章是否和关注的竞品或赛道相关。
3. 要点提取：从相关文章中提取产品动态、融资、人事、战略等事件。
4. 汇总去重：将跨文章重复信息合并成事件条目。
5. 周报生成：把事件按主题整理成一份带摘要的周报。

每一个环节都是独立的模块，有独立的输入输出定义，也有独立的失败兜底。拆完之后，“做一个竞品情报站”就变成了“实现五个小函数”，难度瞬间下降了一个量级。

5.2 提示词与工具实现：可参考的最小模板

以“过滤”环节为例，提示词我写成了这样：

任务：判断以下文章是否与“智能客服”赛道相关。 判断标准：文章主体涉及客服机器人、自动应答、大模型客服应用、客服SaaS产品，视为相关； 仅泛泛提到“AI”或“客服”但不作为核心内容，视为不相关。 输出JSON：{"related": true/false, "reason": "一句话说明判断依据"} 文章标题：{title} 文章摘要：{summary}

配合这个提示词，采集模块做好RSS抓取，过滤模块调用模型做判断，之后要点提取和汇总去重各自独立。整条链路没有用Agent框架，就是一段Python脚本把各步骤串起来。生产环境里，“轻量编排+少量模型调用”往往比“重框架+自由Agent”更稳定、更好维护。

5.3 组装与联调：最容易被忽视的“人机协作边界”

很多人做自动化项目会陷入一个执念：希望全链路无人参与，一步到位。但现实是AI工程里最稳的设计，是明确“哪些步骤必须有人审批/修正”。在我的情报站里，采集、过滤、提取是全自动的；汇总去重之后，会生成一份“待人工确认”清单，运营同事可以勾选、修改、删除事件后再生成最终周报。这个设计让自动化负责“把80%的重复劳动干掉”，而人只需要在关键节点把关。结果就是项目既高效又可信，大家也愿意接受AI的输出。

5.4 上线后的数据与收益

这个项目上线三个月后，我拉过一次数据。每周平均采集文章400多篇，过滤后保留大约40篇相关材料，提取出20个左右的事件条目，最终人工修正的时间从原来的每周3小时缩到40分钟。Token成本折算下来大约每周30元人民币左右，这个数字在当时让我挺意外——工程的收益不只是“效果变好”，更是成本可控、过程可查、结果可预期。

6. 关于AI工程，最后想说的几句实在话

走到这一步，你已经知道AI工程不是某个模型、某条提示词、某个框架能定义的。它是一个系统，是由任务拆解、流程编排、评测反馈、成本控制和异常兜底共同构成的系统。这也是为什么我一直强调“from scratch”——从零搭建的价值，在于你必须亲手理解每个环节为什么这么设计，而不是拿一套现成方案直接套用。

我现在的日常工作里，仍有不少时间花在“看失败样本”上。模型每答错一次，评测集就多一条用例，提示词就多一条约束。这个循环给了我一种非常踏实的感觉：AI项目的质量不是靠“最强模型”保出来的，是靠一次次针对失败样本的迭代修出来的。无论你从哪个领域开始进入AI工程，这个迭代习惯都是最值得尽早建立的能力。

如果你也想从零开始搞一个AI项目，我的建议很直白：挑一个自己每天都在做的重复性任务，拆成步骤，搭一条最简单的自动化链路，然后建评测集、记日志、看失败案例。不用等到“准备好”才开始，先用最小闭环跑起来，然后在一个月内不断修补它。你会发现，所谓AI工程能力，并不是某个顿悟时刻，而是这一个月里每一次修补积累出来的手感。