腾讯云代码助手 CodeBuddy初体验

大家好，我是杜金房，是一个老码农。今天跟大家聊聊AI辅助编程——我使用CodeBuddy的体验。

#背景#

AI算是当今最热的话题了。我主要是做音视频通信的，其实最早接触的跟AI相关的都是跟ASR/TTS相关的软件和产品。自从生成式AI火了以后，我也不甘落后，迅速学习了ChatGPT，最早在FreeSWITCH内实现了跟ChatGPT语音交互的模块，后来又把OpenAI开源的Whisper也集成到了FreeSWITCH中，再后来，就是OpenAI Real-Time以及Agora的TEN开源框架。

当然，作为一名腾讯云TVP，腾讯混元大模型出来后，我也第一时间做了适配和对接，并写了一篇文章：《保姆级教程：如何用Python自制聊天机器人？》。

偶尔，我也会尝试一些AI工具。然而，热爱并不应该迷信。现在五花八门的AI工具实在是太多了，根本就尝试不过来。

对于编程来说，在大模型出来之前，我就在使用 Tabnine 和 Copilot。大模型出来之后，感觉代码生成的质量是比以前好，但也没有那么好。作为一名深资码农，我对代码还是有点洁癖的，因此，我大部分情况下只是“问”大模型，或让它做一点代码补全之类的，但很少让大模型帮我改代码，更别提写代码了。

我也相信“不用写一行代码，大模型就帮我写了一个项目（或App）”之类的故事，但我从来没有冲动尝试。主要是我写的代码很多都比较偏门，大模型表现还没有那么好。

我也尝试过商汤小浣熊、通义灵码、Cursor和Trae，有时候确实惊艳，但对我来说，也没有什么质的提升。感觉主要原因还是我写的东西比较偏门，当然，也可能是我尝试的不够多。

#小试牛刀#

这次，腾讯云代码助手重磅推出了新的CodeBuddy，包含Craft、Chat、MCP等很多功能，拿到灰度账号后我自然要尝试一下。下面就简单说说我的体验。

XCC Examples （https://git.xswitch.cn/xswitch/xcc-examples）是我司的一些开源示例代码。这些代码主要是与我们的XSwitch结合，进行音视频和AI交互的一些示例。我们使用了NATS消息队列（你可能更熟悉Kafka）。该消息队列有各种语言的客户端库，因此，我们也写了很多语言的示例代码，如Node.js、Go、Python、C#等，都是手写的。

其实，我一直想写几个C语言的例子，但一直没有时间写，这次想试一试CodeBuddy。在VS Code中安装了插件并登录后，CodeBuddy和Craft就准备好了。我在VS Code中打开了我的项目目录，给他下达了以下指令：

这里有很多通过NATS连接XSwitch的例子。nodejs 目录中的示例比较全。参考示例中的 events.js ，写一个C语言版的 c/events.c，要求用cmake编译。

Craft就开始工作了，它首先分析并明确了任务，然后分析了我的项目目录，然后分析了event.js的功能，感觉分析得很不错：

我已经看到了Node.js版本的代码，它主要功能是：
1. 连接到NATS服务器（默认地址是nats://127.0.0.1:4222）
2. 订阅主题"cn.>"
3. 接收消息并尝试解析JSON
4. 打印接收到的消息信息
5. 使用定时器保持程序运行

然后，它就（打开VS Code的终端调用shell命令）自动创建了 c/ 这个子目录，生成的 CMakeLists.txt 以及 events.c 文件，并指导我运行以下命令：

cd c
mkdir build
cd build
cmake ..
make

熟悉 CMake 的同学都知道这是C程序标准的编译步骤。当然还有一些其他命令，比如如何安装C语言版的NATS库之类的，那些我其实很早就装过了，因此，我只是手动执行了上述命令就一次性编译通过。再执行 ./events 就直接连接到我本地（早已运行）的 NATS 和 XSwitch，并接收到了事件消息。分分钟的事，一切如丝般顺滑。趁热打铁，我顺便让它生成了一个README。

这个过程很有趣。有图有真相，图中我也简单标注了一下。

我输入的提示词以及交互过程是中文的，但生成的代码中注释以及README中都是英文的，可能跟我的环境有关（我的macOS和VS Code系统界面都是英文的），当然我也可以输入更多的提示词去尝试让它多输出一些中文的结果，或者直接让它翻译成中文，但我没有这么做。

