老王日记

开源原创：Posd收银管理系统适合中小商家即插即用

Sat, 07 Nov 2026 17:52:31 +0800

开源原创：Posd收银管理系统适合中小商家即插即用

作者：JavaUser，原文见吾爱破解论坛：https://www.52pojie.cn/thread-2136216-1-1.html

Posd · 收银管理系统

Posd 是给小餐馆、奶茶店、便利店用的单机收银系统：收银、挂单、桌台、后厨分单、会员储值、库存盘点、采购入库、班次交接、日结月结、小票与价签打印，全部在一台电脑上完成。

没有云端、没有订阅、没有远程激活。断网照样卖货，数据不出店门。

功能

模块	能力
收银	现金 / 微信 / 支付宝 / 会员余额 / 积分抵扣，支持组合支付
订单	挂单取单、抹零、改价（审计）、按件退款、整单作废、退款原路
餐饮	桌台开台、加菜、并台、转台、清台，小票与后厨单带桌号
后厨	多档口分单（按类目路由到不同打印机），后厨单不印价格
会员	开卡、充值（含储值赠送）、余额、积分规则、等级折扣、到期提醒
库存	下单扣减（套餐按组件）、退款回补、盘点单、采购入库、低库存提醒
班次	开班结班、交接单（退款/作废/折扣/积分/堂食外带/跨班次退款）
报表	日结、月结、毛利（估算）、24 小时时段分布、CSV 导出
打印	ESC/POS 小票、后厨单、价签条码、小票 logo/二维码、失败重打队列
数据	自动备份、审计日志、权限分级、商品图片

快速开始

用安装包

双击安装。默认地址 http://127.0.0.1:8080，默认账号 admin / 1234（首次登录后请立刻改 PIN）。

同一局域网的手机/平板浏览器打开 http://收银机IP:8080 即可当副屏。

从源码构建

需要 Go 1.26+ 与 Node 20+：

git clone https://github.com/yixin-lot/posd.git && cd posd
npm --prefix web ci
npm --prefix web run build
node scripts/copy-embed.mjs
go build -trimpath -ldflags "-s -w" -o posd ./cmd/posd
./posd --addr 127.0.0.1:8080 --db ./data/pos.db

Windows 一键打包（需要 Inno Setup 6/7）：

pwsh -File scripts/pack/package.ps1 -Version 0.1.0

数据与备份

数据在程序同目录的 pos.db（SQLite WAL），不联网、不上传；自动备份到 backups/（默认保留 7 份）；卸载或删除程序不会删 pos.db / backups / images——要彻底清理请手动删目录。

技术栈

层	选型	为什么
后端	Go 单文件	无运行时依赖，双击即用
数据库	SQLite（modernc，无 CGO）	跨平台编译简单，备份就是拷文件
前端	Vue 3 + Vite（构建期内嵌）	一套代码适配收银机与手机
打印	内置 ESC/POS 渲染	不依赖驱动，USB / 网口均可

国内开源 gitee：https://gitee.com/yixin-lot/posd

喜欢的帮忙 star 一下，谢谢！

GitHub 项目：zed

Sat, 07 Nov 2026 07:58:43 +0800

GitHub 项目：zed

我换编辑器的次数不多，VS Code 一用就是好几年。倒不是它多好，是懒得折腾。但用久了有个感觉绕不过去：开个大项目要等，敲字偶尔会顿一下，装的插件一多，启动就更慢。这些毛病都不致命，可每天加起来，就是一种说不出的拖沓。Zed 吸引我的地方很直接——它把“快”当成第一卖点，而且是真快，不只是宣传语。

Zed 是 Atom 和 Tree-sitter 那拨人做的，整个编辑器用 Rust 从头写，界面是他们自己的 GPUI 框架，渲染能跑到 120fps。口号是“Code at the speed of thought”，听着像吹牛，但用起来确实能感觉到差别：冷启动几乎是秒开，打开几万行的文件、满屏搜索、来回切标签页，都没有那种熟悉的卡顿。项目现在 9.3 万多星，今天一天又涨了 292 星，提交数已经 4 万多次，每周都有新版本，更新很勤。

上手没什么门槛。去 zed.dev 下载就行，macOS、Linux、Windows 都有，装完打开就能写代码。语言支持主要靠扩展，装扩展的地方在编辑器里直接搜，HTML、Java、Python、Go 这些常用的都有，主题也有 Catppuccin、Tokyo Night 这些熟面孔。Vim 用户会很舒服，Vim 模式是一等公民，文本对象、mark 这些都有，不是装个插件凑合的那种。配置是 JSON，改键位、改设置都得自己写几行，不像 VS Code 全是图形界面，这点一开始会觉得别扭，用惯了反而觉得清爽。

真正让我想写这篇的，是它在 AI 上的路子。Zed 不绑死一个模型，这点我很看重：内置的 Zed Agent 能用，Claude Agent、Codex CLI 也能通过 ACP 协议接进来，等于把编辑器当成一个开放的 Agent 底座。模型怎么来也随你：不想管 key 就用它托管的 Claude Opus、GPT 5.4；想省钱就自己带 key；介意代码出内网就接 Ollama 全跑本地。还能同时开几个 Agent 并行干活，改 50 个文件也能实时看到每一处变化。还有一个叫 Zeta 的编辑预测，开源的权重和数据，按键粒度预测你下一步要改什么，写代码的时候像有人在旁边递词，准的时候挺顺手。

