我之前常说，不要逆AGI潮流去做一些事情，但也要对当前的大模型的边界有清晰的了解。Github Copilot 本质还是IDE工具的衍生，是一个更加“智能”的代码提示，而其提供的Copilot Chat 则更加只是把一个聊天框做到IDE而已，和集成一个搜索框到IDE工具没有任何区别，然还是一个古典产品的思维在做的一个产品。更细节的，我可以从三个维度做给大家做分析：第一个维度是 Github Cop

之前我说AI辅助编程的发展历程大概是是这样的：tab -> tab tab -> chat -> write -> commit -> pr我简单画了个图：最早 github copilot 的核心是自动补全，也就是以前IDE自动补全的 大模型版本（其实补全模型的规模都不大，一般都在 33B 左右）。我们认为这个AI编程的 tab 时代。用户有不懂的地方，还是要打开w

想象一下，无论你在哪里输入文字，都有AI助手随时为你提供建议。作为Github Copilot和Chat-Auto-Coder的资深用户，我深感AI辅助输入的魔力。但是，为什么要局限于特定软件呢？Web Typing Auto-complete，你的Chrome浏览器全能AI输入助手，该插件采用 Chat-auto-coder 开发，99.99%的代码为AI生成，基于硅基流动提供的高并发低延迟的底

我是 Github Copilot 和 Chat-Auto-Coder的重度使用者。前者在编辑器里做代码提示，后者是通过命令行写文字来修改代码，迭代需求。有一段时间，我每次打字或者写代码，就忍不住要停顿一下，等 Github Copilot 给我做补全..... 然后呢，有时候网络不给力，就让我很难受。后面我就在想，这么好的东西，能不能让所有人在任何有文字需求的场景，都可以享受这种AI的自动补全。

前言从上周四开始，极限十小时实现了第一个可用版本，在这期间，我们成功实现了自举，也就是利用 Auto-coder 的基础功能来帮助 Auto-coder的开发，所以才有如此神速。今天这篇文章，我们来介绍下 Auto-Coder 到底可以给程序员带来什么价值。Github Copilot 够么？对于这个事情，我给大家从三个维度做分析。第一个维度是 Github Copilot 的定位，我一直是 Gi

My Best Friend Mr Wang(系统架构师) 告诉我，用 secureCRT.哈哈 大家用用，确实有很多方便之处。

前一段时间自己开发了一套基于Yarn的容器调度系统，这篇文章就是分享其中的一些经验。

Spark on k8s，可能都有听说，可是笔者从网上没有找到一个可以顺利运行的例子。笔者也是走了几个弯路才顺利跑通的。下面笔者将基于spark native方式部署，分别讲解如下三种模式...

今天正好和以前的一个老朋友通了个电话，他在创业，其实做的还可以，业务发展的也不错。但是做互联网服务，尤其是内容服务，不可避免的需要譬如推荐，搜索，精准推送等功能，而这几个功能，又比较依赖大数据和AI相关的体系。举个最简单的例子，获取用户访问行为，然后做个协同，然后推荐时需要把用户看过的内容过滤掉，就这个可能就需要Flume,Kafka,流式引擎等，更别提然后还要归档日志（或者进入数仓）了。我以前就

前言很多时候，比如用structure streaming消费kafka数据，默认可能是得到key,value字段，key是偏移量，value是一个byte数组。很可能value其实是一个Json字符串。这个时候我们该如何用SQL操作这个json里的东西呢？另外，如果我处理完的数据，我想写入到kafka,但是我想把整条记录作为json格式写入到Kafka...