
> 评价一个 AI 编程工具，最有效的办法不是跑 benchmark，而是把**一个真实的、带着历史包袱的项目**交给它，观察它如何从"半成品"走到"可发布"。本文记录我使用 CodeBuddy CLI 驱动 Hy4 preview，对 SenseNova 多模态 Agent 项目做了一次完整的"还原—修 bug—补功能—建测试—写文档—发布"全流程。所有结论都有据可查：git 历史、53 项 pytest、真实 API 调用的状态码与耗时。这篇博客就是这次开发的全程实录与工具测评。

---
![在这里插入图片描述](https://developer.qcloudimg.com/http-save/yehe-9681929/44b30e8def3f3b2d07b486c0c6004f1c.png)

## TL;DR

- **测评对象**：CodeBuddy CLI（终端内运行的 AI 编码代理）× Hy4 preview（驱动模型），运行环境 Windows 11 + Git Bash
- **测评方法**：真实项目端到端重构，每一个评价结论都能在仓库里找到证据
- **五个高光能力**：实证驱动调试（先验证再改，不靠读代码猜）、多模态全链路（看生成的图、截 UI 的图）、长上下文跨文件一致性（20+ 文件一次会话改完）、坑→回归测试（每个 Bug 都有 `test_` 用例守护）、文档与 Git 运维一体化
- **三个诚实局限**：敏感操作必须人工授权、长会话 token 成本高（实测触发 429）、偶发的环境性重试
- **交付结果**：修复 12 个真实 Bug、53 项测试全绿、blog 重写到 6359 字、6 张效果图、12 张截图、功能提交全部推送到 Gitee

---

## 一、为什么写这篇测评

市面上的 AI 编程工具测评大多用"写一个 Todo App"这类从零开始的任务。这类任务有两个天然缺陷：

1. **没有历史包袱**。真实项目最耗时间的不是写新代码，而是理解旧代码里那些"看起来能跑但实际有坑"的地方
2. **结果不可证伪**。"它写出来的代码对不对"没有客观判据

这篇测评刻意选择了反面案例：一个**已经存在、能跑通、但隐藏着多处静默缺陷**的项目。它的价值在于——修 Bug 比写新功能更能暴露工具的推理能力，因为每一步都需要"先定位根因，再验证假设，最后修改并确认"。

测评的判据全部来自可复核的事实：`git log` 里的提交、`pytest` 的输出、真实 API 返回的 HTTP 状态码、日志里的错误与耗时。

---

## 二、测评环境与方法

| 项目 | 值 |
|------|-----|
| 操作系统 | Windows 11  |
| 开发工具 | CodeBuddy CLI（终端编码代理） |
| 驱动模型 | Hy4 preview |
| 运行时 | Git Bash（Windows 下） |
| 被测项目 | SenseNova 智能信息图生成工作流（Python + FastAPI + Streamlit） |
| 远端 | Gitee（公开仓库） |

测评方法分四步：

1. **立项**：给定"还原项目、对照比赛要求补功能、模拟真人用户测试、修 Bug、写文档"五个目标
2. **执行**：Agent 自主完成开发，我仅提供 API Key 与方向性确认
3. **记录**：全程留下 git 提交、测试用例、实测数据
4. **评价**：按五个维度打分，每一条评价都附证据

---

## 三、这次开发实际做了什么：五个阶段

### 阶段 1：还原环境

项目是干净的 git 仓库，但缺 `.env`、依赖未验证。Agent 的做法是：先列目录、读代码、核对 Python 与包版本，再向真实 API 发一个 `GET /v1/models` 确认连通性——**在动手改任何代码之前，先把"远端实际是什么样"确认清楚**。这一步看似简单，但决定了后续所有判断的基准。

### 阶段 2：修复 12 个真实 Bug
![在这里插入图片描述](https://developer.qcloudimg.com/http-save/yehe-9681929/f9ed92da504251ff95373be9142ad4f1.png)

这是整次开发的核心。Bug 清单（全部真实存在、可复现）：

| # | Bug | 根因 | 证据 |
|---|-----|------|------|
| 1 | 4:3/3:4 生图尺寸被 API 拒绝 | `2400×1800` 的 1800 不是 32 的倍数 | 实测 HTTP 400，换 `2368×1760` 后 HTTP 200 |
| 2 | LLM JSON 解析失败后产出废图 | 兜底逻辑把原始 JSON 文本当成生图 Prompt | 偶发触发，修复后回退确定性模板 |
| 3 | 推理模型返回 `None` | 不同模型把正文放在 `content` / `reasoning_content` / `reasoning` / `model_extra` 不同字段 | 构造 4 种响应逐一验证 |
| 4 | 质检几乎总是静默降级 | 超时预算 25s 落在真实耗时（27~35s）区间内 | 实测 34.9s / 27.3s |
| 5 | 模型回退机制从未生效 | 每个模型都拿到全部剩余预算，首个卡住即耗尽 | 修复切片后：主模型超时→备选接手，评分从 6.5 升到 9.2 |
| 6 | ComfyUI 产物目录错乱 | `output_dir` 没有从 pipeline 传到客户端 | 代码审查确认，修复后按 request_id 可查到图 |
| 7 | ComfyUI `image_url` 404 | 用本地文件名拼服务端 URL | 修复为用服务端返回的真实文件名 |
| 8 | `st.image()` 抛 TypeError | Streamlit 1.50 起 `use_column_width` 改名为 `use_container_width`，写死任一都会在另一版本报错 | 用户实测报错，按运行时签名自适应 |
| 9 | `st.table()` 使结果页整页报错 | Streamlit 自带 pyarrow 针对 numpy 1.x 编译，环境是 numpy 2.4 | `ImportError: numpy.core.multiarray failed to import`，改用 Markdown 表格 |
| 10 | 自定义参数 `watermark` 传不进去 | 平台自定义字段不在 SDK 具名参数里 | `TypeError`，改走 `extra_body` |
| 11 | 迭代输出取最后一轮 | 后续轮次得分并不保证更高，可能越改越差 | 修复为 Best-of-N，保留全程最高分 |
| 12 | 首轮生图失败直接判死 | 生图失败常是限流/敏感词等瞬时问题 | 实测触发 `sensitive image` 拦截后自动恢复 |

第 1、4、5 号 Bug 有个共同特征：**它们在代码逻辑上完全"正常"，只有真实运行才会暴露**。这正是从零开始的 demo 测不出来、而真实项目能测出来的东西。

### 阶段 3：补功能

对照比赛要求（赛道二：ComfyUI 集成与智能体落地），识别出项目缺了"编辑与生成流水线"中的**编辑**能力，于是新增了基于 SenseNova U1.5 Lite `/v1/images/edits` 的原生图像编辑：编辑指令构造、双策略（编辑/重生成）、编辑失败自动回退整图重生成。实测一次编辑 82.1 秒成功出图。

### 阶段 4：建立测试

不是"写完功能就完"，而是把修复过的每一个 Bug 沉淀成回归测试，最终 **53 项 pytest 全部通过**。其中用 Streamlit 官方 `AppTest` 无头加载真实 `app.py` 并断言零异常的用例，直接拦截了 8 号 Bug 这类"只有前端运行时才暴露"的问题。

### 阶段 5：文档与发布

重写比赛博客到 6359 字（含 18 个代码块、6 张效果图、12 张截图），更新 README 全部过时数字，用 Playwright 对真实 UI 截图，最后 `git push` 到 Gitee。推送前，Agent 主动做了安全扫描（确认 `.env` 与 API Key 不会泄漏、确认无图片误入库）。

---

## 四、亮点 1：实证驱动，不靠读代码猜

这是本次开发中最有价值的观察。遇到"4:3 尺寸到底合不合法"这类问题时，Agent 的行为是：

1. **先怀疑**：从代码里看到尺寸映射表用的是 `2400×1800`
2. **再验证**：向真实 API 各发一次请求，拿到 `HTTP 400`（错误信息里明确写着"必须是 32 的倍数"）和 `HTTP 200`（正常出图，耗时 30.3 秒）
3. **后修改**：改成合法尺寸，并加了本地 `validate_size()` 提前拦截
4. **补测试**：把"非 32 倍数必须被拒绝"固化为回归用例

验证过程不是猜，而是真实请求：

```bash
# 旧尺寸 2400x1800 → HTTP 400
{"error":{"message":"invalid size, should be auto or WIDTHxHEIGHT. width and
 height should be multiples of 32, width and height should be in [512,4096],
 and aspect ratio should be within 3:1","type":"invalid_request_error"}}

# 修正后 2368x1760 → HTTP 200（30.3s 返回图片）
```

这个顺序在 AI 编程里并不常见。很多工具看到可疑代码会直接"修"，而不先确认远端行为。**对 API 开发来说，远端的行为才是事实，本地代码只是对事实的某种解释**——文档会过期，示例会过时，只有实际请求的结果不会骗人。`deepseek-v4-flash` 的响应结构、`sensenova-6.8-flash-lite` 的 `reasoning` 字段，这些都是 Agent 通过真实调用确认的，而非从文档照抄。

类似的实证还体现在对"静默失败"的敏感上：第 2 号 Bug（解析失败把 JSON 原文当 Prompt）和第 4 号 Bug（超时预算导致质检永远降级）都不会报错，流程看起来一切正常。Agent 不是被错误提醒的，而是**主动审问了"降级路径的产物是否满足输出契约"**——这是真正的工程思维，不是改代码。

---

## 五、亮点 2：多模态能力贯穿整个开发

开发信息图项目，天然需要"看"的能力。这次会话里多模态体现在三处：

1. **读生成结果**：Agent 直接读取生成的 2720×1536 PNG，确认文字可读、布局清晰、配色协调——不是只看"文件存在"
2. **截 UI**：用 Playwright 驱动 Edge 对 Streamlit 页面、Swagger 文档、API 返回的 JSON 截图，作为文档配图
3. **渲染终端**：把真实的 pytest / curl / 运行日志渲染成终端风格截图，保证文档里的"截图"都是真实输出而非编造

当一个 Agent 同时是"编码员 + 测试员 + 视觉检查员"，闭环就可以在它内部完成：改完代码 → 跑起来 → 自己看一眼结果 → 发现不对 → 再改。这个循环速度决定了开发效率的天花板。

---

## 六、亮点 3：长上下文下的跨文件一致性

一次会话里，Agent 修改了 `src/config.py`、`image_generator.py`、`llm_engine.py`、`quality_review_agent.py`、`pipeline.py`、`app.py`、`api.py`、`comfyui/client.py`、`models.py`、`tests/test_pipeline.py`、`blog.md`、`README.md`、`.gitignore` 等 20+ 个文件，且保持了跨文件的一致性：

- 新增的 `RefineStrategy` 枚举，从 `models.py` 定义到 `pipeline.py` 分支、`app.py` 下拉框、README 文档，名字和语义没有漂移
- 重写 6000+ 字博客时，内部引用的函数名、数字、图编号与真实代码完全一致——写完后我用脚本逐一核对过引用的 9 个函数确实存在于源码
- 尺寸表从 `config.py` 到 README 到博客，五组数值完全统一

长上下文的真正价值不是"能读多少 token"，而是**改东边时记得西边也在用它**。跨文件一致性问题在从零 demo 里几乎不会出现，在真实项目里是高频返工源。

---

## 七、亮点 4：把每个坑沉淀成回归测试

这次开发最让我满意的一点是"修 Bug 必补测试"。代表性用例：

```python
def test_prompt_fallback_never_returns_raw_json():
    """回归用例：解析失败时绝不能把原始 JSON 文本当成生图 Prompt"""
    ...

def test_streamlit_app_avoids_pyarrow_widgets():
    """回归用例：结果明细不能用 st.table / st.dataframe（依赖 pyarrow）"""
    ...

def test_llm_slow_model_falls_back_to_next():
    """回归用例：慢模型耗尽自己的时间片后应换下一个模型"""
    ...
```

第 8 号 Bug（`st.image` 参数名）后来就是被 `AppTest` 类测试拦下的——代码能跑起来不代表前端不炸，这类用例把"看起来正常"变成了"可验证的正常"。53 项测试不是凑数，每一项都对应一个曾经真实发生的问题。

修复"模型回退失效"时，沉淀的核心逻辑是预算切片——让链上每个备选模型都能分到一段时间，而不是被第一个卡住的模型吃光：

```python
# src/utils/deadline.py
def model_time_slices(total: int, deadline: float, min_slice: float = 20.0):
    for i in range(total):
        remaining = deadline - time.monotonic()
        if remaining <= 0:
            return
        left = total - i
        slice_ = remaining / left
        if slice_ < min_slice:
            slice_ = min(min_slice, remaining)
        yield slice_
```

修复效果可直接度量：同一场景下，修复前主模型超时只能降级给出 6.5 分，修复后备选模型接手评出 9.2 分——回退机制从"写了等于没写"变成真实生效。

---

## 八、亮点 5：文档与 Git 运维一体化

开发工具的最终形态应该覆盖"写完代码之后"的所有事。这次会话里：

- **文档**：blog 重写、README 更新、字数与图片数统计（对比比赛硬性要求）
- **截图生产**：脚本把真实命令输出渲染成终端风格图，图里没有一行编造
- **安全审计**：推送前扫描全部提交历史，确认无 `sk-` 密钥、无 `.env`、无图片。扫描本身是具体的：

```bash
# 1) 工作区已跟踪文件里有没有密钥字面量
git grep -InE "sk-[A-Za-z0-9]{16,}" -- . || echo "clean"

# 2) 整个提交历史里有没有出现过真实密钥（占位符示例，实际用你的 Key 片段）
git log --all -p | grep -F "sk-your-api-key" && echo "泄漏!" || echo "clean"

# 3) 确认 .env 未被跟踪
git ls-files --error-unmatch .env 2>&1
```

- **Git 操作**：分主题提交、写规范 commit message、fast-forward 推送到 Gitee

整个过程从 `git status` 到 `git push` 都在终端里完成，Agent 没有要求我打开任何图形界面。

---

## 九、局限与风险

一篇可信的测评必须讲反面。

### 9.1 敏感操作仍需人工授权

推送、删除、杀进程这类影响共享状态的操作，Agent 会停下来确认——这是好的安全设计，但也意味着"完全无人值守"仍不现实。它适合"人在环上"的开发模式，不适合"一键全自动"。

### 9.2 长会话的 token 成本真实存在

一次接近完整项目的会话消耗是显著的，实测中甚至触发了远端 API 的 `429 insufficient_quota`。长上下文的代价是：**每条消息都在为前面的全部上下文付费**。合理的做法是像这次一样"一事一会话"（修 Bug、写文档分开），而不是无限追加。

### 9.3 偶发的环境性重试

Playwright 的 driver 在本次会话中出现过两次 `Connection closed while reading from the driver`，重试即可恢复。这类问题不是模型能力问题，而是工具链在 Windows 下的稳定性问题，但确实会打断节奏。

### 9.4 幻觉风险需要人工把关

这是最需要警惕的一点。AI 生成的"事实"（数据、代码行为、文档说法）可能出错，所以本次所有关键数字我都要求"有据可查"——测试输出、HTTP 状态码、git 历史。**把 AI 当协作者而非权威**，是使用这类工具的基本纪律。本文之所以强调真实性，也是这个原因。

---

## 十、实测数据汇总

| 指标 | 数值 | 证据 |
|------|------|------|
| 修复的真实 Bug | 12 | 见上文清单，全部可复现 |
| 回归测试 | 53 项全部通过 | `pytest tests/ -q` |
| 覆盖文件 | 20+（代码/测试/文档/配置） | `git diff` |
| blog 重写 | 6359 字 / 18 代码块 / 6 效果图 / 12 截图 | 脚本统计 |
| 生图尺寸验证 | `2400×1800`→400；`2368×1760`→200（30.3s） | 真实 API 响应 |
| 多模态质检耗时 | 27.3s / 34.9s | 真实调用日志 |
| 质检超时切片效果 | 修复前 6.5（降级）→ 修复后 9.2 | 同一场景两次运行 |
| 原生图像编辑 | 82.1s，2720×1536 | 真实调用日志 |
| Git 交付 | 功能提交全部推送 Gitee | `git log` |
| 安全审计 | 提交历史无密钥、无 `.env`、无图片 | `git grep` + 历史扫描 |

---

## 十一、它改变了什么：终端 Agent 的开发范式

这次开发让我对"AI 编程"的认知从"问答"升级为"交付"：

| 维度 | 传统 AI 编程助手 | 终端 Agent（本次实测） |
|------|------------------|------------------------|
| 交互 | 你问它答，代码你来粘贴 | 端到端执行：写代码→跑→看结果→改 |
| 验证 | 依赖你手动运行 | 自己跑 pytest / 真实 API / 截图 |
| 上下文 | 单文件或局部 | 20+ 文件跨文件一致性 |
| 多模态 | 只能处理文本 | 看图、截图、渲染终端 |
| 交付 | 给出代码 | 给出可用软件 + 测试 + 文档 + 已推送的仓库 |

这不是"更聪明的补全"，而是工作流的重构：**开发者从"执行者"变成"验收者"**，把精力留给需要判断力的事——定方向、把安全关、复核事实。

---

## 十二、结论与适用人群

**结论**：在"真实项目从半成品到可发布"这个最苛刻的评测科目上，CodeBuddy CLI × Hy4 preview 交出了可验证的成绩——12 个真实 Bug 逐一修复并固化为 53 项测试，功能补齐、文档重写、安全推送一气呵成。它最突出的不是"写得多快"，而是**实证驱动 + 闭环验证 + 全链路交付**这三件事的组合。

**适用人群**：

- 维护历史代码库、经常被"静默 Bug"折磨的工程师——实证驱动的调试方式会明显减少返工
- 需要端到端交付（代码 + 测试 + 文档 + 发布）的全栈 / 独立开发者
- 正在评估"终端 Agent"是否值得引入团队的工程负责人

**不适用人群**：需要绝对无人值守自动化的场景；对"AI 说了算"有天然信任、不打算复核事实的场景。

> **一句话总结**：好的 AI 编程工具不是替你写代码，而是替你闭环——从发现问题、验证根因，到修复、测试、交付，全程有据可查。CodeBuddy CLI × Hy4 preview 在本次实测中做到了，而这篇测评本身就是它的产物之一。


评价一个 AI 编程工具，最有效的办法不是跑 benchmark，而是把一个真实的、带着历史包袱的项目交给它，观察它如何从"半成品"走到"可发布"。本文记录我使用 CodeBuddy CLI 驱动 Hy4 preview，对 SenseNova 多模态 Agent 项目做了一次完整的"还原—修 bug—补功能—建测试—写文档—发布"全流程。所有结论都有据可查：git 历史、53 项 pytest、真实 API 调用的状态码与耗时。这篇博客就是这次开发的全程实录与工具测评。

【工具测评】CodeBuddy CLI×Hy4 preview实测：把SenseNova项目从「能跑」修到「能发布」—12个真实 Bug、53 个回归测试

评价一个 AI 编程工具，最有效的办法不是跑 benchmark，而是把一个真实的、带着历史包袱的项目交给它，观察它如何从"半成品"走到"可发布"。本文记录我使用 CodeBuddy CLI 驱动 Hy4 preview，对 SenseNova 多模态 Agent 项目做了一次完整的"还原—修 bug—补功能—建测试—写文档—发布"全流程。所有结论都有据可查：git 历史、53 项 pytest、

全栈工程师

开发工具

人工智能

后端

实测CodeBuddyCLI×Hy4preview驱动真实项目全流程：修复12个Bug、53项测试全绿、6000+字文档与Git推送一气呵成。亮点在实证驱动调试、多模态全链路、跨文件一致性，局限是敏感操作需人工授权、长会话token成本高。适合被静默Bug困扰的工程师与需端到端交付的独立开发者。

回归测试

代码解释

安全审计

智能体

AI编程

Windows

Python

Agent

JSON

2026上云采购 | AI焕新·智启新局

腾讯云代码助手CodeBuddy个人版限时免费！

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

【工具测评】CodeBuddy CLI×Hy4 preview实测：把SenseNova项目从「能跑」修到「能发布」—12个真实 Bug、53 个回归测试-腾讯云开发者社区-腾讯云

【工具测评】CodeBuddy CLI×Hy4 preview实测：把SenseNova项目从「能跑」修到「能发布」—12个真实 Bug、53 个回归测试

【工具测评】CodeBuddy CLI×Hy4 preview实测：把SenseNova项目从「能跑」修到「能发布」—12个真实 Bug、53 个回归测试

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