协作是 Zed 从第一天就带的东西，不是后来打的补丁。两个人可以进同一个项目一起改代码，还能聊天、共享屏幕。还有个我挺喜欢的功能叫 multibuffer：把散在代码库各处的片段拼到一个可编辑的界面里，改跨文件的逻辑时不用反复跳转。另外远程开发也有了，编辑器只跑界面，代码跑在远程机器上。

坑我也得说清楚。第一，扩展生态跟 VS Code 没法比，小众语言的支持要自己动手或者等社区补，插件数量差着量级。第二，暂时没有网页版，只能装客户端。第三，AI 功能是好，但托管模型要花钱，自己带 key 也得有 key，白嫖不了。第四，Zed 的许可证主要是 GPL-3.0，公司里拿来改源码分发要留意合规，虽然正常用完全没问题。第五，它的快捷键和操作逻辑有自己的脾气，从 VS Code 过来的人，第一周总会按错几个键，得给自己几天适应期。

适合谁？我觉得是三类：第一，每天被编辑器卡顿磨得没脾气、就想换个快的人；第二，Vim 用户，或者一直怀念 Atom 的人；第三，想把 Agent 写代码直接放进编辑器里、而不是在终端和编辑器之间来回切的人。反过来，如果你重度依赖 VS Code 的某个冷门插件，或者团队强制统一用某款 IDE，那就别折腾了，Zed 目前还替代不了那种生态。

我的建议是：先别急着卸载 VS Code，装上 Zed，用它正经写一周代码——开一个真实项目，试试 Agent 改个功能，再开两个 Agent 并行跑一次。一周之后你就知道，快这件事到底值不值得换。

https://github.com/zed-industries/zed

GitHub 项目：gstack

Fri, 06 Nov 2026 07:58:40 +0800

GitHub 项目：gstack

我用 Claude Code 写代码有一阵子了，越用越顺手，也越用越心虚。顺手是因为它写得快，心虚是因为全凭感觉：想到哪写到哪，设计靠脑补，review 靠眼力，上线靠运气。gstack 吸引我的地方就在这里：它不给你换一个更强的模型，而是直接给你配了一支“虚拟团队”——CEO、设计师、工程经理、发布经理、文档工程师、QA，各就各位，全是斜杠命令。

这套东西是 Garry Tan 开源的，他是 Y Combinator 的总裁兼 CEO，这是他每天真正在用的 Claude Code 配置，不是写出来做样子的。今天一天它就涨了 600 多星，总星数已经快 14 万。安装就两行命令，克隆到 ~/.claude/skills/gstack 再跑 ./setup，官方说 30 秒，前提是你已经装了 Claude Code、Git 和 Bun 1.4.2 以上。装完不用学什么新工具，在 Claude Code 里敲斜杠命令就行，全部是 Markdown 写成的技能，MIT 协议，免费，没有高级版。

上手我建议先跑三个命令，就能摸到它的脾气。第一个是 /office-hours：你描述要做的东西，它不急着写代码，先反问你六个问题，挑战你的想法本身。README 里那个例子我印象很深：你说想做个“每日简报应用”，它听完你的痛点直接说，你做的根本不是简报应用，是一个私人幕僚长 AI——它听的是你的痛苦，不是你的功能清单。然后它会写一份设计文档，后面的技能都接着读这份文档。第二个是 /review：扫一个有改动的分支，专门找那些能过 CI、却会在生产环境炸掉的 bug，明显的直接帮你修好，拿不准的列出来等你点头。第三个是 /ship：跑测试、核对覆盖率、检查文档，最后推上去开 PR。

真正让我觉得它不一样的，是流程是串起来的，不是一堆散命令。想清楚、定计划、写代码、做评审、跑测试、发版、复盘，每一步的产出都是下一步的输入，/office-hours 写下的设计文档，/plan-ceo-review 会接着读；/plan-eng-review 定好的测试计划，/qa 会拿去执行。另一点是它有护栏：/careful 会在 rm -rf、删表、强制推主分支这类危险操作前拦你一下，主分支强制推送和删根目录是直接拒绝的；/freeze 能把编辑范围锁在一个目录里，调试时不怕改错地方。这些东西平时感觉不到，出一次事就知道值多少钱。

坑我也列清楚。第一，Windows 只是最低限度支持，核心技能能用，别的都不保证；Aside 浏览器只在 macOS 上有，Linux 和 Windows 的浏览器技能走它自带的 Chromium，Ubuntu 24.04 以上还可能要加环境变量关沙箱。第二，Bun 版本卡得很死，低于 1.3.3 安装直接拒绝，先把 Bun 升上去再装。第三，外部评审默认是开着的，/review 这类技能会把你的代码发给 Codex 或 Claude Code 复核，用的是你自己的登录，第一次会弹提示，介意的人先在配置里关掉。第四，这项目膨胀得很快，介绍里还写着 23 个工具，技能表里如今已经有四五十个，别想着一次全学会，先用 /office-hours、/review、/ship 这三个，顺了再慢慢加。

适合谁？我觉得是三类：每天用 Claude Code 写代码、已经觉得“光会写不够了”的人；技术出身还想自己下场写代码的创始人；带小团队、想把 review 和发版流程固定下来而不是靠人盯的技术负责人。反过来，如果你只是偶尔让 AI 写个小脚本，或者根本不用 Claude Code，那这套东西跟你没关系。另外提醒一句，Garry Tan 的流程很“YC 味”——强势、爱反问、逼你把问题想清楚，喜欢自由发挥、不爱被流程管着的人，用起来会觉得啰嗦。

上手建议：先别碰团队模式，就在自己的一个项目上跑一圈——/office-hours 聊一个真实需求，/review 扫一个分支，/ship 发一个 PR。这三步都顺手，你再决定要不要让团队模式自动给队友也装上。

