2026年1月

winrar_x64_5.31.0.0_scp是 WinRAR 5.31 的 64 位安装包,用来压缩和解压文件,支持 RAR、ZIP 等常见格式,日常传文件、备份资料都能用。

一、准备工作

  1. 下载安装包

    安装包下载:https://pan.quark.cn/s/8638259bf289

二、安装步骤

  1. 双击 winrar_x64_5.31.0.0_scp.exe运行。
  2. 如果是 Win10/Win11,会弹出“用户账户控制”提示 → 点  “是” (需要管理员权限)。
  3. 进入安装向导,选语言(默认 English,有的版本有中文可选)→ 点  “OK”
  4. 点  “Install” ​ 开始安装(有的版本是“Next”)。
  5. 选安装位置:

    • 默认是 C:\Program Files\WinRAR,想改就点“Browse”选 D 盘或其他盘。
  6. 关联文件类型:

    • 勾选要关联的格式(建议全勾:RAR、ZIP、7Z 等),这样双击压缩包直接用 WinRAR 打开。
  7. 界面选项:

    • 可勾“在桌面创建快捷方式”,方便以后打开。
  8. 点  “确定” ​ 或  “Done” ​ 完成安装,桌面会有 WinRAR 图标。

三、首次使用

  1. 双击桌面图标打开 WinRAR。
  2. 主界面左边是文件夹树,右边是文件列表。
  3. 压缩文件:选中要压缩的文件/文件夹 → 点“添加”→ 选压缩格式(RAR 或 ZIP)→ 点“确定”。
  4. 解压文件:双击压缩包 → 选要解压的文件 → 点“解压到”→ 选目标文件夹 → 点“确定”。

新装的联通宽带,让安装小哥改了桥接,结果获取的也是 172 的内网 ip,开 v6 拨号倒是有公网。
打客服电话要求开通动态 v4 公网,回电说没有,要专线才有公网,不满意,继续上报让我等消息,我问等多久,等一天还是一年十年,客服回答不上来,看明天怎么说。
搜索了一圈网上大家在说杭州联通就算工信部投诉了也不给公网 v4 ,说是 ip 资源不够,但我还是想工信部投诉一次。

Skip 是一款通过 Swift/SwiftUI 代码库创建 iOS 和 Android 应用程序的解决方案,经过三年的开发,Skip 团队宣布他们决定将该产品完全开源,以促进采用和社区贡献。

 

在此之前,Skip 是一个付费解决方案,需要订阅和许可密钥才能创建应用,除非你是独立开发者或开发免费应用。Skip 解释说,这种模式有助于在没有外部投资的情况下启动产品,但“事实是,开发者希望免费获得他们的工具”。随着最近决定转向开源,Skip 现在与 iOS 和 Android 的主要开发工具保持一致,包括 Xcode、Android Studio、流行框架和其他基本工具,这些工具都是免费的。

 

但 Skip 表示,促使他们做出这一决定的不仅仅是成本问题。

 

除了价格,还有一个更深层的担忧是持久性。开发者对于在小公司的付费闭源工具上构建整个应用策略持谨慎态度是可以理解的。如果公司倒闭了怎么办?被收购然后关闭了怎么办?他们的应用程序怎么办?

 

简而言之,这就是 Skip 决定开源的原因:即使当前的开发团队消失了,解决方案也会继续存在,保护开发者在其中所做的投资。

 

根据 Skip 团队的说法,Android 和 iOS 上 UI 框架的快速发展,包括 Material Expressive 和 Liquid Glass,造成了使用传统跨平台 UI 框架可能导致“过时的界面、较弱的用户体验和真正的竞争劣势”的局面。相比之下,Skip 能够在两个平台上实现完全原生的用户体验。

 

事实上,Skip 框架通过将 SwiftUI 桥接到 Jetpack Compose 上,将其引入 Android。这种方法允许 iOS 开发者在相同的代码库中编写应用程序的业务逻辑和 UI,而无需额外的努力。

 

当 Skip 还是一个封闭源码的付费产品时,它的一些早期使用者在 Reddit 上分享了他们的经验。Reddit 用户 jestecs指出:“总的来说,使用起来相当愉快,虽然偶尔会遇到一些问题,但总体上令人惊讶地愉快”。此外,JEHonYakuSha进一步阐述

 

有些问题是因为某些弃用的构造函数不受支持,因此你可能习惯于用较旧的方式来定义视图修饰符或组件,但一旦你习惯了稍微发挥创意并确认什么是受支持的,它就非常好。

 

