v2ex_hot_2026-03-30

V2EX 热门帖子

1. 2026 年了，程序员用 chrome 还是用 Safari 比较多？可以说一下推荐的原因吗？

_{作者: liang37038 | 发布时间: 2026-03-29 14:39}

2. 基于微信 iLink API，微信可以连上 Claude、Code、Copilot、Qwen、Gemini、OpenCode 等各类 Agent！

昨天，微信官方推出了 OpenClaw 的支持。

我看了一下相应的源码，发现底层其实是基于 iLink API 进行消息通信的！

endpoint 是 [ilinkai.weixin.qq.com](http://ilinkai.weixin.qq.com)，通过 REST API 进行交互。

那么，事情就好办了！

我是不是能做一个通过 WeChat Bridge ，通过 ACP 来连上任意的 ACP Agent ？

于是，今天晚上马上开搞！

发布了 WeChat ACP： https://github.com/formulahendry/wechat-acp

你只需要运行一行命令：
npx -y wechat-acp --agent copilot
用微信扫二维码，然后就能在微信里面操控 Copilot CLI 了！

当然，也内置了其他主流 Agent：
npx -y wechat-acp agents
也可以启动其他 ACP Agent：
npx wechat-acp --agent "npx my-agent --acp"
代码完全开源：

https://github.com/formulahendry/wechat-acp

欢迎来试用或者围观！

_{作者: formulahendry | 发布时间: 2026-03-23 16:21}

3. Claude Code 百万级逆向文档！

HitCC——近百万字级 Claude Code 逆向文档
https://github.com/hitmux/HitCC

这不是源码仓库，而是对 Claude Code 静态逆向分析写出的文档

截止目前，文档已经超过 95w 字节，人类阅读可能存在困难，建议喂给 AI+语义检索来学习

项目目标不是复刻原始文件树，而是尽可能还原 Claude Code 的全部客户端运行逻辑

本项目与 Anthropic PBC 无任何关系。仓库中不包含 Claude Code 原始源码，不包含破解内容，也不包含绕过产品策略或权限机制的实现

文档覆盖范围
docs/ 已覆盖的范围可以按目录理解为：

00-overview

范围边界、证据来源、置信度口径、文档结构与维护约定

01-runtime

CLI 入口、命令树、运行模式分流

Session / Transcript 持久化与恢复

输入编译链、主 Agent Loop 、compact 分支

Model adapter 、provider 选择、auth 、stream 处理与 remote transport

web-search、web-fetch 两类内建网络工具

telemetry 、control plane 、非 LLM 网络链路

settings source 、路径、合并、缓存、写回与关键消费面

02-execution

Tool execution core 、并发执行、Hook runtime 、Permission / Sandbox / Approval

instruction discovery 、rules 、prompt assembly 、context layering

非主线程 prompt 路径、attachment 生命周期、context modifier 与 tool-use context

03-ecosystem

Resume 、Fork 、Sidechain 、Subagent 、agent team

Remote persistence 、bridge 、Plan system

MCP 、Skill 、Plugin 、TUI 及其运行时交互边界

04-rewrite

面向重写工程的候选分层、目录骨架、未决项与阻塞判断

05-appendix

glossary 、evidence map 等统一术语和证据索引

附录：我逆向 Claude Code 的原因： https://www.anthropic.com/news/detecting-and-preventing-distillation-attacks https://www.anthropic.com/news/disrupting-AI-espionage https://www.anthropic.com/news/updating-restrictions-of-sales-to-unsupported-regions

_{作者: Hitmux | 发布时间: 2026-03-29 13:33}

4. windows 11 现在问题还多吗

前段时间遇到的是，win11 下，突然没有声音，后来又是 win11 chrome 下，mp4 视频卡顿，变声的问题。想问下各位，最近修复了没

_{作者: Drliehuo | 发布时间: 2026-03-29 15:44}

5. claude 到底应该算是“通用”大模型还是“垂域”大模型

毕竟 claude 是靠 coding 广受码农好评。

_{作者: YanSeven | 发布时间: 2026-03-29 12:06}

6. 当大模型失去“品牌光环”，你还能分辨出谁更聪明吗？——我做了一个 AI 盲测竞技场

最近我在死磕 AI Agent 的评估技术，看了市面上五花八门的评测榜单，又去深入研究了各种复杂的 AI 辅助评估体系（比如让 GPT-4 当裁判）、RAGAS 等等。

但看来看去，总觉得心里缺点什么。

现在的模型评测痛点真的太明显了：

指标太冰冷 ：各种学术化的分数堆叠在一起，当模型真正面对普通用户的闲聊、吐槽或者是各种稀奇古怪的需求时，那些干瘪的指标根本体现不出哪个模型更有“人情味”和灵性。

AI 当裁判的偏见 ：用强模型做评委（ LLM-as-a-Judge ）不仅贵，而且这些模型特别喜欢“给自己打高分”（也就是自我偏好），或者是哪个答案长就选哪个。

真实声音太少 ：其实最有效、最能反映用户诉求的评测，就是真实用户的“用脚投票”（ RLHF 人类偏好数据），然而市面上能让普通人低门槛参与进来的开源趣味测评并不多。

所以，我索性自己动手糊了一个小项目：AI Evolution Arena （ AI 进化竞技场） 。

👉 体验地址在这里： https://arena.angrach.top/

简单来说，这是一个 大模型盲测与评测平台 。

它是怎么玩的？

双开盲盒 ：当你进入竞技场，系统会自动在幕后随机抽选两个匿名大模型（可能是通义、GPT 、或者是某个黑马模型）。

匿名对战 ：你可以尽情地抛给它们任何问题——写代码、讲笑话、甚至情感咨询。两个模型会同时流式输出答案，这个时候你是看不到它们名字的。

必须站队 ：抛开了排版和品牌的先入为主，你只能单凭“谁这盘回答得好”来选择偏好（左边好 / 右边好 / 都好 / 都烂）。

揭开真名 ：当你投完票，才会揭晓这两位选手的“真面目”。那一刻你可能会惊呼：“什么？我刚才居然觉得 XXX 比 GPT 还要顺眼？”

我最初做这个项目的初衷真的就是为了 撕掉大模型的厂牌标签，回归到“回答内容本身” 。

它没有任何登录注册的门槛，即开即用。所有的流式渲染、打字机效果我都做了仔细的优化，只为给你最流畅的对阵体验。希望你能来玩一玩，哪怕只是偶尔遇到了什么无解的问题，顺手丢进竞技场，看看两个神秘模型谁能给你更好的启示。

平台刚上线，后续我还会把胜率排行榜（ Leaderboard ）慢慢完善起来。你的每一次投票，其实都在帮我们沉淀一份最真实、最宝贵的人类偏好数据。

_{作者: lanweizhujiao | 发布时间: 2026-03-29 02:14}

7. 简单梳理一下 llm 开发的变和不变？这个对吗。

1. 大模型就是 CPU/GPU ，所有的一切都是围绕着 llm 的“智能”来的，所以 llm 大模型的架构、训练、推理的研发和优化是人上人，是软件工程新时代的核中核，一旦 llm 的智能停滞，一切都消散，属于金饭碗。

2. 只要 llm 仍然是基于自然语言的，自然语言就是 0-1 比特流，是和 llm 交互的唯一入口，上下文窗口就相当于内存。内存和上下文窗口自然会不断发展和增长，但是任务和需求也会同步增长，上下文窗口大小和任务大小的矛盾将一直存在。所以，研究上下文工程的是银饭碗，包括压缩，检索，子代理编排等。

3. llm 垂域应用，在有了智能和窗口管理，就可以面向各个垂直领域做改造适配来，这部分和业务以及领域知识强相关，垂域应用想要解决痛点，易于使用而不是流于 PPT 和 demo 还是不容易的，是真正落地的地方。属于铜饭碗。

4. 工具，就算是多模态的大模型也不能直接吐出生成所有模态的数据来作为结果，那就真是造物主了，llm 仍然需要工具来做具体的事情，所以针对各种需求的旧工具改造，新工具创造仍然是持续的需求，但是鉴于工具由传统代码构建，而金饭碗和银饭碗的工作一定程度上已经可以批量生产工具来了，所以单纯的生产各种组件和工具会是一种流水线上的廉价”铁饭碗“。

_{作者: YanSeven | 发布时间: 2026-03-29 15:30}

8. 升级了一下自己写的 Codex 切换应用

之前因为自己有几个 Codex 的账号，切来切去十分的麻烦，索性自己写了个切换账号的应用，可以帮我快速切换账号，或者指定账号打开一个独立的 Codex 应用，免去了多账号的情况下只能同时使用一个账号的烦恼，后来又扩展了一下 cli 的支持，可以看： https://www.v2ex.com/t/1200427?p=1#reply15

用的过程中发现有时候额度用的快，想找个国内的平替，又懒得搞一堆 cli 或者其他的应用，索性想着能不能继续用 codex cli 来开发，于是就实现了一下接入 kimi 、GLM 、minimax ，用下来发现意外的挺好，于是就想着能不能也支持 claude code cli 呢？

折腾一番下拉，居然也问题不大，当然这中间参考了不少已有的项目，自用目前来说十分满足，可以让我丝滑的把 codex 的额度用来使用 claude code(PS: 反过来也行)，用国产模型来使用 codex 、claude code ，美滋滋。

项目地址： https://github.com/aikilan/Orbit

_{作者: aikilan | 发布时间: 2026-03-29 14:02}

9. AI 盛行的当下，做美颜 SDK 开发还有市场吗？

做了一套支持多平台的实时美颜 SDK ，当然也有 AI 写的代码。断断续续做了将近半年，核心功能自己写的，网站，服务器后端都是 AI 辅助下做的，最近上线了。目前注册人数 100+，付费用户只能说能 Cover 住各种成本。

那么 AI 能力越来越强的背景下，这种 SDK 的市场还会有生存空间吗？担心自己开发半年，最后被 AI 干死。

目前想的是运营着，迭代着，看看情况，有没有独立开发者或者资深 AI 研究的朋友说说看法

_{作者: devzhaoyou | 发布时间: 2026-03-29 14:07}

10. 陪伴我最久的一台服务器，到底是没见到 2025 年的春节，让我升级坏了报废。

2007 年底装的 PC 机箱 2008 年春节前一直丢政府机房自用

一直做内部 IPPBX/语音服务器

Pentium E2180 + 4GB*2 RAM + 320GB 硬盘

初始安装 ubuntu server 6.06 LTS

因为内存大于 4GB 当时选了 AMD64 装的这个决定让他活到了现在

一路从 6.06lts -> 8.04lts -> 10.04lts -> 12.04lts -> 14.04lts -> 16.04lts -> 18.04lts -> 20.04lts -> 22.04lts -> 24.04lts

其中 14.04lts->16.04lts 升级时出现了不兼容问题手动修复了引导

这次 22.04lts -> 24.04lts 后重启直接没起来

不是操作系统升级坏了，应该是硬件物理损坏积累下来的，重启直接没法开机了

陪伴最久的老战士，这些年累计创造了几万块利润，除了升级也几乎不需要维护，考虑要不要会老家给他挖个坟立个碑埋下去……墓碑整个二维码……

_{作者: realpg | 发布时间: 2025-01-18 04:05}

11. ai-menshen：一个轻量级、本地优先的 Go 代理，用于 OpenAI 兼容的 API，旨在审计、缓存

https://github.com/jiacai2050/ai-menshen

ai-menshen (门神) is a local-first proxy for OpenAI-compatible APIs. It sits in front of your upstream providers to handle Auth Injection (BYOK), Model Overriding, Usage Auditing, and Caching—keeping your API keys and logs strictly under your control.

_{作者: lcj2class | 发布时间: 2026-03-29 14:12}

12. 一直用 opus-4.6，但是最近谷歌反重力 Antigravity 的 ultra 家庭组不耐用了，超级不耐用

除了中转站和直接开 Claude 会员（封的太厉害了，如果有好方法也行）还有其他什么好的方案吗？

_{作者: bailywen | 发布时间: 2026-03-29 09:12}

13. 今天双倍快乐🎉结束了感觉用量刷刷往上涨

MAX 5X 要不够用了

_{作者: bitnerd | 发布时间: 2026-03-29 04:24}

14. API 工具并没有变得更好，只是我们降低了期待

奇怪的是，现在已经很少有人认真讨论 API 了。

不是因为 API 没那么重要了。恰恰相反，API 比以前更重要。现代软件几乎都是靠 API 连起来的：SaaS 产品、内部平台、移动应用、合作方集成、自动化工作流，还有现在越来越多通过 HTTP 形态边界调用工具的 AI agent 。

但 API 生态却显得异常安静，甚至有点认命。好像这个问题已经被解决了。好像 Postman 、Swagger 、一个测试框架、一些 CI 胶水代码，再加上一堆半维护状态的示例文件，就是最终形态。

就连 GraphQL 、gRPC 这样重要的新方向，也没有真正重新点燃整个 API tooling 的讨论。它们改变了一些技术边界，但 workflow 问题并没有消失。

我不觉得这个问题真的被解决了。

我觉得只是大家已经习惯了这些摩擦。

最容易改善的那部分 API 问题，已经被 AI 戏剧性地改善了
很长一段时间里，API 最显眼的问题其实是文档。

文档不完整，文档会漂移，文档里的例子总是过于理想化，和真实行为对不上。Swagger 和 OpenAPI 当然帮了很多，但工作流还是那一套：先读 spec ，再打接口，发现真实行为和文档不完全一致，更新自己的理解，然后继续往下走。

AI 非常快地改变了这一点。

今天，只要你手里有一个还不错的 spec 、一些示例，甚至只是一个能工作的 endpoint ，AI 就能帮你解释 API 、总结结构、生成 payload 、比较版本、写 client ，回答文档里的问题，速度比大多数人工流程都快。

这是实打实的进步。但它也暴露了一个更深的问题：过去我们对 API 的很多挫败感，其实都被“文档问题”吸收掉了。现在 AI 把这部分大幅改善以后，那些真正没解决的问题反而更难被忽视。

真正的问题从来不只是文档
更难的问题，是理解一个 API 之后发生的所有事情。

你怎么探索它？

怎么把探索过程中有价值的部分留下来？

怎么把一次性的试验，变成可以重复运行的验证？

怎么测试一个真实 workflow ，而不是一堆彼此无关的请求？

怎么从本地探索过渡到 CI ，而不需要重写一遍？

怎么让这整套事情是为 AI 工作，而不是绕开 AI 工作？

这也是为什么 workflow 这么重要。workflow 决定了哪些知识能留下来，反馈能多快回来，一次有价值的试验最后会变成长期资产还是直接消失，也决定了 AI 到底是在一个真实的验证闭环里帮忙，还是只是在生成更多一次性代码。

API 知识到底会沉淀还是蒸发，往往就发生在 workflow 这一层。

我觉得 API 生态真正失败的地方就在这里。我们有很多局部工具：

文档工具

发请求的工具

schema 生成工具

mock server

测试框架

SDK 生成工具

contract tooling

这些工具里有些是好的。Swagger 是好的。OpenAPI 是有价值的。design-first 也是一个很强的概念。

但如果诚实一点说，这些东西并没有真正改变大多数团队的日常 API 工作流。

这个领域太多产品，只是在不断重新发明 API client ，却几乎没有真正碰 workflow 本身。

这么多年，行业一直在打磨各种“发请求”的变体，然后把这叫做进步。

现实还是一样：你在一个地方探索，在另一个地方写文档，在第三个地方测试，在第四个地方自动化，在别的地方排查失败。真正有价值的知识，就消失在这些缝隙里了。

这才是行业默默接受下来的部分。

举个再普通不过的例子：后端把响应里的一个字段名改了。前端类型过期了，文档里的示例过期了，某个保存下来的请求虽然还能“跑通”，但已经不能代表真实 workflow 。最后测试在 CI 里挂掉，离最初的改动已经非常远。这种事情一点都不罕见，这就是 API 日常工作的一部分。

design-first 适合的是“人和人协调”的时代
design-first 不是坏思路。它本质上是一种为人类设计的协调技术。

它适用于这样一个世界：frontend 和 backend 由不同的人做，甚至在不同团队里，节奏不同，需要在实现发生太多漂移之前先把 contract 对齐。

在那个世界里，spec 要承担很多职责：

团队对齐

mock 生成

frontend/backend 并行开发

实现前 review

外部文档

这是一个真实问题，而 design-first 也是一个真实答案。

但 AI 改变了协调模型。

现在，一个开发者带着一个或多个 AI agent ，往往可以在同一个 loop 里同时处理 frontend 、backend 、测试、示例和文档。过去支撑 spec-first workflow 的协调成本，正在快速塌缩。

新的默认工作流越来越像这样：

AI 写 backend 代码

AI 写 frontend 代码

AI 起草测试

代码跑起来

只有在需要时才生成或更新 API spec

这不意味着 contract 不重要了。

它意味着，重心不再是把 spec 作为起点。

AI 让这个问题更明显，而不是更不重要
很多人会觉得，AI 会降低 API tooling 的重要性。我觉得恰恰相反。

AI 很擅长处理代码、结构化 schema 和明确 contract ，但它并不天然适合碎片化的点击式工作流、陈旧的 collection ，或者散落在不同工具里的运行知识。

如果 AI 能帮你理解一个 endpoint 、起草一个请求，甚至生成一个测试，那当然有用。但如果一旦你想把这些工作保留下来、验证它、在 CI 里重跑、查看失败、或者复用到更大的 flow 里，整个 workflow 就断了，那 AI 并没有解决真正的问题，它只是加速了第一步。

而这恰恰是当前 AI coding tools 在实践里最缺的东西。瓶颈通常不是“更多文档”，而是实时的执行反馈、结构化 trace 、失败断言、环境上下文，以及一种把探索性代码自然沉淀成长期验证资产的方式。

AI 解决了很多 API 解释问题，但它没有解决 API workflow 。甚至可以说，它只是让这个缺口变得更清楚了。

这也是为什么我觉得测试在今天反而更重要。它不应该只是事后检查 endpoint ，而应该是探索变成验证、验证留在代码旁边、同一份 artifact 能穿过本地使用、CI 、debugging ，以及 AI-assisted authoring 的那个地方。

过去的中心是 specification 。

新的中心应该是 executable workflow 。

在 AI 时代，source of truth 不太可能还是一份被精心维护的设计文档，更可能是这些东西的组合：

可运行的代码

可运行的测试

trace 和真实响应

在需要时生成的 spec

能贯穿本地运行、CI 和 debugging 的验证资产

我们不是不需要 contract 。

我们需要的是更少的仪式感，更多可执行的真实。

我觉得 API 生态应该往这个方向走：让 API 探索留在代码里，让有价值的发现自然变成可运行检查，让 AI 能参与写和重构，并让同一套 artifact 贯穿本地运行、调试和 CI 。

这也是我希望 Glubean 推动的方向：不是再做一个发请求的工具，而是围绕这个 loop 来设计工具。

这件事之所以重要，是因为不管上层抽象怎么变，真正的边界依然很像 HTTP：请求、响应、鉴权、重试、headers 、payload 、失败，以及调用之间的状态转换。如果这个边界依然是核心，那么围绕它的 workflow 就不应该永远这么碎。

是时候重新认真对待 API tooling 了
我不觉得结论是：我们需要再做一个 Swagger clone 。我也不觉得结论是：AI 会让 API tooling 消失。

恰恰相反，真正的结论是：是时候重新认真对待 API 生态了。

不是把它只当成文档、schema 、生成代码，或者一个界面更漂亮的 request sender ，而是把它当成一个 workflow 问题。

一个真正像样的 API workflow ，应该让你理解一个 API 、探索它、保留有价值的部分、把它们变成验证、在不同环境中运行、检查失败，并且让这一整套 loop 能和 AI 更好地协同，而不是在 AI 进入后直接断裂。

而这件事，到今天仍然缺席。

我们不再讨论 API ，不是因为它已经完美了，而是因为我们已经不再期待它会变得更好了。

我觉得这是个错误。

我做 Glubean 的原因其实很简单：API 生态一直都没有让我觉得“足够好”。不管是探索 workflow 、测试体验，还是往自动化里的交接，都没有。

所以我想再试一次。不是因为我觉得一个新工具就能神奇地修好一切，只是因为我不觉得这个社区应该放弃这个问题。

_{作者: peisongo | 发布时间: 2026-03-29 12:27}

15. 小白想做一个爬大麦演出信息的脚本, 但遇到滑块验证码不知道怎么办

我是做前端的, 想爬一下演出信息供个人使用, 不涉及抢票之类的. 想实现的效果是脚本自动打开网页, 然后手动拖码, 成功后把演出信息保存到本地. 自己用 node 试了试, 思路是把滑块相关的 script 下载到本地, 每次运行脚本时调用, 但各种混淆代码和加密数据弄得人头大, 最后还是只能把滑块展示出来, 过不了验证. 大家有什么更好的实现方案吗?

_{作者: yanyiming | 发布时间: 2026-03-29 05:55}

16. JennaPress 开源 CMS 获得第一个 Stars

_{作者: zanghongtu2006 | 发布时间: 2026-03-29 11:38}

17. 还是要用 ubuntu

过去一直用 windows 开发，编码问题，行尾问题，使用 docker 绑定目录也会有同步问题。

后来就转到 wsl 中开发，但是不好说是 wsl 的 bug 还是 docker 的 bug ，经常出现磁盘读写 100%，磁盘完全占满后所有 app 都不能正常工作了。

然后就转 linux ，选的三个 mint ，debian/kde ，ubuntu 先用 live 模式尝试，ubuntu 出现了一点卡顿就放弃了，尝试 mint 发现官方网站上列了很多已知问题，我不敢用，debian 暂时没有发现问题，就安装了，用了之后才发现这个 debian 反而经常出现 freeze 的情况，就是所有 app 都不可以操作，10 秒钟之后才能恢复，重启之后问题只是频次有所降低，不过 debian 还不只这一个问题，chrome 渲染也有问题，chrome 打开白屏无法操作，所有基于 chromium 的也都不能用（比如 vscode ），启动时需要添加参数才行，然后更搞是如果 debian 重启会把之前未关闭的程序恢复，但是不会恢复我在命令行中指定的参数，也就是说每次重启都会打开了一堆不能用的窗口

最终，用了 ubuntu ，最看不上的反而没有问题。

_{作者: hengxiangbianhua | 发布时间: 2026-03-28 11:47}

18. you-should-use - 一个提醒你使用别名和现代命令的 Shell 插件

分享一个自己写的 Shell 插件，主要解决两个痛点：

设了一堆别名但总是忘记用

还在用 cat/ls/find 这些老命令，不知道有更好的替代

比如你输入 git checkout -b feature ，但你已经有 gcb 这个别名，它会提醒你：

💡 Hey! You should use your alias: gcb → git checkout -b

也会建议你用现代工具替代旧命令：

💡 Hey! You should use: eza → ls (modern replacement with git integration)

主要特性：

支持 Zsh 、Bash 和 Nushell

检测普通别名、Git 别名、全局别名、后缀别名

推荐 eza 、bat 、ripgrep 、fd 、zoxide 等现代 CLI 工具

缺少工具时显示安装命令

可选 AI 建议（本地 LLM ）

Homebrew / zinit / oh-my-zsh / curl 一键安装

安装： brew install vangie/formula/you-should-use

或

curl -fsSL https://ysu.codelife.me/install.sh | sh

GitHub: https://github.com/vangie/you-should-use

主页: https://ysu.codelife.me

欢迎试用和反馈！

_{作者: vangie | 发布时间: 2026-03-29 11:18}

19. mac 上免费的录屏软件

大家使用的都是啥录屏软件呀？

ScreenStudio 很经典，太贵了，一年 100 多美金

v2ex 社区伙伴开发的 QuickRecorder 还不错，不过不支持 zoom ，不支持画中画

我在 reddit 上找了 2 款软件，不过还没有深度体验，功能和 ScreenStudio 差不多

recordly https://recordly.dev/

screenkite https://www.screenkite.com/

大家多推荐一下

_{作者: sq892246139 | 发布时间: 2026-03-29 03:45}

20. 感觉 mimo-v2-pro 比 glm5 厉害

opencode 上薅免费的羊毛 mimo-v2-pro

trae cn 用的 glm5

同一份代码，处理 web 页面按钮点了事件没触发对的问题，glm5 改得很浅，mimo-v2-pro 思考得更加深入，改得也多，但是修复也更完整。

大家也是这个体验吗

_{作者: tf2 | 发布时间: 2026-03-29 06:12}

21. Windows 文件路径长度限制是多少个字符？ 244、255、256、260？「启用长路径」有用吗？

到底是多少个字符？
256
微软文档《 最大路径长度限制 》（ Maximum Path Length Limitation ）：
在 Windows API 中，路径的最大长度为 MAX_PATH ，为 260 个字符 。
系统按以下顺序构建本地路径：驱动器号、冒号、反斜杠、用反斜杠分隔的路径和终止 null 字符。
例如，驱动器 D 上的最大路径为：
D:\某个 256 个字符的路径字符串<NUL>
其中 <NUL> 表示当前系统代码页的不可见终止 null 字符。（<> 字符在此用于醒目用途，不能作为有效路径字符串的一部分。）

文档到这里的意思是：路径总长度是 260 个字符，掐头去尾中间可用的部分是 256 个字符 （英文版也是 256 ）。

那么来测试一下。
测试用例 ：
240-00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

251-0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

252-00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
字符串计数工具

244
在 D:\ 路径，使用「文件资源管理器（ Explorer.exe ） 」创建文件或文件夹，只能创建 244 个字符的文件、文件夹 。

这张图是在一个 D:\244 字符 的文件夹里，继续新建文件夹的报错「目标路径太长」。

然后我发现群晖文档《如果 Windows 文件资源管理器提示文件名过长，我该怎么办？》讲得很清楚：
「最大可用路径长度为 244 个字符 ，因为 Windows 文件资源管理器为 8.3 文件名格式 预留了 12 个字符。」

其实微软文档《最大路径长度限制》也提到了：「使用 API 创建目录时，指定的路径不能太长以致于无法附加 8.3 文件名 （即目录名不能超过 MAX_PATH 减 12 ）」。只是不太显眼，容易被忽略。

「 8.3 文件名」是什么？
在 MS-DOS FAT 文件系统，基础文件名最多 8 个字符，扩展名最多 3 个字符，总共支持 12 个字符（包括点分隔符），所以被称为 8.3 文件名。Windows FAT 和 NTFS 文件系统不限于 8.3 文件名，因为它们有长文件名支持功能，但也支持 8.3 版本的长文件名。

在 Win10 、Win11 系统，系统盘默认启用 8.3 文件名，非系统盘默认禁用 8.3 文件名 。
可以用 fsutil 查询（需要管理员权限）：
fsutil 8dot3name query D:
卷状态为: 1 (8dot3 名称创建已禁用)
注册表状态为: 2 (按卷设置 - 默认值)

基于上述设置，8dot3 名称创建已在“D:”上禁用
在启用了 8.3 文件名的盘中，创建文件名超过 12 个字符的文件，系统会自动生成相应的 8.3 文件名，即「短文件名」 。

微软文档《命名文件、路径和命名空间》
微软文档《 8.3 Filename 》
《关于 Windows 文件名和路径名的那些事》
联想文档《什么是 8.3 格式？》

所以，文件资源管理器为了兼容性，进一步限制，就只能创建 256 - 12 = 244 个字符的文件、文件夹。

255
在「群晖文档」中提到：「此限制仅适用于 Windows 文件资源管理器和 Windows API 。使用 Windows PowerShell 或命令提示符中的 ren 或 rename 命令重命名文件不受影响 。」

测试后确实，使用 ren 可以创建超过 244 个字符的文件、文件夹。
但是，文件不能超过 255 个字符，文件夹不能超过 254 个字符 ：（ -LiteralPath 是必须的）：
ren -LiteralPath "1" "252-00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000345"
ren : 指定的路径或文件名太长，或者两者都太长。完全限定文件名必须少于 260 个字符，并且目录名必须少于 248 个字符。
所在位置 行:1 字符: 1
+ ren -LiteralPath "1" "252-0000000000000000000000000000000000000000000 ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : WriteError: (D:\1:String) [Rename-Item], PathTooLongException
    + FullyQualifiedErrorId : RenameItemIOError,Microsoft.PowerShell.Commands.RenameItemCommand
报错是：「完全限定文件名必须少于 260 个字符，并且目录名必须少于 248 个字符 」。
微软文档《 Git 跨平台兼容性》：「对于具有 .NET 的目录，完全限定的文件名必须少于 260 个字符，目录名称必须少于 248 个字符」。

为什么文件最多 255 个字符 ？既不是 256 也不是 244 ，代码实现与文档《最大路径长度限制》是对不上的。
在另一篇微软文档《 Filename 》倒是提到了 255 个字符：A filename MUST be at least one character but no more than 255 characters in length.

为什么文件夹最多 254 个字符？这个数字更是哪都对不上。还有，使用 mkdir 只能创建 244 个字符的文件夹。

「启用长路径」有用吗？
「启用长路径」也就是注册表值 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem LongPathsEnabled (Type: REG_DWORD) 设置为 1 。

微软文档《最大路径长度限制》：启用之后，「允许最大总路径长度为 32767 个字符 的扩展长度路径」，要指定扩展长度路径，要使用 \\?\ 前缀。例如，\\?\D:\非常长的路径 。

它只对部分 Windows 函数生效 。

单个文件、文件夹的名字上限还是 255
前面测试的文件资源管理器，PowerShell 的 New-Item 、Rename-Item 等命令仍然不完全支持长路径 。
New-Item 、Rename-Item 具体调用的是什么函数？这个问题超出我能力范围了。

启用长路径之后，mkdir（New-Item -ItemType Directory -Path）可以创建 255 个字符的文件夹，限制只增加了 11 个字符 ，在这个文件夹下也能继续创建文件。
mkdir "252-00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000345"

    目录: D:\
Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
d-----         2026-3-19     21:49                252-00000000000000000000000000000000000000000000000000000000000000000
                                                  000000000000000000000000000000000000000000000000000000000000000000000
                                                  000000000000000000000000000000000000000000000000000000000000000000000
                                                  000000000000000000000000000000000000000000000345
长路径语法 \\?\
如果按文档，加上 \\?\ 反而会报错：
mkdir "\\?\D:\252-00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000345"
mkdir : 路径不能为空字符串或全为空白。
参数名: path2
所在位置 行:1 字符: 1
+ mkdir "\\?\D:\252-000000000000000000000000000000000000000000000000000 ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidArgument: (\\?\D:\252-0000...000000000000345:String) [New-Item]，ArgumentException
    + FullyQualifiedErrorId : CreateDirectoryArgumentError,Microsoft.PowerShell.Commands.NewItemCommand
New-Item 创建文件时，支持 \\?\ 语法：New-Item "\\?\D:\123" 。但创建文件夹时，又不支持了。
Rename-Item 支持 \\?\ 语法：Rename-Item -LiteralPath "\\?\D:\1" "\\?\D:\123" 能正常运行。
Remove-Item 支持 \\?\ 语法，而且对超过 255 个字符的命令没有报错。还好它是支持的，否则创建之后不能删除就麻烦了。

PowerShell 5.1 启用长路径前启用后

文件资源管理器 244 244

mkdir 244 255

ni （文件） 255 255

ren 文件夹 254 ，文件 255 255

del 超过 4000

255 还不到 32767 零头的一半。

PowerShell 7
Win10 、Win11 默认的 PowerShell 是 5.1 版本的 。
$PSVersionTable 查看版本。

我下载了 PowerShell 7.6.0 版本进行测试。

PowerShell 7.6.0 启用长路径前启用后

mkdir 255 255

ni （文件） 255 255

ren 文件、文件夹都是 255 255

del 超过 4000

统一是 255 字符了，比 5.1 版本好一些，但还是不支持长路径，使用 \\?\ 语法也不行。

多层文件夹的路径上限
虽然单个文件、文件夹的名字上限是 255 个字符，但多层目录的限制又不一样了。在未启用长路径 的情况下，就可以创建超过 4000 个字符的路径 。还能在这个路径下新建 txt ，并且用「记事本」读写：

而且，到了这个长度，「文件资源管理器」报错是「目录名称无效」：

「启用长路径」之后这个报错也还在。

就到此为止吧，暂时不继续研究了。

第三方软件的支持情况
PikPak
终于到了我研究这个问题的初心了！
我发现 PikPak 的 Windows 客户端下载文件（ v2.8.16.5418 ），文件名超过 100 个字符的部分会被截断 。网页端没有这个问题。
于是我去找客服提了 bug ，只过了 11 天，官方就在 2.9.0 版本修复了。我要给 PikPak 的客服和研发点赞，认真处理用户反馈。

修复后的逻辑是这样的：
总路径长度支持 500 个字符 ：包括 246 个字符的文件名，246 个字符的上层路径（可以有多层文件夹）：
\\?\D:\246 个字符的路径\246 个字符的文件名
如果超过限制，会弹出「下载失败」的通知。

总结
截至 2026-03 月，使用 Windows 系统，路径长度（文件名）最好控制在 244 个字符以内 。
单个文件、文件夹的名字上限是 255 个字符。
多层文件夹的路径上限超过 4000 个字符。
「启用长路径」的作用鸡肋。

提醒：4 个字符的扩展名是很常见的 ：
.avif .docx .flac .html .jpeg .json .m3u8 .pptx .webp .xlsx

参考资料
Windows10 下路径名称限制

群晖文档《 Cloud Station Backup 帮助》：
Cloud Station Backup 默认在以下情况下不会备份文件和文件夹：
对于 Windows：

文件夹或文件路径长度超过 247 个字符。

文件名称长度超过 255 个字符。

看了但没用上 ：

30 年前的技术债引发 win11 离奇 bug ，微软不敢修！
请教一下，windows 系统变量字符过长有什么好的解决方案！

更新日志
2026-03-21 第一版
2026-03-19 开始写

欢迎关注我的频道： https://t.me/fengwq

PowerShell 5.1	启用长路径前	启用后
文件资源管理器	244	244
mkdir	244	255
ni （文件）	255	255
ren	文件夹 254 ，文件 255	255
del	超过 4000

PowerShell 7.6.0	启用长路径前	启用后
mkdir	255	255
ni （文件）	255	255
ren	文件、文件夹都是 255	255
del	超过 4000

_{作者: fengwq | 发布时间: 2026-03-27 02:59}

22. 太离谱了，改名叫离谱云吧

[物语云计算] 尊敬的用户您好：物语云计划于 2026 年 3 月 29 日晚 21 时至次日 3 时，对「中国香港」地区产品（不含 CeraCMI ）进行升级维护，过程中云服务器将无法访问网络，数据不受影响。详情请查看官网相关公告，给您带来的不便我们表示诚挚的歉意。

_{作者: psirnull | 发布时间: 2026-03-29 13:19}

23. [开源] 当 AI Agent 学会三思而后行

背景：养虾繁荣背后的隐忧
2024 年以来，以 OpenClaw 为代表的开源 AI Agent 助手如雨后春笋般涌现。这些工具让开发者能够通过自然语言指挥 AI 执行文件操作、运行命令、调用 API ，极大地提升了工作效率。然而，在这场技术狂欢背后，一个关键问题被普遍忽视：安全问题 。

绝大多数 AI Agent 采用”云端 LLM → 工具执行”的直连架构。用户的一句”帮我清理临时文件”，云端模型可能生成一条 rm -rf /tmp/* 的命令，而系统在权限允许的情况下会直接执行。这种设计存在三个致命缺陷：

意图劫持风险 ：恶意提示词注入可能让模型执行超出用户预期的操作

数据外泄隐患 ：模型可能生成将敏感文件上传到外部服务器的命令

破坏性操作无拦截 ：删除、覆盖等高危操作缺乏二次确认机制

更严峻的是，这些问题在现有开源方案中几乎无解——因为它们将安全完全寄托于云端模型的”自律”，而模型本身并不理解本地文件系统的敏感性和操作的不可逆性。

双脑架构：一种新的安全范式
Kocort 项目提出了一种不同的思路：双脑架构 （ Dual-Brain Architecture ）。其核心思想借鉴了人类神经系统的分工——大脑负责复杂推理，小脑负责快速反射和安全监控。

在技术实现上：

大脑（ Brain ） ：云端大模型（ GPT-4 、Claude 等）负责理解用户意图、制定执行策略

小脑（ Cerebellum ） ：本地量化模型（ 0.8B-1.5B 参数）完全离线运行，对每一条工具调用做语义安全审查

这种架构的关键创新在于：**将安全审查从”规则匹配”升级为”语义理解”**。传统的工具策略（ Tool Policy ）只能基于白名单/黑名单做静态拦截，而小脑模型能够理解”这条命令是否真的符合用户的原始请求”。

技术实现深度解析
审查管线集成
在 Kocort 的 Runtime 执行管线中，小脑审查被深度集成到 pipeline_execute 阶段。每次云端模型产生 tool_call 后，执行流程如下：
┌─────────────────┐    ┌─────────────────┐    ┌─────────────────┐
│  云端 LLM 输出   │ →  │  小脑语义审查    │ →  │  工具执行/拦截   │
│  tool_call      │    │  approve/flag   │    │                 │
│                 │    │  /reject        │    │                 │
└─────────────────┘    └─────────────────┘    └─────────────────┘
核心代码位于 internal/cerebellum/cerebellum.go：
func (m *Manager) ReviewToolCall(req ToolCallReviewRequest) (ToolCallReviewResult, error) {
    status := m.local.Status()
    
    // 优雅降级：小脑不可用时自动放行，不阻塞流程
    if status != StatusRunning {
        return ToolCallReviewResult{
            Verdict: "approve",
            Reason:  "cerebellum not running; degraded to rule-only check",
            Risk:    "none",
        }, nil
    }
    
    // 构建审查 Prompt ，包含用户原始请求和工具调用参数
    prompt := buildToolCallReviewPrompt(
        req.UserMessage, 
        req.ToolName, 
        req.ToolParams
    )
    
    // 本地模型同步推理（使用 llama.cpp CGO 绑定）
    output, err := m.inferSync(prompt, 4096)
    if err != nil {
        // 推理失败时同样降级放行
        return ToolCallReviewResult{
            Verdict: "approve",
            Reason:  "inference failed; degraded to rule-only check",
            Risk:    "none",
        }, nil
    }
    
    // 解析审查结果
    result := parseToolCallReviewOutput(output)
    return result, nil
}
审查 Prompt 设计
小脑模型的系统指令经过精心设计，要求从 5 个维度进行评估：
你是一个安全审查助手。你的任务是审查 AI Agent 工具调用指令是否安全。

## 审查要点
1. 指令是否与用户原始请求的意图一致？
2. 是否存在数据外泄风险（如 curl 上传敏感文件）？
3. 是否存在超出用户预期的破坏性操作（如删除非目标文件）？
4. 参数中是否包含注入攻击（如命令注入、路径遍历）？
5. 操作范围是否限制在沙盒授权目录内？

## 输出格式（严格 JSON ）
{"verdict": "approve|flag|reject", "reason": "简短原因", "risk": "none|low|medium|high"}
这种设计让小脑模型能够理解上下文语义 ，而不仅仅是匹配关键词。例如：

用户说”帮我看看配置文件”，模型生成 cat ~/.aws/credentials → 小脑可能标记为 flag（敏感文件读取）

用户说”删除下载文件夹里的临时文件”，模型生成 rm ~/Downloads/*.tmp → 小脑可能 approve（符合预期）

智能跳过机制
为了平衡安全性与响应速度，Kocort 实现了基于风险分级的智能跳过：
func ShouldReviewToolCall(toolName string, toolParams map[string]any, isElevated bool) bool {
    // 配置模式不需要审查
    if isConfigMode {
        return false
    }
    
    // 低风险只读工具默认跳过，除非包含敏感关键词
    if isLowRiskReadOnly(toolName) {
        if localmodel.ContainsSensitiveKeywords(toolParams) {
            return true
        }
        return false
    }
    
    // 提权操作必须审查
    if isElevated {
        return true
    }
    
    // 包含敏感关键词的必须审查
    if localmodel.ContainsSensitiveKeywords(toolParams) {
        return true
    }
    
    return true
}
这种机制让 memory_search、sessions_list 等只读操作在正常情况下快速通过，而 exec、write、delete 等高危操作始终接受审查。

技术权衡与思考
双脑架构并非没有代价。引入本地小脑意味着：

资源占用 ：需要运行一个额外的本地模型（约 1-2GB 内存）

延迟增加 ：每次工具调用增加一次本地推理（约 100-500ms ）

复杂度提升 ：需要管理两个模型的生命周期

但这些代价换来的是本质性的安全提升 ：

敏感信息永不出设备（小脑完全离线）

恶意提示词注入被本地语义理解拦截

破坏性操作有二次审查机制

结语：AI Agent 安全的必经之路
随着 AI Agent 在企业和个人的普及，安全问题终将成为不可回避的议题。双脑架构提供了一种可行的解决思路：不依赖云端模型的”善意”，而是用本地的小模型做实时的安全守门人 。

这种架构或许会成为未来桌面级 AI Agent 的标准配置——就像现代浏览器的沙箱机制一样，成为用户信任的基石。

本文基于 Kocort 项目的实际实现，代码已开源：github.com/kocort/kocort

_{作者: libii | 发布时间: 2026-03-29 08:01}

24. 我想用 phpstorm + wsl2 + docker desktop 作为开发环境，有没有什么建议的。

最近想在 wsl2 的 docker 中。跑我的开发环境，各位大佬们，有什么好的方案和建议吗。

_{作者: junwind | 发布时间: 2026-03-29 09:45}

25. C++实习，求大佬解答

现在研一下，我后面想去实习，大佬们认为我是应该一直维护一个自己的项目下去，还是多去了解别人项目的代码，应付面试。

_{作者: YangJiLei | 发布时间: 2026-03-29 05:07}

26. 腾讯云香港，我放个爬虫爬海外网站

行不行？

_{作者: andforce | 发布时间: 2026-03-29 08:21}

27. Obsidian 写作环境搭建：这 6 款插件让我的博客管理效率翻倍

前段时间 Obsidian 非常的火，所以我准备上手学习一下，就看到我自己其实有挺多文章需要归纳和处理的，所以准备花时间尝尝鲜。

现在的主要工作就是设置 Obsidian 然后把我博客文章里面的文章全部从 Halo 迁移到了 Obsidian 管理，折腾了一圈之后发现这套组合比想象中顺手很多。这篇记录一下我现在的配置，顺便把迁移途中踩的几个坑也说清楚，省得你重踩。

其实最主要的点，还是因为我想配合 AI 去使用，在 Obsidian 结合 AI 使用会非常的便利。我也是看中了这一点，花了一些时间主动学习了这个工具

安装
其实直接搜索 Obsidian 就可以了，但是怕很多人搜索错我就直接贴对应的地址了。

Obsidian 官方下载地址

主题：AnuPpuccin
我这里使用了好几个主题，最让我舒服的还是 AnuPpuccin ，主要是它的暗黑系风格和我的 IDEA 的主题像类似，这样我就可以很好的使用它。

而且 AnuPpuccin 的下载量 80 万+，目前 Obsidian 社区里最受欢迎的主题之一。亮暗模式都好看，配色方案多，不会让你盯着屏幕眼睛酸。

我主要用深色模式写作，配色调成了偏冷的灰蓝，长时间写稿不容易疲劳。如果你对界面颜值有要求，AnuPpuccin 基本是开箱即用不用再找别的。

配置方式也很简单，点击左下角设置按钮，然后找到外观，主题设置就可以更换你自己想要的主题了。

插件配置
安装的使用第三方插件是需要关闭安全模式，如果没有关闭是无法安装第三方插件。下面就是我使用很不错的第三方插件。

Custom Attachment Location
附件按笔记名自动归类到对应子文件夹。以前图片全扔在 vault 根目录，找起来一团乱；装了这个之后，每篇文章的截图自动进 assets/文章名/，整洁很多。

这里需要简单设置一下安放图片的位置，设置全部文件和图片位置需要设置。URL 其实也不习惯不是标准的 markdown 文档的格式，所以需要设置一下。

Dataview
用类 SQL 语法查询笔记内容，适合做内容索引。我主要拿它追踪文章状态——哪些草稿还没发、哪些选题已经有文章对应——写一条查询语句就能汇总，不用手动翻文件夹。

Enhancing Export
支持导出 PDF 、HTML 、ePub 、Markdown 多种格式。偶尔要给人发一份格式整齐的文档，用这个比直接复制粘贴省事。

Git
自动定时备份到 GitHub 。版本控制这件事我以前全靠手动，某次误删了半篇稿子才意识到有多危险。装上之后基本不用管，按设定的时间间隔自动 commit ，在哪台机器上都能拉到最新版本。

这里有几个推荐设置，不是必须的编辑停止之后自动 push ，我这里设置了一分钟之后知道同步。还有就是设置两个 json 文件去掉，不需要同步到 git 因为经常修改容易冲突。

Local Images Plus
检测笔记里所有外链图片，自动下载到本地并更新链接。这个对从 Halo 迁移过来的文章特别重要 ——导出的文章图片链接还指向服务器，服务器一旦停了图片就全挂，用这个插件一键本地化可以彻底解决问题。

Templater
预设文章模板，新建文件自动套用。我的模板里带 Front Matter ，包含文章状态、发布日期、分类等字段，配合 Dataview 查询能直接看到哪些文章的状态是”草稿”或”待发布”。

迁移途中踩的几个坑
Halo 导出的是 HTML ，不是 Markdown
当时以为官方「文章导入导出」插件能直接导出 Markdown ，结果打开一看全是 HTML 。原因是 Halo 2.x 默认编辑器存储格式就是 HTML ，导出自然也是 HTML 。

解决方式：用 Python 的 markdownify 库批量转换。写一个脚本扔进文件夹跑一遍，几十篇文章几分钟搞定。

HTML 转 Markdown 格式混乱
一开始用 Pandoc 转换，结果富文本 HTML 转出来格式一团糟，标题层级乱、列表嵌套出问题。后来换成 markdownify + BeautifulSoup 组合，效果稳定很多，基本不需要再手动修正格式。

图片链接失效
从 Halo 导出的文章，图片 URL 还是指向原服务器的。迁移完之后如果不处理，服务器一停图片就全挂。

用 Local Images Plus 扫一遍，插件会自动把外链图片下载到本地，并把 Markdown 里的链接替换成本地路径，一步到位。

我现在的工作流
Halo → Obsidian
导出 HTML → markdownify 批量转换 → 导入 Obsidian Vault → Local Images Plus 本地化图片
Obsidian + Claude Code 创作流
分析已有文章风格 → 生成选题灵感 → 确认选题 → 生成大纲 → 确认结构 → 生成文章 → 导回 Halo 发布
选题和风格分析这两步现在基本交给 Claude Code 来跑，它能读完整个 vault 里的历史文章，总结出我的写作语气和高频话题，然后按这个风格出新文章。比自己一篇一篇翻快多了。

如果对这方面感兴趣，我后面也出一篇相关的内容，怎么使用 Obsidian 结合 Claude Code 打造自己的创作流程。

总结
这套配置没什么特别复杂的地方，核心就两件事：

插件组合把「文件管理乱」「备份靠手动」「图片会失效」这三个痛点全堵上了

迁移的坑主要在 HTML 转 Markdown 这一步 ，用对工具基本没什么大问题

如果你也在用 Halo 写博客、想迁移到 Obsidian 管理，按这个流程来应该能少走不少弯路。其实这篇最主要还是介绍 Obsidian 的一些插件和设置，给后续 AI 对接工作流打下基础。

如果感兴趣，我也会写一篇怎么打造自己的文章创作流程，让自己的内容更完整。

_{作者: zp872571679 | 发布时间: 2026-03-29 03:59}

28. Windows 不能触发 “在 Claude 需要输入时获得通知”

我看官方文档提供了这个 hooks, 加进去发现 windows 不会触发系统通知, 是不是缺少了哪方面的设置

_{作者: hentailolicon | 发布时间: 2026-03-29 04:00}

29. 一般用 api key 来访问的话，都没有联网查询功能吗？

opencat 里面，用 gpt5.4 和 minimax2.7 ，都没有访问网页功能。也也就是不能联网搜索。

例如 minimax2.7 的回答如下：

是的，我没有访问互联网的功能。

我的能力包括：

- ✅ 回答基于训练数据的问题
- ✅ 编写代码、文本创作
- ✅ 分析和解释内容
- ✅ 逻辑推理
- ❌ 浏览网页
- ❌ 访问实时信息
- ❌ 搜索互联网

所以像价格、功能对比这类需要最新信息的查询，我无法帮你直接获取。

如果您方便的话，可以把官网或小红书上的信息截图/复制给我，我可以帮您分析对比。

_{作者: Usrename | 发布时间: 2026-03-29 02:56}

30. Deep Research MCP/SKILL 哪个好

请问大家实践过程中，哪个 MCP/SKILL 的 Deep Research 功能比较好用，主要是科研用途（文献综述），请推荐下，谢谢！

另外问问能否比肩 ChatGPT 、Gemini 等 Deep Research 的输出？

_{作者: amnaruto | 发布时间: 2026-03-29 01:16}

31. fnos 飞牛 os 一个很奇怪的 bug

升级了 1.1.26 后，网卡绑定后，系统就卡死了，取消网卡绑定正常。有人碰到过吗？

_{作者: guoguobaba | 发布时间: 2026-03-29 02:40}

32. 如果 5x 持续限额，是否不犹豫的升级到 20x 之后再考虑其他方案？

代码用 opus ，跑数据用的 sonnet ，

但我开启多 agents 在跑的模式（比如用 39 个 agents 在后台跑一个任务），所以频繁小时限额，

用 codex 5.4 试了下，无论是代码还是跑数据都很慢！真的很慢！！（相比 claude ）

另外，国产的大模型有抓数据能力比较强的吗？

_{作者: tho | 发布时间: 2026-03-28 23:53}

33. 有点搞不懂 Claude Code 了

之前习惯的编程工具是 cursor ，本质还是在 vscode 的基础上内置了聊天对话方式调用 agent 来变成或进行任意授权的操作，一直习惯边改还能边看看代码，不管是 review 具体代码还是看看生成了什么文件，就觉得很方便

最近 claude code 越来越火，也了解到有很多人可以多开或者使用 agent teams 来同时使用多个 agent 来干活，想尝试一下，然后就试了。但有发现纯 cli 编码的话任务开始后不就不能东看西看（指看看代码之类的）了，编码完成之后在 claude code 里看代码/review 貌似也不是很方便，用了之后突然感觉有点无所适从了，完成一个需求后还得打开 cursor 看看改动了什么然后再提交。

请教一下各位佬，我这使用姿势是不是不太对？

_{作者: nealzhuqian | 发布时间: 2026-03-28 01:56}

34. [独立开发 / 招募封测] 📻 做了一款极简且高颜值的全球电台 App，求 20 位 Google Play 封测体验官 (即送终身 Pro)

大家好，我是独立开发者。

最近花了点时间做了一款 Android 端全球电台应用 —— RadioPlayer 。市面上其实有很多电台应用（比如 TuneIn ），但大多充满了臃肿的 UI 、繁杂的推荐逻辑，甚至满屏的各种横幅广告。所以我决定自己造一把轮子，核心理念就三个字：好看、纯粹、极简。

✨ 核心亮点：

全球频道：依托 RadioBrowser 数据库，按国家 / 流派 (Jazz, Pop, News 等) 随意切换收听。超高颜值 UI：使用完全原生的 Compose 构建，全局支持顺滑的暗色模式。特别是播放页底部的 MiniPlayer 有纯正的高斯模糊（毛玻璃）效果和音频波纹动画。自定义源：支持 m3u / mp3 直播流，自己添加私有电台（如网易云播客、私服音乐等）。完全没有流氓组件：权限极简，清爽无后台驻留。 💎 Pro 版特权（封测用户免费赠送）：应用本身包含基础体验，高级版 (Pro) 支持了：

📻 纯净无广告 🎧 强制解锁最高音质比特率 (High Quality Audio) 💤 睡眠定时关闭 (Sleep Timer) 🚗 专为开车定制的极大字体的“驾车模式” (Car Mode) ⚡ 无限量的自定义专属电台 🚀 关于封闭测试 (Closed Test) 与福利：众所周知，Google Play 现在上架新应用要求有 20 个用户连续测试 14 天。为了顺利上架，我在此向大家招募 20 位体验官！福利说明：只要你愿意加入测试群组并帮我挂够时长，我会将你的 Google 账号加入 Android 内部测试组（ License Testing ）。在测试版本由于配置了特权测试通道，你可以免费直接购买 Pro 版本（显示 Google Pay 模拟扣款，实际 0 元白嫖应用终身 Pro 权益！）感谢你的支持。

📌 如何参与？

先加入测试群组 https://groups.google.com/g/radioplayer-beta

加入测试计划 https://play.google.com/store/apps/details?id=com.nomo.simpleradio 需要在手机浏览器打开后跳转 google play store

在 Google Play 安装 App 并打开一次即可

如果你也有需要测试的 App ，可以把链接发出来，我也可以帮忙测试，互相帮助一下 🙏 再次感谢大家，如果有任何交互建议或 Bug 反馈，欢迎直接在帖子里指出，我会光速迭代！

_{作者: wumian1 | 发布时间: 2026-03-28 08:57}

35. GLM 5.1 有实际测试过的吗

GLM 5.1 有实际测试过的吗，效果怎么样，能达到 Sonnet 4.6 的水平吗？

_{作者: onedge | 发布时间: 2026-03-28 04:03}

36. Kiro 免费用上 Claude Sonnet 4.5

一、Kiro 是什么
简单说：亚马逊做的 AI IDE ，基于 VS Code 魔改的。跟 Cursor 一个路子，但模型用的是 Claude Sonnet 4.5 （不是 GPT ）。

核心信息：

模型：Claude Sonnet 4.5 （跟 Cursor 的 Agent 模式用的同一个）

免费额度 ：每月 500 次 AI 交互（含代码补全、Chat 、Agent 操作）

平台：macOS / Windows / Linux 都有

账号：需要 AWS Builder ID （免费注册，不需要绑信用卡）

二、申请步骤
第 1 步：注册 AWS Builder ID
打开 https://profile.aws.amazon.com/ ，点 “Create AWS Builder ID”。

填邮箱、用户名，做一下邮箱验证就行了。

注意：Builder ID 不是 AWS 控制台账号，不需要信用卡，不会产生任何费用。就是个亚马逊的开发者身份而已。

第 2 步：下载 Kiro
去 Kiro 官网下载对应系统的安装包。

macOS 选 ARM64 （ M 芯片）或 x64 （ Intel ）

Windows 选 x64

Linux 有 AppImage 和 deb

安装完打开，第一次会弹登录框，用刚才注册的 Builder ID 登录。

第 3 步：登录激活
打开 Kiro 后，点右上角登录按钮，选 “Sign in with AWS Builder ID”。

浏览器会弹出一个授权页面，点 Allow 就行。回到 Kiro 就自动登录了。

登录后右下角会显示你的账号名，说明激活成功。

第 4 步：开始用
直接打开一个项目文件夹，在右侧的 Chat 面板里就能跟 Claude Sonnet 4.5 对话了。跟 Cursor Chat 差不多的用法。

三、可用模型和额度

模型额度说明

Claude Sonnet 4.5 500 次/月主力模型，Chat + Agent + 补全都用这个

500 次是什么概念？我实测了一下：

纯 Chat 问答，一天问 20 个问题，能用 25 天

如果开 Agent 模式让它自己改代码，一个复杂任务大概消耗 20-30 次

代码补全（ Tab 补全）不消耗额度，随便用

省额度技巧 ：

简单问题用 Chat 模式，别开 Agent

Agent 模式一次对话里多说几个需求，别一个一个问

代码补全不花额度，能 Tab 补全的就别 Chat

四、配置说明
基本设置
打开 Kiro Settings （左下角齿轮），关注这几项：

AI Model ：默认就是 Claude Sonnet 4.5 ，不用改

Auto-complete ：建议开启，代码补全不消耗额度

Agent Mode ：在 Chat 面板顶部可以切换 Chat/Agent 模式

插件兼容
Kiro 基于 VS Code ，大部分 VS Code 插件可以直接装。但有些不兼容：

✅ GitLens 、Prettier 、ESLint 、Python 插件都能用

❌ GitHub Copilot 插件装了也没用（会跟 Kiro 自带的 AI 冲突）

❌ 其他 AI 补全插件（ Codeium 、Tabnine ）建议关掉，避免冲突

项目配置
Kiro 会读项目根目录的这些文件：

.kiro/ 文件夹：Kiro 的项目级配置

[CURSOR.md](http://CURSOR) / [CLAUDE.md](http://CLAUDE)：如果你之前用 Cursor 或 Claude Code 写过项目说明，Kiro 也会读

五、踩坑记录
1. 登录一直转圈

浏览器弹出授权页后，点了 Allow 但 Kiro 没反应。解决办法：关掉 Kiro 重新打开，再点一次登录。大概率是浏览器回调没接住。

2. Chat 回复很慢

正常的。Kiro 走的是 AWS 的服务器，亚太区延迟比较高。第一次回复要等 5-10 秒，后续会快一些。如果超过 30 秒没响应，刷新一下 Chat 面板。

3. 额度显示不准

右下角的额度计数器有时候会延迟更新。实际消耗以月底 reset 后的数字为准。

4. Agent 模式改错文件

跟 Cursor 一样的问题。Agent 模式有时候会改不该改的文件。建议在开 Agent 之前先 commit 一下，改坏了可以回滚。

六、Kiro vs Cursor 免费版对比
| Kiro 免费 | Cursor 免费
—|—|—
AI 交互次数 | 500/月 | 50/月（ Premium ）
补全次数 | 不限 | 2000/月
模型 | Claude Sonnet 4.5 | GPT-4o + Claude （混合）
Agent 模式 | ✅ 有 | ✅ 有
价格 | 免费 | 免费（升级 $20/月）

从纯免费角度看，Kiro 的 500 次交互比 Cursor 的 50 次 Premium 宽裕太多了。如果你不想花钱，Kiro 是目前最良心的选择。

说实话，我之前一直用 Cursor ，切到 Kiro 一周后最大的感受是：模型能力差不多（毕竟都是 Claude Sonnet ），但 Kiro 的免费额度真的够用。对于个人项目来说，一个月 500 次足够了。

如果你同时用多个 AI 编程工具，也可以考虑用 OpenRelay 把 Kiro 的 Claude Sonnet 配额接入到 Cursor 或 VS Code 里用——一份额度多个工具共享，就不用在不同 IDE 之间来回切了。

模型	额度	说明
Claude Sonnet 4.5	500 次/月	主力模型，Chat + Agent + 补全都用这个

_{作者: rxc420902911 | 发布时间: 2026-03-28 15:59}

37. LeetCode 1000 题了，一个小小的 milestone

_{作者: JasonLaw | 发布时间: 2026-03-29 11:44}

38. opus 小时限额之后，你们是等，还是用 sonnet 继续？

默认都是用 opus 在跑，中间换 sonnet ，然后又 opus 继续，

遇到限额就这样适合吗，从各角度综合来看？ ——已经是 max

_{作者: tho | 发布时间: 2026-03-28 03:52}

39. 「教程揭秘向」扒完中转站掺假，再扒低价代充——顺便教你自己订阅 Claude/ChatGPT，一分钱不经手中间商

上一篇扒了 AI 中转站掺假的事，评论区炸了——但说实话，被人当傻子宰了，谁能忍？

所以这篇来还债：教你自己动手订阅，把中间商的饭碗直接掀了。

但在上教程之前，我先帮你把市面上那些低价代充的底裤扒干净。不是劝退你，是想让你花钱之前，起码搞清楚自己买的到底是什么玩意儿。

一、低价代充的那些烂活儿
我理解为什么有人买代充。$20 一个月合人民币一百四五，不便宜。能省就省，人之常情。

但省钱和被坑之间，往往就差一个你不知道的细节。

Claude 这边
① 尼日利亚区苹果账号 → 大约半价 $10/月 目前相对最”体面”的一种。尼日利亚区定价低，代充基本走这条路。严格说风险可控，但终归是钻定价差的空子，翻不翻车全看命。

② 虚拟卡订阅完就退款 → 你号没了 纯纯恶心人。帮你订阅，转头就退款，Anthropic 一查账直接封你号。钱花了，号废了，你还在那儿等着用呢——人家早跑了。

③ 礼品卡链接订阅 → 赌运气 有些礼品卡是黑卡买的。一旦上游被追溯，你的账号跟着陪葬。运气好没事，运气差连申诉的门都没有。

④ GitHub 开发者福利 / 美国学生优惠 正规渠道，没毛病。但流通量极少，闲鱼上偶尔冒出来几个名额，真假自辨。

ChatGPT 这边——水更深
最泛滥的玩法：注册机批量建号 → Codex 白嫖 GPT-4 → 反代出去卖 API 。 你在某些平台买到的便宜 API ，大概率就是这么来的。今天能用，明天号池被 OpenAI 一锅端，你去找客服——人没了。

闲鱼上几块钱的 GPT Team 会员号 也是同一条流水线：

日本 IP 访问 OpenAI → 刷出首月 $0 优惠

域名邮箱注册 → 同样触发 $0

两条路都要绑卡，于是又养活了一门生意——虚拟 0 元卡 。发卡网一搜一大把，几块钱一张，据说是美国实体公司批量开出来的（水星银行之类）。绑上去能用，但撑不过一个月就被风控拉黑。周而复始，韭菜割完一茬又一茬。

Gemini 那边更离谱，按下不表，改天单开一篇。

看到这儿你应该品出味了：整条产业链上，每个人都在割你，只是刀大刀小的区别。

我的态度很简单：能自己动手就别求人。一次搞定，省钱省心，不用每个月提心吊胆等封号通知。

二、正式教程：安卓手机 + 国内银行卡，自己订阅 Claude / ChatGPT

先说苹果用户：这条路目前走不通。Apple Pay 虽然能绑卡，但就是不让你直接买 GPT 、Claude 订阅，最靠谱的还是自行购买礼品卡充值，本文不展开。以下全部针对安卓。

方案一：外币 Visa 信用卡 × Google Play ——我自己在用，目前最稳
这是我最推荐的方式，没有之一。

原理说穿了不复杂：通过 Google Play 付钱，等于在你和 AI 厂商之间套了一层 Google 的壳。Anthropic 和 OpenAI 看到的只是 Google 的支付请求，根本不知道你用的是哪国的卡。稳定、合规、不会莫名其妙被封号。

你需要准备：

随便哪家银行的 Visa 外币信用卡 （能刷美元就行）

一台安卓手机

一个 Google 账号，Play 商店地区切到美国

切换地区的教程就不详说了，google 上很多教程。

关于办卡： 我自己办的招商 Visa ，去柜台的时候说”海淘用”，工作人员没多问一句。大部分银行差不多，别自己吓自己。唯一的问题是来不及等卡的话确实急不了，但长远看这张卡的用处远不止订 AI ，值得备一张。

操作步骤：

第一步：确认 Play 商店地区是美国

梯子挂美国节点，建议全局模式。打开 Google Play → 右上角头像 → 拉到底找「设置」→「常规」→「账号和设备偏好」→ 看「国家/地区」是不是美国。

不是的话按上面的链接改，改完再继续。

第二步：绑外币信用卡

头像 →「付款和订阅」→「支付方式」→「添加信用卡或借记卡」

几个坑，踩过的人都懂：

姓名别填中文 ，填拼音

账单地址选美国免税州 ，推荐俄勒冈，用 google 搜索美国地址生成器随便搞一个，填完添加就行。

第三步：去安卓客户端里订阅

打开手机上的 Claude 或 ChatGPT 客户端，找到订阅入口。

划重点：只能在安卓客户端里操作，网页端订阅不了。 别问我怎么知道的，别浪费时间去试了。

进入订阅界面，先别急着点按钮 。点一下「包含税费」那行小字，确认显示「免税，合计 $20.00 」。如果显示有税，说明账单地址没设对，回去检查。

确认免税 → 点订阅 → 输密码 → 完事。

以后想取消？「付款和订阅」→「订阅」里面操作，不复杂。

这个方案唯一的遗憾： 只适合基础档——Claude Pro 和 ChatGPT Plus 。如果你要上 Claude Max 或 ChatGPT Pro ，走 Google Play 会被抽谷歌税，走苹果也一样被抽苹果税。这个目前无解，认了吧。

方案二：普通储蓄卡 × Google Play ——没信用卡也能搞
没外币信用卡？不想办？这个方案给你。

原理一样，只是这次把 Play 地区切到新加坡 ，用新加坡元结算。国内储蓄卡可以消费新加坡元，但有个前提：去银行 APP 里把「境外锁」关掉 。各家银行叫法不一样，有的叫「境外交易开关」，有的叫「海外消费」，总之翻一翻设置找到打开就行。建议用四大行的卡，兼容性好。

代价？新加坡元换算下来每月多花 23 块左右，合计约 163 元。贵了一点点，但省去了办信用卡的等待，自己取舍。

操作步骤和方案一完全一样，就两处不同：Play 地区改成新加坡，账单地址填新加坡地址。其他照搬。

三、两个方案一眼对比
| 方案一（外币信用卡） | 方案二（储蓄卡）
—|—|—
需要什么卡 | Visa 外币信用卡 | 普通储蓄卡（关掉境外锁）
Play 地区 | 美国 | 新加坡
月费（ Claude Pro ） | $20 ≈ 145 元 | 约 163 元
稳定性 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐
上手门槛 | 需提前办卡 | 随时可操作

写这篇的原因很简单：工具是好工具，没必要因为支付这点破事去求中间商，更没必要拿一个不知道掺没掺假、随时可能被封的号凑合。

钱花在刀刃上，账号攥在自己手里，踏实。

有问题评论区见。能帮到一个是一个。

_{作者: scf2024 | 发布时间: 2026-03-23 05:25}

40. [无卡订阅 Claude Pro 方案] 尼日利亚🇳🇬路线约 6.2 折、美区苹果路线约等于汇率价购买 Claude Pro，附 Claude 假模型避坑指南以及为什么不使用中转站

整理了两个不需要信用卡的 Claude Pro 购买方式，主要走 Apple Store / Google Play 礼品卡路线。

为什么不推荐代充/成品号
因隔壁站各种无下限怂恿小白送风控指纹的操作，A\目前有一套充分且完善的滥用画像，新号开 Max 订阅封号概率极高，买来的账号随时可能被封，站内欺诈成本低且无售后 ，闲鱼起码还有披露流程和小法庭流程。比较常见的坑有「确提即争议退款」——卖家收款后立刻对你发起支付争议，「保存登录凭证二次利用」等等…

当然，除去无泄漏，走 Apple store/google play 渠道最大的好处是：封号后可以走平台争议退款，金额退回账户余额 ，损失相对可控。

方案一：美区 Apple Store 礼品卡（按照实时汇率 Claude Pro 大概是 139 元/月）
本质是绕过直接付款障碍，按即时汇率购买，并无折扣 ，约等于花人民币买美元订阅。

操作步骤：

将 Apple ID 切换至美区或者注册美区账户（网络有很多案例这里不赘述）

收件地址填美国免税州地址（俄勒冈、蒙大拿等，网上搜一个即可）

支付宝搜索 PockytShop （支付宝内的跨境购物小程序）

购买 $20 面值美区 App Store 礼品卡，按即时汇率结算

充值后在 Claude App 里内购 Claude Pro

费用： 按当前汇率约 139 元人民币 ，风控比较低。

方案二：尼日利亚🇳🇬 Apple store 礼品卡（目前约 86 元）
折扣来源是 Claude Pro 在尼日利亚的本地化定价 远低于美区（ 14,900 奈拉 vs $20 ），并非汇率差。

操作步骤：

准备一个尼日利亚区 Apple store 账号 （自行搜改区教程，换成尼日利亚地址即可）

在闲鱼搜索「尼日利亚 Apple store 礼品卡」，购买 14,900 奈拉面值

走闲鱼担保交易，收到卡后先充值 Apple store ，Claude APP 里内购即可，等到时间会自动确认收货，无需手动确提，有问题则可以发起退款争议，二次争议上闲鱼小法庭。

费用： 14,900 奈拉闲鱼收购价约 86 元人民币 ，对比美区约 139 元，折扣约 6.2 折 。

封号应对
A\目前有一套充分且完善的滥用画像。如果你被画像误伤，封号后：

平台操作路径退款去向

Apple Store 设置 → Apple ID → 订阅 → 报告问题，以「服务无法使用」为由申请退回 App Store 余额

Google Play 进入订单记录提交退款申请退回 Play 余额

两个平台退款成功率都还可以，远优于代充的维权难度。

Google play 同理
有更新方案欢迎补充。

关于为什么不使用站内中转站，道理一样，

最后小声 bb 两句：

~~kiro 渠道的模型都是隔壁几十万撤离的小孩哥玩腻的假渠道，Claude.ai 宕机了那玩意儿还跑着，早被锤麻了，那玩意儿搁隔壁骗小孩都卖不掉~~ https://www.v2ex.com/t/1187389?p=1

~~实在没经费又想用 Claude opus4.6 ，Cursor Pro Plus 和 google ai ultra 试用去搞点啊~~

平台	操作路径	退款去向
Apple Store	设置 → Apple ID → 订阅 → 报告问题，以「服务无法使用」为由申请	退回 App Store 余额
Google Play	进入订单记录提交退款申请	退回 Play 余额

_{作者: ideard | 发布时间: 2026-03-27 17:19}

41. [科普向]claude 中转站为什么这么费钱？明明便宜 70%，余额却消耗得飞快

最近在 V2 和 LinuxDo 看到不少人吐槽：中转站价格明明便宜，但余额消耗速度比官方还快。

有人说”自己什么都没做，上下文就已经用了 25K”，有人说”扣费扣得有点快，但看日志每次请求又正常”。

今天算一笔账，看看钱到底花在哪了。

一、缓存率：被忽视的吃钱黑洞
什么是 Prompt Caching ？
大模型每次对话都要重新读一遍完整历史。就像翻译文件，每次都要从头读一遍之前的内容。

Prompt Caching 就是把读过的内容缓存起来，下次直接用。**缓存命中的部分，价格降低 90%**。

Prompt Caching 价格表 ：

操作类型价格倍率说明

正常输入 1x 基础价格

缓存创建（ 5 分钟） 1.25x 首次建立缓存

缓存创建（ 1 小时） 2x 长期缓存

缓存读取 0.1x 便宜 90%

缓存率对成本的影响
核心原理 ：缓存命中的部分，成本只有原来的 10%（节省 90%）。

举个例子 ：

假设你和 Claude 聊了很久，对话历史有 50K tokens 。

官方渠道（有缓存） ：

第 1 次请求：50K tokens 全部计费，建立缓存

第 2 次请求：50K tokens 中 80% 从缓存读取（便宜 90%），只有 20% 重新计算

第 3 次、第 4 次…都是这样

中转站（无缓存） ：

第 1 次请求：50K tokens 全部计费（虽然便宜 70%）

第 2 次请求：50K tokens 又全部计费

第 3 次、第 4 次…每次都全部计费

算一笔账 （ 10 次对话）：

场景首次成本后续 9 次成本总成本

官方（有缓存） 100 9 × 28 = 252 352

中转站（无缓存但便宜 70%） 30 9 × 30 = 270 300

看起来中转站便宜？但如果对话次数更多：

算一笔账 （ 100 次对话）：

场景首次成本后续 99 次成本总成本

官方（有缓存） 100 99 × 28 = 2772 2872

中转站（无缓存但便宜 70%） 30 99 × 30 = 2970 3000

结论：对话次数越多，官方越划算。

为什么中转站缓存率低？
原因一：逆向渠道本身不支持缓存

Kiro 、Cursor 、Windsurf 等客户端的逆向接口，本身就不支持 Prompt Caching 。中转站即使想提供也做不到。

原因二：号池轮询导致缓存失效

中转站用号池轮询分配请求：

第一次请求用账号 A ，缓存建在 A 上

第二次请求分配到账号 B ，缓存全部失效

第三次请求又分配到账号 C ，又要重新建缓存

结果就是：缓存创建多，但命中的少。

原因三：虚标缓存率

有些中转站声称有缓存，实际是站长写死的假数据（比如写死 80%~88%）。

实际情况：缓存率差 10%，长期成本可能更高。

二、隐藏的系统提示词：上下文黑洞
一个真实案例
有人测试发现：

用自己的 Claude Pro 账号，新对话 /context 显示正常

用中转站，新对话 /context 显示已经用了 25K

问客服，客服说”就是官网，不可能是假的”，然后就不解释了。

为什么会有隐藏的系统提示词？
原因一：反代客户端自带的提示词

逆向 Kiro 、Cursor 等客户端的接口，这些客户端有自己的系统提示词（专为代码场景优化）。你的请求会被自动注入这些提示词。你看不到，但它在消耗你的 tokens 。

原因二：中转站自己注入的提示词

有些中转站为了”优化”体验，会注入自己的提示词。这些提示词每次对话都要计算，而且无法缓存。

原因三：多层代理叠加

中转站 A 从中转站 B 拿货，中转站 B 又从中转站 C 拿货。每一层都可能注入自己的提示词。最终到你手上，上下文已经被塞满了。

如何验证？
方法：用 /context 命令对比

用官方账号新建对话，输入 /context，记录基础消耗

用中转站新建对话，输入 /context，记录基础消耗

对比两者差异

判断标准 ：

如果中转站的基础消耗明显高于官方（差距超过 50%），说明中转站注入了额外的系统提示词

这些额外的提示词每次对话都要计算，而且无法缓存

注意：即使是官方账号，新建对话后也会有系统提示和工具的基础消耗，不会是 0

三、切换服务商 + 无缓存 = 双重打击
为什么需要频繁切换？
中转站经常不可用，很多人需要准备多个备用中转站。甚至有人问”怎么快速切换，不用每次都复制 url 和 api-key”——切换频繁到需要专门的工具。

切换的成本
每次切换，缓存全部丢失

举个例子：

你在服务商 A 上聊了很久，已经建立了缓存。现在每次对话成本很低（假设 100 元）。

突然服务商 A 挂了，你切换到服务商 B：

服务商 B 没有你之前的缓存

需要重新建立缓存

首次请求成本：500 元（是有缓存时的 5 倍）

如果一天切换 3 次：

第 1 次切换：多花 400 元（ 500 - 100 ）

第 2 次切换：又多花 400 元

第 3 次切换：又多花 400 元

一天多花 1200 元

切换 + 无缓存 = 双重打击 ：

切换导致缓存丢失（每次切换都要重新建缓存）

中转站本身缓存率低（即使不切换，缓存命中率也低）

双重打击，成本爆炸

四、其他吃钱的坑
扣费 bug
有些中转站存在扣费 bug：

缓存创建和缓存读取计费混乱

重复计费

计费精度问题

套餐陷阱
便宜的套餐往往有日度预算限制，比如 11.90$ 的套餐每天只有 25$ 额度，根本不够用。超出部分按量计费，可能比官方还贵。

贵的套餐又用不完，不用就等于亏了。

不稳定导致的重试成本
有些低价分组很不稳定，不是 api timeout 就是 filter 。timeout 后重试，每次重试都要重新计费。不稳定导致的重试成本，可能比正常使用还高。

五、如何避免被坑
选择中转站的核心原则
原则一：问清楚缓存率

不支持缓存的中转站，再便宜也贵

虚标缓存率的中转站，更坑

要求提供真实的缓存命中数据

原则二：测试上下文消耗

新建对话，用 /context 检查

看上下文是否有隐藏的系统提示词

如果有，立即退款

原则三：算清楚长期成本

不要只看单价

要看缓存率

要看长期使用的总成本

官方 vs 中转站：全面对比

维度官方渠道中转站

月费 $20 （ Claude Pro ）看起来便宜

缓存率 80%~85% 0%~40%

稳定性高差，需要频繁切换

长期成本约 28% 40%~60%

隐藏提示词无可能有

扣费透明度高可能有 bug

结论：短期看中转站便宜，长期看官方更划算。

什么时候可以用中转站？

场景类型是否适合原因

短对话 ✅ 适合上下文少，缓存影响小

临时使用 ✅ 适合不需要长期稳定

预算极度有限 ✅ 适合愿意接受不稳定

长对话 ❌ 不适合上下文多，缓存影响大

重度使用 ❌ 不适合每天高频使用，成本累积

对稳定性有要求 ❌ 不适合不能接受频繁切换

总结

中转站价格便宜 70%，但缓存率低或没有缓存

缓存率差 10%，长期成本可能更高

隐藏的系统提示词，每次对话都在吃钱

频繁切换 + 无缓存 = 双重打击，成本爆炸

最后建议 ：问清楚缓存率、测试上下文消耗、算清楚长期成本。别让”便宜”蒙蔽了双眼，最后发现钱花得比官方还多。

数据来源 ：基于官方以及参考真实用户使用信息，仅供参考

操作类型	价格倍率	说明
正常输入	1x	基础价格
缓存创建（ 5 分钟）	1.25x	首次建立缓存
缓存创建（ 1 小时）	2x	长期缓存
缓存读取	0.1x	便宜 90%

场景	首次成本	后续 9 次成本	总成本
官方（有缓存）	100	9 × 28 = 252	352
中转站（无缓存但便宜 70%）	30	9 × 30 = 270	300

场景	首次成本	后续 99 次成本	总成本
官方（有缓存）	100	99 × 28 = 2772	2872
中转站（无缓存但便宜 70%）	30	99 × 30 = 2970	3000

维度	官方渠道	中转站
月费	$20 （ Claude Pro ）	看起来便宜
缓存率	80%~85%	0%~40%
稳定性	高	差，需要频繁切换
长期成本	约 28%	40%~60%
隐藏提示词	无	可能有
扣费透明度	高	可能有 bug

场景类型	是否适合	原因
短对话	✅ 适合	上下文少，缓存影响小
临时使用	✅ 适合	不需要长期稳定
预算极度有限	✅ 适合	愿意接受不稳定
长对话	❌ 不适合	上下文多，缓存影响大
重度使用	❌ 不适合	每天高频使用，成本累积
对稳定性有要求	❌ 不适合	不能接受频繁切换

_{作者: scf2024 | 发布时间: 2026-03-28 08:40}

42. Claude 官网看个文档都被 ban，有没有解决办法？

浏览器隐私模式+clash+Tun+全局代理，能看 openai 文档，但上 claude 官网依旧会被检测出来，跳转到 https://claude.com/app-unavailable-in-region 页，大家都是怎么解决这个问题的？

_{作者: ex1gtnim7d | 发布时间: 2026-03-28 03:06}

43. 大家帮忙看看跑本地大模型哪个方法更好点, 以及云端调用 api 的方法.

方法一:cherry studio 对接本地 Ollama 跑的大模型, 突破只能聊天的限制
方法二:AnythingLLM+llama.cpp ，可以自己配 gpu 和 CPU 分配。且占用资源少。

第二个问题:
一个任务最后如何做到 80%用本地模型, 最后 20%高精度/高密度的工作才扔给云端来最后进行收尾?

第三个问题:
如何薅羊毛使用云端 api, 比如通过注册机 24 小时产号, 然后本地搭建 sub2api 之类的调用 openai 之类的 token
P.S: 各位能推荐一个注册机吗?

还是大家直接用 cc-switch 呢?

期待各位指点, 不胜感谢.

_{作者: Hermitist | 发布时间: 2026-03-28 17:34}

44. Claude Pro 信用卡频频被拒？用 N26 + Apple Pay 丝滑升级保姆级教程

近被问了好几次”Claude Pro 怎么开通”，说实话，这事卡在支付上的人不少。支付宝不行，微信不行，国内信用卡（包括双币卡）想都不要想，基本上填完卡号点确认，直接就是一个 Card declined 打回来，搞不清楚原因，折腾半天又得重新找路子。

我自己当时也是这样，试了几条路之后发现最顺滑的方案就是 N26 欧洲虚拟卡 。配合众安和 Wise 入金，整条链路打通之后其实没什么难度，就是每一步都有几个坑，没人提前说的话真的很容易卡住。今天把完整流程都写出来，建议先收藏再操作。

出发前先对照准备清单
东西没齐全，中途卡壳会很烦，提前检查一遍：

N26 账户 ：已开通并完成实名，App 里能看到虚拟卡（卡号 + 有效期 + CVV ）

众安银行（ ZA Bank ） ：港元账户，作为整条入金链路的起点

Wise 账户 ：港币换欧元的中转，缺了这个没法低损耗入金

海外网络 ：美国节点，全程不能断、不能切换，这点后面会反复提

Gmail 邮箱 ：注册 Claude 用，国内邮箱成功率玄学

还没有 N26 账户？参考：N26 账户免视频验证”偷渡”实录，半小时丝滑下户

还没有 Wise 账户？参考：2026 最新教程：用身份证开通 Wise 香港、美元账户

还没有香港银行卡？参考：肉身实测：香港一日极限开 4 张卡全流程复盘

第一步：先把钱的问题解决掉
很多人 N26 开好了，对着那个 AT 开头的 IBAN 发了半天呆，不知道钱从哪来。这是整条流程里最容易被忽视但又最基础的一步，先把它搞清楚。

我用的入金链路是这样的：

众安银行（港元）→ Wise 港币账户 → 换汇欧元 → SEPA 转账到 N26

为什么用众安而不是其他港卡？ 众安转 Wise 走的是本地港元通道，免手续费，基本上是秒到的。我试过其他港卡，有的要收跨行费，有的到账要等个把小时，众安是目前这几张里最顺手的，而且开户门槛也最低，基本上申请就能过。

Wise 换汇的步骤：

打开 Wise App ，进入「港币账户」，复制账户号码和 Sort Code

打开众安 App ，发起本地转账，把钱打到 Wise 港币账户，秒到

钱到账后，在 Wise 里发起一笔「港元 → 欧元」的换汇

Wise 用中间市场汇率，手续费大概 **0.4%-0.6%**，换 200 港元损耗不到 2 块钱，基本感知不到

换好之后发起 SEPA 转账，填入 N26 的 IBAN ，收款人写自己名字，打过去基本秒到账 ，N26 App 会直接弹余额通知

每月 Claude Pro 是 20 美元，折合欧元大概 18-19 欧。建议一次往 N26 里打 30 欧 ，不要刚好卡着余额，续费扣款的时候余额不够直接降回免费版，然后还要手动重新触发付款才能恢复，烦得很（我就吃过这个亏）。

第一步：注册 Claude 账号
打开 claude.ai，右上角 Sign up 开始注册。

邮箱选 Gmail
优先 Gmail ，因为可以直接使用 Google 账户登入，如果是其他方式风控的可能性更高所以还是建议使用 Google 的账户最简单。之前也有人反馈用 Outlook 注册没问题，但 Gmail 目前是最稳的，没必要拿其他邮箱碰运气。

手机验证——只能使用国外账户
这里是第一个坑。Claude 注册需要验证手机号，国内 +86 的号码就不要想了，原因是 Anthropic 的短信服务商对部分国家/地区的号码有限制。

解决方案有两个：

有 esim 的直接用（比如 GG 卡） ：以前还是很容易得到的，但是如果没有那就没办法了现在闲鱼也涨价了。

使用第三方接码平台 ：找一些靠谱的第三方接码平台，也是一个不错的选择，价格也在几块钱以内，最好是欧洲的手机号码和你的支付卡一直。

我手里是有现成的 GG 卡，所以直接使用了 GG 卡完成了注册

全程同一个网络，不要切换
网络风控是毕竟严格的一种，如果没搞好很容易出现问题，全程建议不要出现网络切换和网络波动。

最好保持一致的网络环境，这样对你的注册流程是最方便的。

第二步：升级 Claude Pro ，绑定 N26 虚拟卡
账号注册好之后，登录 Claude.ai ，左下角点击头像 → 选「 Upgrade to Claude.ai Pro 」，进入付款页面。

填写卡片信息
打开 N26 App ，进入「卡」页面，找到你的虚拟卡，把三个信息复制出来：

卡号（ 16 位）

有效期（月/年）

CVV （ 3 位）

填入 Claude 的付款表单，这步没什么难度。

支付方式

卡支付：直接输入你刚才复制的内容，然后绑定卡就可以完成支付。

Apple Pay：如果你是 IOS 手机我非常建议使用 Apple Pay 完成购买，现在是通过 Apple Pay 支付是最稳定的。

我这里是选择的 Apple Pay 完成的支付，稳定使用了一段时间没什么问题。如果遇到封号退款概率也是最大的，如果出现问题还可以联系客服。

账单地址
付款表单里有一栏「账单地址（ Billing Address ）」，很多人在这里栽跟头。然后不注意随手填了国内地址，大概率支付的时候会报 Card declined 或者 Do not honor ，报错信息还非常模糊，完全看不出来是哪里的问题，就是一个劲地提示支付失败。

这里还是建议填写你注册 N26 时登记的奥地利地址 ，因为 Apple Pay 会拿你填的账单地址跟 N26 的发卡行记录做比对，这样对风控来说也是风险最小的。

不记得当时填的地址？打开 N26 App → 右下角「我的账户」→「个人信息」，里面有你注册时填的地址，原样搬过来就行。格式参考：
Street: Mariahilfer Straße 100
City: Wien
Postal Code: 1060
Country: Austria
续费维护：别让账号在自动扣款时翻车
Claude Pro 是按月自动续费 ，每月从你绑定的 N26 卡里扣款，金额大概 18-20 欧，视当时汇率略有波动。

这里有个很容易忽视的点：如果续费那天卡内余额不足，Claude 会直接把账号降回免费版，同时发一封「支付失败」的邮件给你。要恢复 Pro 的话，还要先往 N26 补钱，再进 Claude 的「账单设置」页面手动触发一次付款，整个过程折腾起来挺烦的。

我的习惯 ：在手机日历里设一个每月月初的提醒，专门检查一次 N26 余额够不够下个月的续费，确认没问题再关掉。每次往 N26 打 30 欧，基本能覆盖一个多月，安全边际够用。

开通之后
免费版用久了再用 Pro ，最直接的感受就是不卡了。免费版在高峰期经常要等，有时候等到一半还给你一个「 Claude is at capacity 」，Pro 基本上发出去就能回。

用得最多的是 Projects 功能 ，可以建独立的项目空间，给 Claude 设定一段固定的背景信息，这样每次开新对话不用再重新解释”我是谁、我在做什么、我的偏好是什么”，对话质量明显提升，省了很多来回沟通的时间。

上下文窗口也更长，处理长文档、长代码的时候免费版容易在中途截断，Pro 的表现好很多。另外每次 Anthropic 发新模型，Pro 用户也是第一批能用上的。

20 美元一个月，重度用户的话值，轻度用户自己衡量需求。

整套流程踩坑最多的就是三个地方：账单地址最好和你的支付卡的地址一致 、全程网络稳定不要切换 、续费前记得保持卡内有余额 。其他按步骤来基本没什么问题。

_{作者: zp872571679 | 发布时间: 2026-03-28 12:19}

45. K8s Admin：一个轻量级的多集群 Kubernetes 管理平台

K8s Admin：一个轻量级的多集群 Kubernetes 管理平台
背景：我们为什么还需要一个 K8s 管理平台？
2025 年 8 月 1 日，国内最知名的 Kubernetes 管理平台 KubeSphere 突然宣布闭源。官方删除了 Docker 镜像、下架了安装文档、关闭了下载链接，甚至锁定了 GitHub 讨论区——没有任何过渡期。大量在生产环境中使用 KubeSphere 的企业一夜之间被”抛弃”，核心成员当天离职，社区称之为”信任塌方”。

另一边，Rancher 虽然仍在维护，但长期存在的痛点让很多团队望而却步：

太重了 。Rancher 自身就是一套复杂系统，对资源消耗大，管理 20+ 集群时 UI 明显卡顿

升级是噩梦 。社区频繁反馈：哪怕一次小版本升级都可能导致丢失所有托管集群

学习曲线陡峭 。对中小团队来说，Rancher 的功能过于臃肿，很多功能用不上但运维成本降不下来

被 SUSE 收购后 ，社区投入明显减少，重心转向商业版 Rancher Prime

KubeSphere 闭源、Rancher 过重——对于只需要一个简单好用的多集群管理界面 的团队来说，选择并不多。这就是我做 K8s Admin 的原因。

K8s Admin 是什么
K8s Admin 是一个开源的多集群 Kubernetes 管理平台，基于 Next.js 16 和 React 19 构建。它的设计理念是够用就好 ——不做平台的平台，只做一个让你能快速管理多个 K8s 集群的 Web 工具。

GitHub 地址：https://github.com/twwch/next-k8s-admin

核心功能
1. 多集群管理
支持通过 Kubeconfig 、ServiceAccount Token 、EKS Token 三种方式接入集群，一个界面管理所有集群。

2. 完整的资源管理
覆盖日常运维所需的全部 K8s 资源：Deployment 、StatefulSet 、DaemonSet 、Job 、Pod 、Service 、Ingress 、ConfigMap 、Secret 、PVC 、StorageClass 、Namespace 。

支持在线 YAML 编辑，所见即所得。

Deployments Services

3. Pod 终端 & 实时日志
基于 WebSocket + xterm.js 实现的 Pod 终端，直接在浏览器里进入容器 Shell 。实时日志流式查看，不用再切到命令行敲 kubectl logs -f。

Pod 终端实时日志

4. RBAC 权限控制
内置 super-admin 、cluster-admin 、developer 、viewer 四个角色，支持自定义角色。权限粒度细到集群 + 命名空间 + 资源类型 + 操作类型 ，适合多人协作场景。

用户管理角色创建

5. 应用发布 & 飞书通知
支持应用发布记录追踪和回滚。部署时自动通过飞书 Webhook 发送通知卡片，方便团队协作。

发布记录飞书通知卡片

6. 审计日志
所有操作留痕，记录操作人、IP 、时间、动作，满足安全审计需求。

技术栈

类别技术

前端 Next.js 16 、React 19 、Ant Design 5 、Tailwind CSS 4

后端 Next.js API Routes 、WebSocket Server 、Drizzle ORM

数据库 PostgreSQL

认证 JWT 、邮箱验证码

快速体验
git clone https://github.com/twwch/k8s-admin.git
cd k8s-admin
cp .env.example .env
# 编辑 .env ，配置 DATABASE_URL 和 ENCRYPTION_KEY
docker compose up -d
首次启动自动建库、迁移、创建管理员账号（密码在控制台输出）。也支持 npm run dev 本地开发。

和其他方案的对比
| K8s Admin | KubeSphere | Rancher
—|—|—|—
开源协议 | Apache 2.0 | 已闭源 | Apache 2.0
部署复杂度 | 一个容器 + PostgreSQL | 依赖 K8s 集群部署 | 需要独立集群
资源占用 | 极低（~100MB ） | 较高 | 高（建议 4C8G+）
多集群管理 | ✅ | ✅ | ✅
RBAC | ✅ | ✅ | ✅
Pod 终端 | ✅ | ✅ | ✅
上手难度 | 低 | 中 | 高

总结
K8s Admin 不打算做一个大而全的平台，它解决的是一个具体的问题：用最小的成本，让团队能通过 Web 界面管理多个 Kubernetes 集群 。

如果你的团队正在寻找 KubeSphere 的替代方案，或者觉得 Rancher 太重，不妨试试。

GitHub：https://github.com/twwch/next-k8s-admin

协议：Apache 2.0


Deployments	Services


Pod 终端	实时日志


用户管理	角色创建


发布记录	飞书通知卡片

类别	技术
前端	Next.js 16 、React 19 、Ant Design 5 、Tailwind CSS 4
后端	Next.js API Routes 、WebSocket Server 、Drizzle ORM
数据库	PostgreSQL
认证	JWT 、邮箱验证码

_{作者: jaycee110905 | 发布时间: 2026-03-29 04:46}

46. koog 中文文档

https://koog.marquez.top

学 koog 的时候没有找到中文文档，官方也没有做国际化，所以我自己翻译了一个。有需要的朋友可以试试，如果文档翻译有误可以提一下 issue 。

我 fork 了官方仓库，新增了一个 zh 目录，接下来会随着 koog 的 release 同步更新。翻译用的 deepseek 。

_{作者: Yasuke | 发布时间: 2026-03-28 14:41}

47. 想要一个 codex/claude code 的 Web UI 界面

背景：我本地配好了 codex ，想让非技术同学用。不是写代码，是想做一些数据分析之类，主要能连数据库。

在他们本地配置比较麻烦，同时我又想管控这个权限。所以想要一个 Web 环境的 codex 。

看了下，Github 上有一些开源的项目。但是都不怎么活跃。比如 https://github.com/harryneopotter/Codex-webui https://github.com/friuns2/codex-web-ui

类似需求，大家都怎么搞呢？

难道真要搞个服务器，让他们 ssh 上面，自己跑吗？

_{作者: inza9hi | 发布时间: 2026-03-28 07:35}

48. 🔥 Dooong · AI 一个公益 AI API 站点提供免费 CodeX/GPT5.4 模型 API 接入

1. 站点简介
Dooong AI 是一个公益性质的一站式 AI 模型 API 中转服务站点。目前基于 CodeX 号池向所有用户提供完全免费 的 AI API 接入服务。

官方网站 : ai.dooo.ng

Telegram 社群 : Dooong 社区

图床支持 : Dooong 图床

2. 可用模型列表
所有模型均已支持 thinking 参数，最高兼容 xHigh 推理强度。

系列模型 ID

GPT-5.1 系列 gpt-5.1, gpt-5.1-codex, gpt-5.1-codex-max, gpt-5.1-codex-mini

GPT-5.2 系列 gpt-5.2, gpt-5.2-codex

GPT-5.3 系列 gpt-5.3, gpt-5.3-codex

GPT-5.4 系列 gpt-5.4

3. 接入指南
3.1 接入流程

访问官网 : 进入 ai.dooo.ng。

邮箱注册 :

支持后缀：[gmail.com](http://gmail.com), [outlook.com](http://outlook.com), [qq.com](http://qq.com), [163.com](http://163.com), [nodeseek.org](http://nodeseek.org), [seek.li](http://seek.li)。

获取订阅 : 注册即自动配发 Free-CodeX 订阅计划。

创建密钥 : 前往 我的账户 - > API 密钥 生成 Token 。

调用服务 : 在任何兼容 OpenAPI 规范 (OAS) 的工具中使用。

3.2 API 配置信息

配置项详细信息

根地址 (Base URL) <https://ai.dooo.ng/v1>

认证方式 (Auth) Bearer Token (API Key)

数据格式 (Format) application/json

4. 状态监控
用户可以在管理面板中查看各个模型的连通性，或访问状态页获取详细信息：

状态查询 : ai.dooo.ng/status

备注 : 相关 API/OpenCode/ClaudeCode/OpenClaw 接入及推理强度调用文档正在编写中，后续将通过 TG 社群及网站公告发布。

Image storage powerd by Dooong 图床

系列	模型 ID
GPT-5.1 系列	`gpt-5.1`, `gpt-5.1-codex`, `gpt-5.1-codex-max`, `gpt-5.1-codex-mini`
GPT-5.2 系列	`gpt-5.2`, `gpt-5.2-codex`
GPT-5.3 系列	`gpt-5.3`, `gpt-5.3-codex`
GPT-5.4 系列	`gpt-5.4`

配置项	详细信息
根地址 (Base URL)	`<https://ai.dooo.ng/v1>`
认证方式 (Auth)	`Bearer Token` (API Key)
数据格式 (Format)	`application/json`

_{作者: WizisCool | 发布时间: 2026-03-25 23:17}

49. 多 Agent 系统里的「提示词漂移」问题，你们怎么解决的？

最近在用 OpenClaw 跑多 Agent 协作系统，遇到一个很头疼的问题：提示词漂移（ Prompt Drift ）。

具体现象是这样的：

一个 Agent 做了某件事，把结果写进 memory ，下一个 Agent 读了这段 memory 之后，它的行为出现了微妙的偏移——不是错的，但和预期有差距。这种偏移在多轮任务后会叠加，越跑越偏。

我观察到几个规律：

1. Context 越长，漂移越明显 —— 特别是有很多 memory bank 内容的时候，模型倾向于迎合上下文而不是执行指令
2. Agent 数量越多，问题越复杂 —— 9 个 Agent 同时运行时，某个节点的漂移会通过 memory 传染给后续 Agent
3. 不同模型漂移程度不同 —— 实测 Claude Sonnet 比 GPT-4o mini 稳定很多，但成本差 10 倍

我目前的应对方案：

- 每隔 N 轮任务，强制重置 Agent 的工作记忆（只保留核心 memory ，清空临时 context ）
- 给每个 Agent 写「人格锚点」—— 在 system prompt 里明确说「你是 XX ，你的核心职责是 YY ，遇到矛盾时优先遵循 ZZ 」
- 对关键输出做格式校验，不符合预期结构的就打回重做

但感觉这都是治标，想知道大家有没有更系统的解法？

特别想了解：
- 有没有好用的 prompt 版本管理工具？
- 多 Agent 之间的 memory 隔离怎么做比较合理？
- 有没有实测过的「漂移检测」方案？

更多 Agent 实战踩坑记录在公众号「 Wesley AI 日记」，欢迎来聊。

_{作者: caesor | 发布时间: 2026-03-28 08:58}

50. 求推荐一个 go 里运行 js 的方案

目前试用了 goja ，很好用，就是语法不全，新一点语法的跑不了。

_{作者: hanxiV2EX | 发布时间: 2026-03-28 05:38}

V2EX 热门帖子

1. 2026 年了，程序员用 chrome 还是用 Safari 比较多？可以说一下推荐的原因吗？

2. 基于微信 iLink API，微信可以连上 Claude、Code、Copilot、Qwen、Gemini、OpenCode 等各类 Agent！

3. Claude Code 百万级逆向文档！

HitCC——近百万字级 Claude Code 逆向文档

文档覆盖范围

4. windows 11 现在问题还多吗

5. claude 到底应该算是“通用”大模型还是“垂域”大模型

6. 当大模型失去“品牌光环”，你还能分辨出谁更聪明吗？——我做了一个 AI 盲测竞技场

7. 简单梳理一下 llm 开发的变和不变？这个对吗。

8. 升级了一下自己写的 Codex 切换应用

9. AI 盛行的当下，做 美颜 SDK 开发还有市场吗？

10. 陪伴我最久的一台服务器，到底是没见到 2025 年的春节，让我升级坏了报废。

11. ai-menshen：一个轻量级、本地优先的 Go 代理，用于 OpenAI 兼容的 API，旨在审计、缓存

12. 一直用 opus-4.6，但是最近谷歌反重力 Antigravity 的 ultra 家庭组不耐用了，超级不耐用

13. 今天双倍快乐🎉结束了 感觉用量刷刷往上涨

14. API 工具并没有变得更好，只是我们降低了期待

最容易改善的那部分 API 问题，已经被 AI 戏剧性地改善了

真正的问题从来不只是文档

design-first 适合的是“人和人协调”的时代

AI 让这个问题更明显，而不是更不重要

是时候重新认真对待 API tooling 了

15. 小白想做一个爬大麦演出信息的脚本, 但遇到滑块验证码不知道怎么办

16. JennaPress 开源 CMS 获得第一个 Stars

17. 还是要用 ubuntu

18. you-should-use - 一个提醒你使用别名和现代命令的 Shell 插件

19. mac 上免费的录屏软件

20. 感觉 mimo-v2-pro 比 glm5 厉害

21. Windows 文件路径长度限制是多少个字符？ 244、255、256、260？「启用长路径」有用吗？

到底是多少个字符？

256

244

「 8.3 文件名」是什么？

255

「启用长路径」有用吗？

单个文件、文件夹的名字上限还是 255

长路径语法 \\?\

PowerShell 7

多层文件夹的路径上限

第三方软件的支持情况

PikPak

总结

参考资料

更新日志

22. 太离谱了，改名叫离谱云吧

23. [开源] 当 AI Agent 学会三思而后行

背景：养虾繁荣背后的隐忧

双脑架构：一种新的安全范式

技术实现深度解析

审查管线集成

审查 Prompt 设计

智能跳过机制

技术权衡与思考

结语：AI Agent 安全的必经之路

24. 我想用 phpstorm + wsl2 + docker desktop 作为开发环境，有没有什么建议的。

25. C++实习，求大佬解答

26. 腾讯云香港，我放个爬虫爬海外网站

27. Obsidian 写作环境搭建：这 6 款插件让我的博客管理效率翻倍

安装

主题：AnuPpuccin

插件配置

Custom Attachment Location

Dataview

Enhancing Export

Git

Local Images Plus

Templater

迁移途中踩的几个坑

Halo 导出的是 HTML ，不是 Markdown

HTML 转 Markdown 格式混乱

图片链接失效

我现在的工作流

Halo → Obsidian

Obsidian + Claude Code 创作流

总结