https://github.com/garrytan/gstack

GitHub 项目：auto-ontology

Thu, 05 Nov 2026 07:57:57 +0800

GitHub 项目：auto-ontology

我最怕的不是 AI 答不出来，而是它答得飞快，数字却是错的。以前让 agent 查营收，它就靠列名猜：哪个字段像 revenue 就 sum 哪个，口径对不上、关联表接错，最后给出的数字看起来很自信，查账时根本对不上。auto-ontology 吸引我的地方就在这里：它不先急着回答，而是先给数据建一层“意思”——什么叫营收、这个指标由哪些字段算出来、表和表之间怎么连，都先写清楚、让人审过，agent 再按这层意思去查。

它的做法分三步，这个顺序比功能列表更重要。第一步是生成：从数据库元数据里抽出业务术语、表间关系和 SQL 表达式，存进 Postgres 加 pgvector，变成一张可以检索的语义图。第二步是认证：人在界面里改术语、改口径，确认无误后再打上认证标记，没认证过的东西不值得信任。第三步才是回答：agent 先查术语、再写 SQL、再校验过滤值和查询，跑完把答案、SQL 和推导步骤一起交出来；答不出来就直说数据里没有，别硬编。

上手门槛我先说明白，这不是 pip install 就能跑的小库，而是一整套服务：前端、后端、摄取服务、Postgres，还有可选的 Vault，本地用 Docker Compose 起，线上用 Helm 上 Kubernetes。还要准备 NVIDIA 的 API 密钥，默认走 NIM 的模型，推理、抽取、向量、重排各有分工，环境变量按三元组配，漏配就回落默认值，配错了排查起来有点绕。官方快速上手用的是微软的示例销售库，先起数据库、导数据，再开语义编译，等到提示就绪后才能在聊天里提问。这一圈跑下来不算短，但对数据类项目来说，这个前置成本花得值。

真正让我觉得它值得试的，是两个细节。第一，答案带出处：不光给数字，还给 SQL 和步骤，错了能定位到是术语错了、关联错了还是过滤值错了。第二，它懂得说“不知道”：问一个数据里根本没有的概念，它会先做可回答性检查，而不是现编一个数字。这两点加起来，才是做数据分析的 agent 该有的样子——慢一点没关系，错了还自信才要命。

坑我也列清楚。MCP 服务器本身只是只读客户端，不存数据库连接、不存密钥，别把它当成产品本体；后端和摄取服务的端口要放在内网，因为摄取接口自己没有鉴权、还信任前端传来的用户标识，暴露到公网就是隐患。向量模型在摄取和查询时必须一致，换模型要重建。预测问答走外部服务时会把表上传出去，开之前先过一遍数据合规。另外这个项目目前不接受外部贡献，想参与只能提 issue 或集成需求，别指望提 PR 能合进去。

适合谁？我觉得是三类：同一指标在不同系统里有不同口径、经常为数字打架的数据团队；已经在用 Postgres、Snowflake、Databricks 这些源、想让 agent 稳定查数的人；还有在给 Cursor、Claude 这类工具接企业数据、但不想让 agent 直接猜表结构的人。反过来，如果你只是偶尔查一两次表、数据量很小、口径从来没乱过，那这套东西就是大材小用，先把 SQL 写清楚更划算。

上手建议：先别接自己的生产库，就用示例库走通一圈——起服务、等语义编译就绪、问一个能算出数的业务问题、再故意问一个数据里没有的概念，看它是不是真的会说不知道。这两问都对了，你再决定要不要把自己的库接进来。

https://github.com/NVIDIA/auto-ontology

GitHub 项目：worktrunk

Wed, 04 Nov 2026 07:58:59 +0800

GitHub 项目：worktrunk

我以前同时开几个任务的时候，最怕的不是写代码，而是切分支。手头一个功能写到一半，线上突然要修个 bug，stash 一下、切过去、修完、再切回来、再把 stash 弹出来——每一步都小心翼翼，生怕哪一步手滑把没写完的东西弄丢。git worktree 本来就是为了解决这个问题的：同一个仓库可以在不同目录各检出一个分支，互不干扰。可惜原生用法实在别扭，新建一个 worktree 要把分支名敲三遍，路径还得自己记。worktrunk 就是把这层别扭磨平的工具：分支名就是地址，剩下的事它替你办。

它的核心命令只有三个，我上手十分钟就记住了。wt switch --create feature-auth，新分支、新目录、切过去，一步到位；wt list 一眼看清所有 worktree 各自改了什么、领先主分支几步、有没有没推的代码；干完了 wt merge main，把分支合回主分支，顺手把 worktree 和分支一起清掉。以前要敲一串 git worktree、cd、git branch -d 的活，现在一句话说完。对我来说，真正省事的不是少敲几个字符，而是脑子里不用再维护一张“哪个目录对应哪个分支”的表了。

这个工具最对我胃口的场景，是同时跑多个 AI 编程助手。以前我让两个 agent 各改各的，最担心的就是它们在同一个工作区里互相覆盖。给每个 agent 一个 worktree，问题就从根本上消失了：wt switch -x claude -c feature-a -- '加用户登录'，wt switch -x claude -c feature-b -- '修分页 bug'，三个任务各干各的，我再用 wt list 巡一圈，谁改了多少、谁跑偏了，一目了然。不用 agent 的时候也一样好用：手头功能做到一半，插进来一个紧急修复，开个新 worktree 就行，旧的现场原封不动地留在那里，等回来接着写。

