2025年CodeBuddy是如何拯救职场危机中的我？

​

一、

说一说这一年我的AI经历。

2025年我与CodeBuddy初相识，也是与社区初相识。

回首往事我不禁感慨，我这一年啊，过得太快了，时间不够用，脑子也不够用。

​

年初deepseek爆火了一把，火出圈了，冲击了我单位所在的行业，到处都是要结合deepseek搞大模型应用，AI替代人工的呼声甚嚣尘上，部署本地大模型成为了当务之急的zz正确。

准确的说是DeepSeek-R1。被宣传得神乎其神，似乎已经登上了世界之巅。

领导也着急忙慌，召集我们紧急开会讨论行业，啊不是，是本单位应用deepseek的可行性。

一夜之间，不懂技术的人心惶惶，仿佛AI的时代真的来临了！要降维打击了！

真的，有不少同事都怀疑单位会不会应用AI后裁员。

对于搞技术的，除了有被AI替代的风险不提，围绕这个本地部署，真的是纠结了不少人。

不时传来兄弟单位部署成功本地大模型这种炸裂消息，在我们领导耳边环绕，促使他的神经变得有些敏感和焦虑，而作为公司IT技术方面的主管人员，我的压力自然也非常之大。

二、

我这个人不太喜欢这种被动的感觉。于是我尝试找找出路。

好在我运气不错，很快在各种教程的指导下搞出来一套还算标准的攻略。

我也用ollama部署了本地蒸馏版进行了实践，不是满血版631b，单位没那个闲钱，也没有对应的设备物质基础，70b版也需要至少多张4090或者搞h100，这些我统统没有，只能单机搞了8b/14b的模型试试水，反正我觉得核心就是那么个意思搞明白怎么连接搭好架子跑起来就行。

虽然时至今日，我所在的行业到底应用怎么用好AI，仍然是未解之谜。但是这一点也不妨碍当时在那个泡沫鼓起来的时候加入狂欢。

cherrystudio、openwebui一类的便捷连接ollama本地的过程，我都搞定了，跑通了，一路磕磕碰碰，加上恶补的一个月transformer的知识，谈吐间我也俨然半个AI专家。当然Coze，Dify这些也接触了不少，什么工作流和智能体，但那都是后话了。

但是本地部署的demo如何产品化给领导看，这仍然让当时的我非常心虚。

这时候一个救星出现了，那就是codebuddy。

三、

大概25年的3月份左右，我从一个朋友那里偶然得知了腾讯云社区，当时主要是想研究腾讯元宝。又通过社区的广告宣传了解到了codebuddy可以对话式编程。

更幸运的事，机缘巧合我搭上了一位腾讯的产品大佬，从他那里我更加清晰的了解了codebuddy的用法，最新发布动态和一些官方活动，他的帮助使我能以极低的成本上车，真是难能可贵，感激不尽！

我试着在VS Code中安装部署好codebuddy的插件，这个过程很简单，当时随便在插件中一搜就有了。

当时开发大概是这个样子：

然后对话开发，直接让它帮我连接本地的ollama,然后搭建应用框架，顺着它的解析和开发代码，我很快就脱离了其他辅助工具，直接构建了自己的web页面，只用提供本地的接口信息，就可以调用我部署好的大模型服务进行前端对话呈现，这样理论上我做demo的技术路线就成了。

项目情况总结如下所示：

实现了一个基于本地知识库的问答系统，支持文档上传、知识向量化存储和语义搜索问答功能。系统采用前后端分离架构，支持多种文档格式和AI模型接口。

## 技术栈

### 前端技术
- 纯HTML5/CSS3/JavaScript实现
- 响应式布局设计
- 本地化字体优化
- 使用pdf.js和mammoth.js处理文档

### 后端技术
- Node.js HTTP服务器
- Express.js框架（v4.18.2）
- node-fetch（v3.3.2）用于HTTP请求
- concurrently（v9.1.2）用于并发进程管理
- cors（v2.8.5）用于跨域处理

### 核心依赖
- express-fileupload：文件上传处理
- mammoth：DOCX文档解析
- natural：自然语言处理
- docx：文档生成
- markdown-it：Markdown解析

## 核心功能模块

### 1. 文档上传与解析
- 支持多种文档格式：TXT、MD、DOCX、PDF
- 使用专用解析器处理不同格式文档
  - TXT/MD：直接读取文本内容
  - DOCX：使用mammoth.js解析
  - PDF：使用pdf.js解析
- 文档分块处理，将大文档拆分为多个知识块

### 2. 知识向量化存储
- 使用Ollama本地模型生成文本向量
- 向量化存储支持语义搜索
- 实时显示文档处理状态和知识块数量

### 3. 智能问答系统
- 支持自然语言提问
- 基于向量相似度检索最相关知识块
- 结合上下文生成高质量回答
- 显示相关上下文来源

### 4. 模型管理
- 支持多种AI模型接口
  - Ollama本地模型
  - OpenAI API
  - 硅基流动API
- 可配置嵌入模型和生成模型

