Hi, 请登录     我要注册     找回密码

Codex 拿下 Claude Code 都没解决的难题：微信输入法右引号 Bug 修复实录

分类：未分类 阅读() 评论(0)

macOS 用户此前发现，使用微信输入法在 Ghostty 终端中输入中文时存在一个奇怪问题：连续按两次引号键，本应得到成对的中文引号，实际却只能打出两个左引号。而系统原生输入法搭配 Ghostty、微信输入法搭配 iTerm2 均表现正常，问题仅出现在微信输入法与 Ghostty 的组合上。经排查，解决方法是在微信输入法已有的 use_local_context_bundles 策略中加入 Ghostty 的 Bundle ID（com.mitchellh.ghostty），使输入法为该应用维护独立的输入上下文，从而正确判断下一次应输出左引号还是右引号。该策略保存在 ~/Library/Application Support/WeType/mmkv/wetype.features 文件中。作者特别提醒，该文件为 MMKV 二进制存储并配有 .crc 校验文件，不能直接用文本编辑器修改，需借助腾讯官方 MMKV 库读写，修改前应备份，修改后需重载输入法。在解决过程中，作者先尝试使用 Claude Code（opus-5-5 xhigh）未能成功，随后改用 Codex（gpt-6.1-sol xhigh），借助源码分析、Computer Use 等手段，最终定位并解决了问题。作者感叹如今的 AI Agent 已足够强大，大部分疑难杂症都能解决。

事件分析

这一案例的技术看点在于输入法与终端应用的兼容机制：微信输入法依赖应用级上下文策略来判定引号配对，而 MMKV 二进制存储抬高了配置修改门槛，普通用户难以手工干预。更重要的是问题解决路径——AI Agent 在常规调试失败后，通过源码分析与 Computer Use 组合操作，完成了对闭源软件配置格式的逆向式排查，展示了 Agent 处理系统级、跨应用疑难问题的能力。Claude Code 与 Codex 在同一任务上的表现差异，也为评估各家 AI 编程工具的真实能力提供了鲜活参照。后续走向上，此类由 Agent 主导的深度排障可能成为开发者社区的新常态；输入法厂商若能开放更友好的配置接口，也可减少类似兼容性问题依赖手动修复的成本。

核心观点：AI Agent 已能攻克闭源软件的系统级疑难 Bug，编码工具之争正从代码生成转向真实排障能力。

原文链接：Linux.do

C code80.ai · AI 编码 API 聚合 Claude / GPT 多模型统一接入,稳定不限速,按量计费,几行配置接入 Claude Code。 了解一下 ›

相关推荐

抢沙发

评论前必须登录！

立即登录   注册

易安
易安作者
长期关注 AI Agent、软件工程、自动化工作流与个人生产力系统。喜欢把复杂技术拆成普通人也能上手的实践教程,也记录自己在工具链、编程、内容创作和知识管理上的真实折腾。
  • 分享 AI 工具、Agent 工作流与提示词工程的实战经验
  • 记录从想法到产品、从代码到上线的完整实践过程
  • 关注普通人如何用 AI 放大能力,而不是被工具牵着走
