前言FDE系列内容总纲【大纲】FDE 前沿部署工程师学习系列教程-CSDN博客前置课程列表见文档结尾附录。阶段3·Day 54思维链与推理任务 — 让模型一步步想清楚FDE 学习系列教程 · 第三阶段 · 第 7 周 · Day 4预计时长2.5 小时 | 难度★★★☆☆ | 前置知识Day 51-53API 调用、System Prompt、结构化输出对标大纲课时3.1.4一句话目标分清什么任务该快答、什么任务该慢想掌握 CoT、Plan-and-Execute 引导方法并跑通 ReAct 循环雏形Agent 的种子。‍‍ 开场工单建完了然后呢第二阶段的工单闭环系统处理完建单 → 通知 → 接单 → 完工之后还缺一环师傅赶到现场看着一台 91℃ 的注塑机问到底哪儿的毛病这一环过去靠老师傅的经验温度高、水压正常、加热圈刚换过、今天车间 38℃……几条线索在脑子里一过先查什么后查什么门儿清。但你那套系统里没有老师傅。它有的是阈值规则温度 80 → 建工单。它能告诉你坏了不能告诉你为什么坏、先查哪儿。今天给这套系统加的能力故障根因分析助手——输入一组现场线索输出一份有条有理的排查路径。现场线索结构化/半结构化 │ A3 料筒 91℃ / 水压 0.3MPa / 加热圈上周刚换 / 车间 38℃ / 同型号 B3 正常 ▼ 模型按先假设 → 再排除 → 后定论的脚手架思考 │ ▼ ## 可能原因 → ## 逐条排除 → ## 可能性排序 → ## 结论 → ## 排查步骤 → ## 需确认信息和昨天不一样的是昨天的分类/提取是一步出结果今天要的是推理过程。直接问答案模型容易跳步、拍脑袋错了你也不知道它错在哪。这节内容承上启下——CoT 本身好用而最后的 ReAct 循环就是第 6 周 Agent 的思想源头。 一、快答类 vs 推理类先学会分流不是所有任务都该让模型深思熟虑。分错类要么浪费钱要么降低质量。┌──────────────┬────────────────────────────────────────────┐ │ 快答类任务 │ 分类、提取、改写、翻译、摘要、格式转换 │ │别让它多想 │ 要的是确定结果想太多反而节外生枝、更慢更贵 │ ├──────────────┼────────────────────────────────────────────┤ │ 推理类任务 │ 故障诊断、方案比较、数学计算、 │ │要分步 │ 多约束规划、根因分析、影响分析 │ │ │ 直接问答案错误率明显上升 │ └──────────────┴────────────────────────────────────────────┘维度快答类推理类输出形态一个标签 / 几个字段一段分析 结论典型做法Zero-shot / Few-shot JSON modeCoT / Plan-Executetemperature00.2~0.5留一点发散找假设但别飘max_tokens小几十到几百大800~2000成本低高推理是用 token 换准确率失败表现分类错、字段漏跳步、编数据、给错结论⚠️最常见的浪费给工单分类套上 CoT。每条工单多烧 500 token准确率一点没涨——快答类任务滥用 CoT纯粹是给平台送钱。分流是 Prompt 工程的第一步决策。一个判断小技巧问自己如果让人来做这件事他需要打草稿吗 · 看一眼就选机械还是电气 → 不用打草稿 → 快答 · 要列出原因、排除、排序、给步骤 → 要打草稿 → 推理而且要把草稿格式写进 Prompt 二、Chain-of-ThoughtCoT把推理过程显式化CoTChain-of-Thought思维链不神秘就是在 Prompt 里要求模型按步骤分析先给思考再给结论。❌ 普通问法直接要答案现象A3温度91℃冷却水压正常加热圈刚换过环境温度38℃。最可能啥问题 → 模型可能直接蹦一个结论温控表故障。 猜错了你也不知道它凭什么猜的更没法检查它漏了什么。✅ CoT 问法规定步骤 输出结构你是设备故障分析专家。请严格按以下步骤分析最后才给结论 1. 列出所有可能导致超温的原因至少4个 2. 针对每条线索温度/水压/加热圈/环境逐一分析能排除的说明理由 3. 对剩余的可能原因按可能性排序 4. 给出最可能的根因并列出验证它的具体检查动作带顺序 输出格式 ## 可能原因 ## 逐一排除 ## 可能性排序 ## 结论与排查步骤为什么这样就能变好用大白话讲模型是一个字一个字往下写的。 · 直接问它得在第 1 个字就押上结论没有回头路 · 按步骤它先写出假设1、假设2…这些文字随后会成为它自己的上下文 —— 模型看着自己刚写的假设去排除等于有了草稿纸 这就是所谓的让模型用计算步数换准确率。CoT 的四种常见写法写法示例句式适用步骤指令请按 1/2/3/4 步分析最后给结论通用最常用零样本触发句让我们一步一步地思考懒人版效果弱于显式步骤示例示范给一个完整的分析过程 结论范例格式要求高、行业特殊时结构化输出骨架规定 Markdown 小标题报告类场景Day 55 直接用工业级经验给 FDE 用的是步骤指令 结构化骨架组合。既保证思路又保证产出可直接进报告/系统。️ 三、实操故障根因分析助手含直接问 vs CoT 对照实操步骤 1先写直接问的对照组新建day54_direct.py故意的坏例子用来做对照对照组直接问答案不做推理引导 import os from dotenv import load_dotenv from openai import OpenAI load_dotenv() client OpenAI(api_keyos.getenv(DEEPSEEK_API_KEY), base_urlhttps://api.deepseek.com) CASE 故障现象 - A3注塑机料筒温度显示91℃设定80℃持续20分钟 - 冷却水进水压力0.3MPa正常范围 - 加热圈上周刚整体更换 - 今天车间环境温度38℃比平时高8度 - 同型号B3机台温度正常80℃ resp client.chat.completions.create( modeldeepseek-chat, messages[{role: user, content: f{CASE}\n\n最可能是什么问题}], temperature0.3, max_tokens1200, ) print(resp.choices[0].message.content) print(f\n[消耗 {resp.usage.total_tokens} tokens])大概率你会得到一段只有三五句话的回答直接给结论没有排除过程。实操步骤 2写 CoT 版本新建day54_cot.pyCoT 版本规定分析步骤与输出结构 import os 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 你是资深设备故障分析工程师。回答必须遵守 1. 先分析后结论禁止跳过步骤直接下判断 2. 信息不足处明确标注需补充确认不得编造数据 3. 排查步骤必须具体可执行看哪个表、摸哪个管、查哪个参数 4. 涉及安全风险时放在最前面提示 CASE 故障现象 - A3注塑机料筒温度显示91℃设定80℃持续20分钟 - 冷却水进水压力0.3MPa正常范围 - 加热圈上周刚整体更换 - 今天车间环境温度38℃比平时高8度 - 同型号B3机台温度正常80℃ PROMPT 请按以下结构分析 ## 一、可能原因至少列出4个假设 ## 二、逐条验证与排除结合给定线索说明排除或保留理由 ## 三、可能性排序 ## 四、最可能根因 ## 五、现场排查步骤按顺序每条写明检查对象和判定标准 ## 六、需补充确认的信息 故障信息 \\\ %s \\\ % CASE resp client.chat.completions.create( modeldeepseek-chat, messages[{role: system, content: SYSTEM}, {role: user, content: PROMPT}], temperature0.3, # 推理任务可以给一点点发散空间但别太高 max_tokens1200, ) print(resp.choices[0].message.content) print(f[消耗 {resp.usage.total_tokens} tokens])实操步骤 3对照并记录跑两个脚本把结果整理成这张表写进实验记录本对比项直接问CoT 版给了几个假设通常 1 个结论4 个假设有没有排除过程❌✅ 逐条给理由结论是否可追溯否不知道怎么得出的是能看到推理链排查步骤可执行性笼统具体到摸哪根管、看哪个表是否标注需确认信息容易编造明确列出需补充确认输出 token少明显多适合进系统吗不适合无法校验适合结构固定可解析观察点CoT 版的结论可靠性和步骤可执行性明显强于直接问token 消耗也明显上升——推理是拿 token 换准确率所以快答类任务别滥用 附带好处CoT 的输出是可以检查的。哪一步排除错了你能一眼看出来——这对 FDE 至关重要你不能把无法验证的黑箱结论交给客户。一个重要的安全约束禁止编造注意 SYSTEM 里第 2 条信息不足处明确标注需补充确认不得编造数据。这一条必须写。不写会怎样 模型会合理补全你没给油温它可能写油温约65℃属正常范围—— 一个看起来很专业、实际是编的数字。 在故障排查场景编造的数据比不回答危险得多 师傅拿着假的水压正常去排除会漏掉真正的根因。 四、CoT 写法速查表要素写法要点反例角色资深设备故障分析工程师你是一个 AI步骤编号列出 3~6 步顺序符合专家思路好好分析一下输出骨架规定 Markdown 小标题不规定每次格式都不一样防编造信息不足标需补充确认不得编造不提模型会补全可执行性写明检查对象和判定标准给出建议安全涉及安全风险放在最前不提温度0.2~0.50假设太少/ 1.5跑题max_tokens800~2000报告类200写到一半截断万能 CoT 骨架直接抄【角色】你是 {领域} 专家。 【任务】基于以下信息分析 {问题}。 【步骤】 1. 列出所有可能原因至少 N 个 2. 结合给定信息逐条验证能排除的说明理由 3. 对保留项按可能性排序 4. 给出结论 可执行的验证/处置步骤带顺序 5. 列出需补充确认的信息 【规则】信息不足处标需补充确认严禁编造未提供的数据 【输出格式】## 一、… ## 二、… ## 三、… ## 四、… ## 五、… 【输入】 {输入内容} 这个骨架迁移性极强把设备故障换成IT 系统告警产品质量异常客户投诉归因结构完全通用。练习 2 就干这个。 五、Plan-and-Execute复杂任务先出计划再干活当任务是多步骤动作要真去改数据、发通知、调接口而不是分析一道题时先让模型出一份计划人确认后再执行比让它边想边做可控得多。用户把本月所有高温告警整理成报告标出重复报警的设备发飞书通知对应负责人 ❌ 差的做法模型一上来就执行 → 可能漏步骤、可能顺序错、可能把通知先发了报告还没写 ✅ 好的做法 第一步计划让模型输出执行计划 1. 查询本月 temperature80 的工单 2. 按 device_id 聚合计数 3. 筛选 count2 的设备 4. 生成报告草稿 5. 【需人工确认】再发飞书 第二步人确认/修改计划 第三步按计划逐步执行第 6 周 Agent 自动化这段对照你第二阶段的工单系统这个计划其实你早就在代码里写了——只不过那时是你自己写的第二阶段告警 → 建单 → 通知 → Webhook 改状态 流程由你用代码写死 第三阶段让模型读一句自然语言 → 自己排出流程步骤 流程由模型生成人审核今天先用纯文本体验先计划PLAN_SYSTEM 你是运维自动化规划师。只输出编号步骤计划标注哪些步骤有风险需要人工确认。 plan client.chat.completions.create( modeldeepseek-chat, messages[{role: system, content: PLAN_SYSTEM}, {role: user, content: 任务分析本周重复高温告警设备并通知负责人}], temperature0, ) print(plan.choices[0].message.content)你会拿到类似这样的计划1. 从工单库查询本周 temperature 80 的全部工单记录 2. 按 device_id 聚合统计每台设备的告警次数 3. 筛选告警次数 2 的设备作为重复报警对象 4. 【风险·需人工确认】向对应负责人发送飞书通知 5. 生成《本周重复高温告警设备报告》并归档 注意第 4 步前面的标记——动作类步骤发通知、改数据、删东西必须标需人工确认。这是 AI 系统区别于脚本的关键不可逆动作留一道人卡。第 6 周做 Agent 时会专门实现人工审批节点今天先把这个意识种下。 同一个思想Day 93 的 Spec-Kit、Day 94 的 Cline Plan 模式还会再见一次。记住先计划、后执行、高风险要人批——这是所有 AI 自动化系统的安全底线。️ 六、实操ReAct 雏形 — 想 → 做 → 看今天最后埋一颗种子。ReAct Reason想 Act做 Observe看结果循环┌─────► 想Reason现在该干什么 │ │ │ ▼ │ 做Act调用一个工具查工单/查手册/算数 │ │ │ ▼ │ 看Observe工具返回了什么 │ │ └────── 还没完继续想下一步…… │ ▼ 信息够了 → 输出最终答案实操步骤 1准备假工具今天不用任何框架用文字角色扮演感受这个循环——工具由我们先假扮。新建day54_react_taster.pyReAct 雏形模型在文本里走 想→做→看 流程工具由代码假扮 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) # 假扮的工具库第 6 周会换成真实函数查 MySQL / 查向量库 / 调 API FAKE_TOOLS { query_tickets: [{id:101,device:A3,temp:91},{id:108,device:A3,temp:88}], } SYSTEM 你可以使用工具 query_tickets查询本周高温工单。 每轮严格只输出一个 JSON - 需要调工具时{thought:..., action:query_tickets} - 信息足够给结论时{thought:..., answer:最终答案} 不要输出 JSON 以外的内容。实操步骤 2跑循环messages [{role: system, content: SYSTEM}, {role: user, content: 本周哪台设备重复高温报警几次}] for step in range(4): # 循环上限就是保险丝 out client.chat.completions.create( modeldeepseek-chat, messagesmessages, temperature0, response_format{type: json_object}).choices[0].message.content print(模型, out) data json.loads(out) messages.append({role: assistant, content: out}) if answer in data: break action data.get(action) observation FAKE_TOOLS.get(action, 工具不存在) print(工具返回, observation) messages.append({role: user, content: f观察结果{observation}})实操步骤 3观察输出理解每一轮第 1 轮 模型{thought:需要查本周高温工单,action:query_tickets} 工具返回[{id:101,device:A3,temp:91},{id:108,device:A3,temp:88}] 第 2 轮 模型{thought:A3 出现两次信息足够,answer:A3 设备本周重复高温报警 2 次}请特别留意这三个设计点它们在第 6 周会原封不动地出现在真正的 Agent 里设计点今天的做法为什么必须有循环上限for step in range(4)没有上限 可能死循环烧钱输出格式约束JSON mode 只输出一个 JSON程序要能解析是要调工具还是要回答观察结果回灌messages.append({role:user, ...})模型看到工具返回才能继续决策把这段和 Day 51 的模型无状态连起来看 ReAct 循环之所以能工作是因为【你】在每一轮把 模型的想法 工具返回 重新拼进 messages 发过去。 Agent 的全部秘密就是这个 messages 拼接循环 一堆真实工具函数。选学Self-Consistency自洽投票大纲 3.1.4 还提到一个进阶模式Self-Consistency自洽性——同一个问题用较高 temperature 跑 N 次取出现最多的答案。适用有唯一正确答案、但单步容易算错的任务数学、逻辑、计数 代价N 倍成本 工业场景用得少故障诊断没有标准答案可投票了解即可 七、三种推理引导对比速查表模式适用关键动作成本CoT分析/诊断类单轮问题规定分析步骤先推理后结论中一次调用输出长Plan-and-Execute多步骤操作类任务先出计划 → 人确认 → 再执行中两次调用计划 执行ReAct需要边查信息边判断想 → 调工具 → 看结果循环直到完成高多轮调用上下文累积Self-Consistency选学有唯一解的计算/逻辑题跑 N 次取多数很高N 倍怎么选决策树要不要动手改数据/发通知 ├─ 是 → Plan-and-Execute先计划高危步骤标人工确认 └─ 否 → 需不需要外部信息查库/查手册/查接口 ├─ 是 → ReAct边查边判 └─ 否 → 需不需要推理过程 ├─ 是 → CoT └─ 否 → 快答Zero/Few-shot JSON modeDay 52-53 把这张决策树抄进你的实验记录本。它会一直用到第 6 周做 Agent——Agent 不是万能药能用 CoT 一次解决的别上循环。 本课小结知识点一句话记住任务分流快答别多想推理才分步CoT规定步骤结构让推理外显、可检查为什么有效模型看着自己写的草稿继续推用步数换准确率防编造信息不足标需确认不许编数据成本推理用更多 token 换准确率快答类别滥用Plan-Execute复杂动作先计划后执行高危动作要人工确认ReAct想 → 做 → 看的循环Agent 的内核循环上限任何自动循环都要有最大轮数费用保险丝输出约束ReAct 每轮只输出一个 JSON程序才能解析决策顺序快答 CoT Plan-Execute ReAct能用轻的别用重的 核心认知模型的智能不是开关是可以被流程设计引导出来的。你把专家解决问题的方法论先假设、再排除、后定论写进 Prompt模型就按专家的路子走。FDE 的行业经验在 AI 时代最值钱的用法之一就是沉淀成这些思考脚手架——你脑子里有流程模型才能跑出流程。 课后练习练习 1直接问 vs CoT 盲评对照约 35 分钟用同一个故障案例分别跑day54_direct.py和day54_cot.py保存两份输出。把两份输出的模型名/来源信息抹掉编号 A、B找一位同事或让另一个会话的模型盲评哪份更靠谱为什么记录评价理由填进下表评价维度AB胜出结论可信度步骤可执行性是否暴露了不确定信息做盲评是为了去掉我知道哪份是 CoT的心理偏差。评测要盲优化才有效——这也是 Day 56 评测方法论的起点。练习 2把 CoT 骨架迁移到另一个行业约 30 分钟把第四节的万能 CoT 骨架复制到你的领域餐饮后厨设备、IT 运维、医疗设备、物流分拣任选一个改写角色、步骤和输出小标题跑一个真实案例。验收标准至少列出 4 个假设每一条排除都有依据哪条线索至少 1 条需补充确认排查步骤能落到看什么/摸哪里/查哪个参数写下一句结论骨架的哪些部分是通用的哪些必须行业定制练习 3给 ReAct 加第二个工具约 30 分钟在FAKE_TOOLS里加一个query_manualFAKE_TOOLS { query_tickets: [{id:101,device:A3,temp:91},{id:108,device:A3,temp:88}], query_manual: A3 料筒温度设定范围 60~85℃超温首要检查冷却水路与固态继电器, }同时把 SYSTEM 里的工具说明改成可用工具query_tickets查工单、query_manual查设备手册然后把问题改成本周重复高温报警的设备按手册该怎么处理观察模型会不会自主决定查完工单还要查手册看它是否发起第二次 action把循环上限range(4)改成range(2)再跑一次看会不会因为轮次不够而答不完整——体会循环上限的双刃剑 下节预告今天你学会了让模型想清楚再说。但到目前为止模型产出的内容都还停留在终端打印里——没落盘、没进系统、没有版本管理。明天Day 55是本周收官我们把四天所学组装成一个真用得起来的东西建smart_assistant/包把四天的零散脚本收敛成llm.py统一调用、extractor.py工单提取、reporter.py报告生成把 Prompt 从代码里抽出来变成prompts/*.v1.txt文件带版本号管理做出巡检报告生成器输入几条巡检记录温度、振动输出带异常识别、风险分级、处置建议的 Markdown 报告用边界输入空数据、缺读数、异常值逼出 Prompt 漏洞迭代出 v2做完这个你的智能工单助手 v0.1就有两大件了工单提取Day 53 巡检报告Day 55。明天见附录前置课程列表阶段一认知启蒙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博客【FDE系列】阶段3Day 53结构化输出 — 让模型的回答能进数据库-CSDN博客待完成教程RAG 知识检索系统Agent 框架与开发Tool Calling 与 MCPLLM 推理与部署规范驱动开发与 Agent 工程方法论阶段四平台与交付含 Agent 治理阶段五行业实战与认证