还有几处小设计，我觉得是真正用过才懂的好。第一是钩子：worktree 建好之后自动装依赖、起开发服务器，这些重复活可以交给钩子，不用每个新目录手动来一遍。第二是构建缓存共享，十个 worktree 不用各复制一份 node_modules 或 target，省磁盘也省编译时间。第三是按分支给开发服务器分配不同端口的办法，每个 worktree 有自己的端口号，不用再为端口冲突改配置。第四是直接检出 PR 的分支，wt switch pr:123 就能跳过去看别人的改动，审代码的时候很顺手。

但有几个坑，我得提前说在前面，免得你装完第一天就骂它。最关键的一条：装完二进制还不算完，必须跑 wt config shell install 装 shell 集成。原因很简单，一个普通进程改不了父 shell 的当前目录，不装这层壳，wt switch 切了目录也不会跟着走，很多人第一次用就卡在这里。第二，Windows 上 wt 这个名字和 Windows Terminal 冲突，官方给的办法是装成 git-wt，别硬抢名字。第三，钩子虽好，但写错了会在每个新 worktree 里重复执行，调试时先在一个分支上试，别一上来就全量铺开。第四，构建缓存共享只在 APFS、btrfs、XFS 这类支持写时复制的文件系统上才有意义，别的文件系统上别指望它。第五，AI 生成的提交信息只是帮你起草，合并不检查就直接推，出了问题还是你自己的锅。

所以它适合谁？我觉得最适合三类人：已经在用 AI 编程助手、想同时跑好几个任务的人，这是它一开始就是为了解决的问题；经常被紧急修复打断、又不想 stash 来 stash 去的开发者；还有维护多个并行功能分支、需要一眼看清全局的团队成员。反过来，如果你平时一个仓库永远只用一个分支，从来不并行，那它对你就是多余的一层，不用硬上。先挑一个正在做的仓库装上，开两个 worktree 干一天活，合并不顺手再卸也不迟。

上手建议很简单：装好先跑 shell 集成，再在一个练手仓库里建个分支、改两行、wt list 看一眼、wt merge 合回去。这一圈走通了，你就知道它是不是你要的那种“少操心”的工具了。

https://github.com/max-sixty/worktrunk

GitHub 项目：agent-desktop

Tue, 03 Nov 2026 16:02:43 +0800

GitHub 项目：agent-desktop

我折腾过不少让 AI 操作电脑的方案，绕来绕去，卡住的地方几乎都一样：模型对着截图猜坐标，点下去偏几个像素，按钮没按到，流程就断了。agent-desktop 换了一个思路，不让模型看图猜位置，而是直接读系统给出的无障碍结构树——界面上每个能点的东西都有一个编号，模型按编号下指令，完事再重新读一遍确认。这一步改动不大，稳定性却完全是两回事。

它的用法也直白。装好之后先列出当前能操作的应用，再对某个应用做一次快照，返回的是结构化的 JSON，里面每个可交互元素都带编号。点某个编号，改某个输入框的值，滚到某个区域，都是按编号来。操作完再快照一次，看状态是不是真的变了，变了才算数。这种“看一眼、动一下、再看一眼”的循环，恰好就是人操作电脑时的习惯，只不过以前靠眼睛，现在靠结构树。

我最喜欢的一点是它默认不动你的鼠标和焦点。很多桌面自动化工具一跑起来，整个屏幕就被接管了，你没法同时干别的。agent-desktop 默认走无障碍接口在后台操作，不抢焦点、不动指针，只有明确要求时才允许真实输入。这对要把 agent 挂在自己工作机上跑的人来说很关键：它在后台帮你点，自己还能继续写代码。

还有一处设计很克制：每次命令都是独立进程，输出统一是一份 JSON 信封，成功给数据，失败给错误码、能不能重试和建议。写胶水代码的人都懂这份克制的价值——不用再猜输出格式，不用再用正则从日志里抠结果。出错时它会明确告诉你是编号过期了、目标不唯一了，还是参数不对，照着提示处理就行，不用靠玄学重试。

但有几个坑，得提前说清楚。第一，编号只属于某一次快照，界面一变就过期，拿着旧编号去点会被拒绝，必须重新快照。这不是 bug，是设计，但写循环时一定要把“过期就重拍”写进去。第二，应用窗口一多，目标可能不唯一，得先指定窗口再操作。第三，界面元素特别密的应用，先用骨架模式画个大地图，再钻进某个区域细看，一上来就全量快照会把上下文撑爆。第四，Windows 的 PowerShell 里编号要加引号，不然会被当成别的语法。第五，快照、剪贴板、截图里都可能含私人内容，别随手贴进公开日志或上传。

平台覆盖是它另一个加分项：macOS、Windows、Linux 都能用，核心是 Rust 写的，许可证是 Apache-2.0。macOS 要先给无障碍权限，Windows 对同级应用基本不用额外授权，Linux 要走图形会话和 AT-SPI，Wayland 下有些能力会受限。除了命令行，它还提供 C 库，程序可以直接在进程里调用，不用每次都起新进程。

所以它适合谁？我觉得最适合三类人：给 agent 做电脑操作能力的开发者，终于不用再维护一套截图猜坐标的脆弱逻辑；做桌面自动化和回归测试的人，结构树比像素稳定得多；还有想在本地跑 agent 助手、又不想屏幕被抢走的人。反过来，如果你的场景必须精确到像素，比如图形软件里的拖拽选区，或者目标应用根本不提供无障碍信息，那它就不是合适的工具，先拿自己的目标应用实测一遍再决定。

