你好，我是 idiotfan

之前写过一版 DSH 的 macOS 启动器：一个 shell 脚本包装成的 .app，双击后自动拉起 dsh web 服务再开浏览器。能用，但打开的还是浏览器标签页，混在一堆网页里不够"应用"。 这次升级成原生应用方案，并且把整套方法整理成跨平台教程： macOS：Swift + WKWebView 编译成原生 .app，独立窗口、Dock 图标、断线自动重连 Windows：Edge/Chrome --app 模式快捷方式（零依赖），或 WebView2 原生窗口（进阶） 图标：不再手绘，直接从 DSH 源码里提取官方鲸鱼 SVG 渲染，配深蓝渐变圆角背景 最终效果（图标）： 本文自包含：所有源码完整附上，照抄即可复现；也可以直接把本文链接发给任何 AI agent，让它照着做。 一、原理 DSH 的 Web 界面跑在 http://127.0.0.1:3080。所谓"桌面应用"，本质就是一个固定加载这个地址的独立窗口： ...

日常用 DeepSeek Harness（DSH）的 Web 界面和 AI 结对干活，每次都要先开终端敲 dsh web、再开浏览器输地址，步骤琐碎。于是让 AI 直接给我做了一个 macOS 应用：双击图标就打开 DSH 页面；如果 dsh web 没在跑，它会自动在后台把服务拉起来，就绪后再弹开浏览器。 整个过程一次会话搞定，中间翻了两次挺有意思的车——一次在图标，一次在认证——记录如下。 一、应用本体：手写 .app 结构 macOS 的应用本质上就是一个遵守约定目录结构的文件夹，~/Applications/DSH.app： DSH.app/ └── Contents/ ├── Info.plist # 应用元信息（指定可执行文件、图标、Bundle ID） ├── MacOS/ │ └── dsh-launcher # 启动脚本（chmod +x） └── Resources/ └── icon.icns # 图标 不需要 Xcode，不需要 Automator，三个文件就是全部。 ...

⚠️ 脱敏声明：本文是折腾过程的记录与复盘。所有服务器地址、域名、密码、密钥、token 一律以占位符代替，请勿在公开笔记里保存真实凭据——这是本文最重要的教训之一。 为什么自建 商业机场的问题：节点质量不可控、流量共享、跑路风险。于是从 2026 年 6 月开始，我用三个多月时间搭了一套自己的网络： 两个自建出口节点：一台美国 CN2 线路的 VPS（日常主力），一台日本大阪 IIJ 线路的 VPS（兜底） 一个自建订阅服务器：跑在美国 VPS 上，一个 URL 管所有客户端 客户端矩阵：家里主路由 + 多台店里旁路由（iStoreOS + OpenClash）、两台 Mac（Clash Verge Rev + TUN）、iPhone（Shadowrocket）、一台带电池和蜂窝网络的便携路由（出门即热点） 最终效果：五台路由器全部验证通过，故障切换自动兜底，换 VPS 的 IP 时所有客户端零改动。 架构一句话 美国 VPS ──┐ ├── 订阅服务器(同一台美国VPS) ── 各客户端拉订阅 日本 VPS ──┘ 两个关键设计决定： ...

在十几个人的小微精酿餐吧做用工合规，是一件极具挑战的事情。 传统律所或大厂人事法务给出的方案，往往一上来就是一份主合同外加 10 个编号配套附件： 配套 1：员工手册与规章制度 配套 2：岗位职责说明书 配套 3：绩效考核与试用期规定 配套 4：考勤与加班审批制度 配套 5：知识产权与账号归属条款 配套 6：专项保密协议 配套 7：非全日制（兼职）协议 配套 8：竞业限制协议 配套 9：专项培训服务期协议 配套 10：离职交接与保密交还确认书 现实情况是：前厅服务员、调酒师和厨师根本不会耐着性子签完这十几份密密麻麻的文件，店长也根本没有精力去逐一归档管理。过于繁重的法务形式，最后的结果必然是全员流于形式、甚至干脆不签，导致法律风险反而完全敞口。 最近我们利用 Claude Fable 5 针对大梦的用工制度做了一次全面的合规梳理，核心目标是**「保底线、去冗余」，最终将整套体系精简为员工只需签 1~2 份文件的「最小必要合规包」**。 这篇文章记录这次梳理的核心逻辑与避坑要点。 一、 警惕「提示词污染」：死守真实的业务边界 在利用 AI 协助起草和审查法务合规文件时，我们踩过一个非常典型的坑：通用模板的提示词污染。 在最初引入的一份标准用工合规指南中，某些通用示例提及了「私教课消」、「健身教练」等字眼。LLM 在随后的跨文件修订中，将这些术语自动扩散到了 8 份配套合同中，甚至把前厅主管的考核写成了「课消完成率」。 ...

