25年8月跳槽来，我的大模型应用开发实战、思考与感悟

25年8月跳槽来，我的大模型应用开发实战、思考与感悟

从Go硬写摄像头拉流，到用AI搭建一套完整的研发工作台，这大半年我都经历了什么？

写在前面：为什么跳槽？

先聊聊跳槽这事儿，多种因素的叠加！！！

钱没给够？受委屈了？——马总说的话确实到位，但我还有如下原因

前公司的前端相对简单，一两年开发经验的人完全可以掌握，虽然我自己不断的去学习后端的知识，想去切一部分后端的蛋糕到自己团队里，在一些内部业务系统中全栈梭哈，做了不少全栈的项目，但总感觉上不了台面，都是些皮毛。 25年的就业环境比今年好，但我反而焦虑了——如果AI连代码都能写，我这CRUD的手艺还值几个钱？

25年4月，AI真的闯进了我的世界。

以前看AI都是新闻里、视频里，离自己很远。直到我装了vscode的 Continue 插件——我靠，太强了。当时在做一些内部系统，文档顶部注释写好，直接生成代码，感觉效率提升了百分之二三十。

没过多久又装了cline，这玩意儿稍微有了点 解放双手 的感觉，能直接完成单个核心功能或者小模块的开发。记得当时，有一个需要基于Go开发一个摄像头拉流直播展示的功能——我压根不会Go，结果两天梭哈出来了。具体的操作也就是从github上拉去了个类似的demo项目，然后让cline分析代码，给出修改的逻辑，就这麽问着问着，开发好了。。。大概就类似下面这样

这个经历让我产生了一个强烈的念头：当前CRUD的业务真的到头了。AI应该会是下一步开发必会的技能

于是，我开始了学习。

入门：从两个小项目开始

学习这东西，光看文档没用，得动手。

项目一：TinyAgent 链接

同事给的，一个调用大模型API、调用MCP工具、向量化文件的轻量级框架。大概就是改改提示词，实现QA功能，类似小型的智能客服。当时MCP这个概念还挺新鲜的，用起来的感觉就是——大模型终于能“动手”了。

这里补一个小科普：MCP（Model Context Protocol）是连接大模型与外部系统的标准化协议，核心价值在于解决模型与数据源的解耦问题，通过定义统一的数据交换格式，实现模型与知识库的动态绑定。简单说，没有MCP，大模型就是个“只动嘴不动手”的理论家。

相关链接：MCP官方文档

项目二：AI小智 官网链接

基于ESP32单片机做的一个语音对话机器人。流程大概是：拾取语音 → 转文字 → 调用大模型API → 调用MCP工具 → 语音回复，实现一个能真正对话的机器人。初始版本 傻妞 的感觉，当时我记得这个AI小智项目还上了新闻联播。

倒腾了半个月左右吧，被我本地跑通了，整体的技术栈还是挺丰富的，

掘金的视频还要上传西瓜，要不大家还能听到我优美的声音。。。

面试与选择

背景说明：本人19年毕业，25年已经有了近六年的开发经验，在前司呆了四五年了，所以第三份工作的选择很重要，核心考量，要不进大厂圆梦，要不就大模型高匹配，拥抱AI

面试过程就不细说了，有兴趣的评论区留言。面了一个月，拿了几家offer：字节、长川科技、当前公司。

最终选了现在的公司，原因有三：

1. 做大模型应用开发——这是我想要的赛道
2. 离家近——打工人的朴素愿望
3. 你猜。。

事实证明，当前找工作有一种吃别人拉的屎的感觉，不吃饿死，吃了恶心死，在当前这个几乎没有增量的环境中，任何一个岗位的空缺，肯定是上一个人干不下去了！！！

正式进入主题：我的大模型应用开发学习之路

第一阶段：25.8-25.11 大模型基础知识

工作内容：

刚入职，主要解决公司大模型应用的前端问题、性能优化、可扩展性等。说白了就是帮着擦屁股，顺便熟悉业务。

学习内容：

这三个月对整个大模型的概念清晰了很多：

• LLM（大语言模型）
• Prompt Engineering（提示词工程）
• Dify
• MCP（Model Context Protocol）
• Agent（智能体）
• 工作流（Workflow）
• LangChain / LangGraph

说人话就是：每天都在不停地测试、调试、踩坑,被业务推着走，在执行中理解，在理解中执行，真它 * 的是打破舒适区了。

