Ketteiron

@skkakaka2 #13 并不行
```typescript
interface A {
b: B
}
interface B {
c: 'c'
}
const a: A = { b: { c: 'c' } }

console.log(a)
// ^?
此时 a 的类型是 A ，而不是 { b: { c: 'c' } }
在这之前不装插件我不知道怎么才能显示完整类型，试了下一些插件效果不好

简单变量肯定全是 ref ，我先假设你指的是对象用 reactive 还是 ref 包裹。
如果你写了很多 usehooks ，或许会发现 reactive 比 ref 更好用。
例如简化业务逻辑经常会自行封装 useTable/useForm 等参数，然后传递 api 类型，用泛型推断出参数和返回值类型。
此时可以用这样的写法
const params = reactive({}) as T
const model = reactive({}) as K
暂时用空对象欺骗下 ts 推断正确类型
而不是得到 T | null ，不得不写没必要的可选链，只要源头的类型是正确的，那么运行时实际也是安全的。

@shubiao #71 AIDA64 之类的一大堆啊，鲁大师是面向小白用户的，几乎没有参考价值，也就是推广做得好。

目前所有 AI 检测 AI 的项目都是狗屁不通的玩意，也就骗骗投资人。
如果什么提示词都不加，AI 生成确实会有十分显著的特征，例如大段废话，低质量注释。但使用提示词、agent ，它生成的文本与真实人类所写的几乎不存在统计学上的区分性。

@tiRolin 什么原因，没信心找到下一份工作？
公司又不是你开的，裁员了除了走人还有什么办法，不然世界上就不存在裁员了。
假如招一个人进来无法简单开除，那么面试难度增加一百倍你能接受吗。

@muchan92 #68 缺点是几乎无法正常测试，所有规则都是黑盒，就如#62 说的，可维护性是非常重要的，能保证大型项目能正常迭代。
你这种做法相当于是放弃了各种测试和静态分析，在组合数量爆炸时虽然不用梳理大量组合逻辑，但是一个规则对其他规则以及集合总体的影响是几乎无法预知的，有好处，也有坏处，在我看来坏处大于好处。

好奇看了下 demo 给我看晕了。
这要是真有人用在生产上，怕是一半时间都在 debug 。
声明式/响应式编程我承认有一定合理性和可行性，本质上是希望将 n²的组合复杂度缩小为 2n ，虽然其实并没有消除任何复杂度。