JEHonYakuSha 还指出,你可以使用//SKIP INSERT将 Kotlin 代码片段混合到 Swift 代码库中,并且 iOS 端只支持 Swift 包管理器,这可能会使管理内部依赖关系变得有些棘手。

 

Skip 的文档中有一个重要的警告,即该框架最适合外部依赖较少的新项目或应用程序

 

将现有的应用程序迁移到 Skip 并不简单。大多数应用都包含许多仅针对 iOS 的依赖,这使得移植到 Android 平台变得非常困难。

 

Skip 三年前开始作为 swift 到 kotlin 的转译器,后来增加了对 Android 上最广泛使用的 SwiftUI API 的支持。在此期间,他们成立了 Swift Android 工作组,发布了Swift Android SDK,实现了在 Android 上原生编译 Swift 代码。今天,Skip 支持许多流行的集成框架,与数千个跨平台 Swift 包互操作,并提供全面的 SwiftUI 实现。

 

SwiftCrossUI是一个开源的替代方案,它为跨 macOS、Linux、Windows 的 UI 提供了类似 SwiftUI 的 API,并对 Android 提供了一些新生支持。

 

Skip 可以在GitHub上克隆,而所有文档、博客和案例研究都转移到了skip.dev上。

 

原文链接:

https://www.infoq.com/news/2026/01/swift-skip-open-sourced/

typora-setup-x64是 Typora​ 的 64 位 Windows 安装包,Typora 是个所见即所得的 Markdown 编辑器,写笔记、博客、技术文档都很顺手,一边写一边就能看到最终效果,比传统双栏编辑器舒服很多。

安装很简单,下面一步步说。

一、准备工作

安装包下载:https://pan.quark.cn/s/9caec01429bb

二、安装步骤

  1. 双击 typora-setup-x64.exe运行。
  2. 如果是 Windows 10/11,会弹出“用户账户控制”提示 → 点  “是” (需要管理员权限)。
  3. 进入安装向导,选语言(一般默认中文或英文)→ 点  “下一步”
  4. 选“我接受协议”→ 点  “下一步”
  5. 选安装位置:

    • 默认是 C:\Program Files\Typora,想改就点“浏览”选 D 盘或其他盘,点  “下一步”
  6. 选附加任务:

    • 建议勾“创建桌面快捷方式”和“添加到开始菜单”,方便以后打开,点  “下一步”
  7. 点  “安装” ​ 开始安装,等进度条走完(大概十几秒到半分钟)。
  8. 最后点  “完成” ,安装结束,桌面会有 Typora 图标。

三、首次运行设置

  1. 双击桌面图标打开 Typora。
  2. 第一次打开会提示选择主题(有浅色、深色等),选一个看着舒服的。
  3. 进入主界面,左侧是文件列表,中间是编辑区,右边实时预览效果。

四、基本使用(简单说两句)

  • 新建文档:点“文件”→“新建”或 Ctrl+N
  • 写 Markdown:直接打字,用 #标标题、*斜体、**粗体、-列表等符号,右侧实时显示效果。
  • 插入图片:直接拖图片到编辑区,或 Ctrl+Shift+I选本地图片。
  • 导出文件:点“文件”→“导出”,可选 PDF、HTML、Word 等格式。
  • 保存Ctrl+S保存成 .md文件。

#!/usr/bin/env python3
import asyncio
import os
import sys

async def main():
    print("Starting MoltBot in micro-VM sandbox...")
    print("Type 'exit' or press Ctrl+D to quit\n")
    try:
        from boxlite import InteractiveBox
        term_mode = os.environ.get("TERM", "xterm-256color")
        async with InteractiveBox(name="moltbox", image="ubuntu:26.04", env=[("TERM", term_mode)], ports=[(18789, 18789)], auto_remove=False, reuse_existing=True) as itbox:
            await itbox.wait()
    except KeyboardInterrupt:
        print("\n\nInterrupted by Ctrl+C")
    except Exception as e:
        print(f"\nError: {e}", file=sys.stderr)
        import traceback
        traceback.print_exc()
        sys.exit(1)