我把这次改动提交到了 https://git.xswitch.cn/xswitch/xcc-examples/commit/d7ed95d0e3e3d35206559fa2abe2fb24820788ec 。对于一个每天都执行上百次 git 命令的程序员来说，我并没有让大模型帮我提交代码，因为我觉得我手动输入命令比让大模型做来得快，来得准，而且不用太动脑筋（写提示词）。但我想，这里代码助手应该还有一个用处，就是帮你生成 Commit Message。我们的团队有点国际范，Commit Message 一般都写英文的。写一个好的Commit Message其实对很多程序员都是一个比较头痛的事，即使用中文写。这一点，我相信大模型能做得很好，不过，我也没有尝试。

#趁热打铁#

接下来，我让它参照play.js和tts.js生成了对应的C版本。由于我们使用了JSON格式的消息，也用到UUID，因此它引入了两个依赖库，json-c和 uuid。但是我们对cJSON更熟悉（在FreeSWITCH以及其他项目中都使用了cJSON），我又让它把 json-c 换成了 cJSON。不过，这个过程比较漫长，它说在下载代码，但是实际上 cJSON.h 和 cJSON.c 都是“生成”的，也可能是在大模型后台下载。由于cJSON.c 比较长，它会提示要分步生成，我同意了。但它还是在生成了几部分以后停下来，去完成了其他的工作。比如将json-c的代码替换成cJSON版本的，修改CMake工程文件等。这些工作完成后，又继续尝试生成cJSON.c。在生成的过程中，我尝试使用make命令编译，最初编译很正常，只是在连接阶段缺少相应的cJSON函数。后面，随着代码生成，有时候编译也会出错。在生成了1500多行以后，它说这个任务花了好长时间了，停下来问我是否继续。我对照了Github上的版本，发现还差一半，因此，我手工同步了Github上的cJSON.c以及cJSON.h（虽然这个文件已经生成了，但跟Github上的最新版本不一致）。然后make命令一次性编译通过。

执行 ./tts 进行测试，发现一些问题。JSON格式不对。我检查了一下，发现少了一个层级，然后使用以下指令让它修改：

tts.c 不对， 再对照一下原始的 tts.js，text 和 type 应该是在 params.media 对象中。

它告诉我它发现了问题原因。原来的JS中，格式如下：

rpc.params.media = {
    data: text,
    type: "TEXT",
    engine: tts_engine,
    voice: "default"
}

而在对应的C语言版本中，这些参数都被放到了 rpc.params 对象中，接下来就很快改好了，我确认后也一次性编译通过。

当然，最终的代码也还是有些问题，比如它使用了 azure 的 TTS 引擎，而不是 play.js 中的 ali （阿里）或 minimax。这些参数我手工修正了，没有让它来做。打电话测试，成功播放了“您好，这是一个文本转语音的测试。感谢您的来电，再见！”。

图中，CherryCall 是我自己写的一个SIP电话客户端软件。后面我还会讲到它的产生过程。

另外，play.c也有相同的JSON格式问题，也使用同样的方法修复了。最后，也更新了README，对应的提交为：https://git.xswitch.cn/xswitch/xcc-examples/commit/695211033e792af882d41b8d0de789b4354eb0b1 。

#C3#

最近发现一门叫C3的编程语言。

C3 是 C 语言的进化版，“进化，而不是革命”代表了它的设计初衷。有趣的是，C3是由C2进化来的，他们都保持了与C的完全兼容。多年来，人们一直试图再造一个“更好的C语言”，如C++、Zig甚至D（D其实是想做一个更好的C++）、Rust、Go、V等都算，但这些语言越来越偏离了C，而且跟C语言的互操作都有或多或少的额外开销。

我是一个C程序员，看了一下C3的语法，感觉挺喜欢，就想试一下。正好有了CodeBuddy，这个试验就更加有趣。在人工智能时代，很多人都说程序员要失业了，因为AI已经可以写出很好的代码，甚至不懂代码的人也能写出一个网站、一个App，编译、调试、上线、运行等，AI都能给出相应的指导，但我不这么看（当然，也有很多人不这么看）。这里的理由是，AI只是个助手，是个催化剂。如果你不懂编程，它可能会帮你完成一些编程工作，但不至于能帮你成为一名程序员；但如果你已经是程序员，它会帮你成为一名更好的程序员。

我之前没见过C3，这就像不是程序员的人不懂JavaScript或Python一样。他们可以借助AI写Python程序，我借助AI写C3程序，道理上应该类似。所以，我想看看我用C3写一个项目需要花多长时间。

在写C3之前，我花了不到一小时的时间浏览了C3的语法，做到心中有数。然后，接着上面C语言版的XCC的例子，我又让CodeBuddy写了C3的例子。

