智能助手网
标签聚合 习惯

/tag/习惯

linux.do · 2026-04-18 15:25:31+08:00 · tech

刚转运维那会儿有个挺明显的习惯,到现在偶尔还会犯:服务一出问题,第一反应就是是不是代码又写崩了。可能跟之前做测试有关系,那时候基本所有问题最后都能落到代码上,久了就会下意识这么想。 但干久一点之后发现,有些问题你把代码翻几遍其实没什么用。 之前遇到过一个事还挺典型的。有个服务发完版之后开始偶尔超时,不是一直挂,就是那种隔一阵来一下的,很烦。当时第一反应肯定是代码问题,刚发版嘛,然后就很自然去看改动、怀疑某段逻辑,甚至都准备回滚了。结果回滚完还是会偶尔出现,当时就有点懵。 更离谱的是日志也没啥明显异常,就那种你感觉不对,但又说不上哪不对。那段时间其实来回看代码好几遍,也没什么新发现,有点钻牛角尖了。 后面也是没办法了,才开始往别的方向看,去看机器、连接数、一些运行时状态。最后才发现是连接数在某些时间段被打满了,新请求卡在建连上,看起来就像接口超时。这种东西你要是一开始就死盯代码,其实很难想到。 后来类似的情况也遇到过几次,慢慢就有点感觉了:有些问题不是“写的时候就错了”,而是“跑着跑着出问题”。比如配置稍微有点偏、资源顶到边上、网络偶尔抖一下,或者 k8s 调度有点歪,单看都还行,但叠在一起就开始出事。 现在再看问题会稍微控制一下自己,别一上来就扎进代码里,不然很容易越看越觉得就是代码问题,然后一路跑偏(虽然有时候最后还真是代码 )。 这两年也试过用 AI 帮忙看日志,有时候确实能帮你收敛一下范围,但也有那种越看越不对劲的情况,尤其这种不是单一原因的问题,它给的结论有时候挺自信的,但不一定对,所以现在基本当参考用。 也没啥总结,就是最近又遇到一个类似的,有点感慨。有人也遇到过这种吗,一开始死盯代码,最后发现完全不是那回事的那种。 2 个帖子 - 2 位参与者 阅读完整话题

www.ithome.com · 2026-04-18 09:54:51+08:00 · tech

IT之家 4 月 18 日消息,搜狗输入法 4 月 17 日发布《致搜狗输入法用户的一封信》,表示将在 2026 年 4 月至 7 月逐步实现账号的多设备统一,并计划在 5 月份推出跨设备复制粘贴功能。 IT之家附具体内容如下: 亲爱的用户朋友: 长期以来,我们收到许多用户的反馈,希望不同设备间的输入体验能更加统一。为响应大家呼声,自 2026 年 4 月下旬起至 7 月,我们将逐步实现账号的多设备统一。升级完成后,无论你是更换新设备,还是在多个设备间切换使用,只要登录同一账号 (支持不同登录方式), 输入习惯、内容列表等都将自动同步 ,为你带来更统一、更便捷的输入体验。 整个升级过程将由系统自动完成,无需你额外操作,也不会影响正常使用。如在升级期间遇到账号相关问题,欢迎通过应用内反馈、用户社群、客服邮箱 (IMETS@ tencent.com ) 等渠道联系我们,我们会第一时间帮你核查处理。 此外,我们计划在 5 月推出跨设备复制粘贴功能,敬请期待! 感谢你一直以来对搜狗输入法的支持。 搜狗输入法团队 2026 年 4 月 17 日

linux.do · 2026-04-16 16:48:06+08:00 · tech

