企业官网建设流程全解析

朋友找我帮忙看一个项目，标题叫“ai-engineering-from-scratch”。乍一看像是仓库名，再一看实际上是个很典型的工程实践命题：从零开始把AI能力做成一个真正能跑、能迭代、能交付的系统。很多人会误以为这事就是调个API、套个Prompt，实际上真正落地的时候涉及的东西远比想象中多。这篇文章我就用自己踩过一遍坑之后的思路，把一条完整的“从零到一”AI工程项目路径拆开给你看。无论你是个人开发者、正打算转型做AI应用的技术人，还是团队里负责技术选型的同学，这里面的东西应该都能帮你少走一些弯路。

先说实话，我见过太多项目死在了第一步：根本没有想清楚“AI工程”和“写段调用模型代码”的区别。如果你只是想要一个能回答问题的窗口，那确实不用往下看。但如果你要做的是能接入业务、能处理真实数据、能在出问题的时候被排查、能持续演进的系统，那你需要的是完整的工程思维。

1. 先搞清楚：从零开始AI工程的边界

1.1 “从零”不等于“从造发动机开始”

很多第一次接触AI工程的人，看到“from scratch”这个词就紧张，以为要从数学推导、手写反向传播开始。但实际上，在2025年的工程语境里，AI工程的“从零”指的是：从一个空目录开始，用现有的模型能力、开发框架、开源工具，搭出一套属于你自己的AI应用系统。这有点像盖房子——你不会从烧砖开始，但你得从平整土地、画图纸、打地基开始。

我理解“from scratch”包含的其实是三个阶段：第一阶段是“零基础理解”，也就是你能清楚说出AI系统里每个环节为什么存在；第二阶段是“零依赖搭建”，所有核心逻辑都自己掌控，不盲目信任某个黑盒平台；第三阶段是“零经验落地”，也就是你已经具备把想法变成可运行demo并逐步完善的能力。

换句话说，AI工程不是一门“调参艺术”，而是一门“系统科学”。它关心的是：输入什么数据、模型如何被调用、Prompt如何被管理、输出如何被校验、失败如何被恢复、整个链路如何被观察和度量。这跟写一个普通的Web服务不一样，因为引入了不可完全确定性的模型推理，你的错误处理、边界控制、结果验证都要比传统软件多一个维度。

1.2 AI工程的五层体系

我自己在梳理AI工程时，一直沿用一套五层结构，每次跟团队对齐都用它，效果很好。有了这套结构，你再看任何AI项目，都能快速定位它卡在哪一层。

第一层是数据层。包括数据采集、清洗、切分、向量化、存储。不要觉得只有做大模型训练才需要数据工程，即使是做RAG问答，数据做不好，后面全白搭。

第二层是模型层。这里要决策是用商用API还是开源模型，要不要微调，需不需要本地部署，用什么推理框架。这一层相对容易被高估，其实很多项目根本不用微调。

第三层是提示词与上下文管理层，也就是大家常说的Prompt Engineering。这个层级的职责包括：把任务描述清楚，把格式化输出约束住，把上下文窗口管理好，把系统提示词和人设稳定住。

第四层是Agent与应用编排层。也就是让模型能调用工具、能访问外部系统、能按计划执行多步任务。这里涉及的框架有LangChain、LlamaIndex、自家写的状态机等等，选择很多，但核心是控制流。

第五层是评估、监控与运维层。这是最容易被新手忽略、却决定项目能否长期存活的层。你需要有一套评测集来判断模型改Prompt之后是变好还是变坏了，你还需要记录每次调用的输入输出、token用量、延迟、错误率，这样才能在线上问题出现时快速定位。

记住，这五层缺一不可。缺了数据层，你的模型再聪明也没有依据；缺了评估层，你的项目就是开盲盒。

2. 选型与架构：开工前的第一场硬仗

2.1 先拆需求，再选模型

