程序是死的，程序设计是活的。

【用例】
有个技能叫火球术，有个天赋A可以让火球术击中时附加Buff，有个天赋B可以让火球术击中时附带击退效果。

【设计方案一】
只学习天赋A时，将火球术替换为技能A；
只学习天赋B时，将其替换为技能B；
AB天赋都学时，将火球术替换为技能C。
优点：不需要任何新增的数据模型，现有代码直接就能用；代码理解成本低，因为只是替换技能。
缺点：当多个天赋影响同一个技能时，一个技能就要配置CDEFGH技能。

【设计方案二】
新设计一种数据模型，用于描述技能局部的修改。
优点：无论学习几个天赋，火球术都依然是它本身。
缺点：这个数据模型定义起来很麻烦，比如动作游戏里要改变第N帧的击退力度。

【决策】
如果项目只会有一个天赋影响一个技能，或者项目特别赶时间出原型，方案一就合理。
否则方案二更合理。

今日消除焦虑：
那些天天嚷嚷着啥也不学白手就能写个系统的
都是臭卖课的
他们自己都写不出个功能

#自媒体运营频道 #@yunying23

我不一样，来金山，我真请你喝咖啡

【不会写代码但用cursor做好了第五个应用】
目标仍然是要多利用AI为姐妹们做出好用的工具/应用!👩‍🎨

第二个小程序获得了一千多个小姐妹的喜欢，大成功🏅第三个马上也要来啦˗ˋˏ( ´͈ ᗜ `͈ )ˎˊ˗，这个小程序的质感经过多番的调试，感觉效果和预期一样，浅浅期待一下上线吧💥

分享一些小程序需求来源的感悟💡
🧩把小红书当作一个巨大的需求池，关注姐妹们在关注在分享的东西，深挖一下可能就是姐妹们背后的需求。
🧩把大应用的某个小功能单独拎出来做成一个小程序（我目前对小程序的理解是：为用户提供小而美的东西），大应用都做了这个功能，说明这个需求大概率是真的，所以如果能够把某个小功能做成一个比较不错的小程序，应该还比较可行。
🧩要做自己也会用的东西（既是用户也是产品经理），如果自己都不是这个应用的受众群体，很难把它做好，即使是第一个版本。
🧩需求对应的功能不要搞得太复杂，最好简单几步就能解决用户的需求，毕竟这只是个小程序还是初始版。

第一次以工程师的身份开发App，第一次了解什么是Swift。家里的小朋友想实现一个小功能半途而废之后，我捡了起来，用Cursor三小时出了一个最小可用，然后每天业余时间玩一玩磨一磨，逐渐转战到windsurf，被迫学了git 和debug以及xcode的各种隐藏设置，这两天被storeKit折磨到不行（相比于功能和界面，它太抽象了），终于今天提交了😁 祝我过审吧，届时抽码

我们的bot透露着一种冷幽默。
（第一个发言的是bot）