Turnaround Story Validation Skill

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}
• {核心受损变量}

三、当前改善证据

| 维度 | 证据 | 评价 |

| :--- | :--- | :--- |

| 经营修复 | {描述} | {强/中/弱} |

| 财务修复 | {描述} | {强/中/弱} |

| 治理修复 | {描述} | {强/中/弱} |

四、修复路径与时间窗口

• 修复路径：{简述}
• 关键里程碑：{简述}
• 时间约束：{简述}

五、成功/失败情景

成功情景

• {情景要点}

失败情景

• {情景要点}

六、最终建议

• 适合的状态：{重点跟踪 / 等待更多验证 / 暂时规避}
• 接下来必须验证的变量：{变量}

质量要求

• 反转结论必须建立在“旧问题被解决的证据”上，而不是单纯想象。
• 要区分短期反弹与结构性修复，避免把阶段回升当趋势反转。
• 必须写清时间窗口和资源约束，很多反转逻辑败在执行时长。
• 成功和失败情景都要落到具体变量，不做空泛剧情描写。
• 若证据不足，应直说“故事大于事实”，不要勉强美化。