知识分享与微小叙事

前阵子开源了 Video Studio Skills 之后，我又顺手做了一个“姊妹项目”：Novel Studio Skills 。 这是一个面向 Claude Code 、Codex、Hermes Agent 等工具的多 Agent 网络小说创作技能包。简单来说，它能让你用六个 AI Agent 组成一个虚拟的小说工作室，从立项、世界观、大纲、设定卡，一路写到正文、定稿和封面插画。你只需要丢给它一个大致的梗概创意。 为什么要给写小说也做条流水线 把视频做成流水线，大家可能都能理解：视频本来就是研究、脚本、配音、剪辑分工明确的活儿。但写小说听起来是个很“整体”的事情，为什么也要拆？ 因为我自己用单个大模型写过长篇，踩过几个很典型的坑： 越写越飘。开头还记得主角左手有道疤，写到第三十章这道疤就不知道跑哪去了。设定、人名、地名，写着写着就开始自相矛盾。 一次写太长就崩。你让模型“接着往下写”，它要么糊弄几段草草收尾，要么上下文塞满之后开始遗忘前情。 浓浓的 AI 味。和写视频脚本一样，模型写正文也特别喜欢堆砌华丽的排比和宏大的形容词，读起来很假。 这些坑，本质上都是“一个脑子既要管全局设定，又要管这一段怎么写”带来的。所以我想试试：能不能像视频那样，把小说创作拆成几个各管一摊的角色，让它们通过文件来交接，而不是全靠一个对话上下文硬扛。 六个 Agent，各管一摊 在这个项目里，我把小说创作拆成了六个角色： 总编（Chief Editor）：工作室的大管家。负责接收你的创意、编制实施计划、推进流程、分阶段向你汇报，最后做终验交付。 架构师（Architect）：负责打地基。世界观设定、故事梗概、章节大纲都出自它手。 设定师（Lore Master）：把抽象设定落成一张张“卡牌”——人物卡、场景卡、关键道具卡、关键情节卡，给后面写正文的人当字典查。 写手（Writer）：分批起草正文初稿。 编辑（Editor）：润色加工，并且对照梗概和设定卡逐项做一致性核对。 设计师（Designer）：产出封面、角色立绘和关键情节插画的文生图提示词与规格。 它们之上还有一个所有人共享的“宪法”——总控技能 novel-studio，里面定义了整条流水线的状态机、项目目录规范、分批规则和质量门禁。所有协作都通过项目工作区里的文件来交接，project.yaml 记录当前进度，所以哪怕你今天写五章、下周再接着写，它也能从断点恢复。 “强制分批”这条铁律 如果说视频项目里我最在意的是“去 AI 润色”，那小说项目里我花心思最多的，是强制分批这件事。 长篇小说动辄几十上百章，如果放任模型“一口气写完”，结果一定是后半段质量断崖式下跌。所以我在流程里加了一条铁律：默认每批只写 5 章，写完必须停下来，由总编汇总这一批的成果向你汇报，等你确认之后再开下一批。 这么做有两个好处。一是把质量风险切成了小块——哪批不满意，就重跑那一批，不用从头来过。二是天然适配 Agent 会“失忆”的现实：每批结束都会生成滚动摘要和设定索引，下一批开工时先读这些压缩后的记忆，而不是去翻几万字的原文。 为了对抗前面说的“越写越飘”，我还设了三道一致性关卡：设定卡里的命名一旦冻结就不许改 → 写手交稿前先自查 → 编辑再做两轮对照复核。三道关下来，主角左手那道疤基本就跑不掉了。 一点感想 做完视频工作室再做这个，我越发觉得：多 Agent 协作真正解决的，不是“让 AI 更聪明”，而是“让 AI 别在长流程里把自己绕晕”。 单个模型的上限其实很高，但你要让它独自扛完一部长篇，它就会在全局和细节之间反复横跳，顾此失彼。而把任务拆开、用文件当交接界面之后，每个 Agent 每次只需要专注一件小事，反倒更稳。 当然，它替代不了真正的好故事。设定再自洽、流程再顺滑，最终能不能打动人，还是取决于你最初塞给它的那个创意，以及你愿不愿意在它写歪的时候停下来，亲手把它掰回正轨。 ...