在给可能实验室（大梦餐饮）制作午市特惠、台风天畅饮、球赛之夜等一系列商业促销海报时，我做了一个决定：不打开 Photoshop，全部用纯 HTML + CSS + Python 脚本来做。 用 Web 技术做海报有极大的优势：布局可以用 Flexbox/Grid 极速调整、文案改动只需改一行字符串、多尺寸适配通过 CSS 变量瞬间完成，而且全套物料可以纳入 Git 版本管理。 但在真正借助 Claude Fable 5 与 Grok Imagine 图像模型 将网页无损导出为 300DPI 商业级印刷海报的过程中，我们踩遍了前端渲染、字体子集化、图像抠图与色彩空间的几乎所有暗坑。 这篇文章把这些工程细节与解决方案彻底拆解，给同样想用代码做设计的朋友一份避坑指南。 一、 导出引擎的演进：从 html2canvas 到 Chrome Headless 网页在浏览器里看着很美，但要导出一张像素完美（Pixel Perfect）的 1600×2400 高清大图，首先要选对渲染引擎。 1. html2canvas 的「翻车」表现 最初我们尝试了老牌的 html2canvas，结果导出的图片与原页面差异巨大： ...

实体餐饮经营最怕的是什么？固定成本在空转。 在大梦滨江店的总账分析中，我们发现了一个极其明显的规律：周五六「周末夜」的日均营业额，接近周日至周四「工作日」的两倍（具体金额已脱敏）。 然而，每月雷打不动的商场租金和晚班员工薪资，无论客人来不来都是按天硬性扣除的沉没成本。 为了把周日至周四 17:00–20:00 的晚市流量做起来，我们策划了「工作日晚餐畅吃 · 微醺社交夜」活动。这篇文章将复盘整个项目的核心推演：如何用 Claude Fable 5 建立精确的边际成本模型重构四档定价、如何通过腾讯文档 API 实时协同落地、以及如何调用 xAI Grok Imagine 自动化生成从手机海报到 6912 像素户外 LED 巨屏的全套视觉物料。 一、 算透边际成本：打破「全成本思维」的四档阶梯定价 很多餐饮营销方案往往死在粗暴的「成本估算」上。在最初收到的活动方案草案中，存在两个严重逻辑误区： 盲目假定 50% 毛利率：草案认为精酿酒水均价 50 元，成本要占 25 元，于是设了一条「单客综合成本不可超过 45 元」的硬红线。 忽视了真实采购价：没有把后厨批发的真实原料价代入计算。 1. 真实原料成本反推 我们调取了总账审计审定的各部门原料率，并结合实际销售牌价做了加权核算（具体数值属经营机密，此处只讲结论）： 门店精酿的真实加权均价，远高于草案拍脑袋假设的均价。 按原料率反推，精酿与经典鸡尾酒的真实边际成本只有草案估计的一半以下。 这意味着：正价好酒完全可以放进套餐和互动奖品池，完全无需使用廉价工业啤酒冲量。 2. 后厨真实采购单人均成本 结合后厨当月真实进货台账逐项代入核算（采购单价属供应链机密，此处不展开）： ...

在中小餐饮连锁店，每个月最令人头疼的除了盘点，就是算工资。 在大梦（可能实验室），两家门店涵盖了侍酒师、调酒师、咖啡师、主厨、出品厨师和兼任店长等多种角色。看似人不多，背后的算薪逻辑却极其复杂： 考勤源散落各处：有人在群里发手写考勤表照片，有人交 .xlsx，店长交 .xls 评估表，西湖夜班员工在腾讯文档里打卡。 提成与多维营收挂钩：薪酬不仅看基本工资，还挂钩部门业绩（精酿/调酒/咖啡/厨房）、班次业绩（白班/中班/晚班），甚至需要按部门 × 班次矩阵进行交叉剥离。 新 SKU 归口漂移：每个月两家店都会上新酒水或新菜品，如果菜品库没有及时维护，POS 导出的几百条订单就会分错部门。 输出要求高：算完不仅要在腾讯文档 43 列大表里逐行填平并标注店色，还要给每位员工生成带有公章、大写金额、社保代扣明细的精美工资单。 这篇文章记录我如何通过一套组合拳（Claude Fable 5 驱动的 Python 管道 + 腾讯文档 API + 响应式 HTML 工资单 + Rails 8 HR 系统集成），将原本需要耗费一整天的结薪工作缩减为 10 分钟自动化流程。 一、 考勤与数据清洗：手写照片与多格式兼容 结薪的第一步是收集出勤、法定假日、加班与请假数据。 面对不同来源的考勤资料，我们建立了一条标准化的数据摄取流水线： ...

