这种群，他 5 个人里骗 1 个，被骗的出来曝光，剩余 4 个没被骗的还会帮着群主说话
看看这帖子里的回复

@jetsung

感谢，居然是 CNAME 解析，我还以为是 TXT 呢（毕竟 ACME-Challenge 就是 TXT ），拨云见日啊~

@mynameisK

你是真神探。

当然不是机场，这是我自己部署的 Drone CI ，里面一堆流水线天天运行，npm/docker 一个劲拉取。
我这个服务器也是国内的实名制的厂商，协议明说不允许搭代理的。

@nc
哈哈哈，你说的一点毛病没有。
不过 Rest API + Skills 其实已经很接近 MCP 了，MCP 不也是用一个 JSON 把参数格式描述定义好，然后让 AI 来按需调用嘛，本质上已经差不多了。

MCP 有一个好处是对 AI 只暴露接口，业务逻辑在外部实现，这样就算你的 Agent 没有沙箱也能接；
Skills 要让 Agent 执行代码，会多消耗一部分 token ，然后必须有代码沙箱，不然跑不起来。

#4 说的对，Skills 更多用于扩展 AI 的能力，MCP 用于连接外部系统。

现在做的好的 Skill 都带 /srcpits 目录，里面有一堆 py/js 代码，很多 Agent 都有沙箱环境，可以运行这些代码；
那你把 MCP 里的逻辑放到 Skill 的 /scripts 目录里，让 Agent 执行，其实也能实现和 MCP 类似的效果，但就是会浪费很多上下文，浪费 token ，而且很难保证 AI 每次都能乖乖按照预期跑。

MCP 就是把这部分代码实现分离出去，只对 AI 暴露 “调用 XX 工具” 这一个工具，附带参数格式；
AI 只需要发起一次工具调用就能解决问题，最多可能参数有点小错，AI 会根据报错提示自动重试。
（例如，输入地址 “苏州工业园区”，看似正确对吧？其实少了一个 “市” 字，AI 提交了报错就马上改对了）

更何况 “连接到外部系统” 这个诉求 Skill 无法替代，比如通过获取某地区交通情况，你总不能让 AI 开天眼去监控街区吧，这个你用 Skills 去做，也是要通过百度地图 API ，要么 AI 自己写代码，要么 AI 去操纵网页，还不如直接接入百度地图 MCP 。这一点和 #2 说的一样。

@0x1001 我看了以下 Qoder 的这个，和 Anthropic 的差不多，可以直接参考 Anthropic 的 Skills：
https://github.com/anthropics/skills

很多年前知乎就支持“接力”了

@s1n1an 图片没贴好，点开链接看吧……

从 Qoder 里逆向出来的 skills ，跟这个差不多

比如处理 docx 的 skill ，非常完整，包括了一系列代码和规格文件：


Agent 两大本质：工具调用（这个是主要的，MCP 也是工具调用）、提示词管理（ Markdown 小作文）

豆包/千问帮用户点外卖是工具调用； Agent 弹出个表单或者选择框让用户选择，也是工具调用； Agent 列出一个 Todo 清单，也是工具调用； Manus 的 Agent 可以读写文件沙箱、可以在沙箱里运行 Shell 命令，也是工具调用； Claude Code 在本地 ls 列出代码、grep 查询代码，也是工具调用。

但是，把上面每一个工具注册给 Agent ，都需要一个配套的 Markdown 小作文。

把 Skills 注册给 Agent 也要小作文；规范工具的调用方式，例如 Todo 清单只允许从上往下 done ，不允许修改已 done 的项，这也需要小作文，不然这个 Todo 会跳着执行或者突然被改掉了；很多 Agent 提供的例如 “深度研究”，其实也是提供一个 Markdown 小作文给 Agent ，让它的输出更高大上。

DlerCloud 我感觉应该挺出名的，他们赞助了 OpenClash ，OpenClash 自带一个登录账号的页面……

支持，希望提高稳定性

@w568w 感谢解答，确实是心理作用，毕竟我以为是 CUDA 禁用了，现在懂了

打印日志，看到 useSession() 在服务端预渲染时，返回始终是 { data:null, isPending: true }，这是对的，符合预期；
那问题就出在 useSession() 在客户端运行，应该是客户端运行时，页面右上角的登录态渲染的比较早，触发了 useSession 并发送请求，此时页面内深层的组件还没加载出来时，然后 useSession 提前拿到返回值了，这就导致后续组件渲染时是已登录状态，与服务端未登录的状态不一致，触发 Hydration Error

@Razio
全部 SSR 肯定没问题，也不会有 Hydration Error ；哪怕用根 HydrationBoundary 把登录状态提前 prefetch ，也不会报错的，我上面就说了呀。

我主要是希望尽可能多静态渲染，只有非 SSR 不可的页面再 SSR ；
右上角那个登录状态，所有页面都要用，所以要是这里用 SSR 来读 cookies 的话所有页面都是 SSR 了，不符合需求；
所以我之前和 4 楼说的一样，右上角那个登录态做成客户端组件，用 useQuery 去查登录态，请求返回之前有个 loading 的样式占位，这一切正常。

现在问题，只要客户端组件多处用到 useQuery （或者 better-auth 的 useSession ，也一样） 来查询登录态，居然能出现 Hydration Error ，这是客户端组件啊，刷新 N 次就能复现一次；如果是上级 layout.tsx 用 SSR 把数据注入 <HydrationBoundary>，那触发的更频繁了，基本刷新 2 次就复现一次。
当然是登录时才有这 Error ，退出登录就好了，刷新 100 次也没 Error 。

对登录 hook 的返回值打 log 发现，如果是这个顺序：A undefined 、B undefined 、C undefined 、A 已登录、B 已登录、C 已登录，这样就正常；
报错的时候是这样：A undefined 、A 已登录、B 已登录、C 已登录，或者是：A undefined 、B undefined 、A 已登录、B 已登录、C 已登录，这样就报错了；
难不成 useQuery() 在预渲染的时候返回值不稳定？如果变的时机提前了，例如在 B 代码运行前就变了或者在 C 代码运行前就变了，就导致后续的若干个组件出问题？

请求数据也都是先根据 isPending 再根据 data 来读取的，想不明白怎么还能这样；本来我以为是 better-auth 的 isPending 有问题，查了一下，确实之前有这个 bug ，但是五月份已经修复并 merged 了；也试了一下不根据 isPending 也是有问题。

也像我说的一样，如果用 useMounted() 来提前区分一次，这样也是 100% 不报错的；
所以我觉得是 Next.js 在预渲染的时候出问题了？毕竟就算是客户端组件也会预渲染。

@heishu 用 middleware 的话也是，所有页面失去 SSG ，和 HydrationBoundary 是一样的

这 VSCode 最近更新的都是啥啊，这两天 ESLint 的扩展也是，更新后直接挂了不能用，一堆 Issue ，降级后发现上个版本还是 2023 年的笑死

估计是爬虫，我去年就遇到了，47.128.xx.xx 的 IP 段一个劲抓取我博客页面，后来遇到阿里云的，UCloud 的，每次我都去手动屏蔽，然后去填单子举报。
上 CF 会影响国内访问的体验，非必要还是不太推荐的。

用智能家居，不是得买个带蓝牙网关的最好嘛，不然家里那些温度计、灯泡之类的，都是要用蓝牙，你还得再买个蓝牙网关，岂不是有点麻烦……

然后 Home Assistant 也是占内存的，配置上最好 512MB 内存

选路由器推荐上这个网站（猫点饭），能看详细配置，不是广告： https://mao.fan/select