上手建议也简单：先装上，列出应用，对一个常用应用拍一次快照，手动点一个编号，再看一次快照确认状态变了。十分钟走通这个循环，你就知道它适不适合你的场景了。

https://github.com/vercel-labs/agent-desktop

GitHub 项目：Cindy

Mon, 26 Oct 2026 18:16:44 +0800

GitHub 项目：Cindy

现在缺的不是 AI agent，而是 agent 太多、太散。Claude Code 一个窗口、Codex 一个窗口、手机上又是另一个，任务做到一半想换个模型，就得连上下文带习惯一起搬家。Cindy 的切入点就在这里：它不做又一个聊天框，而是做一个能把多个 agent harness 装进同一个 agent 的客户端——任务中途换 harness、换模型，工作区、记忆、技能不断线。

这篇文章不复述 README，重点说它跟“又一个 agent 客户端”到底差在哪、适合谁、以及你第一次上手最容易踩的坑。

一、为什么值得关注：它把“换工具”从重开一局变成中途换人

很多人用 agent 的真实状态是“多线并行”：规划用一个、写代码用一个、审稿再换一个。每个工具各有长处，但上下文、记忆和操作习惯互不相通，换一次就等于重新交代一遍。Cindy 的做法是把 Claude Code、Codex 这些 harness 收进同一个 agent：一个任务可以先规划、再并行执行、最后独立审稿，中间换 harness、换模型，任务本身不重启。

这个思路值钱的地方在于，它承认了一个现实：没有哪个模型在所有环节都最强。与其押注一个，不如让任务在不同组合之间接力，而由 Cindy 守住工作区、上下文和验收标准。至于 Pi harness 和原生 harness 还在路上，买之前先按“现有两个 harness”来评估，别为路线图付费。

二、它怎么跑：客户端在你手里，后端不在这个仓库里

先把结构说清楚，免得装错东西：这个仓库是开源客户端，桌面端是 Electron、移动端是 Expo / React Native，组织成 pnpm monorepo，Apache-2.0 开源。它的后端服务在另一个仓库，不在这个仓库里。

日常使用不走克隆编译那条路：普通用户直接去官网下载客户端。登录后可以用官方服务；也可以把已经付费的 Claude Code / Codex 方案接进来复用，不用重复付一份钱；或者接自己的 API Key、用本地模型。客户端还支持“Skip Sign-In”：不登录也能用本地 agent，但那时服务端能力不可用，应用里会显示“Not signed in”。桌面、手机、浏览器操作和 IM、日程接任务，都是在这个框架里展开的。

记忆、技能、定时自动化、MCP 接入内部工具，都是“一次教会、处处复用”的方向；插件和插件市场还在开发中，别把它当成现成的生态来规划。

三、适合谁，不适合谁

适合三类人。第一类，已经同时在用 Claude Code、Codex 这类工具，来回切换嫌麻烦的人——Cindy 的价值恰恰在“多 harness”上，只用一个工具的人感受不到。第二类，想让 agent 在桌面和手机之间接续干活、还想把重复工作排成定时任务的人。第三类，想把内部工具通过 MCP 接进 agent、或者想自己改客户端的开发者：源码开放，能审计、能 fork、能提改进。

不适合三类人。一类是只想找个聊天框问答的人，这个客户端的整套 harness、记忆、审批概念对他来说太重了。二类是想要完全自托管后端的人：后端不在这个仓库，官方服务或本地模式才是现实选项。三类是冲着插件市场来的：市场还在做，现在装上是得不到它的。

四、上手体验和坑：先把这五条看完再动手

第一，别把“下载客户端”和“克隆仓库”混成一件事。普通用户下载官方客户端就行；克隆仓库、装 Node.js 22.x、pnpm 10.x（注意 v11 暂不支持）、Git LFS，那是给贡献者准备的开发流程，不是日常安装流程。

第二，先定好模型账单怎么付。官方服务、复用已有方案、自己 API Key、本地模型，四条路成本完全不同；先想清楚再登录，免得装完才发现账单不是自己预期的那条。

第三，“Skip Sign-In”不是免费全功能。它只能用本地 agent，服务端能力不可用；如果你要的是云端同步、服务端能力，就别指望跳过登录能拿到。

第四，遥测要自己看一眼。官方发行版带 TapDB 用量统计，官方说明是不收集聊天内容、文件内容和工作目录数据，只做产品级聚合统计并在登录后关联账号；从源码编译可以去掉这部分。在意的人装之前先确认这一点，别装完再纠结。

第五，地区选项别靠默认。开发入口里中国大陆账号和全球账号是分开的，内部默认值不可靠；国内用户按中国大陆账号的入口走，别用默认去碰运气。

五、怎么试，第一次这样试最划算

先在官网下载客户端，登录并接好你已有的方案或 API Key，然后别急着让它写大功能，先做三件事验证它是不是你要的：第一，同一个任务中途换一次 harness、换一次模型，看工作区、记忆和验收标准是不是真的没断；第二，让它并行跑两个子任务，再用另一个组合独立审一遍，看“接力”是不是真的省了你重新交代的时间；第三，试一次定时任务和一次手机端接续，看它是不是真的能在你不在电脑前时把活干完、回来接着看。

这三件事都顺，这个工具在你手里才算立住了。我的判断是：它值得关注，不是因为“又一个 agent”，而是因为它把 agent 时代最烦人的问题——工具越多、上下文越散——变成了一个可以实际操作的产品形态：一个 agent，多个 harness，任务不断线。

https://github.com/makecindy/cindy

Github：这个项目有点东西-OpenShell

Sun, 25 Oct 2026 17:24:03 +0800