if __name__ == "__main__":
    asyncio.run(main())
  • 执行 pip install boxlite

  • 执行 python moltbox.py 进入沙箱

  • 进入沙箱后,粘贴以下命令,按回车

  apt-get update -y
  apt-get install -y --no-install-recommends curl ca-certificates
  curl -fsSL https://deb.nodesource.com/setup_22.x | bash -
  apt-get install -y nodejs

  Or the full updated script for Ubuntu:

  #!/bin/sh
  set -e
  export DEBIAN_FRONTEND=noninteractive
  export PATH=/usr/local/bin:$PATH

  # --- Install Node.js + clawdbot if missing ---
  if ! command -v clawdbot >/dev/null 2>&1; then
    apt-get update -y
    apt-get install -y --no-install-recommends python3 make g++ git ca-certificates curl lsof
    curl -fsSL https://deb.nodesource.com/setup_22.x | bash -
    apt-get install -y nodejs
    npm config set cache /tmp/npm-cache
    npm install -g clawdbot@latest
  fi

  # --- Configure & start gateway ---
  set -eu
  CONF_DIR=/root/.clawdbot
  mkdir -p "$CONF_DIR"

  BIN=$(command -v clawdbot || true)
  if [ -z "$BIN" ]; then
    BIN="$(npm bin -g)/clawdbot"
  fi

  export CLAWDBOT_STATE_DIR="$CONF_DIR"
  export CLAWDBOT_CONFIG_PATH="$CONF_DIR/clawdbot.json"

  TOKEN=$(head -c 16 /dev/urandom | od -A n -t x1 | tr -d ' \n')
  PORT=18789

  cat > "$CLAWDBOT_CONFIG_PATH" <<EOF
  {
    "gateway": {
      "mode": "local",
      "bind": "lan",
      "port": $PORT,
      "auth": {
        "mode": "token",
        "token": "$TOKEN"
      },
      "controlUi": {
        "enabled": true,
        "allowInsecureAuth": true
      }
    }
  }
  EOF

  "$BIN" gateway run --allow-unconfigured --force --dev --bind lan --port "$PORT" --token "$TOKEN" &
  PID=$!
  echo "Gateway PID: $PID"
  echo "Endpoint: http://127.0.0.1:$PORT?token=$TOKEN"

  for i in $(seq 1 120); do
    if curl -so /dev/null --connect-timeout 1 "http://127.0.0.1:$PORT/" 2>/dev/null; then
      echo "Gateway is ready!"
      break
    fi
    sleep 2
  done
  • enjoy!


本方案沙箱基于
https://github.com/boxlite-ai/boxlite
一个轻松跑在本地,基于 micro-VM 的沙箱实现

点赞 + 关注 + 收藏 = 学会了

整理了一个NAS小专栏,有兴趣的工友可以关注一下 👉 《NAS邪修》

Haptic 是一款开源极简的 Markdown 编辑器区别于传统编辑器的 “编辑 / 预览分屏” 模式,它能实时渲染 Markdown 语法(输入即显示最终效果,无割裂感),界面极简无多余干扰,还支持丰富格式,操作流畅如普通文本编辑,比同类工具更贴近 “自然书写” 的体验。

我很喜欢 Typora 这种”所见即所得“的编辑器,Typora 收费后我一直找同类产品。对于我来说在编辑体验方面 Haptic 是能取代 Typora 的。

这次我用群晖的 NAS 部署 Haptic,其他品牌的 NAS 部署流程差不多。

在”File Station“的”docker“文件夹下创建一个”haptic“文件夹。

打开”Container Manager“,新增一个「项目」。

填入以下信息。

输入以下代码,然后点击“下一步”。

services:
  haptic:
    image: chroxify/haptic-web:latest
    container_name: haptic
    ports:
      - 3002:80

「网页门户设置」这里要开启“通过 Web Station 设置网页门户”。

完成上述操作后,打开”Web Station“(没有的话就去「套件中心」下载),新增一个”网络门户“。填入以下信息。

注意,端口要设置一个和其他项目不冲突的数字,比如我这里设置的是 2388

完成上面的操作后,等待 Haptic 镜像下载成功后,打开浏览器输入 你NAS的IP + haptic端口 就能使用 Haptic 了。

比如我的是 http://192.168.31.85:2388


以上就是本文的全部内容啦,有疑问可以在评论区讨论~

想了解更多NAS玩法可以关注《NAS邪修》👏

点赞 + 关注 + 收藏 = 学会了

当 Andrew Harmel-Law 邀请演讲者参加 QCon 伦敦大会时,他首先想到的是:“让 Diana 和 Cat 一起登台!”这完全是出于一种顽皮的冲动。

 

Cat Morris 是一位产品经理。Diana Montalion 是一位系统架构师。我们都专门从事软件系统和平台开发。我们都把对方视为我们所有痛苦的根源。不是个人层面的,我们从未一起工作过,但我们都认为对方所代表的角色是问题所在。

 

