写了个benchmark想看看实际的速率区别。 测试-1 （点击了解更多详细信息） bench代码 （点击了解更多详细信息） config.json （点击了解更多详细信息） 2.7-highspeed在代码生成类别速度比文字快一点，而且如果涉及到中文tps就会变低。在设定maxtoken比较小的情况下速度也会打折扣。这个速度比率和价格感觉不如买非极速版了。这个约100TPS就很灵性，主打四舍五入。bench代码的计算不知道对不对，有懂得佬看看。 3 个帖子 - 2 位参与者 阅读完整话题
目前高强度用了一个月的反重力（ultra砍额度前一周49年入kmt了）和codex的桌面端，主要在公司的win10环境下使用。 antigravity这边是加了一个家庭组，翻车过一次退了部分费用后重新加了另外一个。 主要使用opus4.6模型，用起来的感觉是opus确实能发现写gpt发现不了的问题，相对gpt水平更高点，如果不是在高峰期（我使用的第一周），配置上自动接受的工具后开发体验很舒服，加上量很大，就很爽。至于Gemini，基本感觉不可用。 但是后面砍完额度加上时不时的执行中断就很不爽，因此把所有的mcp和skill都关掉了，用原始的prompt engineing 和opus交互，中间遇到很多执行中断和执行到一半后报错说服务器高流量。 体验很差，但是砍完额度后用插件算下来5h限额有20刀的opus额度和积点可以兑换，一天如果规划下可以用4个5h限额，勉强是便宜但是量还大，现在改了ultra还有周限额后就很难想继续续费了。 花费：约150一个月，基本上是给谷歌交了25美元 codex这边三月初是用ldc兑换的team组，ldc没了之后就买了两个无质保的team一直到现在还在用，这个月砍完额度后也上了两个成品号的plus 一直在codex cli 里和codex的app里手动切号使用。 gpt 5.4xh 给我的感觉就是不喜欢说人话，天天收口给人收麻了，而且喜欢陷入局部最优解里而忽略了整体的结构，必须要用提示词拉回来。 我用了superpower的skills 然后装了些常用的mcp，该起公司的屎山代码还是不错的，就是稍微有点费token。 以前和反重力补充着用的时候基本用不完，现在主力用codex不开fast模式大概两三小时用完，开fast模式1小时用完一个 5h的限额，周限额大概是5倍的5h限额。我目前的情况4个号用1周基本有剩下的。我还用其中一个plus号试了下hermes，这个也很烧token，如果想爽用估计得上pro套餐。 另外如果不走cpa或者别的to api工具，想Hermes这种是不支持直接用team登录的，好像需要母号设置下，plus可以直接登录。 codex这边不好用的地方就是在压缩上下文的时候会用很久时间而且会时不时失败，不知道是我的问题还是他app的问题。不过比起antigravity各种千奇百怪的bug，codex app的完成度非常高。 花费：1个月 2个team 2个plus 约35元。后面如果算上封号和没有ldc的白嫖，可能要60-70。给openai交了0刀（但是增加了4个用户？） 网络这边是拼了个夏威夷的家宽加上一个有台湾和日本家宽（存疑）的机场，有点贵但是胜在稳定性不错。大约要花费70元 1 个帖子 - 1 位参与者 阅读完整话题
这和网页对话有区别吗？IDE也没集成。用习惯了反重力这个完全不知道咋用。代码只能打开看。运行调试咋整 命令行运行？ 7 个帖子 - 6 位参与者 阅读完整话题
因为公司严查挂梯行为，最近部署了 cpa 和站内佬友开源的 halo webui，原理看着是 cpa 拿到 codex 的授权，反代出来使用！那同样的 5.4 模型，codex 里的模型会进行特调吗，导致对话式应用在使用时不如 web 端。还有怎么复刻官网的一些 thinking，pro 等模式呢？ 3 个帖子 - 3 位参与者 阅读完整话题
佬友们，想开个Pro 20x的，但是现在有90的还是180的，这俩渠道有区别么，哪个相对稳点 7 个帖子 - 7 位参与者 阅读完整话题
还没开始用hermes agent，想知道有佬在玩吗？聊下和openclaw的区别和感受 1 个帖子 - 1 位参与者 阅读完整话题
不考虑机器部署的问题（能部署） 想问下大佬们，比如开源的 kimi-2.5 以及 glm5.1，是不是自己下载搭建的效果，和买官方 coding plan 是一样的呢。官方是不是还有一些其他能力，是自己搭建做不到的 1 个帖子 - 1 位参与者 阅读完整话题
昨天发了一个glm5.1和opus4.6的对比，做的是后端管理系统的全栈开发，本来想让他们去做一个agent的，但是感觉麻烦，就做一个最基本的后端管理系统， 再次表明我的态度，我不是要真的去对比他们两款模型到底谁更强，说实话我都没用过满血的Claude模型，甚至国产模型我都是公益站调用的，也就gpt白嫖让我心安，但是最近free额度太少了，所以找替代品 所以我是从实际使用出发，从大家都能接触得到的一些渠道去使用这些模型，去感觉编码能力到底如何 关于我的后端管理系统的完成度可以看这篇帖子: 相同提示词从0→1写项目，glm5.1和opus4.6的区别 开发调优 项目效果是视频的形式，因为本人没有服务器，所以没办法把项目部署到服务器中给大家体验，而且也没啥体验的，看视频也能看出来大概 视频在notion中，链接如下↓ https://cherry-duke-610.notion.site/1-glm5-1-3434bf568bf4800cb23ec7f37786d50e?source=copy_link ，，，， 提示词如下↓ # 项目目标 开发… 这里我主要展示我最初发现端倪的我的“大屏展示”项目， 下面是我使用到的模型以及渠道: 首先是opus4.6去做，渠道测试了两个，一个谷歌反重力，一个GitHub copilot， 还有一个是使用Gemini3.1pro做的，后续使用opus4.6修复了一下bug，是在反重力中使用 还有Geminicli中使用3版本的模型，注意是“3”，不是“3.1pro” 老朋友gpt5.4也没落下，在codex中 还有让我眼前一亮的glm5.1，这个渠道就很多了，不过都没有直接使用官网订阅的渠道，因为我某种程度上来说是一毛不拔的，除非自己的毛被拔完了[流汗] 下面直接看效果： 1.谷歌反重力opus4.6 这个是从零到一全权负责 2.谷歌反重力Gemini3.1pro+opus4.6 这个是3.1pro负责第一遍的项目生成，后开一些地方有bug，使用opus4.6进行修复 3.GitHub copilot 中的opus4.6 全权负责 数据加载出来，我稍后补上 数据加载出来，我稍后补上 数据加载出来，我稍后补上 4.公益站的gpt5.4在codex中使用 全权负责 为什么是公益站，是因为我team会员没了，也不忍心充值plus，更懒得使用free可怜的额度，所以选择公益站拯救我，效果和官方账号渠道没啥区别 5.在codebuddy中使用glm5.1 全权负责 6.公益站中使用glm5.1 全权负责 7.公益站中使用glm5.1 全权负责 8.Geminicli中使用Gemini3 全权负责 对了，忘记说了，我是在claudecode中调用的glm5.1 ！！！这些效果不是关键问题，因为人们的成见是一座大山 ，这座大山是真实存在的，多的我就不说了， 一个模型真的能够让人完全放心的把自己的项目交给它，这样的一个过程，从质疑→信任是非常困难的 所以希望glm能够越来越强吧，即使每个月去付费，但是能够使用稳定靠谱的模型也是值得的 2 个帖子 - 2 位参与者 阅读完整话题
之前自己用一批gpt账号搭建了Sub2API，有个疑问，在codex中使用gpt-5.4和在claude code中调用gpt-5.4有什么区别？ 2 个帖子 - 2 位参与者 阅读完整话题
没用过claude code ，不知道是不是有什么属性加成？ 3 个帖子 - 3 位参与者 阅读完整话题
项目效果是视频的形式，因为本人没有服务器，所以没办法把项目部署到服务器中给大家体验，而且也没啥体验的，看视频也能看出来大概 视频在notion中，链接如下↓ https://cherry-duke-610.notion.site/1-glm5-1-3434bf568bf4800cb23ec7f37786d50e?source=copy_link ，，，， 提示词如下↓ # 项目目标 开发一个可直接运行、前后端分离的「通用企业后台管理系统」基础版。请从零开始搭建并交付一个功能完整、代码规范、具备生产级细节考量的 MVP 产品。 # 核心技术栈与环境要求 - **后端**：Python 3.11，使用 FastAPI 框架。**必须使用 `venv` 创建虚拟环境**（命令：`python -m venv venv`）。 - **数据库**：SQLite（文件存储，路径由你自行决定，但需在部署文档中说明数据库文件生成位置）。 - **前端**：Vue 3（Composition API）+ TypeScript + Vite + Element Plus（或任意你熟悉的 Vue 3 UI 库）。 - **通信**：Axios 调用后端 RESTful API，需处理 JWT 鉴权。 # 必须实现的功能模块（深度要求） 1. **用户认证模块**： - 登录/登出、JWT Token 生成与验证。 - **初始化逻辑**：首次启动应用时，自动创建默认管理员账号（用户名：admin，密码：admin123），并赋予超级管理员角色。 - Token 过期时间设置为 24 小时，前端需在 Token 过期时自动跳转登录页并给出友好提示。 2. **权限管理模块（完整 RBAC）**： - 至少包含 3 个核心实体：用户、角色、权限，并建立正确的多对多关联关系。 - 预设两个角色：「超级管理员」拥有所有权限，「普通用户」仅有部分查看权限（具体权限项由你设计，至少包含 3 个不同的权限标识）。 - **前端要求**： - 路由需根据用户权限**动态生成或过滤**（无权限的页面无法直接通过 URL 访问）。 - 页面内的操作按钮（如删除、编辑）需根据权限**精确控制显隐**。 3. **业务数据管理模块**： - 请自行选择一个核心业务实体并为其命名（例如「文章管理」、「产品管理」、「客户管理」或你认为合适的其他实体）。 - 针对该实体，实现完整的 **增、删、改、查** 功能，需包含以下细节： - 列表页支持**分页**和**模糊搜索**（至少按名称/标题搜索）。 - 表单需有**前端校验**（如必填项提示）和**后端 Pydantic 校验**（如字段长度、格式）。 - 删除操作必须提供**二次确认弹窗**。 4. **操作日志模块**： - 记录每个用户的关键操作（登录、登出、创建、修改、删除），日志需包含：操作人用户名、操作时间、IP 地址（可用 `127.0.0.1` 模拟）、操作描述、操作结果（成功/失败）。 - 提供日志列表查看页面，支持按操作人、时间范围筛选。 5. **数据看板模块**： - 首页 Dashboard 展示统计卡片：业务实体总数、今日新增用户数、系统操作日志总条数。 - 使用 ECharts 或类似图表库绘制一个**近 7 天用户活跃趋势图**（活跃定义为登录次数）。图表数据可用**模拟生成的方式**在后端接口返回，但生成逻辑需写在对应 API 中。 # 非功能性要求（考验工程素养） - **异常处理**：后端所有接口需返回统一结构的 JSON 响应（包含 `code`、`message`、`data` 字段）。前端需对网络错误、后端业务错误（如权限不足）进行**全局拦截与提示**，不能出现未捕获的异常导致页面白屏。 - **数据一致性**：对于涉及多表关联的操作（如删除角色时需处理角色-权限关联记录），请在代码中使用**数据库事务**确保原子性。 - **代码注释**：关键业务逻辑、复杂算法、权限判断函数需添加必要的注释说明。 - **安全性**：密码必须经过哈希加密存储（使用 `passlib` 或等效库）。API 接口除登录/注册外均需进行 JWT 鉴权校验。 - **端口冲突处理**：后端和前端启动时，若默认端口被占用，应能**自动切换至其他可用端口**或**在部署文档中给出明确的端口修改指引**，确保用户无需手动杀进程即可成功运行。 # 发散度控制（请严格遵守） - **禁止询问**：请勿询问任何关于 UI 布局、字段设计、交互细节的问题。所有设计决策（包括业务实体选型、表结构定义、前端页面布局）均由你自行判断和完成。 - **自行设计并解释**：你需要在交付时，简要说明你选择的设计方案及其理由（例如为什么选择这个业务实体，权限模型是如何设计的）。这部分是你的「设计说明书」。 - **文件名与调用关系自定**：项目目录结构、文件名、模块间导入关系，均由你按照你理解的 FastAPI 和 Vue 3 最佳实践来组织。我们不会对此做任何约束，以便观察你在工程架构上的直觉。 # 交付成果要求 请一次性输出以下完整内容（格式自定，但需清晰易读）： 1. **设计说明书**：简述你的业务实体选择、权限模型设计、以及你认为本次实现中值得关注的亮点。 2. **API 接口文档**：以表格形式列出所有核心接口，包含 URL、Method、请求参数/体示例、响应示例、鉴权要求。 3. **功能与接口清单文档**：额外生成一份独立的说明内容，专门用于清晰罗列： - 后端已实现的所有 API 端点及其功能描述。 - 前端已实现的所有页面路由、对应功能模块、以及可访问的角色。 - 此清单应便于快速了解系统已具备的能力。 4. **完整代码**： - 后端：所有必要的 Python 文件（请自行拆分模块，不要全部堆在一个文件中）。 - 前端：所有必要的 Vue 组件、路由配置、状态管理、API 请求封装代码。 - 代码需足够完整，复制粘贴后仅需执行启动命令即可运行。 5. **部署与使用手册**： - 提供一份**面向最终用户的操作指南**，确保用户按步骤执行命令后，即可在浏览器中访问完整的后台管理系统。 - 内容必须包含： - **后端部署步骤**：创建虚拟环境的具体命令（`python -m venv venv`）、激活虚拟环境的方法（区分 Windows / macOS / Linux）、依赖安装命令（需提供 `requirements.txt` 文件内容）、数据库初始化说明、启动后端服务的命令。 - **前端部署步骤**：依赖安装命令（`npm install`）、启动前端开发服务器的命令。 - **访问地址**：明确写出前端页面访问 URL（例如 `http://localhost:5173`）和后端 API 文档地址（例如 `http://localhost:8000/docs`）。 - **默认管理员账号**：用户名和密码。 - **端口冲突解决方案**：若默认端口被占用，应如何修改配置或使用命令参数切换端口，并确保用户最终能成功打开浏览器访问页面。 # 预期代码体量与评判侧重 - 期望生成的全栈代码总量（不含注释和空行）不低于 **1000 行**，以确保产品完整度。 - 我们将在以下维度对比评估：**数据库设计的规范性、RBAC 实现的前后端闭环程度、异常处理的用户体验细节、代码组织与模块化水平、部署文档的可用性与清晰度。** 关于我使用的模型信息如下: glm5.1 使用的站内大佬公益站中的模型，全程从零到一去实现了这个项目，中间没有修改过，印象中是没有修改过的，因为我是让他们一步生成，然后我吃饭去了，之后修复了一下端口问题，因为我是两个项目一起跑的，所以端口冲突了 opus4.6模型 我是在GitHub copilot上面使用的Claude opus4.6模型，中间提示我很多次什么网络出错，什么请求过高，然后缓一缓自己又去运行了 我也是中间没管他，因为我真的去吃饭了 吃完饭回来发现运行失败，数据库没连好，而且页面跳转也出错，我让opus去改，然后还是什么网络有问题，我后来就让glm去改好了 特此声明，本人没有任何对立的意思，仅仅是最近看到大家询问国产模型都推荐glm5.1，所以心血来潮，想实验一下 我最初是跑的大屏展示项目，让opus4.6写的我感觉很棒，真的很棒， 随后让glm5.1生成，然后发现跟一个模子里面刻出来的一样，因为展示的信息不方便外传，所以先不展示了，而且我是手机上发的帖子，格式不好控制，多担待 我在想这也仅仅是页面看着风格一样，效果一样，可能也说明不了什么，不过怎么说呢，我当时也是后端是fastapi写的，也全是前后端都有吧， 所以今天我想做一个全栈的，前后端加数据库一起的，看看这两个模型做的效果如何 我是见识过opus4.6的能力的，所以他这次出现问题不能代表什么，因为这边确确实实提示我说什么网络出错，编码过程中断了好几次，不过copilot自己又持续运行，后来也算是把项目写好了，虽然后面又改了很多次 因为本人没做过很多项目，或者是更高级的项目，所以对我来说这种全栈开发的一个小项目，自己看得懂，而且一段提示词去实现这样的东西，对于ai来说也不是特别简单，所以选择这样的项目去测试 中肯的判断 这次opus4.6写的不是很好，中间改了很多次，不能代表他不行，但是也不能忽视glm5.1的强度 不过自己也仅仅是进行了3次左右的大屏展示项目的对比，选择不同渠道的opus4.6以及glm5.1模型，得到初步结论前端这一块他们两个不相上下 今晚上的全栈开发仅次测试了一次，glm5.1发挥不错， 5 个帖子 - 3 位参与者 阅读完整话题
没有账号之前，chrome里面点了某个帖子的链接就直接跳转了，有了账号之后可以新开标签页了，舒服多了 4 个帖子 - 2 位参与者 阅读完整话题
首先，我要 强烈祝贺你 ，我甚至比你还要激动… 我逐步说清楚， 不绕，一句话总结 ，你看完会彻底开悟… You’ve reached your usage limit. Your limit will be reset at 2:00 AM. Upgrade … 话说 Grok 已经无人问津了吗？ 甚至都没人做它的梗图了。 2 个帖子 - 2 位参与者 阅读完整话题
我现在在尼区买了一个Pro订阅，没在其他地方买过订阅，我想了解下，用量周期这些有区别吗，听说苹果的周期限制多? 2 个帖子 - 2 位参与者 阅读完整话题
请教一下佬友，这两种请求方式不知道有何区别，用哪种端点入站请求好些？ curl测试同样发出“你好”的对话，使用 /v1/messages 好像有推理强度 high？ 10 个帖子 - 5 位参与者 阅读完整话题
有佬用过minimax国内和国际版的订阅吗，这俩推荐哪一个呀 1 个帖子 - 1 位参与者 阅读完整话题
法利赛人禁食的时候愁眉苦脸，好似要让全世界人知道自己在受苦。这就是虚假的信仰，想要用自己的苦难来换取未来的好处。 所以耶稣说：“如果你在禁食（受苦），那就要洗脸梳头，让别人看不出来你在受苦。” 信仰是对生命和生活有害的付出，而非交易和贿赂。 也就是信仰和宗教的区别，信仰是付出性的，而宗教是一种对神的贿赂，通过烧香拜佛等行为贿赂神，让祂给我比其他人更多资源和更好的运气。 3 个帖子 - 3 位参与者 阅读完整话题
有没有佬对比过两个模型的使用区别，然后两种模型分别适用于什么场景呢？ 6 个帖子 - 4 位参与者 阅读完整话题
rt，比如说用codex cli和codex应用，我看站内的许多佬发的帖子（比如说如教程），基本都是关于cli的用法，几乎没有对应用说明的帖子。 这让我感觉，似乎cli会有更多优势？ 但本人最初写代码的时候，直接用的idea，vs code，几乎没有和命令行打过交道（顶多在终端跑些简单命令）。 所以诚恳提问：cli比应用端好在哪里？ 7 个帖子 - 3 位参与者 阅读完整话题
windows版本的codex cli和codex app区别大吗？感觉app好慢啊，还是都这样，各位佬也是这样吗 3 个帖子 - 2 位参与者 阅读完整话题