最近开源了一个新项目：Video Studio Skills 。 这是一个面向 Hermes Agent 的多 Agent 视频创作技能包。简单来说，它能让你用 7 个 AI Agent 组成一个虚拟的视频工作室，接管从深度调研、脚本写作、TTS 配音到 Remotion 动画渲染、多平台 SEO 包装的全部工作。 为什么要做这个工具 随着 AI 能力的不断提升，用 AI 创作短视频已经变得非常容易。如今我们能在抖音或 B 站上刷到各种 AI 生成的视频。但无论是先进的 Seedance 2.0，还是 Gemini omni，它们都有一些共性问题，比如速度慢，比如难控制。有时候为了生成一段满意的视频，我们需要反复掷骰子，不断挑选、拼接，消耗大量时间，更别说批量生产短视频了。 虽然我认为以现在的发展速度，AI 迟早能解决上面的这些问题，但毕竟当下这些痛点还依然存在。所以于是我就在想：能不能通过多 agent 协作的工作流，让 AI 视频生成变得稍微可控一点？至少当我们对最终交付的视频成品不满意时，可以不必从头来过，而是对工作流中的某个节点进行修改，这样能节约不少时间。 于是就有了这个项目。它尤其适合制作批量的科普类短视频，从查资料、写逐字稿、录音或配置 TTS、剪辑、做动画、到各个视频平台的标题和简介包装，这一整个流程都能让特性各异的 AI Agent 来合作完成。你只需要提供选题，AI 就能像流水线一样为你批量生产视频。你当然可以自己配音，再加上讲解的 A Roll，这样视频质量会更高。 7 个 Agent，6 个阶段 在这个项目里，我把视频制作流程拆解成了 7 个具体角色的协作： Director（导演/编排）：整个工作室的大管家，负责接收你的选题，拆解任务并派发给其他 Agent。 Researcher（研究员）：负责深度调研，输出结构化的研究数据。 Writer（作家）：根据研究数据，撰写视频脚本初稿。 Editor（编辑）：专门负责“去 AI 润色”，定稿最终脚本。 Narrator（播音员）：调用 TTS 工具生成配音，并输出时间轴同步文件。 Renderer（渲染师）：基于 Remotion 将文本、音频转化为动态的视频画面。 Packager（包装师）：生成适合 YouTube、Bilibili 等平台的标题、简介和标签。 整个管线完全是自动流转的。你可以选择不同的工作模式：如果你想随时插话，可以拉一个“群聊”看着它们讨论；如果你只想看结果，可以单线联系 Director，让它在后台“委派”工作；如果你需要批量生产，还可以用看板模式管理进度。 ...

