Guizang combines design skills in a DeepSeek Harness plugin

hybrid 检索（向量 + 关键词）、标签/作用域、置顶置灰、启用/禁用； Memory Dream：每日自动语义整理（合并去重/精炼重写/删除低价值/提升长期）； 用户可在面板里直接改记忆，重启不回滚。 7. 用量与统计 用量工作台：趋势、Token 活动热力（52 周 × 7 天）、供应商余额、预算； 跨天单点数据也绘制、铺满模式随窗口缩放实时跟随。 8. 文件与工作区 文件浏览器 + 修改历史对比（行级 LCS 对齐 diff）、应用内预览总线； 工作区文档卡片（AGENTS.md / CLAUDE.md 检测、预览、一键创建）； `_tmp/` 临时垃圾清理器（调度、最小文件年龄、保护目录、落 jsonl 日志）。 9. 外观与系统 玻璃质感主题（半透明毛玻璃 + 高光细边 + 柔和投影）、悬浮侧边栏； 壳管理更新（一键更新 DSH 本体）、插件自更新（增量）：只下载两版之间 diff 补丁（实测 336 KB vs 整包 4.7 MB），unified diff 应用 + git blob sha 逐文件校验，写入用「临时文件 + rename」避开 pnpm 硬链接写穿全局 store， 校验不过自动回退整包重装，绝不留半成品； 移动端适配（App Shell 底部 Tab、折叠菜单、极简视图、返回顶部）。 为什么这些对官方有参考价值 1. 证明插件机制可承载复杂产品：40+ 模块 / 8 万行代码，零 DSH 源码改动， 全部经由 `dsh.bundle.patch`、host/client 双半身、client 模块表与槽位系统装配 ——DSH 的插件架构是「真的能长出大插件」的。 2. 模块化装配的工程实践：每个模块独立 try/catch 挂载、可按配置裁剪、 [...] | 楼里 17 条发言我逐条读完，连同自己插件从 0.1.1 直跳 alpha.2 的实测，整理成了一个可跑的 skill： （MIT）。结构上没有新发明，就是大家已经收敛的「稳定流程 + 按版本事实」。里面有两块楼里还没有的。 一个是幽灵宿主体检脚本。源码检出原地升级后，跑着的老进程还在执行内存里的旧代码，磁盘上 `git describe` 已经是新版本。脚本比对进程启动时间（`ps -o lstart`）和检出最后变更时间

即刻App年轻人的同好社区 App内打开 566关注29k被关注51夸夸 产品设计师、模型设计师、 不会代码的独立开发者。 关注人工智能、LLM 、 Stable Diffusion 和设计。 歸藏 10:43 Claude200美元的订阅计划移除了5小时的限制 200 美元的计划现在叫 Ultra 会员 不过跟我们关系不大。移除 5 小时的限制，也需要他们自动进行验证，通过了才会移除。估计是为了防止蒸馏之类的东西 14 00 歸藏 09:55 苹果AI功能终于要在国内上线了！ 不过 Siri 这部分应该是之前的版本，不是最新的，是 24 年那个版本。 里面也写了是千问驱动。 然后会在 iOS 27.3 更新，应该是 12 月。 最主要的不是 Siri，Siri 倒无所谓，是一些比如说关于实时翻译呀之类的其他设备的 AI 功能挺有用的。 16 00 歸藏 00:44 终于把自己的几个设计Skill合并了！ 做成了一个 DeepSeek Harness 的插件 dsh-guizang-design 共用一套设计系统和 Design Token，还加了几个有用的功能 这几个原始插件加起来的 star 数可能已经有个五六万了 这里尝试：github.com/op7418/dsh-guizang-design 45 17 歸藏 1天前

终于把自己的几个设计Skill 合并了！ 做成了一个DSH 的插件dsh-guizang-design 共用一套设计系统和Design Token，还加了几个有用的功能.

终于把自己的几个设计Skill 合并了！ 做成了一个DSH 的插件dsh-guizang-design 共用一套设计系统和Design Token，还加了几个有用的功能. 4:20 PM · Oct

这次给Deepseek Harness 做的这个新插件dsh-guizang-design，旧的PPT Skill 也进行了很多优化。 如果你已经安装过其中的几个Skill 的话，建议更新一下

把一次"对话轮次"拆开看，大致是这样运转的： 1. 你发一句话（或者有排队的后续任务需要继续）； 2. dsh 把当下该让 AI 知道的背景信息——身份设定、可用工具、上下文——拼装成一份"简报"喂给模型； 3. 模型给出回应：可能是直接说话，也可能是"我想用个工具"——比如执行一条命令、读一个文件、搜一下网页； 4. 每一次工具调用在真正执行前，都会先过一道"关卡"：允许、拒绝，或者转去问你本人，同时还会做安全检查（比如自动清除命令里可能带出的密钥、密码等敏感信息）； 5. 工具执行完，结果记进账本，循环继续，直到这一轮任务完成、出错，或者达到某个上限（比如模型能同时"看"的文字量，也就是 token，用完了）。 整个过程被安全设计层层包裹：执行命令这类"动手"的操作会被关进沙箱里，避免波及电脑上不该碰的地方；沙箱如果连"能不能保证安全"都确认不了，就直接拒绝启动，而不是"降级"将就着跑——也就是"宁可拒绝，也不将就"的原则。 四、能力可以"即插即用"：从本地电脑到云端沙箱 前面说的"定义 / 提供者 / 使用者"三件套，具体落在了这些能力上（挑几个最直观的列一下）： 读写文件：让 AI 能看、能改文件。可以替换成：本机文件 → 隔离沙箱里的文件 → 云端远程文件。 命令行/终端：让 AI 能敲命令、跑程序。可以替换成：本机执行 → 沙箱里执行 → 云端执行。 代码智能：跳转到定义、查引用，像 IDE 里的插件。可以替换成：接不同语言的代码分析后端。 上网：搜索网页、抓取网页内容。可以替换成：自家搜索 → 第三方搜索服务。 派生"分身"：把子任务甩给另一个 AI 单独处理。可以替换成：本地分身 → 兼容其他工具协议的分身。 安全沙箱：圈定 AI 能碰到的范围。可以替换成：Linux / macOS / Windows 各自的隔离机制。 [...] 这背后还有一套贯穿全系统的固定搭配，可以理解成"三件套"：先有一份"定义"（这件事该长什么样），再有"提供者"（具体怎么实现，随时能换），最后是"使用者"（谁在用它，比如某个具体工具）。举个例子：dsh 定义了"文件读写"该有的样子，今天可能由"读写你自己电脑上的文件"来实现，明天想换成"读写云端沙箱里的文件"，只需要换掉"提供者"——所有用到文件读写的工具完全不用改，因为它们从头到尾只认"定