高晓庄 札记

从传统后端到 AI 工程化：我的六年踩坑复盘 写这篇文章之前犹豫了很久——怕被说”凡尔赛”或者”成功学”。但想了想，简历上罗列的项目和文章里干巴巴的”问题 → 解决”，其实不能完整说明一个人是怎么走过来的。这篇文章试着把那些简历和文章里不会写的东西记下来，包括走错的弯路、推翻过的方案、深夜 debug 的崩溃时刻。 一个不太体面的起点我 2020 年底入职腾讯无线大连研发中心的时候，简历上写的是”熟悉 Spring Boot、MyBatis”，实际上对大厂那套工程化流程是两眼一抹黑的。第一次 code review 被打回来 30 多个 comment，包括命名、异常处理、日志格式、单元测试覆盖率——每个我都觉得”不至于吧”。 那段时间最大的心理冲击不是技术本身，是发现自己之前在小公司积累的”工程化”标准，在大厂眼里根本不达标。这种感觉挺打击自信的，但反过来也让我开始认真对待”工程”这两个字。 2020 - 2022：腾讯，安全中心，做自动化测试和安全运营这是我的第一个正经后端岗位，做了两个项目： 优测自动化测试平台：Golang（Beego）为主，混着 Java（Sprin...

Dify 编排企业级 Workflow 当 AI 能力要真正落地到业务，靠的不是”聊天框”，而是一条条可控、可调试、可复用的 Workflow。Dify 是编排这些工作流的利器。 为什么用 Workflow 而不是纯 Agent一开始我们也试过”让 Agent 自由发挥”，结果很惨：Agent 会乱调用工具、输出不稳定、难以调试。 Workflow 的价值在于”可控”：把 AI 能力拆成一条明确的执行链，每一步做什么、走哪个分支都是确定的。对企业场景，可控比”聪明”重要得多。 核心节点类型Dify 的 Workflow 由几种节点拼成： 节点 作用 LLM 调大模型生成 知识检索 从知识库召回 工具 调用外部 API / 自定义代码 条件分支 根据结果走不同路径 变量聚合 汇总多个分支的结果 一个真实场景：气量智能问数以我做的”自然语言查数据”为例，Workflow 大概是这样的： 123456789用户提问（"上个月各营业厅的用气量是多少"） ↓LLM：意图识别 + 实体抽取（时间、指标、维度） ...

YOLOv5 目标检测训练完整实践 网上”YOLOv5 教程”一大堆，从环境搭建到训练到部署都有。但没人会告诉你：标注质量差到模型根本训不出来是什么体验？现场 GPU 跑得好好的模型到客户机房延迟 1.2 秒怎么破？这些”破事”才是真做项目时遇到的。这篇写这些。 项目起源：客户一句”能自动识别吗？”这个项目不是从”我们想用 AI”开始的，是从客户一句”拍照不规范，能不能自动识别？“开始的。 背景：我们做的是燃气行业的巡检系统，巡检人员去现场拍调压箱、井盖这些设备，回来人工检查拍照是否符合规范。但人工检查不靠谱——拍糊了、角度不对、漏拍的情况太常见。客户希望自动识别。 当时我心里的第一反应是：”这个需求不靠谱，照片变化太多，AI 怎么可能都识别？”后来发现——业务方对 AI 的预期和 AI 的真实能力之间，永远隔着一道鸿沟。这个项目就是学着怎么填这道鸿沟。 第一阶段：数据采集，差点死在起点第一次数据清洗：扔掉了 40%我们从客户的真实巡检照片里收集了 2 万张，准备训练。但第一轮数据清洗就让我震惊： 重复照片：同一个巡检员上传 5 张几乎一样的图 拍照失败：模糊、过曝、角度...

LangChain Agent 实战：从原理到落地 这篇本来想写成标准的”LangChain 教程”——讲 ReAct、讲工具调用、讲 Memory。但写到一半发现，网上这种教程一搜一大堆，没必要再写一份。所以改成”我在做气量智能问数项目时用 LangChain Agent 的真实经验”，把那些官方文档和教程不会告诉你的事写出来。 Agent 是什么（不废话版）如果你已经知道 Agent 是大模型 + 工具 + 记忆，可以直接跳到下面”我踩的坑”部分。 简单说：传统 LLM 只能生成文本，Agent 让 LLM 能”行动”——决定要不要调工具、调哪个工具、怎么解析结果、多次推理直到完成目标。 经典范式是 ReAct（Reasoning + Acting）： 123456Thought: 我需要先查询天气Action: get_weatherAction Input: 北京Observation: 晴，25°CThought: 现在可以给出穿衣建议了Final Answer: 北京今天晴，25°C，建议穿短袖。 我用 Agent 做的真实项目：气量智能问数我在金建做的”气量智能...

