当前位置：首页 > news >正文

Skill生成能力测试

news 2026/7/9 9:13:37

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

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

核心流程 (Pipeline)：

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

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

CodeBuddy 给我的第一印象是快。

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

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

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

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

结构过于简单：整个 Skill 的文件结构非常扁平，缺乏模块化设计。
生成的工程目录非常"清爽"，但也暴露了逻辑的单薄：
```
/project ├── main.py # 主逻辑 ├── utils.py # 工具函数 ├── requirements.txt # 依赖 └── README.md # 说明文档
```
Hardcode 问题：最致命的是，它将生成视频的 Prompt写死在脚本里了，没有根据用户输入动态生成。
我在检查main.py时发现了这样尴尬的代码：
```
# CodeBuddy 生成的代码片段 def generate_script(topic): # 错误：无论用户输入什么 topic，提示词里的 theme 都是固定的 prompt = "写一个关于【人工智能】的短视频脚本..." return call_llm(prompt)
```
这除了造成改动不方便，也意味着它退化成了一个"模板填充机"，而非真正的 Agent。
风格幻觉：生成的视频风格不可控，最后一个图片，居然变成了漫画风，而且与文案匹配度一般（奶奶呢？/emoji笑）。
字幕翻车：自动烧录字幕失败，不得不通过播放器挂载外挂字幕。

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

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

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

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

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

字幕烧录成功：这是它比 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 ]
```
同样的硬伤：令我意外的是，Trae 同样犯了"提示词写死"的错误。看来对于复杂的 Prompt Engineering 逻辑，目前的 AI 在没有明确指引下，都倾向于偷懒。
在config.py中，我找到了罪魁祸首：
```
# Trae 的配置文件 VIDEO_PROMPT = "A futuristic city with flying cars..." # 硬编码在配置里
```
脚本过多，虽然生成速度快了，但是大模型利用能力下降，简单问题复杂化了。
文案生成：果然，Trae生成的文案差多了，显得比较生硬，也没什么文风。可能是因为它把 Prompt 拆散到了不同文件，导致上下文丢失。
尺寸问题：生成的视频尺寸与预期有偏差，横竖屏处理不够智能。
TTS 的调用也不如 CodeBuddy。CodeBuddy 调用了edge-tts这种高质量库，而 Trae 似乎直接调用了系统原本的pyttsx3，生成的语音是很机械化的，毫无感情色彩。感觉是参数没有调配，按理说两个都应该是调用的 Windows 本地 TTS，但效果天差地别。