我在做项目规划时，第一步永远不是打开ChatGPT页面或者下载模型权重，而是先写一份需求拆解文档。这个文档不需要很长，但必须回答几个问题：用户是谁？输入是什么？输出需要什么样的结构？允许的延迟是多少？数据敏感程度如何？容错率多高？

举个例子，你想要做一个“行业问答机器人”。这个需求看起来简单，但拆开之后会发现很多变体：是面向C端用户的闲聊型问答，还是面向企业内部员工的文档检索型问答？用户提问时是否可能涉及多轮上下文？答案是需要引用原文出处，还是只需要一段自由生成的结果？如果模型给错了答案，后果有多严重？

这些问题直接决定了后续的技术选型。闲聊型问答可以靠一个通用大模型API加系统提示词解决，但文档检索型问答大概率需要RAG架构，要引入向量数据库、文本切分、召回排序一整套流程。如果你不做需求拆解就直接选型，很可能做出一个“听起来很酷但根本没法用”的东西。

2.2 API、开源模型、本地推理怎么权衡

选型的第二个关键决策是：你的模型能力从哪里来。目前市面上有两条主流路径：调用云端大模型API，或者部署开源模型到自己的服务器。综合考虑成本、隐私、定制自由度、运维复杂度和效果，具体对比可以看这张表。

我的经验是：对于初创项目、快速验证行为的场景，先无脑用商用API，让业务逻辑跑通最重要。当项目有了一定规模的用户和收入，或者数据合规要求变得敏感，再考虑迁移到开源模型。不要一上来就自建推理集群，那是给自己找罪受。

如果你确实需要本地部署，也有个折中方案：先用Ollama这类工具把模型跑起来，再通过OpenAI兼容接口接入你的应用层代码。这样你在应用层写的代码从第一天起就不依赖具体厂商，后面想换模型很轻松。

2.3 Prompt工程和Agent框架怎么选

Prompt工程这个说法很容易让人误会，好像只是写几句提示词而已。实际上，一个成熟项目的Prompt管理应该纳入版本控制，要有模板系统，要支持不同场景下的动态拼装。我建议不要直接把Prompt写死在业务代码里，而是单独维护一个配置文件，或者用专门的Prompt管理工具把系统提示词、用户前缀、示例样本、输出格式三段分开。

至于Agent框架，我的忠告是：不要为了用框架而用框架。LangChain确实火，但很多简单需求用代码手写一个带if-else的Agent循环就够了。你只需要定义一个工具列表、一个模型调用函数、一个解析模型输出的函数，再加上一个循环判断是否需要继续调用工具。这套手写的控制流也许看起来土，但它可读性强、调试方便、没有版本升级带来的破坏性变更。

只有当你的任务确实涉及复杂路由、多工具协作、动态规划、记忆管理等需求时，才值得考虑引入成熟的Agent框架。请一定记住：框架解决的是通用问题，你的项目解决的是特定问题，中间必然存在适配成本。

3. 实操案例：从零构建一个带记忆的行业问答Agent

3.1 场景定位与数据准备

为了讲清楚整套流程，我拿一个最近做过的项目举例：帮一家做企业资质服务的公司搭一个“政策咨询Agent”。用户会问“我们公司想申请高新技术企业认定，需要哪些材料？”“研发费用占比要求是多少？”“去年有一项知识产权不满足条件怎么办？”这类问题。

这个场景有几个特点：第一，答案不能瞎编，必须对应具体政策条文；第二，不同年份、不同地区政策不一样；第三，用户会提供公司自身信息，Agent需要记住这些信息并在多轮对话中使用。所以一个裸的通用模型完全不够，必须做知识库检索加上对话记忆。

数据准备阶段的工作量远超预期。我先从客户那里拿了一批政策文件PDF和Word，第一步是清洗格式：去掉页眉页脚、处理全角半角、统一表格样式。然后做段落切分，不能让一个超长条款占满整个向量库片段，也不能把一个问题切成两半。经过测试，按三级标题和条款编号进行切分，平均每个片段控制在200～500字，效果最好。

