Claude Code 前端演示记录：AgentHub 与 Codex 产物对照
保留同一中文需求下的 Claude Code 与 Codex/GPT-5.5 两次 AgentHub 演示观察，核对交互、移动端截图和历史构建记录，并明确模型标识、证据和可比性限制。
记录范围与证据
本文保留原作者当时的截图、需求和演示观察。当前仓库只有文章与图片，没有原始可运行演示工程、依赖锁文件、完整构建日志或交互测试 trace；本次编辑没有重新运行那个演示。下文构建体积、耗时和代码结构细节属于历史记录，不是可独立复跑的测量结果。九项检查是展示层面的人工记录，不是自动化通过率或生产验收。
Claude Code 是执行工具，基础模型需要单独核验。旧稿“Claude Code 4.7”和当前 URL 中的 4.7 是历史标签；本页没有 CLI 版本输出、会话模型 ID 或请求日志可证明具体版本。截图中的 opus-4.7、sonnet-4.6、haiku-4.5 均为 mock 卡片文案，不代表实际调用。本文不据此声称 1M 上下文、token 用量或模型之间的能力差异。
作者当时记录两次使用同一中文需求，但没有保留完整会话供逐字比对；工具配置、依赖和执行过程也未全部控制。因此这里只比较两个产物，不把差异归因于基础模型。下文是提示词摘录，完整中文原文保留在上一篇。
这是同一产品需求的第二次独立演示。上一次交给 Codex/GPT-5.5 的结果记录在 AgentHub 评测，这次保留 Claude Code 产物的观察，用来比较两个原型的布局和交互取舍。
这份演示记录检查什么
1. 实验设置
作者当时记录，这次也从空目录开始，由 Claude Code 创建 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评测里的完整版本。上面的摘录省略了重复设计条款。作者当时说明实际使用了上一篇的完整需求，包括避免单一蓝紫渐变、移动端不能横向溢出等要求；由于会话原始记录未保留，这一陈述不能替代对输入、配置和运行过程的独立复核。
2. 它交付了什么
Claude Code从空目录开始，自己生成了一个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. 它做对了什么
第一，这次选择了不同的控件和窄屏布局
上一篇讨论的两个观察点是：状态切换用了原生 <select>，移动端 Agent 轨道右侧只显示部分卡片，滚动可达性待验证。这次Claude Code在同样的提示词下，主动把状态切换做成了自定义dropdown menu（带"Move to"标题、CircleDot图标、当前状态用Check标记），并且看板上额外提供HTML5原生的拖拽方式——drag-over时目标列会高亮，dragging时源卡片会半透明。移动端的Agent列表也老老实实做成了 overflow-x-auto no-scrollbar 的横向strip，加上 overflow-x-hidden 的main容器，原作者在 393px 视口下未观察到整页横向溢出。这些是本次产物的实现选择；不能据此推断模型在其他任务中也会采用相同方式。原生 select 本身并不是功能或可访问性缺陷，是否替换仍取决于需求。
第二，Mock数据写得像真项目
6个Agent各有人格化名字（Atlas、Pixel、Forge、Sentry、Lens、Mason），分别带不同的Claude模型标签（opus-4.7、sonnet-4.6、haiku-4.5），用于表现“不同角色对应不同模型”的界面概念；这不是真实模型路由或计费记录。任务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还略大
原记录的主 JS 产物为 599.24KB（gzip 170.40KB），与上一篇约 561KB 的记录相差约 38KB，并出现了 Vite 的 Some chunks are larger than 500 kB 提示。这里没有 bundle 分析报告，不能把差额确定归因于 Agent 数量、图表模式或拖拽逻辑，更不能据此判断模型代码效率。后续应先检查依赖占比和加载路径，再评估图表或 Drawer 是否适合懒加载。
桌面拖拽有记录，触屏路径仍需验证
作者当时记录桌面鼠标拖拽可以改变状态，任务卡的“…”菜单也能执行状态切换。实现使用 HTML5 原生 draggable，但本页没有保留 iOS Safari 真机或其他触屏浏览器的操作记录；不能把“未验证”写成“浏览器不支持”。正式使用前需要验证触屏、键盘以及菜单替代路径，再决定是否采用支持这些交互的拖拽库。
没有可访问性tab order的特殊处理
键盘导航能用——button、role和aria标签都齐全，focus ring也定义了 .focus-ring utility——但drawer打开后没有focus trap，Tab键会跑出drawer到背后的页面里。这个问题在demo里看不出，但正式产品应进一步核对焦点管理和完整键盘流程。算是一个"很容易加但它没加"的项。
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：原记录 9 项展示检查满足，状态切换是自定义menu + 拖拽双通道，6 个带 mock 模型标签的 Agent，3个项目可切，主chunk 599KB（多了38KB）。
按当时的记录，两份产物都可以用于演示和讨论。Claude Code 这次的自定义状态菜单、窄屏布局和主题组织更符合我的审美偏好；Codex 这次的主包记录略小。原生 select 不是错误，自定义控件也不会自动获得更好的可访问性；这些取舍应放回具体原型评价。
我的取舍是先用这两份原型讨论信息结构和操作流程，再单独检查状态持久化、日志、焦点管理和真实接口。不能把这次偏好转化成“哪个工具更适合所有前端项目”的结论。
作为个人使用偏好，我通常愿意先用 Codex 做代码检索和排障，再让 Claude Code 尝试一版页面布局。这段偏好没有系统采样，也不是本文演示能够证明的能力分工；读者应在自己的仓库、工具配置和任务上验证。
这份中文长提示词明确了很多产品和交互决策，可能减少自由发挥的空间。但没有进行简短提示词对照，也没有重复运行，因此无法给提示词分配“60% 的贡献”，或预测两种工具在更简短需求下的差距。
方法与结果问答
为什么不再把“Claude Code 4.7”当成已确认版本？
Claude Code 是执行工具，基础模型需要单独记录。旧稿和 URL 中的 4.7 只是历史标签；本页没有保留 CLI 版本输出、会话模型 ID 或请求记录。演示卡片中的 opus-4.7、sonnet-4.6、haiku-4.5 是 mock 数据，不能证明生成此项目时实际调用了这些模型。
9 项检查意味着生产可用吗？
不意味着。9 项是作者当时记录的展示项与基本操作检查，不是自动化通过率。详情面板的 Pause/Reassign 等按钮没有业务 handler，焦点约束、持久化、操作日志及真实 API 接入仍未完成；移动端也只保留了 393px 截图和当时观察。
599KB 与 561KB 能证明哪个模型代码效率更高吗？
不能。它们是两次演示的历史主 JS chunk 数字，约相差 38KB；这里没有保存完整依赖锁定、分析报告或相同条件下的重复构建。功能与依赖差异可能影响体积，但无法从总量确定原因或模型效率。
移动端拖拽已经验证了吗？
没有保留 iOS Safari 真机触摸测试记录。作者记录了桌面拖拽和任务菜单操作，截图能展示窄屏布局，不能证明触屏拖拽或菜单焦点行为。正式使用前应在目标设备验证拖拽、菜单替代路径和键盘操作。
可以据此选择 Sonnet、Opus 或 1M 上下文吗？
不能。这次没有独立的 Sonnet/Opus 调用对照，也没有可核验的上下文配置或 token 用量记录。模型卡片只是示例数据；具体可用模型和上下文应以当前官方配置及实际会话记录核对。
同一份提示词是否足够构成控制实验？
不够。作者当时记录两次使用同一中文需求，但此页只有提示词摘录，没有两次完整会话、参数、工具版本和重复运行。比较应限于这两个产物；没有做短提示词对照，不能给提示词贡献百分比。