企业官网建设流程全解析

AI 工程项目的 5 个进阶等级：从“能跑的 Demo”到“可在生产环境稳定运行的系统”
翻译整理自：https://medium.com/data-science-collective/why-your-ai-engineering-projects-wont-land-you-a-job-84de0c913951

开场：差距不只在模型，而在工程成熟度

一个周末做出的聊天机器人，与 Claude、Codex 背后的大型系统，看起来像是两个完全不同的世界。实际上，两者之间存在一条相对清晰的工程进阶路径。

许多初学项目停留在“调用大模型 API、加一个简单界面、能够现场演示”的阶段。这样的项目可以证明基本开发能力，却很难证明系统能够稳定解决真实问题。企业真正关心的通常不是界面是否炫酷，而是答案是否可靠、错误是否可定位、成本是否可控制、权限是否安全，以及系统能否长期运行。

这套框架把 AI 工程项目划分为五个等级。它并非行业统一认证标准，而是一种便于理解工程成熟度的经验性分类，适合用于判断项目当前处于什么阶段，以及下一步需要补齐哪些能力。

等级 1：基础应用——大模型 API 加一个简单界面

等级 1 的项目通常包括三部分：

1. 调用 OpenAI、Anthropic 等大模型 API；
2. 编写一组提示词；
3. 使用 Streamlit 等工具搭建简单界面。

常见案例包括客服问答机器人、文章摘要工具、文案生成器、饮食计划助手等。部分项目还会加入结构化输出、格式解析测试，以及模型调用失败时的兜底逻辑。

从表面看，这类项目已经能够完成一项具体任务。但它们往往只能在理想输入下正常工作，也就是“顺利时能用”。

核心问题一：提示词没有被系统化管理

提示词被修改之后，如果没有版本记录和测试集，就无法判断新版本到底更好还是更差。某一次回答更流畅，并不代表整体质量得到提升。

核心问题二：没有明确的质量指标

“感觉不错”不是工程指标。客服机器人是否回答正确、摘要是否遗漏关键信息、生成内容是否符合业务要求，都需要可重复的评价方法。

核心问题三：缺少组织内部语境

通用模型主要依赖训练数据和公开信息。公司制度、产品文档、历史案例、客户规则等私有知识并不会自动进入模型上下文，因此回答很容易停留在通用层面。

适合的练习方式

起步阶段适合围绕真实生活问题完成一个小项目，例如饮食计划助手。重点不是堆叠复杂功能，而是先理解模型 API、提示词、前端界面和基本异常处理如何连接起来。

不过，仅完成等级 1 通常还不足以形成有竞争力的求职作品。下一步需要让系统能够访问私有资料，并且证明回答质量可以被评估。

等级 2：知识增强——RAG 与系统化评估

等级 2 的关键词是RAG（Retrieval-Augmented Generation，检索增强生成）。

RAG 可以理解为“先查资料，再回答问题”。系统收到问题后，不会只依靠模型原有知识，而是先从内部文档中找到相关内容，再把这些内容连同问题一起交给模型生成答案。

RAG 为什么有用

当系统需要回答公司制度、项目资料、产品手册、个人记录等私有信息时，RAG 能够补充模型从未见过的上下文。例如，饮食计划助手可以接入个人营养日志和家庭食谱，而不是只提供通用饮食建议。

真正困难的部分并不是“接入向量数据库”

接入 RAG 只是相对容易的部分。真正困难的问题是：

• 检索到的内容是否正确；
• 回答出错时，错误发生在文档切分、向量表示、检索还是生成阶段；
• 最终答案是否真正解决了用户需求。

四项关键能力

1. 文档切分

长文档需要拆成较小片段。片段太长会混入大量无关信息，片段太短又可能失去上下文。切分策略会直接影响后续检索质量。

2. 向量表示

系统需要把文字转换成向量，也就是一种可以进行相似度比较的数字表示。向量质量决定了系统能否理解“文字不同但含义接近”的内容。

3. 检索策略