开一家精酿美式餐吧到底要花多少钱？经营大半年后到底是赚是亏？钱都流向了哪里？ 这些问题听起来是基础会计常识，但当真正面对实体餐饮的一地鸡毛时–一整本扫描版银行流水、微信支付宝混合刷卡、物业方系统各期抵扣、股东实物入股、负责人个人信用卡垫付–账目会迅速变成一团乱麻。 最近我用 Claude 桌面端（主力模型 Claude Fable 5），对大梦滨江店（DAMON BREWING / 可能实验室）从 2025 年建店到 2026 年 6 月全周期的账务做了一次彻底的总账梳理。最终输出了 12 页签的标准化 Excel 底账、一份 10 页的完整对账报告，以及一份面向全体股东的 3 页精简经营汇报。 这篇文章记录这次梳理的核心方法论、踩坑教训，以及如何利用多 Agent 对抗式审计把 20 多个核心财务指标做到分文不差。 ⚠️ 脱敏声明：出于商业保密，本文不展示任何真实金额、比例与流水笔数，一律以定性描述代替，表格只保留指标间的推导结构。方法与流程是完整的，数字请自行代入自己的业务。 一、 为什么账会算不清：实体餐饮的 5 大「账面陷阱」 在动手拉表格之前，必须先理清业务现实。实体店的流水如果直接生搬硬套做汇总，一定会得出荒谬的结论： 混淆主体账户：滨江店以经营主账户为唯一现金账，但早期存在与西湖老店的店间结算和借调。如果直接抓商户名，西湖店的款项会混入。 第三方支付的「全量汇总陷阱」：微信和支付宝账单里包含了大量个人日常消费。如果全量汇总，两条渠道会各自凭空多出一大笔与门店无关的「假收入」！正确做法是只能通过付款通道子串匹配，精确提取实际扣自经营主账户的对手方明细。 团购的「双重计算」：美团到综团购的核销款，一方面已经反映在 POS 系统的「顾客实付」订单里，另一方面结算后又作为净款打入了银行卡。如果把团购单独列为一项收入加进来，营业额会被凭空重复计算一大块。 房东账单的「名目倒腾」：商业物业方在系统里将早期缴纳的意向金与首批款项打散冲抵到租赁保证金、物业保证金、能源保证金、首期租金、装修保证金与装修管理费中。按银行流水摘要搜「租金」只能看到零散转账，必须顺着物业系统的逐笔扣费凭证回溯。 信用卡垫付与公私倒挂：负责人个人信用卡替门店垫付了数万元房租与水电，但该卡同时存在个人日常消费，且经营主账户从未向该卡还款。如果把信用卡账单全量导入，会彻底污染负债端。 二、 6 条铁律：不可违背的底账原则 为了防止在多轮推演中产生数字漂移，我们在系统提示词与 Skill 中固化了 6 条铁律： ...

手上有两台红米 Note 13 5G（型号 2312DRAABC，内部代号 gold，天玑 6080，8+256，HyperOS / Android 15）。这 SoC 没有 Linux 主线内核支持，刷不了原生 Linux 发行版，但 8G 内存 + UFS 256G + 能一直插着电——拿来当 7×24 家庭服务器正好：音乐库离线听、远程可运维、双机互备。 整个折腾历时一周，从解锁 bootloader 到音乐自动同步上线，中间还出了双机重启卡死的事故。这篇把过程和结果完整记一下。 第一步：解锁 bootloader（最危险的一步） 小米官方解锁等待期长、限制多，走的是 Jz8Root 的 MTK RPMB 硬件解锁路线——通过 BROM 用 preloader 直接写 seccfg。但第一原则是先备份一切：动任何东西之前，先把所有 NV 分区（nvram / nvdata / nvcfg / persist / protect1 / protect2 / seccfg / lk / RPMB）用 mtkclient 完整导出来。 ...

《飘渺之旅》算得上修真小说的开山之作，我一直挺喜欢。最近突发奇想：能不能让 AI 先把整本小说读完，再用 Three.js 把书里的世界观宇宙"架构"出来——不是画几张概念图，而是做成一个能在浏览器里拖拽、缩放、点击的 3D 宇宙。 于是有了这个项目：一个零依赖、纯静态、完全离线的单页应用，双击 index.html 就能打开。 第一步：先让 AI 把小说读完 原始文本是 5.8MB 的 txt，46,806 行，GB18030 编码，而且尾部拖了两段垃圾——一段第 14 集的残章，加一段第 15~24 集的逐字重复拷贝（约 12,000 行）。 第一件事就是把语料洗干净： 删掉全部垃圾，46,806 行 → 34,311 行，精确统计出 28 集 × 292 章 编码从 GB18030 转成 UTF-8，macOS 直接能打开 修了第 2 集标题里的 ?? 乱码（“星星宫??寒冰原” → “星星宫·寒冰原”） 修了 2 处 GB18030 私有区字符（“水流突然化作…"、“突然出现一个巨大的黑洞”） 干净的语料是一切的基础。后面 AI 写的所有世界观数据，都要能回到这份原文里查到出处。 ...