### 5. Ollama嵌入代理服务
- 专门的嵌入向量代理服务器（nodejs-ollama-embedding-server.js）
- 监听端口3000，代理Ollama API（端口11434）
- 支持模型可用性检测
- 支持的模型：deepseek-r1:1.5b、nomic-embed-text:latest
- CORS跨域支持
- 动态加载node-fetch模块

## 项目结构

```
项目根目录/
├── nodejs-ollama-embedding-server.js    # Ollama嵌入代理服务
├── mcp-server.js                       # MCP服务器
├── monitor.js                          # 监控服务
├── convert-to-docx.js                  # 文档转换工具
├── package.json                         # 项目依赖配置
├── start-all.bat                       # 一键启动脚本
├── fix-dependencies.bat                  # 依赖修复脚本
├── fix-path-to-regexp.bat               # 路径修复脚本
├── 项目功能说明.md                     # 功能文档
├── report_template.md                   # 报告模板
├── 系统功能演示截图.png               # 功能截图
├── .codebuddy/                        # IDE配置目录
├── document/                           # 文档目录
├── knowlege/                           # 知识库目录
└── web_server/                         # Web服务器目录
```

## 部署与运行

### 启动方式
- 通过`start-all.bat`一键启动所有服务
- 默认端口：19191（主服务）、3000（嵌入代理）
- 依赖Node.js环境

### 服务端口
- 主Web服务：19191
- Ollama嵌入代理：3000
- Ollama API：11434

## 技术特点

### 前端设计
- 现代化UI设计
- 响应式网格布局
- 微交互动画效果
- 本地化字体支持

### 后端架构
- CommonJS模块系统
- 异步模块加载（node-fetch动态导入）
- 错误处理和日志记录
- CORS跨域支持

### 安全性
- 输入验证
- 错误处理机制
- 最小权限原则

## 未来扩展方向

1. 支持更多文档格式
2. 增加知识库管理功能
3. 优化向量搜索算法
4. 支持多轮对话
5. 增加用户认证
6. 提升模型兼容性

## 项目亮点

- 完全本地化部署，保护数据隐私
- 支持多种AI模型接口，灵活可扩展
- 文档处理能力强，支持主流格式
- 实时向量化和语义搜索
- 一键启动，部署简单
- 模块化设计，易于维护和扩展

我又用codebuddy帮我不断迭代尝试，扩展开发了很多功能，做了很多的小demo和实验。codebuddy编程确实思路清晰，速度又快，让我省下来大把的时间喝咖啡，我用这些空闲继续思考了很多扩展应用，然后都让codebuddy帮我开发，再进行测试验证。

demo演示如下：

别看这个界面简陋了点，但是确实是把本地大模型部署的精髓都跑通了一遍。不仅支持本地，还可以调用硅基流动等云服务API切换后台模型,可以修改模型的多种参数配置，因此验证了技术路线的可行性，后续扩展功能实现只是加水的过程，毕竟，世界是一个巨大的草台班子，捂脸。

只需要对话AI就能理解你的意图并开发，不需要写一行代码，你只需要做好一个产品经理，实现应用的过程变得单纯而又快乐！

当时我想，难怪要说AI淘汰程序员，这个真是恐怖如斯！

理论上，chat-gpt出来的时候，之前就有cursor和copilot这些国外的AI编程工具，我不可能不了解。然而实时情况是，我也只是私下了解，因为种种原因，这些技术没在单位的环境中实用过。

那个时候就算AI还是不太完美，生成大型应用上架构能力不足，有乱输出跑偏和编造结果的现象，也有很多细节上的bug问题。但是从写基础功能代码的复制粘贴来说，codebuddy是一个实用性非常高的AI工具，它确实极大提升了初级程序开发的效率，让思路瞬间转换成原型产品。

同时，AI进化的速度实在太快了,从单元到集成再到创造我觉得不过是时间问题，这就代表了一种必然的发展趋势。

后来，codebuddy出了IDE，我也是第一时间就下载试用了。

技术人员用脚投票，codebuddy是好用的，于是乎很快我就成为codebuddy的忠实拥趸。

四、

这个时候伴生AI还有一个很火的概念叫RAG，就是知识增强检索，为本地大模型构建本地垂直领域专用知识库，咋一看非常合理，行业内被广泛宣传的一套理论实现了逻辑自洽：因为是本地知识壁垒，所以其在本行业专业领域的问答能力及准确性理论上应该吊打通用模型，而且能更省tokens。

恰！完美！

然而，经过一年的起起伏伏沉淀下来，现在又有很多人认为这是在忽悠觉得根本不如通用大模型。

我怎么看？

专有知识库强不强？

从针对性来说，肯定比通用大模型的知识库大海捞针要强的，但是大部分单位哪有人工智能的人才基础呢，所以他们的知识向量化水平、模型调参和输出结果优化水平肯定是很抱歉的，各种问题重重。

总之，事实上这也是一个技术活非常难搞定。

所以可能很多行业的垂类模型面临一种投入得不偿失，被快速迭代淘汰的尴尬境地。

不过不管怎么说，至少在当时，我是决心做RAG的。