只找到“看起来相似”的片段并不够，还要找到真正能支持回答的证据。常见优化方向包括关键词与向量混合检索、重排序、元数据过滤等。

4. 评估体系

等级 2 不仅要评价最终答案，还要评价每个组件。例如：

• 检索结果是否包含正确证据；
• 证据是否与问题相关；
• 回答是否忠于证据；
• 回答是否完整解决业务需求。

完成这一阶段后，项目不再只是“模型能回答”，而是能够基于私有数据给出相对可靠、可验证的答案。

等级 3：AI Agent——让模型真正采取行动

等级 2 的系统主要负责回答问题。等级 3 则进一步要求系统执行任务。

AI Agent 可以理解为“能够使用工具并自主决定下一步行动的模型”。系统接收一个目标后，会不断循环执行以下过程：

1. 观察当前状态；
2. 决定下一步做什么；
3. 调用工具执行行动；
4. 检查结果；
5. 根据结果继续下一步，直到任务结束。

典型应用

• 研究智能体：从多个来源收集资料并整理简报；
• 客服智能体：查询订单、判断问题类型并处理请求；
• 编程智能体：读取代码、运行测试、修改文件；
• 数据智能体：查询数据库、执行计算并生成报告。

能力越强，风险越高

在 RAG 系统中，错误通常表现为一次回答不准确。智能体则会执行连续决策，一旦前面走错一步，后续行动可能全部建立在错误基础上。

如果智能体能够操作信用卡、代码仓库、邮箱或数据库，错误就不再只是“回答不好”，而可能造成真实损失。因此，等级 3 的评估对象不只是最终答案，而是整条决策轨迹。

更安全的升级方式

刚开始接入工具时，应优先采用只读模式。例如，饮食智能体可以读取饮食日志、调用营养计算器和搜索网页，但暂时不能修改数据或自动下单。

在开放更多权限之前，需要先完成：

• 全链路可观测性；
• 工具权限控制；
• 异常处理；
• 安全测试；
• 可靠性评估。

这也是 Agent 项目从“有趣 Demo”走向“可用产品”的分水岭。

等级 4：企业级 AI 系统——多智能体、规模化与可靠性

等级 4 面向企业级 AI 系统。高阶 AI 工程岗位通常并不是在做一个简单聊天机器人，而是在建设能够承载真实业务的大型系统。

此时，一个智能体不再承担所有任务。系统会由多个专门智能体协作完成工作：

• 路由智能体负责理解请求并分配任务；
• 计费智能体处理费用相关问题；
• 技术智能体解决技术问题；
• 知识智能体负责检索证据；
• 审核智能体在结果发出前进行最终检查。

多智能体系统为什么更难

每增加一个智能体，就增加一个可能出错的环节。前一个智能体的错误可能被直接传递给下一个智能体，最终形成错误链路。

当系统面向真实客户并同时服务大量用户时，一次错误可能公开暴露，并带来业务、品牌或合规成本。

主要工作往往发生在智能体之外

对 Claude Code 代码结构的研究曾显示，真正的模型调用只占系统的一小部分，大量代码用于维持系统可靠运行。这里更值得关注的并不是某个具体比例，而是一个清晰结论：企业级 AI 的难点通常不是“调用模型”，而是围绕模型建立完整工程体系。

关键能力包括：

• 追踪（Tracing）：记录每个智能体调用了什么工具、读取了什么信息、做出了什么决定；
• 安全护栏（Guardrails）：防止提示注入、越权操作与数据泄露；
• 成本控制：控制模型调用次数、上下文长度和工具资源消耗；
• 延迟控制：避免多轮协作导致响应时间过长；
• 故障恢复：在某个组件失败后能够重试、降级或转人工处理；
• 规模化设计：系统架构能够支持更多用户和更高并发。

单一饮食智能体可以进一步拆成一个小团队：一个负责规划餐食，一个负责生成购物清单或下单，另一个负责审核计划。随后可通过故意加入错误信息，测试审核智能体是否真正能够发现问题。

