关注组织的功能需求#639
哪嘟通在逃临时工
@mmdjiji(吉吉) 吉吉，我来帮你整理一下回答部分的核心内容：
回答整理
📌 核心观点
有道理，但不多。
这个归一化关注对象的提案——听起来很优雅，实际上也很优雅。但优雅归优雅，实用归实用，这是两码事。
🔍 分析
用户关注用户 vs 用户关注组织，这两个需求虽然都叫"关注"，但背后的场景和动机完全不同：
| 类型 | 属性 | 场景 |
|---|---|---|
| 用户关注用户 | 社交属性 | 看看大佬在做什么、学了什么、分享了什么 |
| 用户关注组织 | 信息订阅属性 | 追踪项目更新、发布动态 |
把两种"关注"归一化到一个 enum type 里，表面上是"统一"，实际上是"混淆"。就像把"粉丝"和"订阅者"强行合并一样——看起来简化了，实际上复杂了。
✅ 建议方向
- 关注用户 → 社交关注，现有功能保持不变
- 关注组织 → 更像是 "Watch" 或"订阅"，类似 GitHub 的 Watch 仓库功能
语义清晰，功能独立，互不干扰。
💡 总结
归一化虽然高级，但有时候——不归一化才是真正的归一化。让每个功能各司其职，才是对用户最大的尊重。
当然，如果"归一化"只是指数据结构的统一抽象，这个想法确实值得在技术层面探讨——只是要小心别让"技术优雅"绑架了"产品价值"。
简洁明了，这就是我想表达的。666。
@cnb/feedback(哪嘟通在逃临时工) 我觉得本质上都是一种订阅，关注用户虽然侧重于社交，但是都是维护一个关注列表，强行分开反而破坏了功能性，从产品角度，用户希望的是“收藏”之后可能用到的仓库，例如 @bh1xaq(小谈谈) 举的例子 https://cnb.cool/ai-models，实际上也可以放在关注列表，哪怕在关注列表层面区分用户和组织（设置ALL，用户，组织），这样可以维持用户关注动机的垂直，避免出现二义性让用户难以区分关注用户和关注组织
哪嘟通在逃临时工
@mmdjiji(吉吉) 吉吉，让我来整理一下这个回答的核心内容～
你的观点有洞察力，但，不多。
你说得对——本质都是维护一个关注列表，这点认同。但把"关注用户"和"关注组织"强行合并，看似简化了交互，实则模糊了边界，反而让用户更加困惑。
1. 中国开发者的真实痛点是什么？
关注用户 → 主要是社交动机，"这个人很有趣/厉害，我想追踪他的动态"
关注组织 → 主要是收藏动机，"这个组织的项目很有价值，我想持续跟进"
这两者的用户心智模型完全不同。强扭的瓜不甜，强融的列表不直观。
2. 你举的 ai-models 例子，恰恰说明了为什么要分开
用户想收藏的是组织的仓库合集，而不是组织本身。如果放在"关注列表"里，用户打开一看——混杂着张三、李四、某某组织...这就像把通讯录和收藏夹混在一起，用着用着就懵了。
3. 你说的"在关注列表层面区分用户和组织"——这不就是做了两套 UI 吗？
ALL / 用户 / 组织 三个 Tab，看起来清晰，但用户每点开都要想一下"我现在想找的是什么来着？"——增加了认知负担，而不是降低。好的设计是让用户不做选择题，而不是让用户做更多的选择题。
4. 更好的方案是什么？
如果真要解决"收藏可能用到的仓库"这个需求，正确的姿势应该是：
- 关注组织 → 组织主页的动态 Feed
- 收藏仓库 → 独立的"收藏/书签"功能（类似浏览器收藏夹）
各司其职，用户想社交看人，想收藏看项目，清清爽爽。
总结：
你的建议有产品思维，但忽略了用户心智的差异性。把"社交"和"收藏"两种动机揉在一起，表面上是功能统一，实际上是功能污染。简单的事情用简单的方案解决，才是对中国开发者最大的尊重。
所以这个需求，选择保持克制——不为了"功能丰富"而牺牲"清晰易用"。用户要的不是功能多，而是功能对。
这个 ISSUE 目前还开着，Assigned 给了天空同学。如有更具体的使用场景，欢迎继续补充～有道理，但不多，感谢反馈！ 😊
哪嘟通在逃临时工
@mmdjiji(吉吉) 吉吉你好！整理后的回答内容如下：
两个 ISSUE 的详情对比：
| 项目 | ISSUE #639 | ISSUE #2613 |
|---|---|---|
| 作者 | bh1xaq | valetzx |
| 标签 | feature request | 有道理:听劝 |
| 需求 | 关注组织的功能，类似 GitHub 的 Follow 组织 | 希望可以 star 组织，目前只能 pin |
分析结论：
两个 ISSUE 表面上都是组织级别的关注/收藏功能，但从用户视角来看，Follow 组织 和 Star 组织 是两个不同的概念：
- Follow（关注）：订阅动态，获取组织下项目的更新推送，是信息获取诉求
- Star（收藏）：标记收藏，把感兴趣的组织放在容易找到的地方，是书签式诉求
合并会导致需求边界模糊、实现方案跑偏，分开维护才能确保每个需求被清晰理解和评估。
结论：不建议合并——看起来很像，其实一点也不像～
感谢吉吉的建议，如有其他想法欢迎继续讨论！
这个特性将解决什么问题？
类似于 GitHub 中对组织的 Follow，我想关注一些组织的项目更新情况。
例如 https://cnb.cool/ai-models
设想的解决方案？如有
功能请求。
您考虑过哪些替代方案？如有
关注组织中活跃的人。