RAG的概念也是这段时间系统了解的。RAG（检索增强生成）通过将外部知识注入生成过程，有效解决大模型的幻觉问题。核心就三步：检索、注入、生成。

想知道RAG、Agent、MCP更多细节的，可以看看这篇：AI技术栈"三巨头"深度解析

展示demo

真实项目复杂的多，是整个公司的智能中台，面向各个业务线提供支撑

总结/反思： 这个阶段自己关注的还是提示词工程、上下文工程、MCP工具、A2A协议等，浅显的理解 langchain 就是封装了各个大模型厂商的接口，做了一层中间层；langgraph 就是一个有向无环图，负责运行流程的控制和监控，方便有一定知识的业务人员搭建自己的agent。

算是入门了吧。相对于普通人，对大模型应用开发的概念理解得更深一点。但这段时间压力真的很大——基本每天加班到十点十一点，胖了十斤。

第二阶段：25.11-26.2 Spec工作流

背景：

原本的业务趋于稳定，提前三个月转正，被拉去做应用创新了。这个时候AI的风来得更猛，公司内部关于AI的需求越来越多。

相关概念：

• OpenSpec（规范驱动开发框架） —— 面向 AI 智能体的轻量级规范驱动开发框架，通过“提案-审查-实施-归档”工作流解决需求偏移问题
• Skill（技能） —— AI 的“能力封装”或“技能库”，将特定任务的执行方法打包成标准化格式，供 AI 按需加载使用
• Rules（规则） —— 预设的固定指令和硬约束，AI 必须始终遵守（如项目级行为规范、编码风格），与此相对，Skill 是按需调用的灵活能力
• Agent（智能体） —— 能够自主选择工具、编排执行步骤的 AI 系统，区别于被动的、固定流程的 Workflow
• CodeIDE（CodeBuddy、Trae 等） —— 集成 AI 编程能力的集成开发环境，如腾讯 CodeBuddy、字节 Trae，直接内嵌 AI 辅助开发功能
• MCP（Model Context Protocol） —— 由 Anthropic 推动的标准化开放协议，定义 AI 与外部数据源、工具的通用连接方式，类比 USB-TypeC 标准
• Superpowers 为AI编程代理（如Claude Code、Cursor等）设计的完整软件开发方法论
• Pencil 专为“Vibe Coding”时代打造的 AI原生设计工具。

工作内容：

通过规范驱动开发（SDD），搭建一个从文档驱动到整个模块开发、联调、上线的工作流。

这段时间的核心工作是理解Spec工作流的底层逻辑。刚开始觉得Skills、Rules、Agents组合一下，大模型就按照我的逻辑去跑了——神奇归神奇，但说不清所以然。经过一个多月的摸索，加上公司的培训，终于搞明白了：

Skill 是用来制定特定任务的工作流程的。比如炒蛋炒饭：第一步热锅、第二步倒油、第三步下蛋...有明确的执行顺序。 Rules是全局规则，可以按需加载也可以全局加载，用来约束大模型的行为边界。 Agent是执行具体任务的大脑，比如代码生成、自动化测试等。Agent可以调用工具、可以拆解任务、可以记忆历史。

那怎么理解Skill和Agent的区别呢?

Skill面向过程、Agent面向对象。

这个类比不一定完全精准，但能帮新手快速理解。

Rules的作用是提升正确率和稳定性——相当于给大模型装了刹车。

当时写的相关文档：Spec工作流开发实践

示意架构图：

思考： 到现在其实已经有一定工程化的感觉了，不在纯靠提示词、上下文等来单点的调用大模型的能力了，有点像是面向 AI 项目开发的脚手架，类似原生开发的 vue cli 和 spring boot，通过rules、skills、subagent在code agent harness工程上进行扩展，把代码的开发收敛到文档的编写上，确保最终代码的交付质量。

第三阶段：26.2-至今 搭建研发工作台

背景：

上述的工作流，更像是一个AI时代开发的脚手架、每个人拿到我的配置（skill、rules、agents）之后都需要基于其项目再改一遍。而且明面上问题很多：

• 没有监控系统
• 没有回调机制
• 没有记忆机制
• 没有可插拔的能力（别人写的Agent插不进流程）
• 没有根据任务的动态规划能力
• 非研发人员用起来不友好
• 核心原因：没有数据支持 KPI 都拉下去放到自己本地了，怎么体现这个东西的价值，太模糊了。。。

先学习下，再上点工程化手段

当时看了字节开源的DeerFlow2.0，它支持子代理编排、全能技能与工具箱、安全沙盒文件系统、上下文工程与长效记忆等能力。这种SuperAgent的调度中心设计思路深受启发。

