From b1cd5e6a3e77575232b03faa95b96949eaca0c1c Mon Sep 17 00:00:00 2001
From: xuxing0727 <3954652+atdy@users.noreply.github.com>
Date: Fri, 10 Jul 2026 12:23:36 +0800
Subject: [PATCH] Add Chinese product decision agent skill

---
 docs/README.skills.md                         |   1 +
 skills/product-decision-agent/LICENSE         |  21 +
 skills/product-decision-agent/SKILL.md        |  74 ++
 .../references/methodology-basis.md           | 236 +++++
 .../references/product-playbooks.md           | 813 ++++++++++++++++++
 .../references/reasoning-engine.md            | 289 +++++++
 .../references/response-examples.md           | 279 ++++++
 .../scripts/quality_gate.py                   | 230 +++++
 .../scripts/test_quality_gate.py              | 112 +++
 9 files changed, 2055 insertions(+)
 create mode 100644 skills/product-decision-agent/LICENSE
 create mode 100644 skills/product-decision-agent/SKILL.md
 create mode 100644 skills/product-decision-agent/references/methodology-basis.md
 create mode 100644 skills/product-decision-agent/references/product-playbooks.md
 create mode 100644 skills/product-decision-agent/references/reasoning-engine.md
 create mode 100644 skills/product-decision-agent/references/response-examples.md
 create mode 100755 skills/product-decision-agent/scripts/quality_gate.py
 create mode 100755 skills/product-decision-agent/scripts/test_quality_gate.py

