简直就是在反向升级，我看很多都是别人pull进来的，希望作者不要用别人的pull request了，自己慢慢干，不必要优化没用的功能，都是不经过严谨验证的ai代码随便pull，害人屎山代码。0.2.16版本无法通过验证，0.2.17版本一直掉登录，退回15版本最稳。 8 个帖子 - 7 位参与者 阅读完整话题
话说各位佬目前 PD 虚拟机都用的是什么渠道的？ 破解？ 咸鱼？ 目前市面上有很多的破解版本。 闲鱼上好多卖的也是破解版的，想着还是用破解版的吧。 但是不知道有没有什么问题，有些站点感觉还是不太敢用。 找了一个社区推荐的版本，比较新（26.3.1），传到 VT 上，是全绿的。 想问问各位佬有没有什么建议。或者靠谱点的安装包，或者其他渠道。 2 个帖子 - 2 位参与者 阅读完整话题
没忍住这两天买了 mac mini，看到网上有很多卖 mac mini 扩展坞底座的产品，各位佬们觉得有必要买吗？ 欢迎佬们分享下使用/不使用扩展坞的场景，如果推荐的话希望能分享下在用的品牌~ 5 个帖子 - 5 位参与者 阅读完整话题
现在好像都没有很多的token了，公益站好像也没有gpt了，就算有的余额也卡的有些厉害，大家是都转官方了吗？还是说还有别的渠道？ 作为一个个人开发者太难了，两个月前的一个项目还没写完…… 6 个帖子 - 5 位参与者 阅读完整话题
大佬们你们觉得可以吗 我打算买几个摄像头然后接入AI 每隔1小时总结分析一次 这样就是一个健康小伙伴了 10 个帖子 - 8 位参与者 阅读完整话题
我有1个美区的48个月 有1个英区的48个月。实测美区用量比英区至少高30%，看了很多帖子说英区少的 也有说差不多的。 我很好奇用量的算法，本质上是走反代获取的比如gpt 5.5，那我们平时web端对话也会消耗额度对吧？ 那现在大家对账不一致 有没有可能是大家在网页用量上不一样？ 我不了解这个用量的算法 所以问一下大家。如果是我上述的算法的话，那pro拼车，他们转web权限，岂不是也会影响到反代出来的“codex”的用量？ 另一个角度，如果网页版和反代出来的是分开计算的，完全不受影响的，那各个地区的team差异化也太大了 （pro plus用量是否也跟地区有关） 5 个帖子 - 4 位参与者 阅读完整话题
今天很多号挂了，我们一直在找号找渠道，所以白天公益站不可用了一段时间 Codex公益站： https://new.sharedchat.cc/ RawChat付费站： https://rawchat.cn/ 声明：在资源紧张的时候我们还是会优先保障付费站的，希望各位佬友理解 新规则修改：部分仅跨站注册的用户可以到公益站使用了 qq群：758607042（有问题群内反馈回复会快点，群内有技术支持） 13 个帖子 - 13 位参与者 阅读完整话题
如题，第一次在L站过生日，来到L站的这几个月里跟着佬友们学到了很多有用的东西，愿佬友们天天开心，社区越来越好 53 个帖子 - 52 位参与者 阅读完整话题
现在微信公众号出现了很多图文并茂的知识类文章，应该是用AI生成的，非常不错。 但有问题请教下，有些是一页纸的，我觉得还能理解，用某个大模型LLM的图像功能生成。 但有些很不错的文章，显示了好几张风格一致的图片，这些一般是用怎么生成的？ 谢谢。 5 个帖子 - 4 位参与者 阅读完整话题
Claude Fable 5 发布前后，感觉使用codex写代码更舒畅了，一些问题思考的也有深度，不知道是新模型还是提高参数了 1 个帖子 - 1 位参与者 阅读完整话题
工作的时候最怕手搓ppt了,最近看很多人都在用ai做ppt,佬们有什么好的思路吗,还是有什么好用的skills可以分享一下 1 个帖子 - 1 位参与者 阅读完整话题
很多人第一次接触 AI 编程助手时，都会把它当成“高级搜索引擎”或者“代码生成器”。但真正用下来之后我发现，Codex 最有价值的地方，并不是帮你凭空写一段代码，而是帮你在复杂项目里更快理解上下文、更稳地定位问题、更安全地完成修改。 这篇文章不讲具体项目业务，只分享我在维护项目过程中总结出来的一些实战经验。对刚开始使用 Codex 的同学来说，这些方法能少走很多弯路。 一、先让 Codex 读规则，而不是马上写代码 刚开始用 Codex 时，我很容易犯一个错误：问题一抛过去，就希望它马上给方案、改代码、跑测试。 后来发现，真正高效的方式是先告诉它项目规则。 比如： 项目有哪些子模块 每个模块用什么技术栈 构建命令是什么 哪些目录能改，哪些不能乱动 当前项目有哪些约定 测试、构建、发布分别怎么跑 有哪些历史遗留问题需要避开 这类信息最好写成类似 AGENTS.md 的说明文件。这样 Codex 进入项目后，第一件事不是“猜”，而是“按项目手册工作”。 我的经验是： 越复杂的项目，越不能让 AI 靠猜。你给它越清晰的操作边界，它越像一个靠谱的协作者。 二、让 Codex 先理解现状，再动手修改 很多时候，我们觉得自己只是要改一个小问题，但真实项目里，一个小改动可能牵连配置、接口、构建脚本、前端页面、后端服务、移动端兼容等多个地方。 所以我现在会习惯性要求 Codex： 先查相关代码 找调用链 看现有实现风格 判断影响范围 再决定怎么改 尤其是在维护老项目时，这一点非常重要。 不要直接说： 帮我把这个功能改成 xxx。 更好的说法是： 先帮我看看这个功能现在是怎么实现的，涉及哪些文件和调用链，然后再给出修改方案。 这样 Codex 不会一上来就“自信开写”，而是会先进入侦察模式。等它把上下文摸清楚之后，再进入修改模式，成功率会高很多。 三、善用 CodeGraph，别让 Codex 大海捞针 维护大型项目时，单纯全文搜索经常不够用。一个类、一个函数、一个接口，可能散落在很多模块里。 这时候 CodeGraph 这种代码索引工具非常有用。它能帮 Codex 快速知道： 某个方法在哪里定义 谁调用了它 它又调用了谁 改它会影响哪些地方 某个功能大概分布在哪些文件中 我的体感是，CodeGraph 相当于给 Codex 装了一张“项目地图”。 没有地图时，它需要在代码森林里乱翻。 有地图后，它可以直接走到关键区域。 所以维护项目时，我会优先让 Codex 用代码图谱定位，再做具体阅读和修改。这样不仅快，而且不容易漏掉关键调用点。 四、把构建命令固定下来，别每次临时发挥 项目一复杂，环境问题就会变成噩梦。 比如： 后端需要某个 Java 版本 另一个服务需要另一个 Java 版本 前端要固定 Node 版本 Android、iOS、脚本服务又各有自己的工具链 有些模块用 Maven，有些用 Gradle，有些用 npm/yarn 如果每次都让 Codex 自己猜命令，很容易出现“代码没问题，环境跑崩”的情况。 我的做法是把常用命令整理成脚本： build-backend.sh build-web.sh build-android.sh build-ios.sh check-all.sh status-all.sh 然后告诉 Codex： 不要自己拼命令，优先使用项目提供的脚本。 这点非常关键。 因为脚本里可以固定 JDK、Node、Maven、SDK、环境变量、registry 等细节。Codex 只需要执行标准入口，不需要重新理解整个环境。 结论就是一句话： 把复杂环境封装成脚本，把脚本交给 Codex 调用。 五、每次改代码前，先看工作区状态 多人协作或者长时间维护项目时，工作区里可能已经有别人改过的文件，或者有自己之前没提交的临时改动。 如果不先看状态，Codex 可能误改、覆盖、格式化不该动的文件。 所以我会让 Codex 在动手前先跑状态检查，确认： 当前有哪些文件被修改 哪些改动可能是我已有的 这次任务真正应该碰哪些文件 有没有需要避开的脏文件 这其实是一个非常工程化的习惯。 AI 写代码的能力很强，但它不知道哪些改动是“历史现场”。 你必须让它尊重现场。 我现在的原则是： 只改和任务相关的文件，不顺手重构，不清理无关改动，不替用户做危险操作。 这能避免很多不必要的事故。 六、把 Codex 当初级同事用，会翻车；当资深搭档用，才好用 很多人用 AI 的方式是命令式的： 写一个 xxx。 修一下 xxx。 加一个 xxx。 这种方式适合小脚本，但不适合真实项目。 在真实维护工作中，我更推荐把 Codex 当成一个资深搭档，而不是一个代码打字员。 你可以这样用它： “先帮我分析这个问题可能出现在哪一层。” “这个改法会不会影响已有逻辑？” “有没有更贴合当前代码风格的实现方式？” “帮我找一下类似功能是怎么写的。” “这个地方有没有隐藏的兼容性风险？” “改完之后应该跑哪些最小验证？” 你会发现，当问题问得更工程化，Codex 的回答也会更工程化。 AI 不是只能写代码，它还可以帮你做： 代码考古 风险评估 调用链分析 方案对比 测试补充 构建验证 文档整理 真正的效率提升，来自这些环节串起来。 七、不要追求“一次生成完美代码” 我现在越来越不指望 Codex 一次性生成完美答案。 更高效的节奏是： 让它先定位问题 让它提出最小修改方案 修改后跑测试或构建 根据错误继续收敛 最后总结改动和风险 这和真实开发流程很像。 AI 辅助开发不是“许愿机模式”，而是“快速迭代模式”。 尤其是复杂项目，第一次方案可能只对了一半，这很正常。关键是 Codex 能根据编译错误、测试失败、日志输出继续修正。它不会累，也不会嫌麻烦，这一点非常适合处理维护类工作。 八、让 Codex 跑验证，而不是只相信代码看起来对 只改代码不验证，是非常危险的。 我会尽量让 Codex 在修改后做对应检查： 后端改动跑后端构建 前端改动跑前端构建 移动端改动跑对应编译 脚本改动跑语法检查或单元测试 公共逻辑改动尽量跑更大范围验证 如果构建太重，也至少跑最相关的局部检查。 这一步的价值很高。因为 Codex 不只是“写完了”，而是可以帮你把“能不能过”这件事也确认掉。 我最喜欢的一种用法是： 改完后帮我运行最小必要验证，如果失败，继续根据错误修。 这样整个闭环就完整了。 九、明确告诉 Codex：不要过度发挥 AI 很容易“顺手优化”。 比如你只是让它修一个 bug，它可能顺便： 改了格式 重构了结构 换了写法 调整了命名 改了无关文件 加了不必要的抽象 这些在新项目里可能无所谓，但在维护项目时很危险。 所以我会明确给它约束： 保持改动最小 遵循现有风格 不做无关重构 不碰无关文件 不覆盖已有改动 不引入新的依赖，除非确实必要 修改公共逻辑前先分析影响范围 维护项目最怕“看起来更优雅，实际上风险更大”。 Codex 很强，但你要给它刹车系统。 十、让 Codex 最后交付一份清晰总结 一次好的 AI 协作，不应该只留下代码改动，还应该留下清楚的交代。 我通常希望 Codex 最后说明： 改了哪些文件 解决了什么问题 核心逻辑怎么变了 跑了哪些验证 有没有未验证的风险 后续还可以做什么 这份总结对自己回顾、写 commit message、发 PR、同步团队都很有帮助。 尤其是当你一天内处理很多小问题时，Codex 的总结能帮你快速恢复上下文。 我的 Codex 使用心法 总结下来，我觉得 Codex 辅助维护项目的核心不是“让 AI 多写代码”，而是“让 AI 更好地参与工程流程”。 我的使用心法大概是这几条： 先给规则，再给任务。 先理解上下文，再修改代码。 优先使用项目已有脚本和工具。 改动越小越好，验证越明确越好。 尊重已有工作区，不覆盖别人的现场。 把 Codex 当协作者，而不是代码生成器。 复杂问题分阶段推进，不追求一步到位。 每次交付都要有总结、有验证、有风险说明。 结语 小白使用 Codex，最开始可能会觉得它只是“帮我写代码的工具”。 但真正用进项目维护流程之后，你会发现它更像一个随时在线的工程搭档：能帮你读代码、查调用链、分析风险、执行构建、修复错误、整理结论。 它不能替代你的判断，但能显著放大你的判断。 它不能保证每次都对，但能让你更快接近正确答案。 所谓“小白成神”，并不是因为 AI 让人突然无所不能，而是因为它把很多原本需要大量经验积累的工程动作，变成了可以被学习、复用和自动化的流程。 会提问、会约束、会验证、会迭代。 这才是用好 Codex 的真正干货。 3 个帖子 - 2 位参与者 阅读完整话题
Trae国内版很多国产大模型免费用，但是排队太久；看了升级权益不是很贵，值得买吗？ 国际版有很多大模型没有了，但是这个价格也不美丽。 3 个帖子 - 2 位参与者 阅读完整话题
有些安卓手机或者鸿蒙手机没有 Google Play 商店，很多国外软件就没法直接安装。遇到这种情况，可以用 APK 镜像站来下载软件安装包，（比如： https://www.apkmirror.com ）。打开 APKMirror，搜索要安装的软件找到对应版本后下载即可 如果下载的是普通 .apk 文件，直接打开安装就行。如果下载的是 .apkm、.xapk 这类文件，就需要先安装 APKMirror 自家的安装器。如果手机提示“不允许安装未知来源应用”，断网后再安装即可 1 个帖子 - 1 位参与者 阅读完整话题
各位佬推荐哪个好点，本来打算直接买PS的，但是最近看了很多地平线6的视频，也想玩玩地平线6，地平线6目前没上PS，有人说后续会上，不知道到底上不上，所以比较纠结买哪个。 6 个帖子 - 5 位参与者 阅读完整话题
有很多请求提示TPM，都是0输入0返回，是不是负载太高了。模型监控也异常了 1 个帖子 - 1 位参与者 阅读完整话题
佬们是吗 尝试了很多个 都不能用了我反正是一个都不能使用了 8 个帖子 - 7 位参与者 阅读完整话题
这几天用完很多站的 Opus 转回 官方 Opus4.7 和 4.8 会出现 API Error: 400 messages.1.content.0.thinking: each thinking block must contain thinking 这是其他模型不兼容的现像 我刚才 官方Opus 5小时满了，先接一下 其他来源的 好几家都出这句 是明显掺假了，因为无论是哪裏反代出来的，只要是claude 模型，我都没看过会出现这句的 1 个帖子 - 1 位参与者 阅读完整话题
不抛弃 不放弃 继续！ 4 个帖子 - 4 位参与者 阅读完整话题
主流的"测试" vs 我的"6 阶段" 很多团队的测试流程是 3 段式: UT → 集成 → 上线 每阶段都做"测试"——只是测试对象不同。 我的判断不一样: ▌ 测试不是"测一遍"—— ▌ 是按 6 个阶段性质拆分, ▌ 每阶段有"该阶段独有、其他阶段无法替代"的验证内容。 不是 6 次相同动作 —— 是 6 类不同性质的验证 。 6 阶段是什么 ┌──────────────────────────────────────────────────────────┐ │ │ │ ① 单元测试 ── 验证"函数内部" │ │ ↓ │ │ ② 集成测试 ── 验证"跨网络" │ │ ↓ ← 比对工具进场 │ │ ③ Code Review ─ 验证"设计 + 性能" │ │ ↓ │ │ ④ 他测 ────── 验证"用户视角" │ │ ↓ ← 比对工具回访 │ │ ⑤ 灰度 ────── 验证"生产数据兼容" │ │ ↓ ← 比对工具在线 │ │ ⑥ 上线观察 ── 验证"业务大盘波动" │ │ │ └──────────────────────────────────────────────────────────┘ 每阶段独有验证内容: 阶段 性质 独有验证 ① 单元 函数内部 UT 覆盖率 + 冒烟 + 功能埋点 ② 集成 跨网络 跨服务冒烟 + DML 比对 ③ Review 设计性能 设计审查 + 性能分析 + 回滚方案 ④ 他测 用户视角 提测文档 + Test Case + 修复后再比对 ⑤ 灰度 生产数据 时间窗口 + 分工 + DML 在线比对 ⑥ 上线 业务大盘 6 项指标 + 四方确认 → 第 ②④⑤ 阶段的"比对"动作,就是上一篇讲的"比对工具体系"。 → 第 ⑥ 阶段是大多数团队最常省的——本文重点讲它。 阶段拆分的核心标准 我自己的判断标准很简单: 两个阶段如果验证内容重叠 —— 说明阶段拆分错了。 举个例子:很多团队把"集成测试"和"他测"混在一起做—— 都让测试同事跑一遍。 但这两个阶段性质完全不同: 集成测试是 "跨网络"性质 —— 关心服务调用、数据穿透是否对 他测是 "用户视角"性质 —— 关心 case 覆盖、修复后再验证是否对 合在一起做的代价: 集成阶段没暴露的跨服务 bug,会被他测的"用户场景"掩盖 —— 等到灰度才发现,代价是集成阶段的 N 倍。 第 6 阶段最贵 —— 也最被忽视 很多团队的"上线观察"=刷一下监控大盘。 我的版本: 6 项指标 + 四方确认 。 6 项观测指标: 1. 产品功能有没有执行 2. 数据有没有问题 3. 系统有没有性能问题 4. 跨系统交互有没有影响 5. 财务大盘是否波动 ← 关键! 6. 业务大盘是否波动 ← 关键! ▌ 把"财务大盘 / 业务大盘波动" ▌ 作为发布观察指标 —— ▌ 这是大多数团队最常省的一步。 因为这两项指标"看起来不归技术管"。 但实际上 —— 80% 的"上线后才发现"的事故,在前 4 项指标 里全是绿的,只有第 5 、6 项暴露异常 。 例子: 某次上线某个改动,前 4 项指标全绿; 3 天后才发现财务对账差异—— 这种 bug 在 UT/集成/灰度 都看不出来 ,只有"业务大盘"能看见。 四方确认 —— 不是签字流程 四方确认 = 开发 / 测试 / 技术 TO / 产品 都同意才能"上线观察通过"。 听起来像 PPT 流程,但 反共识在于 : ▌ 测试同意 ≠ 验收通过 —— ▌ 业务大盘没波动,不代表产品认为"功能符合预期"。 ▌ 产品同意 ≠ 验收通过 —— ▌ 数据正常,不代表开发认为"性能达标"。 四方共同确认—— 任何一方说"我看到的不对"——就回退 。 我经历的项目里,真发生过 "3 方都过了,产品最后说不对" 的情况。如果没有四方流程,这个回退根本走不动。 反共识在哪 主流:测试 = UT + 集成 + 上线(3 阶段) 我的版本:6 阶段,每阶段独有验证 主流:每阶段都做"测试"动作 我的版本:每阶段对应 该阶段性质独有 的验证手段 主流:上线观察看"是否有大故障" 我的版本: 6 项观测指标 + 四方确认 主流:业务大盘归运营管 我的版本: 把"财务大盘 / 业务大盘"作为发布观察指标 主流:验收 = 测试通过 我的版本: 四方确认 (开发 / 测试 / 技术 TO / 产品) 什么时候不该用这套 也踩过坑。 某次内部小工具改动,代码量不到 200 行。 我也想搞 6 阶段——leader 直接说:"过度。" 事后是对的。 我的判断: 核心业务系统改造 → 必上(尤其涉及财务 / 业务大盘) 跨多研发角色的项目 → 必上(否则四方确认走不通) 内部工具 / 后台脚本 → 别上(单人项目,4 阶段够) DDL 类无法灰度的改动 → 跳过第 5 阶段(灰度),其余照走 不影响 KPI 的小项目 → 简化为 3 阶段(UT+集成+上线) 阴面 · 这套也有副作用 我自己用了这套 4 年,踩过的坑: 重型流程 —— 小项目用不上,6 阶段成本太高 跨公司不通用 —— 没有"四方确认 / 业务大盘"概念的公司套不进来 可能流于形式 —— 团队成员把 6 阶段当 6 个 checkbox 而非 6 类性质 决策慢 —— 至少 6 次评审 / 检查 最后一条最关键 —— **6 阶段的代价是"决策周期变长"**。 所以才有上面那句:"小项目别上 / 不影响 KPI 的项目简化为 3 阶段"。 写在最后 把测试拆 6 阶段,不是为了"显得专业"—— 是因为我经历过太多次: "你那阶段不是测过吗?怎么还出问题?" 仔细看,会发现: 那阶段测的不是这一类问题 。 每阶段性质不同 —— 验证手段就该不同。 6 阶段是"性质拆分",不是"动作拆分"。 跟"渐进式改造"和"比对工具"一样,这是一套 关心可逆性、关心 追溯性 的工程纪律。 写到这,我也不太确定 6 阶段对所有团队都成立。 我经历的项目都是"核心业务系统 + 跨多角色 + 业务大盘敏感"—— 这种场景 6 阶段几乎是必修。 但创业团队 / 内部工具 / 没有"业务大盘"这个概念的公司—— 搞这套可能反而是负担。 这点我自己也还在想。 下一篇打算写 17 类业务迁移分类—— 跟 6 阶段是一对:6 阶段是 纵向 (时间),17 类是 横向 (业务域)。 两者合起来才是完整的迁移管理体系。 (以上 SOP 都做了脱敏。 如果你做过核心系统改造,欢迎评论区聊聊你们的验收流程长什么样, 特别想听 6 阶段简化为 3 阶段后,踩过的坑 。)