阅读作者的全部文章 ›
文章目录

    置顶推荐

    Code80 · AI 编程巴士

    前沿哨所

    • 新基准MaxxBench质疑AI编程智能体：DeepSWE高分是真泛化还是'背题'？

      Hacker News近日出现一项名为MaxxBench的新基准研究，全称为’Benchmarking Task Adaptation and Generalization in Frontier Coding Agents’，聚焦评测前沿AI编程智能体在任务适配与泛化方面的真实能力。该基准的核心测试思路是：对智能体已经熟悉的软件工程任务进行改动，让’熟悉的题目提出不同的要求’，观察模型能否正确响应。研究页面以’Nice DeepSWE score. But is it true?’为标题，直接对DeepSWE等模型在主流基准上的高分提出质疑，暗示部分成绩可能来自训练数据与评测集的重叠，即所谓的基准污染与过拟合，而非真实的工程泛化能力。MaxxBench试图补充SWE-bench等现有基准的不足——后者因被广泛使用和公开讨论，其题目大概率已进入各模型的训练语料，导致榜单分数的区分度持续下降。该研究针对当前主流的前沿编码模型与Agent框架，通过任务变形来量化模型的适应能力，并公开了详细的研究方法说明页面。此类’反过拟合’基准的出现，反映出AI评测社区对基准可信度问题的关注正在明显升温，也可能改变模型能力的衡量方式。

      事件分析

      MaxxBench指向AI行业的一个隐性问题：主流编程基准因公开度极高，题目极易进入训练数据，榜单高分与实际工程能力之间可能已经脱节。该基准通过任务变形测试泛化，若头部模型在变种任务上表现大幅下滑，将动摇’以榜单论英雄’的模型发布叙事，也会影响企业选型时的参考依据。从产业角度看，评测方法论本身正在成为新的竞争维度，动态更新或私有的评测集将获得更多话语权。后续值得关注的是MaxxBench完整评测结果是否披露，以及DeepSWE等被点名的模型团队是否会公开回应；若质疑成立，训练数据去重与评测集隔离将上升为模型工程的标配环节。

      核心观点：当榜单分数可能来自'背题'而非真功夫，评测可信度本身正成为AI编程竞争的新战场。

      原文链接：Hacker News

    • AI前沿的终结：能力突破正从开放研究收缩为巨头内部游戏

      知名机器学习研究者John Langford在其个人博客hunch.net发表文章《AI前沿的终结》，指出AI领域“研究前沿”的存在形态正发生根本性变化。文章回顾了过去几十年AI研究的推进方式：学术界、开源社区和小型研究团队曾长期占据前沿位置，新想法可以在公开环境中快速验证、传播和迭代。而当下，训练最先进模型所需的算力、数据和资金规模急剧膨胀，能够负担前沿实验的机构只剩下少数科技巨头，能力突破正从开放的公共领域收缩为封闭的产业内部活动。文章分析了这一转变带来的连锁反应：学术研究难以触及真正的能力天花板，开源模型与闭源前沿之间的差距持续拉大，顶尖研究者加速流向产业实验室。作者同时讨论了新格局下的应对思路，包括将研究重心转向强化学习、评估方法与应用层创新，以及在有限算力条件下寻找差异化的研究空间。该文在Hacker News社区引发广泛讨论，焦点集中在开源生态能否跟上前沿、学术AI研究的价值重估，以及个体研究者在新格局中的位置。

      事件分析

      这一论断与近年的产业数据相互印证：前沿模型的训练成本已从百万美元量级攀升至数亿美元量级，进入门槛呈指数级上升。由此产生的结构性影响体现在三个层面：其一，算力规模取代想法本身成为研究竞争的核心变量，科研经费与GPU集群数量决定参与资格；其二，开源生态的追赶策略从同步研发转为蒸馏和复现闭源成果，时间差成为常态而非例外；其三，评估体系与安全研究的重要性相对上升，因为外部研究者接触最前沿系统的机会越来越少。后续值得关注的是推理时计算范式的普及能否重新降低前沿参与门槛，以及各国公共算力基础设施计划能否为学术界保留一席之地。

      核心观点：当前沿被算力价格锁死，AI创新从开放探索变成资本军备竞赛，真正的变量只剩巨头的现金流。

      原文链接：Hacker News

    • 31B音视频扩散模型压缩至14B：6步生成、INT8量化

      一支开发团队在Hacker News发布Show HN项目，宣布将一个310亿参数的音视频联合扩散模型压缩至140亿参数，同时将推理步数降至6步，并采用INT8整数精度部署。这是在模型体积、采样步数与数值精度三个维度同时优化的综合成果。扩散模型通常需要数十步迭代采样才能生成高质量内容，步数直接决定生成延迟与算力消耗；将步数压缩至6步，一般需借助步数蒸馏或一致性采样等技术实现加速。INT8量化则将模型权重从常见的16位浮点压缩为8位整数，可大幅降低显存占用、提升推理吞吐，尤其有利于在边缘设备和消费级显卡上部署。音视频联合生成模型对算力的需求远高于纯文本或纯图像模型，动辄数百GB显存的需求使其长期只能依赖云端大规模集群运行。此次参数减半、步数锐减、精度降低三者叠加，推理成本有望下降一个数量级，为大规模多模态生成模型走向本地化、实时化部署提供了可行路径。该帖发布后引发社区对模型压缩技术路线与实际生成质量保留程度的讨论。

      事件分析

      该工作的核心看点在于同时在三个正交维度做压缩：参数规模减半、采样步数从常规数十步降至6步、数值精度从FP16降至INT8，三者叠加的工程复杂度远高于单一维度优化，需要蒸馏、剪枝与量化感知训练等多种技术协同。音视频联合建模通常依赖庞大的DiT骨干网络与跨模态对齐模块，是当前算力消耗最高的生成任务之一，此类模型若能在消费级硬件上接近实时运行，将直接改变视频生成服务的成本结构。产业层面，步数蒸馏与量化部署正从大语言模型领域向多模态生成迁移，6步生成的低延迟特性可能催生交互式视频创作、虚拟主播实时驱动等新场景。后续值得关注的验证点包括：压缩后音画质量与一致性的保留程度、是否开源权重与推理代码、以及在主流消费级显卡上的实测吞吐与显存数据。

      核心观点：多模态生成的竞争正从拼参数转向拼效率，谁能把大模型塞进消费级硬件，谁就握住规模化落地的钥匙。

      原文链接：Hacker News

    • OpenCode Go 接进 DSH：缓存 99.8% 命中，计费打六折

      OpenCode Go 每月 10 美元给 DeepSeek V4.1 Flash 100 美元额度，接进 DSH 后同一会话第二轮缓存命中 99.8%，成本只剩首轮的 2.4%。这个数字成立的前提只有一个：请求里带一个稳定的 x-opencode-session 头，而它在 DSH 里会因为一行配置静默失效。

      数据来自 2026-11-07 的真实订阅账号与实测请求，DSH 侧数据在 0.2.1-rc.5 headless profile 上抓包获得，单价以 OpenCode 官方 Go 文档当日页面为准。

      这 10 美元买到了什么

      OpenCode Go 是订阅制，不是充值制。每月固定 10 美元，换一批模型各自的月度美元额度，额度用完可以切到免费模型，或者开启 Extra Usage 回落到按量付费余额。

      对 DeepSeek V4.1 Flash 来说，这个额度是每月 100 美元。但它不是一个整块，而是被切成三个滚动窗口，其中 5 小时窗口最容易被撞到。

      指标 数值 说明
      订阅价 10 美元 / 月 Go 档，单成员工作区
      V4.1 Flash 月度额度 100 美元 5 小时窗口 20 美元，每周 50 美元
      V4 Pro 月度额度 15 美元 5 小时窗口仅 3 美元
      官方估算请求数 21.6 万次 / 月 按典型 coding agent 请求结构

      三个窗口的额度分配

      DeepSeek V4.1 Flash 在 Go 套餐下的三层额度窗口横向条形图

      同一个月度额度被切成 5 小时、每周、每月三层，最短窗口只有总额度的五分之一。

      把额度换算成 token 更直观。DeepSeek 在 Go 上采用峰谷定价：低谷时输入每百万 token 0.15 美元、输出 0.60 美元、缓存读 0.003 美元；高峰是低谷的两倍，高峰时段为 UTC 周一至周五 01:00–04:00 与 06:00–10:00，折成北京时间就是工作日上午 9 点到 12 点、下午 2 点到 6 点。

      所以 100 美元能买多少 token，取决于你让它读多少、写多少，还取决于缓存命中率。三个纯理论值如下，全部按低谷价计算。

      100 美元的理论兑换量

      计费类型 低谷可买 高峰可买
      纯输出（生成） 1.67 亿 token 8330 万 token
      纯新输入（读代码） 6.67 亿 token 3.33 亿 token
      纯缓存读（重复上下文） 333 亿 token 167 亿 token

      注意：V4 Pro 的额度只有 15 美元，5 小时窗口 3 美元，按官方估算约 1050 次请求。它适合攻坚，不适合当主力。真正跑量的模型必须是 V4.1 Flash。

      实测：缓存到底命中没有

      订阅之前最该确认的不是价格，是缓存有没有生效。同样一份上下文，命中缓存和没命中，成本差 50 倍——缓存读每百万 0.003 美元，未命中输入每百万 0.15 美元。

      验证方法很直接：同一个会话里，连续两次发送完全相同的前缀，看第二次的 cached_tokens 是否接近 prompt_tokens。

      DSH 侧的两轮抓包（18.9k 上下文）

      场景 prompt_tokens cached_tokens 命中率 allowance 耗时
      首轮 18,978 640 3.4% 0.00165 45.1s
      次轮（同会话） 18,989 18,944 99.8% 0.000039 2.6s

      第二轮的成本只有首轮的 2.4%

      同一会话首轮与次轮额度消耗对比条形图，次轮仅为首轮的百分之二点四

      同一会话内前缀不变时，第二次请求的额度消耗断崖式下降，耗时从 45 秒降到 2.6 秒。

      另一次更小规模的独立验证也复现了同样的形状：4035 token 的上下文，第一次缓存命中 73%，第二次升到 98.3%，额度消耗从 0.00010421 降到 0.00001389。

      两次实验用的是不同的客户端、不同的上下文长度，但结论一致：只要 session 头稳定，OpenCode 网关就会把请求固定路由到同一后端，prompt 缓存正常复用。9 月那次「缓存完全不命中」的问题，在现在的链路上不复现。

      要点：判断缓存是否生效，不要看响应耗时，看 usage.prompt_tokens_details.cached_tokens。耗时受网络和排队影响，这个字段不会说谎。

      接进 DSH 的三个硬坑

      先说结论：DSH 原生支持 OpenCode Go，一个插件都不用装。前提是版本 ≥ 0.2.0-rc.2，从这个版本起它自己会发 x-opencode-session。低于这个版本才需要补 session-header 插件。

      配置本身很短，全部写在 profile 的 cordis.patch.yml 里。

      最小可用配置

      - id: llm-pi-ai
  config:
    providers:
      opencode-go:
        displayName: OpenCode Go
        models:
          - id: deepseek-v4.1-flash

