HarmonyOS 鸿蒙Next怎么关闭严格模式，开发人员能不能管一下这个功能

有一段代码如下，是不是感觉AI都写不出来这样无脑的代码？不是我想这样写，是因为deveco 的什么判断，估计是强制开启了严格模式，会进行类型检查。

如果不这样写，就会报错如下：

但是实际上传参时，已经传的是所有参数已定义，只是因为接口定义中，成员是可选项。模拟器运行调试截图如下：

就是因为这种情况，其实许多可选属性都是已经定义了的，只是因为使用的接口中是可选的类型成员，是自动number|undefined。导致现在代码中，用来判断可选属性是否存在的if语句，都快赶上正常功能代码的1/5了，这他妈1/5开发时间都是无效作用。那么如果接口中新增成员，那不是还要在所有用if 判断涉及到这个接口得地方去增加条件？哪个人想出来得这种东西。要不然就是使用重新赋值，let xx:number = k.shuxing as number;不满篇if判断了，整个满篇as 语句？？？？？？？？当数据类型是number值为0时，简单用一个if（对象）还判断不出来，还得用if(对象 || 对象 ==  0)，如果一个接口中多几个number类型成员，那不是if（老长的条件语句，可能要换个10行），这样很舒服？特别是UI中，好多UI组件属性值都是number类型。

其实deveco3.0并没有这种严格的类型判断，用起来特别舒服，虽然调试起来，可能会因为属性未定义报错，但是也比这满篇都是if else判断可选类型好。并且，哪个开发者会在自己的程序里面写一大堆undefined属性，一般都是直接在构造时就赋值了，或者写一点就测一点，根本不会存在因为属性未定义，在调试时找不到问题的情况。即使要用，也会谨慎使用，例如函数返回值时，可能用得比较多。麻烦开发者用的东西，按照开发者的来，整一个简单算法判断，有用？要做就做好，做了后，自己用一下，自己都不用，用起来不舒服，拿给其他人用，不抵触才怪，又不是像鸿蒙系统这种不可或缺的东西。开发者不是AI，不需要什么都限制得死死的，不然就申明ArkTS是给AI专用的语言，不需要开发者参与，我绝对不会再用。

本来打字就慢，还要打一大堆没必要的if else，实在不行，就不允许用undefined的类型，那估计这内存管理起来得成什么样。

最后其实是想请教下大佬，怎么把这个类型判断模式给他取消掉，是真的不需要这个功能，就是ArkTScheck。感觉鸿蒙的官方人员又换了一批了，真没以前感觉给力（那种开拓的感觉，变成随波逐流）。