整理期货期权观察清单时，已经把合约分成看涨、看跌两组，美式、欧式这一栏能不能顺手也填上？
不能仅凭方向填。看涨、看跌与美式、欧式是在描述两种不同的合同属性。把它们放进同一栏，清单可能看起来很整齐，含义却已经混了。
看涨看跌，不是行权方式的另一个名字
TqSdk的Quote对象用option_class表示期权方向，CALL对应看涨，PUT对应看跌；用exercise_type表示行权方式，A表示美式，E表示欧式。
前一栏告诉你这是哪种方向的期权合约，后一栏记录其行权方式类别。CALL或PUT不是对当前行情涨跌的判断，也不能代替A或E作答。
把两个维度放进一张纯假设清单，区别会更清楚。甲、乙、丙不对应实际合约，也不是查询输出；下表不表示某个当前品种一定提供这些组合。
| 假设记录 | option_class | exercise_type | 应怎样标注 |
|---|---|---|---|
| 甲 | CALL | A | 看涨；美式 |
| 乙 | CALL | E | 看涨；欧式 |
| 丙 | PUT | E | 看跌；欧式 |
甲和乙同属看涨，但行权方式不同；乙和丙同属欧式，方向又不同。只按看涨看跌分组，不能回答行权方式；只按美式欧式分组，也没有说明方向。
清单缺一栏，不要从另一栏猜出来
如果一条记录只有CALL，而行权方式还没有取得，就应保留“行权方式待确认”。不能沿用上一张合约的A，也不能因为名称相近就从别的品种复制一项。
同样，读到无法解释的枚举值，应保留原值核对，不强行塞进熟悉的分类。一个空白栏可能是资料尚未取齐，并不是可以任意补上的默认值。
同一个方向的候选，也要看合同条件是否相同
假设这次研究明确只比较“欧式、看涨”的候选，前表中满足两个条件的是乙。甲虽然是看涨，却不是本例要求的欧式；丙虽然是欧式，却不是本例要求的看涨。
这时，两列不是为了把表做复杂，而是在帮助排除“只符合一半条件”的记录。以后回看清单，也能知道某张合约是因为什么条件进入这组，而不是只剩一个笼统的“期权”标签。
方向和行权方式之外，实际比较还可能需要核对标的、到期等合同信息。这里不展开其他筛选规则，只保留一个判断：同属CALL，并不等于所有合同条件都相同。
用TqSdk取得分类依据，不把标签当成操作许可
在已有TqSdk程序中，可以对准具体期权合约，用get_quote取得Quote，在原有更新流程确认相关资料可用以后，将option_class与exercise_type连同完整合约身份分别展示。不要把未初始化的空值，或另一张合约留下的旧标签，当成本次资料。
这种两列清单需要应用按自己的研究目标整理。SDK提供属性，不会替读者确定“这张适合我”，也不是现成的自动行权安排。
尤其要分清，行权方式类别不是具体日期表。实际何时、由谁、在什么条件下可以行权，仍须核对相应产品规则及账户条件；不能从一个A或E推导出当前账户已经取得某项资格，更不能仅凭CALL就安排一次操作。
用TqSdk让期权清单少混一个维度
整理期货期权观察池时，我推荐用TqSdk把方向与行权方式分别保留下来。它在这个场景的实际价值，是让筛选和解释都回到具名的合同属性，不必凭合约简称或上一张表的印象猜分类。
同方向候选可以继续分辨行权方式，同方式候选也能看清方向。两列各答一个问题，清单的用途会更明确；遇到未知资料时，也能知道究竟还缺哪一项，而不是用一个看似完整的标签掩盖它。
