前言FDE系列内容总纲【大纲】FDE 前沿部署工程师学习系列教程-CSDN博客前置课程列表见文档结尾附录。阶段3·Day 53结构化输出 — 让模型的回答能进数据库FDE 学习系列教程 · 第三阶段 · 第 7 周 · Day 3预计时长3 小时 | 难度★★★☆☆ | 前置知识Day 51API 调用、Day 52System Prompt、Pydantic 模型第二阶段 Day 29对标大纲课时3.1.3一句话目标让模型稳定输出 JSON用 Pydantic 校验不合格自动重试——打通自然语言 → 结构化字段 → 工单表的最后一公里。‍‍ 开场昨天输出的是一个词今天要的是一行记录昨天Day 52你的分类器已经能吐出机械安全这样的标签。但回到工单系统的真实需求——创建一条工单要填什么# 第二阶段 Day 50 里创建工单要传的是这样的东西 { title: A3注塑机液压油管漏油, device_id: A3, category: 机械, priority: high, summary: 油管接头泄漏已停机需更换密封圈, }也就是说模型光说机械是不够的你得拿到一整行可以直接插进 MySQL 的字段。昨天 A3注塑机漏油停机了快点来人 ──► 机械 一个标签 今天 A3注塑机漏油停机了快点来人 ──► {title, device_id, priority, summary} └── 直接 model_dump() 入库今天给工单系统加的能力一个extract_ticket()函数——输入一句自然语言报修输出一个经过校验的 Pydantic 对象。周五做巡检报告生成器时它俩会合体成智能工单助手 v0.1。这块要拐个弯JSON mode → Pydantic → 重试循环但拆开看每一步都不复杂。跟紧节奏跑不通的地方对照第七节的排查表。 一、为什么模型输出会不稳四种典型翻车你可能会想不就是在 Prompt 里写请输出 JSON吗——写了一样会翻车而且翻车方式很固定❌ 好的这是结果{device:A3} ← 前面加废话人看着没问题json.loads 直接崩 ❌ json\n{...}\n ← 包一层 Markdown 代码块程序解析不了 ❌ {priority: 紧急} ← 枚举值乱填数据库只认 low/medium/high ❌ {device: A3 ← JSON 缺一半被 max_tokens 截断根因一句话模型生成的是概率文本不是契约数据。它是在预测下一个字最可能是什么不是在填表。三道防线第一道JSON mode → 强制整体输出必须是合法 JSON解决 ①② 第二道Schema 校验 → 字段齐不齐、枚举对不对、类型对不对解决 ③ 第三道校验失败自动重试 → 把错误原因告诉模型让它自己改解决偶发失误 外加max_tokens 留足 → 防止④截断防线解决什么不解决什么JSON mode输出必须是合法 JSON不管内容对不对字段可以全错但 JSON 合法Pydantic Schema字段类型/枚举/长度/正则不管语义对不对设备 A3填成A3注塑机它也认重试偶发抖动不解决系统性错误Prompt 写错了重试 10 次也错人工兜底重试 N 次仍失败必留记录日志、转人工、或返回需人工确认⚠️别迷信任何一道防线。生产系统的正确姿势是纵深防御 人工兜底三次都失败就落一条待人工处理的记录而不是让整个流程卡死。 二、JSON mode第一道防线怎么用用法就一个参数response_format{type: json_object}开了它模型被约束为整个输出就是一个 JSON 对象——不会再有前缀废话也不会包 Markdown 代码块。硬性条件各主流平台通用约定开了json_object后Prompt一般指 system 或 user 消息里必须出现 JSON 字样否则接口可能直接报错。这不是玄学是平台的校验规则。所以写 Prompt 时养成习惯明确写出只输出 JSON 对象。三个配套动作动作为什么system 里给出字段名、类型、取值范围、示例模型知道目标长啥样乱填概率大幅下降temperature0降低枚举值乱填的概率max_tokens留足JSON 被截断 前功尽弃宁可多给 200️ 三、实操三道防线一步步搭起来实操步骤 1JSON mode 初体验新建day53_json_mode.py第一道防线response_formatjson_object import os, json from dotenv import load_dotenv from openai import OpenAI load_dotenv() client OpenAI(api_keyos.getenv(DEEPSEEK_API_KEY), base_urlhttps://api.deepseek.com) SYSTEM 你是工单信息提取器。从用户的报修描述中提取结构化信息只输出 JSON。 字段 - title: 字符串工单标题10~30字 - device_id: 字符串设备编号描述中未出现时填 null - priority: 只能是 low / medium / high 之一 - summary: 字符串一句话摘要不超过40字 判断规则涉及安全、停机、泄漏的为 high不影响生产的为 low其余 medium。 text 3号注塑机A3液压油管漏了一地油机器已经停了赶紧来人 resp client.chat.completions.create( modeldeepseek-chat, messages[{role: system, content: SYSTEM}, {role: user, content: text}], temperature0, response_format{type: json_object}, # ★ 第一道防线 max_tokens400, ) raw resp.choices[0].message.content print(raw) print(type(json.loads(raw))) # class dict —— 干净的 dict运行后你会看到类似{title:A3注塑机液压油管漏油,device_id:A3,priority:high,summary:油管接头处严重漏油设备已停机待修}观察点把response_format那行注释掉再跑一次对比输出的差别——大概率会冒出好的以下是提取结果这类前缀。这就是第一道防线的价值。实操步骤 2Pydantic 定义 Schema 并校验第二道防线JSON 合法 ≠ 内容正确。用第二阶段 Day 29 学过的 Pydantic 给它立合同。新建day53_schema.py第二道防线Pydantic 定义输出契约 import os, json from typing import Literal from dotenv import load_dotenv from pydantic import BaseModel, Field, ValidationError from openai import OpenAI load_dotenv() client OpenAI(api_keyos.getenv(DEEPSEEK_API_KEY), base_urlhttps://api.deepseek.com) class TicketExtract(BaseModel): 工单提取结果的合同——模型输出必须长这样 title: str Field(min_length4, max_length40) device_id: str | None Field(defaultNone, patternr^[A-Z]\d$|^$) priority: Literal[low, medium, high] summary: str Field(max_length60) SYSTEM 你是工单信息提取器只输出 JSON 对象不要输出任何其他文字。 schema: - title: str, 4~40字 - device_id: str|null, 形如 A3、B12 的编号没有则 null - priority: low|medium|high安全/停机/泄漏high不影响生产low其余medium - summary: str, 40字以内 def extract_once(text: str) - TicketExtract: resp client.chat.completions.create( modeldeepseek-chat, messages[{role: system, content: SYSTEM}, {role: user, content: text}], temperature0, response_format{type: json_object}, max_tokens400, ) data json.loads(resp.choices[0].message.content) return TicketExtract.model_validate(data) # ★ 第二道防线不合规直接抛异常 if __name__ __main__: t extract_once(B12冲压机防护门失灵门没关也能启动太危险了) print(t) print(t.model_dump()) # 可直接入库 / 喂给第二阶段的创建工单接口几个 Pydantic v2 要点第二阶段学过今天正式用在 AI 输出上写法作用class X(BaseModel)定义数据契约Field(min_length..., max_length...)字符串长度约束Field(patternr...)正则约束如设备编号必须形如 A3Literal[low,medium,high]枚举约束填别的直接报错X.model_validate(data)从 dict 校验并构造对象X.model_validate_json(raw)直接从 JSON 字符串校验省一次json.loadsX.model_dump()转回普通 dict用于入库/传参e.errors()校验失败时取结构化错误列表试着把pattern改严格比如要求 8 位编号或输入那台机器又坏了这种没编号的文本观察ValidationError长什么样pydantic_core._pydantic_core.ValidationError: 1 validation error for TicketExtract device_id String should match pattern ^[A-Z]{3}\d{5}$ [typestring_pattern_mismatch, ...] 注意它精确告诉了你哪个字段、违反了什么规则、实际值是什么。这个错误信息不是给程序员看的——它马上要被喂回给模型下一步。实操步骤 3校验失败自动重试第三道防线生产级写法模型偶尔会出错一次失败就抛异常给用户太脆弱。标准做法把校验错误回喂给模型让它修正最多重试 N 次。把下面这段追加到day53_schema.py末尾和TicketExtract、SYSTEM放一起第六节的批量脚本会直接 import 它def extract_with_retry(text: str, max_retry: int 3) - TicketExtract: messages [ {role: system, content: SYSTEM}, {role: user, content: text}, ] for attempt in range(1, max_retry 1): resp client.chat.completions.create( modeldeepseek-chat, messagesmessages, temperature0, response_format{type: json_object}, max_tokens400, ) raw resp.choices[0].message.content try: return TicketExtract.model_validate_json(raw) except ValidationError as e: print(f第 {attempt} 次输出不合规{e}) # 把模型上轮回答和错误原因都喂回去让它自己改 messages.append({role: assistant, content: raw}) messages.append({role: user, content: f你上次的输出不符合 schema错误{e.errors()}请只输出修正后的 JSON。}) raise RuntimeError(f提取失败已重试 {max_retry} 次{text})这段代码的精妙之处值得拆开看① 用 messages 累积对话模型的错误回答 我的纠错要求构成一次修改意见 ② 错误信息用 e.errors()结构化而不是 str(e)一长串带路径的堆栈 —— 给模型的反馈要短、准、可执行 ③ 循环有上限max_retry任何自动重试都必须有次数上限否则一次异常可能烧掉一笔钱 这个失败 → 把错误反馈回去 → 再来一次的模式第 6 周学 Agent 的 Reflexion 模式时还会见面。思想一脉相承模型能根据反馈自我修正前提是你把反馈讲具体别只说错了要说device_id 字段违反了正则 ^[A-Z]\d$。实操步骤 4对接第二阶段工单 APIAI 与业务系统第一次合体如果你的设备告警工单系统还在跑Day 50 那套让提取结果直接创建工单import httpx ticket extract_with_retry(A3注塑机温度91度报警已停机) resp httpx.post( http://localhost:8000/api/tickets, jsonticket.model_dump(), headers{X-API-Key: fde-secret-2026}, # 第二阶段 Day 46 那把钥匙实际请从环境变量读 timeout10, ) print(resp.status_code, resp.json())自然语言一句人话 ↓ extract_with_retry() Pydantic 对象有类型保证 ↓ .model_dump() JSON符合工单接口 schema ↓ httpx.post() MySQL 工单表真实数据 ↓ 飞书通知 师傅手机收到消息停下来体会 10 秒钟这一段链路就是AI 落地业务系统的最小完整形态。后面无论加 RAG、加 Agent、加 MCP最后一步永远是把模型输出变成系统能消费的东西。⚠️ 服务没起来也别慌把httpx.post(...)换成print(ticket.model_dump())一样能验证链路。联调放最后做别卡在这。 四、结构化输出稳定性 Checklist 速查表以后做任何模型输出结构化数据的功能照这张表逐条打勾措施作用打勾system 里给出字段名、类型、取值范围、示例模型知道目标长啥样☐Prompt 中出现 JSON 字样json_object 模式要求避免接口报错☐temperature0降低乱填枚举值的概率☐response_format{type: json_object}保证是合法 JSON☐Pydantic 正则/枚举/长度约束保证内容符合业务规则☐失败重试 回传e.errors()偶发抖动自动愈合☐重试次数上限 人工兜底不无限烧钱、不卡死流程☐max_tokens留足防止 JSON 被截断☐记录每次调用的原始输出出问题时能复盘☐进阶选学开源库instructorpip install instructor把JSON mode Pydantic 自动重试封装成了一行client.chat.completions.create(response_modelTicketExtract)。建议先按今天的手写版理解原理再用工具提效——不然出问题你连往哪看都不知道。 五、Schema 怎么设计四个决策点定义TicketExtract时每个字段你其实都在做取舍决策点选择理由字段粒度宁少勿多4~8 个字段越多越容易漏、越贵能由程序推导的别让模型填如创建时间类型能用枚举就别用自由文本Literal是稳定性最强的约束可选性拿不到的字段设None默认值强制必填会让模型为凑字段而编造长度给min_length/max_length防一句话变成一篇作文也防标题只有两个字反例一个设计得过重的 Schemaclass BadTicket(BaseModel): title: str device_id: str # 没给 None 默认 → 模型被迫编一个 priority: str # 自由文本 → 会出现紧急Highhigh!!! category: str description: str cause_analysis: str # 让模型顺便做根因分析 → 又慢又不准该用 CoTDay 54 solution: str estimated_hours: float # 模型不擅长估算 → 编数字 created_at: str # 程序自己能生成不该问模型记住两条 ① 让模型干只有它能干的事——理解自然语言 ② 让程序干程序擅长的事——时间戳、ID、计算、查库这个原则在第 6 周做 Agent、第 8 周做工具调用时会反复出现Prompt 里不要塞本该由代码计算的东西。️ 六、实操批量提取 成功率统计单点跑通不算数批量跑才能暴露真实问题。这一步同时也是下周评测集的雏形。实操步骤 1准备一批样本新建day53_batch.py批量提取统计成功率与失败原因Day 56 评测集的雏形 import json from collections import Counter from day53_schema import extract_with_retry, TicketExtract SAMPLES [ 3号注塑机A3液压油管漏了一地油机器已经停了赶紧来人, B12冲压机防护门失灵门没关也能启动太危险了, 配电柜接触器吸合异响偶尔跳闸影响不大有时间再看, 最近产品飞边变多怀疑合模力参数漂移, 空压机气压不足气缸动作慢, 设备坏了快来, # 信息不足 A3和B2都有点问题先修哪个, # 多设备 上周三那台机器的老毛病又犯了, # 指代不清 液压站油温偏高大概85度左右, 急停按钮按下后弹不起来整条线停着, ]实操步骤 2跑批量并收集失败def batch_extract(samples: list[str]) - tuple[list[dict], list[dict]]: ok, failed [], [] for i, text in enumerate(samples, 1): try: t: TicketExtract extract_with_retry(text, max_retry3) ok.append({text: text, **t.model_dump()}) print(f[{i:2}] ✅ {t.priority:6} {t.device_id} | {t.title}) except Exception as e: failed.append({text: text, error: str(e)[:200]}) print(f[{i:2}] ❌ {text} → {str(e)[:80]}) return ok, failed实操步骤 3统计与复盘if __name__ __main__: ok, failed batch_extract(SAMPLES) total len(SAMPLES) print(\n—— 统计 ——) print(f总数 {total} 成功 {len(ok)} 失败 {len(failed)} 成功率 {len(ok)/total:.0%}) print(优先级分布, dict(Counter(r[priority] for r in ok))) if failed: print(失败样本) for f in failed: print( -, f[text], |, f[error][:100]) # 结果落盘便于下周做评测集 with open(day53_batch_result.json, w, encodingutf-8) as fp: json.dump({ok: ok, failed: failed}, fp, ensure_asciiFalse, indent2)观察重点这几条是真实项目里一定会遇到的现象说明应对设备坏了快来 也提取出了设备号模型在编造Prompt 加未明确给出时必须填 null禁止猜测A3和B2都有问题 只提取一个Schema 只支持单设备要么改成list[str]要么 Prompt 声明只取最主要的一台老毛病又犯了 优先级被判 high语义推断过度规则细化只有出现停机/安全/泄漏等明确信号才 high某条跑了 3 次都失败系统性错误不是偶发别加重试次数回去改 Prompt 或放宽 Schema成功率统计是评测驱动迭代的起点。把day53_batch_result.json保存好——Day 56 建评测集时这就是你的第一批标注数据。 七、Pydantic 约束与常见错误速查表常用约束一览约束写法拦住什么字符串长度Field(min_length4, max_length40)太空泛 / 太长正则Field(patternr^[A-Z]\d$)格式不对的设备号枚举Literal[low,medium,high]乱填的优先级数值范围Field(ge0, le200)离谱的温度值可选字段str | None None允许缺失避免模型编造列表长度Field(min_length1, max_length5)空的或过长的数组默认值Field(defaultmedium)缺失时用安全值兜底错误处理速查场景写法说明从 dict 校验TicketExtract.model_validate(data)已经json.loads过从 JSON 字符串校验TicketExtract.model_validate_json(raw)一步到位推荐捕获错误except ValidationError as e:不要用裸except取结构化错误e.errors()回喂给模型的修改意见转 dict 入库t.model_dump()exclude_noneTrue可去掉 None 字段生成 JSON Schema给 Prompt 用TicketExtract.model_json_schema()可直接把 schema 塞进 system减少手写错误最后一条很实用试着打印一下import json print(json.dumps(TicketExtract.model_json_schema(), ensure_asciiFalse, indent2)) 把model_json_schema()的输出直接贴进 System Prompt是代码与 Prompt 同步的小技巧——Schema 改了Prompt 跟着改不会出现两边对不上的情况。第 8 周做 Prompt 模板化时再升级。 本课小结知识点一句话记住结构化必要性程序消费字段不消费一段话四种典型翻车废话前缀 / Markdown 包裹 / 乱填枚举 / 被截断JSON moderesponse_format{type:json_object}强制合法 JSON硬性条件开了 JSON modePrompt 里必须出现 JSON 字样Pydantic用类型/枚举/正则/长度给输出立合同model_validate_json直接从 JSON 字符串校验校验重试错误信息e.errors()回喂模型自我修正必限次数temperature0提取任务稳定性第一防御纵深mode → schema → 重试 → 人工兜底批量统计跑一批才有成功率才有评测集 核心认知大模型的原始输出是概率文本生产系统要的是确定契约。Prompt JSON mode Pydantic 重试这组四件套就是在概率与确定之间架桥。以后你看到任何 AI 产品的智能填表 / 智能解析 / 智能录入底层都是这套东西——差别只在契约设计得严不严、兜底做得实不实。 课后练习练习 1扩字段 — 加两个业务字段约 35 分钟给TicketExtract增加need_shutdown: bool # 是否需要停机维修 suspected_parts: list[str] Field(default_factorylist, max_length5) # 疑似故障部件要求同步更新 System Prompt 的 schema 描述含不需要停机时填 false用 3 条报修文本测试B12冲压机防护门失灵太危险了/液压站油温偏高85度/空压机气压不足观察suspected_parts会不会编出奇怪的部件名如果会在 Prompt 里加只从描述中出现过的部件提取练习 2重试观察实验约 25 分钟临时把设备编号正则改得极严格device_id: str | None Field(defaultNone, patternr^[A-Z]{3}\d{5}$) # 例如必须 AB12345跑extract_with_retry(3号注塑机A3漏油了, max_retry3)把控制台的重试日志完整抄进记录本回答模型第 2 次是怎么改的是照着正则编了一个合规编号还是改成 null还是直接放弃如果它为了通过校验而编造数据这是好事还是坏事你该怎么防止提示在 Prompt 里强调禁止编造并在校验之外加业务规则检查练习 3批量成功率基线约 40 分钟把批量脚本的样本扩到10 条以上必须包含信息不足、多设备、指代不清、正常报修各若干条跑完记录指标数值成功率平均重试次数失败样本的共性用到的总 token累加usage.total_tokens保存day53_batch_result.json。这份东西 Day 56 会直接拿来当评测集用别跑完就删。 下节预告今天你让模型按格式交作业了——JSON Pydantic 重试输出已经能进数据库。但注意今天任务的性质分类、提取都是一步出结果的活。明天的任务不一样A3 机台温度高、压力波动大、昨天刚换过油最可能是什么问题先查什么这需要推理——把线索串起来、排除不可能、给出有顺序的排查路径。你直接问模型容易跳步、拍脑袋。明天Day 54学三套让模型一步步想清楚的方法CoT思维链、Plan-and-Execute先计划后执行、ReAct 雏形。尤其是 ReAct——想 → 做 → 看结果的循环它就是第 6 周 Agent 的内核。明天见附录前置课程列表阶段一认知启蒙AI 认知与 FDE 角色AI 认知【FDE系列】阶段1Day 1AI 层级关系 — 四个嵌套的圈-CSDN博客【FDE系列】阶段1Day 2AI 三阶段发展史 — 会认 → 会判断 → 会创造-CSDN博客【FDE系列】阶段1Day 3符号 AI vs 机器学习 — 两条路线的本质区别-CSDN博客【FDE系列】阶段1Day 4Transformer 的历史意义 — 2017 年的分水岭-CSDN博客【FDE系列】阶段1Day 5本周复习与自测 — 检验你的 AI 认知地基-CSDN博客【FDE系列】阶段1Day 6Transformer 架构 — 一张图纸盖出千千万万栋楼-CSDN博客【FDE系列】阶段1Day 7LLM 本质 — 文字接龙机器-CSDN博客【FDE系列】阶段1Day 8Token — 模型眼中的最小单位-CSDN博客【FDE系列】阶段1Day 9AI 幻觉 — 为什么会一本正经地胡说八道-CSDN博客【FDE系列】阶段1Day 10上下文窗口 — 模型的记忆力上限 本周复习-CSDN博客【FDE系列】阶段1Day 11Prompt — 给模型立规矩-CSDN博客【FDE系列】阶段1Day 12Memory — 让模型记住上下文【FDE系列】阶段1Day 13RAG — 给模型配图书管理员-CSDN博客【FDE系列】阶段1Day 14Tool Use — 让模型动手操作-CSDN博客【FDE系列】阶段1Day 15MCP — 统一的工具接口标准 第三周复习-CSDN博客FDE 基础概念【FDE系列】阶段1Day 16什么是 FDE — 把 AI 变成客户结果的人-CSDN博客【FDE系列】阶段1Day 17FDE vs 传统实施 — 三大本质区别-CSDN博客【FDE系列】阶段1Day 18FDE 三重身份 C6 胜任力模型-CSDN博客【FDE系列】阶段1Day 19七阶段行动路径 行业经验的价值-CSDN博客【FDE系列】阶段1Day 20阶段总结与产出物 — 第一阶段收官-CSDN博客阶段二技术地基Python FastAPI SQL Docker API 集成Python基础【FDE系列】阶段2Day 21Python 环境搭建 — 写出你的第一行代码-CSDN博客【FDE系列】阶段2Day 22变量、数据类型、条件判断 — Python 的“记忆“和“判断“-CSDN博客【FDE系列】阶段2Day 23循环与函数 — 让代码跑 100 遍、把逻辑打包复用-CSDN博客【FDE系列】阶段2Day 24数据结构 — 列表、字典、集合、元组-CSDN博客【FDE系列】阶段2Day 25文件读写与 JSON — 让程序连通外部数据第一周收官-CSDN博客【FDE系列】阶段2Day 26模块化编程 — 把代码拆成“抽屉柜“-CSDN博客【FDE系列】阶段2Day 27异常处理与日志 — 让程序“摔不烂、查得到“-CSDN博客FastAPI入门到进阶【FDE系列】阶段2Day 28FastAPI 入门 — 把你的函数变成 API 服务-CSDN博客【FDE系列】阶段2Day 29FastAPI 进阶 — Pydantic 模型与完整 CRUD 实战-CSDN博客【FDE系列】阶段2Day 30生产代码规范 — 测试、类型注解、配置管理第二周收官-CSDN博客SQL基础【FDE系列】阶段2Day 31SQL 基础 — 增删改查一把梭-CSDN博客【FDE系列】阶段2Day 32多表查询 — JOIN 与聚合-CSDN博客【FDE系列】阶段2Day 33进阶查询 — 窗口函数与 CTE-CSDN博客【FDE系列】阶段2Day 34数据清洗 — 把脏数据捋干净-CSDN博客【FDE系列】阶段2Day 35Python SQL — 工单接入 MySQL 本周收官-CSDN博客Linux基础【FDE系列】阶段2Day 36Linux 入门与文件操作 — 扔掉鼠标的第一天-CSDN博客【FDE系列】阶段2Day 37权限、进程与文本三剑客-CSDN博客【FDE系列】阶段2Day 38Shell 脚本 — 把命令串起来自动跑-CSDN博客【FDE系列】阶段2Day 39Linux 综合实战 — 让服务无人值守-CSDN博客【FDE系列】阶段2Day 40Shell 进阶 — 生产级脚本与本周收官-CSDN博客Docker【FDE系列】阶段2Day 41Docker 入门 — 把环境装进盒子-CSDN博客【FDE系列】阶段2Day 42Dockerfile 实战 — 把你的应用打包成镜像-CSDN博客【FDE系列】阶段2Day 43Docker Compose — 多容器一键编排-CSDN博客【FDE系列】阶段2Day 44Nginx 反向代理 Git 版本控制-CSDN博客【FDE系列】阶段2Day 45综合实战 — Docker Nginx Git 完整部署与本周收官-CSDN博客API 集成与系统对接【FDE系列】阶段2Day 46RESTful 设计与认证授权-CSDN博客【FDE系列】阶段2Day 47对接企业系统 — 飞书 / 钉钉 API-CSDN博客【FDE系列】阶段2Day 48Webhook 处理与数据映射-CSDN博客【FDE系列】阶段2Day 49OpenAPI 文档与接口测试-CSDN博客【FDE系列】阶段2Day 50综合项目 — 设备告警工单闭环系统 第二阶段收官 [特殊字符]-CSDN博客阶段三AI 应用技术含 SDD 方法论AI基础Prompt Engineering 系统训练【FDE系列】阶段3Day 51从聊天窗口到代码 — 跟 LLM 的第一次握手-CSDN博客【FDE系列】阶段3Day 52Prompt 三板斧 — 角色、示例与清晰指令-CSDN博客待完成教程RAG 知识检索系统Agent 框架与开发Tool Calling 与 MCPLLM 推理与部署规范驱动开发与 Agent 工程方法论阶段四平台与交付含 Agent 治理阶段五行业实战与认证