EA 定制与源码授权：把需求写成可以验收的清单
“做一个 EA”或“给我源码”还不足以形成可比较的报价。写清运行环境、功能边界、使用权和交付结果，能让双方更早判断是否适合合作，也让验收有据可查。
这份清单可用于新开发、现有项目适配或源码许可咨询。先填写已知部分，不确定的项目标注“需共同确认”，再交给顾问评估。
第一步：说明环境和用途
写明 MT4 或 MT5、终端版本、电脑或 VPS 环境，以及目标品种和账户模式。已有项目还需说明当前版本、依赖组件、可提供的材料和允许修改的范围。
用途会影响许可要求：个人使用、团队内部使用、付费服务、二次开发和再分发，需要分别说明。希望交付源码时，同时要求确认第三方依赖及相应使用限制。
第二步：用输入和结果描述功能
每个功能至少写出：在什么条件下发生、用户如何操作、系统应显示或输出什么、失败时如何提示。把“界面好用”“运行稳定”拆成能检查的行为。
说明示例：MT5 面板状态提示
下面只是需求写法示例，不是已交付项目或报价。
| 项目 | 示例要求 | 检查方法 |
|---|---|---|
| 连接状态 | 显示当前连接状态及最近更新时间 | 在约定的模拟测试环境中改变连接条件，核对显示 |
| 帮助入口 | 点击后打开指定使用说明 | 检查目标页面可打开，链接与版本一致 |
| 异常提示 | 获取状态失败时显示明确提示，不显示旧状态为最新 | 模拟失败响应，记录实际提示 |
| 改动边界 | 本次仅改面板状态显示，不新增交易功能 | 对照范围清单和变更记录检查 |
如果项目涉及交易功能，应另行写清触发、执行、异常处理与测试条件；不能用这个界面示例替代完整的策略规格。
第三步：约定具体交付物
| 交付类型 | 报价中应列出的内容 |
|---|---|
| 可运行版本 | 文件名称、版本、适用环境、安装和配置说明 |
| 源码 | 源文件范围、依赖及版本、构建说明、所需工具和许可范围 |
| 验收材料 | 测试输入、预期结果、实际结果及对应记录 |
| 运维说明 | 更新步骤、常见错误提示、问题反馈方式 |
| 后续支持 | 支持期限、问题修复范围、修改轮次及额外需求的处理方式 |
并非每个订单都包含整张表。请让报价明确勾选哪些包含、哪些需要另行安排。
第四步：把验收和追加需求分开
开始前约定测试环境、参与验收的人、反馈时间和通过条件。验收时按已确认的功能逐项记录“通过／待修订”，附上能复现问题的步骤。
没有达到已约定要求的事项，作为修订处理。原范围之外的新功能，先记录影响，再确认费用与排期。交易结果本身不能替代对代码功能和交付物的验收。
可直接复制的需求模板
项目目标：用一句话说明要解决的问题。
交付类型：成品授权／源码许可／适配／新开发。
运行环境：平台、版本、设备、目标品种、账户模式。
已有材料：公开链接、可合法提供的文件、说明文档。
功能清单：每项写触发条件、操作、预期结果和异常情况。
不包含的内容：本次明确排除的功能和服务。
使用权要求：使用主体、修改、商用、再分发、是否独家。
交付清单：运行文件、源码、依赖、文档、测试记录。
验收方法：测试环境、样例、通过条件和反馈方式。
后续支持：期望支持范围、期限和修改安排。
时间与预算：期望日期、预算范围及优先级。
初次沟通可先提供概括说明。需要进一步交接时，再确认材料权限和交接方式。
发出需求前，再核对三件事
- 范围是否一致：正文、报价与交付清单描述的是同一个项目。
- 权利是否明确：拿到哪些文件，与能如何使用这些文件，分别写清。
- 验收是否可执行：双方能在约定环境中，用同一组样例检查结果。
准备好这些信息后，联系 EAXAU 评估范围。可行性、费用和工期根据实际材料确认。