之后我把每个片段喂给一个Embedding模型，生成向量存入向量数据库。这里我用了轻量级的开源Embedding方案，不需要很大模型，几百MB的模型在CPU上都能跑，速度可以接受。切分时还有一个细节：相邻片段之间保留少量重叠文字（大概50字左右），防止检索时因为边界跳过关键信息。

3.2 Prompt设计与上下文压缩

这个项目的Prompt我改了很多版。最初版的系统提示词只写了“你是一位资深政策咨询顾问”，结果模型回答得倒是流畅，但经常自由发挥，把一些不存在的要求说得头头是道。

后来我改成“你只能根据给定资料回答，如果资料中没有明确依据，必须回复‘资料中未找到相关内容’”。并且给Prompt加了检索结果引用格式：每个回答至少要标注引用了哪一份文件的哪个条款。这样做以后，模型的“幻觉”明显减少，而且用户能看到出处，信任度也高很多。

关于上下文管理，你的第一直觉可能是“把用户多轮对话全部塞进提示词”，但这样很快会撞到上下文窗口和成本限制。我的做法是：每一轮对话结束后，用一个轻量级模型或规则对历史对话做摘要，把关键信息（比如公司名称、行业、人员规模、已具备的知识产权数量）抽出来，放进一个结构化的“记忆字段”。下一轮生成时，只把摘要和最近的3轮对话传给模型。

举个例子，用户第一轮说“我们是一家软件公司，有120人，研发人员45个”，这些数据不在资料库里，但对后续回答有用。我把它存进记忆字段之后，第二轮他问“我们符合小微企业的标准吗”，模型就能结合记忆里的“120人”和召回的政策文本给出判断。这个功能用LangChain的Memory也能做，但手写更灵活。

3.3 Agent编排与工具调用

问答型Agent的流程可以简化成三件事：检索相关资料、分析用户问题、组织回答。但真实的业务中，还需要Agent具备主动追问和基于时间条件做分支判断的能力。

比如用户问“今年高企申报什么时候截止”，资料库里只有各地方的通知，没有统一的截止日期。这时候只靠向量检索并不足够，因为不同的政策文件时间不一样。我把“查询当前日期”和“查询政策数据库”分别封装成两个工具，让Agent决定先调用哪个。为此我写了一个很小的控制循环：第一轮调用工具，把工具结果塞回上下文，第二轮让模型综合回答。如果你把两轮调用合并成一步，模型就更容易胡编时间。

另一个实用的设计是“澄清机制”。模型判断用户问题模糊时，不直接回答，而是生成一个反问句：“请问您申报的是哪个省份的高企认定？”我把这个行为定义成Prompt里的一个分支指令，并给出一个结构化输出：要么是answer字段，要么是clarify_question字段。业务代码根据字段值决定直接展示答案还是继续追问。这是最简单的Agent决策逻辑，但非常有效。

3.4 评估指标与回归测试

项目上线前，我们建立了一套评估集，包含50个真实用户问题和对应的正确答案等级。这里的正确答案不要求逐字一致，而是标记为三类：完整正确、部分正确、错误。每次调整Prompt或换模型版本时，我都会跑一遍这套评估集，计算“完整正确率”和“部分及以上正确率”。

不到一周我就发现，改Prompt经常是“东边日出西边雨”：某几个问题的回答质量大幅提升，另几个却意外变差。所以光看平均值不够，我还会按业务模块分组看结果。比如“申报条件类问题”和“政策时间类问题”分开统计，这样能更清晰定位哪部分退化了。

我还加了一个“拒答正确率”指标：当问题明显超出知识库范围时，模型应该明确说不知道，而不是硬答。这个指标和“幻觉率”紧密相关，宁可多拒绝，也不要乱回答。没有这套评估，你根本无法进行科学的Prompt迭代，基本就是瞎试。

4. 常见问题与排坑技巧

4.1 模型“胡说八道”的根治办法

