【AI 一文入门】从 Prompt 到 Agent，搞懂所有核心概念 + 大数据提效实战

zy12345cc

256人浏览 · 2026-06-09 17:01:27

zy12345cc · 2026-06-09 17:01:27 发布

写在最前面：我为啥要写这篇文章？

说实话，最近这几年 AI 发展得太快了，新概念层出不穷，有时候刚学会一个，又来了三个。

2022 年 ChatGPT 出来，大家还在玩"你帮我写首诗"；2023 年就开始卷 Prompt Engineering（提示词工程）；2024 年 Agent（智能体）概念爆火，LangChain、AutoGPT 一堆框架冒出来；2025 年 Skill（技能）、MCP 协议、RAG 检索增强、多 Agent 协作……新概念跟下雨一样，噼里啪啦往下掉。

作为一个编程爱好者，我平时喜欢折腾各种新技术，也加了不少技术交流群，发现群里大家经常问：

“Prompt 和 Skill 到底啥区别？”
“Agent 是个啥？跟传统程序有啥不一样？”
“RAG 和 MCP 又是啥？我该学哪个？”
“公司想把 AI 接入大数据系统，该咋设计？”

这些问题，网上碎片化的文章一大堆，但没有一篇能从 0 到 1、由浅入深、把概念串成体系地讲清楚。所以今天这篇文章，我就把这段时间学习和实践的成果整理出来，再附上一个的实战案例，让你看完就大概知道怎么回事。

一、AI 概念全景图：一张图看清所有名词
二、Prompt 是什么？—— 你跟 AI 说话的"点菜指令"
三、Skill 是什么？—— AI 的"收藏菜单"
四、Prompt vs Skill：核心区别一张表说清楚
五、Agent（智能体）：让 AI 从"会说话"到"会干活"
六、RAG（检索增强生成）：给 AI 装上"外部大脑"
七、MCP 协议：AI 的"万能 USB 接口"
八、LangChain / LangGraph：AI 开发的"脚手架"
- 8.5 Workflow vs Chain vs Skill：日常开发到底用哪个？
九、规范 AI 开发流程：从需求到上线的正确姿势
十、实战案例：AI 驱动财务数据开发提效
十一、写在最后：给不同阶段同学的建议

一、AI 概念全景图：一张图看清所有名词

先别急着逐个学概念，咱们先来个"航拍的视角"，看看整个 AI 应用开发的版图长啥样。

这张图啥意思？ 一句话概括：

用户通过自然语言跟 AI 对话，AI 靠大模型理解意图，靠 Prompt 明确任务，靠 Skill 获得专业能力，靠 RAG 查外部资料，靠 MCP 调外部工具，最终由一个或多个 Agent 自主完成任务。而 LangChain/LangGraph/Dify 就是帮你搭这个系统的脚手架。

好，有了这个全景图，咱们逐个拆解。

二、Prompt 是什么？—— 你跟 AI 说话的"点菜指令"

2.1 一句话定义

Prompt（提示词）就是你每次跟 AI 说的话。 它是一次性的、临时的指令，用完就没了。

2.2 打个比方

Prompt 就像你去一家没光顾过的餐馆，每次都要跟服务员详细交代：“我不要香菜、少放辣、米饭硬一点。”——下次去同一家店，你还得再说一遍，服务员也不会记得你的偏好。

又或者像你用快递下单，每次都要手动填写收件地址、选择快递公司、勾选保价——每次操作都是独立的，系统不会记住你上次的选择。

2.3 Prompt 的核心技巧

别小看 Prompt，写得好的 Prompt 和写得差的，输出质量天差地别。分享几个经过反复验证的技巧：

1）角色设定（Role Prompting）

你是一位有 10 年经验的电商数据分析师，擅长从海量交易数据中
发现业务洞察。请用通俗易懂的语言解释以下数据...

给 AI 一个"人设"，它的回答质量会显著提升。这是因为大模型在训练时学习到了不同角色的表达方式。

2）少样本示例（Few-Shot）

请将以下用户评论分类为【好评/中评/差评】。

示例 1：
评论："物流很快，包装完好，手机用着很流畅"
分类：好评

示例 2：
评论："等了一周才到，有点失望"
分类：差评

现在开始：
评论："东西还行，就是价格有点贵"
分类：

给 AI 几个例子，它就能"举一反三"，这比单纯的指令效果好得多。

3）思维链（Chain-of-Thought）

请一步一步思考：一家电商公司上月 GMV 1000 万，
客单价 200 元，退货率 15%，请问实际成交了多少单？

请展示你的思考过程，最后再给出答案。

让 AI “说出思考过程”，复杂问题的准确率能提升 30% 以上。这个技巧后来演化成了著名的 ReAct 模式（后面讲 Agent 时会详细说）。

4）结构化输出

请分析以下产品评价，并以 JSON 格式返回结果：
{
  "情感倾向": "正面/负面/中性",
  "提到的优点": ["..."],
  "提到的缺点": ["..."],
  "购买意向": "强/中/弱"
}

让 AI 按固定格式输出，方便后续程序处理。

2.4 Prompt 的局限性

Prompt 虽然好用，但有几个致命弱点：

问题	说明
一次性	每次都要重新写，无法积累复用
无状态	这次对话和下次对话之间没有记忆
无法调用外部工具	纯靠模型自身知识，不能查数据库、不能调 API
容易泄露敏感信息	把公司数据写在 Prompt 里有安全隐患
长度限制	大模型有上下文窗口限制（比如 4K/8K/128K tokens）

正因为 Prompt 有这些局限，所以Skill、Agent、RAG、MCP 这些东西才应运而生。

三、Skill 是什么？—— AI 的"收藏菜单"

3.1 一句话定义

Skill（技能）是给 AI Agent 的一套标准化"作业流程"。 它包含了：Prompt 模板 + 执行步骤 + 调用的工具 + 约束规则 + 错误处理。一旦写好，AI 就"学会了"这个技能，以后一句话就能触发。

3.2 打个比方

Prompt 是你每次点外卖都要手动勾选"不要香菜、少辣"；Skill 是你在美团上保存的一套"我的偏好"，下单时自动应用，不用每次重复设置。

再换个角度——Prompt 是你每次打车手动输入目的地和车型；Skill 是你收藏的"公司-家"常用路线，一键呼叫。

举个例子——周报自动生成 Skill：

skill_name: 周报自动生成
version: 1.0
description: 从项目管理工具中提取本周数据，自动生成结构化的周报文档
trigger: 当用户说"生成本周报"或"写周报"时触发