前几天地铁上突然想起有个 bug 要改,习惯性想掏手机让 Claude Code 处理,然后卡住了。 claude 是终端工具,电脑在家关着呢。 试了几种方案都不顺手: Tailscale + Termux + tmux:配得累,触屏 SSH 反人类 claude.ai/code 网页版:读不了本地文件,只能操作 GitHub @claude Action:异步,反馈慢,不能交互 Codespaces / Gitpod:容器环境,不是你的本地 后来翻到 Happy 这个开源项目( GitHub ,MIT),装完 5 分钟跑通。写下来给有同样需求的佬友参考。 它到底是啥 简单说,电脑上的 Claude Code 还是本地跑(能读写你的本地文件),手机 App 走一个加密中继,当电脑的遥控器。 ┌─────────┐ ┌──────────────────┐ ┌─────────┐ │ 手机 │─E2EE──│ Happy 中继服务器 │─E2EE──│ 电脑 │ │ App │ │ api.happy.eng │ │ happy │ └─────────┘ │ (Cloudflare 前) │ │ wrapper │ └──────────────────┘ └────┬────┘ ▼ ┌──────────┐ │ Claude │ │ Code进程 │ │ + 本地FS │ └──────────┘ 三个点搞清楚就没误区: CC 真跑在你电脑上 ,文件操作、git、跑命令,全是本地发生 手机不直连电脑 ,中继在中间转一道,所以不用公网 IP、端口转发、同网段这些破事 全链路 E2EE (Signal 协议),中继服务器看不到明文 另外 happy 只是 claude 的 wrapper,原来的 claude 命令你想单独用照用,没影响。 装起来其实就一行 电脑这边(Node 18+,CC 已装好): npm install -g happy 注意别装 happy-coder ,那是旧包名已经弃了。然后进项目: cd /path/to/project happy 终端会蹦出一串 ASCII 二维码。手机应用市场搜 Happy Coder ,iOS/Android 都有,扫码配对完事。配对成功电脑会提 “Paired with …”,手机那边 session 也出来了。随手发一句 list files in current directory 试试,看电脑执行、手机收到回显,通路就是对的。 顺带一提,我习惯加个 alias 让它更顺手: hc() { command happy --yolo "$@"; } # --yolo 跳确权 --yolo 等于 --dangerously-skip-permissions 。我自己用是因为烦它每步都弹确认,但第一次玩不建议开------先让它弹,你才知道它在干啥。 会话归谁、怎么接管,这里很多人绕晕 我自己刚开始也没搞明白,后来发现就三种情况: 会话起点 怎么接 电脑 happy 起的 手机 App 自动出现,点进去就接管 手机端新建的 需要电脑 happy daemon 常驻才能接住 电脑想续手机起的 happy resume <id> 或 happy --resume 列最近的选 happy daemon 就是让 happy 常驻后台。不跑 daemon 手机也能新建,但只落在手机本地临时容器里,功能不全。跑了 daemon 才是完整的「手机发起、电脑干活」。 这里有个坑要先说:手机新建会话的 第一条消息可能被吞 ( issue #637 挂了)。我自己踩过,之后的习惯是先发一条 hi 探路,第二条再发正事。 日常怎么用 我自己现在的用法大概三种。 一是电脑起、手机接。办公室 happy 开着写代码,到饭点关笔记本就走。地铁上想继续,手机 App 点开那个 session 追问、看进度。回家 happy resume 续上,中间 CC 一直是同一个上下文。 二是手机起、电脑干活,这个最爽。躺床上突然想改个啥,手机 App 直接发指令。电脑挂着 daemon,一收到就开跑,测试、改文件、提 PR 都 OK。推送打到手机,你看一眼确认下一步或者继续睡。 三是多 session 并行。电脑开两个终端各跑一个 happy 对应两个项目,手机 App 里就是两个 session 并列,切哪个干哪个。 高频功能顺手列一下:输入框 @ 能浏本地文件树, /clear /compact 这些斜杠命令全支持, ~/.claude/agents/ 和 skills 自动可用( @code-reviewer 手机端调都没问题),长按麦克风语音转文字,要确权时推送直接打过来点一下就批。 国内用会遇到什么(重点) 既然发 Linux.do ,这段重点说。常见症状大概这几种: 扫码一直卡 Pairing------手机连不上中继 配对上了但 session 不同步------一头断流 用几分钟自动断------TCP 长连接被重置 语音转文字巨慢------媒体走另一通道,被限速了 解法从轻到重排: 最轻:电脑挂代理 export HTTPS_PROXY=http://127.0.0.1:7890 export HTTP_PROXY=http://127.0.0.1:7890 happy Clash / Surge / V2RayN 随便哪个,规则覆盖 *.happy.engineering 就行。嫌麻烦丢 .zshrc 一劳永逸。 手机也走系统代理 iOS 用 Surge / Shadowrocket 设全局或对 Happy 分流,Android 用 Clash for Android 同理。扫码一直 Pairing 基本靠这一步就通。 一劳永逸:自建中继 后端开源,docker 一条命令起: git clone https://github.com/slopus/happy cd happy/server docker compose up -d # 默认 3000,前面套 nginx + Let's Encrypt 上 HTTPS 改个指向就完事: # 电脑 export HAPPY_RELAY_URL=https://your-relay.example.com # 手机 App → 设置 → Custom Relay → 填 URL 我自己的分工:日常手机控 CC 全用 Happy;Happy 中继抽风、或者想看实时日志、跑非 CC 命令,回 SSH + tmux a 。电脑端顺手用 tmux 包一层 happy( tmux new -s happy → happy → Ctrl+b d ),出门关窗口也不耽误它后台跑。 装之前建议看一眼的坑 问题 怎么弄 happy: command not found npm config get prefix 看下全局 bin 在不在 PATH 二维码扫不出 终端字体放大,或 happy --pair-url 拿链接手输 同步延迟 5 秒+ 挂代理或自建中继 手机 App 闪退 常见于低端安卓,RN 吃内存,杀后台再开 手机新建会话首条没反应 #637 ,先发条 hi 探路 手机发消息电脑崩 SIGTERM #982 ,升级最新版或重新配对 配对设备列表满 App 设置里删旧设备,免费版有上限 要不要装 看一件事:你出门的时候想不想给 CC 派活。 经常有这需求就装吧,体验甩 Termux 几条街,不受触屏那份罪,也不用维护 Tailscale。从不离开电脑的话,那没必要,多一个组件而已。如果你介意流量过第三方,要么自建中继要么别用,官方的再 E2EE,元数据(你在用啥、什么时间用)还是上第三方。 至于要不要自建中继,偶尔用就官方加代理凑合;每天用的直接自建,回报远超一台 VPS 的成本;商业或涉密基本没得选,必须自建。 相关链接: 项目: GitHub - slopus/happy: Mobile and Web client for Codex and Claude Code, with realtime voice, encryption and fully featured · GitHub CLI: GitHub - slopus/happy-cli: Happy Coder CLI to connect your local Claude Code to mobile device · GitHub 官网: https://happy.engineering Quick Start: Quick Start Guide FAQ: General FAQ 先写这些。踩到别的坑、或者自建中继有更好配置的,评论区交流。 1 个帖子 - 1 位参与者 阅读完整话题

