起心动念：一个法学生的"不务正业"

作为一名公司律师，我每天打交道最多的就是各种法规条文，以及来咨询各种法律条文的亲戚朋友。其中一个最常被问到的问题，就是各种劳动法规。尤其是各地假期政策，比如婚假怎么请，产假有多长……这些是每个人都会遇到的问题。

前段时间，我有个朋友跳槽到一家深圳的公司，问我：“深圳的陪产假到底是几天？网上查的乱七八糟的。“我翻了一圈，发现确实如此。国家层面有一套规定，各省又有各自补充的地方规定，信息散落在各级人社厅的官网、政府公报、地方性法规里，没有一个能一站式对比查看的地方。

我当时就想：要是有一个网站，选一个省份，所有假期政策一目了然，中央规定和地方特别规定并列展示，每条规则还附上法律出处，那该多好。

然后我脑子里蹦出另一个念头——我为什么不自己做一个呢？

放在以前，这个念头冒出来三秒钟就会被我自己摁回去。我不会写前端，不会画地图，不知道怎么部署网站。但最近这一年，情况变了。

当法学撞上 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
  适用条件: 依法办理结婚登记的夫妻
  工资待遇: 正常发放
  法律依据:
    - 名称: 国家劳动总局、财政部关于国营企业职工请婚丧假和路程假问题的通知
      条款: 第一条

然后在各省的文件里，只写和中央不同的部分。比如江苏：

婚姻假:
  天数: 13
  法律依据:
    - 名称: 江苏省人口与计划生育条例
      条款: 第二十七条

这个设计思路，法学圈的人一眼就能看出来是"特别法优于一般法"的逻辑，但你要让我从头手写代码实现这个 merge 逻辑，放一年前的我绝对写不出来。现在呢？我把思路描述给 AI，半分钟代码就出来了，而且类型检查全过。

Zod 数据校验也是同样的道理。法律讲究"形式要件"，合同缺了某个必要条款就无效。映射到项目里，就是数据文件必须有严格的 schema 验证——central.yaml 必须包含全部 7 类假期，省份文件里每个假期必须包含"天数"字段，法律依据不能为空。我把这些约束用自然语言描述给 AI，它生成了一套 Zod schema，build 之前自动跑一遍验证脚本，任何一个省份的 YAML 格式不对，整个 CI 直接报错。

说起来有点好笑，我的导师要是知道我拿法律方法论去"调教" AI 写代码，不知道会怎么想。但说实话，这种跨学科的思维迁移，恰恰是 Vibe Coding 时代最有意思的部分——你不需要是一个科班出身的软件工程师，但你需要有一套成体系的思考框架，不管这套框架是来自法律、医学、建筑还是音乐。

从想法到产品：一个周末的构建记录

想法有了，方法论也理顺了，接下来就是动手。

整个项目的技术栈选择，我基本遵循一个原则：选最主流、AI 最熟悉的方案。这不是炫技的时候，我是拿来主义的信徒——Next.js + Tailwind CSS + shadcn/ui，这套组合是 AI 训练数据里最充分的技术栈，意味着 AI 出错的概率最低。

数据层：31 个省的假期政策汇编

这其实是最耗时的部分。代码可以靠 AI 生成，但内容不行。

我花了差不多两个完整的周末，逐一翻查了 31 个省级行政区的卫健委、人社厅官网，以及各地方人大发布的计划生育条例修正案。每一条规则我都在旁边标注了原文件的名称、条款号和官方链接。有些省份的规定藏得特别深——比如某个自治区的陪产假规定，写在一份 2016 年的《关于修改〈XX 自治区人口与计划生育条例〉的决定》里，要顺着修正案的指示往前翻原文才能拼出完整的规则。

这件事 AI 帮不了忙，至少现在帮不了。它可能会"编造"一些看起来很像真的法条，但在这种事上，一个法律人的底线还是有的——数据必须可溯源。

所有整理好的数据，我按照 XX-pinyin.yaml 的命名规范放在 data/provinces/ 目录里，一共 31 个文件，加上一个 central.yaml 做基准。

前端：SVG 中国地图的三天折磨

整个项目里最让我头疼的部分，是中国地图。

一开始我想得很简单：找个现成的 ECharts 图表库，把中国地图渲染出来就完了。结果发现 ECharts 的中国地图用的是 GeoJSON 格式，数据量巨大不说，暗黑模式下的颜色适配也很麻烦。AI 建议我用原生 SVG，但网上找到的中国地图 SVG 大多质量堪忧——边界线粗糙，有些省份的路径数据甚至不完整。