生成的代码大致框架是对的，但是编译不通过。大多数时候，我会直接把出错信息贴到CodeBuddy的聊天区，它就会帮我改代码。当它再也改不动时，我就用我“一小时的C3”知识，根据编译的出错信息做出修改。功夫不负有心人，最简单的events.c3终于调通了。这里主要的困难是events.c3依赖于NATS库，但由于C3比较新，也比较小众，所以，并没有对应的NATS库。所以，我必须使用C语言版的NATS库。这就涉及到C3和C的混合开发问题。可能是由于C3比较新，没有太多的训练数据，所以在这方面，AI表现的还不是很好。

events.c3只是连接NATS并接收消息，收到的消息直接打印出来，所以比较简单。但后面的play.c3和tts.c3则需要进XSwitch通过JSON-RPC交互，因此，就需要一点RPC框架、JSON序列化和反序列化、生成UUID的库等。C3从语言层面看已经比较完善，但标准库还不是很完善，相关的生态库也很少，因此，大部分需要的东西还需要自己写。好在，有了AI，这些东西可以先用AI写个初稿，然后再进行修改就可以了。

C3中有JSON解析，即可以将JSON字符串解析成内部Object结构的函数，但我没有找到将Object序列化成JSON字符串的方法，因此，我还是使用了C语言的cJSON库来做这些事情。

在实现这些代码的过程中，我发现AI其实已经做得很不错了，但有时候也会犯傻。比如我手工修改好的代码，后面又被AI改回去了。后来我才发现，我使用的是0.7.1版的C3语法，而AI只是停留在0.6~0.7左右（大约有一年或几个月的时间差），坦白说，这不算AI的错误，只是它的训练数据有些旧。但不管怎么说，它都不应该反复覆盖我修改后的代码。而且我也发现一个问题，就是在用Craft的时候，下达的任务，它会拆解成一系列的步骤，一步一步去完成，有些地方它会让我确认。这本是好事情，但关键问题是“确认”操作只能是“接受”或“拒绝”，我并不能输入我的修改意见。除非停止整个任务再从头再来。我认为这是Craft后续可以优化的地方——能根据用户的意见调整任务。

在使用过程中我还发现，它对于同一个代码文件，有时候会连续进行多轮修改，虽然大多数时候会有所改进，但是也有可能会倒退。而且，有时候代码改动比较多，大篇的diff很难阅读，我就只好全部接受，再看看是否要回退。很多时候我为了方便回退，在我确认后的每一步都做了Git提交，这样，我可以用我熟悉的 git diff 命令看代码差异，使用 git checkout 一键回退等。事实证明，这很有用。

在调通所有三个示例代码后，我已经喜欢上这门新语言了。因此，我又按我的喜好进行了一轮重构。比如，我可以让AI把一些重复的代码提取到专门的共享模块中。AI确实也帮我做了一些工作，甚至生成了相应的函数说明，但离我想要的效果还是相差很多，我还是手工做了好多工作。重构完成后，我又进一步把nats、cjson等代码分到独立的C3模块中，看起来，真正有点C3的样子了。

断断续续做完这些工作，花了我差不多一天的时间。如果没有AI，可能需要花更长时间。但在实现、调试的过程中，我也对这门新语言掌握了七七八八。由于C3的文档资料比较少，为了实现我想要的功能，我还阅读了C3标准库的一些源代码。

最终，我将所有修改合并成了一个提交：https://git.xswitch.cn/xswitch/xcc-examples/commit/cf41e73a74c39ff9e675a753f3c5bd9125192c1b

写到这里，我突然有了一个想法。假如，我让它直接读C3网关上关于最新的0.7.1版的博客信息（包含版本发布说明），或者把博客里的内容单独放到一个本地文件里，让CodeBuddy阅读一下，是不是也会有所改进呢？这是个马后炮，我并没有试。

这里只有TTS的例子，后面，我还会写一些ASR的例子。当然，如果我有时间，我还想尝试对接ChatGPT进行语音对话。

#macOS原生开发#

前面提到的CherryCall是一个macOS原生的SIP电话客户端软件。我一直从事SIP相关的工作，但主要是在服务端使用FreeSWITCH和Kamailio。之前用过各种各样的SIP客户端，但都不称手。最近，有了AI的加持，我打算手撸一个。

我当然不是从头开始写。我使用开源的Baresip作为基础。Baresip已经是一个比较完善的SIP软电话了，只是没有图形界面。所以，我只需要增加一个图形界面。我使用macOS。在macOS上开发图形界面有好多选择：原生的Objective-C/Swift（Xcode）、ReactNative、Electron、Tauri等。但是——