但我们也致力于改善我们的工作方式。如果我们能够消除我们之间存在的摩擦……那对每个人来说都是一件好事,对吧?

 

首先,我们对参与的每一个重大项目做了建模分析。我们发现,每一个项目的结局都像泰坦尼克号一样:撞上了冰山。

 

我们发现了以下这些改变职业生涯的真相:

 

  • 我们的工作有很多重合的地方。

  • 我们需要彼此。合作会带来更好的结果。我们思考问题的方式不同但互补。

  • 我们要解决的不是技术问题。技术挑战不难解决。困难之处在于消除摩擦。

 

摩擦是阻碍变革的无形暗流。摩擦并非孤立存在的,而是一个系统性问题,其来源是人、团队与技术之间的关系。解决之道不在于 Kubernetes、云计算或人工智能,而在于改变我们的思维模式、沟通方式和组织架构。

 

本文描述了在每一个项目中都会反复出现的六种摩擦:

 

  • 反直觉行为

  • 拒绝改变

  • 效率与控制

  • 产品与技术角色之间相互指责

  • 线性管道思维

  • 交付能力不足

 

每一种摩擦都让我们忙于重写相同的代码库或重绘相同的组织结构图。摩擦导致很多无益于我们避开冰山的工作浪费。这篇文章将帮助你弄清楚如何应对这些问题。

 

反直觉行为

 

我们怪错了对象。因此,我们做错了事情。

 

反直觉行为,由系统科学家 Jay Forrester 定义,是指复杂的社会和管理系统倾向于用让问题变得更糟糕的解决方案来应对问题。例如,为一个处于后期的项目增派更多的工程师,加快项目进度。

 

面对系统性挑战时,我们人类会倾向于指责他人。遗憾的是,我们怪错了对象。我们责怪工程团队工作效率低下,或者断定是因为团队太小,却未能意识到甘特图不过是虚构的简化模型,它过度简化了复杂的动态过程。

 

“任何系统的输出结果都是其内在设计的必然产物‌。”——W. Edwards Deming

 

当我们改变一个系统的运作方式时,我们也需要改变塑造系统的底层模式、结构和心智模型。例如,不是在本已臃肿的数据库上放上 GraphQL 就能称之为图,而是需要重新构建我们思考数据的方式。我们需要创建异步事件,而不是把什么都塞进管道,我们需要创建反馈循环,让我们能及时知道数据在跨系统移动时出现了异常。

 

这可以解释为什么工程师们会工作到很晚。他们一边忙着给猪涂口红,一边又要完成甘特图上没有预料到的工作。

 

解决之道:理解系统

 

反直觉行为具有引力,会将我们吸入其中,卷入漩涡。至少,我们的感受是这样:感觉像是在行动,在前进,而实际情况是,我们就像烘干机里的衣物,在原地打转。自始至终,我们都是从同一个狭小的视角凝视问题。

 

解决方法是暂时停下来,找准方向再行动。

 

首先是确定核心领域。系统的目标是什么?对于联邦快递来说,是快速递送包裹。很可能,你所经历的反直觉行为,源于人们的说法一致但前进方向不同。

 

每个参与的人都清楚变革与核心领域的关系吗?怎么才能加快包裹递送而不产生负面影响?系统本身如何导致了问题的产生?当前的流程和模式会产生什么样的心态?系统中的关系如何强化了这些模式?有什么你没有看到的变革需求吗?开始绘制这些模式,确定你的核心领域,所需的变革自然便会显现。

 

拒绝改变

 

每个试图变革的组织都有这样一些人:守门人、地牢主、自封的 10 倍速工程师,他们对组织非常了解,并且拥有一个魔法词:不。

 

他们说,“我们已经尝试过迁移。我们已经尝试过平台迁移或重构。我们已经尝试过重组。都行不通。别费心了。”他们掌握着生产环境或管道或某个关键系统的控制权,你没法忽视他们。

 

对此,人们很容易把责任归咎于那人的固执性格。但他展现的行为模式,正是长期的奖励与强化所形成的。通过管理遗留系统的复杂性,他已成为不可或缺的存在。要改变他,必须改变整个组织的思维方式,否则,又会冒出另一个类似的角色取而代之。仅靠技术手段无法从根本上解决问题。

 

拒绝改变是会传染的。当那个人关闭了好奇心,其他人也会转向固定思维模式。人们首先做的是怀疑而不是实验。组织无法在规避风险和尝试新事物之间找到平衡。变革陷入了停滞。

 

