发一些技术文章，然后可以开通专栏

很多 RPA 应用于银行，机器人领域，而且现在机械臂、机器人这种也较来较核心，转向这个领域不错的

时代也不同了，之前是各种测试技术喷发的年代，大家都在拼命搭建、组建各种方案的年代，后面慢慢成型了，进入了各种拼接，组装的年代，然后就是自媒体，分割私域，转化收益的年代

建议看下新公司的发展前景以及当天公司的的融资情况再做决定。
外包不稳定，小公司也一样会存在这种情况，建议综合考虑

领导都不重视，还是因为没有出啥大事，或者说你们通过加班成本消耗掉了。
说实话哈，就看你怎么想了，够狠就按规章办事，他们为难你，你就让他们为难你的领导去呗，有风险向上抛，规避风险 很简单。
一般情况下，愿意承担风险 的才能上位。既然在位，但又不承担风险 ，这样的领导最好就是想办法取而代之呀

拆分责任关系，关联系统做成 mock 档板，与部门领导以及测试负责人达成一致性。【请站较高角度和上层沟通问题，不建议一直扯问题，就说为了我们怎么怎么所以要这样，要明确说明，和其他同行进行了深度探讨沟通，行业内是如何做的，下结论，然后执行】
1、未接收到接口结构变更的情况下，不再进行关联复测，如果上游变更未通知，导致 的问题，由上游进行承担风险。
所有上游变更导致 的关联成本，上线相关，需要上游配合你方进行，我方资源不足也进行时，要学会拒绝。

2、上线时间成本把控到位，所有延期风险由上游承担，多长时间的结果确认明确沟通并邮件双方领导确认，如后续时间问题引起的延期，我们下游那就顺延第二天，当天不再进行上线。 同时通报是由于上游导致的延期等等。

风险向上压，规避非本方问题即可。如测试负责人或业务负责人不给力，建议找机会换部门了，没意义根本不可变改变和调整。

可以等待 30 分钟后，对接口影响数据进行验证。

我了解到目前一些基于 chatgpt 的应用，就是摸索出一套指令，然后封装指令给大模型，大模型给出执行动作，然后应用根据动作执行，吐出结果。

可以写啊，面试时可以主动说明使用 java 做了些什么事情，尝试在工作中如何使用什么的，也一直在努力继续学习之类的

感觉有些偏
Tid、FileIds 这两个在后端体现上，只是两个入参，而且在代码层面上是被确定的参数类型，同时也包括是否为必输项。
只要传入格式不正确，程序就会拒绝访问。

单从这个场景来看，建议从正确参数组合非正确参数，fileids 组合存在不非在文件 id，tid 和 fileids 非对应关系组合这些角度来测试