给 AI agent 干活，最难的不是让它能干，而是让它只能干你允许它干的事。NVIDIA 的 OpenShell 就是冲着这个来的：一个给成群自主 agent 用的、安全又私有的运行时。你在策略里声明每个 agent 能碰什么，它负责在运行时强制执行，而不是事后看日志追悔。

这篇文章不复述 README，重点说它跟普通沙箱到底差在哪、适合谁、以及你第一次上手最容易踩的坑。

一、为什么值得关注：它把“信任”从口头变成强制

很多 agent 沙箱的逻辑是“先给权限，出事再收”。OpenShell 反过来：每个 agent 都跑在隔离沙箱里，内核层控制它能访问哪些文件、能做哪些系统调用，每一次联网都要先过策略检查才放行。这不是应用层的过滤，而是在更底层卡住，agent 绕不过去。

更关键的是第二层：策略改动不是改完就生效。改动前，它会用形式化验证先算一遍这个改动会新放开什么，比如能不能带着密钥去一个新主机、能不能调一个新 API 方法，算出高风险就先留给人审批。这一步很对安全团队的胃口，因为 agent 时代最大的风险往往不是 agent 本身，而是某次“顺手放宽一点”的策略改动。

二、它怎么跑：网关、监管器、沙箱三件套

架构上可以理解成三件套：网关是控制面，管沙箱、策略和访问；监管器盯着运行时的 agent；沙箱是 agent 真正干活的地方。默认沙箱镜像是一个最小的 Ubuntu，里面根本没装 agent，这一点第一次用的人很容易懵：装完以为就能跑 agent，其实还要按“跑第一个 agent”的指引去接一个真实 agent，比如用 OpenCode 配一个免费的 OpenRouter 模型。

安装本身是一条命令加一个建沙箱的命令，但前提要先满足：Linux、苹果芯片的 Mac，或者 Windows 加 WSL 2（还是实验性的），外加 Docker、Podman 或者主机虚拟化。没有这些，装完也跑不起来。

三、适合谁，不适合谁

适合三类人。第一类，已经在跑不止一个 agent、而且要给 agent 文件、装包、调 API、用密钥权限的团队和个人，越是 agent 多、权限杂，这个工具的价值越大。第二类，对数据和密钥外泄特别敏感的人：agent 在这里永远看不到真密钥，密钥只由 OpenShell 加到发往已批准 endpoint 的请求上。第三类，想把 agent 接进自己应用的开发者：它有 Python、TypeScript、Go、Rust 的 SDK，接网关用，但要注意 SDK 和网关尽量用同一个版本。

不适合两类人。一类是只想跟单个 agent 聊聊天、写写代码的人，这个工具的策略、网关、审批流程对他来说太重了。另一类是希望 agent 完全自主、不要人审批的人：OpenShell 的设计就是要在高风险改动前停下来等人看，追求“全自动不打扰”和追求“不出事”在这里是冲突的。

四、上手体验和坑：先把这四条看完再装

第一，别用 curl 管道直接装完就信。README 给的是一条 curl 安装脚本，先看一眼脚本里到底装了什么、装到哪，再跑，这是装任何这类工具都该有的习惯。

第二，策略要从小写起。先给 agent 最小的权限，跑起来、看它在哪些地方被拦、再按需放开，而不是一开始就给一个宽策略图省事。放宽策略的每一次改动都会先被验证器标出来，这正是这个工具想让你慢下来的地方。

第三，遥测默认是开着的。它说只收集匿名的运行类别和数量，不收集沙箱名、主机名、文件路径、提示词、密钥、模型名和用户内容，但如果你在意，还是要在网关上把 OPENSHELL_TELEMETRY_ENABLED 设为 false，或者 Helm 安装里把 server.telemetryEnabled 设为 false，也可以直接编译掉。

第四，版本还早。0.1.x 刚进入稳定发布节奏，改动和升级指引要跟上，别把生产 agent 群直接绑在一个还在快速演进的版本上，先在测试沙箱里跑通你的策略和审批流程。

五、怎么试，第一次这样试最划算

先在 Linux 或苹果芯片 Mac 上装好，建一个叫 demo 的沙箱，然后按官方指引跑第一个 agent，重点不是看 agent 能写出什么代码，而是看三件事：它第一次想访问没批准的东西时是不是真的被拦住；你放宽策略时，验证器是不是真的标出了新风险；密钥是不是真的没有出现在 agent 能看到的地方。

这三件事都通过了，这个工具在你手里才算立住了。我的判断是：它值得关注，不是因为 NVIDIA 背书，而是因为它把 agent 安全里最难的一步——“给 agent 能力，但不给它失控的自由”——做成了可强制执行的运行时，而不是一份使用规范。

https://github.com/NVIDIA/OpenShell

GitHub 项目：security-audit-skill——让 AI 审计先学会别瞎报

Sat, 24 Oct 2026 23:40:59 +0800

解读 GitHub 项目：security-audit-skill——让 AI 审计先学会别瞎报

工作台今日候选里排第一的，是 Cloudflare 的 security-audit-skill。它不是又一个“让 AI 帮你看代码”的提示词合集，而是一个给 coding agent 用的审计技能：把一次安全审计拆成固定流程跑完，最后只认有证据的结论。

这篇文章不复述 README，重点说三件事：它跟普通 AI 代码评审到底差在哪、适合谁上手、以及你第一次跑最容易踩的坑。

一、为什么值得关注：它治的是 AI 审计最常见的毛病