RAG 知识库工程化实践 Retrieval-Augmented Generation（RAG）是当前最主流的大模型应用模式之一。本文从工程实践出发，梳理 RAG 系统的完整搭建流程。 为什么需要 RAG大模型虽然能力强大，但存在三个核心局限： 知识时效：训练数据有截止日期 幻觉问题：会”编造”看似合理但实际错误的内容 私域知识：无法回答企业内部文档相关的问题 RAG 通过在生成前先检索相关文档，把外部知识注入到大模型的上下文窗口，能有效缓解这些问题。 RAG 的核心流程12345678910111213用户提问 ↓Query 改写（可选） ↓向量检索 + 关键词检索（混合检索） ↓重排序（Rerank） ↓Prompt 构造（拼接检索结果） ↓LLM 生成答案 ↓引用溯源（可选） 文档处理流水线123456789原始文档（PDF / Word / Markdown / HTML） ↓格式解析（unstructured / docx / pypdf） ↓切片（chunking） ↓Embedding（向量化） ↓向量库索引（Milv...

从 .NET 单体到 Java 微服务的迁移实践 技术栈迁移是架构师面对的最难课题之一：既要推倒旧的，又要保证业务不断。本文复盘我主导的一次公司级 .NET → Java 迁移。 为什么要迁做这个决策时，公司的核心系统是运行多年的 .NET 单体，问题很现实： 人才：Java 生态的招聘池远大于 .NET，团队扩编困难 生态：微服务、云原生、中间件，Java 侧的成熟方案更多 国产化：信创环境对 Java 的适配和支持更完善 迁移不是技术洁癖，而是工程现实倒逼的战略选择。 迁移策略：双轨并行 + 渐进替换最危险的做法是”停摆重写”。我们采用了双轨并行： 123老 .NET 系统（继续跑） ↓ 逐步替换新 Java 服务（增量上线） 具体节奏： 先建基础设施：注册中心、网关、数据库，先把”新世界的底座”搭好 从边缘模块开始：先迁相对独立、耦合度低的模块，积累经验 核心模块最后迁：等团队熟悉新栈、工具链稳定后再动核心 数据迁移的难点代码能重写，数据不能丢。数据迁移的几个关键点： 双写过渡期：新旧系统同时写库，用 MQ 同步，保证数据最终一致 数据校验：迁移...

大模型应用开发基础：API 调用与工程封装 这是我系统转向 AI 应用开发的第一篇笔记。一切从”调用一次大模型 API”开始，但真正要落地，靠的是工程封装。 一次最简调用调一个大模型 API 本质上就是发一个 HTTP 请求： 1234567891011import requestsresp = requests.post( "https://api.deepseek.com/v1/chat/completions", headers={"Authorization": "Bearer sk-xxx"}, json={ "model": "deepseek-chat", "messages": [{"role": "user", "content": "你好"}], },...

Go + KVM/libvirt 实现虚拟机管理 云平台最底层的核心，是让一台物理机”长出”多台虚拟机。这篇文章记录我用 Go 调用 libvirt 实现虚拟机生命周期管理的实践。 技术背景做超融合私有云时，我们面对的核心问题是：如何把 KVM 的虚拟化能力封装成可编程的接口，供上层平台调用。 技术栈选型： KVM：Linux 内核级虚拟化，负责真正的 CPU/内存虚拟化 QEMU：用户态设备模拟，配合 KVM 使用 libvirt：虚拟化管理抽象层，统一管理 KVM/QEMU/LXC 等 Go 侧通过 libvirt-go 绑定，直接调用 libvirt 的 C API。 连接与发现首先连接本机 libvirt 守护进程： 12345678conn, err := libvirt.NewConnect("qemu:///system")if err != nil { log.Fatal(err)}defer conn.Close()// 列出所有虚拟机doms, _ := conn.Li...