今天下午，家里很安静。妻子和孩子在卧室里睡着了。孩子去年刚出生，还很小，睡着的时候脸上有一种完全不设防的安稳。父母也都还健在，一家三代还可以这样平平安安地生活在一起。这样的日子其实没有什么戏剧性，不过是很普通的周末，普通到如果不是某种情绪突然袭来，它可能很快就会被我遗忘。 但也正是在这样一个下午，我突然产生了一种很强烈的感受：也许这已经是我人生中最幸福的时刻了。这个念头出现的时候，我自己也被吓了一跳。可能正因为眼前这一切太幸福了，悲伤才会从里面慢慢浮现出来。我想到父母会老，孩子会长大，我不可能永远停留在此刻。很多年后再回头看，今天下午也许会变成某种再也回不去的梦境。这一刻，我很清楚地意识到：幸福其实是短暂的，只会某个阶段里偶然被我们遇见。 不知怎的，这种情绪让我想起了《兰亭集序 》。小时候在语文课本里学过王羲之的这篇序文，也全文背诵过：暮春三月，群贤毕至，少长咸集；流觞曲水，列坐其次。老师讲过字词，课本里也有现代文翻译。但说实话，那个时候我并不真正理解王羲之为什么写着写着会忽然悲伤。在一个风景那么好的地方，和一群朋友饮酒作诗，本来是极快乐的事。为什么突然要说“修短随化，终期于尽”？为什么要感慨“向之所欣，俯仰之间，已为陈迹”？小时候读到这些句子，只觉得这是古人惯常的人生感叹，是一种离自己很远的情绪。 直到今天，我才突然明白了。王羲之悲伤的不是兰亭不好，恰恰是因为兰亭太好了。人在极度幸福的时候，反而最容易意识到幸福的短暂。眼前越圆满，越能感觉到它的不可挽留。那些此刻正在发生的快乐，几乎在发生的同时，就已经开始走向消逝。 向之所欣，俯仰之间，已为陈迹。 过去我只是记住了这句话。今天我才知道它在说什么。 这段时间，这种情绪变得越来越明显。原因不仅是家庭生活本身，也和 AI 有关。我一直在跟进和学习最新的 AI 工具。新模型、新产品、新概念，几乎每天都在出现。刚刚理解一个工具的用法，似乎又有更高效、更强大的东西把它替代掉。时间久了，会有一种很深的力不从心感。 这种焦虑，是一种永远无法掌控局面的感觉。无论你多努力追赶，前方都像是在不断加速。你不知道今天学到的东西明天还有多少价值，也不知道现在赖以安身立命的技能，会不会在几年之内变得一文不值。如果只是我一个人，可能还好一些。人总可以对自己说，大不了从头再来。但当我看到父母、妻子和孩子时，这种焦虑就变得沉重起来。因为我真正害怕的，是眼前这份来之不易的幸福生活，会不会被某种更大的时代浪潮卷进去。 父母、妻子、孩子，一家人幸福安稳地生活。正因为它们这么具体，我才会更害怕失去。以前的人当然也面对无常。疾病、衰老、离别，这些自古以来就存在。但我们这一代人的无常感，似乎又多了一层新的东西。我们不只是面对生命本身的无常，还面对时代结构的无常。AI 革命可能正在到来，而且它带来的变化，也许会比过去许多技术变革更剧烈。工作、教育、财富分配、社会组织方式，甚至普通人理解世界和参与世界的方式，都可能发生变化。 于是，一种古典的悲伤和一种现代的焦虑叠加在了一起。古典的悲伤是：再幸福的时刻也终将消逝；现代的焦虑是：即使我想守护眼前的生活，也不知道应该怎样做。这两件事叠在一起，就形成了一种很难说清的状态。它是一种更深的无力感。你知道人生本来就不可掌控，同时又发现时代正在变得更加不可掌控。你想让眼前的幸福持续下去，却不知道自己应该抓住什么。 也正是在这种状态里，我重新想起了《兰亭集序》。一个身处 AI 革命前夜的现代人，居然会在某个周末下午，在妻子和孩子熟睡的卧室，体会到一千多年前一个古人的情绪。时代完全不同，但情绪的底层居然是相通的。人在最幸福的时候，会忽然意识到幸福不能永久保存；人在最想守护某些东西的时候，会忽然感到自己并没有那么大的力量。 很多文章，年轻时读不懂，是因为人生还没有走到那里。那时我们只是把它当作课文，当作考试材料。等到某一天，生活本身把你带到类似的位置，你才会突然发现，原来那些句子不是写在书上的，而是早就等在你生命里的某个地方。 这也许就是文学存在的意义。王羲之没有解决无常。他没有办法让兰亭雅集永远持续。他能做的，只是把那一刻写下来。于是那场聚会消失了，但又没有完全消失。它变成了文字，变成了一种后人仍然可以进入的情绪。时代会变，表达方式也会变。可人心里那些最基本的东西，似乎没有那么容易改变。一个人对幸福的珍惜，对失去的恐惧，对时间的无力感，以及想要通过文字保存某个瞬间的冲动，在一千多年前和今天之间，依然可以彼此相认。 每览昔人兴感之由，若合一契，未尝不临文嗟悼，不能喻之于怀。固知一死生为虚诞，齐彭殇为妄作。后之视今，亦犹今之视昔，悲夫！ 也许这就是我今天从《兰亭集序》中获得的东西。它只是让我知道：我此刻感受到的不安，并不是孤立无援的。很久以前，也有人在极乐之中看见无常，在美景与欢聚中想到消逝，并且把这种感受写了下来。一千多年后，一个普通人在 AI 革命前夜的周末下午，坐在家里，听着妻儿熟睡的声音，忽然读懂了他。这件事本身，就已经给了我一丝确定感。 故列叙时人，录其所述，虽世殊事异，所以兴怀，其致一也。后之览者，亦将有感于斯文。 没想到多年以后，我竟能从《兰亭集序》中获得力量。可能很多时候，人无法阻止幸福成为“陈迹”，但可以决定它成为怎样的陈迹。是仓促经过、事后遗憾的陈迹，还是被认真活过、认真记住的陈迹。 今天这篇文字，也是从我和 AI 的一段对话中慢慢成形的。这一点本身就很有意思。我担忧 AI 带来的未来，却又借助 AI 整理自己的情绪。好像一切都开始和 AI 发生联系，连关于无常、家庭、文学和自我的思考，也不能完全置身事外。