• 我其实并不会Objective-C或Swift，也不熟悉Xcode。而且Xcode原生开发需要下载10个G的开发环境。
• Electron、ReactNative都需要使用JavaScript生态链，而且占用空间以及内存比较大。
• Tauri看起来倒是很美好 ，但还是离不开JavaScript，而且，还需要Rust……

在为选型发愁的时候，我找到了一个近乎完美的方法，使用Lua（LuaJIT）写macOS原生程序——https://github.com/mogenson/lua-macos-app 。

Lua是一门小巧的语言，我们在众多项目中都使用了它。如果能用Lua写原生的macOS程序，那简单是太完美了。当然，任何选择都有代价，完美的事情是不存在的，接着看就知道了。

最初版本的 CherryCall 是在Trae中写的，就是你在上面图中看到的版本。初期版本，还比较粗糙。后面，我又在VS Code中使用CodeBuddy添加了视频的支持。

先从头开始说。最开始，我对Trae也不熟悉，之前用过Cursor也只是简单用过代码补全，在使用Trae时，我又学习了一项技能， 就是在跟AI对话时，可以将AI生成的代码直接“Apply”到当前的代码编辑器中， 这倒是省了不少事。但我发现很多时候“Apply”的代码位置不对，我还是需要手工调整。

相比C3，我用Lua熟练得多。只是，用Lua写macOS程序还是绕不过Objective-C。严格来说，不是Objective-C本身，而是macOS底层的Framework（Cocoa）大都是用它写成的，因此还是要有所了解。我之前不熟悉Objective-C，因此，还是花了很多时间看Objective-C的语法，以及函数库。好不容易理解了Objective-C，又发现有些底层库里的东西还是用C写的（如CGRect，还被映射成了NSRect），所以，还得学习Objective-C与C的互操作，以及在Lua中对应的语法。

这些东西都搞定后，还有一个就是多线程。在macOS上，窗口占了主线程（好像没法或很难在子线程中运行或更新窗口上的组件），而Baresip也有一个线程用于协调I/O和Socket。好在，Baresip可以在子线程中运行。虽然可以直接在Lua中启动子线程进而启动Baresip，但总是莫名其妙地崩溃，后来我还是自己用C写了几个辅助函数将一切串了起来。上面说的C3是C语言的进化版，但毕竟在C3中无法直接使用C语言中的头文件。而Objective-C与C的结合是更“无缝”的，它可以直接使用C的头文件，与C混合编译。当然，如果又使用了Lua，在Lua中也是无法直接进行C调用的。不过，在LuaJIT中，可以直接将C语言的函数声明在字符串的形式写到Lua源代码中，然后就可以直接在LuaJIT中调用C函数。

在Lua中调用Objective-C其实是通过C实现的，Objective-C也有对应的C运行时（Runtime）库，有一些C函数可以给Objective-C的对象发送消息。

这些，都是我在写这些代码的时候慢慢发现的。在这些方面，完全依赖AI就不大可能。也可能是我的提示词没有给到位，但我想，更有可能的是，这种编程方式比较小众，AI也没有足够的“经验”来指导我。好在我C语言的功力还在、Lua很熟，在AI的帮助下，理解了Objective-C，一切都解决了。

打通了音频电话是一个里程碑。但是，我还希望能支持视频，更重要的是，我需要测试在Baresip中支持双流（摄像头和共享桌面的媒体流）。这时候，我已经开始使用CodeBuddy，因此，就试用了CodeBuddy的能力。

有了前面的基础，我使用CodeBuddy更加熟练，使用的提示词也更精准。比如，我在下达指令前会先浏览一遍相关的源代码文件，这样，就能让CodeBuddy知道我最近看过的代码（“人在做，AI在看“，我猜应该是这个逻辑，当然，在实际使用中我也发现它会检查当前项目目录中的文件名来“猜”哪个文件更有可能包含相关的代码），并且，我会在提示词中告诉CodeBuddy我希望改哪些文件的哪些部分。这样，CodeBuddy给的结果就会比较好。

由于从C调用Lua的函数开销比较大（反过来则不大），所以，我还是需要直接用C或Objective-C写Baresip模块，因为一些音视频的处理是使用回调实现的，高帧率的视频需要比较频繁的回调。而且，我还需要使用共享桌面，高帧率的视频渲染（通过Metal直接访问GPU），所有这些也都需要底层的Objective-C。有了前面折腾Objective-C的经验，我也很快就熟悉了底层的逻辑，可以直接用Objective-C写模块了。视频渲染需要OpenGL，然后我发现OpenGL在macOS上已经被Metal替代，然后我又学Metal。在GPU上渲染视频与以前理解的按像素渲染不同，在GPU上需要画三角形。画一个三角形很简单，画个立方体也很简单，随便找个例子就可以跑起来，然而，渲染一幅平面图像我却折腾了很长时间。主要原因是没有找到直接运行的例子，其次还需要学习GPU专用的编程语言。很多例子都是基于OpenGL的，还需要转成Metal版……

