从大模型到Agent：核心概念与AI应用落地全解析-北京尧图网络

1. 国庆第1天搭好世界观——大模型、token 与训练推理1.1 大模型到底“大”在哪里参数量的意义先说一个我经常在群里被问到的问题“大模型是不是就是把很多文章塞进电脑里然后你说一句它回一句”这个理解方向是对的但离真相还差一个关键概念——参数量。所谓参数量你可以把它想成模型脑子里“可调节旋钮”的数量。7B、70B、671B 这些数字指的是模型拥有几十亿到几千亿个这样的旋钮。训练的过程就是拿着海量文本一遍遍调整这些旋钮让模型面对“用户说了前半句后半句最可能是什么”这个问题时预测得越来越准。一个 7B 模型拥有的旋钮大概相当于你办公桌上翻不完的几十本技术手册而一个 600B 级别的模型基本就是一座小型图书馆。旋钮越多模型能记住的“常识模式”越丰富但代价也很直接训练成本、推理延迟、显存占用全部跟着膨胀。这里有个常见的误解模型不是“记住了文章原文”而是“从文章里提炼出了统计规律”。所以它才能回答“给代码起个变量名”这种它没见过的具体问题也能在你给的一段特殊文本里模仿出风格。理解这一点你就不会再问“为什么模型不能保证 100% 准确”这种问题了——它不是数据库它是一台规律推理机。1.2 训练、微调与推理三个环节千万别混淆很多技术人看 AI 资料时总是被“预训练”“微调”“推理”三个词绕晕。我建议你把它们想成“上大学”和“上岗工作”的关系预训练Pre-training花大量算力让模型读遍互联网级别的文本获得通用语言能力和基础知识。成本最高普通团队基本不碰。微调Fine-tuning基于预训练好的底座用特定领域的数据做“岗前培训”让模型更懂某一类任务比如让模型从“什么都聊”变成“专门帮你写 SQL 的助手”。推理Inference模型真正上岗接收用户输入逐词生成回答的过程。这是你日常调用 API 时实际发生的环节。把这三个环节分清后很多概念就能自动归位了。比如“LoRA”“Q-LoRA”这类词本质上是微调阶段的低成本技巧——只调整一部分旋钮而不是全部重训就像给资深员工做一次短期专项培训不用重新上大学。“GGUF”“量化”则属于推理阶段的优化手段讨论的是如何让模型在上岗时跑得更快、吃更少内存。1.3 token、上下文与幻觉评价模型的基本功聊 AI 绕不开的一个基础单位叫 token。你可以把它理解成“模型眼里的字词碎片”。中文里一个 token 可能是一个字、一个词甚至是一个标点英文里可能是一个单词的一部分。模型一次能处理的 token 数量就是“上下文窗口”——窗口越大它能一次读完的文章越长。“幻觉”这个词现在大家应该都听过了指模型一本正经地编造不存在的事实。它本质上是因为模型在做概率预测而不是查证事实。技术人在设计 AI 产品时永远要假设模型会犯错所以才会引出后面讲到的 RAG、工具调用、人工审核兜底等手段。这也是为什么我说第1天只需要把“模型是猜下一个词概率的机器”这句话刻在脑子里后面所有概念都有了锚点。2. 国庆第2天学会对话——提示词、上下文窗口与 RAG2.1 提示词工程不是“念咒语”是写需求文档“提示词工程”这几年被讲得神乎其神甚至有人把它包装成“魔法咒语”。我的看法比较朴素提示词的本质是把你对任务的完整需求用模型最容易理解的方式写清楚。你给实习生布置任务时只说“写个方案”和说“你是技术方案架构师请针对一个 50 人的内部 AI 知识库项目输出包含预算、里程碑、技术选型的三页方案用 Markdown 格式关键假设单独列一节”得到的结果能一样吗提示词工程就是这个逻辑。具体到实操层面有几个技巧是验证过非常有效的给模型一个角色和背景“你是一名熟悉 Spring Boot 的 Java 工程师”会比直接提问得到更贴合语境的回答。把关键约束写进去输出格式、受众、篇幅、禁忌越是硬性要求越要写清楚。用少样本示例Few-shot给模型一两个输入输出的范例它会立刻模仿你的格式这比你把格式要求用文字描述五遍还管用。还有一个经常被提到的高级技巧叫作思维链Chain-of-Thought本质是鼓励模型“分步思考”再给出答案。它对数学题、逻辑推理类任务特别有效原理是让模型把中间推理过程显式地写出来降低跳步出错的概率。你可以在提示词里直接加一句“请先列出你的分析步骤再给出最终结论”效果立竿见影。2.2 上下文窗口的真相不是越大越好现在很多模型动辄宣传“百万级上下文窗口”听起来很厉害意思是你能把一本几百页的书直接丢给它。但实际用下来你会发现几个问题第一窗口拉长后模型对中间内容的注意力会稀释开头和结尾被记住的概率远高于中段这就叫“Lost in the Middle”第二超长上下文的处理速度和成本都会显著上升。所以负责任的做法是不要盲目贪大而是学会“只给模型必要信息”。我见过不少团队做 AI 应用时把一堆历史文档全部塞进提示词里结果回答质量反而下降、费用却涨了不少。更好的方案是结合向量检索先找出和当前问题最相关的 3-5 段内容再喂给模型这就是 RAG 的核心思路。2.3 RAG让模型学会“查资料”而不是“瞎编”RAG 全称是 Retrieval-Augmented Generation检索增强生成是目前企业落地 AI 应用时最常用、最稳妥的技术方案之一。它的原理非常简单模型回答问题前先去外部知识库比如公司内部文档库、专业数据库里检索相关内容把检索结果连同用户问题一起作为输入再让模型基于这些素材生成答案。一个生活化类比是这样的你让一个刚入职的实习生直接回答客户的专业问题他很可能答错或者支支吾吾。但如果允许他先翻公司知识库找到相关制度或案例再照着整理一份答复正确率会高得多。RAG 就是给模型配了一个“可以查资料的助手”。它没有改变模型的参数却有效缓解了幻觉问题也让回答能够引用具体来源。这也是为什么我建议所有刚接触 AI 工程的人第一个亲手实现的项目选 RAG而不是一上来就搞训练。成本低、见效快、能直观感受到“搜索引擎大模型”的组合拳有多强。3. 国庆第3天搞懂 Agent 与多 AI 协作——AI 从“问答”进化到“干活”3.1 Agent 到底是什么记忆、规划、工具一个都不能少你在网上会看到各种 Agent 的定义有的说得很玄乎。如果非要我用一句技术人听得懂的话来概括Agent 就是“让大模型不只是输出文字而是能根据目标制定计划、调用外部工具、根据结果迭代调整”的程序系统。拆开来看一个完整的 Agent 系统通常包含四块大模型底座负责理解任务、做决策、生成中间步骤。规划能力把一个大目标拆解成若干个可执行的小步骤。比如“帮我调研一下竞品”它不会直接写一段报告而是先规划“搜索竞品信息→整理产品定位→分析优劣势→生成对比表格”。工具调用通过 API 去访问搜索引擎、数据库、代码执行环境、第三方应用。这是 Agent 和普通聊天机器人最本质的区别——聊天机器人只会说Agent 会做事。记忆包括短期记忆当前任务上下文和长期记忆用户偏好、历史行为通常存在向量数据库或外部存储里。我实操过的最简单一个 Agent 案例是“客服助手”用户问“我的订单到哪了”Agent 先调用订单查询 API 拿到物流状态再调用售后政策检索工具确认退货规则最后把这些信息组织成一段自然语言回复。整个过程不需要人为编排每一步全靠模型自己判断什么时候调用什么工具。3.2 多 AI 协作让一群 Agent 分工干活当单个 Agent 越来越成熟大家自然开始琢磨一个新的方向能不能让多个 Agent 协作完成更复杂的任务这就是“多智能体协作”或者“多 AI 协作”的由来。这个概念听起来新但思路其实很古老——它就是软件工程里的“模块化分层设计”只不过模块变成了会自己思考的 AI。我在实际项目中跑过多智能体协作最稳妥的模式是“主从编排”一个 Orchestrator编排者Agent 负责任务拆解和分发把子任务交给多个 Worker执行者Agent执行完成后由 Critic评审者Agent 汇总检查。例如生成一份行业报告时资料收集 Agent、图表生成 Agent、文字撰写 Agent 同时开工最后由主控 Agent 统一整合格式。这种模式的好处是每个 Agent 职责单一出问题时容易定位坏处是调用链变长token 消耗和总耗时都会上升。还有另一种“自由讨论”模式让多个 Agent 互相辩论某个“裁判 Agent”在后续收敛结论。这种模式在创意发散、头脑风暴类场景中有奇效但在工程落地中稳定性较差目前我建议只在实验场景用。3.3 工作流与智能体训练一个新方向带来的启发和“多智能体协作”相伴而生的词是“AI 工作流”Workflow。工作流和 Agent 的区别我倾向于这样表述工作流是确定性的流水线步骤是预设好的每个环节该干什么写得清清楚楚Agent 则拥有临场判断能力可以在执行中决定下一步动作。实际工程中最优解往往不是二选一而是“工作流为主线、Agent 做关键决策点上的灵活处理”既保住了可控性又保留了智能性。最近圈子里还有个值得关注的方向——DeepSeek 公开的 AI 智能体训练新方法核心视角是把智能体放进真实工具环境中通过“完成任务的结果反馈”来强化学习而不是只靠人工标注的对话示例。这相当于告诉行业智能体不应只学会“聊天时怎么接话”更应学会“在真实操作中怎么尝试、怎么从错误里恢复”。我自己的体会是这条思路直指多智能体系统不稳定性的根源——模型没有在真实环境中见过“工具报错、参数返回异常”这类情况自然处理不好。如果你打算深入 Agent 方向可以把“环境反馈驱动的智能体训练”当作一个重点话题持续跟进。4. 国庆第4天动手落地——模型部署、AI 编程与工程实践4.1 模型部署的三种姿势API 调用、本地部署、私有化集群概念扫盲进行到第四天你会发现脑子里已经有很多名词了但还缺一个“从理论到工程”的桥梁这就是模型部署。绝大多数情况下你其实不需要自己部署模型直接调用云厂商的模型 API 是最省事的方案。注册账号、拿 Key、写几行代码调接口性能、稳定性、多模态能力全部由服务商兜底按量计费。适合个人开发者和绝大多数创业团队快速验证需求。如果涉及数据隐私、成本敏感或离线场景本地部署就变得有吸引力了。你可以用开源模型比如 7B、14B 量级的模型配合推理框架跑在自己的 GPU 机器上。这里必须提一个关键技术名词——量化。简单说量化就是把模型参数从高精度浮点数“压缩”成更低精度的数字比如从 FP16 压缩到 INT4代价是极轻微的质量损失收获是显存占用降低到原来的四分之一左右、推理速度显著提升。这就解释了为什么很多人用消费级显卡就能跑起一个不错的本地大模型。不过你要有心理准备本地部署只是“能跑”距离“好用”还有很大距离工程细节多得足以消耗掉整个假期。第三类是私有化集群部署服务企业内部多个业务线涉及 GPU 集群调度、推理服务框架、负载均衡、监控告警、模型灰度更新这已经进入 AI 基础设施的范畴。普通技术人员了解前两种就够了第三种更多是架构师和平台团队需要操心的事。4.2 模型微调的现实意义为什么大多数项目不需要明白了部署紧接着就会遇到另一个高频问题“我们要不要用业务数据微调模型”我的回答经常让提问者意外大多数情况下不需要先做 RAG。原因很实在微调擅长改变模型的“行为风格”和“输出格式”比如让模型学会用你的产品口吻说话、按照公司规定的格式生成文案但它不擅长给模型注入新的“知识”。想通过微调让模型记住几万条企业内部制度那是既昂贵又低效的做法——用 RAG 检索外部知识库既便宜又能随时更新。如果你确实有微调需求也要记住几条实操经验微调数据集的质量远比数量重要几百条精心清洗、人工审核过的高质量样本往往强过几万条从日志里直接抽出来的脏数据微调前先分出一部分数据做验证集防止“训练时表现很好、测试时效果暴跌”的过拟合问题微调后必须做回归测试确保模型在原有能力上没有明显退化。这些经验都是我用真金白银的 GPU 算力换来的。4.3 AI 编程、AI 测试开发与 AI 产品经理三个被重塑的技术角色如今“AI 编程”已经不算什么新鲜词了。Cline、Cursor、GitHub Copilot、通义灵码等工具本质都是把大模型嵌入 IDE集成开发环境中辅助生成代码、解释代码、写单测、重构逻辑。我实际使用下来的感受是AI 编程工具对“熟练开发者”的提效最明显它能快速补齐模板代码、写胶水层、生成测试用例但还不能独立承担复杂架构设计——因为架构决策依赖大量上下文和隐性经验。你越懂代码越能看出 AI 写的代码哪里有问题所以“AI 取代程序员”这种说法至少目前还太早。“AI 测试开发”也在同步升温。传统测试人员写自动化脚本需要手动定义用例现在可以让模型根据接口文档自动生成测试用例接口返回异常时模型还能辅助分析日志、定位可疑代码块。我见过最惊艳的一个实践是用大模型把上千条历史缺陷报告聚类成若干根因模式直接指导研发团队优化代码——这种“测试数据挖掘”的能力对普通脚本来说是做不到的。还有一个角色被热词榜反复点名AI 产品经理。这个角色最核心的能力根本不是写提示词而是定目标和设边界——想清楚这个 AI 功能到底服务谁、解决什么问题、用什么样的评测指标判断好坏比如准确率、采纳率、用户留存率然后再去协调模型选型、数据准备、评测反馈这些环节。如果你是从技术转岗我的建议是先从“给 AI 项目搭评测基线”入手因为可量化的评测体系是整个 AI 产品迭代的地基。4.4 Spring AIJava 技术栈里的一股清流聊到工程实践Java 技术栈的同学应该对 Spring AI 这个名字不陌生。简单说它就是 Spring 生态为“接入大模型”提供的一套统一抽象层让 Java 开发者不用被迫切换到 Python 生态用熟悉的 Spring Boot 风格去对接不同模型提供商的 API封装了提示词模板、结构化输出、向量数据库集成、Agent 编排等一大堆常见能力。打个比方它之于大模型就像当年 Spring JDBC 之于数据库你可能不在乎底层用 MySQL 还是 Oracle只需要一个统一的模板方法来执行 SQL。Spring AI 解决的就是“今天接这家模型、明天换那家模型”时的适配成本问题。对于企业内部有大量 Java 遗产系统的团队这是一个非常实际的落地选项。当然如果你是从零开始的新项目未必非要选它选型时还是要结合团队技能树和具体场景权衡。5. 国庆第5天看清生成式 AI 的版图——图片、视频、声音5.1 AI 图片生成原理扩散模型一次讲清如果你只记住一个词那就是“扩散模型”。它的思路可以类比成“逆向打码”训练时给清晰图片逐步叠加噪声直到变成满天星一样的纯噪点图这就是“前向过程”然后训练一个神经网络学习“把噪点图一步步还原成原图”这就是“反向过程”。等模型学会了去噪你给它一张完全随机的噪点图它就能“脑补”出一张全新图片。再通过文字引导也就是提示词模型就能根据“一只戴着草帽的柴犬在沙滩上”这样的描述生成对应画面。理解了这个原理你就会明白几个常见现象为什么 AI 生成的细节容易出错——因为去噪过程是概率性的它对“手有几根手指”这种精细结构并不总能建模清楚为什么多次生成同一个提示词结果不一样——因为起始噪点是随机的每次生成的“起点”都不同为什么提示词里加“8k、高清”不一定有用——“高清”本质是对画面质感风格的引导而不是真的能提升分辨率。5.2 AI 视频生成与画质修复从生成到“把老素材救活”视频方向的热度是今年才彻底爆发的。文生视频的基本框架可以理解为在图像扩散模型的基础上增加了时间维度——不仅每帧画面要合理帧与帧之间还要保持物体一致性和运动连贯性。AI 视频工具生成的素材现在还很难做到大量角色、复杂剧情的长镜头稳定但作为短视频素材、创意分镜预览已经完全够用了。我更想聊的是“AI 视频修复”这个更务实的方向。以 Topaz Video AI 这类工具为例它利用 AI 模型对视频做超分把低分辨率提升到高分辨率、去噪、去隔行、补帧让画面更流畅。老电影、老录像、早年用手机拍的糊视频放进去转一圈出来的画面清晰度能发生质变。做这件事不需要特别强的技术背景但对硬件有一定要求——超分模型在 GPU 上跑得快很多CPU 跑一条十分钟的素材可能要熬一个通宵。我修过几段上世纪九十年代的家庭录像那种“把模糊记忆里的人和事重新看清”的体验确实能让人直观感受到 AI 在创作之外的实用价值。5.3 AI 声音空间化从“能说话”到“能定位”语音合成大家很熟TTS 技术让机器朗读文字早就普及了。但“AI 声音空间化”是一个更有趣的方向它不只是让 AI 用音色说话而是让声音在三维空间中有明确的位置和移动轨迹。你在 VR 里听到有人从左边走过来声音应该从左耳渐入、从右耳淡出同时随距离变化响度和混响——这就是空间音频的概念而 AI 可以自动完成声场建模而不需要人工手动摆位。应用场景也很清晰在线会议时让不同发言者的声音分布在房间不同方位避免一群人挤在“单声道”里相互干扰影视制作里低成本实现 5.1、7.1 甚至杜比全景声的混音虚拟主播直播时根据观众互动位置调整声音方位。这波技术还催生了一批“声音克隆”产品用几分钟样本复刻一个人的音色——作为技术方向很有潜力但这类应用涉及声音肖像权问题我一直建议只在明确授权范围内使用边界意识得刻在骨子里。6. 国庆第6天看懂 AI 应用热点——短剧、旅游、建站与内容安全6.1 AI 短剧、漫剧与 AI 旅游热闹背后的共同逻辑最近“AI 短剧”“AI 漫剧”频繁出现在热搜里圈内还有个说法叫“AI 短剧迟早要出片”。理解这波趋势你只需要把它拆成一条生产流水线剧本用大模型生成分镜脚本用文生图生成关键画面再用图生视频让画面动起来配音交给语音合成最后用传统剪辑软件拼装。这套流程把原本需要几十人协作的影视生产压缩到几个人甚至一个人的工作量制作成本下降了两个数量级。同样火热还有“AI 旅游”方向。它不是简单的“AI 帮你订机票”而是把旅行攻略、行程规划、实时信息、个性化推荐结合在一起你告诉 AI 你的天数、预算和偏好它生成路线旅途中随时问它“附近有哪些不用排队的本地菜馆”它能结合实时数据给出建议。这类应用的共同模式我总结成一句话生成式 AI 行业知识场景化交互一个新应用。无论是短剧、旅游还是 AI 建站用 AI 自动生成企业官网、落地页底层逻辑都是在重复这个公式。6.2 为什么 AI 会“不愿回答”对齐与内容安全的真相网上经常有人抱怨“这个 AI 怎么这也不让问、那也不让答”甚至有人专门搜“无限制”“无审核”之类的关键词。作为一个 AI 工程领域的从业者我想从技术层面把这件事讲清楚。模型之所以在某些话题上表现出“拒绝”核心原因在于对齐Alignment——也就是在训练和发布环节开发团队会通过基于人类反馈的强化学习RLHF等技术让模型的回答尽量符合安全规范、法律法规和社会公序良俗。这被设计成模型内部策略的一部分所以在面对某些高危指令时模型会主动拒绝而不是尝试回答。这和“审核”是两码事审核是发布平台在内容传播时的把关而对齐是模型自身在生成前的行为约束。作为技术人员更应该明白这样一个朴素道理任何面向公众的 AI 产品都必须处理内容安全边界问题这不是 AI 产业独有的而是所有内容平台从第一天起就要面对的成本和责任。越早理解并拥抱这套机制的人越能够在 AI 应用设计阶段就把合规风险纳入架构而不是产品上线后再补救。6.3 技术人面对“限制”的正确姿势把这些天听到的“无限制 AI”“无审核聊天”等热词放在一起看你会发现其中隐藏着一个一眼就能看穿的陷阱完全无约束的 AI 能力天然会被滥用。在今天这个时间点不管是为了个人职业安全还是为了企业合规经营都不应该把自己的技术和产品建立在绕过内容安全机制的基础上。你要是真在项目里动了这个念头我劝你先想清楚你是要对业务负责的工程师不是找刺激的测评博主。正确的姿势是把这个话题转化成正面技术课题如何设计更精准的内容安全策略让模型在“不过度拒绝”和“守住底线”之间找到平衡如何通过提示词策略和模型微调让 AI 在敏感领域用专业、友善、可信任的方式回应。能把这些做好的工程师未来几年在各个行业都会是稀缺资源。这也是我坚持在假期扫盲内容里专门开一节讲安全边界的初衷。共勉。7. 国庆第7天扫盲之后的地图——如何继续长线学习7.1 涟漪学习法一个概念生出一串概念七天扫盲到这里你脑子里应该已经有一张比较完整的概念地图了。但现实的 AI 圈每天都在产生新方向从语音交互到具身智能从推理优化到端侧模型根本学不完。这时候最忌像无头苍蝇一样每天追着热点跑。我自己惯用的一个笨办法叫“涟漪学习法”每接触一个新概念先把它丢到已有知识框架里定位再顺藤摸瓜找出与它相邻的三五个概念逐个攻破。举个例子你今天看到“Agent”这个词涟漪扩散出去会牵扯出“工具调用Function Calling”“规划与反思”“长期记忆”“环境反馈强化学习”等一串概念再顺着“环境反馈”又会碰到“RLHF”“偏好优化”“模拟环境”等更底层的技术。每这样扩散一轮你脑内地图上的节点就会增多一圈而且每个新节点都有据可依、有上下文可挂靠。学得越多后面再吸收新概念的速度就越快——这就是扫盲型学习的复利效应。7.2 个人 AI 工具箱从“收藏了”到“跑通了”这七天我一直在强调动手的重要性。扫盲最后一天建议你花时间给自己搭建一套最小的个人 AI 工具箱不需要多豪华够用就行一个模型 API 账号选一个主流大模型厂商完成注册并跑通一次调用。一个代码环境本地装好 Python 和必要的库或者直接用在线 Notebook 环境也行。一个 RAG 小项目准备一份自己的文档比如你的技术笔记做一次“提问→检索→生成”的完整链路。一个 Agent Demo用一个现成的 Agent 框架让模型学会调用至少一个外部 API比如查天气、查汇率。一个评测脚本给自己做的应用写一个最基础的自动评测记录几个固定的测试问题每次改完版本都跑一遍。别小看这些“玩具级别”的项目。我带过不少人从“看了很多资料”到“真正入门”所有成功案例都有一个共同特征在假期里跑通过至少一个端到端的小应用。收藏夹里的东西永远只是仓库能跑起来的代码才代表你真懂了。7.3 节后 30 天路线从工具用户到方案设计者节后回归正常工作节奏你可以按这样一个 30 天路线继续爬坡前十天把假期搭的小工具结合工作场景做一次改造比如用 RAG 思路给自己的团队做一个内部知识问答机器人中间十天关注评测和优化把机器人从“能答”提升到“答得稳”建立一批评测集、压低幻觉出现率最后十天尝试做一次技术分享把你这一个月的实践过程整理成文档或分享给同事——输出是最好的输入你讲得明白才是真明白。再往后如果你对模型训练感兴趣可以开始系统看微调和强化学习的入门课程如果你对产品更感兴趣可以尝试从商业角度评估一个 AI 功能的投入产出比。走到这一步你已经不是一个“看热闹”的人了而是一个有自己判断框架的 AI 实践者比那些还在收藏各种概念清单的人领先了整整一个身位。最后分享一个个人习惯每年这种长假期我都不会给自己排太满的计划每天两三个小时足够。AI 这东西越追越觉得追不完但只要你把地图画出来了以后每次看到新词做的动作只是“定位、挂靠、延展”而不是“从头再来”。这个假期跑通一个 Hello World 级别的 AI 应用比收藏一百篇文章都值。祝你玩得开心代码跑得通。

从大模型到Agent：核心概念与AI应用落地全解析

相关推荐

MySQL四层能力学习路径：从SQL到索引事务与高可用

Web3.0技术前沿：去中心化存储与智能合约开发实践

ERC-8004与可信智能体工程化落地：身份、权限与操作验证实战

更多资讯

数字孪生技术在航天增材制造中的应用与突破

SpringBoot+Vue物联网仓储管理系统开发实践

语音交互核心技术解析与应用实践

语音交互技术：从原理到工程实践

洛谷P1011入门算法题解析与实现指南

PSO优化BP神经网络：原理、实现与性能提升

今日更新

PLFM_RADAR：从被动告警到主动感知的微服务健康监控系统

SPI隔离设计实战：MAX14431BAEE+与STM32F407工业级应用

数字隔离器如何根治SPI通信地环路干扰：MAX14431与TM4C129实战

本周精选

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

本月热门

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

读完文章，想聊聊您的网站？