国产AI编程工具Skill生成能里测试：CodeBuddy VS Trae

国产AI编程工具Skill能力大对决：CodeBuddy vs Trae

写在前面

• 适合人群：AI 编程探索者、工具效率控、想用 AI 解决复杂任务的开发者。
• 阅读契机：你手握 CodeBuddy/Trae 却只用来写简单脚本，想知道它们处理复杂 Agent 任务的真实上限。
• 核心收获：真实的“短视频生成 Agent”开发实录，包含踩坑细节（附代码片段）、底层逻辑分析及未来 Agent 编程的思考。

1. 引言：从"以人为本"到"人机共生"的生产力跃迁

在过去的一年里，我们见证了 AI 编程工具从简单的"代码补全"（Copilot）进化到了"自主执行"（Agent）。这种进化背后的核心，是我们对生产力定义的重构。

要通过 AI 提升个人生产力，我们需要厘清三个关键概念：工作流 (Workflow)、技能 (Skill) 和 Agent (智能体)。

• 工作流 (Workflow)：是成事的"地图"。它定义了从起点（需求）到终点（交付）的标准化路径（SOP）。没有工作流，AI 只能做点状的辅助；有了工作流，AI 才能串联起链状的价值。

• 技能 (Skill)：是工作流中可执行的"原子单元"。就像一个 Python 函数或一个 Shell 脚本，它是被封装好的能力块。

• Agent (智能体)：则是连接意图与实现的"桥梁"。在 Agent 时代，我们不再只是写代码，而是在编写技能，让 Agent 根据我们的自然语言描述，自动生成能完成特定任务的 Skill。

它们的关系是：Agent 是我们手中的指挥官，我们用它编写出一个个 Skill，最终组装成高效的 Workflow。

今天，我们就来一场实战对决。看看两款国产 AI 编程工具——CodeBuddy 和 Trae，在"编写 Skill"这一核心能力上，究竟谁更胜一筹。

2. 考题：创建一个"短视频生成 Agent"

为了测试上限，我没有选择写"贪吃蛇"这种简单代码，而是设计了一个稍微复杂点的多步骤 Agent 任务。

任务目标：编写一个 Skill，让用户输入一个话题，全自动生成一个短视频。

核心流程 (Pipeline)：

1. 创意策划：根据用户话题，结合预设主题，生成短视频脚本和分镜文案。

2. 视觉设计：根据分镜内容，生成 AI 绘画提示词。

3. 素材生产：调用绘图接口生成图片，生成语音。

4. 视频合成：将图片、语音、字幕自动剪辑合成最终视频。

之前我在扣子上用工作流的形式，搞过这一套，所以今天整合想试试写一个这个的skill，比搭工作流快多少

这不仅考察代码生成能力，更考察工具对复杂业务逻辑的理解、多文件工程的组织以及错误处理能力。

---

3. 第一回合：CodeBuddy —— 极速但略显粗糙的"直觉派"

CodeBuddy 给我的第一印象是快。

3.1 创建过程

我输入了完整的 Prompt，CodeBuddy 迅速理解了意图，并开始创建 Skill 任务。

它首先创建了一个 README.md 文档来梳理思路，这点好评。

紧接着，它在 5 分钟内就完成了代码编写，并提示我可以开始测试。这可比搭工作流快多了。

3.2 结果分析

但在代码审查和实际运行中，我发现了一些问题：

1. 结构过于简单：整个 Skill 的文件结构非常扁平，缺乏模块化设计。

   

   生成的工程目录非常"清爽"，但也暴露了逻辑的单薄：

   /project
   ├── main.py          # 主逻辑
   ├── utils.py         # 工具函数
   ├── requirements.txt # 依赖
   └── README.md        # 说明文档
   

2. Hardcode 问题：最致命的是，它将生成视频的 Prompt 写死在脚本里了，没有根据用户输入动态生成。

   我在检查 main.py 时发现了这样尴尬的代码：

   # CodeBuddy 生成的代码片段
   def generate_script(topic):# 错误：无论用户输入什么 topic，提示词里的 theme 都是固定的prompt = "写一个关于【人工智能】的短视频脚本..." return call_llm(prompt)
   

   这除了造成改动不方便，也意味着它退化成了一个"模板填充机"，而非真正的 Agent。

3. 风格幻觉：生成的视频风格不可控，最后一个图片，居然变成了漫画风，而且与文案匹配度一般（奶奶呢？/emoji笑）。

   

4. 字幕翻车：自动烧录字幕失败，不得不通过播放器挂载外挂字幕。

   

小结：CodeBuddy 赢在了速度和交互的流畅度，但在解决复杂问题的"精度"和"工程化"上，还有待打磨，而且中间脚本错误过多，他花了大量时间在修复脚本错误上。

---

4. 第二回合：Trae —— 稳健但同样有局限的"工程派"

首先说明一下，TraeCN要使用skill能力，必须在“solo模式”，这个情况下他基本上全面接管，你要动手的机会不多，整个过程顶多点一两次确认按钮，这个比codeBuddy体验好多了。