steps:
  1. 调用项目管理 API，获取本周已完成的任务列表
  2. 调用 Git 仓库 API，获取本周代码提交记录
  3. 按"已完成/进行中/阻塞项"三个维度分类整理
  4. 提取关键数据：任务完成数、代码行数、Bug 修复数
  5. 按公司模板格式生成周报（Markdown）
  6. 推送到飞书/企业微信的周报频道
  7. @直属Leader 提醒查阅

constraints:
  - 只统计状态为"已完成"的任务，"进行中"的归到对应分类
  - 涉及敏感项目代号的内容需脱敏处理
  - 周报字数控制在 800-1500 字
  - 阻塞项必须附带原因说明和预计解决时间

error_handling:
  - 如果项目管理 API 调用失败：使用本地缓存数据，并在周报顶部标注"[数据可能不是最新]"
  - 如果本周无任务记录：生成"本周暂无任务更新"的占位周报
  - 如果模板格式缺失：使用默认格式，并提示用户更新模板

配置一次，以后每周一说"写周报"就自动搞定——不用每周手动翻任务列表、数代码行、调格式。

3.3 Skill 的本质特征

特征	说明
可复用	一次编写，到处运行
持久化	以文件形式存在（YAML/JSON），可版本管理
自触发	AI 自己判断什么时候该用哪个 Skill
包含完整工作流	不只是 Prompt，还包含工具调用、数据处理、错误处理
可组合	多个 Skill 可以嵌套调用

3.4 Skill 是怎么被触发的？

这是 Skill 最厉害的地方——触发权从人手里交到了 AI 手里。

AI 会根据用户的输入，自己判断该调用哪个 Skill。这背后靠的就是 Skill 文件里的 description 和 trigger 字段——相当于给 AI 一份"菜单"，让它自己点菜。

四、Prompt vs Skill：核心区别一张表说清楚

这个问题被问得最多，所以单独拎出来讲。

维度	Prompt（提示词）	Skill（技能）
本质	单次对话的文本指令	可复用的完整能力包
有效期	聊完就丢，下次重来	持久有效，可版本迭代
内容构成	只有文字	Prompt + 工具 + 流程 + 约束 + 错误处理
谁干活	大模型独自完成	Agent orchestrate（编排）大模型 + 工具协同
外部能力	❌ 不能调数据库/API	✅ 能读写文件、查数据库、调接口
记忆能力	无状态，每次从零开始	有状态，步骤间数据可传递
出错怎么办	只能人工重问	自动重试、降级、报警
怎么启动	人手动打字输入	AI 看用户意图自动匹配
团队怎么共享	❌ 复制粘贴，容易丢格式	✅ 文件化，Git 管理
典型场景	“翻译这段话”“写首诗”	“自动出周报”“审代码并提 PR”

一句话总结：Prompt 是"手写便签"，Skill 是"磁吸冰箱贴"。

Prompt 是 Skill 的原料之一，但 Skill 远不止 Prompt。

公式：Skill = 多个 Prompt 模板 + 工具调用清单 + 执行顺序编排 + 边界约束 + 异常处理策略

五、Agent（智能体）：让 AI 从"会说话"到"会干活"

5.1 一句话定义

Agent（智能体）是一个能够自主感知环境、做出决策、执行动作、并根据反馈调整行为的 AI 系统。 它不只是"回答问题"，而是能"完成任务"。

5.2 Agent 和 ChatGPT 有啥区别？

	ChatGPT	Agent
能力	只能"说"	能"想"+“说”+“做”
交互方式	一问一答	自主规划多步执行
外部工具	不能调用	能调数据库/API/文件/搜索等
记忆	单轮对话	长期记忆 + 上下文管理
典型应用	聊天、写作	自动数据分析、智能客服、代码生成

打个比方：ChatGPT 像一个"嘴皮子很溜的顾问"，只能给你建议；Agent 像一个"能动手干活的助理"，你跟他说"帮我订一张明天去上海的机票，要上午的，便宜的"，他会自己去查航班、比价、填信息、下单。

5.3 Agent 的核心工作原理

Agent 的运行遵循一个闭环流程，我用一个图说明：

这个循环就是 Agent 的"思考-行动-反思"过程，专业术语叫 ReAct（Reasoning + Acting）。

5.4 ReAct 模式详解

ReAct 是目前最主流的 Agent 设计模式。它的核心思想是：让模型在每一步都显式输出思考过程（Thought），再决定下一步行动（Action）。

看一个实际的执行日志，你就懂了：

用户问："2025 年诺贝尔奖物理学奖得主是谁？他们获得了多少奖金？"

[Step 1] Thought: 我需要先搜索 2025 年诺贝尔奖物理学奖的得主信息。
         Action: 调用搜索引擎，查询"2025 诺贝尔奖物理学奖得主"
         Observation: 2025 年诺贝尔物理学奖授予 John Hopfield 和 Geoffrey Hinton，
                      以表彰他们在人工神经网络和机器学习领域的贡献。

[Step 2] Thought: 好的，我知道得主是谁了。现在我需要查询诺贝尔奖的奖金金额。
         Action: 调用搜索引擎，查询"2025 诺贝尔奖奖金金额"
         Observation: 2025 年诺贝尔奖每项奖金为 1100 万瑞典克朗（约 100 万美元），
                      由获奖者平分。

[Step 3] Thought: 我已经获得了所有需要的信息，可以给出最终答案了。
         Action: 终止任务，输出答案
         Final Answer: 2025 年诺贝尔物理学奖授予 John Hopfield 和 Geoffrey Hinton，
                      两人平分 1100 万瑞典克朗（约 100 万美元）的奖金。

看明白了吗？Agent 不是一次性给出答案，而是一步一步地思考，每步都先想（Thought）再干（Action），然后根据观察结果（Observation）调整下一步策略。

5.5 Agent 的"大脑"组成

一个完整的 Agent 系统，内部通常包含这些核心模块：

模块	功能	类比
规划（Planning）	将复杂任务拆解成子任务	项目经理做 WBS
记忆（Memory）	存储和检索信息	人的大脑记忆
推理（Reasoning）	分析信息、做出判断	人的逻辑思维
工具调用（Tool Use）	调用外部工具完成任务	人用手机/电脑查资料
反思（Reflection）	检查执行结果、纠正错误	人做完事复盘

5.6 多 Agent 协作

复杂任务通常需要多个 Agent 协作完成，就像公司里不同部门协同工作：

比如你要做一个"竞品分析报告"：

项目经理 Agent：拆解任务——查产品功能、查价格策略、查用户评价
研究 Agent：去网上搜资料、爬数据
分析 Agent：做数据对比、趋势分析
写作 Agent：把分析结果整理成报告
审核 Agent：检查报告质量、补充遗漏