大模型幻觉是绕不开的问题。我常用的手段有哪些？首先是强约束输出格式，要求模型在给出答案时附带引用编号，并且编号必须对应到输入的“资料列表”。如果模型生成了一个不存在的编号，业务代码就要拦截掉重新请求。

其次是用“二次校验”。对于高风险回答（比如涉及金额、期限、资质要求的问题），我让模型先生成一个待定答案，然后把这个答案连同原始资料一起去问另一个模型：“请判断以下回答是否完全基于给定资料，若存在超出资料内容的信息，请指出。”等于让一个“评审”模型去审计“回答”模型。这个方法会多一倍token开销，但准确率提升非常明显。

4.2 Token开销失控与控制

我第一次做Agent时，控制流写得太随意，一次问题来回调用七八次模型，单次成本飙升十倍。后来我给工具调用设置了“最大迭代次数”，默认3次，超过就不再执行下一次调用，让模型基于已有信息直接作答。同时对于Agent的中间结果，不全部塞回上下文，而是只保留工具输出的摘要。

还有一个容易忽略的坑：系统提示词和示例也会按token计费。如果你每个请求都带超长示例，并发一高，成本很快就刹不住。建议把常见示例做成一个单独的“示例库”，按分类动态注入，而不是每次把所有示例都带上。

4.3 多AI协作的同步与信任

“多AI协作”是最近很火的方向，但我的体验是别轻易上，因为它带来了一个新的工程问题：Agent之间如何建立信任。如果你的主Agent调用了另一个子Agent，你得考虑子Agent返回的结果是否可靠、格式是否正确、是否可能陷入死循环。

建议采用“白板模式”：多个Agent之间的通信不靠自然语言对话，而是统一写到一个结构化的状态文件里。比如主Agent决定调用工具时，往状态文件里写入工具名、入参和状态；工具执行完，往状态文件里写入结果字段。这样你随时可以检查每条链路的输入输出，重放问题、定位bug都容易得多。如果让Agent自由对话，你会陷入“两个模型尬聊到死循环”的窘境。

4.4 从demo到生产的8个细节

很多项目demo跑通了，一上生产就崩。我列几个最容易翻车的地方：第一，没有设置超时和重试，模型接口偶尔会慢，必须给请求设置超时时间并建立指数退避重试机制；第二，没有做并发控制，一压测就把模型服务打满了；第三，没有日志追踪，线上问题无从查起；第四，没有数据版本管理，向量库里的资料更新了你都不知道；第五，Prompt和代码没有一起做版本管理，导致历史行为无法复现；第六，没有做安全和合规检查，用户输入可能带恶意注入；第七，没有做内容审核，模型输出可能涉及违规内容；第八，没有做成本监控，没有预警阈值。

这八点看着琐碎，但任何一个都能让项目在关键时刻崩掉。具体踩得多了你就知道，AI工程里所谓的“工程”，往往就体现在这些细节上。

5. 最后说点个人体会

做“ai-engineering-from-scratch”这类项目，我最深的体会是：技术选型真的不是最难的环节，最难的是建立一套“反馈闭环”。从数据准备、Prompt调整、Agent逻辑设计到评估指标，每一环都需要你能够快速知道“刚才那个改动到底有没有效果”。

还有一个小建议：把AI项目当成一个持续演进的产品，而不是一次性的交付物。你上线第一个版本只解决60%的问题，没关系，重点是你要有一套机制不断发现剩余40%的问题，并且能低成本地把它们一个个修好。拿政策咨询Agent来说，我每周都会看用户提问记录，把那些模型答错的、拒答不该拒的、还有被用户反复追问的问题整理成新的测试用例，塞进评估集。这样迭代到第三周，整个系统的稳定性就肉眼可见地提升了。

这个项目做完之后，我明显感觉到AI工程已经不像一两年那样充满魔法感了。它越来越像一个常规软件工程，只是它的核心组件有一定不确定性。你只要把这种不确定性关进一个结构化的笼子里——用评测、校验、监控去管理它，它就会慢慢变得可靠。希望这篇东西能帮你把从零到一的路走得更顺一点。