4.1 创建过程

Trae 的第一步是列出详细的任务清单，虽然它没有像 CodeBuddy 那样先写文档，但它的脚本数量明显更多。

它花费了约 4 分钟完成，生成了 7 个脚本文件，不仅有主逻辑，还有专门的配置、工具类，工程结构明显优于 CodeBuddy。

![工程结构](http://8.148.68.103:8000/api/v1/assets/esShHMMXP14bZA8I1WrGP7aQ3OSPzNja/asset_0de09fca7eb8f7c61560a5fae8b21497.jpg)看看这工程结构，确实更有"大厂风范"：
```text
/trae_project
├── main.py
├── config.py           # 专门的配置文件
├── utils/
│   ├── llm_client.py   # LLM 调用封装
│   ├── video_maker.py  # 视频处理
│   └── audio_maker.py  # 音频处理
├── assets/             # 预留的素材目录
└── requirements.txt
```

4.2 结果分析

实际运行下来，Trae 的亮点和槽点并存：

1. 字幕烧录成功：这是它比 CodeBuddy 强的地方，ffmpeg 的参数调教得更准，字幕完美烧录进视频。

   查看 video_maker.py，发现它生成了非常标准的 FFmpeg 滤镜链：

   cmd = ["ffmpeg", "-i", input_video, "-vf", f"subtitles={subtitle_file}:force_style='Fontname=SimHei,FontSize=24'","-c:a", "copy", output_video
   ]
   

   

2. 同样的硬伤：令我意外的是，Trae 同样犯了"提示词写死"的错误。看来对于复杂的 Prompt Engineering 逻辑，目前的 AI 在没有明确指引下，都倾向于偷懒。

   在 config.py 中，我找到了罪魁祸首：

   # Trae 的配置文件
   VIDEO_PROMPT = "A futuristic city with flying cars..." # 硬编码在配置里
   

   脚本过多，虽然生成速度快了，但是大模型利用能力下降，简单问题复杂化了。

3. 文案生成：果然，Trae生成的文案差多了，显得比较生硬，也没什么文风。可能是因为它把 Prompt 拆散到了不同文件，导致上下文丢失。

   

4. 尺寸问题：生成的视频尺寸与预期有偏差，横竖屏处理不够智能。

   TTS 的调用也不如 CodeBuddy。CodeBuddy 调用了 edge-tts 这种高质量库，而 Trae 似乎直接调用了系统原本的 pyttsx3，生成的语音是很机械化的，毫无感情色彩。感觉是参数没有调配，按理说两个都应该是调用的 Windows 本地 TTS，但效果天差地别。

   

小结：Trae 展现了更好的代码组织能力和底层工具控制力（如 ffmpeg），但在业务逻辑（提示词生成）的灵活性上，依然没有突破。

---

5. 最终复盘与展望

5.1 对比总结

| 维度 | CodeBuddy | Trae |

| :--- | :--- | :--- |

| 生成速度 | ⚡️ 快 (< 5min) | 🚀 较快 (< 5min) |

| 工程结构 | 简单，单文件为主 | 复杂，模块化分离 |

| 文档习惯 | ✅ 先写 README | ❌ 直接写代码 |

| 底层控制 | ❌ 字幕烧录失败 | ✅ 字幕烧录成功 |

| 逻辑灵活性 | ❌ 提示词硬编码 | ❌ 提示词硬编码 |

5.2 启示

这次测试不仅是对工具的祛魅，更是对我们使用方式的提醒：

1. AI 仍需"引导"：即便是 Agent 模式，对于"根据话题动态生成 Prompt"这种元认知层面的逻辑，AI 往往会理解成"写一个固定的 Prompt 模板"。我们需要在 Prompt 中明确要求："请编写一个函数，根据输入的 topic 动态组装 prompt"。

2. Skill 的价值：虽然两个工具生成的 Skill 都不完美，但它们都大大降低了我们开发复杂应用的门槛。过去写这样一个视频生成器需要一两天，现在只需要 5 分钟搭架子，剩下的修修补补即可。

3. 未来的 Agent：理想的 Agent 编程工具，不应只是写代码，更应该是一个架构师。

   它应该能主动进行这样的对话：

   Agent: "我检测到脚本里有一个 Prompt 是写死的。请问这个 Prompt 是固定的，还是需要根据用户的 Topic 动态生成？"
   User: "动态生成。"
   Agent: "好的，那我将增加一个 LLM 调用函数，专门用于生成 Prompt。"

   现在的工具，太急于"交卷"了，反而少了这种关键的"需求澄清"。

在 AI 编程的下半场，谁能更好地理解业务流 (Workflow)，谁就能定义新时代的编程技能 (Skill)。 CodeBuddy 和 Trae，都还在路上。

---

作者简介： 10年+视频技术、各种网络协议、后端技术、开发经验，曾任某互联网大厂技术专家。对AI编程工具、云原生架构、视频处理技术有深入研究。

合作请加WX：hbstream
（http://haibindev.cnblogs.com），转载请注明作者和出处