Skip to content

Latest commit

 

History

History
195 lines (128 loc) · 4.14 KB

File metadata and controls

195 lines (128 loc) · 4.14 KB

Methodology Source Policy

这个文档定义研究“研究方法”时如何处理来源分层。

目标不是收集最多的方法,而是收集最值得比较和验证的方法。

核心原则:

  • 来源类型不等于方法质量
  • 机构方法不默认更好
  • 野路子方法不默认更差
  • 实践结果和后续跟踪优先于身份光环
  • 搜索覆盖面不够的方法,不应过早下结论

Search Rule

研究方法论时,默认至少同时搜索:

  • 方法名
  • 功能描述
  • 变量名
  • 作者或机构名
  • 批评词和失败词
  • 后续复盘词

推荐的查询维度:

  • what it is 这个方法是什么
  • how it is used 这个方法实际怎么做
  • who uses it 哪些人反复使用它
  • where it fails 它在哪些场景失效
  • what it looks like in outputs 它在研报、帖子、纪要、投资者信里长什么样

如果是跨圈层方法,应该主动切换搜索语言和标签,不要只用单一社区术语。

Default Source Buckets

institutional

包括:

  • 券商研究流程
  • 基金研究分享
  • 投资人长文和访谈
  • 正式行业研究框架

价值:

  • 结构完整
  • 流程可复用
  • 便于和 buy-side / sell-side 语言对齐

风险:

  • 可能太通用
  • 可能被公开传播后失去优势

practitioner

包括:

  • 一线从业者总结
  • 实盘研究者和交易者方法
  • 行业调研经验帖和访谈

价值:

  • 更接近真实执行
  • 常能补足“实践 > 原理”的缺口

风险:

  • 表达随意
  • 容易夹杂幸存者偏差

first_principles

包括:

  • 从供需、竞争、信息结构、激励、资本成本出发的方法
  • 不依赖某个机构模板的底层分析思路

价值:

  • 迁移性强
  • 有助于发现方法背后的共通结构

风险:

  • 容易停留在抽象层
  • 没有真实应用时难评估收益

derived_internal

包括:

  • 本仓库从实际 case 中提炼出的内部方法

价值:

  • Mira 适配度最高
  • 最容易转化为正式 framework 或 overlay

风险:

  • 容易过拟合少量案例

reverse_engineered

包括:

  • 从研报、会议纪要、长文、帖子、访谈和他人分析结果里逆向抽方法

价值:

  • 能从“别人怎么得出这个结论”反推出隐含流程
  • 有助于快速扩展方法库,不被正式方法论写作风格限制

风险:

  • 容易把漂亮结论误认为好方法
  • 容易把事后归因当成前瞻框架

Credibility Rule

默认不要给任何来源类型特权。

credibility_score 应主要由以下因素决定:

  • 输入变量是否明确
  • 推理链是否完整
  • 失效条件是否存在
  • 是否有 follow-through
  • 是否能在别的 case 中复现
  • 是否能被公开信息或后续事实交叉验证

低可信的典型特征:

  • 只给结论,不给方法
  • 结果导向叙事明显
  • 一旦结论失效,无法解释是哪里错了
  • 大量使用模糊词,但没有可观察变量

Search Coverage Rule

高质量方法论研究,至少要避免以下搜索偏差:

  • 只看支持材料,不看反对材料
  • 只看“方法说明”,不看实际应用
  • 只看大机构,不看实践派
  • 只看英文,不看中文或本地表达
  • 只看热门标签,不搜相邻术语和反面问题

Evaluation Rule

默认不要因为来源“听起来高级”就高估方法。

优先比较:

  • 是否更可执行
  • 是否更能解释股价和预期变化
  • 是否更容易被证伪
  • 是否值得付出调研成本
  • 是否值得长期 follow-through

Reverse Engineering Rule

允许把“别人的分析结果”当作方法候选,但必须补上:

  • 隐含输入
  • 权重排序
  • 假设条件
  • 失效条件
  • 如果当时处在事前,是否真能据此做判断

逆向拆解时,优先搜索:

  • 这套分析在哪些别的文章里重复出现
  • 作者过去是否一直这么分析
  • 这个方法在失败案例里是否也被用过

Adoption Rule

任何新方法想进入正式系统,至少要回答:

  • 它适用于什么场景
  • 它不适用于什么场景
  • 它比现有方法多解释了什么
  • 它最可能错在哪里
  • 它是否经过了 case backtestforward watch 或真实 trial