linux.do · 2026-04-16 13:16:22+08:00 · tech

Anthropic Claude Code 团队工程师 Thariq Shihipar 发布长帖,系统讲解 Claude Code 升级到 100 万 token 上下文窗口后如何管理会话,同时宣布更新了 /usage 面板,帮助用户了解自己的使用模式。 帖子的核心概念是「上下文腐烂」(context rot):随着对话变长,模型注意力被分散到越来越多的 token 上,旧的、无关内容开始干扰当前任务,模型表现因此下降。百万上下文让任务跨度更长,但并不意味着可以无限堆积对话。 Shihipar 认为用户最该养成的习惯是 rewind(双击 Esc 键)。当 Claude 尝试了一种方案但失败时,多数人的本能是发一句「这个不行,试试 X」,但更好的做法是回退到方案执行前,把失败经验写进新提示词重新来过,而不是让失败的中间过程留在上下文里占用注意力。 关于上下文压缩(compaction),他指出一个反直觉的问题:模型在最需要聪明的时候反而最笨。压缩发生在上下文即将撑满的时刻,此时上下文腐烂最严重,模型判断力最差,容易丢掉关键信息。典型场景是一轮长时间的调试后触发自动压缩,模型把摘要聚焦在调试过程上,而用户下一步想处理的其他问题被丢弃了。百万上下文给了用户更多余裕,可以在手动输入 /compact 时附加指令(如「只保留 auth 重构相关内容」),主动引导压缩方向。 他还建议将子代理(subagents)视为上下文管理工具:把会产生大量中间输出、但只需要最终结论的任务交给子代理,在独立的上下文窗口中完成,只将结果带回主会话。判断标准是「我需要的是过程还是结论」。 用户在每一轮对话结束后实际上面临五个选择:继续对话、rewind 回退重试、/clear 清空重新开始、/compact 压缩继续、或派出子代理。新任务开新会话,相关任务(如刚写完功能接着写文档)可以留在同一会话以复用已读取的文件。 https://x.com/trq212/status/2044548257058328723 4 个帖子 - 3 位参与者 阅读完整话题