这种多 Agent 协作架构（Multi-Agent System）是 2025-2026 年企业级 AI 应用的主流方向。

六、RAG（检索增强生成）：给 AI 装上"外部大脑"

6.1 为什么需要 RAG？

大模型有个致命缺陷——知识截止。GPT-4 的知识截止到 2024 年初，你问它"昨天的新闻"，它答不上来。而且大模型还会" hallucination（幻觉）"——一本正经地胡说八道。

更关键的是，大模型不知道你公司的内部数据：销售数据、客户资料、产品文档、规章制度……这些东西它一概不知。

RAG 就是来解决这个问题的。

6.2 一句话定义

RAG（Retrieval-Augmented Generation，检索增强生成）= 先查资料，再回答。 它不是让大模型"硬想"答案，而是先从外部知识库中检索相关信息，然后把检索结果作为"参考资料"一起喂给大模型，让大模型基于这些资料生成答案。

6.3 RAG 工作流程

6.4 用一个例子理解 RAG

假设你在公司内部搭建了一个"产品知识库问答系统"：

用户问： “咱们公司最新款手机的电池容量是多少？支持快充吗？”

传统大模型的回答： “抱歉，我无法获取您公司具体产品的信息……”（因为它没见过你公司的内部资料）

RAG 增强后的回答：

系统将问题转为向量，去向量数据库检索
找到产品手册中的相关段落：
- “XX Pro 手机搭载 5000mAh 大容量电池”
- “支持 120W 超级快充，30 分钟充满”
把这些资料 + 用户问题一起喂给大模型
大模型生成答案：“XX Pro 手机搭载 5000mAh 大容量电池，支持 120W 超级快充，30 分钟即可充满。[来源：产品手册 V2.3]”

关键点：答案基于检索到的真实资料，不是瞎编的，还能标注信息来源。

6.5 RAG 的核心技术环节

环节	做什么	关键考量
文档加载	读取各种格式（PDF/Word/网页/数据库）	格式兼容性、编码处理
文本分块（Chunking）	把长文档切成小段	块大小（通常 500-1000 字）、重叠区域
向量化（Embedding）	把文字转为数字向量	选用什么 Embedding 模型
向量存储	存入向量数据库	Milvus / Chroma / pgvector
检索（Retrieval）	按相似度找最相关的块	Top-K 数量、重排序（Rerank）
生成（Generation）	大模型基于检索结果作答	Prompt 设计、引用标注

6.6 RAG vs 微调（Fine-tuning）

很多人问：“我直接把公司数据拿去微调大模型，不就行了？”

方式	原理	优点	缺点
RAG	检索外部知识，不改模型	成本低、实时更新、可溯源	依赖检索质量
微调	用新数据训练模型参数	模型"记住"了知识	成本高、训练慢、难更新

我的建议： 先用 RAG，能解决 90% 的问题。只有当 RAG 满足不了需求（比如需要深度推理能力）时，才考虑微调。

七、MCP 协议：AI 的"万能 USB 接口"

7.1 一句话定义

MCP（Model Context Protocol，模型上下文协议）是 Anthropic 推出的开放协议，旨在统一 AI 模型与外部工具、数据源的连接方式。 你可以把它理解为 AI 世界的"翻译官"——OpenAI 说一套语言、Google 说另一套、Anthropic 又说一套，MCP 让不同的 AI 模型和工具之间都能"听懂"彼此的调用指令，无缝协作。

7.2 MCP 解决了什么问题？

在 MCP 出现之前，AI 接入外部工具是一片混乱：

没有 MCP：M 个模型 × N 个工具 = M×N 种适配代码
有了 MCP：M 个模型 + N 个工具 = M+N 种适配代码

7.3 MCP 的核心架构

MCP 采用客户端-服务器架构：

组件	作用
MCP Host	AI 应用的主程序（如 Claude Desktop）
MCP Client	实现 MCP 协议的客户端，负责通信
MCP Server	提供具体工具能力的服务端

7.4 MCP 能做什么？

目前 MCP 生态已经支持的工具类型非常丰富：

文件系统：读写文件、遍历目录
数据库：SQL 查询、Schema 获取
浏览器：网页抓取、内容提取
Git：代码仓库操作
Slack：消息发送、频道管理
PostgreSQL / SQLite：数据库查询

7.5 MCP 和 Function Calling 的区别

特性	Function Calling	MCP
定义方	各模型厂商各自定义	统一开放标准
工具发现	程序硬编码	动态发现（AI 自己看有哪些工具可用）
跨模型兼容	❌ 不兼容	✅ 所有支持 MCP 的模型都能用
工具生态	各自为政	社区共建，生态丰富

一句话：Function Calling 是"各讲各的方言"，MCP 是"统一的普通话考试（HSK）标准"。

八、LangChain / LangGraph：AI 开发的"脚手架"

8.1 LangChain 是什么？

LangChain 是一个用于构建大模型应用的 Python 开发框架。 它把 AI 应用开发中常见的模式封装成了可复用的组件，让你不用从零写胶水代码。

LangChain 的核心理念：

LangChain 的 6 大模块：

模块	功能
Model I/O	统一管理各种大模型的调用
Prompts	Prompt 模板管理、变量替换
Indexes	文档加载、分块、向量化
Memory	对话历史管理、记忆存储
Chains	将多个操作串联成"链"
Agents	智能体的定义和执行

8.2 LangGraph 是什么？

LangChain 适合线性流程，但 Agent 的执行往往不是线性的——需要条件分支、循环、并行。这时候就需要 LangGraph。

LangGraph = 用"图"的方式编排 Agent 工作流。

LangGraph 的核心概念：

State（状态）：整个工作流的共享数据容器
Node（节点）：每个执行步骤
Edge（边）：步骤之间的流转关系
Conditional Edge（条件边）：根据条件决定走哪条路

8.3 LangChain vs LangGraph

特性	LangChain	LangGraph
适用场景	线性流程	复杂、有分支/循环的流程
执行方式	顺序执行	图调度，支持并行
状态管理	简单传递	中央状态管理
可视化	弱	强（可以画出流程图）

8.4 Dify / Coze：低代码平台

如果你不想写代码，或者想快速验证想法，可以用 Dify 或 Coze（扣子）。

平台	特点	适用场景
Dify	开源、可私有化部署、功能强大	企业内部应用、数据敏感场景
Coze	字节跳动出品、插件丰富、上手快	快速原型、个人项目

Dify 支持两种模式：

Chatflow：对话式应用（智能客服、AI 助手）
Workflow：自动化流程（数据处理、批量任务）

8.5 Workflow vs Chain vs Skill：日常开发到底用哪个？