“变革之所以困难,是因为人们高估了他们所拥有的东西的价值,低估了他们放弃这些东西可能获得的价值。” ——《会飞的水牛:卓越腾飞,学会让员工引领》(Belasco 和 Stayer,1999 年)

 

解决之道:解雇那个人

 

好吧,这可能有点极端。你可能无法解雇他们,但你可以限制他们的影响。你不是他们的导师、母亲或心理医生。不要陷入那种角色。

 

把他们装进盒子里。给他们一个静态领域,让他们可以保留自己的脚本和遗留代码,而你去改变系统的其余部分。用“是”的力量去平衡他们“不”的力量。

 

是的,这并不意味着认同所有观点。这意味着探索可能性。将对话引向可以向前推进的方向。找到愿意做出改变的人,并帮助他们解决自己的问题,而不是等待守门人为他们开锁。

 

效率与控制

 

效率带来安全感。控制带来责任感。二者结合,便形成了现代组织中最诱人的反模式:效率与控制。

 

当它们占据主导地位时,我们关注的焦点便会缩小到产出:发布特性、关闭工单、满足截止日期。工作以速度来衡量,而不是价值。组织最小化互动和反思,坚信速度等于进步。

 

但在复杂的系统中,只讲效率会使系统变得脆弱。你按时交付了错误的东西。你得到了与蓝图相匹配的结果,但忽略了变化的环境。你得到了短期的解决方案,而那最终会成为未来的障碍。

 

我们制定了一个有预算有时间表的路线图,而唯一的上下文是一堆令人困惑的架构。

 

要求我们增加控制,但又理不清头绪。效率不过是掩盖混乱的遮羞布。其结果是一场组织作秀:Jira 工单、自信满满的时间表,以及追踪一切却唯独忽略意义的指标。

 

截止日期不可更改。功能已锁定。缺的是什么呢?一个明确的目标和协同一致的成果,同时又留有空间,允许在学习过程中进行调整。包裹配送时间没有改善,客户体验也未见提升。

 

解决之道:设计知识流

 

让团队注重效能而非过度追求效率。如何确保时间、精力和注意力都用在塑造真正重要的成果上?用协同取代控制:建立能让正确信息在正确时间传递给正确人员的工作机制,让信息跨越边界自由流动,无需高管做微观管理。

 

思考你目前正在开展的项目。你是在度量产出还是成果?截止日期是反映了现实还是一厢情愿的想法?如何改善信息流,而不是构建一个工厂式的交付过程?做工作与交付价值不是一回事;改善知识流能让你更快地获得价值。

 

产品 vs. 技术

 

Andrew 让我们聚在一起,因为我们有类似的挫败感。我们都面临着用 Kubernetes 解决系统性问题的压力。当然,我们做不到。我们也因为反直觉行为,养成了互相指责对方角色的习惯。

 

工程团队不喜欢产品经理给他们施加压力,要求他们在一个紧迫的时间表内完成特性交付。他们不明白,他们正在做的改变怎么能提高代码质量。基础设施、架构和 DevSecOps 人员则抱怨说,他们需要的改进从未被优先考虑。

 

产品团队不喜欢工程师表现出的抵触和消极态度。他们不明白,为什么一些简单的事情需要那么长时间来构建。他们抱怨说,过度工程化浪费了大量的会议时间,而那些时间本来可以用在寻找前进的方法上。

 

在许多组织中,产品和工程是相互隔离的孤岛。双方对效率与控制的定义截然不同,成了两股相互对立的势力。产品部门只需将需求抛过隔离墙,便坐等可运行的代码返回;而工程部门则被要求加快编码速度,无暇顾及系统设计。

 

即使这两个角色坐在一起,他们相互冲突的方法和控制欲也会加剧摩擦。

 

解决之道:向学习驱动型转变

 

Carol Dweck 博士描述了两种心态:固定型和成长型

 

固定型心态认为,擅长某事就意味着那件事应该很容易做到。如果某事很难,则说明你缺乏天赋。在这种模式下,人们会回避挑战,将反馈视为批评,将他人的成功视为威胁。其结果是团队很脆弱,他们要保护自己的地盘,而不是一起学习。

 

成长型心态认为,能力可以通过实践、反馈和坚持来提升。你不能只是做 Netflix 所做的事。在这种模式下,人们欢迎挑战,将努力视为精通之道,将挫折当作改进的数据基础。其结果是个人和团队都更有韧性,他们会适应而不是抵触。

 

