@yueji #16 这几个人要是主张补缴社保，你必须要补缴。当然同时也会追缴员工应缴的部分。

如果是劳动者签订或者说明了不缴纳社保，只是劳动者不能以不缴社保为由被迫解除了，用人单位缴纳社保的法定义务并不因此消除。

@yueji #13 要看入职之日和提出离职的时间是不是超过 1 年了。

让你媳妇儿保存好这几个人入职、安排工作的相关记录，最重要的是工资支付记录（如果有社保或者公积金就更好证明了）。
如果上述记录（尤其是工资支付记录）超过了 1 年，请务必主张双方已经视同签订了无固定期限的劳动合同，不认可是未签两倍的场景，就是协商一致解除。

可以考虑一下 5#的说法。

想办法主张这几个人已经自用工之日起距离离职超过 1 年了（需要有聊天记录、支付记录来证明），本质上是视同签订了无固定期限的劳动合同，然后走的是劳动者发起的解除，无需赔偿，

遇到一个大厂的系统，在登录密码错误的情况下会提示：
密码错误，正确的密码是：xxxxx

---------
后面反馈后说是把 debug 用的开关错误地打开了

说一下我的用车情况，同在上海，赶上了混动绿牌，市内没有用于日常通勤。
- 买了 1 年 3 个月，行驶里程 1.7w （ ev 1.2w ）
- 油电费：4k ，商桩为主（平均电价 1.1 ）
- 高速费：5k （有过较长时间的沪杭每周通勤）
- 保险：5k*2
- 小区停车费：400*15 = 6k
- 其他停车费（毛估）：1k
- 保养：0 （只做了首保）
- 违章：0

暂时看下来花费 26k ，平均下来每个月会产生 1.5k 的额外支出，你可以看看自己能扛得住不？

给个绿泡泡联系一下？

支持一个

我是属于那种会写几万字 PRD 的产品，但我也会画基本可以直接交付给前端的高保证原型。之所以会这样，主要是：
- 我是 ToB 的平台产品，有很多产品逻辑是需要大量文字或非原型的其他图来描述的（比如状态转换、异常分支、实体关系等这类信息处理逻辑等），这部分用原型图没有办法完整体现，到最后还是要看文档/图才行。
- 我认为原型（或者叫做交互稿）是 PRD 在用户侧的最终体现，原型可以帮助产品经理理清设计思路，用更直接的方式和相关研发、运营同学对焦产品逻辑，在产品设计的相关资料中是很重要的存在。除非没有用户交互的逻辑，否则我也都会画好对应的设计稿。

楼主遇到的产品我觉得最大问题可能还不在于没有图的几万字 PRD ，可能更头疼的是表达过于啰嗦和混乱。没有办法能让合作方迅速理解思路，要靠不断的问询、猜想才能逐步摸清细节。

试着和这个产品表达：
- 你的 PRD 不够有序和精简，需要研发同学二次抽象反而会引起信息传播的偏差；
- 要有图，无论是什么样的图，重点是在总结逻辑，帮助大家快速理解你的需求和思路；
- 没有图实现成什么样我不管我不改，你自己负责 hhhh

拼多多啊，我只能说，尊重，祝福。希望离职时不会后悔入职。