最近上线了一个小工具：SeveranceGO-CN：中国离职补偿金计算工具 。项目代码也放在 GitHub：masonblog/SeveranceGO-CN 。 它的用途很直接：输入入职时间、离职时间、上一年度收入、劳动合同履行地、合同签署情况、离职原因等信息后，工具会估算经济补偿金、违法解除赔偿金、代通知金，以及未签书面劳动合同可能对应的二倍工资区间。 先把免责声明放在前面：这只是辅助估算，不能替代正式法律意见和律师判断。 劳动争议里，解除理由、通知程序、证据材料、当地工资口径、仲裁和法院尺度，都会影响最后结果。这个工具更像一次"第一轮体检"：先把大概区间、关键变量和风险点列出来，方便当事人知道接下来该核对什么。 为什么要做这个工具 做公司业务和劳动争议咨询时，我经常遇到同一个问题： 公司要跟我解除劳动合同，我大概能拿多少钱？ 这个问题看似简单，其实很容易算偏。 很多人只记得一个公式：工作几年就是 N，违法解除就是 2N。但真正落到个案里，马上会冒出一堆细节：工作年限怎么折算？半年以上不满一年算不算一年？月工资有没有封顶？当地上年度职工月平均工资是多少？公司属于无过失性解除，还是经济性裁员？有没有提前三十日通知？没签书面劳动合同的期间从哪天起算、到哪天截止？ 律师当然可以逐项解释，但很多基础问题完全可以先交给一个表单处理。尤其是在咨询前，如果当事人已经知道自己可能涉及 N、N+1、2N，还是二倍工资争议，沟通效率会高很多。 于是我就想做一个尽量朴素的工具：不制造焦虑，不承诺结果，只把规则摊开，把计算过程写清楚。 法律规则不是一句 prompt 就能解决的东西 这个项目最有意思的地方，在于如何把劳动法规则翻译成代码。 法律人看《劳动合同法》第四十六条、第四十七条、第八十二条时，脑子里浮现的是构成要件和法律效果：什么情形应当支付经济补偿，补偿年限如何计算，月工资基数如何确定，什么情况下适用三倍封顶，未签书面合同什么时候触发二倍工资。 程序员看同一组问题，看到的是输入、分支、边界条件和输出。 Vibe Coding 的价值也在这里：我不用先把自己训练成一个全栈工程师，才能开始做产品。但这并不意味着我可以只对 AI 说一句"帮我做个离职补偿计算器"，然后等它交付成品。越是法律产品，越不能这样做。 我的做法是先把规则拆成几层： 事实输入层：入职、离职、收入、地点、合同签订时间、解除原因。 法律判断层：判断是否可能存在经济补偿、违法解除赔偿、代通知金或二倍工资。 数据口径层：匹配地区工资数据、最低工资、封顶基数，并允许用户手动覆盖。 结果说明层：不仅给一个数字，还要说明这个数字是怎么来的、哪些地方需要复核。 这其实很像写一份法律检索备忘录：先列事实，再列规范，再做归入，最后提示风险。只不过这次的输出物从 Word 文档变成了一套可以运行的 React + TypeScript 页面。 最难的是边界感 做法律工具，最怕两种倾向。 一种是装得太懂。明明只是按公开规则做估算，却把结果包装成"你一定能拿到这么多钱"。这很危险，因为劳动争议高度依赖证据和程序细节，一个解除通知书的措辞、一次谈话录音、一次调岗降薪的背景，都可能改变判断。 另一种是缩得太后。什么都说"具体情况具体分析"，最后用户看完还是不知道自己在哪里。 我希望这个工具站在中间：该算的先算，该提示的明确提示，该留白的地方不要硬判。比如疑似违法解除，就展示 2N 的估算区间，同时提醒用户核查解除理由、规章制度、送达程序和证据链；涉及第 40 条解除，就把是否提前三十日通知作为影响 N+1 的因素；未签书面合同，则单独估算可能的二倍工资区间，不把它粗暴塞进补偿金里。 这也是法律人参与 Vibe Coding 的一个优势：我们对"不确定性"比较敏感。代码喜欢确定答案，法律常常只有风险区间。真正要做得可用，就要让产品承认这种不确定性。 数据口径：先可用，再持续修 首版内置了 2024 年工资标准参考数据，并覆盖中国大陆各省级行政区下的地级行政区、自治州、地区、盟以及部分省直管县级行政单位。这里面最麻烦的是，各地公开口径并不完全一致，有的城市能找到官方全口径或城镇单位平均工资，有的只能暂用国家统计局分区域数据作为封顶参考；最低工资也会存在不同档位。 所以我在页面里保留了"可覆盖"输入框：如果用户掌握当地仲裁、法院或人社部门最新口径，可以手动填入。对法律工具来说，这比假装数据库永远正确要诚实得多。 后续我会继续补充和校正数据源，也欢迎熟悉本地劳动争议口径的朋友提 issue 或 PR。 给律师的一点感想 过去我们总觉得，律师的技术化转型大概就是会用检索库、会写提示词、会让 AI 起草合同。但做完这个工具后，我越来越觉得，真正有价值的地方不止是"让 AI 替我们写文字"，还包括把法律服务里可以结构化的部分产品化。 ...

