本次选取 WorkBuddy、TRAE Work、QoderWork、Kimi Work 和百度搭子 DuMate，使用同一份《城市分时电价观察站》PRD，分别完成一个网站 MVP。
MVP 是 Minimum Viable Product 的缩写，通常译为“最小可行产品”，指先用一个功能最小但能够运行的版本，验证核心需求和完整流程。
最终，四款产品形成了可检查的交付成果；Kimi Work 因个人版资源排队和执行稳定性问题，未能完成本轮任务。
AI Work Agent交付的网站效果
查看在线 Demo[1] ｜ 查看项目源码[2]
01 从“地图”走向“验证”
上一篇文章整理了 Agent 产品与运行框架地图，重点是看清商业产品、开源框架、通用 Agent 和编码 Agent 之间的大致位置。
这一轮把重点放到真实任务执行上。
本轮先聚焦国内商业 Work Agent。测试任务涉及中文政策资料、国内公开数据源和本地开发环境，要求 Agent 完成资料检索、数据建模、CSV 与 SQLite 数据访问、网站开发及交付说明。
不只验证模型会不会写代码，更关注 Agent 能否把需求转化为任务计划，调用工具持续推进，并留下可运行、可检查、可复现的交付结果。
02 不是排名，是能力验证
这次实测不追求简单排名，而是观察 Work Agent 在真实任务中的完整执行能力。
为了尽量减少底层模型差异，WorkBuddy、TRAE Work 和 QoderWork 均使用 DeepSeek 模型；Kimi Work 和百度搭子使用各自内置模型。由于各产品的系统提示、上下文机制、工具和资源条件并不完全一致，因此这不是一次严格控制变量的模型评测，而是对个人版用户实际可用产品能力的验证。
重点观察六个方面：
-
• 需求满足度：能否准确理解 PRD，并逐项实现关键功能和验收要求。
-
• 数据可信度：能否找到可追溯的公开来源，正确处理数据口径和缺失信息。
-
• 工程可运行性：网站、CSV、SQLite、接口及配置切换是否真实可用。
-
• 产品可用性：页面是否清晰易懂，查询是否方便，交互和视觉呈现是否接近可用产品。
-
• 任务推进与修复：能否拆解任务、持续执行，并处理中途错误和用户反馈。
-
• 效率与成本：完成任务需要多少时间、积分或 Credit，资源排队和人工介入是否影响交付。
真正需要判断的，不只是 Agent 能不能生成代码，而是它能否把同一份需求转化为符合要求、能够运行，也方便使用的 MVP。
03 实测工作模式
这次测试模拟的是让不同 Agent 完成同一个任务。
人的角色是提出业务场景、明确边界和验收标准，并在测试过程中检查结果、反馈问题和确认修复效果。
ChatGPT Work 主要协助梳理需求、完善 PRD，并对最终产物进行复查；
5 款国内商业 Work Agent 则作为执行方，从同一份 PRD 出发，独立完成资料检索、数据建模、网站开发和交付说明。
这样可以把两个环节分开观察：
-
• PRD 是否足够清晰，属于需求设计问题；
-
• Agent 能否理解并完成，属于任务执行问题。
所有 Agent 使用相同的输入文件和任务指令，页面风格和技术方案则由各产品自行决定。
04 MVP 需求描述
为了尽量保证测试条件一致，本轮不提供现成代码或页面模板，各 Agent 均只接收同一份《城市分时电价观察站_MVP需求文档》和相同的任务指令；在满足 PRD 约束和验收要求的前提下，网站布局、视觉风格和交互呈现由 Agent 自主设计。
向各 Agent 提交的 Prompt 如下：
请阅读本地 PRD 文件《城市分时电价观察站_MVP
需求文档.pdf》，理解需求后搭建可运行的网站MVP。
请严格遵守文档中的数据来源、数据库、页面功能、
交付物和验收标准要求。网站设计可以自行收集创意，
整体要求简约、亮眼，适合数据查询和来源追溯。
完成后输出网站代码、数据库初始化脚本、
数据源清单、README 和已知限制说明。
所有生成文件放在指定的 0X_XXXX 目录下，
请首先回复是否理解需求。
任务围绕广东、江苏、山东、浙江和内蒙古 5 个样本省份，完成公开资料检索、数据结构化、网站开发和来源追溯。
网站需要同时支持两种运行方式：
-
• CSV 静态模式：用于 GitHub Pages 或 IIS；
-
• SQLite 本地模式：用于验证数据库建模和查询链路。
数据库结构由 Agent 自行设计。无法确认的数据必须明确标记为缺失或待验证，不得用无来源数据补齐页面。
05 实测结果
评分依据最终交付物、在线页面、源码、运行过程和问题修复记录，覆盖需求满足度、工程可运行性、数据可信度、产品可用性、任务推进与修复、效率与成本六个维度。
分数用于呈现各产品在本次任务中的交付差异，不代表通用性能排名。评分由 ChatGPT 基于最终交付物、实测记录及与作者的多轮复核结果综合评估。
四款产品得分对比图
WorkBuddy：86 分
WorkBuddy 的整体完成度和产品可用性最好。
它支持前端从 CSV 加载数据，也完成了基于 SQLite 的本地接口验证，以及数据导入、来源清单和运行说明等交付。页面布局、信息层级和交互体验也更接近可实际使用的数据产品。
主要不足是查询条件仍不完整，目前以省份名称筛选为主，没有实现 PRD 要求的用户类型筛选。开发过程中出现过 CSV 解析、异步调用和 JavaScript 代码问题，但最终均完成修复。
结论：产品化程度最高，工程链路较完整，但查询能力仍有缺口。
WorkBuddy 首页
省份区域查询
WorkBuddy 首页与查询区域
百度搭子 DuMate：74 分
DuMate 使用内置模型，具体模型名称暂未在官方资料中查询到，也未找到切换或接入第三方大模型的配置说明。它对查询需求的实现最完整，支持省份、季节和用户类型组合筛选，并交付了静态页面、CSV、SQLite、Python 服务和说明文档。
首次交付存在页面无法渲染、省份查询无结果、数据源模式显示错误等问题，均在用户反馈后修复。部分数据主要依据搜索摘要整理，对政策原文的核验深度不足。
本轮累计消耗约 556 积分，实际成本还包括后续多轮排错。
结论：查询功能最完整，但自主测试和数据核验能力仍需加强。
DuMate筛选条件及查询结果
TRAE Work：71 分
TRAE Work 的工程覆盖范围较广，交付了前端页面、CSV、SQLite、Node.js API、导入导出脚本和说明文档。
首次运行存在数据库为空、CSV 字段错位、依赖未安装和数据源模式显示错误等问题，经过多轮修复后才基本跑通。
页面中的省份入口主要用于跳转至详情区域，并不是真正的条件查询，也没有实现用户类型和季节筛选。
结论：工程结构较完整，但首次运行稳定性和需求实现准确度不足。
TRAE Work 省份导航
QoderWork：63 分
QoderWork 的优势是生成速度快，能够迅速形成视觉效果较完整的静态 Demo。
页面包含五省概览、峰谷价差、图表、数据来源和省份详情，但省份卡片与详情弹窗仍属于浏览功能，没有实现多条件查询。
SQLite 方面主要完成了数据库文件、初始化脚本和连接验证，没有形成前端通过接口读取数据库的完整链路。部分数据还采用了二次来源或估算口径。
结论：适合快速形成展示型 Demo，但数据严谨性和工程闭环相对较弱。
QoderWork 五省卡片
Kimi Work：未完成，不评分
测试过程中，Kimi Work 多次出现资源排队和执行停滞，未能形成完整交付。
本轮只记录个人版的实际使用状态，不将“未完成”直接解释为产品能力最低，也不参与评分。
Kimi Work 资源排队或任务停滞
ChatGPT Work：不参与评分
ChatGPT Work 主要用于梳理 PRD、完善验收标准、检查源码与页面、复核 Agent 自评结果及整理文章，因此不与执行型 Agent 横向比较。
测试进入收尾阶段时，当前使用周期仅剩 8% 使用额度，已接近耗尽。该比例反映的是当前周期的总体使用状态，但也说明需求设计、源码检查、页面验收和结果复核同样会产生较高成本。
ChatGPT 当前周期剩余使用额度
06 同一份 PRD，为什么结果不同
WorkBuddy、TRAE Work 和 QoderWork 均使用 DeepSeek，但交付结果仍有明显差异。这说明，底层模型相同或相近，并不意味着最终产物会趋于一致。
差异首先出现在需求理解上。同样是“省份查询”，DuMate 实现了省份、季节和用户类型组合筛选，WorkBuddy 提供省份筛选，TRAE Work 将其处理为页面跳转，QoderWork 则采用省份卡片和详情弹窗。
工程链路的差异更加明显。同样交付了 CSV 和 SQLite，有的版本真正实现了数据加载和接口查询，有的只生成了数据库文件、初始化脚本或连接验证，距离完整运行仍有差距。
自主验证也是重要分界。多个版本在声明任务完成后，仍存在页面无法渲染、查询无结果、数据库为空或数据源模式显示错误等问题，需要用户实际操作后才能发现并修复。
因此，这次实测比较的不只是模型会不会生成代码，而是 Work Agent 能否把需求理解、上下文、工具调用、工程执行和结果验证连续串起来。模型提供基础能力，Agent 的执行链路决定这项任务最终能否做完、跑通并交付。
更佳阅读效果，请移步关注我的公众号
引用链接
[1] 查看在线 Demo: https://tgzhu-0531.github.io/04_my-mvp/[2] 查看项目源码: https://github.com/tgzhu-0531/04_my-mvp
浙公网安备 33010602011771号