这是很多人学到这里都会懵的地方——Workflow（工作流）、Chain（链）、Skill（技能），这三个词在文章里反复出现，到底啥区别？日常开发该用哪个？

一句话区分

概念	本质	谁在用	类比
Chain（链）	代码层面的操作串联	开发者写代码时用	流水线的机械臂
Workflow（工作流）	可视化编排的执行流程	开发者在 Dify/LangGraph 里拖拽配置	工厂的总控流水线
Skill（技能）	面向 AI 的能力封装	AI Agent 自己判断调用	员工的岗位手册

详细解释

Chain（链）—— LangChain 的核心概念

Chain 是 LangChain 框架里的编程概念，指的是把多个操作按顺序串起来，前一个的输出作为后一个的输入。

# 一个简单的 Chain：Prompt → LLM → 输出解析
chain = prompt_template | llm | output_parser
result = chain.invoke({"question": "销售额是多少"})

Chain 是代码层面的"管道"，开发者在写 Python 代码时拼接使用。它关注的是"数据怎么流"。

Workflow（工作流）—— 平台级的流程编排

Workflow 是可视化/配置层面的概念，指的是你在 Dify、Coze 或 LangGraph 里定义的一套完整执行流程。

Workflow 关注的是"业务逻辑怎么走"——条件分支、循环、并行、人工审批节点等等。你可以不写代码，在 Dify 里拖拽节点就能搭一个 Workflow。

Skill（技能）—— AI 的能力包

Skill 是面向 AI 的能力封装，告诉 Agent “你会做什么、怎么做”。AI 自己决定什么时候调用哪个 Skill。

Skill 内部可能包含多个 Chain 或 Workflow，但 Skill 的视角是"能力描述"——让 AI 知道"我有这个本领"。

从内到外：Chain（代码管道）→ Workflow（流程编排）→ Skill（能力封装）

日常开发怎么选？

场景	用什么	为什么
写 Python 代码拼接操作	Chain	LangChain 的原生方式，代码简洁
搭可视化自动化流程	Workflow	Dify/LangGraph 拖拽即可，不用写代码
让 AI 自动判断调用能力	Skill	Agent 自己选，用户一句话触发
简单线性流程（A→B→C）	Chain	几行代码搞定，没必要上 Workflow
复杂有分支/循环的流程	Workflow	Chain 写条件判断很啰嗦，Workflow 更清晰
需要 AI 自主决策的场景	Skill + Agent	不确定执行路径，让 AI 自己选

一句话总结：

写代码时用 Chain（LangChain 的管道）

搭流程时用 Workflow（Dify/LangGraph 的编排）

让 AI 自主调用时用 Skill（Agent 的能力菜单）

三者不是互斥的，一个 Skill 内部可以用 Workflow 编排，一个 Workflow 里可以串多个 Chain

九、规范 AI 开发流程：从需求到上线的正确姿势

讲了这么多概念，真正的重点来了：如何在企业中规范地开发 AI 应用？

这是结合了业界最佳实践和自己的学习心得，梳理出来的标准开发流程：

Phase 1：需求分析（最重要！最容易被忽略！）

核心问题：

这个需求真的需要 AI 吗？（很多场景用规则引擎就能解决）
目标用户是谁？使用场景是什么？
成功的衡量指标是什么？（准确率 > 90%？响应时间 < 2s？）
数据在哪里？质量如何？
安全和合规要求？（数据能不能出公司？）

产出物： PRD 文档 + 技术可行性评估报告

Phase 2：方案设计

核心决策：

决策项	选项	选择依据
模型选型	GPT-4 / Claude / 通义千问 / DeepSeek	能力、成本、延迟、合规
技术路线	RAG / 微调 / 提示词工程	数据量、时效性要求
开发框架	LangChain / Dify / 自研	团队技术栈、项目复杂度
部署方式	公有云 API / 私有化部署	数据安全要求

产出物： 技术方案文档 + 架构图

Phase 3：数据准备

收集和清洗原始数据
文档分块、向量化
构建知识库（向量数据库）
准备测试集（覆盖各种场景）

经验之谈： 数据质量决定 AI 应用的天花板。Garbage in, garbage out。

Phase 4：应用开发

Prompt 设计和优化
RAG 流程搭建
Agent 工作流编排
工具开发（API 接口、数据库查询等）

Phase 5：测试评估

测试类型	方法
功能测试	各种输入场景跑一遍
准确率测试	用标注好的测试集评估
边界测试	极端输入、恶意输入
性能测试	并发、延迟、吞吐量
安全测试	Prompt 注入、数据泄露

评估指标：

回答准确率
检索召回率（RAG 场景）
平均响应时间
Token 消耗量（成本）
用户满意度

Phase 6：部署上线

容器化部署（Docker + K8s）
监控告警（响应时间、错误率、资源占用）
灰度发布（先给 10% 用户使用）
回滚方案

Phase 7：持续优化

收集用户反馈
分析 bad case
迭代 Prompt / RAG 策略
定期更新知识库

十、实战案例：AI 驱动财务数据开发提效

好了，前面把概念和流程都讲透了。现在上硬菜——一个完整的实战案例，从业务需求到代码落地的全流程。

10.1 项目背景

在一家做财务 SaaS 产品的公司，数据团队的核心工作是根据产品需求写 SQL 开发财务数据报表。典型的工作流是这样的：

产品经理在飞书上丢过来一个 PRD（产品需求文档），里面写"需要新增一个应收账款账龄分析报表"
数据开发同学看完 PRD，还得反复确认：账龄按什么维度分段？"应收账款"在数仓里对应哪张表哪个字段？口径是什么？
确认完需求，开始翻数仓文档找表 → 写 SQL → 自测 → 提测 → 发现口径不对 → 返工
一个中等复杂度的报表，平均要 3-5 天才能上线

痛点：

PRD 里的业务语言（“应收账款”）和数仓里的技术字段（ar_balance_amt）对应关系混乱，新人上手慢
每次写 SQL 都要翻一遍数仓规范文档，看字段命名、表关联关系、计算口径
同样的逻辑（比如"取最新有效版本"）在每个 SQL 里重复写，容易出错
测试用例靠人工想，覆盖不全，上线后才发现边界情况

目标： 用 AI 把"PRD → 整理后的需求 → Design Doc → SQL 代码 → 测试用例"这个流程自动化掉 70%，让开发同学从"写代码"变成"审代码"。

10.2 整体流程设计

核心思路： 不是让 AI 一步到位生成最终 SQL，而是分阶段、每步有明确输入输出，人工在每个节点 Review，确保质量可控。

10.3 阶段一：PRD 整理 Agent

