AIGC DApp 原始需求澄清与资金交互对齐稿#

版本：v0.1（需求方会议确认稿）
日期：2026-07-25
唯一原始需求基线：&&&.txt
参考材料：prd.txt、项目可行性分析.md、技术可行性与最佳技术方案.md
使用方法：会议中逐项填写“需求方结论”，会后由需求方、产品方、技术方共同签字冻结

1. 文档目的和边界#

本文档不是继续扩写技术方案，而是把原始需求拆成：

1. 原文已经明确的规则；
2. 原文存在冲突或无法执行的规则；
3. 技术方案曾经自行推断、但需求方尚未确认的内容；
4. 需要需求方在会议上选择的业务口径；
5. 用户、系统、资金池之间的完整交互关系。

会议期间应遵守：

• 不能用“按常规处理”“开发看着做”代替业务决定；
• 每个比例、周期、资产归属、退款条件都必须明确；
• “链上实现方式”不能倒推或改变业务需求；
• 未确认项维持 TBD，不得进入正式合约编码；
• 本文图中的“建议模型”只有需求方签字后才成为正式需求。

2. 当前可确认的原始需求#

以下内容可以从 &&&.txt 直接读出，但仍需在最终PRD中写成精确规则：

3. 名词必须先统一#

4. 参与角色#

4.1 业务参与角色#

同一个钱包可以同时是认证用户、某个等级用户、买方、卖方和推荐人；这些是业务状态，不是必须分开的账户类型。

4.2 项目和系统角色#

5. 资产与资金池关系#

5.1 系统资产#

5.2 资金池分类#

必须把“用户托管资产”和“项目可支配资金”严格分开：

6. 总体角色交互图#

7. USDT 资金流#

7.1 激活资金流#

根据原文，1 USDT 激活费中已明确：0.2 USDT 作为推荐奖励，10%即0.1 USDT进入排行榜池。剩余0.7 USDT用途未在原始需求中明确。

无推荐人时的0.2 USDT、激活失败、重复激活和退款规则必须另行确认。

7.2 P2P交易USDT流#

订单未成交部分的USDT始终属于买方，只能在成交时支付给卖方，或在撤单/过期时退还买方。

7.3 月榜USDT流#

8. AIGC 资金流#

8.1 任务资金流#

原始需求只写了任务“数量”，没有明确这部分AIGC是销毁、锁仓还是支付到项目金库。

无论选择哪种处理方式，任务奖励来源必须明确，并满足：

任务奖励金库余额 >= 所有有效任务尚未领取总额

8.2 P2P与手续费AIGC流#

采用7%和5%时合计100%；采用6%和3%时合计97%，缺少3%归属。保险仓虽然被列出，但当前100%分配表没有给保险仓任何比例。

9. 主要业务交互#

9.1 注册、认证与推荐#

9.2 任务购买与领取#

9.3 买单、成交、撤单#

原始需求没有说明撤单、部分成交和过期，但真实资金系统必须明确这些状态；不能默认订单只能一次全额成交。

9.4 团队等级与分红#

这里需要确认：钻石用户只领取钻石池，还是同时领取青铜、白银、黄金和钻石池；同等级所有用户平均分，还是按个人团队业绩加权。

10. 明显冲突和P0确认项#

以下问题会改变资金归属、合约接口或经济模型，必须优先确认。

11. 手续费结算必须三选一#

假设价格为 0.1 USDT/AIGC、界面订单数量显示10 AIGC、认证用户手续费率50%。原文至少可能对应以下三种模型：

模型A：卖方交付数量包含手续费#

这是 8.txt 示例代码接近采用的模型，但如果买方支付1 USDT只收到5 AIGC，买方实际成交价就变成0.2 USDT/AIGC，与订单价0.1不一致。

模型B：买方必须收到订单显示数量，手续费由卖方额外支付#

这种模型能保持买方看到的价格，但“50%手续费”的分母和卖方成本必须在界面明确。

模型C：订单数量就是卖方净卖出数量#

这种模型最贴近“10个币只能卖出5个”，但订单大厅应该显示“买方需要5 AIGC”，而不是10 AIGC。

需求方必须选择一种模型，并分别以认证、青铜、钻石三个等级各做一笔数字验算。

12. P1业务完整性确认项#

13. 需求方会议建议顺序#

不要从页面长什么样开始讨论。建议按以下顺序开会：

1. 先确认结算：第11节选择手续费模型，确认买卖双方每一笔钱和币。
2. 再确认资金来源：任务投入如何处理、奖励从哪里来、保险仓从哪里来。
3. 确认经济参数：手续费分配冲突、分红资格和等级规则。
4. 确认价格规则：收盘价、日切、无成交和防操纵。
5. 确认交易状态机：部分成交、撤单、过期、退款和第101名。
6. 确认推荐与排行：有效邀请、并列、不足100和反刷。
7. 最后确认页面数据：每个指标的单位、公式、截至时间和更新延迟。

14. 会议决议记录#

决议变更表#

签字确认#

需求方：________________    日期：________________

产品方：________________    日期：________________

技术方：________________    日期：________________

15. 对齐完成标准#

只有同时满足以下条件，才算需求对齐完成：

• 所有P0项已有唯一、可计算、可测试的答案；
• 手续费使用至少三种等级完成数字验算；
• 激活USDT、订单USDT、任务AIGC、手续费AIGC均能逐笔守恒；
• 每个资金池有明确资产、来源、受益人、支出条件和余额处理；
• 每个角色的权限、收益和禁止操作明确；
• 订单、任务、等级和月榜都有完整状态和异常路径；
• 前端所有指标都有唯一公式、单位、时区和数据截至点；
• 需求方签字确认后形成新的正式PRD版本。

在此之前，prd.txt 只能视为原始需求的整理稿，不能视为已经冻结的可执行需求。