当每个人,无论什么角色,都采用成长型思维时,他们就会一起学习。同理心是一项关键能力。它不同于单纯的同情,而是从多个角度理解情境的能力——对用户和代码的影响;产品团队与技术团队之间的流程和协作模式所导致的顽固问题。

 

为了共同做出有影响力的决策,我们需要成长型思维,借鉴他人的经验来丰富我们的世界观,并引导自己获得更深刻的洞察力。

 

线性管道思维

 

还记得过去软件中某个地方有 Bug 的日子吗?修复一行代码就能解决问题。现在,在微服务和分布式系统构成的复杂世界中,Bug 通常存在于各部分之间的关联关系中。系统架构的艺术和科学在于设计和编排。

 

每天,我们都会经历摩擦,因为我们在一个异步世界中交付线性管道。或许我们称其为平台,但真正的平台是精心设计的不同技术与流程之间的关联体系。它们能用不同的方式响应不同时间发生的各类事件。平台的各部分相互协同,达成单个组件无法独立实现的成果。这种现象被称为涌现(emergence)。

 

面向涌现的设计需要综合多方视角,理解如何调整整个系统以实现包裹快速配送,而又不破坏异步关系。

 

综合意味着不能单打独斗。你需要其他人贡献他们的专业知识,并将这些专业知识与你的知识整合在一起。当我们无法构建能整合组织知识与经验的实践体系时……我们就无法设计(或调试)平台。于是我们交付了一条管道,而所有人都将它的缺陷归咎于不充分。

 

解决之道:构建关系

 

与其用线性思维处理异步情境,不如退一步思考以下问题:

 

  • 在你的系统中,关系如何产生效果?

  • 系统各部分之间如何通过关系实现它们不直接做的事情?

  • 信息如何在技术系统中流动?

  • 痛点和瓶颈在哪里,以及如何优化关系以消除这些阻碍?

 

如果你的组织不支持这项工作,就组建一个秘密小组。无论身处何种角色,都要将多元视角融入建议的更改方案中。确保信息在人员之间顺畅流动,从而实现服务之间的无缝衔接。

 

当具有不同观点的团队(如架构师 Diana 和产品经理 Cat)共同构建这些模式时,一切都会变得更加轻松。与其他团队交流,观察用户使用系统的过程,向基础设施团队了解他们的痛点,并将这些洞察融入解决方案之中。

 

交付能力不足

 

我们以为我们专注于目标,而实际上我们是在专注于需求。目标是一个可衡量的成果,比如,提高包裹递送速度。如果我们提高了系统的能力,我们就实现了目标,而不是简单地添加另外一项功能。

 

对于内部平台团队而言,一个可能的例子是:团队被告知需将软件部署管道从 Jenkins 迁移至 CircleCI。这明确告知了操作步骤,却未说明迁移背后的原因。

 

这里的隐藏目标是将开发者的管道维护工作量减少百分之五十。没有这些信息,团队可能会迁移了软件交付管道却没有达到预期的结果。他们也可能有一些想法,不需要昂贵的管道迁移就能实现目标。

 

部署变更的能力早就已经存在。在这种情况下,交付流程会频繁出现各种断层。对于如何部署变更,每个人都有不同的想法。如果关注点是改变工具,那么这些想法将导致无尽的摩擦。

 

解决之道:专注于目标

 

制定有意义的目标,并整合实现目标的各种方案。描述需要交付的具体且可衡量的效益或成果。确保目标紧密契合核心领域,即加速包裹配送。系统的所有功能都应该服务于这个目标。每次部署变更时,我们(期望)都在提升系统履行职责的能力。聚焦目标能确保每位贡献者都理解自身工作的价值。

 

去尝试

 

现在,你可能感到不知所措。“我做不到这一切!我的工作已经很忙了!”这是真的。

 

幸运的是,你不需要全都做。选一件事来做就行。一个可以减少摩擦的小变革,可以是你最感兴趣的事情,也可以是给你的日常生活造成最大摩擦的事情。

 

系统就是这样工作的……小变革可以扩展为大改进。摩擦在细节中,解决之道也在细节中。

原文链接:

https://www.infoq.com/articles/friction-fix/

我用 LobeChat + HodlAI 测试了我的几个 Agent ,感觉到用量明显不对;加上站长说了用的方案是「 new api + openrouter 」我就测试了下到底是什么导致的,然后发现 openrouter 相当草台班子啊