普通 agent 做代码评审，常见毛病不是找得少，而是报得多、证据少。一段看着可疑的代码，它能讲出一套很像那么回事的攻击链，但你顺着源码一查，发现前提根本不成立。修这种“假漏洞”比不修更浪费时间，还会把真正的风险淹没。

这个技能的核心设计，就是把“找”和“验”分给不同的人。找漏洞的 agent 不能自己给自己盖章，验证的 agent 必须想办法证伪它。证伪不了、证据链完整的，才进 confirmed；证据不完整、还差一个关键事实的，不给严重程度，只记成 needs_validation；被证伪的，记成 rejected，并且留着记录。

这个区分比结论本身更重要。对做审计的人来说，最怕的不是漏报一个低危问题，而是把“还没搞清楚”当成“已经确认”，然后按严重程度排期去修。

二、它怎么跑：六个阶段，其实就三句话

流程说起来是六个阶段，理解起来可以压成三句话。第一句，先画地图：侦察阶段把架构、可信边界、输入面和已有的覆盖情况写成 architecture.md 和 coverage-ledger.json，后面所有工作都对照这张地图查缺补漏，而不是想到哪查到哪。

第二句，分头找、分头验：按覆盖清单派不同的猎手去查，覆盖评审员专门找没覆盖到的地方；每个候选漏洞都交给一个全新的验证者去证伪。第三句，只从已验证的记录生成报告，报告不是 agent 现场发挥写出来的，而是从 findings.json 和覆盖清单里推导出来的。

多次跑同一个仓库，结果是累加的：它会用以前的清单和结论去盯改动过的地方、重新验证变了的源码，而不是把旧结论当成已覆盖。这个设计很对审计的胃口，因为代码审计本来就不是一次性工作。

三、适合谁，不适合谁

适合三类人。第一类，自己维护一个有一定规模的代码库，想定期跑一次结构化审计，但请不起外部审计团队的人。第二类，团队里已经在用 Claude Code、Codex 这类支持并行子 agent 的工具，想把“AI 评审”从聊天变成可复查流程的人。第三类，想学习安全审计方法论的人：它自带的攻击面清单覆盖 Web、客户端、供应链、云和部署、协议、资源耗尽、数据隔离这些方向，照着清单走一遍，比零散看漏洞文章系统得多。

不适合两类人。一类是只想快速扫一遍、马上要一份漏洞列表交差的人，这个流程本来就慢，而且故意不给你“看起来很严重但没证据”的结论。另一类是完全没有安全基础、希望 agent 直接告诉你“修这里就行”的人：它给的是证据和待验证项，最终判断还是要人做。

四、上手体验和坑：先把这四条看完再跑

安装本身不难，用 Skills CLI 装好技能，在代码库里对 agent 说一句“security audit this codebase”就能触发。真正的坑在运行条件上。

第一，沙箱是硬要求。README 明确要求一个操作系统级沙箱：跑目标代码、测试、浏览器、模糊测试这些动作时必须断外网、环境白名单、资源受限、只写指定的临时目录。没有这个沙箱，流程不会替你冒险执行目标代码，相关线索会一直停留在 needs_validation。你以为是审计没跑完，其实是它在等一个安全的执行环境。

第二，成本和时间要按“多次跑”来算。官方自己的测试里，单次跑找到的漏洞大约只有多次跑总和的一半左右。这意味着只跑一次就下结论，很可能漏掉一半；但多次跑也意味着 token 和时间成倍涨。第一次试，建议先拿一个自己熟悉的小仓库跑，别直接上生产大仓。

第三，别把输出目录搞错。完整审计模式下，默认输出在 ~/security-audit-skill/<仓库名>/run-<编号>，只有当你明确选了一个版本控制忽略的目录时，它才会在目标仓库里写东西。跑之前先确认输出落在哪，别事后才发现审计产物混进了提交里。

第四，验证脚本别跳过。它自带两个零依赖的 Node 验证器，分别校验覆盖清单和 findings.json，流程里会在关键阶段跑它们。如果你手动改了结论文件，跑一下验证器比肉眼检查靠谱。

五、怎么试，第一次这样试最划算

先装技能，再找一个你自己写过、规模不大的项目，对 agent 说做一次安全审计。跑完先别看报告正文，先看 findings.json 里三类结论各有多少：如果 confirmed 很少、needs_validation 一大堆，问题大概率出在沙箱或执行条件上，而不是代码真的很干净。

然后挑一个 confirmed 结论，顺着它的源码追踪自己复现一遍；再挑一个 needs_validation，看看它到底卡在哪一个没确认的事实上。这个过程走完，你就知道这个技能在你手里是“能用的审计流程”，还是“又一个报得多、证据少的评审工具”。

我的判断是：它值得关注，不是因为 Cloudflare 背书，而是因为它把审计里最难的一步——“别轻信自己的发现”——做成了流程。AI 审计以后拼的不是谁找得多，而是谁的结论经得起复查，这个技能就是往那个方向走的。

项目地址：https://github.com/cloudflare/security-audit-skill

免费流量被爬虫刷爆：用 Nginx 444 精准拦截（附安全配置清单）

Thu, 22 Oct 2026 21:50:51 +0800

云服务器运维实战系列 · 第 7 篇（共 7 篇）

免费流量被爬虫刷爆：用 Nginx 444 精准拦截（附安全配置清单）

免费套餐的服务器，出站流量有额度，超了可能收费。我在面板上看到上行一直有流量、速度还不低，站点没几个人访问，数据却一直在往外发。查了 Nginx 日志，发现是大量 AI 训练爬虫和扫描器在反复抓页面、扫路径。

