众所周知，任何协议都不可能是完美无缺的，Milky 也是如此。在代码编写过程中，Milky 的一些设计缺陷逐渐暴露出来，这些缺陷并不一定影响 Milky 协议的使用，但违背了对称性、风格统一性的设计哲学，并且进行修改会破坏兼容性，列出如下，未来如果有 Milky 2.x 的迭代，将考虑对这些部分进行改动。
get API 的命名问题
部分 API 遵循 OneBot 11 的命名风格，批量获取的 API 命名为 get_xxx_list，单独获取的 API 命名为 get_xxx_info。另外一部分 API 则直接命名为 get_xxxs。
联合类型的风格问题
Milky 目前存在两种联合类型：
- 形如
Event 和 IncomingSegment，不同子类型一级字段完全相同，其中的 data 字段是一个嵌套结构，不同子类型的 data 字段结构不同，在 Milky IR 中称作 withData。
- 形如
IncomingMessage 和 GroupNotification，不同子类型的一级字段有所不同，有共有部分，也有自己独特的部分，在 Milky IR 中称作 plain。
这严重影响了代码生成部分的代码简洁度。就近而言，应当将消息段部分的联合类型从前者迁移到后者。
API 返回数据结构问题
目前各种 API 的返回数据结构是完全照抄 OneBot 11，即无论 API 调用成功与否，只要成功到达协议端的 API 路由，HTTP 状态码都是 200，而实际执行结果包含在返回数据的 retcode 中，成功为 0，失败为非 0。这种处理方法的误导性较大，应当充分利用已有的 HTTP 状态码（200/404/405/500）来表示执行结果，而返回数据中只包含具体错误信息。
众所周知，任何协议都不可能是完美无缺的，Milky 也是如此。在代码编写过程中，Milky 的一些设计缺陷逐渐暴露出来，这些缺陷并不一定影响 Milky 协议的使用，但违背了对称性、风格统一性的设计哲学，并且进行修改会破坏兼容性，列出如下，未来如果有 Milky 2.x 的迭代，将考虑对这些部分进行改动。
get API 的命名问题
部分 API 遵循 OneBot 11 的命名风格，批量获取的 API 命名为 get_xxx_list，单独获取的 API 命名为 get_xxx_info。另外一部分 API 则直接命名为 get_xxxs。
联合类型的风格问题
Milky 目前存在两种联合类型：
Event和IncomingSegment，不同子类型一级字段完全相同，其中的 data 字段是一个嵌套结构，不同子类型的 data 字段结构不同，在 Milky IR 中称作withData。IncomingMessage和GroupNotification，不同子类型的一级字段有所不同，有共有部分，也有自己独特的部分，在 Milky IR 中称作plain。这严重影响了代码生成部分的代码简洁度。就近而言，应当将消息段部分的联合类型从前者迁移到后者。
API 返回数据结构问题
目前各种 API 的返回数据结构是完全照抄 OneBot 11，即无论 API 调用成功与否，只要成功到达协议端的 API 路由，HTTP 状态码都是 200，而实际执行结果包含在返回数据的
retcode中，成功为 0，失败为非 0。这种处理方法的误导性较大，应当充分利用已有的 HTTP 状态码（200/404/405/500）来表示执行结果，而返回数据中只包含具体错误信息。