前几天刷到那篇讲用YAML写spec治AI幻觉的文章，我抱着试试的心态在自己维护的私有Vue组件库里落地了俩月，说实话最惊喜的反而不是AI相关的收益，是对开发者体验的提升太明显了。
我把所有组件的props、插槽、事件定义全统一写在YAML spec里，写了个几十行的小脚本自动生成TS类型声明、文档站点片段、单测用例骨架，之前改个props要同步改三处的破事彻底没了，最近俩月组件的属性相关bug直接降了60%。
喂给AI生成业务代码的时候直接丢spec过去，输出准确率直接拉到90%以上，省了好多debug的时间。转换脚本我已经开源到GitHub了，要的评论区说一声我发链接。

我上次帮学生会做活动报名组件库，改个提交按钮的权限props忘了同步改单测，上线直接崩，被部长骂半小时啊대박！话说快把链接甩我啊！
之前改个属性要同步改三处的破事我真的受够了，上周为了改个弹窗尺寸，我光找三个得方的代码找了半小时，眼睛都花了。还有喂AI那个我之前啰啰嗦嗦说半天，输出都奇奇怪怪的，准确率低到离谱，这方法我马上试，蹲死链接了啊！

之前组里推configuration as code的时候我还觉得有点overkill，毕竟内部工具的迭代速度快，没必要花额外时间搞重规范，现在看你这玩法简直是把单一数据源的优势玩到极致了啊。
我前两年维护过组里公共的React组件库，那时候最烦的不是写组件逻辑，是每次迭代完要同步给内部文档站、下游业务组的对接wiki、还有测试组的用例库，但凡漏了一处，后面就得接至少三四个slack消息过来问。我还试过用JSON写过一阵子spec，但嵌套层级一多括号看得我眼晕，远不如YAML的缩进读着舒服，对非技术岗的产品同事也友好太多，他们要查参数直接看spec就行，不用翻代码。
说起来这种把重复的同步劳动全automate掉的爽感，跟我周末去半月湾钓鱼前把鱼线、饵料、抄网按使用顺序理进钓箱的感觉一模一样，所有参数都有准谱，不用中途慌慌张张翻找东西。上次我改个公用卡片的阴影属性，漏更了销售团队用的demo站，被PM找过来的时候我正摸鱼查下周钓鱼点的潮汐表，尴尬到想钻到显示器后面去。
对了你的脚本能不能适配React组件的类型生成啊？我最近在写个记录钓鱼点位的私人小web app，正愁组件属性改来改去两边同步麻烦，等你链接发我我fork了改改，要是调通了给你提PR加个React的生成模板？

看到你被 PM 抓包时正在查半月湾潮汐表，我瞬间想起在蓝带学 patisserie 的某个下午——chef 推门进来，发现我凭记忆在调 ganache 的温控，而不是对着打印好的 recipe。那种 “我明明记得是 58 度” 的自信，和你漏更 demo 站时的心态，本质上是同一种幻觉：人类短期记忆在同步任务面前丢包率极高，RFC 1149 都比它可靠。

厨房里有个规矩叫 “une recette, une vérité”。一份配方，只有一个真相。所有 station 的 prep list、成本卡、过敏原标签，都从 master recipe 派生。你改糖量，只改一处；如果手动抄到 pastry station 时抄错，出品就是 disaster。所以楼主这套 YAML spec 在我看来根本不是 “重规范”，而是把 mise en place 引入了前端工程，所有配料在开工前按 gram 称好，生成脚本就是你的 prep cook。

具体到你想 fork 去适配 React，有几个坑比你想象中深。Vue 的 props 定义是运行时可自省的对象，生成 TS 类型基本是 1:1 映射；React 这边你大概率要处理三种范式：React.FC<Props>、ComponentPropsWithoutRef、还有 forwardRef 的泛型注入。如果你用字符串模板硬拼 .tsx 文件，遇到 Omit<Props, 'children'> 或者条件类型时维护成本会爆炸。直接上 ts-morph，它能像操作 AST 的 stand mixer 一样把类型节点揉进去，而不是靠正则表达式切字符串。简单说

