我跟 ChatGPT 脑暴了一晚上，包括几种治理模型和用户体验复杂度，下面是 o1 Pro 的产品方案，欢迎大家讨论：
以下是一份名为 FairSharing 的产品介绍与说明，结合了前面讨论的多种激励与审核模式，包括小型审核团、中心化辅助、timesheet 记录、以及最终的 retro funding 分配等，旨在提供一个更简洁可行、体验友好、又有一定去中心化特性的协作与收益分配系统。
在 DAO 或任何需要多人协作的环境中，如何实现“多劳多得、贡献可追溯、收益公平分配”一直是痛点：
纯去中心化投票 过于复杂：所有贡献都要提案投票，用户体验差且执行效率低。传统中心化管理 不够透明：容易出现暗箱操作，无法让参与者充分信任。贡献多元、难以衡量 ：金钱出资、时间投入、内容产出、技术支持等贡献形式各异，量化复杂。持续激励问题 ：老贡献者的历史贡献需要得到回报，但新贡献者也要有足够动力继续投入。
FairSharing 旨在在保持一定公平、透明的基础上，简化日常管理流程，通过“轻量化登记 + 小型审核团确认 + retro funding 分配 ”的混合模式，打造高效、便捷 的协作激励体系。
贡献提交（中心化登记）
提供一个简单的前端界面，让用户可以自助上传贡献信息、证明链接（例如 GitHub PR、文档、设计稿）或 timesheet（工作时间表）。
不需每次都上链，先缓存在中心化服务或数据库中，后续再进行统一审核和发放。
小型审核团评审
由一组被社区/团队认可的审核人（2~5 人或更多）对提交的贡献进行快速筛查，确保无明显欺诈或造假。
只有审核团通过的贡献，才能进入正式贡献池 ，具备后续获取激励的资格。
审核可结合简单投票、任务对照或基础质量评估，不需要全员参与。
timesheet 机制（可选）
对部分按时薪或按工时计费的任务，用户可以直接提交个人的工作时长记录。
审核人只需核对任务进度与大致合理性，通过后即可记录为“有效工时”。
Retro Funding 分配
在周期性（如每月/每季度）或项目完成时，将所有已审核通过的贡献列出，结合实际产出或项目成果，由社区进行投票或由审核团再次给出评级。
根据评估结果、贡献规模以及可用的资金池，执行一次批量的资金分配。
可以采用retro 理念：实际给贡献者多少奖励，与贡献对最终成果的影响力正相关。
角色管理与激励
贡献者 ：提交贡献并获取相应回报。审核团 ：快速验证贡献真实性、过滤明显违规行为。社区投票者（可选） ：在最终 retro funding 时，对贡献价值进行评价或确认整体分配方案。管理员 / 合约执行 ：协助处理资金池、执行最终分配交易，或由合约自动按照投票结果分发。
场景 1 ：DAO 成员 Alice 在一个月内编写了多篇文档并进行翻译工作。她每天记录自己所花费的时间和成果文件（timesheet + 具体链接），提交到 FairSharing 的“贡献提交”模块。场景 2 ：Bob 出资赞助项目服务器费用、或为项目提供了短期的技术支持，也可以提交自己的发票或简要说明，等待审核团确认后进入贡献列表。场景 3 ：季度末，社区有一个公共奖金池。所有已被审核团通过的贡献会被展示在 DApp 界面，供社区查看、投票或打分。结合投票结果/retro funding 权重，智能合约自动计算每位贡献者应得收益，并打入他们的钱包。场景 4 ：对于持续工作性质（如运营、维护），贡献者每周提交 timesheet 并有小型审核人审核确认。到了月末，系统统一进行 “时薪 × 通过的工时” 的计算并发放薪酬。
下面展示一个典型的 FairSharing 流程 ：
贡献登记
贡献者（Alice）登录 FairSharing 平台，填写贡献信息（标题、类别、时间、可选的时薪或期望积分、外部链接等）。
这些数据先存入中心化数据库，等待审核。
审核团审查
小型审核团在后台查看新提交的贡献，评估其真实性、质量或工时合理性。
若合格，则将该贡献标记为“已通过 ”，写入链上或管理数据库的“正式贡献池 ”；若存疑，则可能与贡献者沟通或标记“待修改 ”；若是明显垃圾信息则“拒绝 ”处理。
周期性结算
根据系统设置的周期（如月底），系统将所有“已通过”的贡献罗列出来，显示在一个“待分配”页面。
如果采用 retro funding，社区或审核团会对贡献价值进行投票/打分：如质量、影响力、时间投入等，形成一份加权评分。
资金分配
FairSharing 根据评分结果与预设分配算法，计算每个人应得的奖励份额。
由管理员/多签/智能合约一次性完成资金转账，或记录到贡献者的“待领取”余额中，让其自行提取。
整个过程透明可查，贡献者可以从前端查看分配权重及最终到账金额。
后续留存
所有被通过的贡献都在系统里保留档案（链上或数据库），历史贡献者可随时翻阅，也能展示在个人资料页作为“履历证明”。
Alice 提交
Alice 写好一篇操作手册，花费 5 小时完成，把文档上传到 GitHub，并在 FairSharing 的“贡献提交”界面填写：
标题：“新手操作手册 第1版”
工作时长：5 小时
链接：GitHub PR 的 URL
点击提交后，系统后台保存了这条登记。
审核
小型审核团的 3 位成员（Bob、Charlie、Diana）在后台收到提示，看见 Alice 的提交信息。
他们查看 GitHub PR，确认确实是 Alice 提交，文档质量尚可。
审核通过后，状态从“待审核”更新为“已通过”，系统记录“文档贡献 5小时”。
月底统一分配
到本月月底，FairSharing 收到社区资金池 1000 USDT 作为“贡献奖励”。
平台列出本月所有已通过贡献，包括 Alice 的文档 5 小时贡献等。
社区或审核团可对各项贡献评分，比如大家认为 Alice 的文档质量不错，打分 8/10；其他贡献也有不同得分。系统根据时长和评分进行加权，计算得出 Alice 最终分配比率约占本月资金池的 15%。
Alice 因此获得 150 USDT 的奖励，并由系统或管理员多签一键发放到 Alice 钱包地址。
贡献者
提交贡献的人，填写基本信息、上传证明材料或 timesheet。
在被审核通过后，有资格领取相应的回报。
审核团
小规模的可信群体或委员会，负责初步把关贡献真实性与合理性，减少不必要的垃圾提案进入最终投票环节。
可能由创始团队、早期核心成员或社区投票选出，定期轮换。
社区/全体投票者（可选）
在 retro funding 或最终分配环节，对每项贡献进行评分或按贡献优先级投票。
若规模大，也可以由审核团或另一个较小的“治理委员会”给出建议分配方案，全体只投一次“通过 / 否决”。
管理员 / 合约执行
协调资金池注入和智能合约的执行（或由多签完成）。
管理前端后台系统，维护贡献登记与审核流程的正常运行。
简单易用，操作门槛低 ：
贡献提交无需频繁链上交互，减少了对钱包签名和高额 gas 费的依赖；
只在关键环节（审核通过、投票、领取资金）才需要更正式的确认。
可扩展的审核机制 ：
小型审核团保证了基础过滤与质量把关，不需要全员投票，能大大提升效率 ；
审核结果仍可公开透明，若出现争议，社区可以发起挑战或重新投票。
Retro Funding 的灵活性 ：
允许在项目阶段性成功后再评估贡献价值，激励真正对成果有用的行为；
与时薪或计件等模式相结合，满足不同类型任务需求。
部分去中心化，兼顾效率与公平 ：
核心结算与最终资金分配可上链，实现公开可追溯；
日常的贡献登记与审核通过中心化或半中心化的方式进行，简化流程、提升用户体验。
适用多场景 ：
适合中小型 DAO、Web3 项目团队、开源社区、有外包合作需求的组织等。
FairSharing 以“轻量贡献登记 + 审核过滤 + retro funding ”的混合机制，避免了纯去中心化投票的高操作成本和纯中心化管理的不透明，力求在公平 与易用 之间取得平衡。它可以帮助各类分布式团队更高效地记录贡献、激励积极性、并在一定程度上保证资金分配的合理与透明。借助此系统，任何人都能多劳多得 ，让努力在社区中被看见并得到真正的回报，达成可持续的协作和共赢。
3 Likes
rayjun
February 21, 2025, 2:14pm
3
非常好的提议，fs 在经过了这段时间在 LXDAO 内的使用之后，我们可以明确 FS 的核心功能就是 记录 + 分配。
而当前的 FS 在产品形态有所偏离，主要体现在以下方面：
功能上太过于复杂，比如 PoC 投票机制、Create Payment 等等
对于 EAS 的设想太过于理想，增加了产品的复杂度，在当前的 Layer2 的 gas 水平下，其实可以不需要这样一个链下的模块
pizza 的概念过于复杂，还额外增加了 claim 的流程
所以在下个版本的 FS 开发中，可以将产品形态内聚一下，将产品分为应用前端和链上合约两部分，链下主要通过数据库来存储未上链的数据，也就是 Bruce 上面说的 mempool，然后链上保存上所有已经确认的数据，包括 poc 记录和激励池等数据，当然为了前端应用的使用体验，需要在链下 index 链上的数据，以便实现开放平台、各类 dashbord 功能，链下的这些数据完全可以依赖链上的数据来恢复。
3 Likes
rayjun
February 22, 2025, 2:33am
4
在整个过程中，只有记录和分配这两个部分是必要的，中间的审核环节可以更灵活，举个例子来说，对于一个小组来说：
可以将所有的人都设置为投票人，每条记录只要有一票就可以上链
还可以只设置三个人作为投票人，每条记录需要有两票才能上链
还可以不设置投票人，只要登记了就能上链
一个项目组的 member 和 voter 都需要上链，这个规则可以灵活设置，按照各个组和项目自身的情况来。
2 Likes
rayjun:
可以将所有的人都设置为投票人，每条记录只要有一票就可以上链
还可以只设置三个人作为投票人，每条记录需要有两票才能上链
还可以不设置投票人，只要登记了就能上链
我觉得可以提供两种模式，一种就是全投票人模型，最去中心化，但是投票最繁琐，类似目前的模式，需要自行添加 member 等。第二种就是监督者模式，设置几个可信的 validator，由 validator （2-3 人或者更多，奇数）进行 review 和投票表决，从 mempool 里面挑选不错的。
只要登记就上链，这个就算了，感觉跟 Notion 一样了，大家随意乱提交的话，就没有意义了。
TL;NR
现在 weekly 的记录形式需要用户“有能力”在每周结束时回溯，也就是说很可能 ta 还需要使用其他工具进行日常记录，或每周估算一下。如果能够改进成为“每次干完立刻记录”，应该会提升体验，并且有助于养成记录的习惯（那后续 FS 可能就成效率工具了 lol）。甚至可以是 chrome 插件
记录条目 item 化，而不是用文本框
已记录数据的更多潜力 - 例如反映组织/项目/工作组在每个周期的时间开销重心，和目标计划 realign；或贡献者了解自身的 dashboard
提升社区互动的可能 - 在 retro funding 投票时不只是进行权重分配投票，也可以互相评价 （somehow like social layer）
从一个贡献者的角度来说，过去半年使用 FS 最多的功能就是“记录”。如果说记录也是 FS 最核心的功能之一，那确实可以考虑如何提供更好的记录体验。
现在的形式：
连接钱包
选择一个已被添加的项目或 WG
在文本框内填写贡献以及时长
选择贡献类型
添加 Proof （链接或附件）
选择日期或日期范围
选择贡献者
自行计算 token
提交并签名
Approve 并签名
遇到或观察到的问题：
贡献者需要先通过钱包地址，被管理员添加至项目或 WG，才能上传贡献记录
记录贡献内容的文本框灵活度太高，从贡献者的角度不方便填写，管理者的角度不方便统计。
以 LXDAO 为例，24 年秋天时大家记录的方法都不一样，有的贡献者可能每周提交多条贡献记录。后来在站会上统一成每人每周提交一条记录，在记录中换行并标明每条贡献的时长。
猜测这个转变的原因是便于管理者进行统计和分配。然而，从贡献者的角度来说，这样的记录方法需要自身使用其他工具记录每天的贡献与时长，才能在周末进行汇总（或者周末大致估算一下）；相对的则是将 FS 直接作为每日贡献记录工具，例如在当日完成工作后，就打开记录一下。个人认为后者的记录体验会更好，也能培养良好的记录习惯，但在系统设计上可能就需要以表格或标签的形式进行管理，方便后续数据统计。即使是一次记录多条，如果采用 item 而非一个文本框统计全部的形式，可能也会更便捷。
其他的还有比如需要自己做加法统计总时长；有一些高频出现的贡献项目是否可以保存为 item，不用每周重复打字输入等。
贡献类型不知道选哪个，选了的作用也不是很清楚
日期会填错或忘记修改 - 这可能与当前 FS 是回溯性记录有关
之前不知道为什么每次还需要选择我自己作为贡献者，直到看到有代他人填写的记录出现。如果这个是必要的，或许可以 by default 是自己，就不需要每次查找再选择了。
自行计算 token 的时候有时忘记 unit - 新版 FS 似乎不再会有这个问题
提交签名时，如果没开全局 VPN，有时候会无法弹出签名窗口（不止一次看到有人问） - 新版 FS 提交记录如果是链下的，应该也不会有这个问题
一开始不知道自己需要 approve，导致有的贡献没有被记录在分配中
其他问题和想法：
新版 FS 提出 retro funding 的方法对部分项目进行贡献分配。那么在贡献记录和统计的时候，是否需要考虑该层面的分类？例如，是 Forge 组内所有贡献一起进行 retro funding 投票，还是 by sub groups 进行投票？如果是后者，该怎么进行分类管理？
上面 Ray 和 Bruce 都提到，新版 FS 的核心是“记录+分配”。我在想，既然已经记录了，是不是可以通过 database 管理让这个记录产生更多信息。例如，通过标签管理或者 LLM，周期性地对所有贡献进行分析，或许可以反映该周期的工作重心之类的；又或者从个人贡献者角度，可以看到过往贡献的词云 or dashboard or heatmap，我会觉得还蛮有意义的。
如果有社区投票，那是不是也可以有社区 tag，比如在给贡献打分的同时，给对方写评价，然后这个评价是会被留存下来的（或许是只能写积极评价 lol）
1 Like
From @charlotte
我主要是从用户体验出发，想到的几个核心点：
Marcus
February 25, 2025, 9:47am
8
投票机制：大部分人对于他人的贡献漠不关心，且不愿投票
FS Token 效用：没有什么用处，它仅作为一个统计的积分
登记的流程繁琐：大部分人提交贡献的格式不一，且内容过泛，耗费的时间过长
重复性的工作反复登记：针对一些重复性的工作，反复登记
用户体验: 贡献登记网络问题，Claim 流程繁琐
自主登记 vs. Milestone 解锁 ：
自主登记模式 ：这个模式比较灵活，可以更好地适应不同用户的贡献情况，但也可能带来信息不对称或滥用问题。为了优化这个流程，建议在登记时加入一定的 自动化审核 或 机器学习辅助 （例如自动检测提交内容的质量或相关性），以减少人为审核的压力。Milestone 解锁模式 ：引入审核员和阶段性解锁的方式确实能提升精准性，但会带来审查员的数量问题和审核成本。你可以考虑以下几种方式来优化：
分阶段的自动审核 ：结合自动化工具，利用 AI 对贡献进行初步筛查（比如，通过内容分析判断贡献的合理性），再由人工审核员进行最终确认。灵活的审核机制 ：给审核员提供清晰的审核标准，并能根据社区反馈对标准进行动态调整，这样可以避免过于死板的审核流程。
与现有平台的差异化 ：
对比 dework 和 krama 的审核流程，它们大多是基于任务列表和完成度进行审核，缺少一个实时的、互动式的贡献确认机制。FairSharing 可以引入 即时反馈 系统，当用户提交贡献时，系统可以提供实时确认或自动化的初步验证（例如，通过检查任务是否按预定要求完成）。
与传统系统不同，FairSharing 可以通过引入 社区投票 或 同行评审 等元素来补充审核机制，这样贡献的确认不仅依赖单一审核员，也能借助群体智慧提升公平性。
贡献比例和资金分配 ：
自动化资金分配 ：根据贡献的量化指标（如任务的复杂度、时间投入等），自动计算并分配资金，而不是依赖人工操作。可以设计一个 贡献评分系统 ，每个任务根据设定标准获得一定的分数，最终资金按贡献分数比例发放。灵活的分配机制 ：为应对不同场景，可以设置多个分配模式。例如，针对某些关键任务，采用 加权分配 （即重要任务的贡献更高，奖励更多）；而对于日常性、重复性的任务，采用 平衡分配 （奖励平均分配）。
分配透明度 ：
提供 可视化数据 ，让用户清楚知道资金分配的依据。例如，用户可以查看自己贡献的具体价值、得票数以及分配的资金比例，增加系统的透明度和可信度。
资金池动态调整 ：根据社区的参与情况动态调整资金池。例如，当社区贡献较高时，资金池可以适度增加，以鼓励更多的参与者。
奖励激励机制 ：
层级奖励 ：根据贡献的质量和数量，设定不同层次的奖励。例如，对于完成高质量贡献的用户，给予更高的资金或特殊奖励；对于初次参与或小规模贡献的用户，给予基本奖励，逐步提升其参与感。“披萨”游戏化机制 ：这个概念很好！可以通过 “披萨分块” 来增加参与感和成就感。例如，用户每完成一项贡献，系统就会为其分配一块披萨，当所有贡献者的披萨块加起来构成一个完整的大披萨时，代表所有人的贡献达成了共识，整个资金池分配完成。
工作组的展示过于简单 工作组的信息展示， Milestone 目标，人员资金分配情况，甚至于说一些需要的人员招募需求，接受 Grants 状态 等等
研究一下最近的竞品更新，CharmVerse，Coordinape，Krama 的动态，看看有什么比较好的想法可以改善 FS 的
我最初的设计和期待肯定不是 Weekly 的方式，但是由于体验和统计方面的问题，导致最后变成了这种。所以我们要在用户体验极大的提升，然后解决这个问题。
Dashboard 可以有，但是我们在第一阶段，更关注底层的功能和体验，可能很难对具体使用方的业务引导什么。
这个可能是很后面了，retro funding 并不在 FairSharing 里面，当然也可以作为分配模式的一种扩展。但是目前可以通过 Dashboard 展示，然后作为依据提供给另外的系统进行 retro funding 投票打分，相互组合。
charlotte:
现在的形式：
连接钱包
选择一个已被添加的项目或 WG
在文本框内填写贡献以及时长
选择贡献类型
添加 Proof （链接或附件）
选择日期或日期范围
选择贡献者
自行计算 token
提交并签名
Approve 并签名
新的我想象中的形式：
连接钱包（一直保持链接）
选择一个已被添加的项目或 WG（或者直接收藏这个页面）
简化模式登记贡献，一个 input，可以通过 # @ ~ 等命令设置 tag、贡献时长等，一条编辑即可实现，例如：Weekly meeting #meeting ~1h > proof link 会变成 meeting 分类，花费 1 小时，内容是 Weekly meeting，然后 proof 是什么，默认是今天然后你自己。复杂模式下，是一个比较大的表单，类似现在的，支持更详细的选择。
按照时薪设置计算 token，同时支持调整
提交到 memepool（无需签名）
如果数值和内容有问题，可以随时进入编辑状态进行修改
由于是提交到 mempool 中心化服务器里面，所以可以通过 API 进行灵活的提交。
Validators 模式（组长或者 core 审批模式，偏中心化，不需要登记地址即可提交）：
单选或者多选，然后点击签名见证，同意，选出没有异议的同意
最后一个 validator 完成验证之后，签名同时将其上 blockchain，并且 mint 出 token 发放到对应的提交者
Validators 需要提供 gas 补贴，以及额外的治理激励，因为会让他们执行
全 Validators 模式（每个人都是 validators 支持投票，需要登记地址，设置最长时间）：流程同上，然后投票时间过了之后，达到目标的也可以通过，但是需要再下一次合约操作时，将其 mint 出来。
charlotte:
其他的还有比如需要自己做加法统计总时长；有一些高频出现的贡献项目是否可以保存为 item，不用每周重复打字输入等。
我们先从最简单的模式开始，然后慢慢扩展优化，避免上来过度设计，过早陷入到打磨细节的陷阱。
charlotte:
这个是在 Dashboard 等统计使用的，比较高级，以前发工资会根据不同工作进行降权，比如会议打折。
charlotte:
日期会填错或忘记修改 - 这可能与当前 FS 是回溯性记录有关
这里感觉有 bug，会存储一些之前的日期，默认当天就行了，然后跟 FS 的回溯性记录关系这个没搞懂，不是很理解。
这个要优化，by default，之前的确实太繁琐了。
charlotte:
提交签名时，如果没开全局 VPN，有时候会无法弹出签名窗口（不止一次看到有人问） - 新版 FS 提交记录如果是链下的，应该也不会有这个问题
一开始不知道自己需要 approve，导致有的贡献没有被记录在分配中
这里的复杂度都是因为 EAS 和 OP，我们优化之后，会将其放在有经验的 Validator 上面。然后测算下 OP 的 gas，可能不用 EAS 了，直接存到 OP 上面。
不用思考，聚焦 记录 + 自动化分配 功能先。然后 retro funding 未来再说，或者整合外部的系统。
这是第二优先级的功能和需求。
Marcus:
投票机制上，将 FS Token 和资金发放强制关联，不具备可调整功能（调整的功能可采取再登记模式），提升人们对于治理的重要性
这里的复杂度，会收敛到 Validator 这里，会自动进行分发。
Marcus:
可以增加 swap 页面或者引导等，增加 token 交易的面板，其实类似资产，对于知名的项目可能会吸引购买支持或者交易，本质是一种创作者 token。
Marcus:
用户体验上：‘分披萨’的感觉不够强烈，可以做一些交互或者游戏化的方式，去增加分披萨的感觉，提交贡献，分配资金，获得一小块‘’披萨‘
尽量简洁简单。
建议先做好最基础的，这些太未来科技了，不显示。
太复杂了，就是登记 -》验证 -》永久保存 -》分配依据 -》自动化分配。
Marcus
February 25, 2025, 10:57am
10
Bruce: 第一种模型达到一定人物量级，导致实际投票的参与者必然会产生治理冷漠的情况，第二种方式节点模式（Gas 报销，某些收益）
Marcus
February 25, 2025, 11:04am
11
Jiwen: 贡献者如何确定贡献值？
Jiwen: Dashboard 功能，比如个人计划对比，治理冷漠的问题，可以做的社交化一点
这个在设计层面应该给用户更多的正反馈，比如有数值的增加，以及整个项目在 grow 变得越来越大。
然后贡献被认可了，可以发送邮件恭喜，或者可以分享自己的贡献，得到了认可。
团队这块，S12 之后，会从 FS 独立出来，会由 Bruce 作为 PM 成立一个新的项目组，然后启用一个新的 FS 进行贡献的登记和团队贡献管理。
先贡献动起来，然后后续申请的 grants 或者融资再分发。
建议有问题解决问题， 不要采用“推倒重来”的设计方式。FS 的设计理念和核心功能是经过大量的讨论和技术方案设计，超过1年半开发迭代形成的产品，起码在一定时间内是经过考验的。
kahn.yuan:
起码在一定时间内是经过考验的。
这个在我眼里不太成立，根据我大量的亲身经历和观察，FS 的设计理念和核心功能，并没有完成我一开始提出的两个最关键的目标：
主观贡献量化成客观，并且通过 token 的方式永久标记和存储，激发大家主动贡献和关注。现状：没人 mint token，根本不知道为什么要 mint
自发的进行提交和投票，自动化的按照贡献进行分配。现状：比较难用的 notion，没人投票，半自动化贡献分配近期才上
上面的新版方案，就是根据目前不合理的地方和已有基础上进行的改进，比如增加 mempool 的设计，就是为了解决大家提交用户体验的问题，提交之后不能编辑。
kahn.yuan:
超过1年半开发迭代形成的产品
一年半的开发迭代，实际印象中是也只有 3 个月左右的实际开发，大部分时间处于无响应状态。
这些问题归结到项目没有正常的迭代，更准确一些。表象是系统不好用，没达到预期，根本原因是项目没有正常运作导致的，比如资源分配、人员交接等。不解决这些问题，到时候还是一地鸡毛。
1 Like
Marcus
March 3, 2025, 11:15am
17
其实在过去，FS 一直都有来自工作组的资源支持，对比其他差不多资源项目如密西西比，是一笔拨款就不支持了，而 FS 每次季度拨款都有 Forge 小组提供资源支持
我们在过去其实 BD 了很多团队，这是我们的 BD 记录（当时主要由 Marcus 和 Mike 去 BD）
我们在 BD 过程中也收集了很多问题，但是并未组织很好的专业的产品团队对问题进行很好思考
我的建议是，我们这一次的改造，直接在此帖子展开并充分讨论，聚焦在产品问题，而不是产品资源分配以及团队构成上（这些问题存在，而且会一直存在，但是解决产品问题，这些问题就可以解决）
1 Like
本末倒置了吧，根本原因是没有理解好需求并且做好相应的设计和需求开发，后来没有得到积极正反馈，再后来团队成员就忙别的去了。还好有 LXDAO，还有 Forge 组一直资助和寻找 PM 来推进。
理解好了需求，做好了相应的设计，也经过了验证，结果失败了，那么就说明这个项目确实不会成功是个伪需求。如果有了正反馈，才会有更多的人来。
这个帖子还是讨论点具体比较实用的新功能吧，不聊这些虚的了。比如你觉得哪些设计和功能是值得保留但是上面没有提到的？