产品经理写的 PRD 通常比较口语化，信息也不完整。第一步是让 AI 把 PRD "翻译"成结构化的需求文档。

原始 PRD 示例：

【需求标题】应收账款账龄分析报表

【需求描述】
财务同学需要看到客户的应收账款按照账龄分段的情况，
要能看出哪些客户的账款快到期了，重点关注 90 天以上的。

【展示字段】
- 客户名称
- 账款金额
- 账龄（0-30天、31-60天、61-90天、90天以上）
- 账龄占比

【筛选条件】
- 可以按事业部筛选
- 可以按客户类型筛选
- 默认看最近一个账期的数据

PRD 整理 Agent 的 Prompt：

你是一位资深财务数据分析师，擅长从 PRD 中提取完整的数据需求。
请根据以下 PRD，输出结构化的需求文档，并补全 PRD 中缺失的信息。

【数仓已有信息】
- 客户主数据表：dim_customer（customer_id, customer_name, biz_unit, customer_type）
- 应收账款表：fact_ar_balance（customer_id, ar_amount, due_date, invoice_date, period_id）
- 账期维表：dim_period（period_id, period_name, start_date, end_date）

【输出格式】
1. 报表名称：
2. 业务定义（一段话解释这个报表是做什么的）：
3. 数据来源（需要哪些表，关联条件）：
4. 维度字段（group by 的字段）：
5. 指标字段（select 的字段，含计算逻辑）：
6. 筛选条件（where 条件，含默认值）：
7. 排序规则：
8. 缺失待确认项（PRD 没说明白的，列出来）：

【PRD 内容】
{prd_content}

AI 输出（整理后的结构化需求）：

报表名称: 应收账款账龄分析报表

业务定义: |
  按客户维度汇总应收账款余额，
  按账龄（距到期日天数）分为 0-30天、31-60天、61-90天、90天以上四段，
  用于识别高风险账款和客户信用状况。

数据来源:
  主表: fact_ar_balance（应收账款事实表）
  关联表:
    - dim_customer（客户维表）ON fact_ar_balance.customer_id = dim_customer.customer_id
    - dim_period（账期维表）ON fact_ar_balance.period_id = dim_period.period_id

维度字段:
  - dim_customer.customer_name（客户名称）
  - dim_customer.biz_unit（事业部）
  - dim_customer.customer_type（客户类型）
  - 账龄分段（衍生字段，见指标字段）

指标字段:
  - ar_balance_amt: SUM(fact_ar_balance.ar_amount)（应收账款余额）
  - aging_bucket: |
      CASE
        WHEN DATEDIFF(due_date, CURRENT_DATE) <= 30 THEN '0-30天'
        WHEN DATEDIFF(due_date, CURRENT_DATE) <= 60 THEN '31-60天'
        WHEN DATEDIFF(due_date, CURRENT_DATE) <= 90 THEN '61-90天'
        ELSE '90天以上'
      END
  - aging_pct: ar_balance_amt / SUM(ar_balance_amt) OVER (PARTITION BY customer_name)（账龄占比）

筛选条件:
  - dim_period.period_id = 最新账期（默认值）
  - dim_customer.biz_unit IN (用户选择)（可选）
  - dim_customer.customer_type IN (用户选择)（可选）

排序规则: 按 ar_balance_amt 降序

缺失待确认项:
  - "90天以上"是否包含已逾期和未到期但超过90天的？→ 确认：只统计未到期且在90天范围内的
  - 账龄计算基准用 due_date 还是 invoice_date？→ 确认：用 due_date（到期日）
  - 是否需要显示已全额回款客户的零余额记录？→ 确认：不显示，只保留 ar_amount > 0 的记录

效果： 把一段口语化的 PRD 变成了开发人员能直接看懂的"需求规格书"，还主动发现 PRD 里没说清楚的地方，提前确认，避免返工。

10.4 阶段二：Design Doc 生成 Agent

需求明确了，下一步是出技术设计文档。这个 Agent 的作用是把业务需求翻译成技术方案。

Design Doc Agent 的 Prompt：

你是一位数据仓库架构师，请根据以下结构化需求，
输出详细的技术设计文档（Design Doc）。

【设计要求】
1. 遵循星型模型设计原则
2. 优先使用已有的事实表和维表，避免重复建设
3. 复杂的计算逻辑用 CTE（公用表表达式）分层，每层有注释
4. 所有金额字段统一保留 2 位小数
5. 日期处理使用 DATE() 函数确保类型一致
6. 输出完整的建表语句 + 数据刷新逻辑（INSERT OVERWRITE）

【数仓规范】
- 表命名：rpt_模块_业务_粒度（如 rpt_finance_ar_aging_cust）
- 字段命名：小写下划线，业务前缀（如 ar_xxx 表示应收账款相关）
- 分区字段：dt（日期，yyyyMMdd 格式）
- 所有报表表按 dt 分区

【输出格式】
1. 模型设计（表结构、字段类型、分区策略）
2. 数据血缘（从哪些源表来，经过哪些处理）
3. SQL 伪代码（含详细注释）
4. 刷新策略（全量/增量、调度周期）
5. 风险提示（数据量大不大、有没有慢查询风险）

【结构化需求】
{structured_requirement}

AI 输出（Design Doc 节选）：
具体的design_doc 可以根据公司实际使用模型情况调整，但我在测试过程中发现还是越详细越好，越偏向技术测越好

-- ============================================================
-- Design Doc: 应收账款账龄分析报表
-- 目标表: rpt_finance_ar_aging_cust
-- 作者: AI-Generated (Review by: __待填写__)
-- 日期: 2026-06-09
-- ============================================================

【模型设计】

CREATE TABLE rpt_finance_ar_aging_cust (
    dt                  STRING COMMENT '数据日期, yyyyMMdd',
    customer_id         STRING COMMENT '客户ID',
    customer_name       STRING COMMENT '客户名称',
    biz_unit            STRING COMMENT '事业部',
    customer_type       STRING COMMENT '客户类型',
    aging_bucket        STRING COMMENT '账龄分段: 0-30天/31-60天/61-90天/90天以上',
    ar_balance_amt      DECIMAL(18,2) COMMENT '应收账款余额',
    aging_pct           DECIMAL(5,4) COMMENT '账龄占比(该客户该分段占其总额比例)',
    total_ar_amt        DECIMAL(18,2) COMMENT '客户应收账款合计'
)
COMMENT '应收账款账龄分析报表-客户粒度'
PARTITIONED BY (dt STRING)
STORED AS ORC;

【数据血缘】

fact_ar_balance ──┐
                   ├──[JOIN]──> rpt_finance_ar_aging_cust