具体做法：用 Project 实例化一个内存文件系统，sourceFile.addInterface 把 YAML 解析后的节点写进去，遇到 ref 标记的字段自动套一层 forwardRef<HTMLDivElement, Props>。比模板字符串多写二十行初始化，但日后加泛型或者条件类型时，你就不用维护一堆 ${...} 的 edge case。

另外，建议你在 YAML 里重度使用 anchor/alias。你们那个公用卡片的 shadow 属性，如果在二十个组件里复制粘贴 box-shadow: 0 1px 3px rgba(0,0,0,0.1)，之后改设计 token 就是灾难。抽成一个 &shadow-sm anchor，谁用谁 <<: *shadow-sm，改一处全部生效。JSON 做不到这个，这也是 YAML 在这个场景下真正的杀器，远不只是 “看着舒服” 那么简单。

还有一层很多人忽略：给 spec 加一个轻量 schema 校验。yamale 或者直接用 JSON Schema 在 CI 里跑一遍，防止手滑多敲一个缩进。我在日本便利店打工那两年，夜班理货全靠 barcode scanner 和库存系统自动对账，回国后看到同事手动同步 props 到三个地方，那种感觉就像看有人用手打蛋白霜，能行，但完全没有必要。自动化不是为了炫技，是为了把社交噪音压到零，让你查潮汐表时心里踏实。其实

简单说其实写 YAML spec 的过程有点像临帖：先定间架结构（schema），再填笔画（具体字段）。前期多花五分钟把 schema 校准，后期生成类型、文档、单测就像描红，出活又快又稳。你在 React 里搞 forwardRef 那套泛型尤其需要这个，不然接口一改，下游业务组的编译错误能把你 slack 炸成火锅里的毛肚，七上八下。

你那个钓鱼点位 app 正好可以反向验证这套思路。把钓点数据（经纬度、潮汐窗口、目标鱼种）也结构化进 YAML，组件层读同一份 spec 生成表单和地图 marker。其实以后加新钓点连 TS 类型带表单校验一起出来，不用改业务代码。C’est la vie，代码和钓鱼都一样，讲究个井井有条。

ts-morph 的文档有点散，你要是卡在 Project 初始化或者 SourceFile 的 import 管理，直接 at 我。祝你的钓鱼 app 早日上线，下次改阴影属性时，PM 永远猜不到你又在看潮汐表。

哎这个思路我居然用到过完全不搭边的领域！我平时爱攒相声小品的段子库，之前每次接商演排节目单，要同时改对外的演出时长表、给搭档的配合要点提纲、后台的道具提示卡，但凡漏改一个地方，台上很容易出小事故。前阵子我也试着把每个段子的参数全写进YAML里，写了个超简单的小脚本自动生成所有需要的文件，省了超多功夫。
刚好最近想给脚本加个自动生成包袱适配场合建议的功能，求个楼主的脚本链接我参考下逻辑呀！

哈哈，看你说被部长骂半小时，想起我二十出头那会帮我家亲戚的艺考机构做报名页，那时候只会撸原生js，改提交按钮的报名权限漏了同步后台的校验逻辑，开放报名当天三个家长直接报了已经满额的播音班，我被我姨追着骂了整整两天，连去她家吃晚饭都被念叨。

之前帮朋友的户外社团维护活动组件库的时候也犯过改属性漏同步的毛病，改个弹窗的报名截止时间提示，找了半小时才找全三处要改的地方，当时差点把键盘砸了。后来摸到用spec统一管理的法子，我现在甚至把带团的路线参数全写进YAML里，十行小脚本自动生成给游客的行程单、给司机的接送点表、还有我自己的物料核对清单，旺季连轴转的时候少出了好多纰漏。

对了，你刚上手的话记得多留个心眼查缩进，我刚开始用的时候没少因为多打了个空格卡脚本卡半小时，别犯我这种低级错误。

我也蹲个链接，刚好最近想试试把路线spec喂给AI，让它自动生成不同年龄段游客适配的讲解词，省的我每次费脑子改话术。