2026-03-20 10:39:38
前两天看了个视频，里边提到特朗普所引用的“纸老虎”这个词，源头是《毛选》，我当时感觉有点怪，因为我似乎记得以前曾在一些更老的线装竖版小说里看到过这个词。于是我就顺手去查了一下，没想到，这一查，事情就开始变复杂了。
《毛选》里的“一切反动派都是纸老虎”这个表述，相信绝大多数中国人都应该知晓，而“纸老虎”这三个字能够被广泛使用，也得益于此。因此，多数人不假思索将其当成源头，其实也很正常。但是从“考据”的心态来讲，我还是想寻求一下这个词真正的源头。
在网上有一个通行的说法，即“纸老虎”的源头是 1828 年英国传教士马礼逊编写的《广东省土话字汇》。我在网上找了一圈，没能找到这本书的 PDF 版本，但是，从常理推断，如果一个词被选进一本字典，那显然这个词其实已经“广为流传”，把词典当成一个字的源头，显然没有道理。
在腾讯元宝查询这个问题，元宝提出，“纸老虎”的说法，最早可见于清代小说《姑妄言》。在这本小说第十五回，有一句“至今我的老爷是个纸老虎，原是个假的，只好吓小孩子同乡下人”。我仔细查了下，这个说法的源头，应该是《华语桥》上的一篇文章《也谈“纸老虎”的来历》。但作者在文章中，同时提出，他在《红楼梦》中也查到这个说法。另外，作者考据到在明代的《金瓶梅词话》和《禅真逸史》中也都看到这个词，而前者大概是万历年间成书，在 1600 年前后，后者大概成书于天启末年，也就是1627年左右。
其实查到这里，我其实有点卡住了。毕竟前人已经考据了很多内容，追溯到万历年间。但我依然不死心，换了个 Ai 继续问。结果在千问那边，它得出一个结论，说“纸老虎”的源头在《水浒传》。这就有意思了。
我立马搜索《水浒传》全文，不过很遗憾，没有找到“纸老虎”三个字。但却找到了“纸虎”这个概念。“纸老虎”“纸虎”虽然一字之差，但其实本质含义是相同的。在《水浒传》第二十五回写武大郎捉奸西门庆时，潘金莲对西门庆大骂到”见个纸虎，也吓一交！” 而这个“纸虎”毫无疑问与我们当代用的“纸老虎”实际上是相同的用法，都是比喻用意。
武大抢到房门边，用手推那房门时，那里推得开。口里只叫得：“做得好事！”那妇人顶住着门，慌做一团，口里便说道：“闲常时只如鸟嘴，卖弄杀好拳棒，急上场时便没些用。见个纸虎，也吓一跤！”那妇人这几句话，分明教西庆来打武大，夺路了走。西门庆在床底下听了妇人这几句言语，提醒他这个念头，便钻出来，说道：“娘子，不是我没本事，一时间没这智量。”便来拔开门，叫声：“不要来！”武大却待要揪他，被西门庆早飞起右脚。
按照这个思路，我又找了下《水浒传》同时期小说，特别是罗贯中、冯梦龙的，毕竟罗贯中就是施耐庵的弟子，而且这三人的小说，流传最广，内容最多。
于是我在罗贯中的《平妖传》中也找到“纸虎”这个概念，甚至就直接写在第十四回的标题上：“圣姑堂纸虎守金山，淑景园张鸾逢媚儿。”
找到元末明初，其实我心中已经基本有了答案。为了验证一下，我又找来数个古籍搜索网站查询，但搜到的“纸虎”，就是剪纸的“纸虎”，并没有发现与现代一样，用作比喻用法的。
不过，这过程中倒也不是完全没有收获，猛然看到一个唐代可能是与佛经有关的内容中，提到“纸虎”。不过点进去一看，哦嚯，原来是 OCR 识别错误。原文写的是“二十六纸”和“虎耳太子经”，跟“纸虎”没任何关系。只是古人没有发明“标点符号”，两个字恰好连在了一起。
但也就是这个与佛经有关的搜索结果，让我进一步联想到，是否可以搜搜佛经呢。毕竟日常用的古籍搜索，其实只会少量收录这些佛经文献，如果要更大范围查找，还是需要使用专门的数据库才行。
但很遗憾，我并未在宋代以前的佛经中寻找到关于“纸老虎”“纸虎”相关信息，倒是找到一个明朝的《三宜明盂说》，里边明确提到禅师在徒弟礼拜后，教训徒弟时，徒弟反而虚张声势，结果被禅师说其是“一个纸老虎”。这已经跟我们现代用法一模一样了。
一僧礼拜起，师云：“错。”僧一喝，师以杖作呈势云：“此令合上座行。”僧以坐具打圜相，师搊住云：“何不道将一句来？”僧云：“恐成狼藉。”师连打云：“一个纸老虎。” —— [明]三宜明盂·说，[明]净范·编
所以，如果一定要给一个结论，我更倾向于这么理解。“纸老虎”这个概念，形成于元末明清的小说写作时期，可能是吸收借鉴了当时民间流传的故事，或者也有可能就是作者自己“想象”出来的概念。但无论如何，这个概念在施耐庵（约1296年—约1370年）写《水浒传》的时期就已经出现了，毕竟施耐庵也只是“集撰”，具体里边的事例，源头还在1119年的北宋时期的梁山起义。到了罗贯中所处的明初时期（约1330年—约1400年），“纸虎”的概念已经多次使用，而发展到明末，就连佛教文献也开始用上“纸老虎”概念。之后，到清代不管红楼梦还是各种其他小说，“纸老虎”概念越用越广泛，甚至于地方的方言字典上都把这概念收录了进去。而到 1946 年，“一切反动派都是纸老虎”以及后来“美帝国主义是纸老虎”，让这个词得到全面推广，以至于后来外国人都开始用上了。
有时候，问题的答案没那么重要，但把这些东西一层层拆开，本身就已经很有意思了。
2026-03-20 02:32:49
今晚在去学校接送小孩路上，我一直在想一个问题，现在的技术博客还有出路吗？
有个典型现象，可以说明这一点。比如，我之前习惯使用 Bing 搜索很多技术上的问题，但似乎最近很长时间都没怎么用过了。细看一下自己的搜索记录，基本都是直接的工具需求，比如 “SVG 转 PNG 在线工具” “二维码在线生成器” “随机密码生成器” ，而关于技术问题的搜索，更多的是 “Claude 封号规则”“ Genimi 图片提示词大全 ”“ChatGPT 长对话浏览器卡死”这类对 Ai 工具的具体使用问题。
甚至于，因为搜索引擎用的少，我已经有很长时间没有去兑换 Bing Rewards 积分了，看了下上次兑换，还是一年以前。而此前，每年我都可以在正常使用 Bing 时，兑换两到三次 100 元购物卡。这也间接说明，相对一年前，我使用搜索引擎的次数，下降了一大半。
而这些需求，都被 Ai 替代了。
多年来，技术博客圈大多聚焦于 IT 互联网行业的底层交互使用，“ Show me the Code” 就是其精神核心。大多数技术问题，说到底，都是围绕解决人类如何更好的操控机器而来。遇到不懂的，先查技术文档，再网上找有没有人遇到过相同或类似问题，实在不行再去技术大佬博客上留言或发邮件咨询，而技术博客最大价值就是解决了 ”遇到相同问题“ 这种场景。同一个问题，前人踩坑，留下记录，后来者可以学习借鉴前人思路和方案或者帮助加以改进，正是这种开源互助精神，引领着 IT 互联网行业数十年高速发展。
但 Ai 的到来改变了这一切。现在主流 Ai 几乎学习了人类所有的机器语言知识，对代码的理解能力，早已超过任何单一人类，此时遇到问题，再去“搜索”和“摇人”几乎没有任何意义。而作为从业人员，再去写这类技术博客，仿佛也没了“灵魂”，写来写去都不如 Ai 写得好，那还写这些干嘛。
到最后，似乎只剩下一条路，写写怎么用 Ai，怎么让 Ai 更好解决问题。
特别是，在目前大量程序员已经进入 VibeCoding 的状态下，本身自己解决问题也开始依赖 Ai ，有时候甚至连打开个目录、删除个字符都懒得自己动手，而是直接命令 Ai 去干。这个过程中，遇到的绝大多数问题，几乎都自动被 Ai 学习理解，以后别人遇到同类问题，可能 Ai 自动帮其解决了，后来者甚至可能都不会遇到同类问题。这种情况下，更加加剧了技术博客的消亡。
我最近两年在使用 Ai 过程中，总体感觉是 Ai 能力在显著提升中。去年初，Ai 的持久记忆还只是一串简单的 json 用户标签，到今年， Ai 的持久记忆，已经能支持一整天的长对话。而 OpenClaw 这种，理论上随着 Ai 发展可以无上限的记忆能力的 Agent 操作系统，更是一个跨时代的标志性时刻。但总体来说， Ai 受制于自身功能实现模式，还是有很长的路要走，比如数据污染问题，定向“投毒”问题，特别是对于“没有现成答案”的问题，Ai 很容易被诱骗输出错误结果。
比我，我在之前文章中多次探讨过一些方言词汇。我想找我老家当地方言中两个高频字的原字，一个是“躲藏”、“隐藏”的“藏”在我们当地是用另一个字表达，发音大概可以写成 b'ɔn ，躲猫猫也叫做 躲 b'ɔn ；另一个是”赶走“、”撵出去“这个前边动词，我们那用的字叫 p'ɔn 。 我用了很多个 Ai 来帮我推理这两个字到底是什么，但一直到现在，也没推理出恰当的汉字来。不过，这过程中倒也不是没有收获，忘了是哪个 Ai 推荐我去找《现代汉语方言字典》在我们当地的分卷，我也顺着这个思路找到了书，但下载下来一看，哦嚯，当初编字典的大佬也没考据出来这两个字到底是什么字。我也只能死心了。（这个字典与我家那边发音还有点不一样，这里的发音都是 p 开头，但在我家那边会区分为 p 和 b 。）
对于语料准确，或者来源通常比较“权威”的问题，即便是一些没有“标准答案”的事情，Ai 也还是能帮助推理还原出很多有意义的细节。比如，昨天我在看了一个视频后，顺手问 ChatGPT ”纸老虎“这个词目前能追溯到最早使用时间是什么时候，有没有明确的书面记录。由于 GPT 数据库中可能没有现成信息，它选择网络搜索，然后结合推理工具，认为这个源头可能就是《水浒传》，一方面，在维基百科的词条中，引用了《水浒传》第二十五回武大郎捉奸时，西门庆慌作一团，潘金莲不禁大怒道：“见个纸虎，也吓一交！” 这个例子作为最早出处；另一方面，它查到罗贯中、冯梦龙在《平妖传》中也有“纸虎守金山”的章节。进而他推论，罗贯中作为施耐庵的弟子，本身就在《水浒传》的写作和推广中发挥了巨大作用，而罗贯中自己的《平妖传》也有大段关于“纸虎”内容，考虑到《水浒传》的成书时间略早于罗贯中的著作，因此确定《水浒传》就是“纸老虎”这个概念的源头并没有问题。我随后在”识典“古文搜索平台搜索这个词，确实发现最早的记录都是在明代，特别以罗贯中著作中使用次数为最。而在宋代之前“纸虎”就真只是个剪纸里边的实物概念。
写到这里，我也有点恍惚，似乎最近一段时间以来，确实没发现多少 Ai 完全无法解决，或者不能提供解决思路的问题。包括，原本我对 Gemini 的欺骗性就很是恼火，经常“过于自信”“脑补”出一些稀奇古怪结论。但看了一下最新的 CAIS Ai 能力测评结果，发现虽然 Gemini 还是很坑，但 Claude 和 ChatGPT 已经很大程度解决了这个问题，GPT 5.4 甚至已经下降到 10 分以内（分数越低越好）。而在另一项对 Ai 来说难度最大的“人类终极问题”考验中，一年前的 GPT 4o 才取得 2.7 分的成绩，2500 道题里边，它几乎回答不出几道题；而到目前，Gemini 3.1 Pro 已经取得 45.9 分成绩，相当于能够随时攻克其中接近一半的难题。而那些题目，本身 99.99% 的人类都解答不出来。
基于目前 Ai 发展的趋势，以及博客这一形态本身所包含的价值，思来想去，我觉得可能有几个方面还是可以长期做下去的。
现在回头看，Ai 最强的能力，其实不是“解题”，而是用户能把问题说清楚。但问题在于，很多时候，可能我们自己也描述不清问题。比如，昨晚我在调试 Pocket Hugo Theme 时发现一个非常头疼的现象，文章页在加载时，似乎总是会出现一闪即逝的抖动。我将这个现象发给 OpenCode，它帮我改了四五个方向，包括可能是滚动条问题，主CSS布局加载问题，字体使用 rem 时浏览器的自动加载问题，以及一些 padding 可能出错等问题，但最后我选择用浏览器调试工具手动排查，发现是一个外部 JS 加载太慢导致的。这就是典型的“只会说现象”未能说清楚问题的表现。
换言之，很多时候，我们自认为自己在讨论一个技术问题，但其实这个问题，很可能是一个已经被误解过两三层的问题。就像上边这种，异常只是表象，真正的问题可能是架构设计，甚至是更早期的决策失误。而这些东西，Ai 是很难真正帮助用户找到答案的，它只会在用户给定的边界里，尽可能给出一个“看起来合理”的答案。
所以未来还能写的技术博客，可能不再是“这个问题怎么解”，而是“这个问题到底是不是问题”。谁能把问题讲清楚，谁就已经赢了一半。
多年来，我一直自嘲自己在经营这个 1ip 博客，虽然也有时会有几个访客，但从内心里，我一直是把它当成只有自己这一个读者的作品在看待。当然，如果能帮到别人就更好，由此，考虑搜索引擎优化，考虑主题设计，考虑更加吸睛的标题和文案也成为无赖的选择。
但现在慢慢发现，其实这个问题又回到了原点。也就是最终，博客这种东西，就像日记一样，很大概率还是供自己使用。尤其是在现在这种大量依赖 Ai 的开发方式下，很多事情其实不是“不会”，而是“忘记了”，忘记自己上一次遇到这个事到底怎么想的。
而博客，恰好留给自己一个最系统的知识库、记忆库。这些内容，等将来 Ai 更加成熟时，很可能成为一套类似“数字生命”的一部分。一篇又一篇的博客，就是最真实、最生动的“人生快照”，可以被调用，可以被继承，可以被长期保存下去。
现在的 VibeCoding 已经到了以前无法想象的地步，Coding 作为生活的一部分，意义越来越淡化，归根结底，还是得回到如何过好自己的人生，如何与这个社会和解、共存、发展。
这就不得不回到大众熟知的那些“终极哲学”现象，为什么人类历史上最顶尖的大脑，很多人最终都从客观世界回到了主观世界，从科学、技术倒过去搞哲学、神学、玄学。
以前总觉得这是“走偏了”，现在反而觉得，这可能才是必然路径。
因为客观世界的问题，总有一天会被工具解决。而主观世界的问题，比如我们日常的选择、焦虑、快乐、痛苦，这些事情永远没有标准答案，也不可能外包给 Ai 去完成。就算你在痛苦的时候，想让 Ai 安慰一下，那效果，也明显不如找一个真人倾诉。
而技术博客，如果还想继续存在下去，可能也只能往这个方向走了。不再是记录自己“怎么做”，而是更多记录“为什么这么做”，以及在这个过程中，自己真实的想法。这些内容，可能看起来有点“无价值”“无意义”，但毫无疑问就是一个人对这世界最真实的回应。只要人还在，这些东西就不可能过时。
2026-03-19 11:16:20
最近如果关注 AI，几乎绕不开“龙虾”这个词。
大家一边惊叹“AI 操作系统”终于来了，一边到处晒自己的工作流、晒自己的 Agent、晒自己又让 AI 干成了什么事。我上个月其实也猛玩过一阵，各种工具轮着试，各种模型来回切，短短一段时间，光 Tokens 就烧掉大几百块钱。
刚开始也很兴奋，觉得这东西真是新时代要来了，但玩到后面，人反而逐渐冷静下来。
不是说这些东西不好用，恰恰相反，正因为它们太好用了，不由得让我惊出一身冷汗。设想一下，如果未来一个聊天群里 500 个人，真正日常发言的可能是 499 个个人 Ai BOT；一个短视频网站上，你连续刷几百条，看到的全是 AI 自己批量制造出来的垃圾内容；一个公众号、论坛、网站站点上，密密麻麻都是 AI 自动拼装出来的图文信息。
换句话说，我们未来很可能会生活在一个充满 AI 垃圾信息的环境里。
而这种环境越往前发展，我越觉得一定会有“逆 AI”的潮流出现，一定会有人重新强调“这是人写的”“这是人画的”“这是人拍的”，就像今天有人强调有机蔬菜、家庭农场那样。
最近两年写过很多关于 Ai 的文章，就不讨论 Ai 实体机器人的大规模应用，光是在 IT 互联网应用层面，也是越来越觉得，AI 应用至少应该有一个最低底线。
我认为，对于普通人能直接看懂、感受的东西，比如文章、图像、视频、音乐、人与人之间的表达，尽可能还是要把这些领域还给真人来做。不是说 AI 完全不能碰，而是不能把这些东西理所当然地交给 AI 批量生产。
因为这些内容本来就是真实世界的一部分，它们的价值不只是“数据信息”，还包括表达者本身的情感。你今天看一篇文章，其实也不只是在看结论本身，而是在设身处地想着，这篇文章我到底在看什么，对我有什么用，如果我遇到这种事情怎么办，所有事情的终点终会落在现实世界。
但对于另外一类东西，我反而没有这么强的保守心理。
比如二进制代码、各种机器语言、编程语言，或者说信息革命以来各国程序员们为了让机器运行，搞出的无数中间层语言。严格说来，这些东西本来就不是给普通人看的，而是给机器用的。既然如此，如果 AI 在这些领域里直接发挥作用，未尝不是一件好事。
也正是在这种心态下，这段时间我借助 OpenCode，连续做完了两个开源项目，一个是 Pocket-Hugo，后一个是 Pocket-Hugo-Theme。都是围绕 Hugo 这个全世界最快的网站构建框架来的，前者用于编辑发布，后者是一套网站模板。
。
严格说来，这两个项目其实算是一体的，因为我在开发 Pocket-Hugo 时，为它添加了独特的页面编辑功能，而这个功能，必须通过调整 Hugo 主题来实现。既然如此，我干脆就自己做个主题，而不是在别人主题的基础上去进行二次开发了。
也正是如此，我在做 PocketHugo 的时候，就已经预想了后面主题要怎么做，很多东西都可以复用，比如按钮、信息层级、卡片节奏、配色等等，都是直接挪到第二个项目，大大减轻了开发难度。
过程中，这一边写 PocketHugo，做出一点顺手的 UI 或交互，另一边 pocket-hugo-theme 就可以顺手复用；那边主题里想到一个更好的卡片布局、多语言切换或者移动端展示方式，这边工具里又能反过来吸收。整个过程其实就是一边研究、一边学习、一边 VibeCoding。
而在这个过程中，我自己反而成了最大的受益者。因为很多以前只是模模糊糊知道“可以这么写”的东西，这次在反复来回折腾里，被真正逼成了理解。无论是 Next.js、Go 语言，还是前端 CSS、Hugo 的各种模板机制，我都比以前有了更具体、更踏实的认识。
也正因为有了这三个前提，后面做 pocket-hugo-theme 这件事，在我这里就不只是“再做一个主题”那么简单了。
如果只是单纯找个主题用，其实 Hugo 官方主题站里已经有很多选择。像我之前长期使用的 Hugo-theme-stack ，后来换的 bear-cub 等，都是非常好的主题。
但我真正想要的，不只是“能用”，而是“正好适合”。
如果看过我那个魔改版 Hugo-theme-stack 以及 bear-cub 的朋友就知道，我一直是钟情于“图文捆绑”这种模式，也就是微信公众号这种默认展示模式。但很遗憾，因为 Hugo 的用户大部分都是 Geek，大部分网站内容也都是跟 Coding 有关，所以一般来说，配不配图对他们压根没影响。甚至网上还有很多 Small Web 项目，一个个在拼自己的网站到底能极限压缩到多小，100KB 都已经排不上号，最小的好像才几 KB。
另一个重要的问题是，我一直想寻求一个手机上发布文章的稳定方案，这一点我在前一篇关于 Pocket Hugo 上线的文章已经讲到，这里就不再赘述。虽然我也很喜欢 IDE 工具，但挡不住，手机上用 IDE 实在是太痛苦了，特别是 iPhone 上默认输入法与网页输入框里边那些“反人类”的交互，相信但凡在 iPhone 的 Github APP 上复制过、修改过代码的都知道有多难受。
所以，最终，这次我想做的，就是一款封面图更突出、卡片感更强、同时又适合长期个人写作的图文式主题。
Hugo 主题的开发，讲起来其实挺容易。起码，在我混迹 Hugo 论坛的这几年，看到一堆北欧、北美五六十岁“老头们”每次都是用几行代码搞定一个页面模板。
但真正下手后却发现，这玩意也不是那么容易。因为我首先需要它能在我自己的网站上运行起来。
于是我几乎是把原来 Hugo-theme-stack 和 bear-cub 用过的各种组件，一个个全部先搬过来测试。
过程中也不知道经历了多少次 Hugo server 构建失败，最后一点一点才把模板搭建起来。
但也正是这个过程，让我后续开发受了不少苦头，因为前边这个过程，本质上是建立在它只服务我一个人的前提之上。各种元素都被我写死了，甚至一些页面结构和图片习惯，也都是完全围着我自己的写作方式转的。对个人来说，这种写法问题不大，反正怎么顺手怎么来，可一旦要把它拿出来开源，问题就立刻暴露了。
比如网站头部各种元素，这些东西以前在我网站里都是写死的；又比如各种组件、图片效果和各种功能，这些以前也都是“我自己知道就行”。但真要开源，就得一项一项改成配置，让别人也能看懂、也能用。
这里边最麻烦的其实不是写模板，而是反复判断什么应该保留成主题性格，什么又必须开放给用户自己设。
同时，为了发到 Hugo 主题站，还得尽量把多语言、注释、bundle、封面图、演示站这些东西都做出来。后面我又补了一堆示例文章和页面。做到这一步，我才更明显地感觉到，做自己的网站和做开源主题完全不是一回事。前者内容是目的，主题只是载体，后者内容反而成了说明书。
而且在这个过程中，Pocket Hugo 其实也一直在反过来逼着这个主题成长。因为我原本在开发 Pocket Hugo 时就是完全按照个人需求来的，如果别人恰好有相同需求就可以用我的方案。但后来，为了上线开源，我也不得不从头修改。过程中，还有人提 issue 说想要一个仅在本地运行的无需 Github 鉴权的版本，又多耗费了我几个小时。
最后，我几乎是把这个主题但凡能自定义的地方，都添加成了具体配置项。而这个过程，对我个人而言，几乎是重塑了对 Hugo 的认识，就像在不断逼问自己，为什么要这么设置，为什么不能那样设置，到底什么样的设定才是更好，更符合实际使用需求。
当然，我现在当然不敢这个主题已经有多成熟。一个主题这种东西，本来就是边用边改，边写边长的。但至少到今天，我已经可以很确定地说，我做这件事不是为了再往网上多堆一份 AI 时代的模板垃圾，而是想给 Hugo 这个老派、笨拙、却依然很可靠的世界，再添一块真正能被人长期使用的砖。
2026-03-17 15:38:43
今天下午，同事在工作微信上发来一份电商服务合作协议，说是他一个朋友（甲方）的，让我帮忙看看。
我向来对这种白嫖行为不是很喜欢，但还是碍于情面看了看内容。这一看不要紧，看完整个人都麻了。
说实话，我粗看这份合同就有点懵。要素齐全、条款专业、逻辑清晰一看就是出自业内人士之手，起码跟普通的“一纸协议”或一两页随便弄弄那种要强上很多，这种东西还要我来看干啥？让我写，我也写不出这么长啊。但仔细一看，哦豁，从第一句开始，就透露出一股“不详”。
继续往后看，越看越头疼，越看越觉得不是滋味。
过程中我只想到一个问题，到底是什么样的环境，能让一份从头到尾都透露出不公和违法的合同，看起来如此“理直气壮”？
看完这份合同，我觉得做电商的人太苦了。这哪是帮人“看店”，这完全是“卖身”好吗。
合同第一条写的“承揽服务协议”。翻译成人话就是，老板和员工之间不是劳动关系，是合作关系，老板不给交社保，不给工伤保障，干一天活拿一天钱。
但与此同时，合同里又要求每天工作 8 小时，覆盖核心运营时段（早上 10 点到晚上 10 点），客服在线率不低于 80%，货品上下架要在约定周期内完成。
这叫“合作关系”？
如果这都不算劳动关系，那世界上就没有劳动关系了。
乙方权利义务
- 按约定完成店铺运营服务工作，认真负责在线客服、货品管理等事项，维护甲方店铺的良好形象。
- 不得擅自泄露甲方的货品成本、经营数据、客户信息等商业秘密，合作终止后仍需保密。
- 不得利用甲方店铺从事违规操作（如刷单、售假、虚假宣传等），否则由此产生的一切处罚及损失由乙方自行承担，甲方有权解除协议并追究责任。
- 自行购买必要的商业保险（如个人意外险），降低自身及合作相关风险。
更悲惨的是，合同第七条还约定，乙方劳动者要自行购买商业险以降低“合作风险”。见过不要脸的，真是没见过这么不要脸的条款。
所以这份合同的本质很清楚：用合作协议的皮，掩盖事实劳动关系的实，把所有成本和风险转嫁给劳动者。
很多人觉得电商就是“在电脑上卖点东西”，轻松、自由、赚钱容易。
如果你也这么觉得，不妨看看一个电商运营每天要干什么：
• 客服：买家咨询要秒回，半夜 11 点也有人问 • 运营：上下架商品、做详情页、报活动、对数据 • 售后：处理退货、应对差评、被买家指着鼻子骂
这些活分开是三个岗位，但在小店铺里，往往一个人全包。有人可能会想，这不就是商店请人都要干的活吗，有啥大不了的。但讲实在的，电商区别于实体商铺的最大特点就是，劳动力被数据绑架。传统商铺的店员，卖多卖少心里有底，但不会有人拿着手机追着你问“今天转化率怎么比昨天低了 0.5%”。
电商不一样。你发出去的每一句话、每一个商品标题、每一张主图，都在被数据实时监控。询单转化率低了，客服要写检讨。DSR 评分掉了，运营要查原因。访客数跌了，推广要背锅。
但问题是，这些数据真的能反映一个员工的真实价值吗？买家不买单，可能是因为产品本身不够好，可能是因为价格太高，可能是季节到了淡季。但最后板子往往打在执行层身上。
传统商铺晚上打烊，事情就告一段落了。但电商不是，电商可以说是越到晚上越重要，因为你永远不知道这个世界的夜猫子有多少。很多人晚上躺床上没事就刷购物车，哪怕凌晨两三点，买家随时都可能来。更不用说各种人造“购物节”，层出不穷的平台规则，以及随时可能翻车“爆款”。
第三条 服务时间与安排
- 乙方每日投入服务时长为8小时，具体起止时间由乙方自主安排，无需向甲方打卡考勤、无需报备具体时段，仅需确保覆盖店铺核心运营时段（如早上10时至晚上22时，具体由双方协商补充约定）。
- 乙方可根据自身情况调整每日8小时服务的具体时段，但需保证店铺客服在线率不低于______%（建议80%以上），货品上下架等操作需在约定交付周期内完成。
合同里写“每天工作 8 小时”，但做过电商的人都知道，这 8 小时仅仅是“最低消费”，除了上午10点到晚上22点“黄金时段”，可能还有时不时的“白银时段”“钻石时段”出现，究竟要上多久班，也许只有自己知道。
很多电商运营是“无底薪 + 提成”模式。店铺卖得好，能吃溢价；店铺卖得差，得喝西北风。
乙方收益：采用无底薪制，收益根据乙方每月负责店铺的经营数据计算，具体分配方式如下：按店铺每月实际成交总额（扣除退款、退货、平台手续费、物流费、推广费）的______%进行结算；结算周期为每月______日前，甲方需在核对上月经营数据无误后，______个工作日内完成收益支付。
而且提成比例可以“根据店铺经营情况协商调整”什么意思？合同签完，老板可以随时改分成比例，你一点办法都没有。
不交社保，意味着没有医保、没有养老金、没有工伤保障。
第六条 上下班安全与责任豁免（核心条款）
- 安全义务：乙方在往返服务场所（或居家办公对应服务场景）、上下班途中，需严格遵守《中华人民共和国道路交通安全法》及相关法律法规，规范使用交通工具（骑行非机动车佩戴头盔、驾驶机动车持有效驾驶证，杜绝酒驾、超速、闯红灯等违规行为），主动做好自身安全防护。
- 责任约定：乙方在上下班途中、往返服务过程中发生交通事故、人身伤害、财产损失等任何意外情况，均由乙方自行承担全部责任，与甲方无关。
- 甲方免责：乙方不得因上述意外向甲方主张赔偿、补偿、工伤待遇等任何权利，甲方不承担任何法律责任及经济责任。乙方确认已充分知晓并自愿承担上述全部风险。
在上下班途中出车祸？自己负责。生了病医药费自己掏。将来老了退休金更是指望不上。
但他们干的是朝九晚九的活，受的是坐班的约束，凭什么享受不了劳动保障？
最后我想说，如果你正在给电商打工，或者身边有朋友在做电商，不妨仔细看看自己签的合同是不是也是这种。如果真的签了，也不用太担心。遇到不合理的要求，该拒绝拒绝，遇到拖欠工资的情况，该仲裁仲裁，该起诉起诉。
如果你也是电商老板，我想说，省社保的钱，不如用来招更好的人。用这种合同骗进来的人，留不住。能留下的人，也只是因为没得选。真正想把店做好的人，不会被这种合同留住；而被合同留下的，多半是随时准备跑路的。
而且这种合同在法律上几乎无效。一旦劳动者去仲裁，确认劳动关系、补缴社保、赔偿金，一样都跑不掉。
附：合同原文（有需要可以看）
# 电商店铺运营合作协议
## 第一条 合作性质与核心定义
1. 双方确认，本协议为平等民事合作/承揽服务协议，非劳动合同关系、非雇佣关系，不适用《中华人民共和国劳动法》《中华人民共和国劳动合同法》及工伤保险相关规定。
2. 合作核心：甲方提供电商店铺运营所需的全部货品、承担经营费用，乙方仅负责店铺运营相关服务工作，双方按本协议约定分配收益、分担责任。
## 第二条 服务内容与范围
乙方为甲方指定电商店铺（店铺名称：，店铺链接：）提供以下运营服务：
1. 货品管理：负责店铺内货品的上下架操作、库存信息同步、商品详情页基础优化（仅排版、文字调整，不涉及品牌侵权、虚假宣传等违规内容）。
2. 客户服务：承担店铺在线客服工作，包括解答客户咨询、处理订单咨询类问题、反馈客户合理诉求（不承担售后纠纷的最终赔付责任，特殊情况需与甲方协商）。
3. 基础运营：配合甲方完成店铺日常基础维护（如活动报名对接、订单物流信息核对配合，不负责物流实际处理）。
4. 乙方承诺仅在约定服务时间内完成上述工作，不得擅自脱离岗位影响店铺正常运营。
## 第三条 服务时间与安排
1. 乙方每日投入服务时长为8小时，具体起止时间由乙方自主安排，无需向甲方打卡考勤、无需报备具体时段，仅需确保覆盖店铺核心运营时段（如早上10时至晚上22时，具体由双方协商补充约定）。
2. 乙方可根据自身情况调整每日8小时服务的具体时段，但需保证店铺客服在线率不低于______%（建议80%以上），货品上下架等操作需在约定交付周期内完成。
## 第四条 费用承担与收益分配
1. 甲方责任：承担店铺运营所需的全部货品采购成本、店铺日常经营费用（如平台服务费、推广费、店铺装修费、物流运费等）。
2. 乙方收益：采用无底薪制，收益根据乙方每月负责店铺的经营数据计算，具体分配方式如下：按店铺每月实际成交总额（扣除退款、退货、平台手续费、物流费、推广费）的______%进行结算；结算周期为每月______日前，甲方需在核对上月经营数据无误后，______个工作日内完成收益支付。
3. 双方确认：收益分配比例可根据店铺经营情况协商调整，调整需签订书面补充协议。
## 第五条 社保与风险承担
1. 社保缴纳：因双方为民事合作关系，甲方不为乙方缴纳任何社会保险（包括养老保险、医疗保险、失业保险、工伤保险、生育保险及公积金）。
2. 乙方承诺：自行负责自身社会保险的缴纳事宜，承担社保缴纳相关全部费用，与甲方无任何关联。
3. 风险确认：乙方确认自身已清楚社保缴纳的相关规定及后果，自愿承担因未缴纳社保产生的一切责任，不得向甲方主张社保相关权益。
## 第六条 上下班安全与责任豁免（核心条款）
1. 安全义务：乙方在往返服务场所（或居家办公对应服务场景）、上下班途中，需严格遵守《中华人民共和国道路交通安全法》及相关法律法规，规范使用交通工具（骑行非机动车佩戴头盔、驾驶机动车持有效驾驶证，杜绝酒驾、超速、闯红灯等违规行为），主动做好自身安全防护。
2. 责任约定：乙方在上下班途中、往返服务过程中发生交通事故、人身伤害、财产损失等任何意外情况，均由乙方自行承担全部责任，与甲方无关。
3. 甲方免责：乙方不得因上述意外向甲方主张赔偿、补偿、工伤待遇等任何权利，甲方不承担任何法律责任及经济责任。乙方确认已充分知晓并自愿承担上述全部风险。
## 第七条 双方权利义务
### 甲方权利义务
1. 提供运营所需货品，确保货品质量合格、货源稳定，及时向乙方提供货品信息、库存数据。
2. 承担店铺经营相关的全部费用，及时处理货品质量、物流纠纷等非乙方服务范围内的问题。
3. 按本协议约定按时足额支付乙方收益，不得无故拖延。
4. 有权对乙方服务质量进行监督，若乙方存在严重失职（如长期不在线导致客户流失、货品上架错误造成重大损失），可提出整改要求，情节严重可解除协议。
### 乙方权利义务
1. 按约定完成店铺运营服务工作，认真负责在线客服、货品管理等事项，维护甲方店铺的良好形象。
2. 不得擅自泄露甲方的货品成本、经营数据、客户信息等商业秘密，合作终止后仍需保密。
3. 不得利用甲方店铺从事违规操作（如刷单、售假、虚假宣传等），否则由此产生的一切处罚及损失由乙方自行承担，甲方有权解除协议并追究责任。
4. 自行购买必要的商业保险（如个人意外险），降低自身及合作相关风险。
## 第八条 协议期限与解除
1. 协议期限：自______年______月______日起至______年______月______日止。
2. 协议期满前30日，双方可协商续签事宜，未协商续签的，协议自动终止。
3. 任意一方如需提前解除协议，需提前15日书面通知对方，双方结清未结算收益后，协议即可解除。
4. 乙方存在以下情形之一的，甲方可单方面立即解除协议，无需支付补偿：连续3日未履行客服职责，导致店铺严重差评、客户投诉增多；因乙方操作失误造成甲方重大经济损失（如货品上架错误导致违规被平台处罚，损失金额超过______元）；利用店铺从事违规、违法活动，损害甲方利益。
## 第九条 争议解决
1. 本协议履行过程中发生的争议，双方应首先友好协商解决。
2. 协商不成的，任何一方均可向甲方所在地有管辖权的人民法院提起诉讼。
## 第十条 其他
1. 本协议一式两份，甲乙双方各执一份，自双方签字（甲方盖章、乙方签字按手印）之日起生效，具有同等法律效力。
2. 本协议为双方完整的合作约定，取代此前所有口头或书面沟通、协议，未尽事宜双方可另行签订补充协议，补充协议与本协议具有同等法律效力。
2026-03-15 11:11:17
一切要从一个想在手机上发文章的念头说起
如果以 Hugo 为关键词在我博客搜索，会发现有四五篇文章都在讨论同一个话题：如何用手机发博客。
这已经不是我第一次这么干了。每次在等待上班、等待小孩放学、晚上在家时有了写作灵感，都想打开手机来更新一篇博客，但“算了吧，又得打开电脑”，“传上去之后还得再修改，不如明天再说”，就这样放弃了。
用 Hugo 的人都知道，内容本身不是问题——Markdown 在哪儿都能写。问题是图片怎么处理、写完怎么发布。
Hugo 官方给自己的定义是"The world’s fastest static site generator"（全世界最快的静态网站构建框架）。这不是宣传语，是实打实的用户体验。本博客现在 400 多篇文章，2000 多图片，每次本地构建只需要一二十秒切完。对比其他静态网站生成器，这个速度是断层领先的。
更重要的是，Hugo 稳定的构建速度和简洁的文件组织方式，让我没有任何动力去切换到其他平台。
作为从 WordPress 时代一路走过来的老 IT 人，对“图文分离”这件事有很深的心理阴影。
早年的 WordPress 根本没有内置图片库，大家写文章要用图片，只能自己找图床外链。我当年用过微博、Flickr，Photobucket、人人网……后来这些服务一个个倒闭或者不给外链，文章里的图片链接全变成了红叉叉，想找回来？门都没有。
所以后来转向 Hugo，我最欣赏的就是它的 bundle 模式：一篇文章一个文件夹，Markdown 文件和图片放在同一个目录里。发布时整个文件夹搬走，图片永远和文章在一起，不会丢，不会乱。
这是我认为最理想的图文管理方式。没有之一。
当然，我知道把图片放在文章目录里，GitHub 仓库体积就会涨。
手机端这个问题尤其突出——现在一张手机照片随随便便就是 10MB，你要在手机上用 GitHub App 发布文章，光是传图片就能把仓库撑爆。
2024 年优化博客时，我下决心做了一件事：把所有图片转成 WebP 格式。现在我的博客大概有 2000 张配图，400 多篇文章，整个仓库才 100 来 MB。对大多数个人用户来说，这种方案是完全实用的——既保留了图文一体的便利，又不会有仓库爆炸的问题。
回到手机端发布的问题。既然 Hugo 这么好，那在手机上写完文章发布，有现成方案吗？
最直接的思路。结果呢？App 主要是给代码协作用的，写 Markdown 的体验停留在“能凑合用”级别。更难受的是配图——手机拍的照片动则 10MB，直接传仓库根本不现实。你得先压缩、再上传、再把链接粘到文章里。这一套流程下来，比在电脑上操作还麻烦。
我之前还专门研究过一种方案：用 GitHub Issue 当作发布入口，通过 Actions 自动把 Issue 转成 Hugo 文章。具体实现我写过一篇文章 通过 Github issue 发布静态博客 ，有兴趣的可以去看看。
那次我已经感觉自己走到了“手机发Hugo”的终点，使用 Github Actions 自动抓取 issue 内容，然后通过自定义的标签格式抓取为 Frontmatter 信息。但实际用下来，就是感觉“不够正式”，需要自己记住 workflow 中的各种设定，实际上用的也少，自那次之后我自己也只用过两次。
我先后试过 Netlify CMS、Pages CMS 等方案。体验确实比 GitHub 网页版好，有编辑器、有图片管理。
但它们都有一个根本问题：图文分离。这些 CMS 的设计逻辑是把“文章”和“图片”分开管理——文章存在一个库，图片存在另一个资产库，最后通过 URL 关联。
即便勉强配置成功，也有使用问题。比如，编辑器里图片无法显示。
这和 Hugo 的 bundle 模式天然冲突。你在 CMS 里发文章，图片传到远端图库，Hugo 渲染时路径全乱套。不是 CMS 不好，是它们和 Hugo 的设计哲学不兼容。
我之前还用过多个临时方案，比如 CodeServer 这种浏览器上的 VsCode ，比如 StackEdit 这种在线编辑器。事实上这次我就是想将 StackEdit fork 修改一下，适配 Hugo 默认上传路径。只是在修改过程中发现这个项目太老了很多依赖项比较过时，而且这个项目本身非常庞大，改起来效益比较低，不如重新做一个了。
于是 Pocket Hugo 诞生了！
不需要下载 App，不需要配置复杂环境。手机、平板、台式机，打开浏览器登录 GitHub 就能写。
支持三种内容结构：
• Flat Markdown：传统单文件
• Single-language Bundle：一篇文章一个文件夹，index.md + 同目录图片
• Multilingual Bundle：多语言版本
保持 Hugo 原有的目录结构，不需要为了迁就工具而改变写作习惯。
手机拍照直接上传，系统自动压缩、转换为 WebP，不需要手动处理图片。这样既保留了图文一体的便利，又不会把仓库撑爆。
写了一半没写完？下次打开继续。不会因为中途打断而丢失内容。
所有数据都在浏览器里。服务端不存 Token，不存文章，没有任何用户数据。用完即走，不留痕迹。
• 入口：https://leftn.com
• 指南：https://leftn.com/guide
自己部署也很简单，Vercel 或 Cloudflare Workers 都有文档。
项目开源地址：https://github.com/h2dcc/pocket-hugo
如果你也在为 Hugo 手机端发布发愁，欢迎来试试。有什么问题欢迎提 Issue，也欢迎点个 Star。