在折腾这些的时候，AI有很多帮助，很多情况下它都能生成一些可以直接运行的代码。特别是在代码翻译上，如从OpenGL的示例翻译成Metal版的，或者，从Swift的示例翻译成Objective-C版的（Apple提供的一些示例只有Swift版的）。还有，共享桌面的API也有了很大的变化，从AVCaptureScreenInput变成了一个单独的ScreenCaptureKit。AI有时候不能区分这些版本的不同和变化，有时候有些混合的代码就比较难调试。不过，最终，在AI的加持下，我也搞定了macOS上共享桌面和视频展示。最让我欣喜的是，最终生成的CherryCall，一个完整的包含音视频通话和共享桌面的macOS程序，只有10MB左右，做成.dmg，也只有6M多一点。支持视频和双流的CherryCall截图如下：

我们将在不久的将来免费发布这款程序（不一定开源），到时候还会在本公众号上发布，感兴趣的同学请保持关注。

#小结#

上面，我体验的对我来说都是一些新的东西。CodeBuddy是新的、各种开发语言是新的，很多甚至是我以前从没见过的。这些东西，对于CodeBuddy来说，甚至也是比较小众，不那么常见的。但AI毕竟是AI，在使用CodeBuddy的过程中，我切实感受到了它给我带来的便利。CodeBuddy作为VS Code的一个插件存在，而不是像Cursor和Trae那样直接Fork了VS Code，能做到现在这种体验，我感觉已经非常好了。

AI都能写代码了，未来还需要程序员吗？这个话题大家一直在讨论，我也一直在思考这个问题。从去年开始，我就在写一本书《大道至简，给所有人看的编程书》。我认为，AI再强，它给你的始终都是一个一个的知识点，而如果真正学会编程，以至成为优秀的程序员，还需要系统地学习。这就像即使有了AI，人们还是要上小学、初中、高中、大学那样，一步一步按部就班地学习。我的这本书当然也不能代替大家按部就班的学习，但是我会把一系列的知识点串起来，对不懂编程的人来说，帮大家对编程开发有一个全面的认识；对于学过编程甚至有过编程经验的人来说，帮他们打通任督二脉，争取早日更上一层楼，成为一个真正的高手。

如前面所说，技术发展日新月异，而且，人生有涯，我也不是什么都会。但在AI的加持下，我学习的速度也变快了。在体验这些功能的过程中，我也尽力理解它生成的每一行代码的含义。不得不说，AI在这方面做得很好，它会不厌其烦地对代码进行解释。所以，这几天折腾下来，我并不仅仅是完成了几个写代码的任务，还系统学习了一些我以前不会的知识（除了跟AI学，我还读了LuaJIT的文档、C3的文档、Objective-C、OpenGL、Metal的文档等）。理论跟实践结合，学会了就不容易忘记。写书或写文章也是一种复盘和积累。这篇文章以及在我在写这篇文章的过程中学到的知识，也会以某种形式出现到我的新书里。

在使用CodeBuddy辅助编程的过程中，我并没有特别依赖它，而是用了它给我的助力。在写这篇文章的时候，我并没有研究和体验CodeBuddy所有的功能，而是把重点放在让它帮助我解决一些特定的问题上。关于CodeBuddy，官网的介绍图文并茂，已经很详细了，我也不需要再多此一举。相反，从某个特定的任务开始，跟大家分享一下我是如何用它帮助我的工作的，我觉得更有价值。

当然，CodeBuddy还有很多功能值得一试，比如代码评审（Code Review）、写单元测试，连接其他MCP Server等。时间关系，我还没有试。大家感兴趣不妨试一试。

最后，这篇文章全是我一个字一个字敲出来的，没有使用AI。不管好不好，在写文章时我还是想坚持我最后的底限。也感谢你读到这里，欢迎各种批评和建议。

#对CodeBuddy的期待#

虽然前面有提到过，我还是在这里总结一下。希望CodeBuddy团队能看到，把CodeBuddy做得越来越好。

• 在任务执行过程中能追加提示词，持续改进任务。
• 较大的diff 可以按代码块（hunk）确认，而不是整个文件。
• 能自动编译，并根据出错信息修改代码中的错误。