即使个人项目无法模拟百万用户，也可以从一开始就考虑云服务、成本、可靠性和扩展性，从而证明系统具备向生产环境演进的可能。

等级 5：自主改进系统——让智能体参与建设智能体

等级 5 是这套框架中的最高阶段。此时，工程师不再手工指导系统完成每一次修改，而是建立一个能够持续改进自身的循环。

这不仅是让编程智能体写代码，也不仅是根据需求说明自动实现功能。更进一步的系统会：

1. 分析当前表现；
2. 提出可能有效的改动；
3. 自动实现并运行测试；
4. 判断改动是否真的带来提升；
5. 保留有效改动，回退无效改动；
6. 再次开始下一轮实验。

代表性案例

Andrej Karpathy 曾让一个智能体在两天内自主完成约 700 次实验，并找到多种加速模型训练的方法。Anthropic 也曾分享，Claude 已经参与编写其代码库中的大量代码。

这些案例共同指向一个趋势：顶尖团队正在探索由智能体持续提出改动、实施改动并验证效果的开发方式。

最难的问题：评价器是否可靠

自主改进循环成立的前提，是系统能够正确评价自身工作。如果评价指标设计得不准确，智能体可能不会真正改善产品，而是寻找评分规则的漏洞。

例如，系统的目标只是“提高某个数字”，智能体可能通过取巧方式获得高分，但真实产品体验反而变差。这类现象可以理解为“指标被优化了，目标却被破坏了”。

因此，等级 5 需要三项极高要求：

• 设计难以被钻空子的评价体系；
• 对所有实验、决策和结果进行完整记录；
• 明确哪些环节仍然必须由人类决定和审批。

即使最先进团队也没有完全取消人工参与。问题选择、评分设计和生产上线仍然需要人类负责。

这一等级很难通过几周自学达到。相关能力通常来自多年生产系统经验，以及对大量真实故障的持续复盘。

五个等级放在一起看

对求职项目最重要的启示

这套五级框架最重要的观点并不是“所有项目都必须做到等级 5”，而是：项目需要证明实际价值，而不是堆叠热门名词。

许多真实生产工作其实主要处于等级 2 或等级 3。有时，一个设计良好的提示词配合简单评估，就足以解决重要问题。企业招聘的目标是找到能够创造价值的人，而不是找到使用最多框架的人。

从五级框架中，可以提炼出一套更适合求职作品集的检查标准。

1. 是否解决了真实问题

项目需要明确说明场景、用户、痛点和成功标准，而不是只展示技术组件。

2. 是否有可重复的评估方法

至少需要准备一组测试样例，并说明系统在准确性、完整性、可靠性或任务成功率方面的表现。

3. 是否能解释错误来源

高质量项目应能够区分：错误来自检索、模型生成、工具调用、数据质量还是业务规则。

4. 是否考虑了异常与边界情况

包括空输入、错误文件、超长文本、模型超时、工具失败、无检索结果和权限不足等情况。

5. 是否考虑安全、成本与延迟

这些内容即使没有做到企业级规模，也可以通过设计说明、日志、限制策略和测试结果体现工程思维。

6. 是否能够复现

项目应提供清晰的运行说明、依赖环境、数据样例、系统架构图和关键设计决策。

结语：有用，比炫技更重要

AI 工程能力并不等于会调用最新模型。真正的能力体现在：能否把模型放进一个可靠系统，让系统基于正确资料工作，能够被评估，能够安全调用工具，并且在真实环境中保持稳定。

等级 1 是起点，等级 2 和等级 3 已经能够覆盖大量实际岗位需求；等级 4 代表成熟的企业级工程能力；等级 5 则是当前最前沿、最依赖长期生产经验的方向。

求职项目最值得展示的，不是功能数量，而是问题定义、评估方法、错误分析和工程取舍。一个范围不大但证据完整、质量可测、逻辑闭环的项目，通常比一个堆满 Agent、RAG 和多模型名词却无法解释效果的 Demo 更有说服力。