要为公司做知识库，我的团队用codebuddy又把行业知识梳理了一遍，搭建了本地知识库，搞了很多切片方面的技术研究。林林总总，各类点状应用创意如数家珍，这些搞下来，好像又取得了不小的成功。

从对外宣传上，完成了本地的大模型部署和知识库搭建，并且开发了成熟的应用上线运行，确实也没有输给行业，这一波的压力顶住了！

五、

可是，此时突然出现的MCP、agent这些理论又狠狠冲击了我的视线。

有了MCP，AI当大脑，工具当手脚，不再局限于对话生成，而是可以调度干活，似乎能做更多的事情了。

AI聊聊天显然已经无法满足生产的需要。AI要创造，要AIGC，要跨界替代人工，这又逼着我们搞事情啊！！！

接下来开会头脑风暴，然后定计划实施，很快发生了大量的针对我们现有开发的应用工具的重构，希望把它们和后台大模型连接起来，然后让大模型统一调度，实现自动化生产。

想法挺美的！

当然，这个也是一个非常宏达的愿景。实际上操作起来也是巨难无比。

这个项目我们推行了几个月，最后的结论是，AI干这些调度工作的技术是不太靠谱的，可能还不如直接让人去干管理和监督，或者用更小的固定的决策网络模型去干。

大模型的不确定性和高成本在这里显得非常鸡肋。

是的，真相就是这么无解。

至少目前，这段研究告一段落，虽然搞出来几个应用发布上线了，但是其实并没有真正解决什么大问题，创造真正意义上的效率提升。

然而，我们也不是一无所获。

这一套搞完，没想到领导对我们今年的工作效果还挺满意，所以codebuddy是真的救了我一回！

我们这种不是主流做AI产业的，最重要的是什么，领导满意了！

这样这一年我还是在AI的席卷风暴中算是全身而退了。但是新的一年应用AI的风向会有什么变化就不知道了。我只能持续努力自勉。

好消息是，基于codebuddy和混社区，我顺手研究了腾讯CloudBase,lighthouse等一批云产品的应用，听了一些腾讯的直播公开课，结识了很多牛人，虚心向他们学到了不少干货，属实薅了一波知识的羊毛，这样我的技术路线、视野大大开拓，搞产品的经验也更加丰富了！

我还加入了社区的群，获得了“腾讯云创作之星”的荣誉。也全拜codebuddy所赐。

就现阶段来说，我感觉，至少五年内，在我们行业AI的能力也不能完全替代人。

得出这个结论其实心里很踏实了，至少我们跟兄弟们都不用失业了！哈哈！

六、

知识库不知道是不是一条光明大道，这个我也说不清，也不想辩论。

但是KAG什么的也出来了，这时候新的观点是知识库的应用上限天花板很明显，实在不如用MCP连接数据库来提供更可靠的数据结果。

是的，直击本源，归根结底，数据库的数更加准确可靠。

围绕这个理念，搞出智能数据服务，或者问数等等这些的服务就很正常了。

A2A也出来了，但是相对于MCP慢了一拍，可能它确实没有抓住好机会和切入点，所以MCP被广泛采纳，就目前我所处的行业来看，A2A似乎没有闹出太大的动静。

我觉得这是个正确的思路，数据的价值也在此真正体现，数据治理，一直以来对企业说重要却也常常不被重视，搞好高质量的数据，对于AI应用还是很关键的。

实际应用和我们理想中的不同，它是一堆充满噪音的菜市场，只要有人的地方，如果不妥善和严格管理，设定种种数据标准规范，那人来用就会把数据变成一堆乱麻。

我很早就发现，各种五花八门的数据格式和错误数据、空数据，使得基于其上做的分析类数据应用变成空中楼阁。数据是实时产生的，而且是有很多不同风格不同水平的人在用。所以聪明的产品都是尽可能设计成几个规范选项的选择题下拉框，尽量不要让用户填空。再就是锁定数据源，单一源取数确保数字的有效性和一致性。

讲这么多，其实扯远了，但是AI应用开发确实高度依赖数据，这都是一把辛酸泪，里面坑很多，只有实践吃点苦头才会印象深刻，不至于纸上谈兵，好高骛远。

这样我又多试用了一款腾讯云产品OpenTenBase，基于PostgreSQL内核深度定制的开放中立的开源数据库，确实也有独到之处。

七、

说来说去，这一年过得很快。

这一年是AI大爆发的一年，涌现出非常多的现象级产品和创意，令我印象深刻的，比如manus，豆包，kimi，讯飞智能语音这些，也包括混元3D，都收获了非常多的用户，也曾一度被视为AI界的灯塔。但是究竟AI对人类影响的终极定义是什么，现在还无从得知。

我用codebuddy不仅解决了很多工作上的事情，也开发了很多好玩的小应用。我也把它推荐给了身边的朋友。希望更多的人能用AI创造出更多精彩的作品，也提升工作和生活的便捷。

因为AI对我工作的巨大影响，我认为2025是个值得纪念的一年。

希望明年更好！

也祝愿社区和大家新的一年，马到成功，事事顺利，钱途无量！

​