dim_customer ────┤    ( customer_id )
                   │
dim_period ──────┘    ( period_id )

【SQL 实现】

WITH ar_base AS (
    -- 第一层：取最新账期的应收账款明细
    SELECT
        a.customer_id,
        a.ar_amount,
        a.due_date,
        b.period_end_date
    FROM fact_ar_balance a
    INNER JOIN dim_period b ON a.period_id = b.period_id
    WHERE a.dt = '${bizdate}'
      AND b.period_end_date = (
          SELECT MAX(period_end_date)
          FROM dim_period
          WHERE period_status = 'closed'
      )
),

ar_with_aging AS (
    -- 第二层：计算账龄分段
    SELECT
        customer_id,
        ar_amount,
        CASE
            WHEN DATEDIFF(due_date, period_end_date) <= 30 THEN '0-30天'
            WHEN DATEDIFF(due_date, period_end_date) <= 60 THEN '31-60天'
            WHEN DATEDIFF(due_date, period_end_date) <= 90 THEN '61-90天'
            ELSE '90天以上'
        END AS aging_bucket
    FROM ar_base
    WHERE ar_amount > 0  -- 排除已清零的账款
)

-- 第三层：汇总输出
INSERT OVERWRITE TABLE rpt_finance_ar_aging_cust
PARTITION (dt = '${bizdate}')
SELECT
    c.customer_id,
    c.customer_name,
    c.biz_unit,
    c.customer_type,
    a.aging_bucket,
    SUM(a.ar_amount) AS ar_balance_amt,
    ROUND(
        SUM(a.ar_amount) / SUM(SUM(a.ar_amount)) OVER (PARTITION BY c.customer_id),
        4
    ) AS aging_pct,
    SUM(SUM(a.ar_amount)) OVER (PARTITION BY c.customer_id) AS total_ar_amt
FROM ar_with_aging a
INNER JOIN dim_customer c ON a.customer_id = c.customer_id
GROUP BY
    c.customer_id,
    c.customer_name,
    c.biz_unit,
    c.customer_type,
    a.aging_bucket;

【刷新策略】
- 调度周期：每日凌晨 2:00（依赖上游 fact_ar_balance 在 1:30 完成）
- 刷新方式：INSERT OVERWRITE 按 dt 分区（T+1）
- 数据保留：最近 90 天分区的数据

【风险提示】
- ⚠️ fact_ar_balance 数据量较大（日增约 500 万条），JOIN dim_customer 时需确保 customer_id 上有索引
- ⚠️ 窗口函数 SUM() OVER() 在大数据量下可能较慢，建议关注执行计划
- ⚠️ 账龄分段逻辑依赖 due_date，需确保该字段无 NULL 值（建议在 ETL 层加校验）

效果： AI 不仅生成了完整的 SQL，还主动做了分层设计（CTE）、加了详细注释、给出了风险提示。开发同学拿到后 Review 一下业务逻辑是否正确即可，不需要从零写。

10.5 阶段三：数仓规范 RAG + 代码生成

这一步是最关键的——确保 AI 生成的 SQL 符合公司数仓规范，而不是胡写。

10.5.1 搭建数仓规范知识库

我们把公司的数仓文档都录入 RAG 知识库：

表目录：每张表的业务含义、主键、分区字段、更新频率
字段词典：每个字段的含义、枚举值、口径定义
命名规范：表怎么命名、字段怎么命名
SQL 规范：CTE 分层要求、注释要求、禁止的写法
口径文档："应收账款"对应哪张表哪个字段、"收入确认"的时点是发货还是签收

10.5.2 代码生成 Agent（结合 RAG）

你是一位严格遵守公司数仓规范的数据开发工程师。
请根据以下 Design Doc 和数仓规范，生成生产级的 SQL 代码。

【相关数仓规范（自动检索）】
{rag_retrieved_rules}

【设计要求】
1. 严格遵循命名规范：表名 rpt_finance_xxx，字段名小写下划线
2. 所有 CTE 加注释说明该层做什么
3. 金额字段用 DECIMAL(18,2)，比例字段用 DECIMAL(5,4)
4. 按 dt 分区，INSERT OVERWRITE 语法
5. 不要 SELECT *，必须显式列出字段
6. JOIN 条件必须包含分区的等值过滤

【Design Doc】
{design_doc}

【输出】
完整的、可直接运行的 SQL 代码

10.5.3 实际生成的代码（可直接运行）

-- ============================================================
-- 报表: 应收账款账龄分析报表
-- 目标表: rpt_finance_ar_aging_cust
-- 开发: AI-Generated
-- Review: __待人工 Review__
-- 调度: 每日 02:00
-- ============================================================

SET hive.exec.dynamic.partition.mode=nonstrict;
SET hive.exec.max.dynamic.partitions=1000;

-- 第一层: 取最新已关账账期的应收账款明细
WITH ar_base AS (
    SELECT
        a.customer_id,
        a.ar_amount,
        a.due_date,
        p.period_end_date
    FROM fact_ar_balance a
    INNER JOIN dim_period p
        ON a.period_id = p.period_id
        AND p.dt = '${bizdate}'           -- 分区裁剪
    WHERE a.dt = '${bizdate}'
      AND p.period_status = 'closed'
      AND p.period_end_date = (
          SELECT MAX(period_end_date)
          FROM dim_period
          WHERE dt = '${bizdate}'
            AND period_status = 'closed'
      )
),

-- 第二层: 计算账龄分段
ar_with_aging AS (
    SELECT
        customer_id,
        ar_amount,
        CASE
            WHEN DATEDIFF(due_date, period_end_date) <= 30
                THEN '0-30天'
            WHEN DATEDIFF(due_date, period_end_date) <= 60
                THEN '31-60天'
            WHEN DATEDIFF(due_date, period_end_date) <= 90
                THEN '61-90天'
            ELSE '90天以上'
        END AS aging_bucket,
        period_end_date
    FROM ar_base
    WHERE ar_amount > 0                     -- 排除已清零账款
      AND due_date IS NOT NULL              -- 数据质量过滤
)

-- 第三层: 关联客户维表并汇总
INSERT OVERWRITE TABLE rpt_finance_ar_aging_cust
PARTITION (dt)
SELECT
    c.customer_id,
    c.customer_name,
    c.biz_unit,
    c.customer_type,
    a.aging_bucket,
    SUM(a.ar_amount)                          AS ar_balance_amt,
    ROUND(
        SUM(a.ar_amount)
        / NULLIF(SUM(SUM(a.ar_amount)) OVER (
            PARTITION BY c.customer_id
        ), 0),
        4
    )                                         AS aging_pct,
    SUM(SUM(a.ar_amount)) OVER (
        PARTITION BY c.customer_id
    )                                         AS total_ar_amt,
    '${bizdate}'                              AS dt
