就是说你的造数脚本都需要用户自己提供到平台上，业务逻辑一变这些脚本就需要跟着变，人家用自己的脚本用的好好的，甚至在 CLI 里面更快捷，为什么要用你的平台，搁我我也不愿意用啊……
所以看起来你没有增值服务或者太少，比如

• 帮用户搞定了用户、权限接入问题从而减少了他们的重复性配置工作
• 提供了各种格式的数据结果导出格式
• 提供了用户使用习惯的分析，哪些是高频的、哪些是不常变的、哪些耗时比较长的，等等等等
• 适配对接用户造数之后的目标使用场景，比如测试平台、框架，提供一键对接灌入等
• 提供按照用户原有脚本可运行的容器，让用户直接平移而不需要重新开发，或者一键迁移等功能
• 你们自己的业务自己清楚，多找一下用户的痒点……

另外，找机会访谈一下用户，让他们象征性给点建议，汇报的时候把功劳分摊到用户头上，跟大大大 BOSS 汇报或者写邮件的时候就说 “在 XXX 的帮助下”，鸣谢一下，把他们绑到你的战车上，这是另一方面的小技巧。

只要社区能保证其他用户不会通过社区绑定的微信信息找到我，我就举爪

https://www.cnblogs.com/rexcheny/p/9498091.html

自己创业吧

仅楼主可见

想造反闹革命的永远是最底层的穷苦百姓，士绅都知道自己要努力维持或增加自己的财富和实力，不参和那些杀头的营生。

找好下家了吗，找好了马上就走，干吗要答应晚点走？

思路是对的，只要能干好，都是共赢，非要攀比只有不开心
我前几年还会打听别人的薪水和奖金，现在已经完全不关心了，只关心自己干这个活值不值这个价，后面怎么发展这样

上进也分档次，我说的仅限于把代码搞漂亮点，也并不是炫技，至少不通过加 if else 来实现新的业务逻辑也是一种上进的表现，至于觉悟能不能更进一步，自测通过再提测，这就要再提点提点或者通过流程来帮着提升了……我本人还停留在前一种，虽不耻于堆代码屎山，但是自测这一点上的确不值得骄傲……经常被测试妹子耳提面命

场景二里面有其他情况，我以前合作的开发经常出现。
1、开发主要精力在处置较为麻烦的问题，比如缓存、性能等，解决之后对业务基本逻辑出现主观偏差，觉得 “哎呀真爽啊，完事”，造成低级问题产生。
2、不屈从于垃圾代码，为兼容当前的业务逻辑，花了额外的功夫做优秀的设计或者对遗留代码做了重构，这种情况也很容易出现低级问题。

除了大家说的流程上的处理手段，我觉得还是要试着去理解一下深层次的原因，逻辑简单，CRUD 不犯低级错误的开发也不见得就是多么出色的开发，因为这些人坑一般挖的比较深；经常犯低级错误的人反而也可能是技术比较好、比较上进的人，只是方法未必到位而已。这样跟开发合作，相互知根知底，了解对方容易出错的习惯，效率一定不会差的——测试和开发的合作也是一个相互培养的过程，俗称磨合。