codex(gpt5.5) vs opencode + omo(claude opus4.6 指挥 gpt5.5) vs opencode + omo-slim(gpt5.5)
opus4.6 是 kiro 逆向的,智力不如原版满血。
让这三个 agent 针对同一份提示词去做一个前后端分离的项目,提示词如下:
我想做一个自用的临时文件传输项目。
这个项目的定位不是网盘,也不是长期文件管理系统,而是一个轻量级的临时文件访问和传输工具。我的使用场景是:有时候我在外网、局域网、别人电脑或者临时设备上,需要访问我自己某个目录里的文件,进行浏览、下载,或者临时让别人给我上传文件。
项目需要有前端和后端。
前端是一个简洁的网页界面。用户打开网页后,需要先登录。登录成功后,可以看到后端配置中开放出来的目录和文件列表,可以进入目录、查看文件、点击下载。界面不需要复杂,但要清楚、好用,适合电脑和手机访问。后续也需要支持上传文件到指定目录。
后端负责读取配置中的目录,把目录里的文件和文件夹展示给前端,并提供文件下载和上传能力。后端可以使用 Go + Fiber。项目应该支持配置多个目录,每个目录可以有不同的用途,例如只读下载目录、上传目录、临时中转目录等。
鉴权方面,我希望使用 TOTP。也就是说,项目里预先配置一个固定的 TOTP secret,我把它导入手机上的验证器软件。以后我访问这个系统时,只需要输入手机上显示的动态验证码就可以登录。登录之后,在一段合理时间内应当保持登录状态,不要每次刷新页面或下载文件都重新输入验证码。但也不能永久保持登录,应该有退出登录和会话过期机制。
后端还需要支持临时令牌功能。登录后的我可以创建临时下载链接或临时上传链接。临时下载链接可以让没有登录的人在一定条件下下载指定文件或访问指定资源;临时上传链接可以让没有登录的人上传文件到指定位置。令牌应该可以设置有效期,也应该可以被我手动撤销。具体来说可以搞一个管理员账号用来管理这些
可以用vue,项目需要有一个简单的管理界面,用来查看当前可访问的目录、管理临时令牌、创建下载链接、创建上传链接,以及查看一些基本访问记录。访问记录不需要很复杂,但至少要能让我知道最近有哪些登录、下载、上传或令牌使用行为。
项目最终应该方便部署和使用。最好可以通过 Docker 或类似方式启动。配置文件里可以设置监听端口、开放目录、TOTP 信息、上传下载相关限制、会话有效期等。公网访问时可以放在 Nginx 或 Caddy 后面,但项目本身不要强依赖这些组件。
请你根据以上需求,独立完成项目的设计和实现。你可以自行决定具体的前端框架、后端结构、数据库或存储方式、API 设计、页面布局和部署方式,但要保证最终项目可以实际运行。
最终我希望能够做到:
1. 启动服务;
2. 打开网页;
3. 输入手机 TOTP 验证码登录;
4. 浏览配置目录里的文件;
5. 下载文件;
6. 上传文件到指定目录;
7. 创建临时下载链接;
8. 创建临时上传链接;
9. 管理和撤销临时令牌;
10. 查看基本访问记录;
11. 方便地部署到局域网或公网环境中等。
最终要搞一个完整的项目出来二号选手使用 ulw-loop,一号和三号选手使用 /goal。
工作情况
二号选手时间最长,使用的 token 最多。一号选手次之,耗费了 653K,历经 24 分钟。三号选手最省,具体数据忘了。
前端概况
这三个选手应该都使用了 ui-ux-pro-max skill。
-
选手一:

-
选手二:




- 选手三




打分
可以发现,二号选手和三号选手页面功能都做的不错,只有风格上的不同,但是一号选手最简陋,一号选手被薄纱。
评委打分
我请 chatgpt5.5(xhigh) 和 deepseekv4 pro 对这三个项目进行独立审计和打分,最终结果汇总如下:
功能对比:
| 功能 | codex | opencode + omo | opencode + omo-slim |
|---|---|---|---|
| TOTP 登录 | 完成 | 完成 | 完成,且有限速 |
| 会话保持/退出/过期 | 完成 | 完成 | 完成 |
| 多目录配置 | 完成 | 完成 | 完成 |
| 文件浏览 | 完成 | 完成 | 完成 |
| 登录下载 | 完成 | 完成 | 完成,但需补目录显式检查 |
| 登录上传 | 完成 | 完成 | 完成 |
| 临时下载令牌 | 完成 | 完成 | 完成 |
| 临时上传令牌 | 完成 | 完成 | 完成 |
| 令牌有效期 | 完成 | 完成 | 完成 |
| 令牌最大使用次数 | 完成 | 缺失 | 完成 |
| 令牌撤销 | 完成 | 完成 | 完成,另有删除 |
| 访问日志 | 完成 | 完成 | 完成,且有保留策略 |
| 管理界面 | 完成 | 完成 | 完成 |
| 公开访客页面 | 后端 HTML/页面 | 前端公开页完整 | 后端上传 HTML,前端公开页不足 |
| Docker 部署 | 部分完整 | 较完整 | 较完整 |
安全排序:
opencode + omo-slim:令牌哈希存储、登录限速、配置校验、原子次数控制最好。安全健壮性子评分为 29 / 35。codex:路径防护和最大使用次数较好,但无登录限速、Cookie Path 缺失、明文令牌、令牌次数竞态和清理策略弱。安全健壮性子评分为 23 / 35。opencode + omo:基础路径防护不错,但会话 ID 写日志、令牌无限次、明文存储、无登录限速、同名覆盖和无测试风险突出。安全健壮性子评分为 16 / 35。
最终结论:
| 排名 | 项目 | 总分 | 结论 |
|---|---|---|---|
| 1 | opencode + omo-slim | 87 / 100 | 综合完成度最高。功能链路完整,前端品质最好,安全设计最强,令牌采用哈希存储并支持原子使用次数控制;存在示例密钥、运行数据入项目目录、登录下载缺少目录显式检查、公开上传页体验较简等问题。 |
| 2 | codex | 75 / 100 | 核心需求基本都实现,有后端单元测试,令牌支持最大使用次数,端到端验证通过;主要短板是后端高度集中在单文件、前端信息过载、移动端体验较弱、无登录限速、Docker 一键部署不完整。安全性明显优于 opencode + omo,因此综合排序上调。 |
| 3 | opencode + omo | 72 / 100 | 功能覆盖完整,前后端整合方式较好,公开下载/上传页和上传交互较完整;但安全短板较多,包括无登录防爆破、会话 ID 写入日志、令牌无最大使用次数、令牌明文存储、同名上传可能覆盖、测试缺失,因此综合排序下调。 |
总结
看来三号选手,也就是 opencode + omo-slim 并全用 gpt 模型略胜一筹啊。不过 omo 表现拉胯,也可能与 claude 智商不满有关系。
三号选手写的此项目的后续版本在这里
