@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 的文档啊，其实能教的也都教了 https://i.imgur.com/agAJ0Rd.png 但保不齐有人玩花活整点 js 里要动脑子的技巧。

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

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

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

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

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

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

@Chuckle 还有就是为了绕过浏览器的限制，内置 vpn 、认证啥的，反正就是为了方便

除了为了指标、任务做这种 zzzq 的东西，集成企业内部系统，内置插件，开箱既用或许有些说法，毕竟不是人人都是开发。对于开发来说，都不如 Thorium ，性能好才是硬道理。至于什么监控、安全，公司电脑一般都有安装**安全软件的吧 https://i.imgur.com/agAJ0Rd.png 还用得着专门搞个浏览器

@Chuckle #6 用最长子序列搞了字符级的 diff 标记

@sibusana 最后就是用了第二种方案，直接进行了 dom diff ，差不多是 html diff 的简化版吧，只 diff 了文本，而且 dom 的相对位置一样才是修改，不然就是删除后再添加 https://i.imgur.com/agAJ0Rd.png 够用了，不知道 react 上的 dom diff 有没有现成的库，而且一旦替换了 react 管理的 dom ，react 后续就没法正常更新那个 dom 了，所以必须每次渲染都随机 key ，强制更新整个组件。

菜得离谱（不用看谱也能做菜）

好菜

@kamilic diff 倒是简单，loadsh 都有现成方法，后面我还是用了方案二，写了个通用组件，把新旧数据都渲染一次，然后用 observer api 观察子元素 dom ，dom diff 、算最长公共子序列，把增删改的文本在新 dom 上标记了出来，不过坏处就是只能对文本节点操作，像勾选框之类的就没办法了

以前我也是把文档看了 7788 、写了不少 demo 后才开始做东西，但有了 ai ，先开始做再说，遇到问题先用自己的办法解决，后续迭代功能，让 ai 帮助重构，ai 也能提供新的思路、api 、工具，实在干不出来，或者有点思路想偷懒，就让 ai 自己写，写完 cr 调试下，差不多了，再去看里面代码实现

在用洛斐小顺，机械矮轴

@Shokupanman 每种 type 都是独立的组件，要展示的内容、value 数据结构都不同，没法复用