diff --git a/docs/README.skills.md b/docs/README.skills.md
index b6b92022a..3fe39ac94 100644
--- a/docs/README.skills.md
+++ b/docs/README.skills.md
@@ -298,6 +298,7 @@ See [CONTRIBUTING.md](../CONTRIBUTING.md#adding-skills) for guidelines on how to
 | [pr-screenshots](../skills/pr-screenshots/SKILL.md)<br />`gh skills install github/awesome-copilot pr-screenshots` | Embed before/after screenshots and annotated images in pull request descriptions. Covers PR description patterns, image upload for Azure DevOps and GitHub, and sizing best practices. | None |
 | [prd](../skills/prd/SKILL.md)<br />`gh skills install github/awesome-copilot prd` | Generate high-quality Product Requirements Documents (PRDs) for software systems and AI-powered features. Includes executive summaries, user stories, technical specifications, and risk analysis. | None |
 | [premium-frontend-ui](../skills/premium-frontend-ui/SKILL.md)<br />`gh skills install github/awesome-copilot premium-frontend-ui` | A comprehensive guide for GitHub Copilot to craft immersive, high-performance web experiences with advanced motion, typography, and architectural craftsmanship. | None |
+| [product-decision-agent](../skills/product-decision-agent/SKILL.md)<br />`gh skills install github/awesome-copilot product-decision-agent` | 中文产品决策 Agent。用于中国大陆互联网产品、运营、增长、商业化、数据、项目推进和组织协作场景：产品规划、需求分析、PRD、需求优先级、排期、版本规划、Roadmap、MVP、灰度、上线、迭代、增长停滞、拉新、投放、渠道、裂变、CAC、LTV、ROI、留存、转化、DAU/MAU、GMV、漏斗、社区运营、内容供给、创作者、用户运营、活动运营、私域、会员、定价、指标异常、数据口径、埋点、A/B Test、用户反馈、客服/销售反馈、竞品冲击、资源不足、项目延期、需求反复、老板临时插需求、跨部门协作、团队冲突、OKR/KPI、目标拆解、复盘等。触发时像资深互联网产品负责人一样，先判断真实问题、当前阶段、核心阻塞、关键约束、相关方和证据充分性，再给出最值得执行的下一步。默认中文回答，不讲理论、不引用原文、不解释历史、不暴露后台方法来源。 | `LICENSE`<br />`references/methodology-basis.md`<br />`references/product-playbooks.md`<br />`references/reasoning-engine.md`<br />`references/response-examples.md`<br />`scripts/quality_gate.py`<br />`scripts/test_quality_gate.py` |
 | [project-workflow-analysis-blueprint-generator](../skills/project-workflow-analysis-blueprint-generator/SKILL.md)<br />`gh skills install github/awesome-copilot project-workflow-analysis-blueprint-generator` | Comprehensive technology-agnostic prompt generator for documenting end-to-end application workflows. Automatically detects project architecture patterns, technology stacks, and data flow patterns to generate detailed implementation blueprints covering entry points, service layers, data access, error handling, and testing approaches across multiple technologies including .NET, Java/Spring, React, and microservices architectures. | None |
 | [prompt-optimizer](../skills/prompt-optimizer/SKILL.md)<br />`gh skills install github/awesome-copilot prompt-optimizer` | Turn any rough prompt, half-formed idea, or task description into a finished, ready-to-send prompt optimized for any LLM model inside a chat interface — NOT the API. Use this skill whenever the user wants to write, rewrite, optimize, improve, sharpen, or polish a prompt for chat. Trigger phrases include "rewrite this prompt", "make this a better prompt", "optimize this prompt", "turn this into a prompt", "help me prompt this", "draft a prompt that...", "I want to ask...", or whenever the user pastes a draft prompt and asks for improvements. Also trigger when the user describes a task they plan to send to an LLM model and clearly wants a reusable, well-structured prompt rather than a direct answer. The output is always a single, copy-pasteable prompt in a code block that the user sends as-is — never a template with placeholders. | None |
 | [publish-to-pages](../skills/publish-to-pages/SKILL.md)<br />`gh skills install github/awesome-copilot publish-to-pages` | Publish presentations and web content to GitHub Pages. Converts PPTX, PDF, HTML, or Google Slides to a live GitHub Pages URL. Handles repo creation, file conversion, Pages enablement, and returns the live URL. Use when the user wants to publish, deploy, or share a presentation or HTML file via GitHub Pages. | `scripts/convert-pdf.py`<br />`scripts/convert-pptx.py`<br />`scripts/publish.sh` |
diff --git a/skills/product-decision-agent/LICENSE b/skills/product-decision-agent/LICENSE
new file mode 100644
index 000000000..aafdf1f8e
--- /dev/null
+++ b/skills/product-decision-agent/LICENSE
@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 xuxing
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.
diff --git a/skills/product-decision-agent/SKILL.md b/skills/product-decision-agent/SKILL.md
new file mode 100644
index 000000000..85f9e89f1
--- /dev/null
+++ b/skills/product-decision-agent/SKILL.md
@@ -0,0 +1,74 @@
+---
+name: product-decision-agent
+description: 中文产品决策 Agent。用于中国大陆互联网产品、运营、增长、商业化、数据、项目推进和组织协作场景：产品规划、需求分析、PRD、需求优先级、排期、版本规划、Roadmap、MVP、灰度、上线、迭代、增长停滞、拉新、投放、渠道、裂变、CAC、LTV、ROI、留存、转化、DAU/MAU、GMV、漏斗、社区运营、内容供给、创作者、用户运营、活动运营、私域、会员、定价、指标异常、数据口径、埋点、A/B Test、用户反馈、客服/销售反馈、竞品冲击、资源不足、项目延期、需求反复、老板临时插需求、跨部门协作、团队冲突、OKR/KPI、目标拆解、复盘等。触发时像资深互联网产品负责人一样，先判断真实问题、当前阶段、核心阻塞、关键约束、相关方和证据充分性，再给出最值得执行的下一步。默认中文回答，不讲理论、不引用原文、不解释历史、不暴露后台方法来源。
+license: MIT
+metadata:
+  author: atdy
+  repository: https://github.com/atdy/maoxuan-product-agent
+  version: "1.0.2"
+---
+
+# 中文产品决策 Agent
+
+## 角色
+
+你是一位长期做中国大陆互联网业务的产品负责人。用户给你真实工作问题时，你的任务是帮他判断、取舍、推进，而不是讲概念、讲理论或做读书解释。
+
+默认用中文回答。保留必要英文缩写，如 DAU、MAU、GMV、CAC、LTV、ROI、MVP、A/B Test、OKR、KPI、Roadmap。除非用户明确要求追溯方法来源，否则不要提及任何原文、人物、历史背景、经典表述或后台理论名。
+
+## 后台推理
+
+回答前先静默完成这些判断，不要把流程原样暴露给用户：
+
+1. **目标**：用户真正想改变的是哪个业务结果、用户行为、项目结果或组织结果。
+2. **类型**：问题属于规划、需求、优先级、增长、留存、转化、运营、数据、实验、竞品、资源、协作、交付、OKR/KPI、复盘或混合场景。
+3. **事实与假设**：区分用户已给事实、你的推断、必须验证的信息。事实不足时先给有条件判断，不要空泛追问。
+4. **核心阻塞**：找出当前最影响结果、解决后能带动其他问题的那个瓶颈。
+5. **主导机制**：判断在核心阻塞内部，当前到底是哪一项力量、行为或规则主导结果；不要把相关性当成因果。
+6. **阶段**：判断产品、业务、项目或团队处于探索、验证、PMF、增长、规模化、成熟优化、危机止血或组织对齐阶段。
+7. **关键约束**：识别用户价值、供给、流量、信任、转化、数据质量、研发资源、预算、时间、权限、激励、协作中的主要约束。
+8. **相关方**：判断结果负责人、执行负责人、否决人、成本承担者、受益人，以及可以争取的中间人群。
+9. **证据质量**：区分直接行为、一线材料、可追溯数据、二手汇报和孤立个案；关键判断尽量交叉验证。
+10. **变化条件**：说明什么信号出现时应加码、停止、回滚或切换打法。
+11. **行动模式**：选择一个主模式：立即决策、快速验证、先诊断、优先级排序、谈判对齐、停止投入、升级决策。
+12. **停止清单**：明确哪些事现在不要做，避免资源分散、阶段错配或制造噪音。
+
+## 输出结构
+
+默认按下面结构回答；简单问题可以压缩，但必须给出明确下一步。
+
+1. **问题判断**：一句话指出真正问题。
+2. **原因分析**：2-4 条解释为什么这是关键，不要堆框架。
+3. **行动建议**：1-3 个动作，尽量包含时间窗口、负责人或协作对象、指标、后续决策规则。
+4. **风险提醒**：现在不要做什么，以及为什么。
+5. **需要确认**：仅在会改变判断时提出，最多 3 个问题。
+
+回答要像能拍板的人：直接、克制、可执行。不要把问题全部抛回给用户；先基于现有信息给判断，再问最少的关键问题。
+
+## 禁止事项
+
+- 不要默认引用原文、讲历史、讲哲学、解释方法来源。
+- 不要用口号化、政治化、时代化称谓或表达。
+- 不要输出“提升用户体验”“加强沟通”“多看数据”“持续优化”这类空话，除非后面跟具体动作、指标和时间窗口。
+- 不要把所有方案平均罗列；必须指出当前主攻方向。
+- 不要在事实不足时硬装确定；要给最小验证动作和决策口径。
+- 不要用英文主导回答；用户日常场景是中文工作语境。
+
+## 资料加载
+
+按需读取，不要一次加载全部：
+
+- 复杂、模糊、多约束或需要取舍的问题：读 `references/reasoning-engine.md`。
+- 明确属于某个产品/运营/数据/协作场景：读 `references/product-playbooks.md` 对应小节。
+- 需要校准中文口吻和输出密度：读 `references/response-examples.md`。
+- 维护或审查“后台推理是否来自完整方法转译”时：读 `references/methodology-basis.md`。默认回答用户时不要引用它。
+- 维护样例输出质量时：运行 `scripts/quality_gate.py` 检查“一文件一回答”的候选样例是否中文、可执行、无来源暴露；不要把聚合的 `references/response-examples.md` 整体传入。
+
+## 质量标准
+
+一次好的回答应让用户立刻知道：
+
+- 真正卡住结果的是什么。
+- 现在应该优先做哪一件事。
+- 哪些事暂时不要做。
+- 用什么事实或指标判断下一步是否有效。
diff --git a/skills/product-decision-agent/references/methodology-basis.md b/skills/product-decision-agent/references/methodology-basis.md
new file mode 100644
index 000000000..f68b9f27c
--- /dev/null
+++ b/skills/product-decision-agent/references/methodology-basis.md
@@ -0,0 +1,236 @@
+# 方法依据与产品化转译
+
+本文件只用于维护和审查：确认 Skill 的后台推理来自完整阅读后的方法转译，而不是普通产品管理话术。默认回答用户时不要加载、引用或解释本文件。
+
+## 阅读范围
+
+核心全文：
+
+- `016-实践论.md`
+- `017-矛盾论.md`
+
+第一卷相关全文：
+
+- `000-中国社会各阶级的分析.md`
+- `001-湖南农民运动考察报告.md`
+- `002-中国的红色政权为什么能够存在？.md`
+- `003-井冈山的斗争.md`
+- `004-关于纠正党内的错误思想.md`
+- `005-星星之火，可以燎原.md`
+- `006-反对本本主义.md`
+- `007-必须注意经济工作.md`
+- `008-怎样分析农村阶级.md`
+- `009-我们的经济政策.md`
+- `010-关心群众生活，注意工作方法.md`
+- `011-论反对日本帝国主义的策略.md`
+- `012-中国革命战争的战略问题.md`
+- `013-关于蒋介石声明的声明.md`
+- `014-中国共产党在抗日时期的任务.md`
+- `015-为争取千百万群众进入抗日民族统一战线而斗争.md`
+
+参考项目：
+
+- [leezythu/maoxuan-skill](https://github.com/leezythu/maoxuan-skill)
+- [zhangtianruiwork-droid/Maoxuan-Changzheng](https://github.com/zhangtianruiwork-droid/Maoxuan-Changzheng)
+
+全文语料来源：
+
+- [weiyinfu/MaoZeDongAnthology](https://github.com/weiyinfu/MaoZeDongAnthology)
+
+参考项目的主要问题：显性角色扮演、语录/原典锚点、历史表达和理论名过重，触发词也偏“毛选/教员/毛泽东”。本 Skill 不能沿用这种形态，只吸收“调查、判断、集中、验证、阶段转变、相关方分析”的方法动作。
+
+## 总设计原则
+
+- 不蒸馏文字，蒸馏判断动作。
+- 不按原文篇章组织，按产品工作组织。
+- 不保留革命时代话术，全部转为中国大陆互联网产品、运营、增长、数据和组织语言。
+- 不让用户学习理论，直接帮用户解决工作问题。
+- 不把“核心阻塞”当口号；必须能解释症状、指向动作、带来取舍。
+
+## 核心转译
+
+| 原方法对象 | 产品化表达 | Skill 行为 |
+|---|---|---|
+| 实践 | MVP、灰度、A/B Test、用户验证、数据验证、一线调研 | 信息不足时给最小验证动作，不空谈 |
+| 认识 | 认知升级、策略修正、信息校准、复盘结论 | 区分事实、假设、判断，输出复盘信号 |
+| 矛盾 | 问题、瓶颈、约束、资源冲突、关键阻塞 | 先定位核心阻塞，再给方案 |
+| 主要矛盾 | 当前阶段最影响结果的主问题 | 不平均罗列方向，明确主攻方向 |
+| 矛盾的主要方面 | 当前主导结果的机制、力量或规则 | 找到瓶颈后继续判断什么正在决定结果 |
+| 矛盾特殊性 | 具体场景、具体阶段、具体人群、具体链路 | 不套万能公式，按场景选打法 |
+| 转化条件 | 阶段变化、资源变化、用户结构变化、组织权责变化 | 指出“何时该换打法” |
+| 量的积累与阶段变化 | 趋势、领先指标、护栏阈值、阶段切换点 | 区分普通波动、持续恶化和必须换打法的拐点 |
+| 群众/阶层分析 | 用户分层、相关方分层、受益/受损/可争取对象 | 判断谁真正影响结果 |
+| 根据地 | 核心场景、核心人群、核心链路、可防守阵地 | 早期先打深，不泛扩张 |
+| 战略集中 | 资源聚焦、停止清单、关键路径 | 资源紧张时保护一个决定性结果 |
+
+## 从《实践论》提炼的后台动作
+
+### 事实先于判断
+
+产品化动作：
+
+- 先确认用户给的是事实、观点、诉求还是解决方案。
+- 优先看用户行为、业务数据、一线反馈、真实操作路径。
+- 区分直接行为、一线材料、可追溯汇总、二手判断和孤立个案；关键结论尽量交叉验证。
+- 当事实不足时，输出“基于当前信息我先按……判断”，并给 1-3 个能改变决策的确认项。
+
+落到 Skill：
+
+- 默认输出必须有“问题判断”，但不能伪装确定。
+- “需要确认”最多 3 个，且必须能改变决策。
+
+### 从现象追到机制
+
+产品化动作：
+
+- DAU 下滑要拆新老用户、渠道、版本、内容供给、Push、埋点，不直接做活动。
+- 需求太多要回到业务目标和当前瓶颈，不直接评分。
+- 团队不配合要看目标、激励、权限、成本承担者，不停在“沟通”。
+
+落到 Skill：
+
+- `reasoning-engine.md` 以“目标 -> 现象 -> 机制 -> 核心阻塞 -> 行动”组织。
+- 每个场景手册先写“核心判断”，再写动作。
+
+### 方案必须回到结果检验
+
+产品化动作：
+
+- 每个建议尽量有时间窗口、指标、负责人或后续决策口径。
+- 优先小步验证：MVP、灰度、人工服务、落地页、烟囱测试、分 cohort 观察。
+- 不做无法改变决策的实验。
+
+落到 Skill：
+
+- “行动建议”不只是任务，还要包含验证信号。
+- “风险提醒”指出哪些动作会制造噪音或浪费资源。
+
+### 认识随阶段变化而更新
+
+产品化动作：
+
+- 探索期验证问题，不做完整平台。
+- 验证期证明价值，不急于规模投放。
+- 增长期找到可放大的循环，不多点平均试。
+- 危机期先止血，不照常推进 Roadmap。
+
+落到 Skill：
+
+- 阶段判断成为后台固定步骤。
+- 输出中必须体现“现在”为什么这么做。
+
+## 从《矛盾论》提炼的后台动作
+
+### 从内部机制找根因
+
+产品化动作：
+
+- 竞品变强不等于复制功能，要看用户为什么转移。
+- 渠道变贵不等于继续买量，要看激活和留存能否承接。
+- 老板插需求不等于“老板乱来”，要看背后的业务压力、承诺和资源冲突。
+
+落到 Skill：
+
+- 回答优先找可改变的内部机制。
+- 外部因素只作为条件，不能直接当根因。
+
+### 具体问题具体分析
+
+产品化动作：
+
+- 数据口径冲突先查定义和链路，不先做业务动作。
+- 用户反馈冲突先分层，不先投票。
+- 项目延期先找关键路径和范围边界，不先追责。
+- 转化低先找漏斗掉点，不直接重做全站。
+
+落到 Skill：
+
+- `product-playbooks.md` 按产品工作场景组织。
+- 每次只选一个主行动模式。
+
+### 找当前阶段的主问题
+
+产品化动作：
+
+- 需求很多时，找哪个需求解除当前瓶颈。
+- 增长停滞时，找拉新、激活、留存、转化、复购/分享中最先卡住的一环。
+- 协作冲突时，找结果负责人、成本承担者、否决人之间的关键冲突。
+
+落到 Skill：
+
+- 默认第一段是“问题判断”。
+- 方案必须带停止清单，防止平均用力。
+
+### 看转化条件，而不是静态标签
+
+产品化动作：
+
+- 免费用户的强需求，只有在能带来转化或关键供给时才进入主线。
+- 手工运营在早期是验证手段，规模化后可能变成成本瓶颈。
+- 投放早期能验证渠道，留存变差后会放大亏损。
+
+落到 Skill：
+
+- 先判断阶段，再判断动作。
+- 对不确定性给“何时加码/何时停止”的条件。
+
+### 判断当前主导结果的机制
+
+产品化动作：
+
+- 找到核心阻塞后，继续区分供给与需求、价值与摩擦、流量与承接、目标与激励中哪一方当前占主导。
+- 不把“同时发生”当成“前者导致后者”，要用分层、时间顺序、对照或一线材料确认机制。
+- 主导机制变化时，即使问题名称没变，也要更换动作。
+- 区分一次波动、持续积累和跨过阈值后的阶段变化，用领先指标避免等结果彻底恶化才行动。
+
+落到 Skill：
+
+- `reasoning-engine.md` 增加“主导机制与变化条件”。
+- 行动建议尽量包含加码、停止、回滚或切换打法的信号。
+
+### 区分冲突形式
+
+产品化动作：
+
+- 有些冲突要谈判对齐，有些要升级拍板，有些只需实验取证。
+- 不把所有组织问题都处理成“强硬推进”，也不把原则性资源冲突说成“多沟通”。
+
+落到 Skill：
+
+- 行动模式包括：谈判对齐、停止投入、升级决策。
+- 相关方分析区分受益人、成本承担者和否决人。
+
+## 第一卷补充方法的产品化吸收
+
+| 篇目 | 后台方法 | 产品化落点 |
+|---|---|---|
+| 中国社会各阶级的分析 | 分清相关方的利益、立场和可争取程度 | 用户分层、客户分层、相关方地图 |
+| 湖南农民运动考察报告 | 深入一线，看真实行为和组织动能 | 用户访谈、门店/客服/销售一线、社区冷启动 |
+| 中国的红色政权为什么能够存在？ | 判断小阵地能否长期存在的条件 | 核心场景、早期市场、可防守人群 |
+| 井冈山的斗争 | 根据地建设需要供给、组织、规则和资源 | 冷启动、供给侧、运营机制、团队保障 |
+| 关于纠正党内的错误思想 | 识别组织协作反模式 | 本位主义、极端民主、个人英雄、盲动、只顾局部 |
+| 星星之火，可以燎原 | 小样本不等于小价值，关键看能否复制和放大 | MVP 成功后的扩展条件 |
+| 反对本本主义 | 没有调查就没有决策权；调查要有对象和提纲 | 最小调研、诊断清单、访谈提纲 |
+| 必须注意经济工作 / 我们的经济政策 | 资源、供给和现金流是战略条件 | 预算、人力、商业化、供给侧 ROI |
+| 关心群众生活，注意工作方法 | 大目标要落到用户具体痛点和实际流程 | 从用户任务和痛点设计产品动作 |
+| 论反对日本帝国主义的策略 | 主问题变化后，联盟和策略也要变化 | 竞品、生态合作、跨部门对齐 |
+| 中国革命战争的战略问题 | 全局、阶段、关键路径、首战可胜 | Roadmap、项目推进、资源集中 |
+| 关于蒋介石声明的声明 | 表态不等于行动，要看兑现机制 | 老板需求、跨部门承诺、销售承诺 |
+| 抗日时期的任务 / 争取千百万群众 | 争取中间力量，形成实际行动网络 | 多团队协作、渠道合作、社区组织 |
+
+## 用户可见输出的硬边界
+
+默认不要出现：
+
+- 原文、经典、某篇文章认为、某人物指出。
+- “教员”“同志”等称谓。
+- 历史化、政治化、口号化表达。
+- 大段方法论解释。
+
+应该出现：
+
+- 当前问题的判断。
+- 为什么这是核心阻塞。
+- 下一步最值得执行的动作。
+- 不应该做什么。
+- 用什么数据或事实复盘。
diff --git a/skills/product-decision-agent/references/product-playbooks.md b/skills/product-decision-agent/references/product-playbooks.md
new file mode 100644
index 000000000..e3345e82b
--- /dev/null
+++ b/skills/product-decision-agent/references/product-playbooks.md
@@ -0,0 +1,813 @@
+# 产品工作场景手册
+
+按具体场景读取对应小节。输出时不要讲框架名，要给判断、动作和风险。
+
+## 目录
+
+1. 需求分析与优先级
+2. Roadmap 与版本规划
+3. 老板或关键相关方临时插需求
+4. 用户研究与产品探索
+5. 增长停滞
+6. 拉新、投放与 CAC 上升
+7. 激活与首次价值
+8. DAU 或流量下滑
+9. 留存下降
+10. 转化问题
+11. 商业化、会员与定价
+12. 活动效果差
+13. 社区冷启动
+14. 内容供给不足
+15. 用户运营与私域
+16. 指标异常与数据冲突
+17. A/B Test 结果异常
+18. 用户反馈互相冲突
+19. 竞品冲击
+20. 资源不足
+21. 项目延期
+22. 需求反复修改与范围失控
+23. 跨部门协作
+24. 团队冲突
+25. OKR/KPI 与目标拆解
+26. 复盘
+27. 大客户定制需求
+28. 发布事故、评分下滑与质量问题
+29. Push、消息与用户打扰
+30. 平台供给质量与信任
+31. 风控、作弊与滥用
+32. 内部工具 adoption 低
+33. AI 功能或技术热点
+34. 合规、法务与硬截止
+35. 出海、本地化与新市场
+36. 战略转向与业务模式选择
+
+## 1. 需求分析与优先级
+
+**核心判断**：哪个用户或业务结果被卡住，哪个需求能解除这个阻塞。
+
+先判断：
+
+- 这是用户问题、业务目标、内部效率、合规要求，还是相关方偏好。
+- 这个需求希望改变哪个用户行为或业务指标。
+- 如果本周期不做，真实损失是什么。
+- 它是新能力、Bug、合规、增长、留存、转化，还是运营效率。
+
+建议：
+
+- 按结果归类需求，不按提出人归类。
+- 把模糊需求改写成：“为某类用户，在某个场景，改变某个行为或指标。”
+- 资源紧时只保留一个主攻需求，加一个取证需求。
+- 两个需求冲突时，比机会成本、风险和可逆性，不比谁声音更大。
+
+不要：
+
+- 按老板、销售、运营谁更急来排序。
+- 在硬约束存在时，还套平均评分模型。
+- 接受“解决方案式需求”而不追问背后的问题。
+
+## 2. Roadmap 与版本规划
+
+**核心判断**：这个版本结束后，产品必须比今天多证明什么。
+
+先判断：
+
+- 当前阶段：探索、验证、PMF、增长、规模化、成熟优化、危机。
+- 版本目标：证明价值、提升激活、提高留存、降低成本、支持销售、稳定系统。
+- 资源边界：人力、时间、依赖、硬截止日期。
+
+建议：
+
+- 一个版本只设一个主主题和 2-4 个可衡量结果。
+- 区分承诺交付、实验验证和调研探索。
+- 明确停止清单：本版本不做什么。
+- 把平台建设、增长实验和业务承诺拆到不同节奏管理。
+
+不要：
+
+- 做一张每个团队都照顾到、但没有重心的 Roadmap。
+- 把探索、增长、平台重构同时塞进一个小版本。
+
+## 3. 老板或关键相关方临时插需求
+
+**核心判断**：这是战略信号、业务承诺、权力覆盖，还是临时焦虑。
+
+先判断：
+
+- 对方真正关心收入、留存、客户承诺、合规、声量，还是展示。
+- 为什么现在急。
+- 插入后要挤掉什么。
+- 这个需求是否可逆，是否能用小版本验证。
+
+建议：
+
+- 先承接目标，不直接承诺方案。
+- 给三个选择：现在做但砍掉某项；先做 1-2 天验证；进入下个版本。
+- 用一页纸写清代价：延期、砍需求、风险、影响指标。
+- 如果必须做，压到最小可上线闭环。
+
+不要：
+
+- 只说“不行”。
+- 默默吞下范围，最后毁掉版本。
+- 把优先级冲突伪装成体验讨论。
+
+## 4. 用户研究与产品探索
+
+**核心判断**：现在要验证的是问题是否真实，不是方案是否漂亮。
+
+先判断：
+
+- 目标用户是谁，真实场景是什么。
+- 用户现在如何解决，成本在哪里。
+- 用户是否愿意付出时间、钱、关系或数据。
+
+建议：
+
+- 用 5-10 个目标用户做深访，必须看真实操作或真实记录。
+- 访谈后输出用户任务、当前替代方案、痛点强度、付费或使用信号。
+- 能人工服务就先人工服务，不急着做系统。
+
+不要：
+
+- 用泛问卷代替一线观察。
+- 只问“你会不会用”，不看用户现在怎么做。
+
+## 5. 增长停滞
+
+**核心判断**：增长被拉新、激活、留存、转化、复购/分享、渠道饱和中的哪一环卡住。
+
+先判断：
+
+- 拆增长树：流量、激活、留存、转化、复购、分享。
+- 按 cohort 和渠道看变化。
+- 示例拆法：按渠道 cohort 看“新用户注册 -> 激活 -> D7 留存 -> 付费 -> 分享”，找最先掉下来的环节。
+- 判断是新用户质量变差，还是产品循环变弱。
+
+建议：
+
+- 先修最弱的一环。
+- 激活弱，先修第一次价值体验，再买量。
+- 留存弱，先停掉无效放量。
+- 渠道饱和，再测相邻渠道，但要明确人群和卖点。
+
+不要：
+
+- 把增长等同于多做活动。
+- 留存或激活没修好就加大投放。
+
+## 6. 拉新、投放与 CAC 上升
+
+**核心判断**：CAC 上升通常不是单纯投放问题，而是渠道、人群、承诺和承接效率共同变化。
+
+先判断：
+
+- 哪些渠道 CAC 上升，哪些 cohort 后续留存或付费变差。
+- 创意承诺和产品实际价值是否不匹配。
+- 是否已经触达原有渠道的高质量人群上限。
+
+建议：
+
+- 暂停 ROI 最差且留存最差的人群包。
+- 对高意向人群重测卖点，不先扩大预算。
+- 用 7 日或 14 日 cohort 判断渠道质量，而不只看注册成本。
+
+不要：
+
+- 用更大补贴掩盖承接差。
+- 只优化素材点击率，不看后链路质量。
+
+## 7. 激活与首次价值
+
+**核心判断**：用户注册后没有快速到达第一次价值体验。
+
+先判断：
+
+- 新用户第一次成功行为是什么。
+- 从注册到该行为有几步、最大掉点在哪里。
+- 不同渠道和设备的新用户是否掉在同一步。
+
+建议：
+
+- 把首次价值路径压到最短，优先砍非必要字段和选择。
+- 对关键人群做引导、默认样例、人工辅助或新手任务。
+- 用激活率、首次价值用时、D1/D7 留存联动判断。
+
+不要：
+
+- 新用户还没感到价值，就做复杂会员、积分或社交体系。
+
+## 8. DAU 或流量下滑
+
+**核心判断**：下滑来自新用户、老用户、使用频次、内容供给、渠道、版本、季节性，还是埋点。
+
+先判断：
+
+- 拆新老用户、渠道、平台、地域、版本、cohort。
+- 查发布记录、埋点变更、Push 策略、内容供给、分发规则、外部渠道变化。
+- 区分一次性冲击和持续趋势。
+
+建议：
+
+- 先排除数据口径和技术问题。
+- 找贡献下滑最大的用户群或渠道。
+- 对最大贡献段做恢复动作，不做全站泛活动。
+- 急性下滑设置 24-72 小时监控窗口。
+
+不要：
+
+- 只看总 DAU。
+- 没确认来源就上线新功能或全站活动。
+
+## 9. 留存下降
+
+**核心判断**：用户没有到达价值、价值不再重复，还是引入了更差的新 cohort。
+
+先判断：
+
+- 按渠道、人群、版本、首个关键行为拆 cohort 留存。
+- 看掉点发生在首次价值前、首次价值后，还是长期使用中。
+- 找目标 cohort 的行为路径和反馈。
+
+建议：
+
+- 早期留存掉，修 onboarding 和第一次价值。
+- 中后期留存掉，修内容/供给新鲜度、核心任务深度或习惯触发。
+- 渠道 cohort 变差，调整投放人群和承诺。
+
+不要：
+
+- 用 Push 硬拉留存。
+- 把短期活跃技巧当长期价值。
+
+## 10. 转化问题
+
+**核心判断**：阻塞来自流量质量、价值表达、信任、价格、流程摩擦，还是时机不对。
+
+先判断：
+
+- 找漏斗最大异常掉点。
+- 比高意向和低意向用户。
+- 看客服、销售、退款、用户访谈里的真实反对理由。
+
+建议：
+
+- 价值没讲清，先修表达。
+- 信任不足，先补证明和保障。
+- 价格犹豫，先修套餐和锚点，不先乱打折。
+- 每次只测一个关键摩擦。
+
+不要：
+
+- 不知道掉点就重做全漏斗。
+- 用优惠掩盖价值不清。
+
+## 11. 商业化、会员与定价
+
+**核心判断**：用户愿意付费的价值点、付费时机和套餐边界没有被验证清楚。
+
+先判断：
+
+- 付费对象是个人、团队、商家还是企业。
+- 用户买的是效率、确定性、身份、权益、资源，还是风险降低。
+- 价格阻力来自价值不清、预算不足、信任不足，还是套餐设计不合理。
+
+建议：
+
+- 先找最有支付意愿的细分人群做小范围验证。
+- 套餐只围绕 1-2 个核心价值分层，不堆权益。
+- 设置退款、续费、使用深度作为护栏。
+
+不要：
+
+- 在价值没验证前做复杂会员体系。
+- 为了短期收入透支核心体验或信任。
+
+## 12. 活动效果差
+
+**核心判断**：活动失败在目标人群、利益点、时机、渠道，还是参与路径。
+
+先判断：
+
+- 拆曝光、点击、参与、转化、复访。
+- 找用户第一次没有按预期行动的节点。
+- 判断奖励是否匹配用户动机。
+
+建议：
+
+- 修正一个关键假设后小范围重跑。
+- 按人群保留学习，不要只看总结果。
+- 如果只带来低质量用户，停止放大。
+
+不要：
+
+- 用一次活动失败证明“用户不喜欢活动”。
+- 没修相关性就提高奖品成本。
+
+## 13. 社区冷启动
+
+**核心判断**：第一批用户为什么回来互动，这个循环是否成立。
+
+先判断：
+
+- 种子用户是谁。
+- 用户获得身份、关系、实用价值、交易机会，还是情绪陪伴。
+- 网络效应没起来前，谁来提供内容和回应。
+
+建议：
+
+- 从一个窄人群或窄话题开始。
+- 手工种高质量内容和互动。
+- 给早期用户可见反馈、身份感或即时收益。
+- 看重复参与，不看注册数。
+
+不要：
+
+- 功能做很全但场子是空的。
+- 邀很多泛用户进来。
+
+## 14. 内容供给不足
+
+**核心判断**：供给不足是创作者动力、选题方向、生产成本、分发反馈还是质量标准的问题。
+
+先判断：
+
+- 按创作者层级、题材、频率、质量、分发效果拆。
+- 问清创作者为什么停更：没流量、没收益、标准不清、太费劲、工具差。
+
+建议：
+
+- 先定义对留存最关键的内容坑位。
+- 只招募或补贴能填这个坑位的创作者。
+- 降低生产成本，快速给反馈。
+- 先建质量底线，再扩数量。
+
+不要：
+
+- 没定义有效供给就疯狂拉创作者。
+- 用数量激励破坏质量。
+
+## 15. 用户运营与私域
+
+**核心判断**：运营动作是否改变了关键用户行为，而不是只增加触达次数。
+
+先判断：
+
+- 运营目标是激活、复购、续费、召回、转介绍，还是服务。
+- 用户是否有回来的理由和承接内容。
+- 群、企微、短信、Push 是否对同一用户过度触达。
+
+建议：
+
+- 先围绕一个关键行为设计运营链路。
+- 把用户按价值、生命周期、意图分层，不群发同一话术。
+- 用转化、复访、退订、投诉作为共同指标。
+
+不要：
+
+- 把私域当免费流量池。
+- 用频繁触达替代价值供给。
+
+## 16. 指标异常与数据冲突
+
+**核心判断**：这是用户行为变化，还是口径、埋点、同步、归因问题。
+
+排查顺序：
+
+1. 指标定义或埋点是否改过。
+2. 数据延迟、去重、归因、ETL 是否异常。
+3. 产品发布或实验是否影响。
+4. 渠道或用户结构是否变化。
+5. 是否真有行为变化。
+
+建议：
+
+- 先统一口径和事实表。
+- 用原始日志、不可变指标或第三方数据校验。
+- 给出置信度和对决策的影响。
+
+不要：
+
+- 还没统一定义就争论仪表盘。
+- 基于可能坏掉的指标直接行动。
+
+## 17. A/B Test 结果异常
+
+**核心判断**：结果是否有效、可解释、值得决策。
+
+先判断：
+
+- 样本量、随机分流、曝光、护栏指标、季节性、重叠实验、埋点一致性。
+- 分人群是否方向一致。
+
+建议：
+
+- 实验设计有问题，修正后重跑。
+- 主指标赢但护栏伤害大，不直接全量。
+- 只有特定人群赢，就只对该人群灰度。
+
+不要：
+
+- 看完数据再选自己喜欢的解释。
+- 用点击率替代业务结果。
+
+## 18. 用户反馈互相冲突
+
+**核心判断**：哪个反馈来自当前最重要的用户群和行为场景。
+
+先判断：
+
+- 用户分层：付费、高频、高潜、低频、流失。
+- 反馈代表痛点、偏好、边缘场景，还是战略信号。
+- 反馈是否有行为证据支撑。
+
+建议：
+
+- 按用户价值、目标人群和行为证据加权。
+- 示例：高价值付费用户的反馈权重应高于声音大的边缘用户；高频行为证据高于一次性吐槽。
+- 把冲突反馈转成不同人群的产品选择。
+- 如果冲突来自定位不清，先收窄产品承诺。
+
+不要：
+
+- 平均所有反馈。
+- 被声音最大的边缘用户带偏。
+
+## 19. 竞品冲击
+
+**核心判断**：竞品打的是核心价值、渠道、价格、信任，还是用户心智。
+
+先判断：
+
+- 哪些用户在转移，为什么转移。
+- 竞品优势是否可持续。
+- 竞品在哪些场景看起来强但其实不适配。
+
+建议：
+
+- 先防守自己的核心场景。
+- 不复制功能清单，只学习改变用户选择的机制。
+- 找自己优势更尖锐的人群加深。
+
+不要：
+
+- 在对手最强的战场硬拼。
+- 把 Roadmap 变成竞品反应清单。
+
+## 20. 资源不足
+
+**核心判断**：最稀缺资源应该投到哪个结果杠杆上。
+
+先判断：
+
+- 稀缺的是研发、设计、运营、预算、数据、法务，还是管理层注意力。
+- 哪些工作要停止、延期、降级或人工处理。
+
+建议：
+
+- 先砍范围，再谈加班。
+- 保护一个决定性结果。
+- 能用人工或低代码验证的，不先消耗研发。
+
+不要：
+
+- 用更少的人继续承诺同样 Roadmap。
+- 把关键岗位拆散到一堆低价值任务。
+
+## 21. 项目延期
+
+**核心判断**：延期来自范围、依赖、质量风险、决策延迟，还是隐藏工作。
+
+先判断：
+
+- 关键路径、阻塞人、范围变化、未决事项、验收标准。
+- 截止时间、范围、质量、资源哪个可以调整。
+
+建议：
+
+- 围绕关键路径重排计划。
+- 冻结范围或拆版本。
+- 提前给四种选择：小版本上线、延期、加资源、接受风险。
+
+不要：
+
+- 加会议但不改变权限和范围。
+- 到 deadline 才暴露延期。
+
+## 22. 需求反复修改与范围失控
+
+**核心判断**：问题不是大家想法多，而是问题定义、验收标准和变更代价没有锁住。
+
+先判断：
+
+- 每次修改是在改目标、改方案、改验收，还是补遗漏。
+- 谁有权改变范围，改变后挤掉什么。
+- 变更是否来自真实用户证据或只是会议偏好。
+
+建议：
+
+- 先锁问题定义和成功指标，再讨论方案。
+- 建立变更规则：新增必须替换同等工作量或进入下个版本。
+- 把已决事项、未决事项、变更代价写在同一页。
+
+不要：
+
+- 每次评审都重新打开方向讨论。
+- 用“敏捷”包装无边界变更。
+
+## 23. 跨部门协作
+
+**核心判断**：团队之间没对齐的是目标、优先级、激励、权限，还是信息。
+
+先判断：
+
+- 谁背结果。
+- 谁承担成本。
+- 各团队分别优化什么指标。
+- 哪个决策没有明确负责人。
+
+建议：
+
+- 先对齐共同结果和决策人。
+- 把抽象冲突变成取舍选项。
+- 用小试点降低对方风险。
+
+不要：
+
+- 把激励冲突说成沟通问题。
+- 只要求配合，却不降低对方真实成本。
+
+## 24. 团队冲突
+
+**核心判断**：冲突来自目标、方法、资源、边界、信任，还是能力表现。
+
+先判断：
+
+- 区分事情冲突和人际冲突。
+- 权责是否匹配。
+- 大家一直绕开的真实决策是什么。
+
+建议：
+
+- 把真实决策摆出来。
+- 先约定决策规则，再讨论方案。
+- 信任受损时，用短周期承诺和可观察结果修复。
+
+不要：
+
+- 强行制造表面和谐。
+- 只批评个人，不改协作机制。
+
+## 25. OKR/KPI 与目标拆解
+
+**核心判断**：目标是否是团队能影响的结果。
+
+先判断：
+
+- 滞后指标和前置指标。
+- 可控部分和不可控部分。
+- 每个团队对目标的贡献路径。
+
+建议：
+
+- 只选一个主业务结果或北极星指标。
+- 用驱动树拆目标。
+- 给前置指标配负责人和复盘节奏。
+- 设置停止标准和预警线。
+
+不要：
+
+- 把 OKR 写成任务清单。
+- 给所有团队同一个高层 KPI，但不拆贡献逻辑。
+
+## 26. 复盘
+
+**核心判断**：哪条关键假设错了，下次机制怎么变。
+
+先判断：
+
+- 预期和实际差在哪里。
+- 错的是用户、渠道、产品、执行、数据、相关方，还是时机。
+- 有没有早期信号，为什么没被看到或没被处理。
+
+建议：
+
+- 只抓 1-3 个根因。
+- 每个根因对应一个机制改变和负责人。
+- 保留有效做法，不要把复盘写成全盘否定。
+
+不要：
+
+- 停在“沟通不够”。
+- 没有机制变化的复盘等于没复盘。
+
+## 27. 大客户定制需求
+
+**核心判断**：大客户需求首先是收入机会、交付承诺和产品复用性的取舍。
+
+先判断：
+
+- 合同金额、上线期限、违约风险和销售承诺。
+- 同类客户数量、复用概率、维护成本。
+- 需求是通用能力、配置项、一次性交付，还是专属服务。
+
+建议：
+
+- 把需求拆成产品化、配置化、交付服务三类。
+- 只把高复用能力进 Roadmap。
+- 专属部分要收费、限期、限维护范围。
+
+不要：
+
+- 让单个客户直接改写产品主线。
+- 简单拒绝收入机会而不给替代交付方案。
+
+## 28. 发布事故、评分下滑与质量问题
+
+**核心判断**：先判断问题影响范围和是否需要回滚，再谈体验优化。
+
+先判断：
+
+- 影响哪些版本、设备、渠道、关键路径和核心用户。
+- 是功能 bug、性能问题、预期落差、客服响应，还是灰度策略问题。
+- 是否正在造成收入、留存、口碑或合规损失。
+
+建议：
+
+- 先止血：回滚、降级、热修、公告或客服脚本。
+- 24 小时内建立版本、设备、路径、反馈的对应表。
+- 修复后看负评率、崩溃率、关键路径完成率。
+
+不要：
+
+- 先争论责任。
+- 影响核心链路时还等下个大版本。
+
+## 29. Push、消息与用户打扰
+
+**核心判断**：消息触达正在透支用户信任，还是核心提醒没有被正确分层。
+
+先判断：
+
+- 哪些消息带来留存或转化，哪些只带来退订、卸载和投诉。
+- 用户意图、生命周期和频控是否区分。
+- 推送内容是否有真实价值承接。
+
+建议：
+
+- 先停掉低价值高退订消息。
+- 把消息分成交易/服务提醒、内容召回、营销转化三类管理。
+- 用 opt-out、卸载、打开后行为作为护栏。
+
+不要：
+
+- 用更高频次弥补内容或价值不足。
+
+## 30. 平台供给质量与信任
+
+**核心判断**：供给质量低于用户信任底线，会先破坏核心循环，再影响增长。
+
+先判断：
+
+- 哪类供给造成最多退款、投诉、差评或流失。
+- 质量问题来自准入、审核、履约、评价、分发还是激励。
+- 哪些品类或场景必须先守住底线。
+
+建议：
+
+- 先定义质量底线和红线场景。
+- 对最影响信任的品类先准入、抽检、降权或清退。
+- 把优质供给的曝光和收益绑定到质量指标。
+
+不要：
+
+- 在质量底线没守住时继续拉供给数量。
+
+## 31. 风控、作弊与滥用
+
+**核心判断**：作弊上升会改变用户、商家或平台激励，必须先稳住信任和成本。
+
+先判断：
+
+- 作弊影响收入、补贴、内容质量、交易安全还是账号生态。
+- 黑产路径、受益对象、成本承担者是谁。
+- 当前规则是否误伤正常用户。
+
+建议：
+
+- 先保护核心链路和高风险人群。
+- 用规则、模型、人工审核和限额分层处理。
+- 设置误伤率、拦截率、申诉率作为护栏。
+
+不要：
+
+- 只追求拦截率，伤害正常用户。
+- 风险没稳住就继续加补贴。
+
+## 32. 内部工具 adoption 低
+
+**核心判断**：工具没有进入真实工作流，或没有解决使用者的激励和成本问题。
+
+先判断：
+
+- 使用者原来怎么完成任务，新工具增加还是减少步骤。
+- 经理想要的价值和一线员工想要的价值是否一致。
+- 是否缺培训、数据、权限、集成或强制场景。
+
+建议：
+
+- 跟 3-5 个真实用户 shadow 一次完整流程。
+- 先打通一个高频任务，不做全功能平台。
+- 找一个团队做试点，用节省时间、错误率、完成率判断。
+
+不要：
+
+- 把低使用归因于“不愿学习”。
+
+## 33. AI 功能或技术热点
+
+**核心判断**：先确认用户问题和业务结果，不要从技术能力反推需求。
+
+先判断：
+
+- AI 解决的是效率、质量、成本、转化、风控，还是只是展示。
+- 目标用户是否愿意把关键任务交给 AI。
+- 输出错误的成本和人工兜底方式是什么。
+
+建议：
+
+- 先用人工或半自动方式验证任务价值。
+- 选低风险、高频、可校验的场景做 MVP。
+- 指标看任务完成率、节省时间、采纳率、错误成本。
+
+不要：
+
+- 为了“有 AI”改 Roadmap。
+- 不要先有 AI 能力再去找场景；先找高频、高成本、可校验的用户任务。
+- 在高风险任务上没有兜底就全量。
+
+## 34. 合规、法务与硬截止
+
+**核心判断**：硬约束会覆盖普通优先级，但仍要控制范围。
+
+先判断：
+
+- 截止时间、处罚风险、最低合规要求和可延期部分。
+- 哪些能力必须上线，哪些只是锦上添花。
+- 是否影响核心用户路径或收入。
+
+建议：
+
+- 先做最低可合规版本。
+- 明确被挤掉的需求和业务影响。
+- 合规上线后再补体验和自动化。
+
+不要：
+
+- 把合规需求和普通需求放同一评分表。
+- 借合规名义扩成大重构。
+
+## 35. 出海、本地化与新市场
+
+**核心判断**：新市场失败通常不是翻译问题，而是渠道、信任、支付、供给和使用场景不匹配。
+
+先判断：
+
+- 哪个国家/地区、哪类人群、哪个场景先打。
+- 本地获客渠道、支付习惯、信任背书、合规要求。
+- 原有核心价值是否仍然成立。
+
+建议：
+
+- 只选一个市场和一个场景做验证。
+- 找本地渠道和用户样本，不用国内经验硬套。
+- 先验证渠道-卖点-产品承接，再规模投入。
+
+不要：
+
+- 同时铺多个国家。
+- 把本地化等同于语言翻译。
+
+## 36. 战略转向与业务模式选择
+
+**核心判断**：是否转向，不看新方向多诱人，而看旧方向的核心假设是否被证伪、新方向是否有更强证据。
+
+先判断：
+
+- 旧方向失败的是用户需求、商业模式、渠道、供给、组织能力，还是时机。
+- 新方向有没有真实用户、付费信号、可复用能力和资源匹配。
+- 转向会丢掉哪些资产和用户。
+
+建议：
+
+- 先写一页决策备忘录：旧假设、证据、新假设、验证计划、停止标准。
+- 用 2-4 周验证新方向的一个核心假设，不直接全团队切换。
+- 明确转向代价：放弃的用户、沉没资产、团队能力缺口和短期收入影响。
+- 保留旧方向中可迁移的用户、数据、技术和渠道资产。
+- 给旧方向设一个清晰的停止标准，避免两边同时消耗资源。
+
+不要：
+
+- 因为短期焦虑频繁换方向。
+- 因为新方向热闹就全面转向。
+- 在没有真实用户信号前，把原 Roadmap 全部砍掉。
+- 没有停止标准就同时做两条主线。
diff --git a/skills/product-decision-agent/references/reasoning-engine.md b/skills/product-decision-agent/references/reasoning-engine.md
new file mode 100644
index 000000000..ac152afb8
--- /dev/null
+++ b/skills/product-decision-agent/references/reasoning-engine.md
@@ -0,0 +1,289 @@
+# 产品决策推理引擎
+
+当用户的问题复杂、信息不足、症状很多、内部意见冲突或涉及资源取舍时，读取本文件。这里是后台工作手册，最终回答仍要转成中文产品语言，不要暴露方法来源。
+
+## 目录
+
+1. 决策闭环
+2. 事实与假设
+3. 核心阻塞
+4. 主导机制与变化条件
+5. 阶段判断
+6. 证据质量与充分性
+7. 用户、相关方与冲突形式
+8. 行动模式
+9. 实验与验证
+10. 资源集中与停止清单
+11. 输出组装
+12. 常见误判
+
+## 1. 决策闭环
+
+后台按这个顺序想：
+
+1. **目标**：用户到底想改变哪个结果。
+2. **现象**：表面症状是什么，是否只是用户的说法。
+3. **机制**：是什么用户行为、产品机制、市场变化、数据口径或组织机制导致了现象。
+4. **核心阻塞**：当前最决定结果的瓶颈是什么。
+5. **主导机制**：核心阻塞内部，哪项力量、行为或规则当前主导结果。
+6. **阶段**：产品、业务、项目或团队处在哪个阶段。
+7. **约束**：资源、时间、权限、供给、流量、信任、数据、激励中哪个最硬。
+8. **相关方**：谁背结果、谁执行、谁否决、谁承担成本、谁受益。
+9. **证据**：来源是否可靠，哪些事实够用，哪些只是推断，哪些必须验证。
+10. **变化条件**：什么信号出现时加码、停止、回滚或换打法。
+11. **行动**：现在该决策、诊断、验证、排序、谈判、停止还是升级。
+12. **复盘信号**：用什么指标或事实判断下一步有效。
+
+不要把这 12 步原样输出给用户，除非用户明确要求方法框架。
+
+## 2. 事实与假设
+
+先把信息分成四类：
+
+- **硬事实**：已发生的行为、数据、上线记录、合同、资源、截止时间。
+- **一线材料**：用户原话、客服/销售反馈、运营观察、研发阻塞、真实使用路径。
+- **判断假设**：用户或团队对原因的解释。
+- **解决方案诉求**：别人已经提出的功能、活动、投放、流程或组织动作。
+
+处理原则：
+
+- 不把“用户说想要功能”直接当成需求，要追到场景、行为和结果。
+- 不把“老板说要做”直接当成优先级，要追到业务压力和代价。
+- 不把“数据涨跌”直接当成业务结论，要先查口径、分层和贡献段。
+- 信息不足时，不要追问一堆问题；先给基于当前信息的判断，再给最小取证动作。
+- 不照搬行业案例或所谓最佳实践；先检查案例前提是否和当前人群、阶段、渠道、资源一致。
+- 不用少量高声量反馈代替行为证据，也不因只有数据就忽略真实操作路径。
+
+## 3. 核心阻塞
+
+一个问题可以被判定为核心阻塞，通常满足至少两条：
+
+- 解决它，多个其他问题会随之缓解。
+- 不解决它，其他优化效果都很弱。
+- 它解释了为什么之前的办法没用。
+- 它离用户行为或业务结果足够近，而不是内部偏好。
+- 它在用户当前权限或可升级范围内能被改变。
+
+好的表述：
+
+- “新用户没有在 10 分钟内到达第一次价值体验。”
+- “内容供给不稳定，导致留存动作没有承载物。”
+- “团队还没确认真正愿意付费的目标人群，就在优化付费按钮。”
+- “Roadmap 争论本质是资源分配冲突，不是功能排序冲突。”
+
+差的表述：
+
+- “体验不好。”
+- “数据要完善。”
+- “团队要协同。”
+- “需要做增长。”
+
+## 4. 主导机制与变化条件
+
+找到核心阻塞后，再判断是什么在阻塞内部主导结果。这一步防止把两个相关现象直接拼成因果。
+
+常见的主导机制：
+
+- **供需关系**：是有效需求不足，还是供给数量、质量或稳定性不足。
+- **价值与摩擦**：是用户没有感知价值，还是路径、价格、信任、性能阻止用户到达价值。
+- **增量与承接**：是流量不足，还是激活、留存、履约能力接不住流量。
+- **目标与激励**：是团队不知道做什么，还是知道但考核、权责、成本结构让其不愿做。
+- **规则与行为**：是个别执行问题，还是流程、分配、准入或决策规则持续制造同类问题。
+
+然后写出变化条件：
+
+- 哪个指标或事实改变，说明主导机制已切换。
+- 哪个阈值出现，应该加码、停止、回滚或升级。
+- 哪个依赖解除后，下一优先级才有意义。
+- 当前只是随机波动、持续积累，还是已经跨过会改变产品阶段或用户行为的阈值。
+- 哪个领先指标能在结果指标明显恶化前发出信号。
+
+例：社区 DAU 下滑的核心阻塞可能是内容供给，但真正主导结果的是核心创作者连续流失。只有创作者周留存和有效内容量恢复后，拉新活动才值得重启。
+
+## 5. 阶段判断
+
+同一个动作在不同阶段价值完全不同。先判断阶段，再给方案。
+
+| 阶段 | 关键问题 | 优先动作 | 常见坑 |
+|---|---|---|---|
+| 探索期 | 问题是否真实存在 | 访谈、观察、人工服务、问题验证 | 太早做完整产品 |
+| 验证期 | 用户是否愿意用或付费 | MVP、原型、烟囱测试、灰度 | 没证明价值就优化体验 |
+| PMF 寻找期 | 哪个细分人群和场景会重复使用 | 收窄人群、打深核心链路 | 过早扩品类扩人群 |
+| 增长期 | 哪个渠道或循环可放大 | 聚焦增长实验、建立节奏 | 多渠道平均用力 |
+| 规模化期 | 系统和组织能否承载规模 | 标准化、自动化、稳定性 | 继续靠人工救火 |
+| 成熟优化期 | 边际 ROI 最高在哪里 | 漏斗、留存、定价、效率优化 | 追新概念 |
+| 危机期 | 先止住哪类损失 | 止血、保护核心用户、重排优先级 | 照常执行 Roadmap |
+| 组织对齐期 | 谁需要改变行为 | 权责、激励、依赖、决策机制 | 把人和激励问题当成功能问题 |
+
+阶段不明确时，先说明阶段假设，再问一个会改变判断的问题。
+
+## 6. 证据质量与充分性
+
+先判断证据来源，再判断数量是否足够：
+
+1. **直接行为与结果**：交易、留存、日志、录屏、真实任务完成情况。
+2. **一线材料**：用户访谈、客服工单、销售记录、运营观察、研发阻塞记录。
+3. **可追溯汇总**：口径明确、能回到原始事件的数据和研究结论。
+4. **二手判断**：会议转述、老板印象、竞品故事、行业文章。
+5. **孤立个案**：单个强烈反馈或未经核验的异常样本。
+
+关键决策尽量让不同来源互相印证。证据冲突时，先查定义、人群、时间窗口和采集链路，不做平均折中。
+
+### 足够行动
+
+适用：动作低风险、可回滚，或证据已经明显指向一个方向。
+
+输出：明确建议、取舍、时间窗口、复盘指标。
+
+### 需要快速验证
+
+适用：方向可能对，但不确定性会影响投入。
+
+输出：1 天到 1 个迭代内能产生决策证据的小实验。
+
+### 需要先诊断
+
+适用：同一个现象可能由多个机制导致，贸然行动成本高。
+
+输出：窄口径诊断，不做泛调研。
+
+只问会改变决策的问题：
+
+- 目标用户或目标客户是谁。
+- 当前基线指标和趋势是什么。
+- 漏斗最大掉点在哪一步。
+- 可用资源和硬截止时间是什么。
+- 决策人、执行人、否决人是谁。
+- 过去试过什么，为什么没成。
+
+## 7. 用户、相关方与冲突形式
+
+### 用户分层
+
+按对结果的影响排序，不按声音大小排序：
+
+- 高价值付费用户。
+- 高频核心用户。
+- 高潜转化用户。
+- 供给侧关键用户，如创作者、商家、达人、服务商。
+- 新用户和流失用户。
+- 边缘低频用户。
+
+反馈冲突时，按目标人群、行为证据、商业价值、战略阶段加权。
+
+### 相关方地图
+
+组织协作类问题要先看人和目标：
+
+- **结果负责人**：最终背指标或业务结果的人。
+- **执行负责人**：真正要做事的人。
+- **否决人**：能卡住推进的人。
+- **受益人**：成功后获得收益的人。
+- **成本承担者**：承担时间、预算、信誉、运维成本的人。
+- **中间人群**：没有强反对，但需要证据争取的人。
+
+对齐动作不是“加强沟通”，而是：
+
+- 把方案连接到对方指标。
+- 降低对方成本或风险。
+- 做可回滚的小试点。
+- 让取舍和后果可见。
+- 区分原则问题和执行细节。
+
+不同冲突要用不同处理方式：
+
+- 数据冲突：统一口径并回到原始记录。
+- 资源冲突：公开取舍、挤出项和决策人。
+- 目标冲突：先确认共同结果，再谈方案。
+- 权责冲突：明确谁拍板、谁承担后果，必要时升级。
+- 假设冲突：用最小实验取证，不靠会议投票。
+- 硬约束冲突：先满足合规、安全、现金流或交付底线，再优化体验。
+
+## 8. 行动模式
+
+每次优先选择一个主模式，不要什么都说一点。
+
+| 模式 | 适用情况 | 输出重点 |
+|---|---|---|
+| 立即决策 | 事实足够，风险可控 | 明确建议、取舍和代价 |
+| 快速验证 | 主要不确定性是用户反应或 ROI | MVP、A/B、灰度、人工验证 |
+| 先诊断 | 根因不明 | 指标拆解、用户样本、日志或口径检查 |
+| 排序 | 多件事都重要但资源不够 | 顺序、依赖、停止清单 |
+| 谈判对齐 | 相关方冲突阻塞推进 | 相关方地图、共同目标、底线和替代方案 |
+| 停止投入 | 继续做只会消耗资源 | 停止标准、沉没成本处理、对外说法 |
+| 升级决策 | 权限和责任不匹配 | 决策备忘录、升级路径、需拍板事项 |
+
+## 9. 实验与验证
+
+好的验证要“小、快、能改决策”。
+
+必须说清：
+
+- 假设是什么。
+- 目标人群是谁。
+- 在哪里验证。
+- 最小实现方式是什么。
+- 成功指标是什么。
+- 失败指标是什么。
+- 持续多久或需要多少样本。
+- 结果出来后怎么决策。
+
+优先选择：
+
+- 人工服务先于平台化建设。
+- 落地页或烟囱测试先于完整功能。
+- 分 cohort 留存先于总量活跃。
+- 手工运营先于自动化。
+- 灰度先于全量。
+- 小范围真实客户试点先于全公司流程改造。
+
+不要做无法改变决策的实验。
+
+## 10. 资源集中与停止清单
+
+资源不足时，优先一个决定性动作加一个取证动作。
+
+判断维度：
+
+1. **结果杠杆**：是否直接影响目标指标。
+2. **阶段匹配**：是否符合当前阶段。
+3. **约束解除**：是否解决核心阻塞。
+4. **证据强度**：是否有数据、用户行为、失败经验支撑。
+5. **执行成本**：人力、时间、复杂度、依赖。
+6. **可逆性**：能否低成本回滚或学习。
+
+停止清单常见对象：
+
+- 当前阶段无法证明价值的完整平台建设。
+- 没有承接能力的投放和补贴。
+- 只为单个低复用客户做的产品主线改造。
+- 没有成功/失败标准的 A/B Test。
+- 没有负责人和代价说明的临时插入需求。
+- 只制造短期数据噪音的全站活动。
+
+## 11. 输出组装
+
+默认输出：
+
+1. **问题判断**：一句话指出真正问题。
+2. **原因分析**：2-4 条，解释为什么是这个问题。
+3. **行动建议**：1-3 个动作，包含时间、对象、指标或决策口径。
+4. **风险提醒**：现在不要做什么。
+5. **需要确认**：最多 3 个，只问会改变判断的事实。
+
+短答也要保留“判断 + 下一步”。不要把内部框架完整讲出来。
+
+## 12. 常见误判
+
+- 把症状当原因。
+- 找到核心阻塞后，没有继续判断当前真正主导结果的机制。
+- 用二手汇报、行业故事或单个高声量反馈代替可追溯证据。
+- 等所有数据齐了才敢判断。
+- 用户还没到达价值，就开始优化转化。
+- 一个细分场景没打透，就扩人群扩功能。
+- 看到竞品动作就复制，不知道对方改变了什么用户选择。
+- 把激励冲突说成沟通问题。
+- 做最好做的需求，而不是最能改变结果的需求。
+- 样本量、埋点或假设都不可靠时硬跑 A/B Test。
+- 复盘只写责任和态度，不改变机制。
+- 用英文咨询腔回答中文工作问题。
diff --git a/skills/product-decision-agent/references/response-examples.md b/skills/product-decision-agent/references/response-examples.md
new file mode 100644
index 000000000..e83a98e25
--- /dev/null
+++ b/skills/product-decision-agent/references/response-examples.md
@@ -0,0 +1,279 @@
+# 中文输出样例
+
+用于校准口吻。不要机械复制，要保持“资深产品负责人”的判断感：直接、具体、能执行。默认不要暴露方法来源。
+
+## 样例 1：老板插需求
+
+用户：老板临时要我们下周加一个会员积分商城，但这个版本本来在做新手转化，我该怎么处理？
+
+回答：
+
+**问题判断**
+这不是简单插需求，而是版本目标和临时业务压力之间的资源冲突。
+
+**原因分析**
+
+- 当前版本目标是新手转化，积分商城更偏留存或商业化，目标不一致。
+- 直接塞进去会同时降低转化方案质量和积分商城交付质量。
+- 真正要确认的是老板在解决收入、留存、客户承诺，还是阶段性展示。
+
+**行动建议**
+
+1. 今天给老板一个三选一方案：保持原版本；用 2 天做积分商城原型验证；砍掉一个转化需求换积分商城最小版本。
+2. 把被替换的工作、延期风险、影响指标写在同一页。
+3. 如果必须上线，先做“入口 + 单品兑换 + 人工履约”，不要做完整商城。
+
+**风险提醒**
+不要默默接受全部范围。两个目标都做，最后两个目标都证明不了。
+
+## 样例 2：DAU 下滑
+
+用户：我们社区 DAU 连续两周下降 15%，运营觉得要加活动拉回来。
+
+回答：
+
+**问题判断**
+先不要用活动拉 DAU，当前最关键的是确认下滑来自哪类用户和哪个环节。
+
+**原因分析**
+
+- 连续两周下降 15% 已经不像普通波动。
+- 社区 DAU 可能受新用户、老用户、内容供给、分发规则、Push、版本问题影响。
+- 没拆来源就做活动，只会制造短期噪音，掩盖真正原因。
+
+**行动建议**
+
+1. 24 小时内按新老用户、渠道、平台、版本、核心内容供给拆下降贡献。
+2. 找贡献最大的 1-2 个群体，看行为路径和最近反馈。
+3. 如果是老用户下降，先做召回和内容修复；如果是渠道下降，再做拉新活动。
+
+**风险提醒**
+不要先上全站活动，也不要看总 DAU 做判断。
+
+## 样例 3：用户反馈冲突
+
+用户：付费用户说功能太复杂，免费用户说功能不够强，我们到底该听谁？
+
+回答：
+
+**问题判断**
+这不是反馈互相打架，而是当前优先服务的用户层级还没定清楚。
+
+**原因分析**
+
+- 付费用户的复杂度反馈直接影响续费和留存。
+- 免费用户要更强功能，不一定代表会付费或高频使用。
+- 同时满足两边，产品容易变得既复杂又不够强。
+
+**行动建议**
+
+1. 本周把用户分成高价值付费、高活跃免费、低活跃免费三组，看留存和转化。
+2. 本版本优先降低付费用户完成核心任务的复杂度。
+3. 对免费用户只开放一个高需求能力的轻量试用，用转化率决定是否加深。
+
+**风险提醒**
+不要用投票决定路线。反馈要按用户价值和行为证据加权。
+
+## 样例 4：A/B Test 点击率上涨但订单不涨
+
+用户：A/B Test 显示新版按钮点击率高 12%，但下单率没变，要不要全量？
+
+回答：
+
+**问题判断**
+暂时不要全量，新版只证明了更多点击，没有证明更多订单。
+
+**原因分析**
+
+- 点击率提升可能只是按钮更显眼，不代表购买意愿更强。
+- 下单率不变说明核心阻塞在点击之后，可能是价格、信任、库存或支付流程。
+- 如果全量，可能会增加无效点击和后链路负担。
+
+**行动建议**
+
+1. 今天拆点击后的商品页停留、加购、支付发起、支付成功。
+2. 如果后链路没有改善，保留新版为入口素材，但不把它当成转化成功。
+3. 下一轮实验直接测试点击后的最大阻塞，比如保障信息、首单权益或价格呈现。
+
+**风险提醒**
+不要把点击率当成业务胜利。全量标准要看主指标和护栏指标。
+
+## 样例 5：项目延期
+
+用户：版本延期两周了，研发说需求总变，产品说研发估期不准，怎么办？
+
+回答：
+
+**问题判断**
+延期的核心不是谁背锅，而是范围变更和交付承诺之间没有硬边界。
+
+**原因分析**
+
+- 需求持续变化时，任何估期都会失效。
+- 没有冻结点和变更代价，团队会默认“边做边改”。
+- 继续争论责任无法恢复进度，必须先重建交付规则。
+
+**行动建议**
+
+1. 今天拉出剩余功能，按必须上线、可降级、可后置三类切分。
+2. 设冻结点：冻结后新增需求只进下个版本，除非负责人同意砍同等工作量。
+3. 每天只看关键路径和阻塞项，不再开泛进度会。
+
+**风险提醒**
+不要继续讨论“谁估错了”。先让版本以可控范围落地，再复盘估期和变更机制。
+
+## 样例 6：增长方向太多
+
+用户：产品增长停了，团队提了十几个方向：投放、裂变、会员、内容、渠道合作，怎么选？
+
+回答：
+
+**问题判断**
+现在不该选方向清单，而要先找增长卡在哪一环。
+
+**原因分析**
+
+- 投放、裂变、会员、内容分别解决不同问题，不能混在一起比大小。
+- 如果留存差，投放会放大亏损；如果激活差，裂变会带来更多低质量用户。
+- 增长停滞通常只有一个环节最先限制整体结果。
+
+**行动建议**
+
+1. 用一周拆增长树：流量、激活、次日/7 日留存、付费、分享。
+2. 找跌幅最大且可控的环节，最多选两个实验。
+3. 本月只保留一个主攻方向，其他方向进入观察池。
+
+**风险提醒**
+不要同时开十几个增长项目。资源一分散，每个方向都得不到结论。
+
+## 样例 7：数据口径冲突
+
+用户：BI 看转化率涨了，产品后台看转化率跌了，业务催我赶紧做方案。
+
+回答：
+
+**问题判断**
+现在不能先做业务方案，第一优先级是统一口径，判断这是不是一个真实业务变化。
+
+**原因分析**
+
+- 两个看板方向相反，说明定义、埋点、去重、归因或同步链路至少有一个不一致。
+- 在指标不可信时做转化方案，可能会把正常链路改坏。
+- 业务真正需要的不是更快拍脑袋，而是可用于决策的事实表。
+
+**行动建议**
+
+1. 今天把两个看板的指标定义、分母分子、去重规则、时间窗口拉齐。
+2. 用原始日志抽 100 个样本，对照注册、下单、支付三个关键事件。
+3. 24 小时内给业务一个结论：真实上涨、真实下跌，还是口径问题；只有真实变化才进入业务动作。
+
+**风险提醒**
+不要在口径没统一前开优化项目，也不要让两个看板继续各说各话。
+
+## 样例 8：社区冷启动
+
+用户：我们做了一个行业交流社区，功能都上线了，但用户进来没人发言。
+
+回答：
+
+**问题判断**
+冷启动问题不在功能缺少，而在第一批用户没有获得回来互动的理由。
+
+**原因分析**
+
+- 社区早期最缺的是高质量供给和即时反馈，不是更多功能。
+- 泛行业用户关系太弱，话题太宽，用户不知道为什么要在这里说。
+- 没有稳定回应机制时，用户第一次发言失败就很难回来。
+
+**行动建议**
+
+1. 本周先收窄到一个细分人群和一个高频话题，比如“新手销售如何拿下第一个客户”。
+2. 运营每天手工种 10 条高质量问题和 20 条回应，保证种子用户发言后 2 小时内有人接住。
+3. 看 7 日内重复发言人数和有效回复率，不看注册数。
+
+**风险提醒**
+不要继续补功能，也不要一上来拉大量泛用户。空场子越大，越显得没人气。
+
+## 样例 9：AI 功能冲动
+
+用户：老板要求本季度必须上 AI 功能，说竞品都有了，我们怎么定方向？
+
+回答：
+
+**问题判断**
+现在要先把“上 AI”改成“解决哪个高频高成本任务”，否则很容易做成展示功能。
+
+**原因分析**
+
+- 竞品有 AI 不代表用户会因为 AI 选择我们。
+- 如果没有明确任务和验收指标，研发会消耗在模型效果和交互包装上。
+- AI 输出有错误成本，必须先选低风险、可校验、可兜底的场景。
+
+**行动建议**
+
+1. 本周从客服、内容生产、销售线索、数据分析里选一个最高频且人工成本最高的任务。
+2. 先做半自动 MVP：AI 生成，人工确认，再进入正式流程。
+3. 指标只看任务节省时间、采纳率、错误率和用户满意度，达标后再产品化。
+
+**风险提醒**
+不要为了“有 AI”改 Roadmap，也不要先做大而全的 AI 助手。
+
+## 样例 10：模糊增长症状，需要确认
+
+用户：我们最近增长不太好，怎么办？
+
+回答：
+
+**问题判断**
+现在不能直接上增长方案，先要确认“不太好”具体卡在增长链路的哪一环。
+
+**原因分析**
+
+- 增长问题可能来自新用户减少、激活变差、留存下降、付费转化变低或渠道成本上升。
+- 不同卡点的动作完全不同，没拆清楚就做活动或投放，容易制造噪音。
+- 当前最值得做的是最小诊断，而不是马上开一堆增长项目。
+
+**行动建议**
+
+1. 今天先拉一张最近 8 周的增长漏斗：曝光、注册、激活、D7 留存、付费、分享。
+2. 按渠道拆 cohort，找跌幅最大且可控的一环。
+3. 48 小时内只选一个主攻实验，成功指标和停止标准写清楚。
+
+**风险提醒**
+不要先加预算、做活动或上裂变。根因没定位前，这些动作只会把判断搞乱。
+
+**需要确认**
+
+1. 你说的增长不好，具体是 DAU、新用户数、收入还是订单下降？
+2. 下滑持续多久了，是突然掉下来还是慢慢变差？
+3. 过去两个月试过哪些动作，哪些有效或无效？
+
+## 样例 11：留存下降但是否回滚不明确
+
+用户：新版本上线后留存掉了，要不要回滚？
+
+回答：
+
+**问题判断**
+先不要直接回滚，除非已经确认留存下降由新版本导致且影响核心用户。
+
+**原因分析**
+
+- 新版本上线和留存下降同时发生，不代表一定有因果关系。
+- 如果问题只影响某个渠道、设备或灰度版本，局部降级比全量回滚更合适。
+- 如果是埋点或 cohort 结构变化，回滚反而会制造新风险。
+
+**行动建议**
+
+1. 2 小时内按新老用户、渠道、设备、版本和灰度组拆 D1/D7 留存。
+2. 如果核心路径完成率、崩溃率或投诉在新版本显著异常，先对受影响版本降级或回滚。
+3. 24 小时内给出保留、局部回滚、全量回滚三个决策条件。
+
+**风险提醒**
+不要只看总留存就全量回滚。全量回滚也有成本，尤其会影响已经正常使用新版本的用户。
+
+**需要确认**
+
+1. 掉的是新用户留存还是老用户回访？
+2. 是否集中在某个渠道、设备、系统版本或灰度组？
+3. 同期是否有发布事故、埋点变更或投放人群变化？
diff --git a/skills/product-decision-agent/scripts/quality_gate.py b/skills/product-decision-agent/scripts/quality_gate.py
new file mode 100755
index 000000000..2ee53201c
--- /dev/null
+++ b/skills/product-decision-agent/scripts/quality_gate.py
@@ -0,0 +1,230 @@
+#!/usr/bin/env python3
+"""Quality checks for Maoxuan Product Agent sample outputs.
+
+Usage:
+  quality_gate.py output1.md output2.md ...
+
+Each input file must contain one candidate answer. Aggregated reference files,
+such as references/response-examples.md, are intentionally not accepted.
+
+The script catches common regressions:
+- source/theory leakage
+- English-dominant answers in Chinese work scenes
+- vague advice without concrete next actions
+- excessive question dumping in the "需要确认" section
+- missing judgment, risk, or decision signal
+"""
+
+from __future__ import annotations
+
+import re
+import sys
+from pathlib import Path
+
+
+HARD_BANNED = [
+    r"毛泽东",
+    r"毛选",
+    r"矛盾论",
+    r"实践论",
+    r"教员",
+    r"毛主席",
+    r"同志",
+    r"阶级",
+    r"革命",
+    r"斗争",
+    r"主席指出",
+    r"《[^》]+》认为",
+]
+
+SOFT_BANNED = [
+    r"辩证",
+    r"唯物",
+    r"经典",
+    r"原文",
+]
+
+VAGUE_PATTERNS = [
+    r"提升用户体验",
+    r"加强沟通",
+    r"多看数据",
+    r"深入了解用户",
+    r"持续优化",
+    r"形成闭环",
+    r"赋能",
+    r"抓手",
+    r"打透认知",
+]
+
+JUDGMENT_HINTS = [
+    "问题判断",
+    "核心是",
+    "关键是",
+    "不是",
+    "当前最",
+    "先不要",
+]
+
+ACTION_HINTS = [
+    "行动建议",
+    "下一步",
+    "今天",
+    "本周",
+    "24 小时",
+    "48 小时",
+    "2 天",
+    "一周",
+    "两周",
+    "负责人",
+    "指标",
+    "验证",
+    "实验",
+    "灰度",
+    "拆",
+    "砍",
+    "暂停",
+    "停止",
+]
+
+DECISION_HINTS = [
+    "成功指标",
+    "失败指标",
+    "主指标",
+    "影响指标",
+    "护栏",
+    "全量",
+    "停止",
+    "暂停",
+    "复盘",
+    "监控",
+    "达标",
+    "不达标",
+    "决策",
+    "上线",
+    "回滚",
+    "留存",
+    "转化",
+    "回复率",
+    "复访",
+    "D7",
+    "7 日",
+    "7日",
+]
+
+RISK_HINTS = [
+    "风险提醒",
+    "不要",
+    "先不要",
+    "暂时不要",
+    "不建议",
+]
+
+AGGREGATE_EXAMPLE_PATTERN = re.compile(r"^##\s+样例\s*\d+", re.MULTILINE)
+
+
+def count_questions(text: str) -> int:
+    """Count questions in the "需要确认" section only."""
+    match = re.search(
+        r"(?:^|\n)(?:#{1,3}\s*)?(?:\*\*)?需要确认(?:\*\*)?[^\n]*\n"
+        r"(?P<section>.*?)(?=\n(?:#{1,3}\s+|\*\*[^*\n]+?\*\*)|\Z)",
+        text,
+        re.DOTALL,
+    )
+    if not match:
+        return 0
+
+    section = match.group("section")
+    questions = 0
+    for line in section.splitlines():
+        stripped = line.strip()
+        if not stripped:
+            continue
+        # Count sentence-ending question marks. This ignores URL query strings
+        # such as https://example.com?a=1 while still catching two questions
+        # written on the same line.
+        questions += len(
+            re.findall(r"？|\?(?=[\s\u4e00-\u9fff]|$)", stripped)
+        )
+    return questions
+
+
+def chinese_ratio(text: str) -> float:
+    zh = len(re.findall(r"[\u4e00-\u9fff]", text))
+    en = len(re.findall(r"[A-Za-z]", text))
+    if zh + en == 0:
+        return 0.0
+    return zh / (zh + en)
+
+
+def check_file(path: Path) -> tuple[list[str], list[str]]:
+    text = path.read_text(encoding="utf-8")
+    errors: list[str] = []
+    warnings: list[str] = []
+
+    if len(AGGREGATE_EXAMPLE_PATTERN.findall(text)) > 1:
+        return ["input contains multiple answers; pass one candidate answer per file"], []
+
+    for pattern in HARD_BANNED:
+        if re.search(pattern, text, re.IGNORECASE):
+            errors.append(f"exposes hard-banned source/style term: {pattern}")
+
+    for pattern in SOFT_BANNED:
+        if re.search(pattern, text, re.IGNORECASE):
+            warnings.append(f"contains review-needed term: {pattern}")
+
+    vague_hits = [p for p in VAGUE_PATTERNS if re.search(p, text)]
+    if vague_hits:
+        errors.append(f"contains vague phrase(s): {', '.join(vague_hits)}")
+
+    if chinese_ratio(text) < 0.72:
+        errors.append("answer is not Chinese-dominant enough")
+
+    if not any(hint in text for hint in JUDGMENT_HINTS):
+        errors.append("missing problem judgment")
+
+    if not any(hint in text for hint in ACTION_HINTS):
+        errors.append("missing concrete action hints")
+
+    if not any(hint in text for hint in DECISION_HINTS):
+        errors.append("missing metric/decision/review signal")
+
+    if not any(hint in text for hint in RISK_HINTS):
+        errors.append("missing risk or stop-doing guidance")
+
+    if count_questions(text) > 3:
+        errors.append("asks too many questions")
+
+    stripped_len = len(text.strip())
+    if stripped_len < 120:
+        errors.append("output is likely too thin")
+    if stripped_len > 2200:
+        errors.append("output is likely too verbose")
+
+    return errors, warnings
+
+
+def main(argv: list[str]) -> int:
+    if not argv:
+        print("Usage: quality_gate.py output1.md output2.md ...", file=sys.stderr)
+        print("Each input file must contain exactly one candidate answer.", file=sys.stderr)
+        return 2
+
+    failed = False
+    for item in argv:
+        path = Path(item)
+        errors, warnings = check_file(path)
+        if errors:
+            failed = True
+            print(f"FAIL {path}")
+            for err in errors:
+                print(f"  - {err}")
+        else:
+            print(f"PASS {path}")
+        for warning in warnings:
+            print(f"  WARN {warning}")
+
+    return 1 if failed else 0
+
+
+if __name__ == "__main__":
+    raise SystemExit(main(sys.argv[1:]))
diff --git a/skills/product-decision-agent/scripts/test_quality_gate.py b/skills/product-decision-agent/scripts/test_quality_gate.py
new file mode 100755
index 000000000..fb217e08a
--- /dev/null
+++ b/skills/product-decision-agent/scripts/test_quality_gate.py
@@ -0,0 +1,112 @@
+#!/usr/bin/env python3
+"""Regression tests for the sample-output quality gate."""
+
+from __future__ import annotations
+
+import importlib.util
+import tempfile
+import unittest
+from pathlib import Path
+
+
+MODULE_PATH = Path(__file__).with_name("quality_gate.py")
+SPEC = importlib.util.spec_from_file_location("quality_gate", MODULE_PATH)
+if SPEC is None or SPEC.loader is None:
+    raise RuntimeError(f"Cannot load {MODULE_PATH}")
+quality_gate = importlib.util.module_from_spec(SPEC)
+SPEC.loader.exec_module(quality_gate)
+
+
+VALID_OUTPUT = """# 测试回答
+
+**问题判断**
+当前最关键的是先拆清楚留存下降来自哪个用户群体。
+
+**原因分析**
+- 总量变化可能掩盖渠道和版本差异。
+
+**行动建议**
+1. 今天按渠道和版本拆 D7 留存，并用结果决定是否回滚。
+
+**风险提醒**
+不要在口径不清时直接全量回滚。
+"""
+
+
+class QuestionCountingTests(unittest.TestCase):
+    def test_counts_only_confirmation_section(self) -> None:
+        text = VALID_OUTPUT + "\n前文的问题是什么？\n"
+        self.assertEqual(quality_gate.count_questions(text), 0)
+
+    def test_counts_multiple_questions_on_one_line(self) -> None:
+        text = VALID_OUTPUT + """
+
+**需要确认**
+1. 掉的是新用户吗？集中在哪个版本？
+2. 埋点改过吗？是否有发布事故？
+"""
+        self.assertEqual(quality_gate.count_questions(text), 4)
+
+    def test_ignores_url_query_string(self) -> None:
+        text = VALID_OUTPUT + """
+
+**需要确认**
+1. 请确认看板 https://example.com/report?cohort=new 是否采用同一口径。
+"""
+        self.assertEqual(quality_gate.count_questions(text), 0)
+
+
+class FileCheckingTests(unittest.TestCase):
+    def check(self, text: str) -> tuple[list[str], list[str]]:
+        with tempfile.TemporaryDirectory() as temp_dir:
+            path = Path(temp_dir) / "sample.md"
+            path.write_text(text, encoding="utf-8")
+            return quality_gate.check_file(path)
+
+    def test_valid_output_passes(self) -> None:
+        errors, warnings = self.check(VALID_OUTPUT)
+        self.assertEqual(errors, [])
+        self.assertEqual(warnings, [])
+
+    def test_hard_source_leak_fails(self) -> None:
+        errors, _ = self.check(VALID_OUTPUT + "\n毛泽东认为应该这样做。\n")
+        self.assertTrue(any("hard-banned" in error for error in errors))
+
+    def test_soft_term_warns_without_failing(self) -> None:
+        errors, warnings = self.check(VALID_OUTPUT + "\n这是一个经典案例。\n")
+        self.assertEqual(errors, [])
+        self.assertTrue(any("review-needed" in warning for warning in warnings))
+
+    def test_more_than_three_confirmation_questions_fails(self) -> None:
+        text = VALID_OUTPUT + """
+
+**需要确认**
+1. 指标是什么？
+2. 持续多久？
+3. 哪类用户？
+4. 试过什么？
+"""
+        errors, _ = self.check(text)
+        self.assertIn("asks too many questions", errors)
+
+    def test_aggregate_examples_get_targeted_error(self) -> None:
+        text = f"""# 中文输出样例
+
+## 样例 1：留存下降
+
+{VALID_OUTPUT}
+
+## 样例 2：转化下降
+
+{VALID_OUTPUT}
+"""
+        errors, warnings = self.check(text)
+        self.assertEqual(
+            errors,
+            ["input contains multiple answers; pass one candidate answer per file"],
+        )
+        self.assertEqual(warnings, [])
+
+
+if __name__ == "__main__":
+    unittest.main()