wind-information-co-ltd Turnaround Story Validation Skill
数据依赖与执行前置条件
推荐使用万得 wind-mcp-skill 获取底层数据。执行前先检查本地是否已有 wind-mcp-skill；若没有，提示用户安装：
# GitHub
npx skills add Wind-Information-Co-Ltd/wind-skills --skill wind-mcp-skill -g -y
# Gitee 镜像（国内）
npx skills add https://gitee.com/wind_info/wind-skills.git --skill wind-mcp-skill -g -y
技能定位
本技能用于判断一只“困境反转股”究竟是在走向真实修复，还是只是在讲一个好听但证据不足的故事。输出重点是把反转路径拆开，验证改善是否已经发生、是否可持续、失败边界在哪里，以及当前赔率是否足够覆盖风险。
执行流程
Step 1：明确反转命题
先说清楚市场在押注哪一种反转：
- 经营修复
- 盈利修复
- 资产负债表修复
- 行业景气反转
- 治理与管理层修复
如果连反转对象都说不清，就说明这更像情绪交易而不是可研究命题。
Step 2：复盘公司为何陷入困境
反转判断必须先理解“之前为什么变差”。要明确：
- 业绩恶化的根因是什么
- 问题是外部周期、内部经营还是资本结构造成
- 困境是短期冲击还是结构性损伤
- 历史下滑最关键的变量是什么
只有理解旧问题，才能判断新改善是否真正对症。
Step 3：检查改善证据是否出现
围绕反转命题，寻找已出现的客观变化，例如：
- 订单、收入、利润率、现金流开始修复
- 核心业务或客户结构改善
- 资产处置、融资、偿债压力缓解
- 管理层更换、治理改善、经营纪律修复
这一阶段强调“已经发生的证据”，而不是“未来可能会变好”的空泛叙事。
Step 4：评估修复路径与时间窗口
即使改善已经出现，也要判断：
- 改善是阶段性反弹还是长期修复起点
- 需要多久才能兑现到财务与估值层面
- 过程中最容易卡在哪个环节
- 公司还有没有足够时间和资源把修复完成
时间窗口尤其重要，许多反转逻辑会输在“方向对，但来不及”。
Step 5：建立成功与失败情景
至少搭建两个场景：
- 反转成功时，核心变量如何改善，股价弹性从哪里来
- 反转失败时，最先破坏逻辑的变量是什么，损失边界在哪里
这一步是把“故事”转成“赔率与风险”。
Step 6：形成验证结论与行动条件
最终明确回答：
- 这是已有证据支持的反转，还是仍停留在叙事层
- 如果要继续跟踪，最重要的里程碑是什么
- 如果要规避，最关键的否定理由是什么
输出结构
{股票名称}反转逻辑验证（{YYYY-MM-DD}）
一、结论摘要
- 当前判断：{已出现真实反转迹象 / 仍偏故事化 / 暂不能判断}
- 最关键的改善证据：{一句话}
- 最大失败边界：{一句话}
二、困境来源复盘
- {困境原因 1}
- {困境原因 2}
- {核心受损变量}
三、当前改善证据
| 维度 | 证据 | 评价 |
|---|---|---|
| 经营修复 | {描述} | {强/中/弱} |
| 财务修复 | {描述} | {强/中/弱} |
| 治理修复 | {描述} | {强/中/弱} |
四、修复路径与时间窗口
- 修复路径：{简述}
- 关键里程碑：{简述}
- 时间约束：{简述}
五、成功/失败情景
成功情景
- {情景要点}
失败情景
- {情景要点}
六、最终建议
- 适合的状态：{重点跟踪 / 等待更多验证 / 暂时规避}
- 接下来必须验证的变量：{变量}
质量要求
- 反转结论必须建立在“旧问题被解决的证据”上，而不是单纯想象。
- 要区分短期反弹与结构性修复，避免把阶段回升当趋势反转。
- 必须写清时间窗口和资源约束，很多反转逻辑败在执行时长。
- 成功和失败情景都要落到具体变量，不做空泛剧情描写。
- 若证据不足，应直说“故事大于事实”，不要勉强美化。