linux.do · 2026-04-14 09:58:08+08:00 · tech

每一次技术革命的初期,人们总是习惯性地拿着旧时代的地图,去寻找新大陆。 如果你今天去看看所谓“AI智能体”的圈子,会发现一派热闹非凡的景象。大大小小的平台都在推出所谓的“Skill(技能)商店”、“插件集市”,他们鼓励开发者去编写各种各样的Skill——查天气的、搜网页的、调取某某数据库的。整个行业似乎都在为这种“乐高积木式”的繁荣而狂欢。 但在这种喧嚣背后,掩盖着一个荒谬的逻辑断层。剥开所有的产品包装与营销话术,用纯粹的工程视角和商业本质去审视,会发现今天行业里风靡的绝大多数“Skill”,不过是AI时代的工业垃圾。 一、 刻舟求剑的“收租旧梦” 要理解Skill为什么是垃圾,首先要扒开它的底裤,看看它到底是个什么东西。 在现有的应用架构里,一个Skill,本质上就是一段简短的胶水代码(Payload),外加一段API接口的说明书(JSON Schema)。它告诉大模型:“我这里有一个工具,叫什么名字,能查什么数据,你需要传给我什么参数。” 就这么一层薄薄的窗户纸。 为什么行业里的大厂和SaaS平台要煞有介事地把它包装成一个独立的概念,甚至要搞出“技能商店”? 答案很简单:这是Web2时代残存的路径依赖,是“平台方”企图继续收租的旧梦。 在移动互联网时代,App是流量的入口,是生态的护城河。苹果和安卓通过App Store建立起了牢不可破的商业帝国。今天做AI平台的这批人,脑子里依然是这套古典的流量逻辑。他们企图把大模型强大的动态生成能力,强行阉割、固化成一个个静态的“插件(Skill)”,然后摆在货架上。 他们试图制造一种人造的稀缺性,让用户觉得“我的Agent比你的强,是因为我挂载了更多牛逼的Skill”。 这是一种极其悲哀的刻舟求剑。大模型的本质,是知识的压缩和逻辑的涌现,它是一种动态的、液态的智力。而现在的平台方,非要把这种液态的智力,重新冻结成工业时代的标准件(Skill),再按件计价卖给你。 二、 中间态代码的归零 为什么说这种“标准件”在今天毫无价值? 因为在顶级的大语言模型面前,执行层面的动作,获取成本已经无限趋近于零。 在过去,你需要一个工程师写几天代码,去打通一个系统的接口,处理各种鉴权、解析和错误重试。这段代码是有价值的。 但在今天,只要你有一份清晰的接口文档,模型能在几秒钟内给你生成一套极其完美的调用逻辑。这种几十行、上百行的微观指令和胶水脚本,根本不配被称为“独立的技术”。 既然AI可以随时、随地、针对任何接口瞬间写出调用代码,我们为什么还要提前把这些代码写死,打包成一个叫“Skill”的东西存起来? 囤积Skill,就像是在自来水管已经铺好、随时可以拧开水龙头的时代,你还在家里院子里摆满了几百个水缸存水。这种做法不仅臃肿,而且可笑。那些为了微观指令而沾沾自喜的开发者,没有意识到他们正在囤积的是必定会被时代淘汰的工业废料。 三、 虚假的通用性与复杂的商业现实 有人或许会辩解:平台提供的Skill是经过测试的、通用的,可以节省开发时间。 这恰恰暴露了他们对真实商业世界运作规律的无知。在真正的高阶应用环境,尤其是企业管理和商业决策的深水区,微观动作的“通用性”是一个彻头彻尾的伪命题。 真实的商业世界是泥泞的、复杂的,充满了利益博弈和历史遗留问题。A公司的“查询子公司季度业绩”动作,和B公司的同一个动作,背后对接的ERP系统结构、财务指标的统计口径、甚至部门之间的权限壁垒,是完全两码事。 你妄图用一个在云端封装好的、标准化的“财务查询Skill”去适配所有企业的复杂环境?这就好比你想用一把工厂流水线生产出来的万能钥匙,去开全世界所有精密定制的保险箱。 真正有价值的工具调用,必须且只能基于此时此刻的特定环境上下文,临时写、动态生成。场景不同,环境不同,代码就必须不同。提前封装好的静态Skill,一旦脱离了它预设的温室环境,扔到真实的商业战场上,瞬间就会因为水土不服而崩溃。 四、 基础设施的推土机 如果微观的执行动作全都是现写现用、阅后即焚的,那么系统靠什么来维持稳定? 答案是:标准化的底层协议。比如现在开发者圈子里真正具有战略价值的MCP(模型上下文协议)。 很多人把MCP和Skill混淆,或者认为MCP只是为了更好地“连接Skill”,这是严重的本末倒置。 MCP的真正使命,不是去连接那些静态的Skill,而是为了最终消灭它们。 MCP提供的是一条绝对标准、底层统一的互联总线。当企业内部的财务数据库、人事系统、甚至是复杂的商业推演沙盘,都通过这种标准化协议暴露为上下文节点时,你的智能体根本不需要提前安装任何“技能”。 在这个终局图景里: 智能体感知到管理动作的需求 \rightarrow 动态理解当前的企业架构和数据总线 \rightarrow AI基于现状,临时、一次性地生成一段指令,通过MCP协议去完成数据的调取或动作的下发 \rightarrow 动作完成,代码丢弃。 这叫做“Just in Time(即时制造)”的智力。协议是铁打的营盘,是真正的高速公路;而运行在上面的具体指令,就是随时生灭的过客。我们只需要修好高速公路,根本不需要去圈养那些跑在路上的马车。 五、 护城河的转移 当我们把这个行业的底裤彻底扒开,当所有关于“执行”、“调用”、“接口”的代码都变得一文不值。如果一切外部工具都可以被AI瞬间捏造,那么AI应用的真正壁垒究竟在哪里? 答案是:结构化的业务认知与对权力的感知。 对于一个真正面向董事长、CEO等核心决策层的“AI管理专家”来说,它的价值绝不体现在它菜单里列着一百个炫酷的Skill。 高管不需要一个会帮你填表格的机器人,更不需要一个只会执行“查询”指令的检索工具。 真正的高阶智能体,它的护城河深埋在它对复杂系统的诊断直觉里。 当系统发现某条业务线的利润率出现异常时,低级的工具只会机械地调取财务报表(这是所谓Skill的做法); 而一个具备深厚管理认知的智能体,能够敏锐地穿透数据,意识到这可能是该业务线一把手和二把手近期权力博弈导致的资源内耗,从而自主决定去调取近期的人事审批流转记录和关键岗位的沟通频率。 执行一个指令极其廉价,但知道“在当前这盘错综复杂的棋局中,此刻该走哪一步”极其昂贵。 真正的壁垒,在于你赋予这个AI系统的思考框架:它是否拥有俯视全局的战略视角?它是否理解组织内部的摩擦力?它是否能进行复杂的商业沙盘推演? 这才是“大脑”,而那些随时可以被替换、被生成的Skill,仅仅是指甲盖。 当我们站在这个时代的风口,最容易犯的错误就是把手段当成了目的,把过渡期的产物当成了终局的王冠。 那些还在为了自己封装了几个“独家Skill”而沾沾自喜的开发者,那些还在试图打造“AI技能超市”的平台,都在无可挽回地走向平庸。因为他们正在用前工业时代的思维,去禁锢一种属于未来的、无处不在的流体智力。 扔掉那些工业垃圾吧。停止在微观的胶水代码上浪费生命。去构建真正的认知引擎,去直面商业世界的复杂真相。这才是AI时代,真正的专家和开发者的正道。 1 个帖子 - 1 位参与者 阅读完整话题