Chuckle

@Chuckle vue 里一堆 any 那是没得救的，emit 的 n 种类型写法，不知道匹配到啥的 function call 参数，没人维护的 inject 类型。reat 里要是一堆 any ，函数泛型慢慢拆，时间问题。自己项目 vue 干得快，多人的公司的项目，必须 react ，但我感觉现在这哥三框架，用着都多多少少有不得劲的地方

react 业务逻辑拆 hook 里，但是很难受的就是，业务逻辑往往又是多变多情况的，很可能今天封好，明天别人看不懂或者不好原地改，只能 cv 一个副本拿去用，而且拆得越多，写 props 和传参 n 层就非常麻烦，也不好维护一堆 ts 类型，这个倒是可以用状态管理解决，但那种多个地方用的组件，因为要用 context 隔离状态其实也挺难受的。vue 的话，vsc 插件太卡了，ts 服务经常也挂，一堆堆的语法糖，公共组件 v-model 和 emit 那套处理起来可比 react 麻烦多了，单文件行数爆炸，类型维护也难，但整体还是比 react 写法规范点，毕竟语法糖限制死了，react 里可见到太多把 hook 玩出花活一层套一层的了，我现在拿 vue 的响应式和 react 结合起来玩，写了个类似 valtio 的东西，清爽很多。react 的文档啊，其实能教的也都教了 但保不齐有人玩花活整点 js 里要动脑子的技巧。

还是更喜欢用装饰器一点，更灵活，堆叠也比函数嵌套调用直观好写，ts 的装饰器本质上也就是把 class 构造器、函数给传了进去，所以既可以 @装饰也可以直接函数调用 遇到需要运行时的动态注入，装饰器也可以封装出更简单的语法糖

那肯定得有地方存这些 md 吧，用咱这个 vsc 插件吧，https://github.com/qxchuckle/vsc-drafts ，平时一些简单脚本、项目记录、画图啥的我都扔草稿本里

能信任编译器的输出结果，那是前人从二进制驱动机器以来的智慧和努力啊 前面的一切都是数学和形式化方法的结果，别人已经关心过了，现在也有人持续的在关心，输入输出的无数可能都已经覆盖完了，多少测试覆盖支撑着这份信任。
而大模型底下是概率抽样，让它写代码，说白了，就是赌风险和收益嘛，还发明个 vibe coding 名词来掩盖放下点责任心想轻松点的人之常情。当然，业务代码里随手写的工具函数，正常来说也不会去做充足的测试、校验、错误处理，反正要字符串不会来个对象就行了，炸了再热修也行。
当然我是觉得，业务代码不可能人不看的，不看那就是用户替你去看了，出了问题特别是像钱算错了，背锅的只能是人啊。现实点，ai 总是接手现有的项目的迭代吧，一个 id 字段在不同对象里几十种意思，ai 啥时候能自己去问 git 历史提交的人？当然，有些面向司内的东西，已经是 ai 开发了，反正没风险。

看地方政策，杭州能一次性提 12 个月的，隔天到

理论上可行，但是现在大模型做不到，一个能用的低代码页面快 10w 行的 schema ，其中 6w 行是各种逻辑节点，无论是企业版 cursor ，还是做到低代码平台里调 api 的大模型，都直接爆了，cursor 大于 2mb 读都读不了，按结构、逻辑等拆分后，幻觉也太严重，什么“极速开单”之类的文本随机插入到 json 里，生成速度也很慢，体验上就是 5 分钟一次抽盲盒，至于提效就更别说了。

上周让 cursor 改个上 w 行的 json ，生成一半不到就加好几个“极速开单”，切换对话也一样