起心动念：一个法学生的"不务正业" 作为一名公司律师，我每天打交道最多的就是各种法规条文，以及来咨询各种法律条文的亲戚朋友。其中一个最常被问到的问题，就是各种劳动法规。尤其是各地假期政策，比如婚假怎么请，产假有多长……这些是每个人都会遇到的问题。 前段时间，我有个朋友跳槽到一家深圳的公司，问我：“深圳的陪产假到底是几天？网上查的乱七八糟的。“我翻了一圈，发现确实如此。国家层面有一套规定，各省又有各自补充的地方规定，信息散落在各级人社厅的官网、政府公报、地方性法规里，没有一个能一站式对比查看的地方。 我当时就想：要是有一个网站，选一个省份，所有假期政策一目了然，中央规定和地方特别规定并列展示，每条规则还附上法律出处，那该多好。 然后我脑子里蹦出另一个念头——我为什么不自己做一个呢？ 放在以前，这个念头冒出来三秒钟就会被我自己摁回去。我不会写前端，不会画地图，不知道怎么部署网站。但最近这一年，情况变了。 当法学撞上 Vibe Coding 先聊聊什么是 Vibe Coding。这个词是 Andrej Karpathy 在 2025 年初提出来的，大意是：你不再需要逐行手写代码，而是用自然语言描述你想要什么，AI 帮你写。你要做的不是"编程”，而是"指挥”。你负责想法和品位，AI 负责执行。 我刚接触 Vibe Coding 的时候，也经历过一段迷茫期。看别人用 Cursor、用 Claude Code 三下五除二搞出一个项目，自己上去一试，发现根本不是那么回事。AI 确实能写代码，但写出来的东西经常有这样那样的问题：组件渲染不出来、类型报错、样式错乱、路由不对…… 后来我慢慢悟出来一个道理：Vibe Coding 不是"不用动脑子"，而是"换一种方式动脑子"。 你不能真的完全放手，你得学会审阅代码、提出精准的修改指令、在 AI 卡壳的时候指出方向。某种意义上，这和 review 一篇法学论文没什么区别——你不是从头到尾自己写每一个字，但你必须判断哪里有问题、该怎么改。 而我的法律背景，在这个项目里扮演了一个意想不到的角色。 法律思维如何重塑我的开发流程 法学的核心训练是什么？如果只让我说一点，那就是体系化的分类与归入。面对一个案件，你要做的第一件事不是拍脑袋下结论，而是把事实拆解成若干个法律要件，逐一检视，最后得出结论。 这套思维方式，在我做这个假期政策查询网站的时候，天然地映射到了数据结构的搭建上。 假期政策说白了，就是一个多层级的规则体系： 第一层，国家法定基准。比如产假 98 天、婚假 3 天，这是写在《女职工劳动保护特别规定》和《人口与计划生育法》里的，全国通用。 第二层，各省地方补充规定。比如上海在 98 天基础上再加 30 天产假，广东的陪产假是 15 天，少数民族自治地方还有特殊政策。 第三层，兜底规则。如果地方没有特别规定，就自动沿用中央标准。 这个三层结构，我用法学里"一般法与特别法"的关系来理解：特别法优先于一般法，特别法没有规定的，适用一般法。这恰恰就是代码里 mergePolicy() 函数的核心逻辑——先加载中央基准数据，再用各省的覆盖字段去 merge，本地有的覆盖中央，本地没有的 fallback 到中央。 所以当 AI 问我要怎么设计数据结构的时候，我几乎没有犹豫就画出了这个 YAML schema： 婚姻假: 天数: 3 适用条件: 依法办理结婚登记的夫妻 工资待遇: 正常发放 法律依据: - 名称: 国家劳动总局、财政部关于国营企业职工请婚丧假和路程假问题的通知 条款: 第一条 然后在各省的文件里，只写和中央不同的部分。比如江苏： ...