doc: 更新简历，新增AI替代危机分析文章，删除过时文章

source/_posts/AI替代危机哪些职业最危险.md

@@ -0,0 +1,392 @@
+---
+title: AI替代危机：哪些职业最危险？——基于342个美国职业的分析报告
+author: Gamehu
+date: 2026-03-19 19:50:00
+tags:
+  - AI
+  - 职业发展
+  - 技术趋势
+  - 就业市场
+categories:
+  - AI观察
+---
+
+> 本文数据来源于 [JoshKale/jobs](https://github.com/JoshKale/jobs) 项目，该项目由 Andrej Karpathy（前 OpenAI 联合创始人、Tesla AI 总监）发起，后由 Josh Kale 维护。项目基于美国劳工统计局（BLS）的342种职业数据，使用 Gemini Flash AI 模型对每个职业进行 AI 暴露评分（0-10分），分数越高表示被 AI 替代的风险越大。
+
+---
+
+# 核心发现
+
+这份研究报告涵盖了美国经济中 **342 种职业**，涉及 **1.43 亿个工作岗位**。研究发现：
+
+- **全行业平均暴露分：5.3/10**（高于中位数）
+- **高危职业（8分以上）：60 个**
+- **极高危职业（9-10分）：31 个**
+
+这意味着，**约 6000 万个岗位**处于高风险区间，占所有岗位的 **42%**。
+
+> Karpathy 的核心观点："如果你的全部工作都在屏幕上进行，那你就危险了。"
+
+---
+
+# 评分标准解读
+
+在深入了解高危职业之前，让我们先理解评分标准：
+
+| 评分 | 风险等级 | 典型职业 |
+|:---:|:---:|:---|
+| **0-1** | 极低风险 | 屋顶工、清洁工、建筑工人 |
+| **2-3** | 低风险 | 电工、水管工、护士助理、消防员 |
+| **4-5** | 中等风险 | 注册护士、零售员、医生 |
+| **6-7** | 高风险 | 教师、经理、会计师、工程师 |
+| **8-9** | 极高风险 | 软件开发、律师助理、数据分析师、编辑 |
+| **10** | 最高风险 | 医疗转录员 |
+
+**核心判断标准**：工作产出是否是根本性的数字化的？如果能在家庭办公室通过电脑完成——写作、编程、分析、沟通——那么 AI 暴露就是天然高的。
+
+---
+
+# 高危职业排行榜（8分以上）
+
+## 🚨 满分 10/10（最高风险）
+
+### 1. 医疗转录员 (Medical transcriptionists)
+
+**暴露评分：10/10**
+
+> **AI 评估理由**：医疗转录是一种纯粹数字化、常规性的信息处理任务，已经受到语音识别的严重冲击。现代 AI 语音转文字技术已经达到很高的准确率，可以自动识别医学术语并生成标准化文档。这项工作的核心——听录音并转写为文字——完全可以由 AI 完成，人类只需进行简单的校对即可。
+
+**为什么最危险？**
+- 工作完全数字化（音频→文字）
+- 任务高度标准化和规范化
+- 语音识别技术已经成熟
+- 不需要人际互动或物理操作
+
+---
+
+## ⚠️ 9/10 分（极高风险）- 30个职业
+
+以下是评分 9 分的职业，按字母顺序排列：
+
+### 2. 账单和账户催收员 (Bill and account collectors)
+**暴露评分：9/10**
+
+工作几乎完全数字化，包括数据分析、查找追踪和电话/电脑沟通。AI 和自动化系统已经推动了该行业 10% 的就业下降。
+
+### 3. 簿记、会计和审计文员 (Bookkeeping, accounting, and auditing clerks)
+**暴露评分：9/10**
+
+几乎完全数字化的日常工作，涉及信息处理、数据录入和数学验证。AI 和自动化软件已经能够以高精度执行这些任务。
+
+### 4. 计算机和信息研究科学家 (Computer and information research scientists)
+**暴露评分：9/10**
+
+虽然这些科学家是构建 AI 的人，但他们创造的工具越来越能够自动化自己的核心任务，如编写代码、简化算法和分析实验结果。
+
+### 5. 计算机程序员 (Computer programmers)
+**暴露评分：9/10**
+
+编写、测试和调试代码的核心任务完全数字化，与大语言模型的优势完美契合。BLS 特别预测由于自动化和 AI，该职业将出现下降。
+
+### 6. 法庭记录员和同声传译员 (Court reporters and simultaneous captioners)
+**暴露评分：9/10**
+
+工作的核心产出是逐字数字转录，而 AI 语音转文字和自然语言处理在这一领域已经达到很高水平。
+
+### 7. 客户服务代表 (Customer service representatives)
+**暴露评分：9/10**
+
+回答询问、处理订单和解决投诉的核心职责本质上是数字化和信息化的。大语言模型和 AI 代理已经能够处理复杂的自然语言交互。
+
+### 8. 数据科学家 (Data scientists)
+**暴露评分：9/10**
+
+完全数字化的职业，以编码、统计建模和数据分析为中心——这些都是 AI 正在迅速达到或超越人类能力的领域。
+
+### 9. 数据库管理员和架构师 (Database administrators and architects)
+**暴露评分：9/10**
+
+完全数字化的工作，涉及 SQL 编码、系统架构和数据管理。AI 已经可以自动化日常 DBA 任务，如性能调优和查询优化。
+
+### 10. 桌面出版商 (Desktop publishers)
+**暴露评分：9/10**
+
+工作产品完全数字化，涉及常规信息处理、版面设计和基础编辑——这些都是 AI 高度擅长的领域。
+
+### 11. 绘图员 (Drafters)
+**暴露评分：9/10**
+
+工作几乎完全数字化，将概念草图转换为技术 CAD 和 BIM 模型。AI 正在迅速发展出生成和优化设计的能力。
+
+### 12. 经济学家 (Economists)
+**暴露评分：9/10**
+
+工作几乎完全数字化，涉及数据分析、数学建模和技术写作。AI 在数据处理、预测建模和报告生成方面表现出色。
+
+### 13. 编辑 (Editors)
+**暴露评分：9/10**
+
+完全数字化的职业，以语言处理为核心——这是大语言模型的核心优势。AI 已经可以执行高级文案编辑、语法纠正和内容优化。
+
+### 14. 财务分析师 (Financial analysts)
+**暴露评分：9/10**
+
+工作几乎完全数字化，涉及处理大型数据集、趋势分析和生成报告。AI 能够以更高的速度和准确性完成这些任务。
+
+### 15. 财务文员 (Financial clerks)
+**暴露评分：9/10**
+
+执行常规的、以数字为先的任务，如数据录入、记录更新和基础财务计算，这些都是软件自动化的理想目标。
+
+### 16. 普通办公室职员 (General office clerks)
+**暴露评分：9/10**
+
+核心职责——数据录入、文档格式化、日程安排和信息处理——几乎完全数字化和常规化。
+
+### 17. 平面设计师 (Graphic designers)
+**暴露评分：9/10**
+
+根本性的数字化职业，核心任务——图像生成、版面创建和照片编辑——正被生成式 AI 迅速改变。
+
+### 18. 保险核保人 (Insurance underwriters)
+**暴露评分：9/10**
+
+根本性的数字化职业，以常规信息处理、风险建模和数据分析为中心——这些都是 AI 擅长的领域。
+
+### 19. 口译员和笔译员 (Interpreters and translators)
+**暴露评分：9/10**
+
+核心工作产品是纯粹数字化信息（文本和语音），而大语言模型在这一领域已经展现出接近人类水平的能力。
+
+### 20. 市场研究分析师 (Market research analysts)
+**暴露评分：9/10**
+
+核心职责——数据收集、统计分析、趋势预测和报告生成——本质上是数字化的，与大语言模型的能力完美契合。
+
+### 21. 数学家和统计学家 (Mathematicians and statisticians)
+**暴露评分：9/10**
+
+几乎完全数字化的工作，涉及数据分析、数学建模和编码——这些都是 AI 和大语言模型高度胜任的领域。
+
+### 22. 医疗记录专员 (Medical records specialists)
+**暴露评分：9/10**
+
+几乎完全数字化，涉及在电子系统中处理、分类和录入数据。AI 已经高度擅长医疗编码和文档处理。
+
+### 23. 运筹学分析师 (Operations research analysts)
+**暴露评分：9/10**
+
+几乎完全数字化的工作，涉及数据收集、数学建模和报告撰写——这些都是 AI 擅长的领域。
+
+### 24. 律师助理和法律助理 (Paralegals and legal assistants)
+**暴露评分：9/10**
+
+核心职责——法律研究、文件起草和信息组织——本质上是数字化的，与大语言模型的优势完美契合。
+
+### 25. 软件开发人员、QA 分析师和测试人员 (Software developers, QA analysts, and testers)
+**暴露评分：9/10**
+
+根本性的数字化职业，编码、调试和测试自动化的核心任务是大语言模型的主要应用场景。
+
+### 26. 特效艺术家和动画师 (Special effects artists and animators)
+**暴露评分：9/10**
+
+几乎完全数字化的工作，3D 建模、渲染和动画的核心任务正被生成式 AI 和自动化工具直接颠覆。
+
+### 27. 调查研究人员 (Survey researchers)
+**暴露评分：9/10**
+
+根本性的数字化知识职业，涉及背景研究、调查设计、统计分析和报告生成——全部都是 AI 的高暴露领域。
+
+### 28. 技术文档撰写员 (Technical writers)
+**暴露评分：9/10**
+
+完全数字化的职业，将复杂信息综合成清晰文档——这是大语言模型的核心优势。
+
+### 29. 旅行代理 (Travel agents)
+**暴露评分：9/10**
+
+核心功能——研究目的地、比较价格、构建行程和处理预订——完全数字化且常规化，已经被 AI 旅行规划工具大量替代。
+
+### 30. Web 开发人员和数字设计师 (Web developers and digital designers)
+**暴露评分：9/10**
+
+完全数字化的职业，编写代码（HTML、JavaScript）、设计布局和创建原型都是 AI 迅速改进的领域。
+
+### 31. 作家和作者 (Writers and authors)
+**暴露评分：9/10**
+
+核心工作产品完全数字化和文本化，与大语言模型的主要能力完美契合。AI 已经可以生成长篇连贯的叙述、营销文案和技术文档。
+
+---
+
+## 🔶 8/10 分（很高风险）- 29个职业
+
+以下是评分 8 分的职业，同样面临很高的 AI 替代风险：
+
+| 序号 | 职业 | 序号 | 职业 |
+|:---:|:---|:---:|:---|
+| 32 | 会计师和审计师 | 47 | 工业设计师 |
+| 33 | 精算师 | 48 | 信息安全分析师 |
+| 34 | 广告、促销和营销经理 | 49 | 律师 |
+| 35 | 艺术总监 | 50 | 贷款官员 |
+| 36 | 大气科学家（含气象学家） | 51 | 医学剂量师 |
+| 37 | 预算分析师 | 52 | 模特 |
+| 38 | 制图师和摄影测量师 | 53 | 网络和计算机系统管理员 |
+| 39 | 薪酬、福利和工作分析专员 | 54 | 政治学家 |
+| 40 | 合规官 | 55 | 公共关系专员 |
+| 41 | 计算机硬件工程师 | 56 | 秘书和行政助理 |
+| 42 | 计算机网络架构师 | 57 | 证券、商品和金融服务销售代理 |
+| 43 | 计算机支持专员 | 58 | 税务审查员和征收员 |
+| 44 | 计算机系统分析师 | 59 | 地理学家 |
+| 45 | 成本估算师 | 60 | 健康信息技术员和医学登记员 |
+| 46 | 财务审查员 | | |
+
+---
+
+# 高危职业的共同点
+
+通过分析这 60 个高危职业，我们可以总结出以下共同特征：
+
+## 1. 工作产品完全数字化
+
+几乎所有 8 分以上的职业，其工作产出都是数字化的：
+- 文本（作家、编辑、技术文档撰写员）
+- 代码（程序员、软件开发人员）
+- 数据（数据科学家、财务分析师）
+- 图像（平面设计师、特效艺术家）
+
+## 2. 任务常规化和可预测
+
+高危职业往往涉及：
+- 信息处理和数据录入
+- 模式识别和分类
+- 规则驱动的决策
+- 标准化的分析和报告
+
+## 3. 不需要物理操作或人际互动
+
+这些工作通常：
+- 可以在家庭办公室完成
+- 不需要体力劳动
+- 不需要现场判断或手动操作
+- 人际互动可以通过数字渠道完成
+
+---
+
+# 为什么这些职业最危险？
+
+## Goodhart 定律的启示
+
+经济学中有一个著名的 **Goodhart 定律**：
+
+> "当一个指标变成目标时，它就不再是一个好的指标。"
+
+在 AI 替代的语境下，这意味着：
+
+**当 AI 针对某个特定任务进行优化时，人类在该任务上的相对优势就会迅速丧失。**
+
+高危职业的共同点是：它们的核心任务恰好是 AI 正在快速优化的领域。
+
+## 当前 AI 的能力边界
+
+现代 AI（尤其是大语言模型）在以下领域已经达到或接近人类水平：
+
+| AI 能力 | 受影响职业 |
+|:---|:---|
+| 自然语言理解和生成 | 作家、编辑、客服、翻译 |
+| 代码编写和调试 | 程序员、软件开发者 |
+| 数据分析和建模 | 数据科学家、金融分析师 |
+| 图像生成和编辑 | 设计师、艺术家 |
+| 语音识别和转录 | 转录员、法庭记录员 |
+
+---
+
+# 对软件行业的特别警示
+
+作为一名软件从业者，我必须特别关注报告中的一些发现：
+
+## 软件开发的 9/10 评分
+
+**软件开发人员、QA 分析师和测试人员**被评为 9/10 分，这意味着：
+
+1. **编码本身正被 AI 快速掌握**
+   - GitHub Copilot 等工具已经能够生成大量代码
+   - AI 在代码审查、bug 修复方面的能力快速提升
+
+2. **但并非所有软件工作都同样危险**
+
+报告指出，以下技能更难被自动化：
+- 系统架构设计
+- 将模糊的产品需求转化为精确的技术约束
+- 理解"应该构建什么"和"为什么构建"
+
+> **建议**：软件从业者应该优先发展这些难以描述为"文本生成"的技能。
+
+---
+
+# 相对安全的职业有哪些？
+
+为了对比，让我们看看评分最低的职业：
+
+| 职业 | 评分 | 原因 |
+|:---|:---:|:---|
+| 运动员和体育竞技者 | 1/10 | 核心为身体表现和实时人类存在 |
+| 建筑劳工和助手 | 1/10 | 几乎完全是体力劳动 |
+| 木匠 | 2/10 | 高度依赖手工技能和实时物理环境判断 |
+| 屠夫 | 2/10 | 需要手工灵活性、体力和与物理产品的实时互动 |
+| 理发师、发型师和美容师 | 2/10 | 需要手工灵活性和与人体的高度互动 |
+| 电工 | 2/10 | 主要是体力劳动，AI 只能协助辅助任务 |
+| 厨师 | 3/10 | 核心是身体和感官的，需要实时适应 |
+
+**共同特点**：需要物理存在、手工技能、实时人际互动或在不可预测的物理环境中工作。
+
+---
+
+# 结论与建议
+
+## 核心结论
+
+1. **6000 万美国岗位处于高危状态**（评分 7+）
+2. **屏幕依赖型职业全线告急**——软件开发 9/10、律师 8/10、办公室职员 9/10
+3. **蓝领体力工作成为避风港**——水管工、清洁工、屋顶工等评分最低
+4. **AI 暴露不等于完全消失**——很多工作将被重塑而非被替代
+
+## 给职场人的建议
+
+### 如果你处于高危职业：
+
+1. **发展 AI 难以复制的技能**
+   - 复杂的人际沟通和情商
+   - 跨领域整合和创新思维
+   - 物理世界的判断和操作
+
+2. **将 AI 视为工具而非威胁**
+   - 学习使用 AI 提高工作效率
+   - 专注于 AI 不擅长的任务
+   - 从执行者转变为策略制定者
+
+3. **考虑职业转型**
+   - 向管理、策略或创意方向发展
+   - 结合技术能力和领域专业知识
+   - 发展需要物理存在或复杂人际互动的工作
+
+### 无论你是哪个行业：
+
+> **最重要的能力是适应能力和持续学习的能力。**
+
+AI 的发展速度远超预期，今天的安全职业明天可能就不再安全。保持学习、保持灵活，才是应对不确定性的最佳策略。
+
+---
+
+# 参考资料
+
+1. [JoshKale/jobs GitHub 仓库](https://github.com/JoshKale/jobs)
+2. [AI 职业暴露可视化](https://joshkale.github.io/jobs/)
+3. [美国劳工统计局职业展望手册](https://www.bls.gov/ooh/)
+4. [Goodhart's Law - Wikipedia](https://en.wikipedia.org/wiki/Goodhart%27s_law)
+5. [The Mythical Man-Month - Wikipedia](https://en.wikipedia.org/wiki/The_Mythical_Man-Month)
+
+---
+
+*本文数据基于 Gemini Flash AI 模型的评估，仅供参考。AI 技术发展日新月异，实际情况可能与预测有所不同。*

source/_posts/Agentic 入门：让 AI 不再一把梭，而是像人一样反复干活.md

@@ -0,0 +1,358 @@
+---
+title: Agentic 入门：让 AI 不再一把梭，而是像人一样反复干活
+author: Gamehu
+date: 2026-03-24 23:22:47
+tags:
+  - AI
+  - Agentic
+  - 工作流
+  - 大模型
+categories:
+  - AI
+---
+
+<div class="tag-container">
+  <span class="ai-tag">AI</span>
+  <span class="sub-tag">Agentic</span>
+  <span class="sub-tag">工作流</span>
+</div>
+
+最近产品里想要集成业务 Agent，真动手之前我想先把底层逻辑搞清楚，但是深入了解agent之前我先看到了一个词：**Agentic**，所以我想得搞清楚Agentic。
+
+它跟 Agent 不是一回事。Agent 是具体的东西，比如一个能自主干活的 AI 助手；Agentic 是一种**工作方式**——让 AI 能规划、执行、反思、修正，在循环里反复迭代，而不是一问一答就结束。搞懂 Agentic，才知道 Agent 该怎么搭。
+
+<span class=”highlight-text”>说白了，Agentic 不是让 AI 更会说话，而是让 AI 更像一个会反复干活的人。</span>
+
+这篇是我自己的学习整理，不聊实现细节，就想先把这件事用人话讲透。
+
+---
+
+## 一、先想明白，我们平时到底是怎么用 AI 的
+
+吴恩达先生以前讲过一个很形象的比喻。
+
+他说我们现在大部分人用大模型，其实还是 **Zero-shot**（就是不给任何示例、不做任何拆解，直接让它一把回答）模式。你扔一个 prompt 进去，模型从第一句一路吐到最后一句，中途没有停顿，没有修改，也没有回头看一眼自己写得对不对。
+
+这件事像什么？
+
+像你让一个人从头到尾写一篇文章，但中途不准按退格键。
+
+你想想，这活儿正常人都干不好，更别说我们还指望 AI 一把出神作。
+
+这也是为什么，我现在回头看，会觉得很多时候不是 AI 本身忽强忽弱，而是我们给它的工作方式，本来就有点反人类。  
+不是它不能干，而是你要求它一次性把所有事情都想对、写对、做对。
+
+但真实世界里的高手不是这么干活的。
+
+不管是写文章、做方案、查资料，还是写代码，正常流程基本都是：
+
+1. 先想一下目标是什么
+2. 拆几个步骤出来
+3. 缺信息就去查
+4. 先搞一个初稿
+5. 回头检查漏洞
+6. 发现问题再改一轮
+
+这套动作，我们人类觉得理所当然；一到 AI 身上，很多人反而想跳过。
+
+所以我现在理解的 Agentic，本质上就是把这套”人类本来就会的迭代过程”，重新装回 AI 的工作流里。
+
+用一张图来看，差别其实一目了然：
+
+{% mermaid %}
+graph LR
+    subgraph 传统模式
+        A1[用户提问] --> A2[AI 一口气输出] --> A3[结束]
+    end
+    subgraph Agentic 模式
+        B1[用户提问] --> B2[规划] --> B3[执行] --> B4[反思]
+        B4 -->|发现问题| B2
+        B4 -->|没问题| B5[输出结果]
+    end
+    style A2 fill:#ffcccc
+    style B4 fill:#ccffcc
+{% endmermaid %}
+
+左边就是我们现在大部分人用 AI 的方式：一问一答，结束。
+右边是 Agentic 的方式：它会自己转圈，直到结果靠谱为止。
+
+---
+
+## 二、Agentic 到底是什么？这是我目前最顺的一句解释
+
+如果非要让我先给自己留一句最顺口的人话解释，我会这么说：
+
+> **Agentic 不是让 AI 更聪明，而是让 AI 不再只回答一次。**
+
+它会在一个循环里反复工作。
+
+比如你让它写一份研究报告，它不是上来就闷头输出 3000 字，而是可能先做这些事：
+
+- 先列提纲，确认应该从哪几个角度展开
+- 判断哪些部分信息不够，需要联网搜索或者调资料
+- 先写一个版本
+- 再自己检查这一版有没有逻辑漏洞、重复废话或者证据不足
+- 然后按发现的问题继续改
+
+你看，这不就是一个稍微靠谱点的人在做事的样子吗？
+
+这里最关键的，不是“会不会调用工具”，也不是“会不会写代码”，而是它终于不再被限制在“一次生成、不可回头”的模式里了。
+
+这件事带来的提升，其实很夸张。
+
+吴恩达先生他们测过一组数据，挺有意思的——GPT-3.5 裸跑代码题只有 48% 正确率，但套上 Agentic 循环以后，直接拉到 95%。比 GPT-4 裸跑的 67% 还高一大截。（数据来自吴恩达先生 2024 年在 Sequoia AI Ascent 的演讲 *[Agentic Design Patterns](https://www.deeplearning.ai/the-batch/how-agents-can-improve-llm-performance/)*）
+
+我觉得这组数字最值得咂摸的地方，不是某个模型赢了，而是它说明了一件事：
+
+<span class="highlight-text">工作流设计，在很多场景下，已经开始比“模型单次裸跑能力”更重要了。</span>
+
+以前大家拼谁的 prompt 写得玄。  
+现在越来越像在拼，谁更懂得给 AI 安排一个像样的工作流程。
+
+---
+
+## 三、我先把 Agentic 拆成四个最核心的招式
+
+吴恩达先生后来把 Agentic 总结成四种常见设计模式。我自己的感受是，这四个词看起来有点学术，但翻译成人话之后，反而会一下子清楚很多。
+
+先上一张全景图，让你对这四个模式的关系有个整体感觉：
+
+{% mermaid %}
+graph TB
+    MA[多智能体协作<br/>把任务分给不同角色] --> PL[规划<br/>拆任务、定顺序]
+    PL --> EX[执行 + 工具使用<br/>干活、调工具]
+    EX --> RF[反思<br/>回头检查、修正]
+    RF -->|发现问题| PL
+    RF -->|通过| OUT[输出结果]
+    style MA fill:#e6f3ff
+    style PL fill:#fff3e6
+    style EX fill:#e6ffe6
+    style RF fill:#ffe6e6
+{% endmermaid %}
+
+简单说就是：多个角色分工（多智能体） → 每个角色先想清楚再动手（规划） → 该查就查、该调就调（工具使用） → 做完回头看一遍（反思） → 不行就再来一轮。
+
+### 1. 反思（Reflection）
+
+**一句话类比：写完作文自己通读一遍，删掉废话、补上漏洞。**
+
+就是让 AI 不要交卷就跑，而是看一眼自己刚刚写了什么。
+
+有没有逻辑不通的地方？  
+有没有明显没回答到题？  
+有没有一堆正确但没用的废话？
+
+这一步特别像我们自己写完文章后，隔两分钟再回来看，突然发现：
+
+“这段说了等于没说。”  
+“这个论点站不住。”  
+“这里应该删，不然啰嗦。”
+
+很多看起来”更聪明”的 AI 应用，往往不是第一次就答得特别神，而是多了一轮自我审稿。
+
+### 2. 工具使用（Tool Use）
+
+**一句话类比：查字典、翻参考书，而不是全靠记忆硬撑。**
+
+AI 靠自己脑补，肯定有上限。
+所以你得允许它出门干活。
+
+比如：
+
+- 去搜资料
+- 读文件
+- 跑代码
+- 查数据库
+- 调 API
+- 调用外部系统
+
+工具这件事，本质上是在补模型的“手脚”。  
+只有脑子，没有手脚，它很多事永远只能停留在嘴上。
+
+### 3. 规划（Planning）
+
+**一句话类比：做菜之前先看一遍菜谱，别上来就开火。**
+
+规划说白了就是，别一股脑往前冲，先想一下顺序。
+
+面对复杂任务，先拆，再干，效率会高很多。比如：
+
+- 先定目标
+- 再拆子任务
+- 然后决定哪些任务要查资料，哪些任务可以直接写
+- 最后再汇总
+
+人一旦不规划，容易瞎忙。  
+AI 一旦不规划，容易一本正经地跑偏。
+
+### 4. 多智能体协作（Multi-agent Collaboration）
+
+**一句话类比：一个人拍电影不如分工——导演、编剧、摄影各管各的。**
+
+这个词听起来很高级，实际你可以把它理解成”别让一个 AI 同时扮演所有角色”。
+
+比如一个负责搜集资料，一个负责写初稿，一个负责挑刺，一个负责做最终汇总。  
+甚至它们之间还可以互相辩论。
+
+这套思路的价值，不在于搞得多复杂，而在于：  
+**不同角色的关注点本来就不一样，拆开之后，结果往往比一个 AI 一把梭更稳。**
+
+---
+
+## 四、从会跑到跑得稳，还差这两样东西：Harness 和 Traces
+
+上面四个招式看起来挺简单的对吧？但一旦真让 AI 跑起来，你马上会碰到两个问题：
+
+1. 它跑偏了你怎么兜住？
+2. 它跑偏了你怎么知道？
+
+第一个问题，对应的是 **Harness**；第二个问题，对应的是 **Traces**。
+
+### Harness：给 AI 装上安全带和工具腰带
+
+如果我只把 Agentic 理解成”让 AI 多跑几轮”，那其实只理解了一半。
+
+LangChain 的 Harrison Chase 提过一个我很认同的点：今天很多 Agentic 系统之所以变强，不只是因为模型本身更好了，而是因为我们给它加了一套越来越完整的”外围设施”。
+
+他管这个叫 **Harness**。说白了，就是你在让 AI 干活之前，先给它搭好的一整套工作台——什么工具能用、什么文件能动、上下文怎么喂、出了问题怎么回滚。
+
+举个具体的例子：你让 AI 帮你写一段代码。如果是裸跑，它只能凭记忆硬编。但如果有了 Harness，它可以先读你项目里的现有代码（文件系统权限），记住你之前说过的偏好（记忆机制），按步骤拆解任务（规划能力），跑完代码自动测试（验证机制），测试没过就自动回退（回滚机制）。
+
+这时候你就能理解，为什么现在很多团队开始讲 **Context Engineering**（上下文工程），而不只是讲 Prompt Engineering 了。
+
+打个比方：如果 Prompt 是你跟 AI 说的那句话，那 Context Engineering 就是你在它开口之前，帮它把该看的资料、该知道的规则、该用的工具全部摆到桌面上。
+
+这俩压根不是一个量级的事。
+
+以前大家总想找一句神 prompt 包打天下。
+现在越来越像搭一个工作台，把 AI 放进去之后，它每一步都有人给它递对工具、递对材料、递对约束。
+
+<span class=”highlight-text”>Agentic 拼到后面，拼的不是一句提示词写得多花，而是谁更会给 AI 配环境、配反馈、配护栏。</span>
+
+### Traces：给 AI 装上飞行记录仪
+
+好，Harness 解决了”怎么兜住”。但还有个问题：AI 跑偏了，你怎么知道它是在哪一步开始偏的？
+
+传统软件有个好处——代码基本就是规则本身，程序为什么这么跑，你顺着代码就能看明白。
+
+但 Agentic 不一样。它不是一条固定路径跑到底，而是在循环里不断判断、选择、调用工具、修正方向。你第 14 步看到它翻车的时候，真正的问题很可能出在第 3 步，甚至第 1 步。
+
+这时候最有价值的东西就不是”它最终输出了什么”，而是它每一步的操作日志——每一步看到了什么上下文、为什么做出这个判断、调了哪些工具、工具返回了什么、它是基于什么决定继续还是回退。
+
+这些记录，就是 **Traces**（追踪日志）。
+
+它特别像什么？像飞行记录仪。
+
+平时你可能不看，但一旦出事，没有它你基本就是瞎猜。
+
+所以我现在会提醒自己，未来如果真要在业务里落地 Agentic，不能只盯着”能不能跑通”。没有 trace 的系统，很多时候只是看起来能跑，一出问题你根本没法定位。
+
+---
+
+## 五、对我这种准备落业务的人来说，更现实的姿势不是全自动，而是”人类在环”
+
+看到这里，我自己先记一个结论：
+
+**小白入门 Agentic，千万别一上来就追求 100% 自动驾驶。**
+
+这事听起来很性感，做起来经常很危险。
+
+因为长链路任务一旦完全放飞，AI 很容易在你没注意的时候，往一个看似合理、其实已经偏掉的方向一路狂奔。
+
+所以比“全自动”更现实的做法，是先把它当成一个很强的起草机、陪练和执行器。
+
+比如：
+
+- 帮你先起一个方案初稿
+- 帮你做一版调研汇总
+- 帮你把一堆需求整理成结构化任务
+- 帮你先生成代码骨架和测试思路
+
+然后关键决策点交给人来审。
+
+我很认同一种说法，叫 **Keep the AI on the leash**。  
+翻译得粗暴点，就是：别把绳子撒手。
+
+你要给它一定的自主性，但这个自主性必须可调。
+
+它能跑，但你随时能：
+
+- 看见它干了什么
+- 拒绝它的修改
+- 编辑它的中间结果
+- 在关键节点让它停下来等你确认
+
+这就是所谓的 **Human-in-the-loop**（人类在关键节点把关）。
+
+它听起来好像“不够自动化”，但对真实业务来说，这反而是更成熟的状态。  
+因为信任不是靠宣传建立的，是靠“我看得见、控得住、改得回”建立的。
+
+---
+
+## 六、如果我后面真要往业务里落，起步大概率会先套这个最小闭环
+
+说了这么多，最后落到实操，我觉得最适合我这种还在往业务里试的人，Agentic 起步姿势就先四步：
+
+{% mermaid %}
+graph LR
+    P[1. 规划<br/>拆任务、定目标] --> E[2. 执行<br/>搜资料、调工具]
+    E --> R[3. 自我反思<br/>挑刺、补漏]
+    R --> H[4. 人类审核<br/>关键节点拍板]
+    H -->|需要修正| P
+    H -->|通过| D[交付]
+    style P fill:#fff3e6
+    style E fill:#e6ffe6
+    style R fill:#ffe6e6
+    style H fill:#e6f3ff
+{% endmermaid %}
+
+### 1. 规划
+
+先别急着让 AI 干活，先让它拆任务。
+
+问清楚目标是什么，输出物是什么，哪些约束不能碰，哪些信息还缺。
+
+### 2. 执行
+
+该搜资料就搜，该读文件就读，该调工具就调。  
+这一步别只让它靠记忆硬编。
+
+### 3. 自我反思
+
+让它自己回头挑刺。  
+检查逻辑、补证据、删废话、找风险点。
+
+### 4. 人类审核
+
+关键节点必须有人拍板。  
+尤其是涉及代码变更、对外发布、客户沟通、业务决策的内容。
+
+这四步看起来很朴素，但已经足够构成一个靠谱的 Agentic 最小闭环。
+
+它真正打碎的，其实也是我自己之前对 AI 的一个幻觉：
+
+**不是“有没有一个神 prompt 能一次性解决问题”，而是“我能不能把问题组织成一个能不断修正的流程”。**
+
+这两个思路，差别非常大。
+
+---
+
+## 七、最后记一笔
+
+如果我现在还把 AI 只当成一个高级搜索框，或者一个会写字的聊天机器人，那我大概率还没真正进入 Agentic 这套工作方式。
+
+Agentic 的重点，从来不是“让 AI 更像人聊天”，而是“让 AI 更像一个可以在工作流里持续推进任务的执行者”。
+
+它会规划，会调用工具，会回头反思，会在必要的时候把决定权交还给人。
+
+我越来越觉得，接下来 AI 应用真正拉开差距的地方，不是大家都在拼模型参数，而是谁先把这套工作方式吃透。
+
+毕竟现实里真正靠谱的人，也不是因为他永远第一次就做对。  
+而是因为他会：
+
+- 先想清楚
+- 再动手
+- 做完回头看
+- 发现不对就改
+
+现在，只不过我们开始要求 AI 也这么干了。

source/_posts/OKR和KPI那套，什么时候开始变味了.md

@@ -1,198 +0,0 @@
----
-title: OKR和KPI那套，什么时候开始变味了
-author: Gamehu
-date: 2026-03-06 08:17:42
-categories:
-  - 工作
-tags:
-  - 管理
-  - 职场
-  - OKR
-  - KPI
-  - 创业公司
----
-
-前两天看到一篇文章，讲一个团队是怎么被 OKR 搞废掉的。
-
-我看完第一反应不是震惊，而是熟悉。太熟悉了。
-
-这种剧情我不光看过，还真切经历过。大厂见过，创业公司也见过，而且每次套路都差不多。通常一开始业务还过得去，大家都忙着打仗，没人太在意考核这套东西。可一旦效益不好了，增长慢了，或者老板心里开始发虚了，OKR、KPI、周报、日报这些东西，往往就会突然变得重要起来。
-
-然后团队就开始慢慢变形。
-
-
----
-
-## 我在大厂第一次明显感受到这股味儿
-
-那次大概是某年 Q3，公司股价跌了一波。上面开了几轮会，最后落下来一个词，叫“精细化管理”。
-
-这词听着挺中性，甚至还有点高级，但翻译成人话，其实很多时候就是：**开始抓考勤、抓周报、抓对齐、抓留痕。**
-
-我们组之前其实挺松的。活干完了，产品也上了，大家喘口气是很正常的。没什么事的时候，下午早一点走，也没人专门盯。那种状态未必完美，但至少大家注意力是在做事上的。
-
-结果那段时间开始，节奏一下就变了。
-
-- 每周一早上要站会，每个人说上周做了什么，这周准备做什么
-- 周五要复盘，OKR 进度必须填进系统
-- 日报、周报开始抄送更多层级
-- 迟到早退这些以前没人太在意的事，也开始被认真统计
-
-我当时带一个小团队，最明显的感受不是“管理加强了”，而是大家开始演了。
-
-写代码的时间少了，写“证明自己在工作”的东西多了。注意，不是那种真正帮协作提效的文档，而是那种为了方便往上汇报、方便自证清白、方便出了问题别算到自己头上的文档。
-
-有个同事我印象挺深。以前他遇到问题，直接拉人说两句，半小时可能就搞定了。后来不一样了，得先把背景写清楚，把问题写清楚，把影响写清楚，再写几个方案，最后约个会统一口径。一件原本半小时能搞完的事，最后能拖成两天。
-
-我问他，为啥不直接说？
-
-他说得也很实在：“现在不是讲流程、讲留痕吗？不留痕，到时候出事了怎么算？”
-
-你看，这就是问题。
-
-**考核和管控一旦上强度，很多人的第一反应就不是怎么把事做好，而是怎么先保护自己。**
-
----
-
-## 创业公司的版本，通常更直接，也更荒诞
-
-后来我去过一家创业公司，二十来号人，团队不大，早期氛围也不错。老板是技术出身，刚开始大家一起熬夜上线、一起救火，很多事都比较直接，没那么多讲究。
-
-做到第二年，融资开始没那么顺，老板整个人的状态也肉眼可见地紧了起来。
-
-先是开会说要“提高人效”，然后 HR 发下来一个表，让每个人填每天做了什么，以及时间大概怎么分配。再后来，周会慢慢变成一种带检查意味的一对一，老板会直接问：“你这周最核心的产出是什么？”
-
-这种问法听着没毛病，但问题是，很多岗位的价值本来就不是按“这周交付了一个什么具体件”来体现的。
-
-我印象很深的一次，是一个产品经理被问急了，说自己这周主要在协调资源、推沟通、解决卡点，没什么特别好拿出来展示的“具体产出”。
-
-老板当时回了一句：“那就是没产出。”
-
-那个产品经理第二周就离职了。
-
-这件事我后来一直记得，不是因为它多戏剧化，而是因为它特别典型。很多管理动作一旦开始变味，最先出问题的，往往就是对“产出”的定义开始变窄了。凡是不好量化的、不能直接截图汇报的、没法马上写成条目的价值，都会被低估。
-
-可现实不是这么运转的。
-
-一个团队里，判断力、协调、补位、把模糊问题想清楚，这些东西很多时候比“今天做完了几个点”重要得多。只是它们更难写进表里。
-
-我后来还跟那个老板聊过一次。我问他，咱们现在才这么点人，抓这么细，真的有必要吗？
-
-他说：“我现在不知道每个人在干什么，心里没底。”
-
-我当时回了一句：你靠抓考核，最后看到的，大概率也只是大家想让你看到的东西。
-
-他没接这个话。
-
-后来我越来越觉得，**老板抓考核，很多时候不一定是为了提升效率，更像是在给自己的焦虑找一个抓手。**
-
-业务看不清楚，数据不好看，方向又没那么稳，人就会天然地想抓住一些“看得见、数得着、能检查”的东西。于是日报、周报、打分、排名、对齐，就都上来了。
-
-问题是，这些东西最容易抓住的，通常都是表层动作。真正决定成败的那些东西，比如判断是不是对、协作是不是顺、试错是不是有效，反而不太容易量化。
-
-最后就会变成一种很别扭的状态：大家都忙得很认真，但你真要问，忙出来了什么，好像又说不太清。
-
----
-
-## OKR 和 KPI 本身没原罪，真正容易出问题的是时机和动机
-
-我不是那种逢考核必反的人。
-
-说到底，OKR、KPI 这些东西本身只是工具。在大厂里，它们有存在理由。人多、层级多、链路长、信息天然不透明，你总得有一套机制让目标能往下拆，让结果能往上看。
-
-工具没问题，问题往往出在它是怎么被用起来的。
-
-我自己这些年看下来，有个规律挺明显：
-
-- 业务顺的时候，考核往往没那么重要，很多时候走个形式
-- 业务开始承压的时候，考核就会突然被强调
-- 老板或者管理层心里没底的时候，考核会迅速精细化
-
-这背后说明的事，其实挺现实的。
-
-**很多时候，考核不是拿来提升业绩的，而是拿来缓解焦虑的。**
-
-管理层焦虑，组织就会想办法把这种焦虑“落地”；一旦落到一线，通常就会变成更密集的汇报、更细的记录、更重的过程管理。
-
-可焦虑这个东西，往下传一层，就很容易变成内耗。
-
-因为一线接收到的信号不是“怎么把事做成”，而是“怎么证明我没问题”。
-
-一旦组织进入这个状态，很多行为都会自然变形。目标会越定越保守，汇报会越写越漂亮，协作会越来越偏向自保，大家慢慢都知道这套东西不太对，但又只能继续陪着跑。
-
----
-
-## 为什么这套东西一变味，团队很快就会失真
-
-这点其实是我后来才慢慢想明白的。
-
-正常情况下，目标管理本来应该是帮助团队聚焦的。你要解决什么问题，优先级是什么，阶段性打到哪里算过关，大家最好心里有数。
-
-可一旦它和惩罚、排名、证明劳动强度这些东西绑得太死，目标管理就不再是“对齐工具”，而会慢慢变成“表演系统”。
-
-人一旦意识到结果会直接影响评价，第一反应通常不是把目标定得更真实，而是把目标定得更安全。
-
-于是：
-
-- 能模糊的就模糊
-- 能保守的就保守
-- 能包装的就包装
-- 能写得好看的就尽量写得好看
-
-最后所有人都在做一件事：让系统里的自己看起来合理。
-
-这个时候，你看到的数据可能越来越完整，表格可能越来越漂亮，但组织对真实情况的感知反而在下降。
-
-这就是最麻烦的地方。
-
-管理层以为自己抓得更细了，离真相更近了；可实际上，大家只是在更用力地经营“被看见的样子”。
-
----
-
-## 我现在怎么看这件事
-
-说实话，我也做过管理，完全能理解那种“我得知道团队现在到底什么情况”的冲动。团队一大，信息天然会打折，靠拍脑袋肯定不行。
-
-但我现在越来越认同一件事：**考核是手段，而且应该是偏后置的手段，不应该是你一上来最先拎出来的东西。**
-
-如果一个团队已经开始严重依赖考核来驱动，那通常说明前面已经有东西出问题了。可能是目标没讲清楚，可能是协同机制有问题，可能是信任不够，也可能是业务本身就进入了困难阶段。
-
-这时候你再往上加考核，很多时候就像一个人发烧了，你不去找病因，先一把退烧药压下去。数字可能短期好看一点，动作可能短期整齐一点，但真正的问题还在。
-
-更麻烦的是，这药吃多了，团队会虚。
-
-人会越来越保守，越来越不愿意承担模糊地带的责任，越来越在意“这件事最后怎么评价我”，而不是“这件事到底值不值得做、该怎么做好”。
-
-团队一旦走到这个方向，再想拉回来，成本很高。
-
----
-
-## 给还在坑里的人几句实话
-
-如果你在一家公司，突然发现考核变严了，流程变多了，周报越写越长，汇报越做越细，先别急着反思是不是自己不够努力。
-
-先看业务。
-
-如果业务是好的，这些东西很多时候只是形式主义，未必真会落到你头上，适当配合就行。
-
-但如果业务已经明显承压，而组织又开始把很多精力放到考核、打分、追踪、排名这些事上，那你最好多留个心眼。因为这往往不是转机的开始，更像是管理层开始没底了。
-
-你要判断的是，这到底只是短期波动，还是结构性问题。
-
-如果只是短期波动，扛一扛也许能过去；如果是结构性问题，那你就要想清楚，这家公司后面是准备解决问题，还是准备把压力层层往下传。
-
-这两者区别很大。
-
-我后来不管选团队还是看组织，都会多看一眼：这地方到底是靠什么在驱动？是靠共识、目标和基本信任，还是靠考核、压力和持续盯人？
-
-前者不一定就能成，但至少队伍还像个队伍。
-
-后者短期可能会显得很有执行力，但时间一长，通常都会跑偏。
-
----
-
-最后说一句。
-
-OKR 也好，KPI 也好，本来都只是工具。工具本身不会自动变坏，但一旦它开始承担“缓解老板焦虑”“证明组织还在掌控中”这些额外功能，它就很容易变味。
-
-所以很多时候，真正该问的不是“要不要强化考核”，而是：**我们现在到底是在解决问题，还是在制造一种自己还控制得住局面的幻觉。**

source/_posts/工作.md

@@ -1,49 +1,32 @@
-title: Java开发工程师、全栈开发工程师
+title: 研发负责人 / 研发专家
 author: Gamehu
-date: 2025-02-22 19:31:46
+date: 2026-03-24 23:31:46
 tags: 求职
 ---
 
-### Java开发工程师、全栈开发工程师
-亲爱的招聘团队：
+### 研发负责人 / 全栈工程师
 
-如果软件工程师是一道菜，那我就是那种经过12年慢火熬制的老汤底——看起来平淡无奇，但一尝就知道功夫在里头。
+各位好，
 
-我的技术栈就像一个资深玩家的技能树：主技能点满了Java和React，副技能解锁了Vue、Docker、Python和Go等。在我的职业旅程中，我善于将复杂问题分解为简单模块，轻松应对各种技术挑战。但我最厉害的外挂其实是曾经当过产品助理——这让我不仅能听懂产品经理说的"简单调整"背后隐藏的36个子需求，还能在技术与业务之间自如翻译，堪称"产品语言通"。
+13年一线研发，后端10年（主Java）、前端3年（主React），从写代码到带团队到架构设计，该踩的坑基本都踩过了。
 
-在我的12年职业生涯中，我从"这bug在本地没问题啊"进化到了"这需求有啥实际意义"再到"好的，我来搞定！"。带团队的经历让我明白，比起Debug代码，Debug人际关系才是真正的高难度挑战。所幸，我在这两方面都交出了不错的成绩单。
+上一段经历，从0到1组了个团队，主导了AI+SaaS宠物医院系统的架构设计和落地，3个月上了1.0版本，拿到天使客户认可。再之前在锐捷网络干了7年多，从前端主程做到Java主程再到LMT负责人，带过10人团队，负责过500+租户的SaaS运维平台核心模块。连续两年绩效A，拿过事业部优秀员工。
 
-相信我的技术能力、产品思维和团队协作经验能为您的团队带来实质性的贡献。代码之外，我能够搭建开发者与产品、业务之间的桥梁，确保我们不只是在开发功能，而是在创造价值。我们一定能擦出技术的火花——毕竟，一个能理解产品、带过团队、写了12年代码还没秃顶的工程师，不是每天都能遇到的。
+技术上，Java全家桶、React、微服务、数据库那些就不赘述了。比较有意思的是做过AI工程化落地——ASR医疗记录生成、RAG知识库、服务器容量预测（ClickHouse + Flink + Prophet + LLaMA2）。另外当过产品助理这段经历，让我在技术和业务之间能自如切换，不会出现"需求理解偏差导致返工"这种事。
 
-代码问候，
-[软件开发特种兵]
-
-联系方式：
-电话：[18515068121]
-邮箱：[gamehu@yeah.net]
-Wechat：[GamehuDB]
-
-P.S. 我的GitHub贡献图可能不够绿，但我的生产环境代码从不让服务器变红。
-
-
-### Java Development Engineer/Full Stack Development Engineer
+带团队这事，比Debug代码难多了。但好在两边成绩单都还过得去。
 
-Dear Hiring Team:
+详细简历在这里：
 
-If software engineers were dishes, I'd be that slow-simmered stock that's been cooking for 12 years — looking unassuming, but one taste reveals the expertise within.
+- [中文简历](/resume/)
+- [English Resume](/resume/en.html)
 
-My tech stack resembles a veteran player's skill tree: maxed-out primary skills in Java and React, with unlocked secondary abilities in Vue, Docker, Python, Go, and more. Throughout my professional journey, I've honed the ability to break complex problems into simple modules, easily tackling various technical challenges. But my most powerful perk comes from my experience as a product assistant — I can decode the 36 hidden sub-requirements behind a product manager's "simple adjustment" and fluently translate between technical and business languages, making me a true "product whisperer."
-
-During my 12-year career, I've evolved from "but the bug doesn't appear on my local machine" to "what's the actual purpose of this requirement" to "I'll handle it!" My team leadership experience taught me that debugging human relationships is far more challenging than debugging code. Fortunately, I've managed to achieve good results in both areas.
-
-I believe my technical abilities, product mindset, and team collaboration experience will bring substantial value to your team. Beyond coding, I can build bridges between developers, product teams, and business units, ensuring we're not just developing features but creating value. We'll definitely create technical sparks together — after all, an engineer who understands products, has led teams, and has written code for 12 years without going bald isn't someone you meet every day.
-
-Code regards,
-[Software Development Special Forces]
+代码问候，
+Gamehu
 
-Contact Information:
-twitter：[Gamehu520]
-email：[gamehu@yeah.net]
-Wechat：[GamehuDB]
+联系方式：
+电话：18515068121
+邮箱：<gamehu@yeah.net>
+Wechat：GamehuDB
 
-P.S. My GitHub contribution graph might not be very green, but my production code never turns servers red.
+P.S. 我的GitHub贡献图可能不够绿，但我的生产环境代码从不让服务器变红。

source/_posts/我现在对宠物行业AI+SaaS架构的几个判断.md

@@ -1,7 +1,7 @@
 ---
-title: 我做完宠物行业 AI + SaaS 第一版后，对这套架构的几个判断
+title: 宠物行业 AI + SaaS 第一版上线后，我对这套架构的几点复盘
 author: Gamehu
-date: 2026-03-23 18:18:00
+date: 2026-03-23 22:18:00
 tags:
   - AI
   - SaaS
@@ -20,18 +20,18 @@ categories:
 
 先说明一下，我不是专业架构师。
 
-之前在上一家公司，我更多做的是一些模块和组件级别的设计，真正意义上从 0 到 1 去设计一整套 AI + SaaS 系统，这次算是第一次，而且第一版已经上线了。
+之前在上一家公司，我更多做的是一些模块和组件级别的设计。真正意义上从 0 到 1 去设计一整套 AI + SaaS 系统，这次算是第一次，而且第一版已经上线了。
 
-所以这篇不是站在一个“很懂架构的人”视角来讲方法论，更像是我做完第一版以后，老老实实回头看一遍：这套架构到底哪里想对了，哪里其实一开始很容易想偏，后面又该往哪个方向继续长。
+所以这篇不是想讲什么大方法论，也不是想摆什么架构姿势。我就是想趁第一版刚做完、产品也刚上线这个节点，老老实实回头看一遍：这套架构到底哪里想对了，哪里其实一开始很容易想偏，后面又该往哪个方向继续长。
 
 场景并不抽象，就是很实际的那种：
 
-- 1个或者N个宠物医院
+- 单机构起步，但架构上要预留多机构扩展能力
 - 后续希望还能继续扩
 
-最开始我脑子里也闪过很多“终局形态”的东西，比如实时音频、拾音器、边缘盒子、流式 ASR、自动生成病历之类。但越往后想，我越觉得这事不能按“终局幻想”来起手。
+最开始我脑子里也闪过很多“终局形态”的东西，比如实时音频、拾音器、边缘盒子、流式 ASR之类。但第一版真的做下来以后，我反而更确定，这事不能按“终局幻想”来起手。
 
-因为我现在做的不是写一份 PPT，也不是做一个看起来很唬人的全景图，而是在想：<span class="highlight-text">如果这套软件第一次真的要从 0 到 1 落地，我当前这版架构最该优先解决什么，最不该一开始就做什么。</span>
+因为我做的不是写一份 PPT，也不是画一个看起来很唬人的全景图，而是在想：<span class="highlight-text">第一次真把产品做出来并上线时，这版架构最该优先解决什么，最不该一开始就做什么。</span>
 
 所以这篇我不想从科普角度写，也不想从“终局方案”往回倒推，我就想站在“第一版已经做完并且上线了”这个节点上，回头复盘一下我对这套架构的几个真实判断，以及我对下一阶段的打算。
 
@@ -40,7 +40,7 @@ categories:
 一个是，架构这事基本不可能一开始就设计到终局。真要硬往“一步到位”去做，很多时候不是做重了，就是做偏了。  
 但反过来也不能只盯着眼前这点需求，完全不看后面，不然技术债很容易越滚越大。
 
-所以我现在更认可的状态是：<span class="highlight-text">别做超前设计，但也别把明天大概率会出问题的坑，当成今天看不见。</span>
+所以我现在更认可的状态是：<span class="highlight-text">别做过度/超前设计，但也别把明天大概率会出问题的坑，当成今天看不见。别把技术债留得过多过重</span>
 
 另一个是，架构不能脱离业务自己玩。  
 对我来说，架构不是先设计一套很漂亮的东西，再让业务来适配它，而是业务走到哪一步，架构就支撑到哪一步，同时再比当前业务多想半步。
@@ -63,11 +63,11 @@ categories:
 
 如果不用那些太虚的词，只说我自己现在真正在想的东西，这套系统至少得先把这些基础问题想清楚：
 
-- 集团、中心医院、诊所之间怎么分层
+- 多租户怎么做，集团、中心医院、诊所之间怎么分层
 - 一个集团下面多门店怎么表达
-- 总部、店长、医生、护士分别能看什么、做什么
+- 权限模型怎么设计，总部、店长、医生、护士分别能看什么、做什么
 - 宠物、主人、就诊、病历、经营数据这些核心对象怎么设计
-- 门店在用的能力和总部在用的能力怎么拆
+- 门店在用的能力和总部在用的能力怎么拆，也就是服务边界怎么划
 - 哪些数据共享，哪些数据隔离
 - AI 和后面的第三方能力从哪里接进来
 
@@ -77,10 +77,10 @@ categories:
 
 而且这里还有一个我现在越来越重视的点：<span class="highlight-text">软件架构不能脱离业务目标单独存在。</span>
 
-我做这套产品，不是为了做一个“功能很多的宠物行业工具箱”，而是希望软件能真正深入到客户的经营和日常管理里，最终达到两个目标：
+我们做这套产品，不是为了做一个“功能很多的宠物行业工具箱”，而是希望软件能真正深入到客户的经营和日常管理里，最终达到两个目标：
 
 1. 提升一线执行效率
-2. 辅助总部和门店做经营决策
+2. 辅助决策
 
 如果离开这两个目标去谈架构，很多设计最后都会变成自嗨。
 
@@ -96,13 +96,13 @@ categories:
 传统 SaaS 更多是在处理确定性流程。  
 比如录入、查询、审批、结算、统计，这些本质上都是规则系统。
 
-而 AI + SaaS 不一样的点在于，它把一个“不完全确定”的处理环节塞进了原本确定的业务链路里。
+而 AI + SaaS 不一样的点在于，它把一个“结果不那么稳定”的处理环节塞进了原本稳定的业务链路里。
 
 第一版做下来，我还是觉得这就是两者最大的区别。
 
 不是多了一个模型服务，也不是页面上多了一个 AI 按钮，而是：
 
-<span class="highlight-text">原来的系统主要在处理规则，现在我要开始处理概率。</span>
+<span class="highlight-text">原来的系统主要是在执行确定规则，现在我要开始想办法把“不那么稳定的结果”稳稳地放进业务流程里。</span>
 
 这件事一旦成立，很多设计思路都会跟传统 SaaS 不一样。
 
@@ -140,6 +140,13 @@ categories:
 
 这几个问题如果不单独设计，AI 最后就很容易变成系统里一个“看起来高级，但责任全是人工兜底”的模块。
 
+而且这里我现在回头看，除了“人工确认”本身，还少不了几件配套的事：
+
+- 要有校验
+- 要有留痕
+- 要能审计
+- 要知道是模型错了、流程错了，还是输入本身就有问题
+
 再往业务上说得直白一点。
 
 传统 SaaS 在大多数时候更像一个被动工具：
@@ -168,7 +175,7 @@ categories:
 
 所以我现在回头看，第一版里最正确的一条原则就是：
 
-<span class="gradient-text">AI 先做增强，不直接做裁决；先做草稿，不直接做真相。</span>
+<span class="gradient-text">AI 先做增强，不直接做裁决；先做草稿，不直接做真相。总之一定要预留口子让人工能参与到最终结果中</span>
 
 这也是我现在跟传统 SaaS 设计思路分叉最明显的地方。
 
@@ -352,6 +359,19 @@ categories:
 
 这层不是附属物，是骨架的一部分。
 
+而且从上线后的视角看，这层不只是为了“把流程串起来”，它本质上还承担了稳定性和兜底职责。
+
+至少在我现在的理解里，这一层后面一定要逐步补齐这些能力：
+
+- 用状态机管理任务流转，而不是靠 if else 到处补
+- 幂等处理，避免重复提交、重复执行
+- 失败重试，但不能无限重试
+- 超时控制，避免模型调用把主链路拖死
+- 降级策略，模型不稳定时至少不能把核心业务流程卡住
+- 可观测性，要能看到任务卡在哪一步、失败在哪一步
+
+说白了，AI 任务层不只是“调一次模型”，它后面其实是一个带容错和兜底能力的处理链路。
+
 而且我现在已经能感觉到，到了下一阶段，光有任务层可能还不够，后面很可能还会自然长出一块专门做经营分析、异常提醒、辅助判断的能力。
 
 因为一旦系统开始服务经营和管理，它就不能只停留在“帮你生成一段文字”，而要开始回答这些问题：
@@ -399,6 +419,12 @@ flowchart TD
 
 这个边界不清，后面系统只会越来越难收。
 
+而且上线以后我更确定一点：任何模型调用失败、结构化失败、结果不稳定，都不应该阻断核心业务流程。
+
+也就是说，AI 这条链路可以失败，可以降级，可以回退到人工处理，但不能把主业务链路一起拖死。
+
+这个在我看来其实也是架构设计里很现实的一部分，不能只想着“AI 成功时多聪明”，还得提前想好“它失败时系统怎么活”。
+
 但另一方面，我也不认为 AI 永远只该停留在“建议层”。
 
 我现在对下一阶段的看法是：
@@ -425,7 +451,7 @@ AI + SaaS 如果做得足够深，是有机会从“把流程记下来”走向
 
 1. 这套系统的底子依然是 SaaS，不是先上 AI 再补业务
 2. 软件架构不能脱离业务目标，我的目标不是做工具，而是深入客户经营和日常管理
-3. AI + SaaS 和传统 SaaS 的区别，核心在于我要处理一个“概率性能力”进入业务链路后的责任边界
+3. AI + SaaS 和传统 SaaS 的区别，核心在于我要处理一个“结果不那么稳定的能力”进入业务链路后的责任边界
 4. 第一版最重要的是业务闭环，不是实时
 5. 第一版不上拾音器，也不上边缘盒子，这个取舍我现在依然认
 6. 第一版更像一个带 AI 助手能力的 SaaS，而不是 AI IoT 系统

source/resume/en.md

@@ -0,0 +1,179 @@
+---
+title: Huantao Hu - Resume
+date: 2025-02-22 19:31:46
+type: resume
+comments: false
+---
+
+## Basic Information
+
+| | |
+|---|---|
+| **Name** | Huantao Hu |
+| **Experience** | 13 years |
+| **Email** | gamehu@yeah.net |
+| **Phone** | +86 18515068121 |
+| **Blog / WeChat Official Account** | [gamehu.run](https://gamehu.run) / Gamehu |
+| **Education** | B.S. Computer Science, Chongqing University of Science and Technology |
+
+---
+
+## Highlights
+
+- **12+ years hands-on development** — 10 years backend (Java-centric), 3 years frontend (React-centric), full-depth capability from coding to architecture
+- **4+ years team management** — built teams from scratch, established OKR systems, defined engineering standards and delivery workflows
+- Led **AI+SaaS product architecture** from inception to launch, validated by pilot customers
+- Drove core module development for a **500+ tenant SaaS platform** at Ruijie Networks; consecutive A-rated performance reviews, received division-level Outstanding Employee award
+- Strong **enterprise architecture** skills: microservice decomposition, multi-tenant isolation, data pipelines, AI engineering
+- Proficient with Alibaba Cloud and AWS; consistently drove technical standardization and DFX practices within teams
+
+---
+
+## Tech Stack
+
+| Area | Technologies |
+|---|---|
+| **Backend** | Java, Spring Boot, Spring Cloud, Python, Go |
+| **Frontend** | React, Vue, GraphQL |
+| **Databases** | PostgreSQL, MySQL, Oracle, ClickHouse, Redis, MongoDB, Elasticsearch |
+| **Middleware** | Kafka, Pulsar, RabbitMQ, Flink, Zookeeper, xxl-job |
+| **AI / ML** | LLM integration (LLaMA2/Ollama), ASR engineering, RAG knowledge base |
+| **DevOps** | Docker, Kubernetes, Nginx, Prometheus, Arthas |
+| **Cloud** | Alibaba Cloud, Volcengine, AWS |
+
+---
+
+## Work Experience
+
+### Sichuan Gongshantou AI Technology Co., Ltd. · Head of R&D
+**2025-03 – Present | Chengdu**
+
+#### Luling AI Veterinary Hospital Smart System
+
+An AI+SaaS management platform embedded in the full veterinary hospital workflow — addressing SOP standardization, consultation quality improvement, talent replication, and pharmacy management to achieve efficiency and decision-support closed loops.
+
+**Tech Stack:** Spring Cloud · ASR · React · Flutter · UniApp · Nacos · xxl-job · ClickHouse · Redis · PostgreSQL · Docker · Prometheus
+
+**Key Responsibilities:**
+
+- **Team Building**: Built the R&D team from scratch — recruitment, role allocation, talent pipeline planning, and established engineering standards and delivery processes
+- **Architecture Design**: Led overall AI+SaaS architecture covering multi-tenant isolation, AI workflow orchestration, and ASR-based medical record generation; completed technology selection, architecture reviews, and reliability design
+- **Technical Roadmap**: Aligned technical evolution path with business roadmap, driving milestone-based delivery
+- **Core Development**: Hands-on coding for core modules; maintained code quality through code reviews and detailed design reviews
+  - Java: real-time keyword matching, multi-device audio capture, AI data extraction
+  - Python: edge device multi-stream second-level screenshot capture
+- **DFX Resolution**: Resolved technical debt issues — e.g., optimized a system handling 2,000 diagnostic keywords with 3s real-time matching under 30 concurrent sessions, achieving 10x performance improvement after refactoring
+- **Results**:
+  - Built strong team self-drive culture
+  - Established efficient development cadence and production monitoring system
+  - Shipped v1.0 within 3 months, earning pilot customer validation and stable partnership
+
+---
+
+### Ruijie Networks Co., Ltd. · Java Tech Lead / Frontend Tech Lead / LMT Lead
+**2017-10 – 2025-01 (7 years 3 months) | Chengdu**
+
+#### Cloud Co-pilot Intelligent O&M Platform
+
+Alibaba Cloud-based SaaS O&M platform (10+ developers, 500+ tenants) providing cloud-ground unified monitoring, AI algorithms, and CRM capabilities for proactive service and 24/7 support.
+
+**Tech Stack:** Spring Cloud · Vue · UniApp · Flowable · Powerjob · Flink · ShardingSphere · Pulsar · ClickHouse · Redis · PostgreSQL · Docker · K8s
+
+**Key Responsibilities (Java Tech Lead):**
+
+- Owned detailed design and implementation of CRM, task board, tenant notification, task strategy, and complaint tracking modules
+- Led **DFX system consolidation**: concurrent strategy triggering, core business monitoring, sharded query performance optimization
+- Completed **server capacity prediction architecture validation** (ClickHouse + Flink + Prophet + LLaMA2), driving AI capability productization
+- Managed cloud platform DevOps (Docker/K8s) and production incident response
+
+---
+
+#### Lexiang Intelligent O&M Management Platform
+
+Flagship O&M platform (70+ developers, ~¥100M annual revenue) with metrics-driven unified resource monitoring across 15+ functional modules including visualization center, work center, monitoring center, and alert center.
+
+**Tech Stack:** Spring Boot · React · eggjs · Kafka · ClickHouse · Flink · ArangoDB · PostgreSQL · Redis · Python · Go · Docker · K8s
+
+**Key Responsibilities:**
+
+**① LMT Lead (~3 years | 10-person team)**
+- **Team Management**: Built and managed a 10-person cross-functional team; defined member profiles and annual OKRs; established team performance evaluation mechanisms
+- **Engineering Standards**: Defined field defect handling processes and technical standards; tracked issue resolution progress
+- **Technical Problem Solving**: Led on-site K8s service availability issue resolution (environment, network, service stability); drove DFX consolidation and implementation
+- **Data-Driven Efficiency**: Built a Python + Vue analytics system for field bug distribution and team efficiency metrics
+- **AI Engineering Practice**: Deployed a private knowledge base using AnythingLLM + Ollama for field issue resolution
+- **Cross-Team Collaboration**: Coordinated cross-team communication, resource alignment, and progress tracking
+
+**② Java Tech Lead**
+- Owned detailed design and API development for strategy management, alert center, data warehouse, and resource discovery modules
+- Led **master data center core API design and development** (CMDB · Model · Strategy · Federated Query)
+- Code Review
+
+---
+
+#### Cheetah Intelligent O&M Platform
+
+A business O&M management tool (30+ developers) enabling proactive closed-loop fault handling: detection → analysis → localization → resolution.
+
+**Tech Stack:** Spring Boot · React · eggjs · Kafka · ClickHouse · Flink · PostgreSQL · Redis · GraphQL · Dubbo · Docker
+
+**Key Responsibilities (Frontend Tech Lead / Full Stack):**
+- Led frontend technology selection and evaluation (React · eggjs · Formily); built the frontend component library and established frontend development standards
+- Developed core frontend modules for business experience center, alert center, and traffic analysis center
+- Led frontend code reviews
+- Set up backend project scaffolding; implemented backend modules including system configuration
+
+---
+
+### Chengdu Dispuna Co., Ltd. · Web Team Lead
+**2017-04 – 2017-10 (6 months) | Chengdu**
+
+#### Big Data Intelligent O&M Platform
+
+A log analysis and host monitoring platform for financial industry O&M teams (8 developers), processing hundreds of MB to several GB of log data daily.
+
+**Tech Stack:** Spring Boot · Vue · Kafka · HBase · Hadoop · Storm · Redis · Elasticsearch · MySQL · Dubbo
+
+**Key Responsibilities (Web Team Lead, 3 members):**
+- Managed team member goals and performance; rotated as ScrumMaster, driving daily standups and task tracking
+- Owned core business design and implementation: Kafka consumption, real-time push, ES index construction
+- Completed log data ETL and Kafka cluster multi-instance validation
+
+---
+
+### Elane (Beijing) Data Technology Co., Ltd. · Java Developer
+**2016-03 – 2017-03 (1 year)**
+
+#### Container Shipping Management SaaS Platform
+
+During the monolith-to-SaaS refactoring transition — responsible for platform maintenance, Redis Sentinel multi-instance session sharing implementation, enterprise client requirement assessment and delivery, Express + MongoDB async data exchange center development, and new hire mentoring.
+
+**Tech Stack:** Spring · Kafka · Redis · MySQL · Zookeeper · Docker · MongoDB · Spark · Hive · Node.js
+
+---
+
+### Beijing Zhongke Fulong Technology Co., Ltd. · Product Assistant
+**2015-06 – 2016-03 (9 months)**
+
+Handled business requirement research, requirement documentation, client relationship management, and project planning coordination for digital factory and State Grid energy management platform projects.
+
+---
+
+### Beijing Shenzhou Aerospace Technology Co., Ltd. · Java Developer
+**2013-04 – 2015-06 (2 years 2 months)**
+
+Participated in detailed design, coding, unit testing, and documentation for the Aerospace Model Collaborative Development Management System (AVDPM) and Product Data Package System Phase 1.
+
+**Tech Stack:** Oracle · SQL Server · Java · jQuery
+
+---
+
+## Education
+
+| University | Major | Degree |
+|---|---|---|
+| Chongqing University of Science and Technology | Computer Science and Technology | Bachelor's |
+
+---
+
+[中文版本](/resume/)

source/resume/index.md

@@ -0,0 +1,179 @@
+---
+title: 扈焕涛 - 简历
+date: 2025-02-22 19:31:46
+type: resume
+comments: false
+---
+
+## 基本信息
+
+| | |
+|---|---|
+| **姓名** | 扈焕涛 |
+| **工作年限** | 13年 |
+| **邮箱** | gamehu@yeah.net |
+| **电话** | 18515068121 |
+| **博客/公众号** | [gamehu.run](https://gamehu.run) / Gamehu |
+| **学历** | 本科 · 重庆科技大学 · 计算机科学与技术 |
+
+---
+
+## 个人亮点
+
+- **12年+一线研发经验**，后端10年（主Java）、前端3年（主React），具备从编码到架构的完整技术纵深
+- **4年+团队管理经验**，有从0到1组建团队、制定OKR、建立研发规范与交付体系的完整实践
+- 主导过 **AI+SaaS 产品从立项到上线**的全链路架构设计，并获得天使客户验证
+- 在锐捷网络主导 **500+ 租户 SaaS 平台**核心模块研发，连续两年绩效A，获事业部优秀员工奖
+- 具备 **企业级系统架构**设计能力：微服务拆分、多租户隔离、数据流水线、AI 工程化落地
+- 熟练使用阿里云、AWS；在团队内持续推动技术标准化、DFX 落地
+
+---
+
+## 技术栈
+
+| 方向 | 技术 |
+|---|---|
+| **后端** | Java、Spring Boot、Spring Cloud、Python、Go |
+| **前端** | React、Vue、GraphQL |
+| **数据库** | PostgreSQL、MySQL、Oracle、ClickHouse、Redis、MongoDB、Elasticsearch |
+| **中间件** | Kafka、Pulsar、RabbitMQ、Flink、Zookeeper、xxl-job |
+| **AI / ML** | LLM 集成（LLaMA2/Ollama）、ASR 工程、RAG 知识库 |
+| **DevOps** | Docker、Kubernetes、Nginx、Prometheus、Arthas |
+| **云平台** | 阿里云、火山云、AWS |
+
+---
+
+## 工作经历
+
+### 四川攻山头人工智能科技有限公司 · 研发负责人
+**2025-03 ~ 至今 | 成都**
+
+#### 鹿瓴 AI 宠物医院智慧系统
+
+嵌入宠物医院全流程的 AI+SaaS 经营管理平台，解决 SOP 标准制定、医生问诊质量提升、人才复制、药品管理等核心管理与执行痛点，实现提效与辅助决策闭环。
+
+**技术栈：** Spring Cloud · ASR · React · Flutter · UniApp · Nacos · xxl-job · ClickHouse · Redis · PostgreSQL · Docker · Prometheus等
+
+**主要职责：**
+
+- **团队建设**：从0到1组建研发团队，完成人员招募、角色分工与梯队规划，制定研发规范与交付流程
+- **架构设计**：主导 AI+SaaS 整体技术架构设计，覆盖多租户隔离、AI 流程编排、ASR 医疗记录生成等核心模块；完成技术选型、架构评审与可靠性设计
+- **技术路线规划**：结合业务 Roadmap 制定技术演进路径，推动阶段性版本按节点交付
+- **核心开发**：参与核心模块编码，通过 Code Review、核心功能的详设评审等活动把控代码质量与技术标准落地
+  - Java 处理关键词实时命中、多端收音、AI 数据抽取等需求实现
+  - Python 边缘盒子多视频流秒级截图需求实现
+- **DFX 问题处理**：为技术债等问题提供解决方案或执行重构解决问题，比如诊疗2000个关键词需对话中3s命中+30并发问题的解决，重构优化后性能提升10倍
+- **成果**：
+  - 构建了较好的团队自驱力
+  - 建立了较高效的开发节奏和线上监控体系
+  - 3个月完成1.0版本上线，获得天使客户认可并建立稳定合作
+
+---
+
+### 锐捷网络股份有限公司 · Java 主程 / 前端主程 / LMT 负责人
+**2017-10 ~ 2025-01（7年3个月）| 成都**
+
+#### 云辅驾智能运维平台
+
+基于阿里云的 SaaS 运维平台（研发10+，接入500+租户），为集团内部服务团队提供云地一体监控、AI 算法及 CRM 等能力，实现主动服务与7×24保障。
+
+**技术栈：** Spring Cloud · Vue · UniApp · Flowable · Powerjob · Flink · ShardingSphere · Pulsar · ClickHouse · Redis · PostgreSQL · Docker · K8s
+
+**主要职责（Java 主程）：**
+
+- 负责 CRM、任务看板、租户平安通告、任务策略、投诉跟进等**核心模块详细设计与编码**
+- 主导 **DFX 体系整理与落地**：并发策略触发、核心业务监控、分表查询等关键性能治理
+- 完成**服务器容量预测技术架构验证**（ClickHouse + Flink + Prophet + LLaMA2），推动 AI 能力工程化
+- 负责云平台日常 DevOps（Docker/K8s）及线上故障定位处理
+
+---
+
+#### 乐享智能运维管理平台
+
+旗舰运维平台（研发70+，年销售额约1亿），以指标体系为核心实现全域资源统一监控，覆盖可视中心、工作中心、监控中心、告警中心等15+功能模块。
+
+**技术栈：** Spring Boot · React · eggjs · Kafka · ClickHouse · Flink · ArangoDB · PostgreSQL · Redis · Python · Go · Docker · K8s
+
+**主要职责：**
+
+**① LMT 负责人（接近3年 | 团队10人）**
+- **团队管理**：组建并管理10人跨职能团队，制定成员画像与年度 OKR，建立团队绩效评估机制
+- **研发规范建设**：制定现场缺陷处理流程与技术规范，跟进故障处理进度
+- **技术问题攻坚**：主导现场 K8s 服务可用性问题处理（环境、网络、服务稳定性），主导 DFX 梳理与落地
+- **效能数字化**：使用 Python + Vue 自建数据分析系统，统计现场 Bug 分布与人效数据
+- **AI 工程化实践**：基于 AnythingLLM + Ollama 搭建现场问题私有知识库
+- **跨团队协作**：负责跨团队沟通协调、资源对接与进度推进
+
+**② Java 主程**
+- 负责策略管理、告警中心、数据仓库、资源发现等模块详细设计与接口开发
+- 主导**主数据中心核心 API 设计与开发**（CMDB · 模型 · 策略 · 联邦查询）
+- Code Review
+
+---
+
+#### 猎豹智能运维平台
+
+研发规模30+的业务运维管理工具，实现从被动排障到主动闭环的故障感知→分析→定位→解决全链路能力。
+
+**技术栈：** Spring Boot · React · eggjs · Kafka · ClickHouse · Flink · PostgreSQL · Redis · GraphQL · Dubbo · Docker
+
+**主要职责（前端主程 / 全栈）：**
+- 负责前端技术选型预研（React · eggjs · Formily），搭建前端组件库，制定前端开发规范
+- 开发业务体验中心、告警中心、流量分析中心等核心前端模块的详细设计与编码
+- 主持前端 Code Review
+- 搭建后端项目脚手架；负责系统配置等模块后端编码
+
+---
+
+### 成都迪斯普纳股份有限公司 · Web 小组负责人
+**2017-04 ~ 2017-10（6个月）| 成都**
+
+#### 大数据智能运维平台
+
+面向金融行业运维团队的日志分析与主机监控平台（研发8人），每日处理百MB至数GB量级日志数据。
+
+**技术栈：** Spring Boot · Vue · Kafka · HBase · Hadoop · Storm · Redis · Elasticsearch · MySQL · Dubbo
+
+**主要职责（Web 小组负责人，3人）：**
+- 负责团队成员目标管理与绩效管理；轮值 ScrumMaster，推进全团队站会与任务跟踪
+- 负责核心业务设计与编码，Kafka 消费、实时推送、ES 索引构建
+- 完成日志数据 ETL 及 Kafka 集群多实例验证
+
+---
+
+### 亿海蓝（北京）数据技术股份公司 · Java 开发工程师
+**2016-03 ~ 2017-03（1年）**
+
+#### 集装箱运输管理 SaaS 平台
+
+正处于单体应用向 SaaS 架构重构转型期，负责平台维护、Redis Sentinel 多实例 Session 共享方案落地、大客户需求评估与落地、Express + MongoDB 异步数据交换中心开发，及新人带教。
+
+**技术栈：** Spring · Kafka · Redis · MySQL · Zookeeper · Docker · MongoDB · Spark · Hive · Node.js
+
+---
+
+### 北京中科辅龙科技股份有限公司 · 产品助理
+**2015-06 ~ 2016-03（9个月）**
+
+承担数字工厂、国家电网能源管控平台两个项目的业务需求调研、需求文档编写、客户关系维护与项目计划协调。
+
+---
+
+### 北京神舟航天科技技术有限公司 · Java 开发工程师
+**2013-04 ~ 2015-06（2年2个月）**
+
+参与航天型号协同研制管理系统（AVDPM）及产品数据包系统一期的功能模块详细设计、编码、单元测试与文档编写。
+
+**技术栈：** Oracle · SQL Server · Java · jQuery
+
+---
+
+## 教育背景
+
+| 学校 | 专业 | 学历 |
+|---|---|---|
+| 重庆科技大学 | 计算机科学与技术 | 本科 |
+
+---
+
+[English Version](/resume/en.html)