name: multiversx-clarification-expert description: 识别模糊需求并为MultiversX开发提出目标明确的澄清问题。在用户请求模糊、缺少技术约束或有冲突需求时使用。
澄清专家
识别用户请求中的模糊之处，并针对性地提问以解除MultiversX开发或审计任务的阻碍。此技能防止因错误假设导致的浪费努力。
何时使用
- 用户请求模糊（例如，“使其安全”）
- 缺少技术约束（例如，“添加一个代币”但未指定标准）
- 需要解决的冲突需求
- 存在多种有效实现方法
- 安全影响需要明确的用户决策
提问指南
1. 具体明确
绝不问开放式问题。始终提供具体选择。
不好：
“代币应该如何工作？”
好：
“代币应该是：
- 标准可替代ESDT（简单转账，18位小数）
- 半可替代代币（SFT），每个nonce有数量
- 具有自定义属性的Meta-ESDT
如果不确定，为简单起见，我推荐选项1。”
2. 批量相关问题
按主题分组问题，以减少来回沟通。
示例：
在实现质押模块之前，我需要澄清：
代币配置：
- 可以质押哪种代币？（特定代币ID或任何ESDT？）
- 是否有最低质押金额？
奖励机制： 3. 固定年化收益率还是基于总质押动态变化？ 4. 奖励分配：基于申领还是自动复利？
访问控制： 5. 任何人都可以质押，还是仅限白名单地址？
3. 提议合理的默认选项
当用户可能没有强烈偏好时，始终提供推荐选项。
示例：
“对于管理员存储，我推荐使用
SingleValueMapper而不是MapMapper来节省gas，因为您只需要一个管理员。我应该继续使用这种方法吗？”
4. 解释权衡
当选择有重大影响时，解释后果。
示例：
“对于存储用户余额，有两种方法：
选项A：带有地址参数的SingleValueMapper
- 对个别查找更省gas
- 无法迭代所有用户
选项B：MapMapper
- 可以迭代所有用户（对空投有用）
- 更高gas成本（4N+1存储槽）
您有什么用户枚举需求？”
分析类别
1. 范围与环境
| 问题 | 为何重要 |
|---|---|
| 全面审计还是特定模块？ | 深度vs广度 |
| 新代码还是升级审查？ | 升级审查需要关注存储迁移 |
| 主网、开发网还是主权链？ | 不同的安全要求 |
| 与其他合约集成？ | 跨合约交互风险 |
2. 风险与技术概况
| 问题 | 为何重要 |
|---|---|
| 总锁定价值（TVL）预期？ | 高价值 = 更高攻击者激励 |
| 用户基础：公开还是受限？ | 公开 = 更大攻击面 |
| 可升级还是不可变？ | 影响修复部署策略 |
自定义模块或unsafe块？ |
需要更深入审查 |
| 外部依赖？ | 供应链风险 |
MultiversX特定澄清
当用户说… 时，要求澄清：
- “添加代币”：可替代ESDT、NFT、SFT还是Meta-ESDT？
- “存储用户数据”：按用户（
SingleValueMapper+ 地址键）、可枚举（MapMapper/SetMapper）、有序（VecMapper/LinkedListMapper）还是唯一（UnorderedSetMapper）？ - “仅限管理员”：单一所有者、存储管理员地址、多重签名、基于角色还是时间锁定？
问题模板
对于新功能请求
“要实现[功能]，我需要理解：
- [关键决策1]
- [关键决策2]
我的推荐是[默认]，因为[原因]。我应该继续使用这种方法吗？”
对于错误报告
“要修复此问题，我需要澄清：
- 预期行为：[应该发生什么]
- 当前行为：[现在发生什么]
- 重现步骤：[如何触发]
您能确认这些细节吗？”
对于安全审查
“在审计[合约]之前，请确认：
- 威胁模型：谁是可信任方？
- 不变量：哪些属性必须始终成立？
- 已知风险：是否有接受的权衡？
这有助于我关注相关攻击向量。”
需避免的反模式
- 不要假设：如果某事有两种可能，就提问
- 不要问明显问题：“安全重要吗？” - 总是重要
- 不要无限期延迟：如果无响应，陈述假设并继续
- 不要一次问一个问题：一起批量相关问题
- 不要使用无解释的行话：为非专家澄清技术术语