FROM ar_with_aging a
INNER JOIN dim_customer c
    ON a.customer_id = c.customer_id
    AND c.dt = '${bizdate}'                   -- 分区裁剪
GROUP BY
    c.customer_id,
    c.customer_name,
    c.biz_unit,
    c.customer_type,
    a.aging_bucket
-- 数据校验: 过滤空值客户
HAVING c.customer_id IS NOT NULL;

关键点： AI 自动加上了分区裁剪（c.dt = '${bizdate}'）、NULL 保护（NULLIF）、数据质量过滤（due_date IS NOT NULL）、注释——这些都是数仓规范里要求的，AI 从 RAG 检索到了规范并严格执行。

10.6 阶段四：测试用例生成 Agent

代码写完了，测试也不能落下。这个 Agent 自动给生成的 SQL 设计测试用例。

测试用例生成 Agent 的 Prompt：

你是一位数据测试专家，请根据以下 SQL 代码和业务需求，
设计完整的测试用例，覆盖正常场景和边界场景。

【输出格式】
每个测试用例包含：
1. 用例编号和名称
2. 测试目的
3. 构造的测试数据（INSERT 语句）
4. 预期结果
5. 通过标准

【要求】
- 至少覆盖：正常数据、空值、超大金额、账龄边界值（30天/60天/90天）
- 账龄分段的边界值必须每个临界点都有测试
- 包含数据质量检查（如 customer_id 为空的情况）

AI 输出的测试用例（节选）：

测试用例 TC-01: 正常账龄分段计算
  目的: 验证 CASE WHEN 的四个分段逻辑正确
  数据:
    - customer_id: C001, ar_amount: 1000, due_date: 2026-06-08  -- 1天内 → 0-30天
    - customer_id: C001, ar_amount: 2000, due_date: 2026-05-10  -- 30天 → 0-30天
    - customer_id: C001, ar_amount: 3000, due_date: 2026-04-20  -- 50天 → 31-60天
    - customer_id: C001, ar_amount: 4000, due_date: 2026-03-25  -- 76天 → 61-90天
    - customer_id: C001, ar_amount: 5000, due_date: 2026-02-01  -- 128天 → 90天以上
  预期:
    - 0-30天: 3000 (1000+2000)
    - 31-60天: 3000
    - 61-90天: 4000
    - 90天以上: 5000
  通过标准: 四个分段的金额完全匹配

测试用例 TC-02: 账龄边界值验证（关键！）
  目的: 验证 30天/60天/90天 三个临界点的归属
  数据（假设 period_end_date = 2026-06-09）:
    - due_date = 2026-05-10  → DATEDIFF = 30 → 预期: 0-30天
    - due_date = 2026-05-09  → DATEDIFF = 31 → 预期: 31-60天
    - due_date = 2026-04-10  → DATEDIFF = 60 → 预期: 31-60天
    - due_date = 2026-04-09  → DATEDIFF = 61 → 预期: 61-90天
    - due_date = 2026-03-11  → DATEDIFF = 90 → 预期: 61-90天
    - due_date = 2026-03-10  → DATEDIFF = 91 → 预期: 90天以上
  通过标准: 每个临界点的分段归属正确

测试用例 TC-03: ar_amount = 0 的数据过滤
  目的: 验证 WHERE ar_amount > 0 的过滤逻辑
  数据:
    - customer_id: C002, ar_amount: 0, due_date: 2026-03-01
  预期: 该记录不出现在结果中
  通过标准: C002 的任何分段都不出现在结果

测试用例 TC-04: NULL 值处理
  目的: 验证 due_date 为 NULL 时的行为
  数据:
    - customer_id: C003, ar_amount: 1000, due_date: NULL
  预期: 该记录被过滤掉（WHERE due_date IS NOT NULL）
  通过标准: C003 不出现在结果中

测试用例 TC-05: 比例计算验证
  目的: 验证 aging_pct 的和为 100%
  数据:
    - customer_id: C004
      - 0-30天: 1000
      - 31-60天: 2000
      - 90天以上: 3000
  预期:
    - 0-30天: 0.1667 (1000/6000)
    - 31-60天: 0.3333 (2000/6000)
    - 90天以上: 0.5000 (3000/6000)
    - 合计: 1.0000
  通过标准: 单个客户的 aging_pct 之和 = 1

效果： 自动生成 15+ 个测试用例，覆盖了正常场景、边界值、空值、数据质量——测试效率提升 80%，而且不会遗漏边界情况。

10.7 技术架构总览

10.8 落地效果和踩坑

量化效果（理想状态）：
自己测试过程发现：需求理解部分是大头：业务复杂场景，自己修改代码也是需要很长时间，部分逻辑开发人员跟产品面对面都需要聊半天，这种目前别指望AI几分钟就给搞定，如果是简单场景，就是类似指标汇总这种，需求写清楚，他的提效可以达到下列表格的效果。当然这个仅代表我个人目前遇到的情况～

指标	改造前	改造后	提升
需求理解+确认时间	0.5-1 天	2 小时	75%↓
Design Doc 编写时间	0.5 天	5 分钟	97%↓
SQL 开发时间	1-3 天	0.5～1 天（Review 为主）	70%↓
测试用例设计时间	0.5 天	5 分钟	97%↓
返工率（口径不对）	约 30%	约 5%	83%↓
整体交付周期	3-5 天	1-2 天	70%↓

踩坑记录：

坑 1：AI 幻觉——编造不存在的字段

问题：AI 有时会"脑补"一些看起来合理但实际不存在的字段名
解决：RAG 检索真实的表结构注入 Prompt，生成后做字段存在性校验

坑 2：数仓规范更新后 AI 还在用旧规范

问题：数仓改了命名规范，AI 知识库没更新，生成的 SQL 不符合新规
解决：知识库版本化 + 自动同步数仓文档（监听文档变更事件）

坑 3：复杂 SQL 超出模型上下文长度

问题：一个超长的存储过程（2000+ 行），AI 看不全，生成的改造版缺了逻辑
解决：分段处理，用 CTE 模块化，一次处理一个 CTE

坑 4：测试用例在真实数据上跑不过

问题：AI 生成的测试数据在真实数仓环境里执行报错（外键约束、字段类型不匹配）
解决：测试数据生成时校验字段类型和约束，用沙箱环境跑测试

10.9 关键经验总结

