Day 1：AI 应用开发全景地图
学习目标
今天的目标只有一个：建立对 AI 应用开发的完整认知框架。
很多学 AI 的人，学了两个月还停留在”跟 ChatGPT 聊天”的阶段。根本原因是他们脑子里没有全景图，不知道 AI 应用到底由哪些部分组成，不知道从哪里开始、往哪里走。今天我们要解决的就是这个问题。
完成今天的学习后，你应该能回答以下问题：AI 应用开发和”用 AI”有什么本质区别？一个完整的 AI 应用系统包含哪些模块？Chatbot、RAG、Workflow、Agent 这些概念到底是什么关系？为什么企业 AI 不是写好 Prompt 就够了？
这些问题的答案构成了你后续 55 天学习的地基。地基不牢，后面所有内容都会浮在表面。
核心概念
一、AI、机器学习、深度学习、大模型、Agent 的层级关系
理解这五个概念的最简单方式是把它们想象成一套俄罗斯套娃，每一层都包含在前一层之内，但每一层都比前一层更加具体。
人工智能（AI）是最外层的套娃，也是最宽泛的概念。它指的是让机器表现出智能行为的任何技术。早在 1950 年代，计算机科学家就在研究怎么让机器下棋、证明数学定理。那时候的 AI 和今天的大模型没有任何关系，但它们都属于 AI 这个大类。
机器学习（ML）是 AI 的一个子集。它的核心思想是：不让人类手写所有规则，而是让机器从数据中自动学习规律。举个例子，如果你想做一个垃圾邮件过滤器，传统做法是人工编写规则——如果邮件包含”中奖”就标记为垃圾邮件，如果包含”免费领取”也标记。但规则永远写不完，垃圾邮件发送者也在不断进化。机器学习的做法不同，你给模型看一万封垃圾邮件和一万封正常邮件，让它自己发现区分两者的模式。
深度学习（DL）是机器学习的一个子集，它使用多层神经网络来学习数据中的复杂模式。深度学习在 2012 年左右开始爆发，主要原因是两个：算力（GPU）变得足够便宜，数据量变得足够大。图像识别、语音识别这些任务，深度学习的效果远远超越了传统机器学习方法。
大语言模型（LLM）是深度学习的一个特定应用方向。它用海量文本数据训练超大规模的神经网络，让模型学会理解和生成人类语言。GPT 系列、Claude、Gemini、LLaMA 都是大语言模型。它们的共同特点是：参数量巨大（几十亿到几千亿），训练数据海量（互联网上的大量文本），能力通用（一个模型能做翻译、写作、编程、推理等多种任务）。
Agent（智能体）是在大模型基础上构建的应用形态。如果说大模型是一个超级大脑，那 Agent 就是给这个大脑装上了手和脚——它能感知环境、制定计划、使用工具、执行动作、根据反馈调整策略。Agent 不只是回答问题，它能完成任务。
用一个比喻来总结：AI 是整个宇宙，机器学习是太阳系，深度学习是地球，大模型是地球上的人类文明，Agent 是一个能干活的工人。每一层都是前一层的特殊化。
为什么要搞清这个层级关系？因为在实际工作中，你遇到的很多问题需要回到正确的层级去找答案。比如客户说”我要一个 AI 系统”，你脑子里应该马上反应过来：他要的是什么层级的 AI？是一个简单的基于规则的自动化流程？还是一个需要机器学习的预测系统？还是一个基于大语言模型的文本处理应用？还是一个能自主执行任务的 Agent？不同层级的方案，技术栈、成本、周期完全不同。
二、AI 应用开发的真实含义
很多人理解的”AI 应用开发”就是在 ChatGPT 网页上输入一段文字，然后复制结果。这不叫 AI 应用开发，这叫使用 AI。
AI 应用开发是把大模型的能力封装到一个系统里，让这个系统能够稳定地、可重复地、规模化地解决特定的业务问题。
打个比方。你会用 Excel 的求和公式，这不叫开发财务系统。真正的财务系统是：把求和公式嵌到一套完整的工作流里，配合数据校验、权限控制、报表生成、异常提醒，让非技术人员也能准确高效地完成财务工作。
AI 应用开发也是同样的道理。你需要把大模型的能力嵌到一套工程系统里。这个系统至少要处理以下问题：
输入管理——用户怎么把需求告诉系统？是文字输入、文件上传、还是数据库对接？输入的内容需要做什么预处理？要不要做格式校验、敏感信息过滤、长度限制？
模型调用——什么时候调用模型？调哪个模型？传什么参数？要不要多轮对话？流式输出还是一次性返回？调用失败了怎么办？超时了怎么处理？
结果处理——模型返回的结果怎么解析？怎么保证格式正确？怎么校验内容的准确性？结果要存到哪里？要不要做后处理？
业务流程——一个任务可能需要多次模型调用，中间的流程怎么编排？每一步的输出怎么传给下一步？出错后怎么回滚？用户中途怎么介入？
评估反馈——系统输出好不好？用什么标准衡量？怎么自动评估？怎么收集用户反馈？怎么基于反馈持续优化？
安全控制——用户输入了恶意内容怎么办？模型输出了不当内容怎么办？数据隐私怎么保护？调用权限怎么管理？
这些问题加在一起，构成了 AI 应用开发的完整含义。它的本质是系统工程，不是写 Prompt。
三、Chatbot / RAG / Workflow / Agent / Multi-Agent 区别
这五个概念是 AI 应用开发中最核心的架构模式，理解它们的区别是入门的第一步。
Chatbot（聊天机器人）是最基础的 AI 应用形态。用户发消息，模型回复消息，就这么简单。ChatGPT 网页版就是一个 Chatbot。它的特点是单轮或简单的多轮对话，没有外部知识，没有工具调用，完全依赖模型自身的知识。适合做通用问答、闲聊、简单咨询。
RAG（检索增强生成）在 Chatbot 基础上加了一个知识库。模型不再只依赖自身训练时的知识，而是先从你的文档库里检索相关内容，再基于这些内容来生成回答。RAG 解决的核心问题是：大模型不知道你公司的内部信息。比如你问”我们公司的年假政策是什么”，模型本身不知道答案，但如果它能从公司员工手册里找到相关内容，就能准确回答。
Workflow（工作流）是一种固定流程的自动化方式。你预先定义好一系列步骤，每个步骤可能调用模型，也可能执行其他操作（查询数据库、调用 API、发送邮件等），步骤之间有明确的输入输出关系。Workflow 的特点是流程是预先设计好的，不会根据中间结果动态调整。就像工厂流水线，产品按固定路线经过每个工位。
Agent（智能体）是一种更灵活的架构。你给它一个目标，它自己决定要做什么、调用什么工具、按什么顺序执行。Agent 有规划能力、工具使用能力、反思能力。它像是一个能自主思考的员工，你告诉他目标，他自己想办法完成。
Multi-Agent（多智能体）是多个 Agent 协作完成复杂任务。每个 Agent 有自己的专业领域和职责，它们通过某种机制协调、通信、整合结果。Multi-Agent 适合特别复杂的任务，单个 Agent 难以胜任的场景。
为了更直观地理解它们的区别，可以这样想：Chatbot 是一个只能说话的客服，RAG 是一个带资料库的客服，Workflow 是一个按流程手册办事的专员，Agent 是一个能灵活应变的项目经理，Multi-Agent 是一个专业团队。
在实际项目中，这些架构不是互斥的，而是可以组合使用的。一个 RAG 系统内部可能包含 Workflow 来编排检索流程。一个 Agent 系统内部可能使用 RAG 来获取知识。一个 Multi-Agent 系统中，每个 Agent 可能都是一个包含 RAG 能力的智能体。
选择哪种架构取决于三个因素：任务的复杂度、流程的确定性、对可控性的要求。任务简单就用 Chatbot，需要外部知识就用 RAG，流程固定就用 Workflow，需要灵活决策就用 Agent，任务特别复杂就用 Multi-Agent。
四、AI 应用系统九大模块
一个完整的 AI 应用系统可以拆解为九个模块。这九个模块不是每个 AI 应用都必须全部实现，但你需要知道它们的存在，因为随着应用复杂度的增加，你会逐一遇到它们。
输入层：用户与系统交互的入口。它负责接收用户的各种输入——文字消息、文件上传、语音输入、图片输入等。输入层不只是简单地传递数据，它还需要做预处理：格式校验（用户上传的是不是支持的文件类型？）、长度限制（输入文本太长怎么截断？）、敏感信息过滤（输入里有没有密码、身份证号之类的隐私数据？）、意图识别（用户想做什么？是提问、下指令、还是闲聊？）。输入层是系统的门面，它的设计直接决定了用户体验。
模型层：系统的核心计算引擎。它负责与大语言模型交互——选择合适的模型、构造请求参数、发送请求、处理响应。模型层需要考虑很多工程问题：多个模型之间怎么切换？用 GPT-4 还是 Claude？什么时候用便宜的小模型，什么时候用贵的大模型？怎么处理模型的速率限制？怎么应对模型服务不可用的情况？怎么统计 Token 用量和成本？一个好的模型层应该把这些复杂性全部封装起来，让上层业务代码不需要关心底层细节。
知识层：系统获取外部知识的通道。大模型的知识来自训练数据，有截止日期，也不知道企业内部信息。知识层就是弥补这个缺陷的。它通常包含文档解析（把 PDF、Word、Excel 转成可处理文本）、文本切块（把长文档切成小段）、向量化（把文本变成数学向量）、向量存储和检索（根据用户问题找到最相关的文本片段）。知识层是 RAG 架构的核心，也是企业级 AI 应用的必备模块。
工具层：系统执行动作的能力。大模型只能生成文字，不能发邮件、查数据库、调用 API。工具层就是给系统装上”手脚”。一个工具通常包含：工具定义（这个工具能做什么，需要什么参数）、工具选择（根据当前任务决定用哪个工具）、工具执行（实际调用工具并获取结果）、结果处理（把工具返回的结果转成模型能理解的格式）。常见的工具包括：网络搜索、数据库查询、文件读写、邮件发送、API 调用等。
流程层：系统的任务编排引擎。一个复杂任务通常需要多个步骤，流程层负责决定步骤的执行顺序、条件分支、循环逻辑、错误处理。流程层有两种风格：固定流程（Workflow）和动态流程（Agent）。固定流程是预先设计好的，每一步做什么都确定了；动态流程由 Agent 根据实际情况实时决策。实际项目中往往是两种风格的混合——大流程是固定的，某些节点由 Agent 灵活处理。
记忆层：系统的状态管理机制。它负责存储和管理对话历史、用户偏好、任务进度等上下文信息。记忆层的设计直接影响系统的连贯性和个性化能力。记忆分为短期记忆（当前对话的上下文）和长期记忆（跨对话的用户信息、历史交互记录）。短期记忆通常用对话历史列表实现，长期记忆通常用数据库或向量存储实现。记忆层还需要考虑上下文长度限制——当对话历史太长超过模型能处理的范围时，需要做截断或压缩。
评估层：系统的质量保证机制。它负责评估系统输出的质量，包括：准确性（输出的内容是否正确？）、完整性（是否遗漏了重要信息？）、格式合规（输出格式是否符合要求？）、安全性（有没有输出不当内容？）。评估可以自动化（用另一个模型来评估输出质量），也可以人工审核（人在循环中检查关键输出）。评估层是持续优化系统的基础——没有评估，你根本不知道系统好不好，更不知道往哪个方向优化。
安全层：系统的防护机制。它负责应对两类威胁：外部攻击和内部风险。外部攻击包括 Prompt 注入（用户精心构造输入来绕过系统限制）、数据投毒（在知识库中植入误导信息）。内部风险包括模型幻觉（模型编造虚假信息）、数据泄露（模型输出了不应该公开的信息）、工具越权（Agent 调用了不应该调用的工具）。安全层需要在输入端做过滤、在输出端做审查、在工具调用时做权限检查。
交付层：系统的用户界面和部署架构。它决定了用户怎么使用这个系统——是一个网页应用、一个微信机器人、一个 API 接口、还是一个嵌入到现有系统中的功能模块？交付层还需要考虑：用户认证和权限管理、多租户隔离（不同客户的数据互不可见）、计费和用量统计、监控和告警、高可用和容灾。
这九个模块不是独立工作的，它们之间有紧密的协作关系。一次典型的用户交互可能是这样的：用户通过输入层提交问题，系统在记忆层找到相关上下文，通过知识层检索相关文档，在流程层编排处理步骤，由模型层调用大模型生成回答，经过评估层检查质量，通过安全层过滤风险内容，最终由交付层把结果呈现给用户。如果任务需要执行动作，还会调用工具层的工具。
五、为什么 Prompt 不是 AI 应用的全部
这是初学者最容易犯的错误。很多人以为做一个 AI 应用就是写好一个 Prompt，然后在 ChatGPT 里跑就行。
Prompt 确实重要。它是你与大模型沟通的方式，好的 Prompt 能显著提升输出质量。但 Prompt 只是 AI 应用系统的一个组件，就像菜谱只是开餐厅的一个要素。
为什么 Prompt 不够？
第一，Prompt 不能保证输出稳定。同样的 Prompt，模型可能给出截然不同的回答。在企业应用中，这种不确定性是不可接受的。你需要结构化输出、格式校验、重试机制来保证稳定性。
第二，Prompt 不能获取实时信息。模型的知识停留在训练数据的截止日期。你问它今天的新闻、最新的股价、公司内部的政策，它要么说不知道，要么编一个答案。你需要 RAG、工具调用来获取实时信息。
第三，Prompt 不能执行动作。模型只能生成文字。你要让它发邮件、改数据库、调接口，光靠 Prompt 做不到。你需要工具层、流程层来实现真正的自动化。
第四，Prompt 不能保证安全。用户可以通过精心构造的输入绕过 Prompt 的限制，让模型做不该做的事。你需要安全层来防护。
第五，Prompt 不能规模化。一个 Prompt 也许能在一个人使用时表现良好，但当一千个人同时使用，当输入格式千奇百怪，当并发请求压上来，光靠 Prompt 就撑不住了。你需要完整的工程系统来支撑规模化。
一个极端但形象的比喻：Prompt 就像是对一个新员工说的第一句话。你告诉他”帮我分析一下半导体行业的 AI 机会”，他也许能给出一个还不错的答案。但如果你要建立一个真正高效的团队，你需要工作流程、知识库、工具系统、质量检查、安全规范、培训体系。AI 应用开发就是建立这套完整体系。
六、为什么 AI 应用开发是系统工程
把前面的内容串起来，你应该能看出：AI 应用开发不是某一项技术的应用，而是多种技术的系统整合。
系统工程的本质是处理复杂性。AI 应用的复杂性来自几个方面：
模型的不确定性。传统软件的行为是确定性的——相同的输入永远产生相同的输出。但大模型不是这样。同样的输入可能产生不同的输出，而且你无法完全预测它会输出什么。这种不确定性要求你在系统设计中加入大量的校验、重试、降级机制。
数据的多样性。企业数据不是干净的、标准化的文本。你会遇到 PDF 里的表格、扫描件的图片、Excel 里的数据、Word 里的嵌套格式。每一种数据格式都需要专门的处理逻辑。
用户需求的模糊性。用户往往说不清楚自己要什么。“我想要一个 AI 帮我分析业务”——分析什么业务？分析的维度是什么？输出什么格式的结果？需要多久？需要多准？系统设计者需要把这些模糊需求翻译成明确的技术方案。
成本与效果的平衡。大模型的调用是有成本的。GPT-4 每次调用可能花费几毛钱到几块钱。如果一个任务需要调用十次模型，每天有一千个用户使用，一个月的成本就是几万到几十万。你需要在效果和成本之间找到平衡点——不是所有任务都需要最贵的模型。
安全与可控。AI 系统不像传统软件那样完全可控。模型可能产生幻觉，Agent 可能做出意料之外的行为。你需要在系统中设计足够的控制机制，同时不牺牲太多灵活性。
正因为这些复杂性，AI 应用开发需要系统思维。你不能只关注某一个环节（比如 Prompt），而要从整体架构出发，考虑各个模块如何协作，如何处理异常情况，如何持续优化。
概念关系图
AI 应用开发全景图
+------------------------------------------------------------------+
| AI 应用系统 |
| |
| 用户交互 |
| +-----------+ +-----------+ +-----------+ |
| | 输入层 | --> | 流程层 | --> | 交付层 | |
| | (接收请求)| | (编排步骤)| | (返回结果)| |
| +-----------+ +-----+-----+ +-----------+ |
| | |
| +-----------+-----------+ |
| | | |
| +----+----+ +-----+-----+ |
| | 模型层 | | 工具层 | |
| | (调LLM) | | (执行动作)| |
| +----+----+ +-----+-----+ |
| | | |
| +-----------+-----------+-----------+-----------+ |
| | | | | | |
| | 知识层 | 记忆层 | 评估层 | 安全层 | |
| | (RAG) | (上下文) | (质量) | (防护) | |
| +----------+-----------+-----------+-----------+ |
| |
+------------------------------------------------------------------+
AI 应用架构层级
Chatbot < RAG < Workflow < Agent < Multi-Agent
(简单) (复杂)
+----------+ +----------+ +-----------+ +----------+ +------------+
| Chatbot | | RAG | | Workflow | | Agent | | Multi-Agent|
| | | | | | | | | |
| 问 -> 答 | | 问 -> 检 | | 触发 -> | | 目标 -> | | 目标 -> |
| | | 索 -> 答 | | 固定流程 | | 灵活决策 | | 团队协作 |
| | | | | -> 结果 | | -> 结果 | | -> 结果 |
+----------+ +----------+ +-----------+ +----------+ +------------+
实战分析
画 AI 应用开发全景图
这个任务的目的是把抽象概念具象化。画图的过程就是思考的过程。
具体画法建议：在画面中心放置”AI 应用系统”这个核心概念，向外辐射九大模块，用箭头标注它们之间的数据流和协作关系。然后在全景图的一侧标注五种应用架构（Chatbot 到 Multi-Agent），用渐进的方式表示复杂度的递增。
这张图不需要美观，但需要逻辑清晰。画完之后，找一个完全不懂 AI 的人，试着用这张图向他解释什么是 AI 应用。如果他听懂了，说明你的图是对的。
整理 50 个 AI 核心关键词
关键词整理的目的是建立术语体系。AI 领域有大量专业术语，初学者经常被各种名词搞混。
建议把 50 个关键词分成几类：基础概念类（AI、ML、DL、LLM 等）、模型相关类（Token、Context Window、Temperature 等）、应用架构类（RAG、Agent、Workflow 等）、工程实践类（Prompt、JSON Schema、API 等）、评估安全类（Eval、幻觉、Prompt 注入等）。
每个关键词不仅要写出定义，还要写一个一句话的解释——如果你能用简单的语言向非技术人员解释清楚这个词，说明你真正理解了。
写一段自己对 AI 应用开发的定义
这个任务看似简单，实际上是在强迫你用自己的语言把今天的知识内化。
不要照抄指南里的话，用自己的理解来写。定义应该包含三个要素：AI 应用开发是什么（本质），它解决什么问题（价值），它包含哪些要素（范围）。
写完之后放在一边，第二天再拿出来看。如果你觉得昨天的定义有需要修改的地方，说明你在进步。
用半导体场景解释 AI 如何嵌入业务流程
这个任务是在练习把技术概念映射到具体行业。半导体是一个好的练习场景，因为它有丰富的业务流程和明确的数据需求。
思考路径：半导体企业的核心业务流程有哪些？从外延片制造到芯片测试封装，每个环节都有哪些数据和知识可以 AI 化？哪些环节适合用 Chatbot（比如设备操作问答）？哪些适合用 RAG（比如工艺文档检索）？哪些适合用 Workflow（比如良率分析报告生成）？哪些适合用 Agent（比如生产异常自动排查）？
不要泛泛地想”AI 可以帮半导体提升效率”，而是要具体到某个环节、某个场景、某个岗位、某个痛点。越具体，越能体现你对 AI 应用开发的理解。
当日产物说明
《AI 应用开发全景图》
这是一张概念关系图，核心要素是九大模块及其协作关系，五种应用架构及其复杂度递进关系。可以手画也可以用工具画，重点是逻辑清晰而非美观。质量标准：一个不懂 AI 的人能通过这张图大致理解 AI 应用系统的组成。
《AI 核心关键词 50 个》
一份术语清单，每个词包含：中文术语、英文原名、一句话定义、所属类别。建议按类别分组排列，方便后续查阅。质量标准：覆盖 AI 应用开发最常用的术语，定义准确且通俗易懂。
《我理解的 AI 应用开发》
一段 300-500 字的文字，用你自己的语言定义 AI 应用开发。质量标准：不是照抄定义，而是体现了你自己的理解和思考。包含本质、价值、范围三个要素。
《半导体 AI 提效场景草图》
一份场景分析文档，列出半导体企业中至少 5 个可以用 AI 提效的具体场景，每个场景标注适合的应用架构类型（Chatbot/RAG/Workflow/Agent/Multi-Agent）。质量标准：场景足够具体，不是泛泛而谈，能对应到真实的业务环节。
常见误区与避坑
误区一：认为 AI 应用开发就是写 Prompt
这是最常见的误区。Prompt 只是 AI 应用系统的一个组件。把它等同于整个应用开发，就像把写 SQL 等同于做数据库系统一样荒谬。Prompt 决定了模型输出的上限，但工程系统决定了输出的下限。在企业应用中，下限比上限更重要。
误区二：认为 Agent 万能，什么都想用 Agent
Agent 是强大的架构，但不是所有场景都需要。简单的问答用 Chatbot 就够了，固定流程用 Workflow 更可控。Agent 的灵活性意味着不确定性增加、成本增加、调试难度增加。选择架构应该从简单到复杂，不要一上来就上最复杂的方案。
误区三：把九大模块当成必须全部实现的清单
九大模块是一个参考框架，帮助你理解和规划。实际项目中，简单的应用可能只需要输入层、模型层、交付层就够了。随着需求增长，再逐步加入知识层、工具层等其他模块。不要追求一步到位，而是根据实际需要逐步构建。
误区四：混淆”使用 AI”和”开发 AI 应用”
使用 AI 是个人行为——你在 ChatGPT 里写 Prompt，得到回答，你满意了就行。开发 AI 应用是工程行为——你要让系统能稳定地、可重复地、规模化地解决问题。两者的思维模式完全不同。前者关注”能不能得到好结果”，后者关注”系统能不能持续产出合格的结果”。
误区五：忽视评估和安全
很多人做 AI 应用只关注”能跑起来”，完全不考虑输出质量和安全风险。这就像做一个网站不考虑安全和测试一样危险。在企业场景中，一次幻觉（模型编造错误信息）或者一次数据泄露，就可能造成严重后果。评估层和安全层应该从一开始就纳入设计，而不是事后补充。
延伸思考
今天的全景图为后续所有内容提供了框架。明天的 LLM 原理学习，对应的是模型层的深度理解。后天的 Prompt 工程，对应的是模型调用质量的优化。后续的 RAG、Workflow、Agent，分别对应知识层、流程层和动态流程层的具体实现。
从工程视角看，AI 应用开发与传统软件开发最大的区别在于”不确定性管理”。传统软件的行为是确定的，测试用例可以覆盖所有场景。AI 应用的行为有随机性，你无法穷举所有可能的输出。这意味着你需要一种不同的工程思维：不是追求 100% 的确定性，而是建立一套机制让系统在不确定性下依然可控——通过评估持续监控质量，通过安全层过滤风险，通过重试和降级保证可用性。
从商业视角看，理解 AI 应用开发的全景图，能帮你快速判断一个”AI 需求”的真实复杂度。客户说”我要一个 AI 助手”，你需要在一分钟内判断：这是一个 Chatbot 级别的需求，还是一个 RAG 级别的需求，还是一个 Agent 级别的需求？不同级别对应不同的技术方案、开发周期和报价。这个判断能力直接决定了你能不能把 AI 能力变成可交付的服务。
从个人成长视角看，这份全景图是你学习的路线图。你不需要一次性掌握所有模块，但你需要知道每个模块的存在和它解决的问题。当你遇到具体问题时，你知道该往哪个方向深入。
自测问题
-
用自己的话解释 AI、机器学习、深度学习、大模型、Agent 的层级关系。它们之间是什么包含关系？
-
Chatbot 和 RAG 的核心区别是什么？什么场景下必须用 RAG 而不是 Chatbot？
-
Workflow 和 Agent 的核心区别是什么？举一个适合用 Workflow 的场景和一个适合用 Agent 的场景。
-
列举 AI 应用系统的九大模块，并说明每个模块解决什么问题。
-
为什么说 Prompt 不是 AI 应用的全部？至少给出三个理由。
-
一个企业想做一个”员工可以问公司政策的 AI 助手”，这个需求最适合用哪种架构？为什么？
-
在九大模块中，哪个模块负责处理”模型不知道最新信息”这个问题？
-
模型的不确定性给 AI 应用开发带来了哪些挑战？至少说出两个具体的工程问题。
-
如果一个客户说”我想让 AI 自动帮我分析每天的生产数据并生成报告”，你会推荐哪种架构？这个系统至少需要哪几个模块？
-
“使用 AI”和”开发 AI 应用”的本质区别是什么？为什么这个区别很重要？
关键词
- AI（人工智能）：让机器表现出智能行为的技术的总称
- ML（机器学习）：让机器从数据中自动学习规律的方法
- DL（深度学习）：使用多层神经网络学习复杂数据模式的技术
- LLM（大语言模型）：用海量文本训练的超大规模语言生成模型
- Agent（智能体）：能自主规划、使用工具、执行任务的大模型应用形态
- Chatbot（聊天机器人）：基于对话交互的最基础 AI 应用
- RAG（检索增强生成）：结合外部知识库检索的 AI 问答架构
- Workflow（工作流）：按固定流程编排多个步骤的自动化方式
- Multi-Agent（多智能体）：多个专业 Agent 协作完成复杂任务的架构
- Prompt：用户输入给大模型的指令文本
- Token：大模型处理文本的最小单位，约等于 0.75 个英文单词或 0.5 个汉字
- Hallucination（幻觉）：大模型编造看似合理但实际错误的信息的现象
- Context Window（上下文窗口）：大模型单次能处理的最大文本长度
- Embedding（向量化）：把文本转换为数学向量的过程，用于语义检索