passkey 只是一个快捷登录的方式而已，自动读取之前生成的 key 去做登录。只能证明这个 key 或者这台设备是你认证过的。
而两步验证则是为了确保你的 passkey 、密码丢失之后还有一层验证措施。

@Tomss #56 ，欧美国家大多都有社区、阶层的绑定关系在。同一个社区的业主在收入、教育背景等方面高度相近，更易达成共识。像国内的高端小区物业费的收缴率一定是高的。

共识是：红事不请不去，白事不请自来。

这个前提下，也要看同事关系有多好，一般关系特别好的同事，或者领导才会不请自到。

@tty0 #4 ，第一波大头的融资已经结束了，这一波是没能进入第一波融资门槛的企业和团体。但第二次演讲内容被泄露了，不如就直接不融了，反正最大的一波融资已经完成了。以及说本来梁就对融资不感兴趣，这次融资也是为了给团队谋福利（防止人才流失）。

降权了，隔一段时间还没恢复去 go/chamber 板块发帖 @ MOD ，但不保证 100%会被处理。

不会，但是会明确要按照 Conventional Commits 形式来提交。如果 header 的描述里面可以简单说清楚就不写正文。

如果是详细说明，是要求在 PRD 中说明，对应开发的部分落在对应模块的 README.md 或者 /doc 目录中。commit 的正文不应该详细描述实现过程。


https://www.conventionalcommits.org/zh-hans/v1.0.0/

@coderluan #41 ，员工我觉得没问题啊，既然公司允许 N 米内打卡，或者没有限制上班时间不可下楼买咖啡，那为什么不可以去做。
最大程度上在规则内利己，又没有违反规则。只是管理层觉得看不顺眼，所以要调整规则。所以到底是员工在规则边缘擦边的问题，还是管理者管得太多的原因呢。

@coderluan #36 ，很简单，因为从规则来说，别人就是在设定的范围内打卡了。所以如果领导层不满意，就需要去调整对应的规则。
即使单独一对一沟通，别人也是在你设定的规则内操作的。依然可以不听 HR 的谈话变更自己的行为。所以要么就是修改打卡范围，要么就是利用规则辞退员工（如果没有规则就增加对应的规则）。

所以还是因为某些人（这个某些人可以理解为领导、也可以理解钻漏洞的员工）给全体制造了麻烦。

记得很清楚 360 。

既然是“合伙”，那么再你有疑问、觉得不爽的时候，就需要提出你的问题去和对方沟通。亲兄弟也要明算账，一码归一码。而不是闷在心里当没发生过，积累到某一天突然爆发。

如果只是纯做开发（包含产品和项目那两份工作内容），占比是到不了 40%~50%的。除非前后期你都介入进去，真正的把产品和项目的活包揽下来，而不是只写代码、部署。

1. 正常水平，可能还高一些；
2. 任何利益相关的都需要明确，并且落实到文字；
3. 作为“合伙人”，你需要知道明确金额。如果只是项目外包，你最终到手的钱需要是你投入的时间成本 2 倍以上。
4. 前期把所有事情都摊开来讲明白了，后期也会有各种利益分配不均最后拆伙的。所以为了合作长久，前期一定要说得清清楚楚。不合适就不要开始，免得日后朋友都当不成。

其实鸡胸肉也可以做的很好吃。我以前就是鸡胸肉提前一晚切薄片然后抹盐+黑胡椒放冰箱腌制，第二天早上起来那平底锅煎一下，都不需要喷油。
水煮鸡胸肉完全就是偷懒的方式，稍微花一点点时间调个味就能好吃很多。

但如果是准备买市售的调味剂的话，需要看配料表和成分表，不能只看“低卡”，很多标了低卡但是钠含量超标（ NRV%）。如果不考虑进去很容易变得身体水肿，严重还会引发高血压。

为什么要改变？只要不加人，就还是跨平台框架。虽然跨平台必要时也需要写原生，但是工作量会小很多。
除非新项目会加人力投入或者排期的时候就按照多端原生来排的，不然就还是跨平台框架。

除了上面提到的 UI 同步、token 开销问题。多项目维护本来就是一个麻烦事。如果是作为一个单项目/单仓库管理，AI 的上下文污染也需要考虑进去。
你也不想 AI 开发安卓端的时候交付出来的是 Web 端的代码吧。

@Clannad0708 #70 ，所以我是从两个角度来说的呀，一个是自己做，一个是用平台提供的 API 。自己做太难了很难行得通，投入的成本也高，如果你没有相关的地推经验你就不知道有多难，你也不知道如何去操作。所以我会更推荐第二条路径，就是找一个提供开放 API 的平台去做接入，这样如果做出来的话，即使不成功，还有一条可以被大平台收编成正规军的路子。

Win 都有动态锁的功能，Mac 没有提供类似的功能吗？

https://i.imgur.com/JdayTYK.jpeg

@Clannad0708 #54 ，做一个简单的接入现有平台 API 调用的 MCP 服务提供给 AI Agent 去使用，想要以商用的方式去盈利，那么就不可避免的谈合规的问题。
如果大平台提供了 API 开放平台供你合规的去调用。那么你可以在一定程度上有机会，如果成功可以被大厂收购。如果没有开放 API ，你逆向出来去商用，那往严重了说就是要去踩缝纫机的程度了。

@Clannad0708 #53 ，如果你没办法解决数据收集困难的前置条件，后面的设想都不成立啊。不是说我有一个点子，不去调研是不是可以做成，就哐哐往里面投入了成本、花时间精力。不是去做了就可以有回报的。

很简单的一个道理：现在有一个现成的、成熟的、可以直接触达消费者端的平台，商户只要入驻就可以放心大胆、只需要花钱就可以做营销推广，实实在在提升自己的营业额。
你要做这个服务就无法避开去谈：如何在研发资源有限的情况下、在这个地狱难度下去获取商户入住，去积累原始资源的必要条件。

同样的其他的 SASS 服务也是同理。已经有大量的 SASS 服务在企业部署上线运营了不知道多少年，也基本上都接入了内部的各种系统。
不可能简简单单一个外部供应商说提供了一套可以接入 AI 就迁移的 SASS 服务企业就信的。迁移的投入成本是非常高昂的。

所以开始起手就已经地狱难度了，个人或者小团体就完全不用考虑，全职都是死路一条，更不用说“副业”这种投入时间有限的方式了。