最后我采取了一个折中方案：让 AI 帮我生成一个精确的 SVG 路径数据，存储为 JSON 文件，每个省份一条 path，包含 viewBox、路径坐标和省份中心的经纬度。然后自己写了一个 React 组件来做交互。

这里有个细节值得一提：小省份的点击区域。北京、天津、上海这些直辖市在地图上实在太小了，鼠标根本点不到。我当时跟 AI 反复来回了好几轮，最后想到一个办法——在路径外面套一层不可见的圆形点击热区，半径放大 3 倍，覆盖周围的空白区域。这个方案 AI 没有主动提出来，但当我描述给它之后，它很快就实现了。

地图的热力图配色也调了很久。我定义了一个"假期热度值"，把婚假天数、产假天数和陪产假天数相加，然后分成四档：

  • 绿色（≥200）：假期福利比较到位的省份
  • 黄色（190-199）：中上水平
  • 红色（180-189）：中等偏下
  • 深红色（<180）：假期天数较少的地方

说实话，这个"热度值"的算法相当粗糙，但我就是想给用户一个直观的视觉感受——一眼扫过去，大致知道哪个"颜色区域"假期多一些。未来如果有时间，我打算引入更多权重因素，比如育儿假、探亲假也纳入计算。

每个省的详情页：七类假期的卡片式展示

省份详情页的设计灵感来自我手机上的健康 App 仪表盘——每一类假期是一张独立的信息卡片，顶部显示天数，中间是适用条件和工资待遇，底部折叠了资格认定和注意事项的详细说明。

最有价值的设计是 “来源标签"系统。每条规则右侧都会有一个小标签：

  • “中央规定”（灰色标签）：表示这条来自国家层面的法律法规
  • “本地特别规定”（蓝色标签）：表示这是该省在中央基础上额外制定的政策

两者并列展示，用户一眼就能分辨出哪些是国家给的、哪些是本省额外补充的。

部署：GitHub Actions + GitHub Pages，零成本上线

部署部分反而是整个项目最简单的一环。

Next.js 有个特性叫 Static Export，简单说就是把整个网站预渲染成纯静态的 HTML + CSS + JS 文件，不需要服务器。我只需要在 next.config.mjs 里加一行 output: "export"，然后配置 GitHub Actions 在每次 push 代码到 main 分支的时候自动 npm run build，把产物推到 GitHub Pages 上。

CI 流水线也很干净：

  1. Checkout 代码
  2. npm ci 装依赖
  3. npm run validate-data 校验所有 YAML 数据文件的格式
  4. npm run typecheck TypeScript 类型检查
  5. npm run build 构建静态产物
  6. 部署到 GitHub Pages

从 push 代码到网站更新，全自动，整个过程不到两分钟。

最终线上地址：masonblog.github.io/HolidayGO-CN

写在最后：AI 时代，创意才是真正的稀缺资源

这个项目做完，我最大的感触不是"AI 好厉害”，而是——在 AI 时代，有想法的人太少了，能把想法落地的人更少。

你不信的话，想想看：全中国每年有多少法学生、律师、HR 从业者，每天都在查假期政策，查完之后该干嘛干嘛。有多少人会冒出"我为什么不做一个查询工具"这个念头？又有多少人冒出了这个念头之后，真的打开电脑，开始做了？

AI 拉平了技术实现的鸿沟，但没有拉平"想不想做"和"能不能坚持做完"的鸿沟。

我不是什么编程大神。在开始这个项目之前，我连 Next.js 的路由是怎么写的都不知道。但现在呢？一个可用的产品摆在这里，31 个省的数据覆盖齐全，有暗黑模式、有交互地图、有来源溯源，CI/CD 全自动部署。这些东西，放在两年前，是我一个文科生想都不敢想的事情。而在 2026 年，我用业余时间，借助 AI，做到了。

所以我想说的是：如果你的脑子里一直有一个"要是能有个什么东西就好了"的想法，别犹豫，现在就动手。不需要等到你"学会了编程"才开始——那个时代已经过去了。你只需要：

  • 一个清晰的想法（这是你最独特的资产，AI 抢不走）
  • 一套成体系的思维框架（不管来自哪个学科）
  • 愿意花时间去打磨细节的耐心（AI 能帮你写代码，但打磨产品只能靠你自己）

剩下的，交给 AI 和时间。

这个项目的所有代码开源在 GitHub：masonblog/HolidayGO-CN。如果你对假期政策数据有补充或纠错，欢迎提 PR。

如果你也是一个非技术背景、但用 AI 做出了自己作品的"野生开发者"，欢迎在评论区聊聊你的故事——我很想听听。