1) 对于 Claude 模型不返回 usage 信息

我第一个观察到的点是 LobeChat 右下角之前一直都有的统计信息没了;然后我自己请求了下 openrouter 的 API 发现对于 Claude 模型,用 /chat/completions 接口根本没有 usage 信息返回

2) 用 Claude Messages 接口返回的 usage 信息格式不对

那我试试 Claude 模型 + /messages 接口呢🤔 惊喜,usage 信息来了!

但为啥 LobeChat 还是不能正常展示呢…… 结果我一看,"cache_creation_input_tokens":null 是个什么鬼,官方是 0 啊!

题外话,这种问题 LobeChat 确实可以兼容下;但官方 API Reference 里明确写了这个类型是 number + 它在不存在时自己返回的是 0 ,openrouter 返回个 null 也确实不太合适

3) 大善人还是 bug

cache_creation_input_tokens 的语义其实是「本次创建缓存用了多少 token 」,Claude 会把这类 token 多收 25% 的费用

那它是 null…… 究竟缓存了吗?收了缓存钱了吗?

答案其实是…… 缓存了但并没收钱🤔 OpenRouter 把这笔费用自己承担了

4) 所以为啥感觉贵呢

首先,即使它缓存了,但后面的请求不一定用缓存 —— OpenRouter 的 Claude 上游是 4 个随机的(我感觉完全没有「请求亲和性」的设计),所以理论上只有 25% 的概率会利用到缓存

不过真正的问题是…… 还记得 bug 1 吗?在 HodlAI 中,newapi 并没有拿到 openrouter 的正确的用量信息,所以 newapi 只能自己计算 token 按照无缓存计费,那么综合考虑 Agent 的上下文叠加 + 缓存有 90% off ,所以感觉贵就有情可原了

题外话,那用 claude messages 格式接入 newapi 是不是就能正确计费了?答案是…… 并不能…… newapi 也未能正确解析 openrouter 返回的 usage —— 而 claude 官方的就没有任何问题 —— 二者只差了个 null 所以估计还是那个 null 引起的

5) 还有啥其它的吗

OpenRouter 的 Activity 页面就没有人用吗?简直就是个 bug 集合体!

日志出现有十分钟以上的延迟,基于时间的筛选完全不能正常工作,打开的详情页面那个 json 完全靠猜才能知道含义

起因:
在近期使用飞牛时,发现会时不时的出现设备卡死、网络报错的情况,因为每天我都会通过飞牛去跑数据同步,所以没有关心这个问题,只以为是数据太多导致 FNOS 出现的什么莫名奇妙 Bug 。

直到本周周五,我又出现了这个问题,于是就想去查询一下是什么起因。
没想到,不查不知道,一查吓一跳,社区中许多人都出现了设备连接数异常、导致断网或无法连接飞牛服务器的情况。

再一搜索,这居然是一个很普遍的问题!社区中有人已经分析出这是一个专门针对 FNOS 的恶意程序,即便我已经开启了 SSL 、2FA ,且密码为非弱密码的情况下,这个恶意程序仍然植入到了我的设备。

根据一些大佬分析,飞牛疑似存在的 0day (路径穿越漏洞)可以在未授权的情况下可以访问整个 NAS 全部文件,包括系统的配置文件,这可能也是导致如上安全措施归零的主因之一。

这种 T0 级别的重大问题居然被官方一句 “别走 http 明文方式访问设备” 一笔带过,没有任何安全预警。像我一样的普通用户如果不是注意到近期的设备异常,甚至根本不知道有这么一回事。



这么大的一个技术团队,在出现这么大的安全事件后没有任何官方公告是什么用意?能不能有一个正面的态度???


附一些官方社群的分析:
https://club.fnnas.com/forum.php?mod=viewthread&tid=53230
https://club.fnnas.com/forum.php?mod=viewthread&tid=52580

21 年 8 月注册的甲骨文,用的中行长城全币通金卡,当时卡面有效期是到 23 年 11 月(找中行客服和网点来回拉扯了几次终于问到了),21 年底我就注销了该卡,找客服重置 MFA ,结果被告知,该卡片在甲骨文的系统中仍然是有效状态,原话是

The card is still valid in our systems once it expires we can ignore it

然后客服稍微透漏下有效期不是今年,这种情况我该怎么知道有效期,有没有大佬们遇到过类似的情况