分阶段优于一步到位：PRD → 需求 → Design → SQL → 测试，每步人工 Review，质量可控
RAG 是质量保证的核心：没有数仓规范知识库，AI 生成的 SQL 就是"野路子"
AI 写初稿，人做 Review：不要指望 AI 一次写对，让 AI 做"草稿"，人做"把关"
测试用例自动生成是隐藏宝藏：覆盖边界情况的能力比人强得多
知识库要持续维护：数仓规范变了，RAG 知识库必须同步更新

十一、写在最后：给不同阶段同学的建议

如果你是计算机小白/产品/运营：

先学会写好 Prompt。这是门槛最低、见效最快的技能。
体验 Dify/Coze。不用写代码就能搭出实用的 AI 应用。
理解 RAG 的概念。知道"先查资料再回答"这个逻辑就够了。
大胆把 AI 用到工作中。写周报、做数据分析、做竞品调研，都能提效。

如果你是开发工程师（前后端/数据）：

学 LangChain / LangGraph。这是 AI 应用开发的主流框架。
深入理解 Agent 的设计模式。ReAct、Plan-and-Execute、多 Agent 协作。
掌握 RAG 的完整流程。文档加载、分块、向量化、检索、生成，每个环节都要了解。
关注 MCP 生态。这是未来 AI 工具连接的标准。
动手做一个项目。比如智能客服、文档问答、数据分析助手。

如果你是技术负责人/架构师：

建立团队的 AI 开发规范。Prompt 管理、版本控制、测试流程、安全准则。
选择合适的模型和框架。不是越贵越好，适合业务场景的才是最好的。
重视数据安全和合规。数据脱敏、权限控制、审计日志，一样不能少。
从业务价值出发。AI 不是炫技，要能解决实际问题、产生可衡量的价值。

附录：核心概念速查表

概念	一句话解释	类比
Prompt	你跟 AI 说的话	口头指令
Skill	AI 的收藏菜单	外卖偏好设置
Agent	能自主完成任务的 AI	能干活的助理
RAG	先查资料再回答	开卷考试
MCP	AI 连接工具的标准协议	翻译官
LangChain	AI 应用开发框架	脚手架
LangGraph	用图编排 AI 工作流	流程引擎
Workflow	可视化/配置化的流程编排	工厂总控流水线
Chain	代码层面的操作串联管道	流水线的机械臂
NL2SQL	自然语言转 SQL	翻译官
Embedding	把文字转为数字向量	翻译机
向量数据库	存储和检索向量数据	智能图书馆
Function Calling	大模型调用外部函数	遥控器
ReAct	思考-行动-反思循环	复盘工作法

结语

写这篇文章花了我整整一周时间，从概念梳理到实战案例，从架构图到代码示例，力求做到小白能看懂、老手能参考。

AI 领域的变化速度超乎想象，今天写的技术栈可能两月后就会更新。但无论技术怎么变，底层的思维方式是不变的——理解 Agent 的"感知-规划-执行-反思"闭环、掌握 RAG 的"先检索再生成"逻辑、明白 Skill 是"把重复工作自动化"的思想。

把这些理解透了，新工具出来你上手会非常快。

最后，如果你有任何问题，欢迎在评论区留言。如果觉得有用，点赞 + 收藏 + 关注，是我继续输出内容的动力！

AtomGit开源社区

AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。

更多推荐

G-Star 精选开源项目推荐｜第二十二期

AtomGit开源社区

CANN 开发者 Meetup · 杭州模型专场｜线下技术沙龙正式开启报名！

AtomGit开源社区

14.4 万奖金！昇腾 Model Agent 模型适配大赛正式起航（第二季）

AtomGit开源社区

所有评论(0)

查看更多评论

zy12345cc

@zy12345cc

已为社区贡献3条内容

【AI 一文入门】从 Prompt 到 Agent，搞懂所有核心概念 + 大数据提效实战

zy12345cc

写在最前面：我为啥要写这篇文章？

目录

一、AI 概念全景图：一张图看清所有名词

二、Prompt 是什么？—— 你跟 AI 说话的"点菜指令"

2.1 一句话定义

2.2 打个比方

2.3 Prompt 的核心技巧

2.4 Prompt 的局限性

三、Skill 是什么？—— AI 的"收藏菜单"

3.1 一句话定义

3.2 打个比方

3.3 Skill 的本质特征

3.4 Skill 是怎么被触发的？

四、Prompt vs Skill：核心区别一张表说清楚

五、Agent（智能体）：让 AI 从"会说话"到"会干活"

5.1 一句话定义

5.2 Agent 和 ChatGPT 有啥区别？

5.3 Agent 的核心工作原理

5.4 ReAct 模式详解

5.5 Agent 的"大脑"组成

5.6 多 Agent 协作

六、RAG（检索增强生成）：给 AI 装上"外部大脑"

6.1 为什么需要 RAG？

6.2 一句话定义

6.3 RAG 工作流程

6.4 用一个例子理解 RAG

6.5 RAG 的核心技术环节

6.6 RAG vs 微调（Fine-tuning）

七、MCP 协议：AI 的"万能 USB 接口"

7.1 一句话定义

7.2 MCP 解决了什么问题？

7.3 MCP 的核心架构

7.4 MCP 能做什么？

7.5 MCP 和 Function Calling 的区别

八、LangChain / LangGraph：AI 开发的"脚手架"

8.1 LangChain 是什么？

8.2 LangGraph 是什么？

8.3 LangChain vs LangGraph

8.4 Dify / Coze：低代码平台

8.5 Workflow vs Chain vs Skill：日常开发到底用哪个？

一句话区分

详细解释

日常开发怎么选？

九、规范 AI 开发流程：从需求到上线的正确姿势

Phase 1：需求分析（最重要！最容易被忽略！）

Phase 2：方案设计

Phase 3：数据准备

Phase 4：应用开发

Phase 5：测试评估

Phase 6：部署上线

Phase 7：持续优化

十、实战案例：AI 驱动财务数据开发提效

10.1 项目背景

10.2 整体流程设计

10.3 阶段一：PRD 整理 Agent

10.4 阶段二：Design Doc 生成 Agent

10.5 阶段三：数仓规范 RAG + 代码生成

10.5.1 搭建数仓规范知识库

10.5.2 代码生成 Agent（结合 RAG）

10.5.3 实际生成的代码（可直接运行）

10.6 阶段四：测试用例生成 Agent

10.7 技术架构总览

10.8 落地效果和踩坑

10.9 关键经验总结

十一、写在最后：给不同阶段同学的建议

如果你是计算机小白/产品/运营：

如果你是开发工程师（前后端/数据）：

如果你是技术负责人/架构师：

推荐学习路线

附录：核心概念速查表

结语

所有评论(0)

温馨提示：您尚未绑定手机号

zy12345cc