Chuckle

还是更喜欢用装饰器一点，更灵活，堆叠也比函数嵌套调用直观好写，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 ，生成一半不到就加好几个“极速开单”，切换对话也一样

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

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