这篇讲怎么确认是谁在刷、怎么用 Nginx 的 444 状态码在连接层直接掐掉，以及顺手整理的一份安全配置。

第一步：确认流量是谁产生的

先看访问日志里都有哪些 User-Agent、哪些 IP 最活跃：

从访问日志统计活跃 IP 和 User-Agent。

BashBash# 统计访问最多的 IP
sudo awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head

# 统计出现最多的 User-Agent
sudo awk -F'"' '{print $6}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

我看到大量请求来自这些公开的 AI/采集爬虫和扫描器（UA 里直接带名字）：

TextTextSemrushBot
meta-externalagent / meta-externalfetcher
ClaudeBot / anthropic
Bytespider
python-requests / Go-http-client / curl（扫描器常用）

它们有的反复抓整站，有的专扫 .env、wp-login、phpmyadmin 这类敏感路径。页面虽然小，但架不住请求量大，累计出站流量很可观。

第二步：为什么用 444，而不是 403

Nginx 有个非标准状态码 444（return 444）：它不返回任何 HTTP 响应，直接在 Nginx 这一端关闭连接。

命中规则后直接断开连接，不返回响应体。

对比：

403 Forbidden：仍然要走完响应，返回一个错误页，客户端还会继续换路径试；
444：连接直接断，不发响应体，不产生出站流量，对刷量的爬虫最省事。

第三步：按 User-Agent 拦截

在 http 块（通常放 /etc/nginx/conf.d/ 下的独立文件，或 nginx.conf 的 http 段）用 map 标记恶意 UA：

nginxnginx# 放在 http {} 内
map $http_user_agent $bad_bot {
    default 0;
    ~*SemrushBot             1;
    ~*meta-externalagent     1;
    ~*meta-externalfetcher   1;
    ~*ClaudeBot              1;
    ~*anthropic-ai           1;
    ~*Bytespider             1;
    ~*AhrefsBot              1;
    ~*MJ12bot                1;
    ~*DotBot                 1;
    ~*(python-requests|Go-http-client|libwww-perl) 1;
}

然后在需要保护的 server 块里拦截：

nginxnginxserver {
    listen 443 ssl;
    server_name 你的域名;

    # 命中恶意 UA 直接断连
    if ($bad_bot) {
        return 444;
    }

    # 其余正常配置 ...
}

注意：Nginx 配置里 if 在 location 内容易踩坑，但在 server 层做简单的 return 是安全的官方用法。改完先测试再重载：

Bash

sudo nginx -t && sudo systemctl reload nginx

UA 名单按自己日志里实际出现的补，~* 表示不区分大小写。如果你希望自己的内容被某些 AI 检索，就别把对应 Bot 加进去。

第四步：拦截敏感路径扫描

扫描器最爱探测的路径，也直接 444：

nginxnginxserver {
    # ...

    # 常见敏感文件 / 后台扫描
    location ~* /\.(env|git|htaccess|htpasswd) { return 444; }
    location ~* /(wp-login|wp-admin|xmlrpc\.php) { return 444; }
    location ~* /(phpmyadmin|pma|adminer) { return 444; }
    location ~* /(vendor|tmp|backup|config)\. { return 444; }
}

这里有个我实际踩过的点：location 的匹配顺序。Nginx 正则 location 按书写顺序匹配、第一个命中即停；如果请求在 server 层已被 rewrite 改写成别的 URI，再用 location 正则去拦原始路径可能拦不到。所以拦截规则要针对最终生效的 URI，或干脆在 server 层用 if ($bad_bot) 这种不受 rewrite 影响的方式处理 UA。

第五步：限速，兜底防刷

对没被直接拉黑、但请求过密的，做连接和请求限速：

限速处理未直接拦截的高频请求。

nginxnginx# http 块定义限速区
limit_req_zone $binary_remote_addr zone=general:10m rate=10r/s;
limit_conn_zone $binary_remote_addr zone=addrlimit:10m;

server {
    limit_req zone=general burst=20 nodelay;
    limit_conn addrlimit 20;
}

rate=10r/s 是平均每秒 10 个请求，burst=20 允许短时 20 个排队，正常访客无感，脚本狂刷会被挡。

验证效果

重载后，用被封的 UA 本机测试：

BashBash# 用恶意 UA 请求，应直接被断开（无响应）
curl -A "SemrushBot" -I https://你的域名/

# 正常 UA 请求，应返回 200/301
curl -A "Mozilla/5.0" -I https://你的域名/

再观察面板流量和 access.log，被拦的请求不再产生响应流量，上行明显回落。也可以统计日志里 444（若记录了的话）的数量确认命中。

顺手整理的安全清单

结合这次迁移，给服务器定的几条基础防护：

只开放必要端口，面板、数据库不直接暴露公网；数据库只监听 127.0.0.1；
phpMyAdmin 等管理工具不开公网，需要时通过 SSH 隧道或反代 + 访问限制进入；
SSH 换非默认端口、禁用密码登录改用密钥、限制 root 直接登录；
面板用强密码 + 安全入口，及时更新面板和插件；
Nginx 层拦恶意 UA、敏感路径，并做限速；
网站目录权限最小化，删掉不用的站点和默认页；
定期自动导出数据库、异地备份，备份文件不放在 web 可访问目录；
定期看一眼流量和日志，异常刷量早发现。

小结

防爬虫刷量的关键是先看日志、确认是谁，再在 Nginx 层处理：恶意 UA 和敏感路径用 return 444 直接断连、不产生流量，其余靠限速兜底。免费额度有限，与其等流量超了，不如在入口就把无意义的抓取掐掉。