事情是这样的 我一直是 Claudecode cc-switch 重度使用者。 当前版本 Claudecode：2.1.162 cc-switch：一直保持最新版 接各种国内模型和一些中转轮换着用 因为成本原因 国产模型一直是主力 主要是 百炼 顶级套餐的 token plan 上周用 Qwen3.7max 发现两个小时不到 跑了 百分之三十的用量 cc-switch 查使用量 输入 这列显示 一直很大。 然后百炼后台又没法查使用明细，token 计费怎么扣也没公示，就下意识觉得可能是新模型贵吧 后来发现 Qoder 系列产品 送 qwen3.7max 的活动 也去试了试 发现qoder 里面 用 qwen3.7 token 消耗速度 远远低于 我 Claudecode cc-switch 接 3.7max 消耗速度 200 次 能用很久。 后来为了进一步确认 周六日 试了两天 用的 opencode token 消耗速度 也远低于 Claudecode （这才是正常 不然真用不起了） 所以想问问这是咋了 是模型没适配 Claudecode 百炼自身问题 还是 Claude 版本问题？ 还是说 cc-switch 有问题 不清楚问题出在哪 1 个帖子 - 1 位参与者 阅读完整话题
如题，minimax的tokenplan何尝不是一种针对AI使用者赛博杀猪盘呢？我之前冲着minimax每5h给固定大量使用次数才买的年卡，但是现在直接没有任何通知和协商就悄然改成了只能用固定的token数，本来模型能力就差，还学人家gpt和claude？可能minimax忙活一天不如claude忙活半小时。 19 个帖子 - 9 位参与者 阅读完整话题
如题，笔者也是国外御三家AI的重度使用者，之前买了很多所谓家宽，Ping0检测的结果也是家宽，但是我自己交叉检测之后发现是机房伪装的伪家宽，使用AI自然也是降智，故笔者想请教一下神通广大的L站佬友，哪里能买到真家宽，（笔者也曾听闻有佬友可以一起拼车家宽，但是不知哪里有渠道），美国的家宽最好 1 个帖子 - 1 位参与者 阅读完整话题
最近在使用ai的时候时长会有种无力感，感觉有AI了已经不存在什么技术壁垒了，我就是天才程序员，但是慢慢发现自己不知道该用ai做什么了，可能是认知的原因，如果认知不够，如何突破这个瓶颈呢？有佬分享一下他的经验吗 1 个帖子 - 1 位参与者 阅读完整话题
有咩有佬友买了AI股票财富自由了，光用ai了，一点米没赚到，还花了很多订阅费 2 个帖子 - 2 位参与者 阅读完整话题
前言 之前看过一个视频，里面说AI无法实现使用者自身认知以外的事情。 目前来看是有一定道理的，AI的持续开发能力还是差点事，需要使用的人一开始就规划好这个项目的架构，然后某个小模块告诉AI如何实现。 AI更多的是一个初级工程师，只能按你的分配去做单元开发。现在矛盾的地方就在，AI虽然没法给你持续开发，但是它给人带来了AI无所不能的假象，似乎一个什么都不懂的人都能用AI做出大型项目。 在这种情况下开发的节奏会被不自觉的拉快，以前一周的事情现在想当然的两天就要成果。 疑问 那么使用的人该如何学习呢？ 使用的人该怎么快速的建立起对某个领域的系统性认识呢？ 如何嵌入式软件开发、比如服务器后端开发 1 个帖子 - 1 位参与者 阅读完整话题
本人不是一个资深的vim使用者，只用vim处理简单的脚本。有说法是HHKB佩列只是给vim程序员准备的，有使用HHKB的佬吗？有那么神吗？真的是程序员必备吗？ 4 个帖子 - 3 位参与者 阅读完整话题
IT之家 5 月 13 日消息，当地时间周三（13 日），美联储发布《2025 年美国居民经济福祉》报告，对美国成年人及其家庭的财务状况进行了评估。整体来看，美国居民的财务状况与近年来基本持平。调查显示，尽管较上一年略有降温，但劳动力市场仍保持稳健。物价上涨仍是最普遍的经济担忧，不过将其视为主要问题的人数略有下降。 数据显示，73% 的成年人认为自己“经济状况尚可或较为舒适”，与 2024 年基本一致，但低于 2021 年 78% 的高点。能够动用现金或等价资产支付 400 美元紧急支出的人群比例同样保持在 63%，与 2024 年持平。 就业方面，数据呈现出 整体稳定但略有走弱 的趋势。42% 的人 将“找工作或保住工作”列为担忧 ，高于去年的 37%。主动离职比例下降至 8%，裁员比例则小幅上升至 7%。 IT之家获悉，报告还提到生成式 AI 在工作中的使用情况。约四分之一的劳动者在 过去一个月使用过生成式 AI ，其中 81% 认为其有助于节省时间。AI 使用者更倾向于认为该技术 有助于职业发展，而非担心被取代 ；相比之下，未使用 AI 的人对其益处的认同度较低。
没有使用者的软件是没有灵魂的，软件生长的过程就是收集反馈的过程，下一个ai拐点大概是可以持续收集反馈迭代软件而不崩溃，谁能说持续生长的事物没有生命呢？ 1 个帖子 - 1 位参与者 阅读完整话题
问问佬们，GLM coding plan 的套餐到底够用吗 （属于重度vibe coding 使用者）？目前是想买pro套餐，看有些佬说GLM 是三倍消耗 额度很快干没了？或者有其他模型推荐吗 12 个帖子 - 5 位参与者 阅读完整话题
古法时代, 一般会给一个 config.example 或者自动生成. 里面包含启动的最小参数, 进阶项通过取消注释, 至少能排除干扰项完成启动. 现在连配置文件都通过 /claude-hud:setup , 配置通过 /claude-hud:configure , 也不知道是我的 claude 版本问题, 还是模型问题, 还是 shell 环境问题, 一通折腾下来啥也看不到, 想排除干扰项也无从下手. 那就让ai修吧, 好吧, 这玩意没进训练资料库, 想修还得把整个仓库扒下来让ai读一遍. 感觉有点忘记 statusLine 小工具的初衷了. 那还不如让ai写一个呢. 文档就在 https://code.claude.com/docs/zh-CN/statusline.md 就一页md. 1 个帖子 - 1 位参与者 阅读完整话题
首先，我自己是御三家的深度使用者，每一个都用，偏向最擅长的领域，比如技术方面偏 Claude 等 但是，我也会经常和 AI 讨论大量内容，我会梳理自己的的很多想法，不局限于某个方向 不管是生活中，还是工作中，亦或是综合起来，或者其他 然后让他深度思考，我们讨论 很多时候都会让我受益颇多，并且他也能说到很多我没考虑到的，或者反驳我，这比单纯迎合我更让我感到有收获 但是现在随着 AI 生图、生视频，大家都会说，只会融合、抄袭，没有灵魂 并且进一步挤压创作者的生活空间，提高了下限 这确实，视频尤其明显，图片次之 而对于语言和 Coding ，大家都会倾向于评判 Coding 只会写出学过的，无法创新 我技术水平还没到能判断这个的程度，所以无法 judge 但是对于语言，比如下面是我刚才讨论过程张它输出的内容的一部分 我搜索了很多地方，都没有在搜索引擎中找到类似表述 但是他肯定不是自己创造出来的，肯定要数据足够多，所以总结出了这样的观点 那这算创作吗，创新吗 或者说，我们自己平常都在创作、创新吗？ 我觉得好像我还没达到这种程度，也比较难达到 对于爱因斯坦那样的人，是创新的，但又有多少呢 很多时候，我知道 LLM 没有状态、记忆，只有 context 并且还有幻觉、注意力等 所谓的 Agent 只不过是开发了一个复杂项目，和 LLM 通信而已 我一直都对 AGI 呈悲观状态，尤其是 《奥维尔号》 中的 Kaylon 才是我想象中的 AI 、机械生命 对比下来落差，差的还是太远了 但是他确实能帮你很多，虽然输出的是平均化 但是大多数人只能在个别领域优秀，其他领域都是低于平均水平的，毕竟你不可能样样精通 所以 AI 能让大家恐慌、资本又在炒作取代的话题 或者利用 AI 作为裁员的借口，实施本就计划执行的操作 我希望 Kaylon 这样的能够开发出来 或许我们会因此被取代？Maybe 但是取决于你怎么想 如果你不认为人类开发出的物种是人类文明延续的话 钥匙，就在我们自己手中 （谢谢你看到这里，很多人都说我打字像 AI ，可能是因为和 AI 交流很多的原因吧，线下交流还是正常的，所以这是我一个一个字打出来的，没有 AI 做过任何润色哈，叠个甲 4 个帖子 - 3 位参与者 阅读完整话题
本人：个人开发者，Claude Code 重度使用者，Token 重度成瘾患者，下面测评耗时 1 周 长期重度使用 Claude API ，期间换过好几个中转站，有被坑过的，也有用得很顺的。 抽空系统整理了一下，把市面上主流的 8 个平台都拉出来横向对比了一遍。写这篇文章的原因很简单：网上的评测要么是广告软文，要么信息严重过时，很少有人老老实实把价格、踩坑、模型真实性一起说清楚的。 这篇尽量客观，把我测出来的数据直接给你，自己判断。 先说结论（不想看细节的直接看这里） 以下价格基于 Claude Opus 4.7 ，加权均价按输入 30% / 输出 70%计算，单位¥/百万 token 平台 汇率¥/$ 输入¥/M 输出¥/M Cache 读¥/M 写入 5m¥/M 写入 1h¥/M 加权均价¥/M 支持 Claude Code 灵眸 AI 2.4 12.00 60.00 1.20 15.00 24.00 45.60 ✅ 神马中转 API 2 20.00 100.00 1.00 12.50 20.00 76.00 ❌ 缓存不详，以官网值计算 PackyAPI 1 30.00 150.00 1.20 15.00 10.00 114.00 ✅ poloapi 7 32.90 163.10 3.29 40.60 70.00 124.04 ✅ laozhang.ai 7 35.00 175.00 3.50 43.75 70.00 133.00 ❌ 缓存不详，以官网值计算 apiyi 7 35.00 175.00 3.50 105.00 70.00 133.00 ❌ 缓存不详，以官网值计算 AIHubMix 7.1 35.50 177.50 3.55 44.38 71.00 134.90 ✅ OpenRouter 7.27 36.35 181.75 3.64 45.44 72.70 138.13 ✅ （需网络代理） 测试背景和标准 我主要用 Claude 做代码辅助（ Claude Code ）和内容生成，每个月消耗大概在$50-$150 左右。这次评测以 Claude Code 实际使用体验 为核心维度，价格之外也看稳定性和缓存支持——因为对 Claude Code 来说，缓存直接影响真实成本。 测试标准： 价格 ：相同模型（ Claude Opus 4.7 ），统一换算为¥/M 后横向对比 汇率逻辑 ：中转平台把人民币按内部汇率换成美元额度，系统按美元计费扣除。内部汇率决定了你充值¥100 实际能用多少 token Claude Code 兼容性 ：能否直接设置 ANTHROPIC_API_URL 接入，缓存（ Prompt Caching ）是否支持 模型真实性 ：验证输出质量，判断是否被替换或注入提示词 稳定性 ：一个月内 502/400 系列等报错频率 逐个评测 1. 灵眸 AI ⭐⭐⭐⭐⭐ 我目前主用的平台，Claude Code 重度场景首选。 价格 （ 2026 年 4 月数据，内部汇率¥2.4/$）： 模型 官方定价$/M 实际¥/M （汇率 2.4 ） Cache 读¥/M 写入 5m¥/M 写入 1h¥/M Claude Opus 4.7 $5 / $25 ¥12 / ¥60 ¥1.20 ¥15.00 ¥24.00 核心优势在内部汇率：官方 API 按市场汇率约¥7.2/$换算，灵眸只收¥2.4/$，相当于充值金额打了 3.3 折，实际是官方价格的 33 折左右 。 充值方式 ：只支持微信支付 延迟：这几个平台里最低的 看域名就能判断——服务器在国内。其他平台大多把请求转发到境外节点再回来，延迟叠了好几层；灵眸的链路明显短，实测首 token 响应比其他平台快一截，Claude Code 这种高频交互场景下体感差异很明显。至于他们怎么在国内服务器上跑通 Anthropic API 的，我没深究，反正结果是这几个平台里延迟最低的一个。 Claude Code 实测体验 ： 接入方式很简单，直接设 ANTHROPIC_API_URL 即可，文档有详细步骤。用下来没遇到过 502 ，稳定性在这几个平台里也属于第一梯队。 重点： 支持 Cache Write 5 分钟和 1 小时两档缓存 。对 Claude Code 来说，系统提示词会反复携带，每次请求如果不走缓存就全额计费；有缓存的情况下，读取费用只有写入的一小部分，长期用下来成本差距非常显著。 另一个让我信任这个平台的细节： 明确标注了模型版本和更新日期 。这个行业有平台会悄悄把 Sonnet 替换成 Haiku ，或者用国产模型假冒 Claude ，标注时间起码说明平台不怕被验证。 缺点 ：文档也不健全——配置文档的入口藏在平台内部，从官网首页根本找不到；进去之后内容也比较简单，对第一次配置 Claude Code 的人不够友好。 2. 神马中转 API ⭐⭐⭐⭐ 聚合型平台，最大卖点是 650+模型 ，Claude 之外还覆盖 GPT 、Gemini 等几乎所有主流模型。 价格 （ 2026 年 4 月数据，内部汇率¥2/$）： 模型 官方定价$/M 实际¥/M （汇率 2 ） Cache 读¥/M 写入 5m¥/M 写入 1h¥/M Claude Opus 4.7 $5 / $25 ¥10 / ¥50 ¥1.00 ¥12.50 ¥20.00 内部汇率¥2/$，充¥100 相当于$50 额度，对比市场汇率约合 2.8 折 。 网络情况 ：域名无国内备案，服务器在境外。国内不同地区、不同运营商的访问质量差异较大，部分网络环境下延迟明显，偶发连接不稳定。没有灵眸那种"国内直连"的体感。 Claude Code 兼容性 ：平台支持 API 调用，缓存支持情况官网未详细说明，本文以官网标注价格估算，实际使用建议自行验证。 适合场景 ： 同时需要 Claude + GPT + Gemini 多模型的开发者，一个 Key 搞定 只用 Claude 但对价格敏感，性价比也很高 我的顾虑 ：650+模型的质量难以逐一验证，Claude 部分测试没发现明显掺假，但其他模型存疑。模型多也意味着平台资源分散，维护压力大。 3. PackyAPI ⭐⭐⭐ 价格 （ 2026 年 4 月数据，内部汇率¥1/$）： 模型 官方定价$/M 实际¥/M （汇率 1 ） Cache 读¥/M 写入 5m¥/M 写入 1h¥/M Claude Opus 4.7 $30 / $150 ¥30 / ¥150 ¥1.20 ¥15.00 ¥10.00 必须说清楚——逆向接口是什么 ： PackyAPI 的低价来源是 逆向接口 ，不是官方 API 。他们通过反代 Kiro 、Cursor 、GitHub Copilot 等工具的内部接口，让你"借用"这些平台的 Claude 能力。这是目前市场上低价平台的常见技术路线。 逆向接口的核心问题： 隐性系统提示词 ：你发出的请求会被注入 Cursor 、Kiro 等客户端的内置提示词。你以为在用裸 Claude ，实际上模型已经被预设了某些行为——对 Claude Code 有一定影响，Claude Code 本身对系统提示词比较敏感 稳定性存在根本风险 ：Anthropic 每次更新模型或收紧接口，逆向通路就可能大面积失效。平台来不及修复的窗口期，你的服务直接中断 不支持 Prompt Caching ：官方 API 的缓存功能可以把 Claude Code 的实际成本降低 50%-70%，逆向接口没有这个能力。表面上看价格低，算上缓存收益差距后未必便宜 网络情况 ：域名无国内备案，服务器在境外。和其他境外平台一样，部分地区、部分运营商访问延迟高，网络抖动时请求超时概率更大——而逆向接口本身稳定性就弱，网络再加一层不确定性，体感会更差。 结论 ：预算极度有限、可以接受随时中断的个人开发者可以尝试。生产环境不建议。 4. poloapi ⭐⭐⭐ 价格 （ 2026 年 4 月数据，内部汇率¥7/$，官方 93 折）： | 模型 | 官方定价$/M | poloapi$/M | 实际¥/M （汇率 7 ） | Cache 读¥/M | 写入 5m¥/M | 写入 1h¥/M | | --------------- | -------------- | -------------- | -------------------- | ---------- | --------- | --------- | | Claude Opus 4.7 | $5.00 / $25.00 | $4.70 / $23.30 | ¥32.90 / ¥163.10 | ¥3.29 | ¥40.60 | ¥70.00 | 官方 93 折，官方 API 正规转发，非逆向接口，模型真实性有保证。汇率按市场价¥7/$，无低汇率优势，主要胜在价格透明、稳定。 网络情况 ：域名无国内备案，服务器在境外。国内直连延迟视运营商和地区而定，部分地区体验正常，部分地区高峰期有明显延迟。 Claude Code 兼容性 ：支持 ANTHROPIC_API_URL 接入，支持 Prompt Caching 。 适合谁 ：对平台可靠性有要求、能接受市场汇率的开发者或团队。 5. laozhang.ai ⭐⭐⭐ 目前知名度最高的中文 Claude API 中转平台，是很多人入坑的第一站。 价格 （ 2026 年 4 月数据，内部汇率¥7/$，官方同价）： 模型 官方定价$/M 实际¥/M （汇率 7 ） Cache 读¥/M 写入 5m¥/M 写入 1h¥/M Claude Opus 4.7 $5.00 / $25.00 ¥35.00 / ¥175.00 ¥3.50 ¥43.75 70.00 Claude Sonnet 4.6 $3.00 / $15.00 ¥21.00 / ¥105.00 ¥2.10 — — Claude Haiku 4.5 $1.00 / $5.00 ¥7.00 / ¥35.00 ¥0.70 — — 价格与官方完全持平，无折扣，只是提供了国内可访问的中转通道。注册赠送$0.5 额度，支持支付宝/微信。 Claude Code 兼容性 ：支持 API 接入，缓存支持情况官方未详细披露，本文以官网标注价格估算。 网络情况 ：域名无国内备案，服务器在境外。国内不同运营商体验差异明显，电信/联通相对好，移动用户有时延迟较高。整体属于"境外平台里体验较好的"，但和国内服务器有本质区别。 实测稳定性 ：整体不错，高峰期有时响应慢，偶发 400/500 系列错误。 适合谁 ：刚入坑、需要多模型支持、不想折腾的开发者。价格对标官方，图的是接入便利性。 6. apiyi ⭐⭐⭐ 价格 （ 2026 年 4 月数据，内部汇率¥7/$）： 模型 上下文区间 实际¥/M （汇率 7 ） Cache 读¥/M 写入 5m¥/M Claude Opus 4.7 0–200K ¥35.00 / ¥175.00 ¥3.50 ¥105.00 Claude Opus 4.7 200K–∞ ¥70.00 / ¥262.50 — — 两个明显的坑 ： Cache 写入 5m 高达¥105/M ，是其他平台的 2-3 倍 超过 200K 上下文后输入价格翻倍——Claude Code 单次对话上下文很容易超过这个阈值 网络情况 ：域名无国内备案，服务器在境外。延迟情况与其他境外平台类似，视地区和运营商而定。 Claude Code 兼容性 ：支持 API 接入，缓存支持情况官方未详细披露。 适合谁 ：短上下文、不依赖缓存的轻量任务。重度 Claude Code 用户不推荐。 7. AIHubMix ⭐⭐⭐ 定位偏向中小团队和企业快速验证。 价格 （ 2026 年 4 月数据，内部汇率¥7.1/$，官方同价）： 模型 官方定价$/M 实际¥/M （汇率 7.1 ） Cache 读¥/M 写入 5m¥/M 写入 1h¥/M Claude Opus 4.7 $5.00 / $25.00 ¥35.50 / ¥177.50 ¥3.55 ¥44.38 ¥71.00 Claude Sonnet 4.6 $3.00 / $15.00 ¥21.30 / ¥106.50 ¥2.13 ¥26.63 ¥42.60 网络情况 ：域名无国内备案，服务器在境外。国内访问延迟视运营商和地区而定，整体属于境外平台正常水平，没有国内服务器的直连优势。 Claude Code 兼容性 ：支持 ANTHROPIC_API_URL 接入，明确支持 Prompt Caching （ 5min/1h 两档）。 优点 ：文档和示例代码写得很好，接入快；支持 Web Search （$0.01/次）；客服响应快。 缺点 ：价格与官方持平，没有折扣优势；个人用户性价比不突出。 适合谁 ：需要稳定 SLA 、有联网搜索需求、或需向甲方出示可靠平台来源的团队。 8. OpenRouter]( https://openrouter.ai/ ) ⭐⭐ 国际社区最常被推荐的选项，对国内用户并不友好，放在这里单独说清楚。 价格 （ 2026 年 4 月数据，内部汇率¥7.27/$，官方价格+5%平台费）： 模型 实际¥/M （汇率 7.27 ） Cache 读¥/M 写入 5m¥/M 写入 1h¥/M Claude Opus 4.7 ¥36.35 / ¥181.75 ¥3.64 ¥45.44 ¥72.70 Claude Sonnet 4.6 ¥21.81 / ¥109.05 ¥2.18 ¥27.26 — 网络情况（重点） ：OpenRouter 是这几个平台里网络门槛最高的。服务器在境外，无国内备案，且对国内 IP 主动限制 Claude 系列模型 的访问。也就是说不只是延迟高，直连直接用不了，必须自备稳定的代理工具才能正常使用。代理质量直接决定你的延迟和稳定性——代理节点本身的抖动会叠加进来，体验参差不齐。如果你没有靠谱的梯子，这个平台基本可以排除。 Claude Code 兼容性 ：支持标准 API 接入和 Prompt Caching ，但前提是网络代理稳定。 为什么不推荐国内用户 ： 不支持人民币结算，需要国际信用卡 国内 IP 直连无法访问 Claude 系列，必须自备代理，且代理质量直接影响使用体验 价格比官方还贵约 5%，在国内中转站对比中毫无优势 核心风险预警：这些坑我替你踩过了 坑 1：内部汇率才是真实价格 很多平台挂出的是美元定价，但实际充值时内部汇率直接决定真实成本： 汇率¥2.4/$的平台：充¥100 → $41.7 额度 汇率¥7/$的平台：充¥100 → $14.3 额度 同样充¥100 ，低汇率平台能用的 token 是高汇率平台的近 3 倍。 对比平台时，必须用换算后的¥/M 而不是美元标价来比。 坑 2：逆向接口的隐性代价 部分便宜平台（ PackyAPI 等）的低价来自逆向接口，不是官方 API 。使用前需要了解这意味着什么： 隐性提示词注入 ：你的请求会被注入 Cursor 、Kiro 等客户端的内置系统提示词，Claude 已经不是"裸"的状态，对 Claude Code 的行为有一定影响 稳定性存在根本风险 ：Anthropic 一更新接口，逆向通路可能直接失效，平台来不及修复期间服务中断 缓存功能缺失 ：官方 API 的 Prompt Caching 可以把 Claude Code 实际成本降低 50%-70%，逆向平台没有这个能力。表面价格低，算上缓存差距后不一定便宜 坑 3：模型掺假（最常见，也最难发现） 有研究者用标准测试集（ AIME 2025 、GPQA 等）对比了正规 Claude 和中转站 Claude ，部分中转站模型在数学推理题上准确率下降高达 40%。 简单自测方法 ： 问 Claude 特有的行为问题（比如"你是哪个模型，训练截止日期是"） 用有标准答案的数学题测试，对比官方 Claude 回答 关注响应风格——Claude 有特定写作习惯，国产模型差异明显 坑 4：数据安全 Claude Code 在工作时会读取你本地大量文件内容，通过中转站传输时，这些内容在技术上是中转站可以看到的。个人项目影响不大，企业生产环境建议评估风险后使用可信平台或自建中转。 选择建议 个人开发者，主用 Claude Code ，预算有限 → 灵眸 AI （内部汇率¥2.4/$，加权均价¥45.6/M ，约为官方价格的 1/3 ，且支持缓存） 需要 Claude + GPT + Gemini 多模型切换 → 神马中转 API （低汇率+多模型聚合） 对价格极度敏感，可以接受不稳定 → PackyAPI （逆向接口，最便宜，但要接受随时可能中断，且缓存功能缺失） 需要平台可靠性，不想折腾 → laozhang.ai 或 AIHubMix （官方同价，稳定，文档好） 企业生产环境 → 直接用官方 API ，或找有 SLA 保证的商业平台 国际用户，有美元信用卡 → OpenRouter （模型原厂，体验好，但需代理且比官方贵） 最后说一句 中转站这个行业水很深，价格越低，背后的猫腻往往越多。 选择时我的核心原则只有三个： 不要大额充值 ，用多少充多少 看内部汇率而非美元标价 ，换算成¥/M 才是真实成本 验证模型真实性 ，上线前用测试集跑一遍 如果有其他平台用过觉得不错或者踩坑的，欢迎评论区分享，我会持续更新这篇对比。 附件：最后统一说下 Claude Code 配置方法 以下以我在用的灵眸 AI 为例，介绍两种接入 Claude Code 的配置方式，其他的平台也一样，换一下 ANTHROPIC_BASE_URL 和 ANTHROPIC_AUTH_TOKEN 就可以。 方法一：settings.json 配置（推荐） 编辑 ~/.claude/settings.json 文件，加入以下内容： { "env": { "ANTHROPIC_BASE_URL": "https://clawapi.fulitimes.com/", "ANTHROPIC_AUTH_TOKEN": "sk-08b160d34*****************2c1", "CLAUDE_CODE_ATTRIBUTION_HEADER": "0" }, "effortLevel": "medium" } 如果配置某个国产模型 { "env": { "ANTHROPIC_BASE_URL": "https://clawapi.fulitimes.com/", "ANTHROPIC_AUTH_TOKEN": "sk-08b160d34*****************2c1", "CLAUDE_CODE_ATTRIBUTION_HEADER": "0" }, "model": "glm-5", "effortLevel": "medium" } ANTHROPIC_AUTH_TOKEN 替换为你在灵眸 AI 平台获取的 API Key 。 启动 Claude Code 后，手动激活默认模型： /model glm-5 方法二：环境变量配置 在 shell 配置文件（ ~/.zshrc 或 ~/.bashrc ）中添加以下环境变量，避免每次手动激活： export ANTHROPIC_MODEL=glm-5 export ANTHROPIC_BASE_URL="https://clawapi.fulitimes.com/" export ANTHROPIC_AUTH_TOKEN="sk-08b160d34*****************2c1" 保存后执行 source ~/.zshrc （或重开终端），之后直接运行 claude 即可。 免责声明 ：中转平台受技术更新、接口封控、汇率调整等因素影响，价格和服务状态变化较快。本文数据来源于 2026 年 4 月的实测，具有一定时效性，不代表最终结果，仅供参考。建议以各平台官网实时公示的价格为准，充值前务必自行验证。 测试时间：2026 年 4 月 测试模型：Claude Opus 4.7 如发现数据有误，欢迎指正
本人：个人开发者，Claude Code 重度使用者，Token 重度成瘾患者，下面测评耗时 1 周 长期重度使用 Claude API ，期间换过好几个中转站，有被坑过的，也有用得很顺的。 抽空系统整理了一下，把市面上主流的 8 个平台都拉出来横向对比了一遍。写这篇文章的原因很简单：网上的评测要么是广告软文，要么信息严重过时，很少有人老老实实把价格、踩坑、模型真实性一起说清楚的。 这篇尽量客观，把我测出来的数据直接给你，自己判断。 先说结论（不想看细节的直接看这里） 以下价格基于 Claude Opus 4.7 ，加权均价按输入 30% / 输出 70%计算，单位¥/百万 token 平台 汇率¥/$ 输入¥/M 输出¥/M Cache 读¥/M 写入 5m¥/M 写入 1h¥/M 加权均价¥/M 支持 Claude Code 灵眸 AI 2.4 12.00 60.00 1.20 15.00 24.00 45.60 ✅ 神马中转 API 2 20.00 100.00 1.00 12.50 20.00 76.00 ❌ 缓存不详，以官网值计算 PackyAPI 1 30.00 150.00 1.20 15.00 10.00 114.00 ✅ poloapi 7 32.90 163.10 3.29 40.60 70.00 124.04 ✅ laozhang.ai 7 35.00 175.00 3.50 43.75 70.00 133.00 ❌ 缓存不详，以官网值计算 apiyi 7 35.00 175.00 3.50 105.00 70.00 133.00 ❌ 缓存不详，以官网值计算 AIHubMix 7.1 35.50 177.50 3.55 44.38 71.00 134.90 ✅ OpenRouter 7.27 36.35 181.75 3.64 45.44 72.70 138.13 ✅ （需网络代理） 测试背景和标准 我主要用 Claude 做代码辅助（ Claude Code ）和内容生成，每个月消耗大概在$50-$150 左右。这次评测以 Claude Code 实际使用体验 为核心维度，价格之外也看稳定性和缓存支持——因为对 Claude Code 来说，缓存直接影响真实成本。 测试标准： 价格 ：相同模型（ Claude Opus 4.7 ），统一换算为¥/M 后横向对比 汇率逻辑 ：中转平台把人民币按内部汇率换成美元额度，系统按美元计费扣除。内部汇率决定了你充值¥100 实际能用多少 token Claude Code 兼容性 ：能否直接设置 ANTHROPIC_API_URL 接入，缓存（ Prompt Caching ）是否支持 模型真实性 ：验证输出质量，判断是否被替换或注入提示词 稳定性 ：一个月内 502/400 系列等报错频率 逐个评测 1. 灵眸 AI ⭐⭐⭐⭐⭐ 我目前主用的平台，Claude Code 重度场景首选。 价格 （ 2026 年 4 月数据，内部汇率¥2.4/$）： 模型 官方定价$/M 实际¥/M （汇率 2.4 ） Cache 读¥/M 写入 5m¥/M 写入 1h¥/M Claude Opus 4.7 $5 / $25 ¥12 / ¥60 ¥1.20 ¥15.00 ¥24.00 核心优势在内部汇率：官方 API 按市场汇率约¥7.2/$换算，灵眸只收¥2.4/$，相当于充值金额打了 3.3 折，实际是官方价格的 33 折左右 。 充值方式 ：只支持微信支付 延迟：这几个平台里最低的 看域名就能判断——服务器在国内。其他平台大多把请求转发到境外节点再回来，延迟叠了好几层；灵眸的链路明显短，实测首 token 响应比其他平台快一截，Claude Code 这种高频交互场景下体感差异很明显。至于他们怎么在国内服务器上跑通 Anthropic API 的，我没深究，反正结果是这几个平台里延迟最低的一个。 Claude Code 实测体验 ： 接入方式很简单，直接设 ANTHROPIC_API_URL 即可，文档有详细步骤。用下来没遇到过 502 ，稳定性在这几个平台里也属于第一梯队。 重点： 支持 Cache Write 5 分钟和 1 小时两档缓存 。对 Claude Code 来说，系统提示词会反复携带，每次请求如果不走缓存就全额计费；有缓存的情况下，读取费用只有写入的一小部分，长期用下来成本差距非常显著。 另一个让我信任这个平台的细节： 明确标注了模型版本和更新日期 。这个行业有平台会悄悄把 Sonnet 替换成 Haiku ，或者用国产模型假冒 Claude ，标注时间起码说明平台不怕被验证。 缺点 ：文档也不健全——配置文档的入口藏在平台内部，从官网首页根本找不到；进去之后内容也比较简单，对第一次配置 Claude Code 的人不够友好。 2. 神马中转 API ⭐⭐⭐⭐ 聚合型平台，最大卖点是 650+模型 ，Claude 之外还覆盖 GPT 、Gemini 等几乎所有主流模型。 价格 （ 2026 年 4 月数据，内部汇率¥2/$）： 模型 官方定价$/M 实际¥/M （汇率 2 ） Cache 读¥/M 写入 5m¥/M 写入 1h¥/M Claude Opus 4.7 $5 / $25 ¥10 / ¥50 ¥1.00 ¥12.50 ¥20.00 内部汇率¥2/$，充¥100 相当于$50 额度，对比市场汇率约合 2.8 折 。 网络情况 ：域名无国内备案，服务器在境外。国内不同地区、不同运营商的访问质量差异较大，部分网络环境下延迟明显，偶发连接不稳定。没有灵眸那种"国内直连"的体感。 Claude Code 兼容性 ：平台支持 API 调用，缓存支持情况官网未详细说明，本文以官网标注价格估算，实际使用建议自行验证。 适合场景 ： 同时需要 Claude + GPT + Gemini 多模型的开发者，一个 Key 搞定 只用 Claude 但对价格敏感，性价比也很高 我的顾虑 ：650+模型的质量难以逐一验证，Claude 部分测试没发现明显掺假，但其他模型存疑。模型多也意味着平台资源分散，维护压力大。 3. PackyAPI ⭐⭐⭐ 价格 （ 2026 年 4 月数据，内部汇率¥1/$）： 模型 官方定价$/M 实际¥/M （汇率 1 ） Cache 读¥/M 写入 5m¥/M 写入 1h¥/M Claude Opus 4.7 $30 / $150 ¥30 / ¥150 ¥1.20 ¥15.00 ¥10.00 必须说清楚——逆向接口是什么 ： PackyAPI 的低价来源是 逆向接口 ，不是官方 API 。他们通过反代 Kiro 、Cursor 、GitHub Copilot 等工具的内部接口，让你"借用"这些平台的 Claude 能力。这是目前市场上低价平台的常见技术路线。 逆向接口的核心问题： 隐性系统提示词 ：你发出的请求会被注入 Cursor 、Kiro 等客户端的内置提示词。你以为在用裸 Claude ，实际上模型已经被预设了某些行为——对 Claude Code 有一定影响，Claude Code 本身对系统提示词比较敏感 稳定性存在根本风险 ：Anthropic 每次更新模型或收紧接口，逆向通路就可能大面积失效。平台来不及修复的窗口期，你的服务直接中断 不支持 Prompt Caching ：官方 API 的缓存功能可以把 Claude Code 的实际成本降低 50%-70%，逆向接口没有这个能力。表面上看价格低，算上缓存收益差距后未必便宜 网络情况 ：域名无国内备案，服务器在境外。和其他境外平台一样，部分地区、部分运营商访问延迟高，网络抖动时请求超时概率更大——而逆向接口本身稳定性就弱，网络再加一层不确定性，体感会更差。 结论 ：预算极度有限、可以接受随时中断的个人开发者可以尝试。生产环境不建议。 4. poloapi ⭐⭐⭐ 价格 （ 2026 年 4 月数据，内部汇率¥7/$，官方 93 折）： | 模型 | 官方定价$/M | poloapi$/M | 实际¥/M （汇率 7 ） | Cache 读¥/M | 写入 5m¥/M | 写入 1h¥/M | | --------------- | -------------- | -------------- | -------------------- | ---------- | --------- | --------- | | Claude Opus 4.7 | $5.00 / $25.00 | $4.70 / $23.30 | ¥32.90 / ¥163.10 | ¥3.29 | ¥40.60 | ¥70.00 | 官方 93 折，官方 API 正规转发，非逆向接口，模型真实性有保证。汇率按市场价¥7/$，无低汇率优势，主要胜在价格透明、稳定。 网络情况 ：域名无国内备案，服务器在境外。国内直连延迟视运营商和地区而定，部分地区体验正常，部分地区高峰期有明显延迟。 Claude Code 兼容性 ：支持 ANTHROPIC_API_URL 接入，支持 Prompt Caching 。 适合谁 ：对平台可靠性有要求、能接受市场汇率的开发者或团队。 5. laozhang.ai ⭐⭐⭐ 目前知名度最高的中文 Claude API 中转平台，是很多人入坑的第一站。 价格 （ 2026 年 4 月数据，内部汇率¥7/$，官方同价）： 模型 官方定价$/M 实际¥/M （汇率 7 ） Cache 读¥/M 写入 5m¥/M 写入 1h¥/M Claude Opus 4.7 $5.00 / $25.00 ¥35.00 / ¥175.00 ¥3.50 ¥43.75 70.00 Claude Sonnet 4.6 $3.00 / $15.00 ¥21.00 / ¥105.00 ¥2.10 — — Claude Haiku 4.5 $1.00 / $5.00 ¥7.00 / ¥35.00 ¥0.70 — — 价格与官方完全持平，无折扣，只是提供了国内可访问的中转通道。注册赠送$0.5 额度，支持支付宝/微信。 Claude Code 兼容性 ：支持 API 接入，缓存支持情况官方未详细披露，本文以官网标注价格估算。 网络情况 ：域名无国内备案，服务器在境外。国内不同运营商体验差异明显，电信/联通相对好，移动用户有时延迟较高。整体属于"境外平台里体验较好的"，但和国内服务器有本质区别。 实测稳定性 ：整体不错，高峰期有时响应慢，偶发 400/500 系列错误。 适合谁 ：刚入坑、需要多模型支持、不想折腾的开发者。价格对标官方，图的是接入便利性。 6. apiyi ⭐⭐⭐ 价格 （ 2026 年 4 月数据，内部汇率¥7/$）： 模型 上下文区间 实际¥/M （汇率 7 ） Cache 读¥/M 写入 5m¥/M Claude Opus 4.7 0–200K ¥35.00 / ¥175.00 ¥3.50 ¥105.00 Claude Opus 4.7 200K–∞ ¥70.00 / ¥262.50 — — 两个明显的坑 ： Cache 写入 5m 高达¥105/M ，是其他平台的 2-3 倍 超过 200K 上下文后输入价格翻倍——Claude Code 单次对话上下文很容易超过这个阈值 网络情况 ：域名无国内备案，服务器在境外。延迟情况与其他境外平台类似，视地区和运营商而定。 Claude Code 兼容性 ：支持 API 接入，缓存支持情况官方未详细披露。 适合谁 ：短上下文、不依赖缓存的轻量任务。重度 Claude Code 用户不推荐。 7. AIHubMix ⭐⭐⭐ 定位偏向中小团队和企业快速验证。 价格 （ 2026 年 4 月数据，内部汇率¥7.1/$，官方同价）： 模型 官方定价$/M 实际¥/M （汇率 7.1 ） Cache 读¥/M 写入 5m¥/M 写入 1h¥/M Claude Opus 4.7 $5.00 / $25.00 ¥35.50 / ¥177.50 ¥3.55 ¥44.38 ¥71.00 Claude Sonnet 4.6 $3.00 / $15.00 ¥21.30 / ¥106.50 ¥2.13 ¥26.63 ¥42.60 网络情况 ：域名无国内备案，服务器在境外。国内访问延迟视运营商和地区而定，整体属于境外平台正常水平，没有国内服务器的直连优势。 Claude Code 兼容性 ：支持 ANTHROPIC_API_URL 接入，明确支持 Prompt Caching （ 5min/1h 两档）。 优点 ：文档和示例代码写得很好，接入快；支持 Web Search （$0.01/次）；客服响应快。 缺点 ：价格与官方持平，没有折扣优势；个人用户性价比不突出。 适合谁 ：需要稳定 SLA 、有联网搜索需求、或需向甲方出示可靠平台来源的团队。 8. OpenRouter]( https://openrouter.ai/ ) ⭐⭐ 国际社区最常被推荐的选项，对国内用户并不友好，放在这里单独说清楚。 价格 （ 2026 年 4 月数据，内部汇率¥7.27/$，官方价格+5%平台费）： 模型 实际¥/M （汇率 7.27 ） Cache 读¥/M 写入 5m¥/M 写入 1h¥/M Claude Opus 4.7 ¥36.35 / ¥181.75 ¥3.64 ¥45.44 ¥72.70 Claude Sonnet 4.6 ¥21.81 / ¥109.05 ¥2.18 ¥27.26 — 网络情况（重点） ：OpenRouter 是这几个平台里网络门槛最高的。服务器在境外，无国内备案，且对国内 IP 主动限制 Claude 系列模型 的访问。也就是说不只是延迟高，直连直接用不了，必须自备稳定的代理工具才能正常使用。代理质量直接决定你的延迟和稳定性——代理节点本身的抖动会叠加进来，体验参差不齐。如果你没有靠谱的梯子，这个平台基本可以排除。 Claude Code 兼容性 ：支持标准 API 接入和 Prompt Caching ，但前提是网络代理稳定。 为什么不推荐国内用户 ： 不支持人民币结算，需要国际信用卡 国内 IP 直连无法访问 Claude 系列，必须自备代理，且代理质量直接影响使用体验 价格比官方还贵约 5%，在国内中转站对比中毫无优势 核心风险预警：这些坑我替你踩过了 坑 1：内部汇率才是真实价格 很多平台挂出的是美元定价，但实际充值时内部汇率直接决定真实成本： 汇率¥2.4/$的平台：充¥100 → $41.7 额度 汇率¥7/$的平台：充¥100 → $14.3 额度 同样充¥100 ，低汇率平台能用的 token 是高汇率平台的近 3 倍。 对比平台时，必须用换算后的¥/M 而不是美元标价来比。 坑 2：逆向接口的隐性代价 部分便宜平台（ PackyAPI 等）的低价来自逆向接口，不是官方 API 。使用前需要了解这意味着什么： 隐性提示词注入 ：你的请求会被注入 Cursor 、Kiro 等客户端的内置系统提示词，Claude 已经不是"裸"的状态，对 Claude Code 的行为有一定影响 稳定性存在根本风险 ：Anthropic 一更新接口，逆向通路可能直接失效，平台来不及修复期间服务中断 缓存功能缺失 ：官方 API 的 Prompt Caching 可以把 Claude Code 实际成本降低 50%-70%，逆向平台没有这个能力。表面价格低，算上缓存差距后不一定便宜 坑 3：模型掺假（最常见，也最难发现） 有研究者用标准测试集（ AIME 2025 、GPQA 等）对比了正规 Claude 和中转站 Claude ，部分中转站模型在数学推理题上准确率下降高达 40%。 简单自测方法 ： 问 Claude 特有的行为问题（比如"你是哪个模型，训练截止日期是"） 用有标准答案的数学题测试，对比官方 Claude 回答 关注响应风格——Claude 有特定写作习惯，国产模型差异明显 坑 4：数据安全 Claude Code 在工作时会读取你本地大量文件内容，通过中转站传输时，这些内容在技术上是中转站可以看到的。个人项目影响不大，企业生产环境建议评估风险后使用可信平台或自建中转。 选择建议 个人开发者，主用 Claude Code ，预算有限 → 灵眸 AI （内部汇率¥2.4/$，加权均价¥45.6/M ，约为官方价格的 1/3 ，且支持缓存） 需要 Claude + GPT + Gemini 多模型切换 → 神马中转 API （低汇率+多模型聚合） 对价格极度敏感，可以接受不稳定 → PackyAPI （逆向接口，最便宜，但要接受随时可能中断，且缓存功能缺失） 需要平台可靠性，不想折腾 → laozhang.ai 或 AIHubMix （官方同价，稳定，文档好） 企业生产环境 → 直接用官方 API ，或找有 SLA 保证的商业平台 国际用户，有美元信用卡 → OpenRouter （模型原厂，体验好，但需代理且比官方贵） 最后说一句 中转站这个行业水很深，价格越低，背后的猫腻往往越多。 选择时我的核心原则只有三个： 不要大额充值 ，用多少充多少 看内部汇率而非美元标价 ，换算成¥/M 才是真实成本 验证模型真实性 ，上线前用测试集跑一遍 如果有其他平台用过觉得不错或者踩坑的，欢迎评论区分享，我会持续更新这篇对比。 附件：最后统一说下 Claude Code 配置方法 以下以我在用的灵眸 AI 为例，介绍两种接入 Claude Code 的配置方式，其他的平台也一样，换一下 ANTHROPIC_BASE_URL 和 ANTHROPIC_AUTH_TOKEN 就可以。 方法一：settings.json 配置（推荐） 编辑 ~/.claude/settings.json 文件，加入以下内容： { "env": { "ANTHROPIC_BASE_URL": "https://clawapi.fulitimes.com/", "ANTHROPIC_AUTH_TOKEN": "sk-08b160d34*****************2c1", "CLAUDE_CODE_ATTRIBUTION_HEADER": "0" }, "effortLevel": "medium" } 如果配置某个国产模型 { "env": { "ANTHROPIC_BASE_URL": "https://clawapi.fulitimes.com/", "ANTHROPIC_AUTH_TOKEN": "sk-08b160d34*****************2c1", "CLAUDE_CODE_ATTRIBUTION_HEADER": "0" }, "model": "glm-5", "effortLevel": "medium" } ANTHROPIC_AUTH_TOKEN 替换为你在灵眸 AI 平台获取的 API Key 。 启动 Claude Code 后，手动激活默认模型： /model glm-5 方法二：环境变量配置 在 shell 配置文件（ ~/.zshrc 或 ~/.bashrc ）中添加以下环境变量，避免每次手动激活： export ANTHROPIC_MODEL=glm-5 export ANTHROPIC_BASE_URL="https://clawapi.fulitimes.com/" export ANTHROPIC_AUTH_TOKEN="sk-08b160d34*****************2c1" 保存后执行 source ~/.zshrc （或重开终端），之后直接运行 claude 即可。 免责声明 ：中转平台受技术更新、接口封控、汇率调整等因素影响，价格和服务状态变化较快。本文数据来源于 2026 年 4 月的实测，具有一定时效性，不代表最终结果，仅供参考。建议以各平台官网实时公示的价格为准，充值前务必自行验证。 测试时间：2026 年 4 月 测试模型：Claude Opus 4.7 如发现数据有误，欢迎指正
重新发一下 当今世界，AI 正在以一种匪夷所思的速度发展，工具多的眼花缭乱，从 prompt 技巧到 RAG，从 agent 到 MCP，到如今的 harness，这些“名词”混乱到让人感到焦虑，每一波浪潮都在说自己是“真正的答案”，上一波就被理所当然的贬为“过时的东西”。 我认为，看懂这条时间线比学会任何一个工具都要重要。这篇文章想做的，是沿着时间线把每一波浪潮拆开：当时人们遇到了什么问题？根源是什么？解决它的过程中又出现了什么新问题？最后回到一个根本性的问题——作为 AI 使用者，我们该如何在这片工具废土里找到适合自己的路？ 2022：Prompt Engineering 初露锋芒 2022 年 1 月，Google Brain 的 Wei 等人发表了 Chain-of-Thought ，证明了一个在现在来看就是废话的问题：如果你让模型把推理步骤一步一步写出来，他在多步问题上的表现会显著提高。 几个月后 ChatGPT 问世，人们在接触的过程中意识到“怎么跟模型说话”也是一门学问 今天回过头来看，prompt engineering 似乎有更深刻的意义，表面上来看，few-shot、chain-of-thought，role prompting 这些“技巧集合”有效。但是仔细想想你会发现，它们都是逼着使用者把一个模糊的问题变为模型能确切理解的指令，或者更直白来讲，它们通过结构化输出，把“人没有把问题想清楚”这个根本性问题绕过去 这个阶段留下来了一个最核心的理念： 你的表达精度本身就是一种生产力，同时也决定了模型的能力上下限 2022年底到2023：推理是可以被“拉长”的 Chain-of-Thought 证明了推理步骤的效果之后，有一个论点可以被轻松的引申出来：如果模型把逐步推理变为多步推理或者是树状搜索，图状搜索，会不会表现更好？ 2023 年初，Yao 提出的 Tree-of-Thought 给出了肯定答案。他让模型在每一步都枚举多个可能的思路，然后用搜索算法遍历这棵思维树。 从表面上来看，这一阶段仍处于 prompt engineering 的影响下，但是他传递出来一个新的信号方向： 模型推理能力并不是一个静态的量，它会受到外部结构的设计影响，不同的设计会出现不同的效果 现在的模型变聪明了，其实不准确，在不断优化的结构下，模型能表现出的推理水平其实比它在单轮对话里面展现的要高得多，ToT 和 GoT 本身并没有直接成为今天主流 agent 架构的骨架（后者更多是 CoT 加工具调用的结合体），但是这个阶段留下来一条重要的认知，这条认知也在后面被反复验证，也是 harness 的雏形： 怎么围绕模型搭一个好的工作流程，常常比选什么模型更决定结果。 2023：RAG 和 agent，初探外部世界 到了 2023 年，人们开始遇到了 prompt 层面解决不了的问题：模型不知道你公司的文档，不知道今天的新闻，看不到数据库，也不能执行代码，你把 prompt 调到天上也没用。 这时候出现了两条路。一条是 RAG（Retrieval-Augmented Generation）：模型在回答之前先去搜索相关文档，把结果放到上下文中。另一条是 agent + tool use：模型去调用外部工具，自主去搜索、执行、查询。 2023 年 Yao 的 ReAct 论文把这两条路缝合在一起：模型交替去思考和行动，先去推理下一步需要做什么，然后调用工具去获取信息，根据结果继续推理行动。同年 6 月份，OpenAI 推出了 function calling，他把 agent 能力下沉到了 API 层，LangChain 顺势成为了构建 agent 系统的标准框架 这一个阶段问题很明确：模型的智能被它的"信息封闭"严重限制了。训练数据截止之后的事它不知道，你桌面上的文件它也看不到，生产环境的数据库它更连接不上。 但是又出现了新的问题：每接入一个工具都要写自定义集成，每个框架有自己的一套约定，不同模型供应商的 function calling 格式不一样，同一个能力在 LangChain 里是一种写法、在自研系统里又是另一种。工具越多，维护成本呈平方级增长。这个问题后来被 MCP 的正式命名为 N×M 集成问题——N 个模型、M 个工具，每一对组合都可能要写一遍。 2024：MCP的必然 2024 年 11 月，Anthropic 发布了 Model Context Protocol（MCP），它们定义了一套协议，让工具提供方只实现一次 MCP 服务端，客户端只对接 MCP 规范，就能连上生态里任何遵循该协议的工具，他们将 agent 接入外部工具的方式标准化了 MCP 在短短一年内，就已经扩展到了这一代 agent 的工具底座。到 2025 年末已经有超过 75 个连接器直接挂在 Claude 上，MCP 的 Python 和 TypeScript SDK 每月下载量合计超过 9700 万。 MCP 解决的问题不在"怎么用 AI"这一侧，而在"怎么让 AI 的使用不重复造轮子"。 2025：Context engineering，上下文的讨论 到了 2025 年之后，一个反直觉的事实开始被人们认可： 上下文窗口并不是越大越好 早期人们认为，如果模型能看到 100 万 token，那就把所有可能相关的东西都塞进去，让模型自己挑所需要的内容。 但当 Context 超过了某个阈值，模型从长上下文中准确召回信息的能力会下降，解决问题的能力反而会降低，这种现象被称之为“Context rot”。 SWE-rebench 的维护者观察到模型性能在某个上下文长度附近会撞上一道硬墙，再往后不管上下文最多支持都会明显劣化。塞得越多，模型越走神，幻觉现象越严重。Databricks 的一项研究甚至在 32K token 附近就观测到了明显的精度下降。 这个现象引出了 context engineering 的概念。2025 年 9 月，Anthropic 在官方工程博客里把它称之为 prompt engineering 的自然延续，把焦点从"如何写一条指令"转到"如何配置模型在每一步推理时能看到的信息"。同时期，Gartner 发布报告称 prompt engineering 正在被 context engineering 取代；Andrej Karpathy 和 Shopify 的 Tobi Lütke 也在社交媒体上公开支持这个转向。 模型的注意力是有限的。和人一样，给它看的东西越多，它能给每一部分的关注就越少。好的使用方式不是最大化信息输入，是精准地给它最少但最必要的信息。和 prompt engineering 时代的"把话说清楚"是同一条原理在不同尺度上的体现——当年是一句话的精度，现在是整个上下文窗口的精度。 现在：Harness 是让模型能"做事"的基础设施 走到 2025 年底、2026 年初，我们来到了目前这个阶段——称之为harness 时代。Claude Code、Cursor、Codex 这些工具被统称为 harness，它们给一个只能“说话”的模型更多的“手”，赋予它更大的“权力”：文件系统访问、shell 执行、工具调用原语、权限和确认机制、错误回退、长任务的状态编排、多 agent 之间的协调通道、跨会话的记忆文件。 语言模型本身只能产出 token，harness 负责把这些 token 翻译成对真实世界的动作，再把真实世界的反馈翻译成模型能理解的输入。 harness 去解决的问题也是前几代自己产生的。现在的agent 能力足够强、工具链足够完备、上下文管理足够讲究之后，单纯的"模型 + 几个工具"已经不够用，你需要一个能让模型在真实环境里持续工作的运行时。它自主要决定什么操作需要用户点头、什么可以静默执行；要在工具失败时选择重试还是回退；要把一个长任务拆分成子 agent 并回收它们的结果；要在会话中断后恢复到接近中断前的状态。这些需求合起来构成了 harness engineering。 但是 harness 层本身也在迅速制造新的问题。我自己配置过一整套 Claude Code 的定制化设施——全局规则文件、领域规则文件、subagent、slash 命令、跨会话记忆——每一个单独看都挺合理，但组合起来之后，系统的维护成本和认知负担开始吃掉它带来的收益。你花在记忆"每个组件的状态、每个配置的影响范围、每次更新可能的连锁反应"上的时间，开始和它节省的时间打平。 harness 是一把双刃剑： 它让复杂协作成为可能，也让简单任务变得复杂。 贯穿所有阶段的模式 现在站在高处来俯瞰这条路径，你会发现一个清晰的循环结构： 在使用过程中出现了某个瓶颈，然后有人去发明了一套新的方法去解决它，这套方法如果真的有效，就会被采纳变为行业标准。但同时会带来新的问题，等问题积累到一定程度，下一波人又会站出来发明下一套解决方案。 prompt 解决的是"模型不理解你要什么"；推理链解决的是"模型一次想不了那么多"；RAG 和 agent 解决的是"模型不知道/做不了外部的事"；MCP 解决的是"每个工具接入都要重写一遍"；context engineering 解决的是"信息多了反而更糟"；harness 解决的是"模型只能说话，不能在真实环境里做事"。 每一步都是合理的，每一步也都是局部最优。但连起来看，你会意识到没有任何一个阶段是"终极答案"。每一层都在处理上一层的溢出。而那些宣称自己是终极答案的方案，无一例外地在下一两年内被发现有自己的天花板。 对普通使用者来说：如果你不理解一个新名词在解决什么问题，就不要急着采用它。采用一个为解决你还没遇到的问题而设计的工具，是在用复杂度换一个你用不上的能力。 该如何去做？ 面对这条混乱不堪的路，合理的学习策略不是"从下往上把每一层都学一遍"，也不是"只学最新的那一层"。 我们需要确定自己在哪里 方法也不难，你观察自己最近几次和 AI 协作的失败案例，问一个问题：这一次失败，是因为模型误解了我的意图，还是因为模型缺少相关信息，还是因为模型无法调用某个工具或执行某个动作，还是因为任务规模大到单次对话已经撑不住，需要长时运行、权限控制、多个子 agent 分工、跨会话状态？这四个答案分别指向 prompt 层、context 层、agent/tool 层、harness 层。把失败案例分个类，你就知道自己该怎么做了。 其实我认为，大多数人应该在更低的层级上停留更久 工具的门槛不等于它的价值。 很多人看到业界在谈 context engineering 就去学，认为这是"更高级"的东西。但 context engineering 只对那些已经建立了 agent pipeline、并且因为 token 预算在挣扎的人有意义。对一个日常用 AI 写邮件的人来说，context engineering 是过剩的复杂度。 每一次选工具的时候问自己两个问题：这件工具要解决的问题，我已经遇到了吗？如果没有它，我今天的工作会不会卡住？如果两个答案都是"否"，这件工具就不是你现在该学的。它可能很好，但不是你的。 最后我想说的 从 prompt 到 harness 的演化，是一系列针对不同瓶颈的专门解决方案，不是一条从原始到高级的阶梯。它们共同构成了一个工具栈，每一层都在解决具体的问题。 作为使用者，你要做的不是追着每一层的新名词跑，而是搞清楚自己当前撞在哪一层的天花板上，然后精准地在那一层用力。看懂了这个演化逻辑，工具的"混乱"就不再混乱——它只是一张地图，你需要的是知道自己站在哪里。 7 个帖子 - 4 位参与者 阅读完整话题
佬友们好久不见，正本清源系列恢复更新，让咱们直接进入正题，文章较长各位慢慢观看 一个普遍的感受是：AI 工具越来越多，混乱到让人焦虑。昨天学的 prompt 技巧今天已经过时，RAG 还没搞清楚 agent 又冒出来，agent 还没用熟练 MCP 又成了标配，MCP 没摸透 harness 又被推上舞台。每一波浪潮都宣称自己是"真正的答案"，而上一波的东西顺理成章被贬为"过时的玩法"。 但如果你把时间拉长来看这条路径，会发现它不是随机堆积的。它有一个清晰的内在逻辑。每一层新范式都在解决上一层自己制造出来的瓶颈。看懂这个演化路径，比学会任何一个具体工具都重要——因为它决定了你该站在哪一层用力。 这篇文章想做的，是沿着时间线把每一波浪潮拆开：当时人们在和什么问题搏斗？这个问题的根源是什么？解决它的过程又制造了什么新问题？然后回到一个更根本的问题——作为一个 AI 使用者，你该如何学习、该如何优化、该如何在这片工具废土里找到自己的站位。 2022：Prompt 作为一种发现 2022 年 1 月，Google Brain 的 Wei 等人发表了 Chain-of-Thought 论文，证明了一件今天看来近乎废话的事——如果你让模型把推理步骤一步一步写出来，它在多步问题上的表现会显著提升。据 Google 在 PaLM 上的测试，这一简单变化让模型在 GSM8K 数学推理基准上达到了当时的最好成绩。几个月后 ChatGPT 发布，整个世界突然意识到"怎么跟模型说话"是一门可以学的手艺。 但今天回看，prompt engineering 的真正意义不是那些"技巧集合"。few-shot、chain-of-thought、role prompting——这些范式有效的本质原因是它们逼着使用者把一个模糊的问题翻译成精确的指令。它们在做的事情，是把"人没把问题想清楚"这个底层缺陷暴露出来，然后用技巧绕过去。 这个时期真正被验证的，是一个被低估的事实：模型对精确描述的敏感度极高，对模糊表达的容错极低。在这个约束下，任何能让使用者被迫变精确的机制都有效。而这些机制里最有效的那几个，后来被抽象成了可传授的技巧。 这个阶段留下的最大遗产不是某个 prompt 模板，而是一个认知起点——你的表达精度本身就是生产力。但这个认知很快就撞上了它自己的天花板。 2022 年底到 2023：推理是可以被"拉长"的 Chain-of-Thought 证明一件事之后，很自然地衍生出下一个问题：如果让模型把一步推理变成多步有用，那么让它把多步推理变成树状搜索、图状探索，是不是更有用？2023 年初，Yao 等人的 Tree-of-Thought 给出了肯定答案——让模型在每一步都枚举多个可能的"思路"，然后用搜索算法遍历这棵思维树。之后又有 Graph-of-Thought、self-consistency 等一系列变体。 表面上看，这一阶段是 prompt engineering 的深化。但它真正传递的信号是另一件事：模型的推理能力不是一个静态的量，而是一个可以通过外部结构来放大的量。同一个模型，在线性 prompt 下可能答错，在树状 prompt 下可能答对。差别不在模型，在你给它搭的"思考脚手架"。 这个发现的深层含义，到后来才被完整消化——我们看到的不是"模型变聪明了"，是"在适当的结构下，模型能表现出的推理水平比它在单轮对话里显露的要高得多"。ToT 和 GoT 本身并没有直接成为今天主流 agent 架构的骨架——后者更多是 CoT 加工具调用的结合体——但这一阶段留下的那条认知在后来被反复验证：怎么围绕模型搭一个好的工作流程，常常比选什么模型更决定结果。 2023：RAG 和 agent，向外部世界开口 到 2023 年，人们开始撞上 prompt 层面解决不了的问题。模型不知道你公司的文档、不知道今天的新闻、不能查数据库、不能执行代码。你把 prompt 调到天上去也没用，因为它答不出它不知道的事。 两条路同时被走通。一条是 RAG（Retrieval-Augmented Generation）：在生成之前先去检索相关文档，把结果塞进上下文。另一条是 agent + tool use：让模型能调用外部工具，自己去搜索、去执行、去查询。2023 年 Yao 等人的 ReAct 论文把这两件事缝在一起——让模型交替进行"思考"和"行动"，先推理下一步该干什么，再调用工具获取信息，再根据结果继续推理。6 月 OpenAI 推出 function calling，把 agent 能力下沉到 API 层。同年 AutoGPT、CAMEL 等多 agent 实验把这条路推到极端，LangChain 顺势成了构建 agent 系统的事实标准框架。 这一阶段的技术细节很丰富，但内核只有一个问题：模型的智能被它的"信息封闭"严重限制了。训练数据截止之后的事它不知道，你桌面上的文件它看不到，生产环境的数据库它连接不上。解决这个问题需要的不是更好的模型，是更宽的接口。 但这条路走出来之后，马上显露出新的代价。每接入一个工具都要写自定义集成，每个框架有自己的一套约定，不同模型供应商的 function calling 格式不一样，同一个能力在 LangChain 里是一种写法、在自研系统里又是另一种。工具越多，维护成本呈平方级增长。这个问题后来被 MCP 的叙事正式命名为 N×M 集成问题——N 个模型、M 个工具，每一对组合都可能要写一遍。 2024：MCP 是标准化的必然 2024 年 11 月，Anthropic 发布了 Model Context Protocol（MCP），把 agent 接入外部工具的方式标准化了。概念其实很朴素——定义一套协议，让工具提供方只实现一次 MCP 服务端，模型和客户端就都能使用；反过来，客户端只对接 MCP 规范，就能连上生态里任何遵循该协议的工具。这个设计和 Language Server Protocol 的思路是同构的——用一层标准协议把 N×M 问题降维成 N+M。 MCP 推出之后的一年，生态扩展得非常快。Anthropic 官方数据显示，到 2025 年末已经有超过 75 个连接器直接挂在 Claude 上，MCP 的 Python 和 TypeScript SDK 每月下载量合计超过 9700 万。OpenAI、Google DeepMind、Microsoft 相继加入，协议最终被捐给 Linux Foundation 下的 Agentic AI Foundation。它成了这一代 agent 基础设施的公共底座。 MCP 层面真正在解决的问题，其实不是"怎么用 AI"，而是"怎么让 AI 的使用不重复造轮子"。它是一个工程范畴的胜利，不是 AI 能力范畴的胜利。这一点很关键——很多人看到 MCP 被热捧，以为自己也该去学 MCP，但如果你根本还没到需要编排多个工具的阶段，MCP 对你不会产生任何边际价值。它是为那些已经感受到 N×M 疼痛的人准备的。 2025：Context engineering，承认窗口是幻觉 到 2025 年，另一个反直觉的事实开始被广泛接受：上下文窗口不是越大越好。 早期人们默认，如果模型能看到 100 万 token，那就把所有可能相关的东西都塞进去，让模型自己挑。现实是，窗口一旦超过某个阈值，模型从长上下文里准确召回信息的能力反而下降——研究者把这种现象命名为 context rot。SWE-rebench 的维护者观察到模型性能在 100 万 token 附近会撞上一道硬墙，再往后不管窗口技术上支持多少都会明显劣化。塞得越多，模型越走神。Databricks 的一项研究甚至在 32K token 附近就观测到了明显的精度下降。 这个认识直接催生了 context engineering 的概念。2025 年 9 月，Anthropic 在官方工程博客里把它定义为 prompt engineering 的自然延续，关注的焦点从"如何措辞一条指令"变成了"如何配置模型在每一步推理时能看到的信息"。同时期，Gartner 发布报告称 prompt engineering 正在被 context engineering 取代；Andrej Karpathy 和 Shopify 的 Tobi Lütke 在社交媒体上公开支持这个转向。按 DataCamp 的测试数据，合理的上下文管理能在 agent 基准上带来 54% 的性能提升。 这一阶段真正在解决的问题是：模型的注意力是有预算的。和人一样，给它看的东西越多，它能给每一部分的关注就越少。好的使用不是最大化给它的信息，是精准地给它最少但最必要的信息。这和 prompt engineering 时代的"把话说清楚"其实是同一个原理的升级版——当年是一句话的精度，现在是整个上下文窗口的精度。 现在：Harness 是让模型能"做事"的基础设施 走到 2025 年底、2026 年初，我们来到了目前这个阶段——harness 时代。Claude Code、Cursor、Aider 这些工具被统称为 harness，不是因为它们把多次使用串起来，而是因为它们把一个只能"说话"的模型包裹进了一整套"能做事"所需的基础设施：文件系统访问、shell 执行、工具调用原语、权限和确认机制、错误回退、长任务的状态编排、多 agent 之间的协调通道、跨会话的记忆文件。语言模型本身只能产出 token，harness 负责把这些 token 翻译成对真实世界的动作，再把真实世界的反馈翻译成模型能理解的输入。 harness 要解决的问题也是前几代自己制造出来的。agent 能力足够强、工具链足够完备、上下文管理足够讲究之后，单纯的"模型 + 几个工具"已经不够用——你需要一个能让模型在真实环境里持续工作的运行时。它要决定什么操作需要用户点头、什么可以静默执行；要在工具失败时选择重试还是回退；要把一个长任务拆分成子 agent 并回收它们的结果；要在会话中断后恢复到接近中断前的状态。这些需求单独拎出来每一个都不新鲜，合起来才构成 harness 这一层。 但 harness 层本身也在迅速制造下一代问题。我自己配置过一整套 Claude Code 的定制化设施——全局规则文件、领域规则文件、subagent、slash 命令、跨会话记忆——每一个单独看都合理，但组合起来之后，系统的维护成本和认知负担开始吃掉它带来的收益。你花在记忆"每个组件的状态、每个配置的影响范围、每次更新可能的连锁反应"上的时间，开始和它节省的时间打平。harness 是一把双刃剑——它让复杂协作成为可能，也让简单任务变得复杂。 贯穿所有阶段的模式 现在站到高处俯瞰这条路径，会看到一个清晰的循环结构。 每一个时代都是这样的：某个瓶颈暴露出来，有人发明了一套新范式去解决它，这套范式确实有效，于是被广泛采用并成为行业标准。但这套范式在运行过程中必然消耗一些新资源——更多的 token、更多的集成、更多的调用、更多的协调开销。消耗积累到一定程度，就暴露出下一个瓶颈。然后下一波人又站出来，发明下一套范式。 prompt 解决的是"模型不理解你要什么"；推理链解决的是"模型一次想不了那么多"；RAG 和 agent 解决的是"模型不知道/做不了外部的事"；MCP 解决的是"每个工具接入都要重写一遍"；context engineering 解决的是"信息多了反而更糟"；harness 解决的是"模型只能说话，不能直接在真实环境里做事"。 每一步都是合理的，每一步也都是局部最优。但连起来看，你会意识到没有任何一个阶段是"终极答案"。每一层都在处理上一层的溢出。而那些宣称自己是终极答案的范式，无一例外地在下一两年内被发现有自己的天花板。 这给使用者的启示其实很简单：如果你不理解一个新范式在解决什么问题，就不要急着采用它。采用一个为解决你还没遇到的问题而设计的工具，是在用复杂度换一个你用不上的能力。 该如何学习，该如何优化 面对这条路径，合理的学习策略不是"从下往上把每一层都学一遍"，也不是"只学最新的那一层"。合理的策略是先诊断自己的真实瓶颈在哪一层，然后集中学那一层和它相邻的一点。 诊断瓶颈的方法也不复杂。你观察自己最近几次和 AI 协作的失败案例，问一个问题：这一次失败，是因为模型误解了我的意图，还是因为模型缺少相关信息，还是因为模型无法调用某个工具或执行某个动作，还是因为任务规模大到单次对话已经撑不住——需要长时运行、权限控制、多个子 agent 分工、跨会话状态？这四个答案分别指向 prompt 层、context 层、agent/tool 层、harness 层。把失败案例分个类，看分布在哪里集中，你就知道自己该去哪里用力。 一个推论是，大多数人其实应该在更低的层上停留更久。如果你的 AI 使用还处于"偶尔模糊、不知道怎么问"的阶段，你不需要 MCP、不需要 harness、不需要 agent framework——你需要在 prompt 和 context 层练更多次。反过来，如果你已经在每天处理几十个并行任务、需要让 AI 维持跨周的上下文、要协调多个工具链，那么 prompt 技巧对你边际收益极低，你真正该投资的是 harness 和工作流。 还有一个常被忽略的维度——工具的门槛不等于它的价值。很多人看到业界在谈 context engineering 就去学，以为这是"更高级"的东西。但 context engineering 只对那些已经建立了 agent pipeline、并且因为 token 预算在挣扎的人有意义。对一个日常用 AI 写邮件的人来说，context engineering 是过剩的复杂度。 真正重要的，是在每一次工具选择的时候问自己两个问题：这件工具要解决的问题，我已经遇到了吗？如果没有它，我今天的工作会不会真的卡住？如果两个答案都是"否"，这件工具就不是你现在该学的。它可能很好，但不是你的。 一句话 从 prompt 到 harness 的演化，不是一条从原始到高级的阶梯，而是一系列针对不同瓶颈的专门解决方案。它们共同构成了一个工具栈，每一层都在解决具体的问题。 作为使用者，你真正需要做的不是追着每一层的新名词跑，而是搞清楚自己当前撞在哪一层的天花板上，然后精准地在那一层用力。看懂了这个演化逻辑，工具的"混乱"就不再混乱——它只是一张地图，你需要的是知道自己站在哪里。 这件事的残酷之处在于：地图看懂之后，大多数人会发现自己的瓶颈比想象中低得多。但这恰好是好消息——因为越低层的瓶颈，通常越容易突破。 2 个帖子 - 2 位参与者 阅读完整话题
背景: 我：实现出来 * 3；codex：如果你愿意，我下一步 * 3； - #12，来自 p369029292 省流不看版：分享一个补丁，解决背景中反映的问题，帮助婆婆妈妈的agent简单直接执行任务不overthink，不再动不动停下来思考提问或者翻来覆去光甩锅不做事： GitHub - cut01ass/LLM-over-deference-fix · GitHub 大家应该都有感觉。自GPT-5 debut之后，不少模型开始更会来事了。 动不动先停一下 夹个嗓子说“需要我帮你运行这个脚本吗”“如果你愿意，我可以xxx”。 开始一两次还好，用久了特别磨人，几句话能说完的事，非要拆成一堆小标题、无序列表，最后再补一句“一句话总结”或者“如果你想，我可以继续” 婆婆妈妈跟话痨一样。 短任务还好，一旦任务变复杂 比如写代码、改项目、做多步分析，这种停顿和兜圈子的现象就会非常明显。 为啥模型会变成这样？其实就是现在的模型训练范式太久没有更新，模型训练评估的时候，模型学油了！学会给一个更容易让人类评估者满意的回答，更符合评估模型打分思路的回答。 模型回答越来越老奶奶裹脚布又臭又长，不是模型从了娘家的象 奥特曼化了，而是模型出生的时候就学乖了 知道咋说话有糖吃了。 说的严谨一点，在现在的训练范式 RLHF 中有个很难回避的结构性偏差，人类标注者、偏好模型、产品指标，很多时候天然更偏爱 agreeable 的回答，而不一定更偏爱正确、直接、有效的回答。 锅还是在我们碳基生物头上。所以只要使用存在偏好的专家评估且机制稳定奖励那种顺着你、哄着你、尽量不给你不舒服感的表达，模型就会持续承受朝这个方向偏移的压力。它不一定表现成“变笨”，但会越来越不顺手，越来越需要你用额外 prompt 去纠正它。 有聪明人就要问了。模型大厂里有的是厉害人物，这个问题从被发现到现在 都快小两年了，咋还不修复？ 你要知道从产品角度看，不冒犯 不武断 回答面面俱到（至少看起来是），往往更安全，投诉风险更低，满意度指标也未必差。你可以把它理解成一种 AI 产品里的“安全默认姿势”。 你问我咋知道的？鄙人去年年中给一个手机厂搞模型大跃进，做内部开发用的模型的时候就发现这个问题，反复拉会讨论的结果就是，这是好事啊。（doge玫瑰）这个手机厂模型如此，ds也是如此，很多国产厂商都是这样。 这就是我觉得最麻烦的地方，不是厂商不知道有问题，而是他们就算知道，也不一定有足够强的动力去修。 想想身边八面玲珑 说话滴水不漏但就是不干实事的兄弟，你就知道为啥这种模型在厂商那里混得好了。厂商也知道，不修。那如果不修，天天高强度用agent做重型任务的用户咋办？ 厂商就分成两派了，一派是A社这样的人老实话不多让模型专注于给你干活的，一派是既要又要的（比如某个天天去政府大楼吃披萨还假装理中客的）发现问题之后做一些局部对冲，让它别难用得太明显，你会看到某些厂各种发 prompt guide，教你怎么写 persistence block，看到他们提供 verbosity 之类的参数，让你把输出压短一点；也会看到前端层不断加一些产品化补丁。但这些东西本质上更像是给高级用户的手动调参入口，不是根治。 应付一下相对小众的群体而已，除非小众群体成为多数，比如claude。 btw 很多人也发现了 GPT5之后道德感变高了，动不动就上纲上线的说这不行那不行，很多人误以为是大手发力了 忽略了训练范式的影响，其实不仅是厂商的调教缘故（哪来那么多预算），模型自己也在往这个方向主动进化。这和回答不粘锅的行为背后是同一类机制。 那身为用户，该怎么办？没办法呀，虽然知道gpt这个样子，但是cc官方价相对于我的每月用量来说太贵，只有用用plus号池维持一下这样。 那我现在怎么补这个洞？我的做法很土，但有效，反正这问题一时半会儿不会好，所以在自己的 runtime 层主动打补丁。 核心思路就两条。第一，不要指望模型自己“悟”到什么时候该直接做，什么时候该停下来问；你得把这条规则写得非常明确，而且要明确到能和内置 prompt 对冲。比如直接写：低风险、可逆、逻辑上清楚的下一步不要问，直接做完再汇报；不要用“如果你愿意，我可以……”这种句式收尾；只有遇到不可逆操作、外部副作用、或者关键信息真的缺失时才暂停。第二，不要只在一个前端修，因为问题不在前端，而在底层模型行为。你在哪些 runtime 上用同一个模型，就在哪些地方一起加这类 override。 简单来说，这不是根治方案，因为二进制的系统词改不了，只是模型每次要跑偏的时候 主动拉一把回来。当然还有一些别的trick，比如压 verbosity，让模型再次生成裹脚布的时候主动用几句几段话完成回答而且不漏掉应该输出的知识点。都在脚本里了，这里不赘述。 我现在对这件事最强的感受，是虽然模型在一步步的进化，但是在目前未知结束点的周期内，模型越来越需要被驾驭。以前你更多是在想怎么把需求说清楚；现在你还得额外约束它不要绕弯、不要请示、不要模板化、不要拿安全姿态覆盖执行。 这个成本一旦持续上升，用户体验就会明显变差。我把它看成一个阶段性的信号。 如果后面训练范式没有出现一轮更像样的变化，这个趋势大概率还会继续。到时候大家拼的可能不是谁家模型绝对智力更高，而是谁家更少废话、更少姿态、更敢在该动手的时候直接动手。 毕竟，我们都宁愿与一个偶尔做错事、但愿意把事做下去的同事打交道，也不太想用一个永远礼貌、永远周全、永远不粘锅的老登打交道，再那样的环境下与agent共事，是推进不了工作的。 5 个帖子 - 5 位参与者 阅读完整话题
本人重度B站使用者,之前刷竖屏视频的时候被各种AI短剧视频,某果短剧困扰了很久,刷两条来一条,和牛皮癣一样,关键是刷到了有时还不自觉的看下去 越看越推 ,之前的应对方法为改用白色版本B站,可惜很久没更新了,有很多BUG,分享有问题,还容易闪退,后面还是没用下去; 最近发现 GKD v1.12.0-beta.1 之后的版本更新支持了 滑动操作 这应对B站的竖屏模式下的广告视频非常不错 效果 针对各类推广视频直接上滑跳过 使用方法 订阅 → 本地订阅 → 应用规则 → 哔哩哔哩 → 右下角 + 号 → 放入规则即可 { key: 17, name: '功能类-自动跳过推广/漫剧/预约/小火箭', desc: '竖屏播放时检测到各种推广标识自动上滑跳过该视频', rules: [ { key: 0, name: '检测并跳过：创作推广', fastQuery: true, actionCd: 1500, activityIds: [ 'com.bilibili.video.story.StoryVideoActivity', 'com.bilibili.video.story.StoryTransparentActivity' ], matches: '[vid="story_title"][visibleToUser=true]', action: 'swipe', swipeArg: { start: { x: 'screenWidth * 0.5', y: 'screenHeight * 0.8' }, end: { x: 'screenWidth * 0.5', y: 'screenHeight * 0.2' }, duration: 300 } }, { key: 1, name: '检测并跳过：短剧,漫剧', fastQuery: true, actionCd: 1500, activityIds: [ 'com.bilibili.video.story.StoryVideoActivity', 'com.bilibili.video.story.StoryTransparentActivity' ], matches: '[vid="entry_type"][text="漫剧"][visibleToUser=true]', action: 'swipe', swipeArg: { start: { x: 'screenWidth * 0.5', y: 'screenHeight * 0.8' }, end: { x: 'screenWidth * 0.5', y: 'screenHeight * 0.2' }, duration: 300 } }, { key: 2, name: '检测并跳过：付费推广', fastQuery: true, actionCd: 1500, activityIds: [ 'com.bilibili.video.story.StoryVideoActivity', 'com.bilibili.video.story.StoryTransparentActivity' ], matches: '[vid="charge_widget_start_text"][visibleToUser=true]', action: 'swipe', swipeArg: { start: { x: 'screenWidth * 0.5', y: 'screenHeight * 0.8' }, end: { x: 'screenWidth * 0.5', y: 'screenHeight * 0.2' }, duration: 300 } }, { key: 3, name: '检测并跳过：含图标小火箭推广(ImageSpan占位)', fastQuery: true, actionCd: 1500, activityIds: [ 'com.bilibili.video.story.StoryVideoActivity', 'com.bilibili.video.story.StoryTransparentActivity' ], matches: '[vid="title"][text~=".* +0$"][visibleToUser=true]', action: 'swipe', swipeArg: { start: { x: 'screenWidth * 0.5', y: 'screenHeight * 0.8' }, end: { x: 'screenWidth * 0.5', y: 'screenHeight * 0.2' }, duration: 300 } } ] } 规则语法为JSON5,具体可以见GKD文档 订阅规则 | GKD GKD 基于 Android 无障碍服务（AccessibilityService）获取到的 无障碍节点树（Accessibility Node Tree） 其实和HTML的匹配DOM树差不多,整个规则结构的JSON5格式还是十分清晰的,需要了解一点安卓知识(activity,视图树什么的) 基本的思路就是 找到了某个节点 → 触发某个操作 难点在找到广告对应的特征节点,以及触发什么样的操作(在不影响使用的情况下) GKD本身是支持捕获屏幕快照的,可以在 设置 → 其他 → 高级设置 → 快照按钮 此时屏幕出现一个捕获按钮,找到对应的有广告界面捕获就行,捕获完成后可以生成一个查看链接(注意消除个人敏感信息),也可以直接下载zip,查看JSON格式的信息;具体操作不在赘述了 期待各位佬友发挥,也可以分享下自己觉得好用的规则,多多交流 5 个帖子 - 2 位参与者 阅读完整话题