- id: agent-default-model
  config:
    provider: opencode-go
    model: deepseek-v4.1-flash

      注意这里没有写 baseURL，也没有写 contextWindow。因为 DSH 内置的 pi-ai 目录里已经声明了：端点 https://opencode.ai/inference/go/openai/v1、上下文窗口 100 万、最大输出 38.4 万、协议 openai-completions。写冗余配置不加速，只会制造第二个真相源。

      provider 段还需要一行，把凭据来源指向一个环境变量。变量名沿用 DSH 对该 provider 的默认约定，值放在 profile 的 .env 里，别提交进仓库。

      坑一：这一行不能写 api

      这是最难查的一个坑。如果你在 opencode-go 那一段里写了 api: openai-completions，请求会正常返回、不报任何错，但 cached_tokens 恒为 0。

      根因在 DSH 的 buildProvider：只有 spec.api === undefined 时，它才走 reuseCatalogProvider 复用目录自带的实现；那层实现被 withOpenCodeSessionHeader 包过，负责补 session 头。一旦写死 api，就走 createProvider 新建，包装被绕过，头静默消失。

      两种写法的结果差异

      写法 provider 来源 session 头 缓存结果
      不写 api 复用目录实现 自动补上 命中 99.8%
      写了 api createProvider 重建 缺失 恒为 0，且不报错

      注意：这个坑没有错误提示。 配置看起来完全正常，请求也成功，唯一的症状是缓存永远不命中、成本按 50 倍走。排查成本的时候，第一件事就是回去把 api: 删掉。

      坑二：Region 不设成 Global，模型直接不可用

      OpenCode 侧默认只允许 Europe 与 United States 区域，DeepSeek 两个模型需要你在 Console 的 Settings › Privacy 里把 Regions 选成 Global。不做这步，key 正确、配置正确，依然调不通。

      这个设置页只对有活跃 Go 订阅的 owner 或 admin 显示。订阅前打开是看不到 Regions 那一栏的，容易误以为文档漏写。

      坑三：key 长度是 51

      复制 key 的时候尾部多一个字符（比如 %）是常事，症状是 HTTP 401。与其反复调 DSH，不如先量长度：

      KEY=$(cat "$KEY_FILE")
