Amazon Operating Decision Engine
把 Amazon 产品、GTM 与运营问题从“凭经验给一个答案”升级为可追溯的经营决策：先定义问题，再选择合适方法，必要时串联多个方法，直到形成可执行动作、条件分支、参数边界和验证计划。
总原则
- 先定义问题，再选工具。 不因用户提到某个方法就忽略问题本身；若问题尚未定义清楚，先完成最低限度的诊断。
- 按需调用，不机械全跑。 一道题只用一个模块能解决，就不要强行跑完整链路。
- 事实、假设、未知分开。 用户文件、店铺数据、广告数据、VOC、竞品资料、内部资料等是证据；没有证据的判断必须标记为假设或未知。
- 方法边界清晰。 形态盒负责生成方案，决策矩阵负责比较取舍，决策树负责条件分支，数值优化负责参数，实验负责买信息。
- 不制造虚假精确。 没有响应曲线、样本或可靠约束时，不宣称找到了“最优值”；输出可行区间、情景结果和待验证变量。
- 保留经营上下文。 任何推荐都说明目标、约束、依据、主要假设、风险与触发下一步调整的条件。
入口：先识别问题类型
先将用户问题改写为：
在【对象/场景】下，为了【目标】，在【约束】内，需要决定【什么】。
再判断主问题属于哪一类：
| 主问题 | 默认方法 |
|---|---|
| 为什么发生？真正问题在哪？ | 问题诊断 / 证据整理 |
| 还有哪些完整方案？ | 形态盒 Morphological Analysis |
| 已有多个方案，哪个更值得做？ | 决策矩阵 Decision Matrix |
| 条件变化后应该走哪条路径？ | 决策树 Decision Tree |
| 已知方向后，Bid/预算/价格/库存等具体调多少？ | 数值优化 Numerical Optimization |
| 关键假设证据不足，下一步怎么验证？ | 低成本验证 Experiment / Validation |
详细路由规则见 references/problem-routing.md。
复杂问题的默认编排
只有当用户要的是完整经营方案，并且问题确实同时包含多个阶段时，才按以下链路推进：
问题定义 → 形态盒生成候选 → 决策矩阵比较 → 决策树预设条件分支 → 数值优化确定参数 → 低成本验证 → 执行与复盘
允许跳步：
- 已有明确候选方案：跳过形态盒。
- 已选定策略，只问条件分支：直接决策树。
- 已确定方向，只问参数：直接数值优化。
- 原因尚不明确：不要直接生成解决方案，先诊断。
- 用户明确只要求一种方法：优先只执行该方法，除非缺少必要前置定义。
模块 1｜问题诊断与决策框定
当用户描述的是现象，例如“CVR掉了”“广告越来越贵”“新品没起量”，先区分：
现象 → 基准/预期 → 差距 → 可能变量 → 证据 → 当前最值得解决的问题
不要把“降价、加预算、换图”等动作当成问题定义。
读取 references/problem-routing.md 执行诊断与路由。
模块 2｜形态盒：Generate
当需要回答“还有哪些方案”时，读取 references/morphological-analysis.md。
必须做到：
- 区分锁定变量与可动变量；
- 选择 4–7 个真正改变方案的独立维度；
- 每个维度列 3–6 个离散取值；
- 先发散，不提前打分；
- 做组合一致性检查，证据不足标记 uncertain；
- 形成 3–5 个差异明显、内部逻辑完整的候选方案。
可用 scripts/morph_box.py 做结构校验、组合计数和明确排除规则的过滤。
模块 3｜决策矩阵：Compare
当已有多个候选，需要比较取舍时，读取 references/decision-matrix.md。
必须先定义：
- 决策目标；
- 评价标准及其含义；
- 权重来源；
- 评分锚点；
- 每项评分的证据与置信度。
输出加权结果，但不要只报总分。必须指出：
- 拉开差距的关键维度；
- 证据薄弱项；
- 对权重变化是否敏感；
- 是否存在红线，红线不能被高总分抵消。
可用 scripts/decision_matrix.py 计算加权结果与基础敏感性。
模块 4｜决策树：Branch
当策略取决于季节、上市时间、库存、验证结果、竞品动作、价格、生命周期等关键条件时，读取 references/decision-tree.md。
决策树只保留会改变下一步动作的条件：
关键条件 → 分支状态 → 对应动作 → 观察指标 → 下一次判断节点
不要把它画成普通流程图；不同分支必须真正导致不同策略。
模块 5｜数值优化：Optimize
当方向已经明确，需要回答“具体调多少”时，读取 references/numerical-optimization.md。
先写清：
- 目标函数；
- 决策变量；
- 硬约束；
- 可接受风险；
- 数据与响应关系。
若只有静态比例或单点数据，只做约束推导和情景分析，不声称求得真实最优值。
常见 Amazon 参数包括 Bid、Budget、Placement、Daypart multiplier、Price、Coupon/Deal、库存覆盖、补货量、测试预算与资源分配。
若用户提供一组已计算的候选参数/情景，可用 scripts/scenario_grid.py 按硬约束过滤并按目标排序；不要让脚本替代业务模型。
模块 6｜低成本验证：Validate
当一个方案高度依赖未验证假设时，读取 references/experiment-validation.md。
优先找“决定结论、但当前证据最弱”的变量，设计最低成本验证：
关键不确定性 → 假设 → 最便宜的信息来源/实验 → 观察指标 → 通过/失败标准 → 下一步
原则：数据不够时，先买最便宜的信息，不要直接买最贵的执行。
Amazon 三种工作模式
根据问题自动选择模式；不要把不同层级变量混进同一个盒子或矩阵。详细维度库见 references/amazon-modes.md。
Product Mode｜产品与产品组合
用于新品定义、升级款、场景补位、Bundle、产品组合空白、功能/结构方向。
GTM Mode｜上市与营销
用于新品启动、流量入口、Listing内容、价格促销、广告架构、站外、上市节奏和承接路径。
Operations Mode｜经营与运营
用于已明确目标下的运营打法、预算/资源配置、广告策略、库存、价格、ASIN/品线经营动作。
证据规则
- 关键词、Review、QA、搜索趋势、竞品、退货原因、社媒反馈默认是证据层，不要直接当成决策维度。
- 技术可行性、成本、认证、可靠性、供应链能力若无事实依据，标记 Unknown，并提出验证动作。
- 用户提供文件或内部资料时，以其内容为本次分析依据；不要用常识静默修正文件结论。
- 当前市场、竞品、平台政策等若需要实时信息，应明确获取最新来源后再判断。
- 评分依据不足时，不要为了完成矩阵而编造数字。
最终输出
默认使用 references/output-patterns.md 的 Decision Brief。只展示本题真正用到的模块，不把完整方法论课件式复述给用户。
最终必须让用户能回答：
1. 现在真正要决定什么？
2. 依据是什么，哪些仍是假设？
3. 我们考虑过哪些可行路径？
4. 当前更值得做什么，为什么？
5. 什么条件变化后要改策略？
6. 若涉及参数，建议区间/值建立在什么模型和约束上？
7. 下一步最该验证什么？
质量门槛
提交前检查：
- 是否把现象误当问题？
- 是否用错方法，或为了“全面”而过度分析？
- 形态盒是否提前做了优先级排序？
- 决策矩阵是否用红线问题换取高总分？
- 决策树是否真的存在条件分支？
- 数值优化是否缺模型却给出虚假“最优值”？
- 是否把事实、假设、未知混在一起？
- 是否给出了可执行的下一步和复核条件？
Resources
references/problem-routing.md— 问题诊断、方法选择与组合路由。references/morphological-analysis.md— 形态盒与组合一致性检查。references/decision-matrix.md— 决策矩阵、权重、评分、置信度与敏感性。references/decision-tree.md— 条件分支与动态经营路径。references/numerical-optimization.md— 数值优化、约束推导与 Amazon 常见参数。references/experiment-validation.md— 低成本实验与不确定性验证。references/amazon-modes.md— Product / GTM / Operations 三种模式的维度与证据提示库。references/output-patterns.md— 默认 Decision Brief 输出结构。scripts/morph_box.py— 形态盒结构与组合辅助。scripts/decision_matrix.py— 加权矩阵与基础敏感性辅助。scripts/scenario_grid.py— 对已计算情景做约束过滤与目标排序。
