Claude Code 4.7前端实测：AgentHub AI控制台交付评测（vs GPT-5.5对照实验）
同一份1500字提示词分别交给Claude Code 4.7（Opus 4.7 / Sonnet 4.6）和Codex/GPT-5.5生成AgentHub AgentOps控制台。Claude 9/9项交付检查全部通过，主JS chunk 599KB（gzip 170KB），2.42秒构建完2388个模块。从交付清单、自定义控件、移动端边界、状态联动深度、代码结构和构建产物六个维度，量化两个AI编程Agent在前端任务上的真实差距，也对比Claude Code与Cursor、Codex CLI在SaaS控制台原型上的工程化取舍。
这是一组对照实验的下半场。同一份接近1500字的提示词，上半场我交给了Codex/GPT-5.5（结果记录在另一篇 AgentHub评测），这次换成Claude Code 4.7，看看同样的需求，最新一代AI编程Agent能不能做出一个更接近产品形态的AgentOps控制台。
这篇文章主要回答什么搜索意图
1. 实验设置
为了让两次结果可以直接比较，我没有改提示词的一个字。同样的产品背景、同样的页面区域要求、同样的交互清单、同样的设计约束、同样的代码质量底线、同样的交付要求。这次的执行环境是Claude Code 4.7命令行Agent，从空目录开始让它自己创建Vite + React + TypeScript项目并完成全部页面。完整提示词如下：
请你实现一个高完成度的前端demo页面，用来展示一款「AI项目协作控制台的核心界面。
产品名叫「AgentHub」。它用于管理多个AI Agent在同一个软件项目中的协作情况：任务分配、执行状态、代码变更、风险提醒、成本消耗、上下文记录和交付进度。
目标：
做一个真实可用、视觉精致、交互完整的单页前端应用，而不是营销落地页。首屏就是产品本体。
技术要求：
1. 优先使用当前项目已有的前端技术栈和组件风格。
2. 如果当前目录没有前端项目，请创建一个Vite + React + TypeScript项目。
3. 可以使用CSS / Tailwind / shadcn / lucide-react / recharts等常见前端库，但不要依赖后端服务。
4. 所有数据使用本地mock数据。
5. 页面必须能直接运行和预览。
页面要求：
请实现一个完整的AgentOps控制台，必须包含以下区域：
1. 顶部导航
2. 左侧Agent列表（至少5个：Planner / Frontend Builder / Backend Integrator / Test Runner / Code Reviewer）
3. 核心指标区（至少5个：Active Agents / Completed Tasks / Open Risks / Failed Checks / Estimated Cost）
4. 项目进度区（Backlog / In Progress / Review / Done四列看板）
5. 图表区（至少两个：token或cost over time、throughput或checks pass/fail）
6. 风险和提醒区（至少4条，severity分low / medium / high）
7. 活动时间线
8. 详情面板或弹窗
9. 交互要求：明暗主题、时间范围、Agent筛选、任务详情、风险severity过滤、看板状态切换或拖拽
10. 响应式：桌面端像SaaS控制台、移动端不能横向溢出、左侧Agent列表在移动端变成顶部横向列表或折叠区
设计要求、代码质量要求、交付要求一并给出，详见上一篇GPT-5.5评测里的完整版本。为了篇幅，我在上面省略了部分重复段落，但实际投入的提示词和GPT-5.5那次完全一致——包括"不要使用大面积单一蓝紫渐变"、"不允许出现文字重叠或移动端横向滚动"这些边界条件。这种"控制变量"的做法就是为了让两次交付的差异，尽可能落在模型本身的能力上。
2. 它交付了什么
Claude Code 4.7从空目录开始，自己生成了一个Vite + React + TypeScript + Tailwind的项目骨架，依赖只引了lucide-react和recharts，没有上shadcn。最终是9个核心组件、按特性分8个目录，加一份15.3KB的结构化mock数据。
npm run build 在2.42s完成；2388个模块，主JS 599.24KB（gzip 170.40KB），CSS 26.49KB。Vite提示主chunk超过500KB，跟GPT-5.5那次一样属于demo可接受范围，上线前还得拆。3. 它做对了什么
第一，把GPT-5.5留下的几个明显坑都补了
上一次GPT-5.5最被吐槽的两个地方：状态切换用了原生 <select>，移动端Agent横向卡片有右侧裁切。这次Claude Code 4.7在同样的提示词下，主动把状态切换做成了自定义dropdown menu（带"Move to"标题、CircleDot图标、当前状态用Check标记），并且看板上额外提供HTML5原生的拖拽方式——drag-over时目标列会高亮，dragging时源卡片会半透明。移动端的Agent列表也老老实实做成了 overflow-x-auto no-scrollbar 的横向strip，加上 overflow-x-hidden 的main容器，393px视口下没有出现任何横向滚动。这两个细节很关键，因为它们不是提示词新增的需求，而是Claude自己判断"这地方要做精"。
第二，Mock数据写得像真项目
6个Agent各有人格化名字（Atlas、Pixel、Forge、Sentry、Lens、Mason），分别带不同的Claude模型标签（opus-4.7、sonnet-4.6、haiku-4.5），暗示了实际AgentOps平台里"不同复杂度任务匹配不同模型"的成本策略。任务ID走T-2041到T-2049再加3个done态T-2031/2032/2033，文件路径写到 src/checkout/PaymentForm.tsx 这种程度，Risk里的具体数字（"Coverage fell from 82.1% to 77.9% after PaymentForm rewrite — 3 new branches lack tests"）和Activity里的diff统计（"Updated PaymentForm.tsx (+412 / −287)"）能互相对上。这种"自洽到能让人相信这是真项目状态"的程度，比GPT-5.5那次还要精细一点。
第三，主题系统的工程化做得到位
它没有简单地搞一个 light / dark 二选一，而是把所有颜色变量写成RGB三元组（--bg-base: 247 248 250），让Tailwind可以做 bg-status-running/10 这种带透明度的派生用法。状态色（running / idle / blocked / reviewing / done）也都集中在CSS变量里，整个项目要换配色只需要改两段 :root。这是个很"工程师"的选择，提示词里完全没要求，但它主动这么做了。配合useTheme hook读 prefers-color-scheme、写localStorage、加 class="dark"，主题切换不会闪屏。
第四，交互细节超出demo该有的水平
Drawer打开时锁 document.body.style.overflow、ESC键关闭、点遮罩关闭、动画用 animate-slideIn 入场；项目下拉用 mousedown 监听外点关闭；Risk的关闭按钮hover才出现（避免主界面太"按钮多"）；运行中的Agent状态点配 animate-pulseRing 脉冲动画；KPI数字开了 font-variant-numeric: tabular-nums 让对齐稳定。这些都是单独看不起眼、加在一起就会让人觉得"这页面做事的人懂"的细节。
4. 还能挑出哪些问题
主chunk比GPT-5.5还略大
产物体积上Claude给出的是599.24KB（gzip 170.40KB），比GPT-5.5那次的561KB还多了38KB。原因不复杂：6个Agent + 多项目下拉 + Tokens/Cost双模式图表 + drag-and-drop逻辑，全都打进了同一个entry。Vite也明确给了 Some chunks are larger than 500 kB 警告。要做的事很清楚——Recharts按需import、Drawer用 React.lazy，但Claude没有自己拆，跟GPT-5.5一样停在了"demo可用"这条线上。
Drag-and-drop只是HTML5原生，没做触屏fallback
桌面端鼠标拖拽顺滑，但HTML5原生 draggable 在iOS Safari上基本不工作。它倒是同时给了任务卡上的"…"菜单做fallback（点开后选"Move to →"也能改状态），所以触屏用户不会被卡死，但拖拽这个交互在移动端事实上是"装饰品"。要真的做成生产可用，得换成 @dnd-kit/core 这种支持pointer events的库。提示词里写的是"看板任务状态切换或拖拽模拟，至少要能改变任务状态"，所以严格说没失约，只是离"可上线"还差一段。
没有可访问性tab order的特殊处理
键盘导航能用——button、role和aria标签都齐全，focus ring也定义了 .focus-ring utility——但drawer打开后没有focus trap，Tab键会跑出drawer到背后的页面里。这个问题在demo里看不出，但任何要送审的SaaS产品都会卡在a11y审计上。算是一个"很容易加但它没加"的项。
5. 同一组追加交互测试，它的反应
上一篇评GPT-5.5的时候我做过一个组合操作：把Backlog里的某条任务移到In Progress、把时间范围切到 7 Days、再只看high risk。这次同样的操作我又跑了一遍：Claude给的项目板用拖拽和"…"菜单两种方式都能改状态，被拖动时源卡片半透明、目标列出现accent高亮边框；时间范围切到 7 Days 时，"Active Agents"卡的scale倍率、Estimated Cost、token usage图都跟着重算了；Risk的severity pill按住可以多选可以全关，全关时会自动恢复成"全选"避免空状态。
从代码读，这几组状态都集中在App组件的顶层 useState，由 useMemo 派生series / throughput / metrics和filteredRisks。和GPT-5.5那次一样没有引入Redux / Zustand之类的状态库，但和上一次不同的是：它把"哪些数据派生、哪些数据原始"分得更清楚，看板任务用 setTasks 写回，Risk的解决用 setRisks，severity筛选只动UI层。这种"什么是源数据、什么是衍生数据"的边界，在demo里就是能不能往真实API上接的预演。
同样要承认它的边界：刷新页面状态全部重置；Drawer里的Pause / Reassign按钮没有任何action handler；Activity timeline不会因为我刚才把任务从backlog拖到in_progress而新增一条记录。也就是说"内部状态联动"做好了，"操作日志回写"和"持久化"留给了下一阶段。
6. 同一份提示词，两次结果横向比一比
把两次的交付摆到一起，规律是肉眼可见的：
- GPT-5.5：8项通过、1项部分通过（移动端有横向裁切），状态切换用原生select，5个Agent，1个项目，主chunk 561KB。
- Claude Code 4.7：9项全部通过，状态切换是自定义menu + 拖拽双通道，6个Agent + 模型归属，3个项目可切，主chunk 599KB（多了38KB）。
两者都没有"一击致命"的硬伤，都是可以拿去演示、可以截图、可以拿来跟产品同事讨论结构的级别。GPT-5.5在"画一个像样的工作台"这件事上已经合格；Claude Code 4.7在"画好之后再补几刀产品化细节"这件事上更主动，主要体现在它会把GPT-5.5留下的那几个明显坑（原生select、移动端裁切）顺手解决，而且把主题系统、状态分层、a11y属性写得更工程化一点。
代价就是产物略大、复杂度略高。如果你的需求是"能跑起来开会演示"，两个Agent都能交差；如果需求是"明天就要拿去给设计师和PM一起评审、会有人挑细节"，Claude Code 4.7这次的结果会让讨论更聚焦在产品逻辑上，而不是去解释"为什么这个select看起来不对"。
这里也放一个更主观的日常体感：我一直觉得Codex在后端任务、代码检索、定位bug和顺着调用链追问题上更稳一些，尤其是仓库里已有逻辑比较复杂的时候，它更像一个愿意把线索查到底的后端工程师；但在前端页面这类需要审美、布局、交互细节一起成立的任务上，Claude Code往往会更敏感一点。这次对照也能看出来，Claude Code 4.7在自定义控件、移动端边界、视觉层次和"这个页面看起来像不像真产品"这些地方更主动。这个判断不是benchmark结论，更像长期使用后的偏好总结：后端排障我会更想先叫Codex，前端原型和页面打磨我会更愿意先让Claude Code跑一版。
还有一个不该忽略的变量：提示词的细致程度。1500字的边界条件，本身已经替模型完成了60%的判断。如果换成"做个AgentOps控制台"这种一句话需求，差距大概率会被拉得更大，因为弱一点的模型会在边界没规定的地方乱发挥，而强一点的模型会自己补上合理默认。提示词写得越详细，模型之间的差异就越收敛在"工程细节"和"代码风格"这一层；写得越潦草，差异就越落到"产品判断"这一层。这次的对照实验里，因为提示词写得很满，所以差异更多体现在工程细节上，而不是天差地别的形态差异。
常见搜索问题
Claude Code 4.7和Codex/GPT-5.5在前端任务上的差距大吗？
在我这次1500字提示词下的实测里，差距不算大但很有方向性：Claude Code 4.7在9项交付检查里全部通过，GPT-5.5是8项通过+1项部分通过（移动端横向裁切）。Claude主动把状态切换做成了自定义menu+拖拽双通道，把GPT-5.5那次留下的原生select问题也顺手解决了。代价是主JS chunk比GPT-5.5多38KB（599KB vs 561KB），原因是6个Agent + 多项目 + 双模式图表打进了同一个entry。
Claude Code 4.7适合用来做SaaS控制台原型吗？
从这次AgentHub的结果看，是适合的。它能从空目录创建Vite + React + TypeScript + Tailwind项目，组件按特性分8个目录共9个文件，mock数据15.3KB且内部自洽。生产构建2.42秒、2388模块、主JS gzip 170KB。要上生产还需要按需import Recharts、lazy-load Drawer、补focus trap和触屏拖拽，但拿去做产品评审完全够用。
为什么Claude Code 4.7生成的页面主chunk比GPT-5.5还大？
因为它做的事情更多：6个Agent（多了一个Refactor Surgeon）、3个可切换项目、Tokens/Cost双模式图表、HTML5拖拽逻辑全部打进同一个entry，所以主chunk从GPT-5.5的561KB涨到599KB。这不是Claude的代码效率更差，而是它在同样的提示词下选择交付更多功能。要降下来就得做手动splitChunks或lazy import。
Claude Code 4.7怎么处理主题切换和颜色系统？
它把所有颜色变量写成RGB三元组（例如 --bg-base: 247 248 250），而不是常见的hex字符串。这样Tailwind可以在 bg-status-running/10 这种带透明度的工具类里直接派生alpha。状态色（running / idle / blocked / reviewing / done）也全部集中在CSS变量里。配合useTheme hook读prefers-color-scheme + 写localStorage + 加class="dark"，主题切换不会闪屏。这是提示词没要求但它主动做的工程化选择。
Claude Code 4.7的mock数据有什么不一样？
6个Agent都有人格化名字（Atlas / Pixel / Forge / Sentry / Lens / Mason）并标注了不同的Claude模型（opus-4.7 / sonnet-4.6 / haiku-4.5），暗示了真实AgentOps平台里的成本路由策略。任务、风险、活动事件之间能互相对上：例如Risk里的coverage下降百分比和Activity里的diff统计都能匹配同一个PaymentForm.tsx改动。这种自洽程度比上一次GPT-5.5还高。
AI编程Agent的看板拖拽体验有什么坑？
Claude Code 4.7用的是HTML5原生draggable API，桌面端鼠标拖拽流畅，但iOS Safari基本不支持。它同时做了一个"…"菜单作为fallback能改状态，所以触屏用户不会被卡死，但拖拽这个交互在移动端事实上是装饰品。要真的做成生产可用，得换成 @dnd-kit/core 这种支持pointer events的库。
提示词写得多详细，对AI编程Agent结果影响有多大？
影响巨大。这次实验的提示词有1500字，覆盖产品背景、页面结构、交互、设计、代码、交付6个维度，本身就替模型完成了60%的判断。提示词越详细，模型之间的差异就越收敛在工程细节和代码风格层；提示词越潦草，差异就越落到产品判断层。如果换成"做个AgentOps控制台"这种一句话需求，Claude和GPT-5.5的差距会显著拉大。
Claude Code 4.7的可访问性做得怎么样？
基础aria属性、role标签、focus-ring utility都齐全，键盘可以遍历所有交互元素。但Drawer打开时没有focus trap，Tab键会跑出drawer到背后页面，这在任何严肃的a11y审计里都会被flag。算是"很容易加但它没主动加"的项，提示词没要求所以它没做。
Claude Code 4.7和Cursor、Codex CLI比有什么区别？
Cursor是IDE形态，强项是边写边补全和把整个仓库当上下文用；Codex CLI和Claude Code 4.7都是命令行Agent，强项是接到一个任务后自己改多个文件、自己跑验证、自己解释结果。这次实测里Claude Code 4.7和Codex/GPT-5.5在同一份提示词下都能完整交付AgentOps控制台，差异主要落在工程化默认值（自定义控件、主题系统、移动端边界）。如果你已经在Cursor里写代码、临时需要"全自动跑完一个完整任务"，Claude Code或Codex CLI更合适；如果你需要"一边人工写、一边AI补全"，Cursor仍然更顺手。
Anthropic Claude和OpenAI GPT在写代码上谁更强？
没有银弹答案。从这次1500字提示词的对照看，Claude Code 4.7（背后是Opus 4.7和Sonnet 4.6）在自定义控件密度、移动端边界、可访问性默认值上更主动；Codex/GPT-5.5在产物体积上略小，结构判断也合格。两家在2026年的差距已经收敛到"工程细节偏好"和"默认产品化深度"，而不是"能不能跑通"。挑选标准更接近"哪个的工程默认值更接近你的团队风格"，而不是"哪个模型更聪明"。
AI生成的前端代码能不能直接上线？
能演示、能讨论、能截图，但不能直接上线。这次Claude Code 4.7的交付里，主chunk 599KB会被Vite标红，drawer没有focus trap，HTML5原生drag在iOS Safari不工作，操作没有持久化，按钮没有真实handler。这些都是demo和生产之间那一层"工程化收尾"的具体内容。我的判断是：AI编程Agent能把前端原型从0推到0.7，剩下的0.7到1.0（拆包、a11y、触屏fallback、状态持久化、错误边界、监控埋点）仍然要靠工程师。
Claude Sonnet 4.6和Opus 4.7写代码差距大吗？该选哪个？
在AgentHub这次的mock数据里，Claude把Atlas（Planner）和Lens（Code Reviewer）标成opus-4.7，把Pixel、Forge、Mason等执行型角色标成sonnet-4.6，Sentry测试型用haiku-4.5。这其实就是社区里在用的成本路由策略：架构判断和PR review给Opus，例行任务给Sonnet，机械型工作给Haiku。日常用Claude Code写代码可以默认用Sonnet 4.6（性价比高），遇到难需求或多文件协调时切到Opus 4.7。差距在"判断深度"和"上下文跨越能力"，单文件改写两者差不多。
Claude Code的1M context window在实际开发里有什么用？
Claude Code 4.7支持1M token上下文，对前端demo这种10个文件的小任务来说富余很多，没有实际差异。1M context的真正用武之地是大型仓库重构、跨10+文件的状态机改造、以及把整本SDK文档+代码一起喂进去做合规审查。这次AgentHub只用到了不到3万token就完整交付了9个组件 + 15.3KB mock数据，1M窗口在demo级任务里几乎用不到，但这也意味着工程师不用提前考虑"context会不会爆"，可以更放心地让Agent自己决定去读哪些文件。