去年3月份接房就开始每天接10多20个电话，有时候感觉知道是推销电话但是又担心错过真正的电话 我们是三期，这四期月底要接房了，又开始被轰炸了，真的被烦扰，被这售楼部卖几次了，放过我吧 佬们有解决办法吗 1 个帖子 - 1 位参与者 阅读完整话题
一个劲429，疯狂星期六也是到了尾声了 真是一天美味的Token啊，我想我一辈子都不会忘记你吧 1 个帖子 - 1 位参与者 阅读完整话题
君佬的节点现在太不稳定了，一会429 503 的还有流处理失败。 你们放过君佬吧，让我狠狠的登 3 个帖子 - 2 位参与者 阅读完整话题
CPA 代理 Codex 卡在"正在思考"的排查与 WebSocket 解决方案 使用 CPA 代理 Codex / Codex CLI / Codex Desktop 时，可能会遇到这些现象： 卡在"正在思考"，长时间没有输出。 请求反复失败，偶发超时。 CPA 代理下 HTTPS / SSE 转发不稳定。 codex doctor 显示 WebSocket 失败，随后 fallback 到 HTTPS。 这类问题不一定和出口 IP 区域有关，更常见的关键点是 Codex 到 CPA、CPA 到 OpenAI 这两段是否真的走了 WebSocket。本文整理完整配置方式，以及如何确认链路是否已经变成全程 WebSocket。 目标链路 理想的全程 WebSocket 链路是： Codex ---ws---> CPA ---wss---> OpenAI / ChatGPT Codex backend 也就是： Codex -> ws://localhost:8317/v1/responses CPA -> wss://chatgpt.com/backend-api/codex/responses 注意，这里有两段链路： Codex -> CPA ：由 Codex provider 配置决定。 CPA -> OpenAI ：由 CPA 当前选中的 Codex OAuth auth 文件决定。 只配置其中一段，可能只能得到半程 WebSocket。 解决方案：开启全程 WebSocket 目标是让 Codex 到 CPA 使用 WebSocket，同时 CPA 到 OpenAI 也使用 WSS。 1. 修改 Codex 配置 编辑 Codex 配置文件： ~/.codex/config.toml 找到 CPA 对应的 provider，例如： [model_providers.cliproxyapi] base_url = "http://localhost:8317/v1" 在这个 provider 下添加： supports_websockets = true 完整示例： [model_providers.cliproxyapi] name = "cliproxyapi" base_url = "http://localhost:8317/v1" wire_api = "responses" supports_websockets = true 这个配置必须放在 [model_providers.cliproxyapi] 下面，不要放到 [features] 下面。 2. 不要乱配 feature flag 不要盲目在 [features] 下添加： responses_websockets_v2 = true 部分 Codex 版本中相关 feature flag 已经被移除或默认内置。可以用下面命令确认： macOS: /Applications/Codex.app/Contents/Resources/codex debug features Windows 示例： codex debug features 如果输出里显示类似： responses_websockets: removed responses_websockets_v2: removed 说明这个开关已经不再需要，也不应该再配。关键配置是 provider 里的 supports_websockets = true 。 3. 修改 CPA 的 Codex auth 文件 只改 Codex 配置，通常只能保证： Codex ---ws---> CPA 要实现： CPA ---wss---> OpenAI 还需要让 CPA 当前使用的 Codex OAuth auth 开启 WebSocket。 CPA 的 Codex OAuth auth 文件一般在： macOS 常见位置： ~/.cli-proxy-api/ Windows 运行包常见位置示例： <CPA_RUNTIME_DIR>\auth\ 文件名通常类似： [email protected] [email protected] 编辑 CPA 实际选中的 Codex auth 文件，在 JSON 顶层添加： "websockets": true 示例结构： { "websockets": true, "access_token": "...", "account_id": "...", "email": "...", "refresh_token": "...", "type": "codex" } 注意： websockets 是 JSON 顶层字段。 不要放进 metadata 、 attributes 或其他嵌套对象里。 如果有多个 Codex auth 文件，要改 CPA 实际选中的那个。 CPA 日志中的 Use OAuth provider=codex auth_file=... 会显示当前使用的是哪个 auth 文件。 验证步骤 1. 用 Codex doctor 验证 Codex 到 CPA macOS: /Applications/Codex.app/Contents/Resources/codex doctor Windows / PATH 已配置时： codex doctor 成功时应看到类似： websocket connected (HTTP 101 Switching Protocols) supports websockets true endpoint ws://localhost:8317/v1/... 这说明： Codex ---ws---> CPA 已经成立。 2. 用 CPA Manager 监控辅助判断 CPA Manager 的监控列表也可以作为一个直观信号。开启 WebSocket 后，监控里对应模型的请求方法通常会显示为： GET /v1/responses 这和普通 HTTP/SSE 请求不一样。之前走 HTTP/SSE fallback 时，请求通常是： POST /v1/responses Accept: text/event-stream 原因是 WebSocket 握手本身是 HTTP GET + Upgrade: websocket ，成功后才升级成 WebSocket 连接。所以在 CPA Manager 里看到连续成功的 GET /v1/responses ，基本可以说明 Codex -> CPA 这一段已经在走 WebSocket 路由。 不过它只能证明下游请求进入了 CPA 的 WebSocket handler。要确认 CPA -> OpenAI 也变成 WSS，还需要继续看 main.log 里是否有 codex websockets: upstream connected ... url=wss://... 。 3. 打开 CPA 日志验证 CPA 到 OpenAI 这一步不是长期必需，只建议临时打开用于验证。编辑 CPA 配置文件。 macOS Homebrew 常见位置： /opt/homebrew/etc/cliproxyapi.conf Windows 运行包示例： <CPA_RUNTIME_DIR>\config.yaml 临时打开： debug: true request-log: true logging-to-file: true 然后重启 CPA。 日志文件常见位置： macOS: ~/.cli-proxy-api/logs/main.log Windows 运行包示例： <CPA_RUNTIME_DIR>\auth\logs\main.log 用 rg 检索关键日志： macOS: rg -n "codex websockets|upstream connected|wss://|responses websocket|Use OAuth" ~/.cli-proxy-api/logs/main.log Windows: rg -n "codex websockets|upstream connected|wss://|responses websocket|Use OAuth" <CPA_RUNTIME_DIR>\auth\logs\main.log 成功时会看到类似： responses websocket: client connected ... remote=127.0.0.1 Use OAuth provider=codex [email protected] ... codex websockets: upstream connected ... url=wss://chatgpt.com/backend-api/codex/responses 这就说明链路已经是： Codex ---ws---> CPA ---wss---> OpenAI 验证完成后，建议把 CPA 日志开关关回去： debug: false request-log: false logging-to-file: false 然后再次重启 CPA。 原因是 request-log: true 可能记录完整请求 payload，包括对话内容、工具调用参数等，长期打开会增加磁盘占用和敏感信息落盘风险。 常见误区 误区 1：把 supports_websockets 放错位置 错误写法： [features] supports_websockets = true 正确写法： [model_providers.cliproxyapi] supports_websockets = true supports_websockets 是 provider 能力配置，不是 feature flag。 误区 2：只开了 Codex 到 CPA 如果 CPA 日志里只有： responses websocket: client connected 但没有： codex websockets: upstream connected ... url=wss://... 说明大概率只是： Codex ---ws---> CPA 还没有实现： CPA ---wss---> OpenAI 这时继续检查 CPA 当前选中的 Codex auth 文件是否有： "websockets": true 误区 3：被本机代理环境变量干扰 有时环境里设置了： HTTP_PROXY HTTPS_PROXY http_proxy https_proxy 但 NO_PROXY 没包含本地地址，导致 ws://127.0.0.1:8317 也被拿去走外部代理。 典型报错可能是： HTTP CONNECT failed with status 504 Proxy URL scheme not supported 临时验证时可以设置： macOS / Linux: NO_PROXY=127.0.0.1,localhost no_proxy=127.0.0.1,localhost codex doctor Windows PowerShell: $env:NO_PROXY = "127.0.0.1,localhost" $env:no_proxy = "127.0.0.1,localhost" codex doctor 如果这样就恢复 HTTP 101 Switching Protocols ，说明本地代理绕过规则需要补齐。 误区 4：cc-switch 端口能监听但不支持 WebSocket 路由 有些情况下 Codex provider 指向了 cc-switch.exe 暴露的端口，例如： ws://127.0.0.1:15721/v1/... codex doctor 可能显示： supports websockets true Responses WebSocket failed HTTP 405 Method Not Allowed 这说明： Codex 端已经尝试 WebSocket。 配置也认为 provider 支持 WebSocket。 但本地 cc-switch / COA 的 /v1/... WebSocket 路由没有正确接住。 实际请求会 fallback 到 HTTPS/SSE，仍可能卡在"正在思考"。 实践建议：如果你的目标只是让 Codex 通过 CPA 访问上游，并且 CPA 已经能提供 http://127.0.0.1:8317/v1 这类 OpenAI-compatible provider，那么可以先关掉 cc-switch ，让 Codex 直接指向 CPA。这样链路更短，排查也更清楚。除非你明确依赖 cc-switch 做模型切换或其他额外能力，否则它在这条 WebSocket 修复链路里通常不是必需层。 排查方向： 确认 Codex provider 是否应该指向 CPA，而不是 cc-switch 临时端口。 确认 base_url 是否为 CPA 端口，例如 http://127.0.0.1:8317/v1 。 用 Get-NetTCPConnection / lsof 查监听进程，确认端口背后到底是谁。 如果必须经过 cc-switch，确认该版本是否支持 Codex Responses WebSocket 路由。 Windows 查看监听进程示例： Get-NetTCPConnection -LocalPort 8317 | Select-Object LocalAddress,LocalPort,State,OwningProcess Get-CimInstance Win32_Process | Where-Object { $_.ProcessId -eq <PID> } | Select-Object ProcessId,Name,CommandLine macOS 查看监听进程示例： lsof -nP -iTCP:8317 -sTCP:LISTEN Windows 实测参考 以下是一组 Windows 上验证成功的关键点，路径仅作示例： Codex 配置： [model_providers.cliproxyapi] name = "cliproxyapi" base_url = "http://127.0.0.1:8317/v1" supports_websockets = true wire_api = "responses" CPA 进程： <CPA_RUNTIME_DIR>\cli-proxy-api.exe CPA 配置： <CPA_RUNTIME_DIR>\config.yaml CPA auth 目录： <CPA_RUNTIME_DIR>\auth\ CPA 日志： <CPA_RUNTIME_DIR>\auth\logs\main.log 成功日志关键行： responses websocket: client connected ... remote=127.0.0.1 Use OAuth provider=codex auth_file=codex-...-plus.json for model gpt-5.5 codex websockets: upstream connected ... url=wss://chatgpt.com/backend-api/codex/responses 成功后 codex doctor 关键行： websocket connected (HTTP 101 Switching Protocols) supports websockets true endpoint ws://127.0.0.1:8317/v1/<redacted> 快速判断表 现象 含义 下一步 websocket connected (HTTP 101) Codex 到 CPA 已经是 WS 继续看 CPA 日志确认上游 WSS CPA Manager 显示 GET /v1/responses 下游大概率已走 WS upgrade 路由 继续看 main.log 确认上游 WSS responses websocket: client connected CPA 收到了下游 WS 继续找 upstream connected codex websockets: upstream connected ... wss://... CPA 到 OpenAI 已经是 WSS 全程 WebSocket 成功 HTTP 405 Method Not Allowed 本地服务没接住 WS 路由 检查端口背后是不是 cc-switch/旧 COA HTTP CONNECT failed 504 本地 WS 被错误送去代理 设置 NO_PROXY=127.0.0.1,localhost POST /v1/responses + Accept: text/event-stream 可能仍在 HTTP/SSE fallback 检查 Codex provider 与 CPA auth 最终检查清单 Codex provider 下有 supports_websockets = true 。 Codex provider 的 base_url 指向 CPA，而不是不支持 WS 的中间服务。 CPA 当前使用的 Codex auth JSON 顶层有 "websockets": true 。 codex doctor 显示 HTTP 101 Switching Protocols 。 CPA main.log 显示 responses websocket: client connected 。 CPA main.log 显示 codex websockets: upstream connected ... url=wss://chatgpt.com/backend-api/codex/responses 。 验证完成后关闭 debug 、 request-log 、 logging-to-file 。 4 个帖子 - 4 位参与者 阅读完整话题
求求了，放过ai吧，这个点肯定还有人在卷，我常常责怪自己，当初不应该，没把你留下来~好吧，其实我是刷剧刷到现在了，哈哈哈，才不是卷 13 个帖子 - 12 位参与者 阅读完整话题
看来中转的价格该涨价了，节假日结束，风控部门上班了。 6 个帖子 - 6 位参与者 阅读完整话题
他们老板说 这种白嫖机会不可以放过 号召他们员工用一天的时间啥也不干，就注册账号，疯狂发申请函 然后疯狂白嫖 他们公司的 HR 行政什么之类都被抓起来注册账号了 然后把获得的 API 再给程序员使用 就这百万亿词元 估计会被这帮公司最后薅走 90万 亿 他们堪称人形注册机 （到底是千万亿还是百万亿 我忘记了，反正大概就是这个意思，最后 90% 都会被各种小公司注册走） 3 个帖子 - 3 位参与者 阅读完整话题
从“AI-First”到“不强迫使用AI”，从市值250亿美元到40亿美元，多邻国只用了一年的时间。这只让全球用户既爱又恨的“邪恶”小绿鸟到底经历了什么？ 2026年4月，路易斯·冯·安（Luis von Ahn）在播客中表示，Duolingo已不再将员工使用AI的情况纳入绩效考核。他说，绩效最重要的是“把本职工作尽可能做好”；很多时候AI能帮上忙，但如果帮不上，“我不会强迫你去用它”。 这家公司曾是全球最激进的企业之一——2025年4月，路易斯在一封致全员的公开邮件中宣布公司转向“AI-First”，并要求只有证明“AI做不了”时，人力岗位才有存在的必要。 从“强制使用”到“想用就用”，这家曾被视作“All in AI”最激进标杆的语言学习巨头，在短短一年内完成了一次策略回摆。 为什么最早、最猛推行AI的公司，反而最先撤回了这项制度？ 顶级生意遇见永不疲倦的AI 这只绿色的猫头鹰可能是史上对人类态度最差的鸟了。不仅一言不合就“变脸”，还时常威胁它的5000万日活用户：“最后通牒！你的连胜要断了！” 就这样，多邻国用类似闯关游戏的机制，把学习这件枯燥的事情变成让人上瘾的日常打卡，一路高歌猛进，成为资本市场眼中的“标准优等生”——增长快、盈利好、用户黏性强。 AI浪潮来临的时候，在一众C端互联网应用中，多邻国绝对算是出手快的。 2023年3月，多邻国与OpenAI合作推出AI学习功能，正式发布Duolingo Max，随后，多邻国在次年迈入了“吃到AI红利”的第一阶段。 2024年年初，公司裁撤了约10%的合同工，并明确表示正在更多依赖AI来生成内容。 很快，多邻国也确实在生产效率上发挥了AI的“魔力”，借助AI，多邻国2024年上线了超过7500个全新的内容单元，而在AI尚未大规模应用的2021年，这个数字仅为425个。内容生产的效率被拉升到了过去难以想象的高度。 财务数据为多邻国的AI战略提供了最有力的背书。2024财年，多邻国总预订额达8.7亿美元，同比增长40%；付费订阅用户数达到950万，同比增长43%。 在致股东的年度信函中，管理层将2024年定义为“破纪录的一年”。此时的资本市场，看到一个清晰而性感的故事，AI似乎真的成为了多邻国新的增长引擎。 尝到甜头的多邻国，在2025年将油门一脚踩到底，进入了激进的“AI-First（AI优先）”元年。2025年4月，路易斯宣布公司转向“AI-First”，随之而来的是一套硬核的“连招”：逐步停止让承包商做AI能做的工作、在招聘中重视AI使用能力、在绩效评估里考查AI使用情况、申请增员前必须先证明工作无法被自动化。 在这家公司里，默认的生产者从人转向了AI，而人类不仅需要证明自己不可替代，还要和AI同台竞技，甚至从此绩效考核的评价方不仅来自于老板，还来自于AI——AI检查你对AI的使用多不多、好不好。 AI的热潮也带动着这一年的产品与财务表现节节攀升，使2025年成为多邻国的AI叙事最受市场青睐的一年。 第二季度，公司日活跃用户数（DAU）同比增长40%，净利润同比暴涨84%，到第三季度时，公司开始强调Duolingo Max和“家庭计划”带来的用户人均收入（ARPU）提升，出色的业绩推动股价在财报发布后一度大涨约24%。 《快公司》（Fast Company）报道称，市场用真金白银奖励了多邻国的AI故事。甚至在成本端，多邻国也给出了一个“反直觉”的信号：AI成本低于预期。这意味着，AI不仅能提升效率，其成本可控性也得到了证明。 成也AI，败也AI，“小绿鸟”跌落神坛 然而，光鲜的财务数字之下，裂痕已经开始显现。 对外，大量用户开始质疑课程质量，并抱怨“机器味太重”。对内，将AI使用与绩效强绑定的做法，使员工开始“为了用AI而用AI”。 2025年，多家媒体（如Customer Experience Dive，Polygon等）均提到，用户开始集中反馈课程质量层面的问题，诸如“AI生成的句子‘不自然’、‘像机器拼接’”“练习内容重复、语境不真实”和“部分语言课程质量波动明显”。 在Reddit、X（Twitter）等社区中，用户对“教学”这一人人互动的体验变差的诘问声浪也越来越大，“课程变得不像人教的”“对话缺乏真实互动感，像在跟一个模板对话”。 在多邻国内部，Gallup的调查显示，大量员工对AI持有谨慎甚至不信任的态度，他们担心“不会用AI=绩效不合格”、自己的岗位职责会被重新定义甚至边缘化，更多的是对AI是否会取代自己产生强烈的焦虑感。 舆论的影响并不仅仅停留在情绪层面，而是很快体现在具体的业务指标上。公司让“AI参选”，用户则开始“用脚投票”。一部分用户选择删除App，甚至放弃多年积累的连续打卡记录；与此同时，社交媒体上出现大量取消订阅的威胁与抵制言论，多邻国的TikTok和Instagram被用户愤怒的评论淹没，一度删除全部视频内容。 根据Reuters报道，多邻国的用户增长在2025年已经出现放缓，并被公司预期在2026年降至过去水平的一半左右。 市场的反应更加直接。在发布增长放缓的指引后，多邻国股价单日下跌超过23%，年内累计跌幅约38%。这标志着市场判断的转变：投资者不再只关心AI带来的效率，而开始质疑它对产品和商业价值带来的负向影响。 面对来自用户和资本市场的双重否定，多邻国在2026年被迫按下暂停键，进行策略回调。 在发布2025财年业绩时，多邻国明确表示，新财年将优先考虑用户增长和教学效果，改善免费用户体验，并大力投资象棋、数学、音乐等新业务线，即便这会压低短期利润。 同时，公司计划将更多AI功能开放给更广泛的用户，而非仅仅局限于高端订阅层，试图修复因过度追求AI变现而受损的用户关系。这一系列的动作，是多邻国带领用户在AI高速狂奔失散后的挽回之举，仿佛在试图找回以有趣、有效为核心的品牌初心。 再看路易斯的最新表态，就不觉得奇怪了，在多邻国内部，“AI松绑”也自然发生了。 路易斯在播客中公开表态，将不再把员工使用AI的情况纳入绩效考核，强调“最重要的是把工作做好”。 这实际上是否定了之前将AI使用量作为考核指标的尝试，在管理上，也一定程度上能够缓解之前员工“为了使用AI而使用AI”的表演行为，降低了“效率注水率”。 此外，当一个设计师被迫在无需AI的场景下强行使用AI生成配图，一个课程设计师为了刷量而生成大量同质化内容，这非但不能提升效率，反而制造了内部焦虑，并可能导致思考外包——员工不再深入理解问题本质，而是机械地寻求AI的“帮助”。 短短几年，多邻国已经完成了对AI的“上头”和“下头”。 03 阵痛不止多邻国有 多邻国的困境并非个例，它只是首先暴露了AI深度融入商业世界时引发的水土不服，或许多邻国的问题不在AI用得太多，而在过早、过急。在多邻国身后，科技公司们正经历着相似的成长的烦恼。 以电商平台Shopify为例，其CEO托比·卢克曾明确提出“在招人之前，先问AI能否做到”，将AI置于人力的优先级之前。这一理念和多邻国“需要证明人无法被AI替代”的逻辑如出一辙：推崇极致的工作效率。 毕竟在极致的效率这一点上，人确实无法优于AI，毕竟AI不需要休息、不需要请假，也不会去社交媒体上抗议。 Shopify虽然没有大规模裁员，但让许多岗位的JD不再出现在招聘市场上，如ur初级岗位、重复性岗位和支持性职能。此外，Shopify还在内部强调，AI可以让团队完成更多的工作，甚至带来百倍的效率提升。 Shopify的这套策略被曝光后迅速在社交媒体上传播，引发大量讨论。《华盛顿邮报》在报道中提到，有从业者公开批评这种做法“无法推荐这样的公司”，认为它对员工不公平。在Reddit和X等平台上，类似的情绪更加直接——如果所有公司都这么做，新人还能从哪里开始？ 与此同时，这种策略也开始在产品和客户体验层面产生副作用。Shopify在客服等环节引入AI后，一些商家用户的反馈并不理想。《The Logic》报道称，部分商家对AI客服的响应方式感到困惑甚至不满，认为问题解决效率并没有明显提升，反而增加了沟通成本。有商家在论坛中写道：“我只是想跟一个真正理解我问题的人类沟通。”；另一位用户则评论：“AI的回复很快，但并没有真正解决问题。 ”AI一旦进入“人人交互”环节，效率的提升反而演变为服务的降级。 还有更多的多邻国们在AI之路上狂奔。Meta内部越来越强调AI工具的使用熟练度，甚至出现“Token使用排名”等文化。Klarna在激进部署AI客服并宣称取得巨大效率提升后，又不得不公开承认复杂场景下人类客服的不可替代性，进行了策略微调。 AI的投入在部分生产环节中确实能够提升效率，短期内可能提振股价，但另一方面，它也向员工和社会大众传递令人不安的信号：人的价值正在被工具化。公司越是公开强调AI对效率的颠覆，就越把公司间效率的竞赛演变为“人与机器的竞赛”，这无疑会加剧员工和用户的焦虑情绪，最终的成本终将体现在企业真正在意的股价上。 然而，多邻国2026年的“松绑”，不应简单解读为AI战略的失败或倒退。多邻国并没有失败，只是最先走到极限。多邻国的故事，是一个关于管理方式而非技术本身的故事。 查看评论