国产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)：

• 创意策划：根据用户话题，结合预设主题，生成短视频脚本和分镜文案。
  
• 视觉设计：根据分镜内容，生成 AI 绘画提示词。
  
• 素材生产：调用绘图接口生成图片，生成语音。
  
• 视频合成：将图片、语音、字幕自动剪辑合成最终视频。
  

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

这不仅考察代码生成能力，更考察工具对复杂业务逻辑的理解、多文件工程的组织以及错误处理能力。
3. 第一回合：CodeBuddy —— 极速但略显粗糙的"直觉派"

CodeBuddy 给我的第一印象是快。
3.1 创建过程

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

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

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

3.2 结果分析

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

• 结构过于简单：整个 Skill 的文件结构非常扁平，缺乏模块化设计。
  
  
  
  生成的工程目录非常"清爽"，但也暴露了逻辑的单薄：
  1. /project├── main.py          # 主逻辑├── utils.py         # 工具函数├── requirements.txt # 依赖└── README.md        # 说明文档

  复制代码
• Hardcode 问题：最致命的是，它将生成视频的 Prompt 写死在脚本里了，没有根据用户输入动态生成。
  我在检查 main.py 时发现了这样尴尬的代码：
  1. # CodeBuddy 生成的代码片段def generate_script(topic):    # 错误：无论用户输入什么 topic，提示词里的 theme 都是固定的    prompt = "写一个关于【人工智能】的短视频脚本..."     return call_llm(prompt)

  复制代码
  这除了造成改动不方便，也意味着它退化成了一个"模板填充机"，而非真正的 Agent。
  
• 风格幻觉：生成的视频风格不可控，最后一个图片，居然变成了漫画风，而且与文案匹配度一般（奶奶呢？/emoji笑）。
  
  
  
  
• 字幕翻车：自动烧录字幕失败，不得不通过播放器挂载外挂字幕。
  
  
  
  

小结：CodeBuddy 赢在了速度和交互的流畅度，但在解决复杂问题的"精度"和"工程化"上，还有待打磨，而且中间脚本错误过多，他花了大量时间在修复脚本错误上。
4. 第二回合：Trae —— 稳健但同样有局限的"工程派"

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

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

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

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

复制代码

4.2 结果分析

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

• 字幕烧录成功：这是它比 CodeBuddy 强的地方，ffmpeg 的参数调教得更准，字幕完美烧录进视频。
  查看 video_maker.py，发现它生成了非常标准的 FFmpeg 滤镜链：
  1. cmd = [    "ffmpeg", "-i", input_video,     "-vf", f"subtitles={subtitle_file}:force_style='Fontname=SimHei,FontSize=24'",    "-c:a", "copy", output_video]

  复制代码
  
  
  
• 同样的硬伤：令我意外的是，Trae 同样犯了"提示词写死"的错误。看来对于复杂的 Prompt Engineering 逻辑，目前的 AI 在没有明确指引下，都倾向于偷懒。
  在 config.py 中，我找到了罪魁祸首：
  1. # Trae 的配置文件VIDEO_PROMPT = "A futuristic city with flying cars..." # 硬编码在配置里

  复制代码
  脚本过多，虽然生成速度快了，但是大模型利用能力下降，简单问题复杂化了。
  
• 文案生成：果然，Trae生成的文案差多了，显得比较生硬，也没什么文风。可能是因为它把 Prompt 拆散到了不同文件，导致上下文丢失。
  
  
  
  
• 尺寸问题：生成的视频尺寸与预期有偏差，横竖屏处理不够智能。
  TTS 的调用也不如 CodeBuddy。CodeBuddy 调用了 edge-tts 这种高质量库，而 Trae 似乎直接调用了系统原本的 pyttsx3，生成的语音是很机械化的，毫无感情色彩。感觉是参数没有调配，按理说两个都应该是调用的 Windows 本地 TTS，但效果天差地别。
  
  
  
  

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

5.1 对比总结

[table][tr]维度CodeBuddyTrae[/tr][tr][td]生成速度[/td][td]⚡️ 快 (< 5min)[/td][td]
来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！