试了很多之前的 流行的 远程控制软件, 只要是 wayland 都是提示不支持,
不过尝试了系统自带的远程控制和远程登录
发现 其实设置好了也比较好用流畅
动画效果 都可以录制,wayland 一些录屏软件,无法录制窗口动画效果,用 rdp 居然可以。
如下
[现代 Linux 中 Wayland 桌面环境的远程控制解决方案] https://www.bilibili.com/video/BV1JCrWBiE1e/?share_source=copy_web&vd_source=6609c6b7f4319c8c5053dec7ae215bae

唯一要的是需要在路由器中设置正确的 net 端口映射

我使用 Koa 很多年了,一直很喜欢它简洁的设计哲学。近几年在 Cloudflare Worker 上开发较多,接触到了 Hono 。Hono 也是一个不错的框架,但在深入使用后,我对它的一些设计理念并不是很认同,于是萌生了自己造个轮子的想法。

我为新框架设定了三条核心原则:

  1. 微内核架构:与 Koa 类似,保留了洋葱模型的中间件设计,同时还补充了插件系统
  2. 符合直觉的 API 设计:摒弃 Koa 的 delegates 思路,API 严格区分 ctx/ctx.req/ctx.res ,更加符合语义
  3. 环境无关性:可在 Node.js 、Bun 、Deno 以及 Cloudflare Worker 、Vercel 等边缘环境运行

于是 Hoa 诞生了。目前我跟另一个维护者已经为 Hoa 补充了近 30 个常用中间件,我也已经将手头大部分项目从 Koa 迁移至 Hoa 。今天分享出来,希望更多人去使用,也期待收到更多反馈,共同把 Hoa 框架打磨得更好。

特点

  • ⚡ Minimal - Only ~4.4KB (gzipped).
  • 🚫 Zero Dependencies - Built on modern Web Standards with no external dependencies.
  • 🛠️ Highly Extensible - Features a flexible extension and middleware system.
  • 😊 Standards-Based - Designed entirely around modern Web Standard APIs.
  • 🌐 Multi-Runtime - The same code runs on Cloudflare Workers, Deno, Bun, Node.js, and more.
  • ✅ 100% Tested – Backed by a full-coverage automated test suite.

安装

npm i hoa --save

快速开始

import { Hoa } from 'hoa'
const app = new Hoa()

app.use(async (ctx, next) => {
  ctx.res.body = 'Hello, Hoa!'
})

export default app

License

MIT

nestjs + swagger ui

点击 try it out 和 execute 后,

好像只有 status 200 的时候,能看到正常的返回值,

而 201 或者其它状态码就看不到返回值是怎么回事?

其它状态码就显示的 error: 加一个状态码

// controller
  @Get('test1')
  test1() {
    return '111';
  }
  @Post('test2')
  test2() {
    return '222';
  }

pic

最近想搞一搞 agent cli 开发。UI 层面,node 有比较成熟的 ink 方案。

但是看了下 go TUI 相关的解决方案,描述 UI 的方式有点别扭。当然可能是我没找到更好的实现思路。

所以实现了 rego ,取 react + go 的意思。

话不多说,先上代码。

package main

import (
    "fmt"
    "github.com/erweixin/rego"
)

func App(c rego.C) rego.Node {
    count := rego.Use(c, "count", 0)
    
    rego.UseKey(c, func(key rego.Key, r rune) {
        switch r {
        case '+': count.Set(count.Val + 1)
        case '-': count.Set(count.Val - 1)
        case 'q': c.Quit()
        }
    })
    
    return rego.VStack(
        rego.Text("Rego Counter").Bold(),
        rego.Text(fmt.Sprintf("Count: %d", count.Val)),
        rego.Spacer(),
        rego.Text("[+] 增加  [-] 减少  [q] 退出").Dim(),
    )
}

func main() {
    rego.Run(App)
}

运行效果:

Rego Counter
Count: 0

[+] 增加  [-] 减少  [q] 退出

仓库: https://github.com/erweixin/rego

对于多组件的使用可以参考: https://github.com/erweixin/rego/tree/main/examples/gallery

再贴一个 stream 组件的 demo 吧。

https://github.com/erweixin/rego/blob/main/examples/stream/stream_demo.gif

欢迎各位大佬试用、提 Issue 或 PR 。如果你也喜欢这种“在终端写 React”的思路,欢迎给个 Star 支持一下!👏

一直使用 vs code 开发 go,主要搞 web ,最近体验了一下 sublime-text ,发现这个曾经流行的开发工具对 GO 的支持很一般,插件还是很多年前的,是不是我不会配置,有没大神使用 ST 开发?