官网、钱包接入与智能合约开发，交付范围怎么划分？

先把用户流程画出来

一个需要钱包登录和会员凭证的项目，可以先画出进入官网、连接钱包、查询资格、提交交易、查看结果的顺序。哪个步骤需要链上执行，哪个只需普通系统，应逐项判断。这个例子是假设需求，不是实际客户案例。

三类交付承担不同职责

DApp 通常由前端与智能合约等部分协作组成。官网界面负责展示和交互；钱包接入负责连接与请求确认；合约负责链上规则。系统也可能需要后台、数据库和索引服务，不能把整个项目简化为一份合约。

参考： ethereum.org：Technical introduction to dapps

逐步检查状态，避免只验收成功演示

建议按用户拒绝连接、网络不符、数据加载失败、交易待确认、交易失败和成功回执等状态评审。界面显示“已提交”与链上已确认是不同状态；应在交付清单中说明每种状态如何提示和继续。

把运维和管理员操作单独交接

部署环境、域名、接口配置、合约地址、管理员角色和版本记录应有清晰的交接方式。公开展示的案例应去除密钥、登录资料和未授权客户信息；可公开证据与私密交付文件应分开。

报价依照范围，验收依照场景

建议先确定页面、链、钱包、合约功能、业务接口和维护范围，再讨论报价。功能演示、合约测试和独立安全审计属于不同证据，不能相互代替，也不能把一次技术测试写成收益或安全保证。

项目判断清单

• 列出每个步骤由前端、后台还是合约处理。
• 加入拒绝、失败和待确认场景。
• 准备版本、配置、权限与维护交接清单。

常见问题