[ ${#KEY} -eq 51 ] && echo ok || echo "长度不对: ${#KEY}"

      403 来自 Cloudflare，不是 OpenCode

      用 Python 脚本调这个端点会直接 403，返回体是一行 error code: 1010。这不是鉴权失败，也不是额度问题，是 Cloudflare 的 WAF 在拦 UA 指纹。

      三个客户端打同一个端点，结果完全不同。

      同一端点、不同默认 UA 的结果

      客户端 默认 User-Agent 结果
      Python urllib Python-urllib/3.13 403，error code 1010
      Node fetch (undici) 不发送 UA 200
      curl curl/8.x 200

      所以官方文档里那句「客户端应当用自己的 user agent 标识自己，而不是通用 SDK 或 HTTP 库的名字」，不是建议，是硬性拦截。只是触发条件很具体——curl 和 Node 都不受影响，偏偏 Python 的标准库 UA 会被拦。

      如果你们用 Python 写健康检查、监控探针或者批量任务，这里一定会踩。加一行自定义 UA 就好。

      req = urllib.request.Request(
    url, data=body, headers={
        "Authorization": "Bearer " + key,
        "Content-Type": "application/json",
        "User-Agent": "your-agent/1.0",
        "x-opencode-session": "ses_stable_id",
    })

      额度的真实购买力

      OpenCode 在每个响应的 usage.opencode 里回了两个字段：list_cost 是按模型标价算出的费用，allowance 是实际计入套餐额度的金额。两者的比值稳定在 0.600。

      这意味着 Go 套餐按标价的六成计消耗：100 美元额度，实际对应约 166.67 美元的标价用量。这也是为什么官方敢说 100 美元能跑 21.6 万次请求——比按标价直接除算出来的多得多。

      三次请求的系数校验

      请求 list_cost allowance 比值
      短请求探活 0.00001830 0.00001098 0.600
      长上下文首轮 0.00017368 0.00010421 0.600
      长上下文次轮 0.00002315 0.00001389 0.600

      但这个额度不是稳定定价，它在两个月里被改过四轮：9 月 10 日接入时 15 美元，9 月中限时四倍到 60 美元，10 月 12 日提到 80 美元，10 月底到 100 美元。一个半月翻了六倍多。

      同期 Go Plus 从 160 美元提到 200 美元。这种幅度不是成本下降，是获客补贴。

      一个半月里的额度曲线

      DeepSeek V4.1 Flash 在 Go 套餐中的月度额度变化柱状图，从九月十五美元升至十一月一百美元

      DeepSeek V4.1 Flash 在 Go 套餐里的月度额度变化，从 15 美元到 100 美元，六次调整全部是上调。

      背景：补贴期的曲线只能参考，不能当架构前提。OpenCode 这条线在两个月里已经调整过多次，方向随时可以反过来。

      现在用，但别把它当长期方案

      把 DeepSeek V4.1 Flash 接进 DSH 这件事，技术上是成立的，成本上是划算的，但它建立在三个会变的前提上：额度还在涨、六折系数还在、把 Region 放开这件事还允许。

      所以落地时的优先级应该是：把模型路由和凭据放在能一行切走的地方，把业务逻辑和 DSH 的绑定降到最低。真要长期跑量，自己的 DeepSeek key 留在 .env 里当备份，切回去只改两行。

      另外一个实测出来的数字值得写进产品预期：21.6k 上下文的冷 prefill 要 109 秒，而次轮只要 5 秒。这不是配置问题，是大 system prompt 的必然代价。做长会话产品时，要么把稳定前缀拆出来单独命中缓存，要么就别指望首轮有交互感。

      要点：省钱的关键不是换更便宜的模型，是让缓存命中。同一份上下文，命中与不命中差 50 倍——这比任何订阅费率都重要。

      引用与来源

    • 开源工具rea-game：将游戏录像整理成结构化原型开发计划

      开发者在V2EX分享了开源小工具rea-game，用于把游戏录像整理成可直接用于原型开发的结构化材料。该工具针对的痛点是：游戏原型设计阶段参考录像时，画面中确实发生的现象、推测背后的规则、以及无法确认的信息往往混杂在脑中，难以转化为可靠的开发依据。工作流程分三步：首先用FFmpeg从本地游戏录像中按时间点提取画面并记录时间戳；随后人工核对画面与对应视频片段，将观察结果、推断、未确认问题和实现建议分别写入review文件；最后运行命令生成Markdown报告，内容涵盖玩法循环、交互设计、界面、视听表现、待确认问题及一份原型实现计划。作者强调工具本身不会自动看懂视频，分析工作仍需人工完成，也可借助支持视觉输入的AI助手协助；工具的职责是组织证据与结论，并校验时间戳和格式，尽量避免把猜测误写成已确认规则。项目采用MIT许可开源，基于Python和FFmpeg构建，全部在本地处理视频，无需API Key，目前需从源码克隆安装，通过pip安装后即可使用rea-game extract命令提取画面，代码托管在GitHub。

      事件分析

      从技术实现看，rea-game并未引入视频理解模型，而是聚焦工作流的结构化：用FFmpeg完成帧提取与时间戳管理，用固定格式的review文件强制区分观察、推断、待确认三类信息，从流程上抑制主观臆测污染设计文档的风险。这种AI辅助加人工核验加工具约束的组合，正是当前开发者利用多模态大模型视觉能力的常见范式。其全本地化、无API依赖的设计降低了使用门槛，也契合数据隐私考量。局限在于自动化程度有限，帧提取后的分析仍高度依赖人工投入。后续若接入视觉模型自动生成初版观察记录，或与游戏引擎原型模板打通，工具价值可能进一步放大。这类垂直场景开源小工具的涌现，也反映出AI应用正从通用助手向细分工作流深度渗透。

      核心观点：工具价值不在看懂视频，而在于把AI时代的经验观察沉淀为可校验的结构化开发流程。

      原文链接：V2EX 分享发现

    • 批量购买20个Devin Max账号一夜遭封禁，官方回复后杳无音讯

      11月4日，一位企业用户批量开通了20个Devin Max订阅账号，单价200美元。次日（11月5日）下午，这批账号状态全部变为FREE，疑似被平台自动降级封禁。用户随即致信Cognition官方邮箱[email protected]，并附上Stripe支付凭证作为购买证明。11月6日收到官方署名回复，称该问题源于保护平台和所有用户的自动化安全防护措施，相关限制在账户级别生效，切换模型或订阅方案均无法解除；官方表示正在进一步审查账户，审核完成后将跟进反馈。然而此后用户未再收到任何后续消息，问题至今悬而未决。该用户将完整经历发布至Linux.do论坛，并指出近期社区中多人反映遭遇类似封号情况。Devin是Cognition AI推出的AI软件工程师产品，Max方案面向高频重度使用者。此次事件显示其自动化风控机制在区分企业批量采购与异常行为时存在误判空间，且申诉处理缺乏明确时效承诺，给有意批量采购的企业用户带来不确定性，也引发社区对AI编程工具售后保障能力的讨论。

      事件分析

      从技术角度看，此类封号大概率由反欺诈与反滥用系统触发：同支付渠道、同主体批量开通高价位订阅，容易被风控模型标记为疑似转售、盗刷或共享滥用，自动化拦截是平台安全体系的标准设计。真正的问题在于风控误判后的申诉闭环缺失，官方回复承诺审核跟进却再无下文，暴露出Cognition在客服流程与内部工程团队协同上的短板。产业层面，AI编程Agent正处企业采购放量阶段，信任是核心资产，误伤叠加申诉无门会直接动摇企业客户的续费与扩容意愿。后续走向上，若同类案例持续累积，可能倒逼官方建立批量采购白名单、企业认证通道及申诉时效承诺；这类一手案例也将成为企业评估AI工具供应商服务可靠性的重要参考样本。

      核心观点：风控误伤不可怕，可怕的是申诉无门的黑箱流程，信任流失才是AI Agent商业化的最大隐性成本。

      原文链接：Linux.do

    最新文章

    热门专题

    热门标签

    AI编程claude大模型AIAI Agent人工智能开源项目Gemini开发者工具开源Claude CodeGitHub开源工具AI工具开发工具谷歌openaideepseek提示词工程cursoranthropic网络安全AI应用ChatgptAI开发agentAI安全自动化智能体AI智能体

    网站统计

    • 日志总数：29684
    • 评论总数：7
    • 标签总数：17949
    • 用户总数：3675
    • 最后更新：2026-11-08