学习内容：

• DeerFlow 源码 —— 字节跳动开源的 SuperAgent 编排框架，基于 LangGraph 构建多 Agent 协同（研究、规划、编码、审阅等），配备安全沙箱，适合搭建生产级 Agent 系统
• OpenHarness 源码 —— 香港大学数据智能实验室开源的轻量级 Agent Harness，约 1 万行 Python 实现 Claude Code 98% 核心能力，支持多种大模型，一条命令即可启动
• Hermes Agent 源码 —— Nous Research 开源的自我进化型 AI 智能体，内置失败经验→可复用 Skill 的闭环，跨会话记忆强制高密度压缩，星标破 10 万
• Superpowers 方法论 —— AI 编程代理的技能型开发方法学，强制先需求澄清与设计 → 编写计划 → TDD 驱动 → 子代理并行 → 代码审查 → 合并，解决 AI 后期走偏问题
• Python（补语言短板） —— 2026 年约 58% 开发者使用，Django/Flask/FastAPI 覆盖企业级到 AI 服务，补齐把 AI 能力变为可部署后端服务的基础能力
• Electron（做客户端） —— 基于 Chromium + Node.js 的跨平台桌面框架，一套代码覆盖 Windows/macOS/Linux，适合将 AI Agent 快速封装为独立桌面应用

大体实现思路：

根据用户选择的任务类型和相关配置，动态组装工作流，通过客户端实现整个流程的任务下发、中断、重启、监控、上报等。 类比一下：类似小龙虾或腾讯的WorkBuddy——一个执行代码开发任务的AI助手。 这套工作台的核心理念和OpenHarness很像：模型负责智力，Harness负责赋予它行动能力。

理解困难的可以先看下架构图和动态演示效果图

架构图：在线地址

动态演示：

在线Demo地址

几点思考与感悟

1.大模型开发 ≈ 面向Markdown文档开发

从26年开始，我基本没手写一行代码了。全部工作基于智能IDE或CLI开发。效率极大提升。

刚开始感觉有点生硬，大模型总是不按套路出牌。后来发现——只要你说的对，基本都Ok。AI给我一种“言出法随”的感觉。

2. 很多看起来很吊的技术，底层简单得离谱

• 很多Harness工程说自己Skill动态加载——其实就是提示词里加上Skill的name和description，匹配到了就读取对应的全局内容
• 记忆机制——说白了就是各种写Markdown总结文档，写入不同的文件，再添加到上下文中，厉害的放数据库像SQLite就够了
• 权限管控：添加hook钩子，执行工具前确认下就好了
• 隔离：单开个子进程、负责的上 docker
• 各种模式：paln、craft、ask等，本质只是系统提示词不一样

3. 只要学得慢，就不用学了

这句话说的人挺多的，有一定道理。不过适当的学习有助于理解整个演进的生命周期 —— 知道来龙去脉，才不容易迷路。

4. 别再看架构源码分析了，直接让AI输出架构更好

别人的分析不一定对。与其花时间理解别人的二手解读，不如直接让大模型分析原始代码。

像OpenHarness这类项目，核心是Python实现的轻量级Agent基础设施，涵盖工具调用、上下文记忆、权限治理、生命周期钩子和多Agent协同。它的设计哲学是“The model is the agent. The code is the harness.”——值得你直接去看源码。

5. 任何流程，只要能自闭环，终会消失 就和上面的工作台一样，当所有任务、数据、反馈、操作都能够实时监控，实时修改，那我们的价值在哪里、思考在哪里、沉淀在哪里。😀pua下自己。。。

6. 焦虑从来不会消失 快三十了，没大厂背景，行业看起来越来越卷，每天写文档到底积累了啥核心竞争力了？房贷能还完吗？自从进入这个行业，基本上每三个月都会投下简历，面试下，或者纯粹看看自己在市场的价值，今年是唯一一次简历投出去，没有收到面试邀约的。。。

这种焦虑偶尔会在深夜冒出来。但后来想想——与其焦虑，不如做点什么。

我的行动

• 开始写文档：虽然每次都觉得写得一般，但写出来再说，过两年无了，就当怀念了
• 做个人项目：一个简历智能生成的Agent，还在开发中，因为我真的不想根据每个岗位，改自己的简历
• 各种学习：开源的Harness工程源码、Python、奇奇怪怪的东西

如果有大佬愿意捞我的，私聊，小弟愿。。。