contentm_agent/参考资料/技能修法反馈-1b竞品分析方法论-ChatGPT-20261007.md

# 技能修法反馈：1b 竞品分析方法论（ChatGPT）

- 采集时间：2026-10-07
- 来源：ChatGPT 网页对话 <https://chatgpt.com/c/6ac633af-52b0-83e8-97ba-bfb410aaf96c>
- 账号：meiya1（免费版）
- 通道：browser-harness 独立实例（CDP 127.0.0.1:9223）＋ 代理 socks5://127.0.0.1:10800
- 状态：**仅收集反馈，未改动任何技能文件**

---

## 一、我提给它的情况说明（原文）

你是帮我审阅一套自建 AI 技能（Skill）文件的顾问。我先交代背景，再问你一个具体的修改问题。
【背景】
我有一套「产品规划」技能，是四段式流水线：
① 产品需求 → ② 产品功能 → ③ 界面交互 → ④ 原型说明文档。
第①段内部有 5 个子步：1a 需求文档、1b 竞品分析、1c 用户画像、1d 产品策略、1e 使用场景。
【问题所在】
1b 竞品分析这个子步，技能里唯一的方法论载体是文件 references/competitor-analysis.md。
但这份文件是一份英文的「市场商业分析」框架，不是产品视角的竞品分析：
- 正文通篇英文，规定的输出结构是：Market Overview & Definition / Competitive Set Summary / Competitor Profile / Core Product Strengths / Product Weaknesses & Gaps / Business Model & Pricing / Competitive Threats & Advantages / Differentiation Opportunities / Competitive Positioning Recommendation
- 谈的是市场规模、市场份额、成立时间与融资、定价结构、GTM 渠道、12-18 个月的竞争风险
- 全文没有出现中文「竞品」二字，也没有「用途 / 场景 / 功能 / 作用 / 优势」这类产品视角的词
而同一个技能的 SKILL.md 里却明确写着：「商业模式与变现已删……不做市场规模、份额、定价、融资」。
也就是说：文件 A 要求我做市场商业分析，文件 B 禁止我做市场商业分析，两者自相矛盾。
另外，SKILL.md 里 §1b 这一节只有一句话：「读 references/competitor-analysis.md → 产出 docs/pm/<项目>/research/1b-竞品分析.md」，并没有规定 1b 的产出文档应该包含哪几节。
同批未本地化的还有 1c 的 user-personas.md 和 1d 的 product-strategy.md（都是英文）；1a 的 grill-me.md 和 1e 的 usage-scenario.md 是中文。
【我真正要的口径】
我要的竞品分析是产品视角的横向对比：讲用途、讲场景、讲功能、讲作用、讲优势。
与产品规划无关的商业分析内容（市场规模、份额、融资、定价、GTM）全部去掉。
【请你回答这 5 个问题】
1、1b 这份方法论文件应该重写成什么结构？请给出建议的正文章节骨架，每一节写什么、判据是什么。
2、「不做市场规模、份额、定价、融资」这条禁令，应该写在哪里才不会再次和正文打架？
3、SKILL.md 里 §1b 那句话应该补成什么？要不要在技能层直接钉死 1b 必须产出哪几节？
4、1c / 1d 是否应该一并本地化，还是分两批做更稳？
5、从机制上，怎么避免「技能正文和技能禁令自相矛盾」这类问题再次发生？
请直接给可落地的建议，不要泛泛而谈。

---

## 二、ChatGPT 的回复（原文）

你的判断是对的：现在 1b 不是“中文化不足”，而是方法论本身错位。它实际上把「产品规划中的竞品分析」误写成了「市场商业分析」，而 SKILL.md 又在上层否定了这套方法，形成了典型的规则层与方法论层冲突。

我建议不要只改 competitor-analysis.md 的语言，而是顺手把 1b 的职责边界、输出契约、禁区一起钉死。这样以后扩展 1c/1d 时也不容易再出现同类问题。

1. 1b 方法论文件应该重写成什么结构？

我建议把 references/competitor-analysis.md 完整改造成一份**「产品视角竞品分析方法论」**，不要在原英文框架上修修补补。

核心原则：

竞品分析不是研究“谁的生意更大”，而是研究“用户为什么会选择它，以及它在产品层面是怎么解决问题的”。

建议正文骨架如下：

1. 分析目标与边界

写什么：

明确 1b 要回答的问题：

用户在解决什么问题？
用户在什么场景下会使用竞品？
竞品服务的是谁？
竞品提供了哪些核心功能？
每个功能解决什么问题？
不同竞品解决同一问题的方式有什么差异？
各竞品在哪些场景下更有优势？
哪些能力值得借鉴？
哪些地方存在明显空缺？
本产品可以从哪里形成差异化？

判据：

分析结束后，产品规划人员应该能够回答：

「如果我要设计这个产品，竞品已经怎么做了？哪里做得好？哪里没做好？我应该学什么、避开什么、突破什么？」

如果回答不了，就说明竞品分析没有完成。

2. 竞品选择与分析范围

写什么：

定义哪些产品应该进入竞品池：

直接竞品：解决相同核心问题、目标用户高度重叠。
间接竞品：解决同一需求，但产品形态或实现方式不同。
替代方案：用户不用这类产品，也能通过其他方式解决问题。
必要时可以加入标杆产品：某项能力特别优秀，值得单独研究。

建议不要要求固定数量，而是要求：

至少覆盖「直接竞品 + 1 个替代/间接方案」，数量根据问题复杂度决定。

判据：

不能因为“知名”就纳入竞品。

必须能够回答：

「用户为什么会拿这个产品和我们的产品做选择？」

3. 用户与核心需求

写什么：

先建立统一比较基准：

目标用户
用户任务
核心痛点
使用动机
使用场景
使用频率/时机
用户最终希望得到什么结果

这一节非常重要，因为没有统一用户和任务，就无法公平比较功能。

判据：

后续所有竞品比较都必须能够回到：

用户是谁 → 在什么场景 → 想完成什么任务 → 需要什么结果。

4. 核心场景对比

这是我建议重点强化的一节。

写什么：

按用户场景横向比较竞品：

场景	用户目标	竞品 A	竞品 B	竞品 C
场景 1	完成 X	怎么做	怎么做	怎么做
场景 2	完成 Y	怎么做	怎么做	怎么做

重点不是写“有这个功能”，而是写：

用户在这个场景下，竞品具体怎么让用户完成任务。

例如：

进入方式
操作路径
核心步骤
系统提供什么帮助
最终输出
哪一步最省力
哪一步最复杂

判据：

必须能描述出用户实际使用产品的过程，而不是功能名罗列。

5. 核心功能横向对比

写什么：

建立统一功能维度：

核心功能
辅助功能
输入方式
处理方式
输出方式
编辑能力
管理能力
协作能力
AI 能力（如果相关）
自动化能力（如果相关）

但不要机械套固定维度。

应该根据具体产品调整。

判据：

每个功能都回答三个问题：

是什么 → 解决什么问题 → 对用户有什么作用

而不是只写：

A 有 XXX，B 有 XXX。

6. 产品机制与交互方式对比

这是和普通“功能竞品表”拉开差距的一节。

写什么：

比较竞品背后的产品设计方式：

核心任务流程
信息组织方式
导航结构
核心交互
默认行为
自动化机制
AI 与用户的协作方式
关键反馈
异常处理
用户控制权

判据：

关注的是：

竞品为什么这样设计，以及这种设计给用户带来了什么结果。

而不是单纯描述 UI 长什么样。

7. 产品优势与不足

建议把原来英文框架里的：

Core Product Strengths / Product Weaknesses & Gaps

保留下来，但彻底产品化。

每个优势/不足都必须落到：

能力 → 场景 → 用户价值

例如：

优势：批量处理能力强
场景：用户需要一次处理大量内容时
作用：减少重复操作
结果：提高处理效率

而不是：

“产品体验很好。”

判据：

任何“好/差/强/弱”的判断，都必须能够说明为什么。

8. 竞品能力矩阵

建议形成一个最终的横向矩阵：

产品能力	A	B	C	机会
核心场景 1	强	中	弱	高
核心场景 2	强	强	中	低
功能 X	✓	✓	—	中
功能 Y	强	—	强	高

判据：

矩阵不是为了“看起来专业”，而是为了发现：

行业共识能力
竞品差异能力
某竞品独有能力
普遍做得不好的能力
尚未被很好解决的需求
9. 可借鉴点与产品机会

最后一定要从“分析”进入“产品规划”。

建议分成三类：

应该借鉴

竞品已经验证有效，并且与本产品目标一致。

应该避免

竞品存在明显问题，不应直接复制。

可以突破

用户需求存在，但竞品解决得不够好。

最后输出：

产品机会点 → 对应场景 → 用户问题 → 竞品现状 → 建议方向

10. 竞品分析结论

最终不要再输出“Competitive Positioning Recommendation”这种商业定位语言。

改成：

产品层结论

用户最核心的需求是什么
当前竞品共同解决了什么
当前竞品共同存在什么问题
哪些能力已经成为基础能力
哪些能力可以形成差异
本产品应该优先解决什么
一个非常关键的建议

不要把 1b 写成“固定答案模板”。

应该写成：

分析方法 + 判断标准 + 最低输出要求

因为不同产品的竞品维度完全不同。

例如一个 AI 工具和一个 ERP，强行要求相同的 10 个字段，反而会让 Skill 变笨。

2. 「不做市场规模、份额、定价、融资」应该写在哪里？

三个地方写，但职责不同。

第一层：SKILL.md —— 写「硬边界」

这是最高优先级的业务规则。

例如：

Markdown
### 1b 竞品分析边界

1b 仅进行产品视角的竞品分析。

关注：
- 用户
- 用途
- 场景
- 核心任务
- 功能
- 产品机制
- 交互方式
- 产品优势与不足
- 可借鉴能力
- 产品机会

禁止：
- 市场规模
- 市场份额
- 融资情况
- 公司成立时间
- 定价与商业模式
- GTM / 获客渠道
- 财务指标
- 12–18 个月商业竞争风险预测

除非用户明确要求，否则不得扩展到上述商业分析内容。

这里是最终裁判。

第二层：competitor-analysis.md —— 写「方法边界」

文件内部也要明确：

本方法论只处理产品层竞品分析。

这样即使以后有人单独拿这个 reference 文件出来看，也不会误解。

第三层：输出模板/检查器 —— 写「验收规则」

最终生成 1b-竞品分析.md 时检查：

Markdown
### 输出检查

- [ ] 是否分析了用户与核心需求？
- [ ] 是否分析了主要使用场景？
- [ ] 是否进行了功能横向比较？
- [ ] 是否说明功能解决的问题和作用？
- [ ] 是否比较了产品优势与不足？
- [ ] 是否提炼了产品机会？
- [ ] 是否出现市场规模？
- [ ] 是否出现市场份额？
- [ ] 是否出现融资？
- [ ] 是否出现定价？
- [ ] 是否出现 GTM / 获客渠道？

最后几个是负向检查项。

这样就形成：

SKILL.md 定边界 → reference 定方法 → 输出检查负责验收

而不是把所有东西都塞进一个文件。

3. SKILL.md 的 §1b 应该怎么补？

我建议要钉死输出结构，但不要钉死每个细节。

现在：

Markdown
§1b 竞品分析：
读 references/competitor-analysis.md
→ 产出 docs/pm/<项目>/research/1b-竞品分析.md

太弱了。

建议改成：

Markdown
### 1b 竞品分析

目标：从产品视角分析竞品，理解用户、场景、功能、产品机制、优势与不足，并提炼产品机会。

执行：
1. 阅读 references/competitor-analysis.md
2. 根据项目目标确定竞品范围
3. 按用户、场景、功能和产品机制进行横向比较
4. 输出产品优势、不足与可借鉴点
5. 提炼产品机会与结论

产出：
docs/pm/<项目>/research/1b-竞品分析.md

最低输出结构：
1. 分析目标与范围
2. 竞品选择
3. 用户与核心需求
4. 核心场景对比
5. 核心功能横向对比
6. 产品机制与交互方式
7. 产品优势与不足
8. 竞品能力矩阵
9. 可借鉴点与产品机会
10. 产品层结论

边界：
1b 仅进行产品视角分析，不进行市场商业分析。
禁止输出市场规模、市场份额、融资、定价、商业模式、GTM/获客渠道等内容，除非用户明确要求。
为什么我建议“最低输出结构”，而不是“固定输出结构”？

因为 Skill 层应该规定契约，reference 才负责规定怎么做。

也就是说：

SKILL.md：

你必须交付什么。

competitor-analysis.md：

你应该怎么分析。

这两个职责不要混。

4. 1c / 1d 要不要一起本地化？

我的建议：

一起做，但不要一次性“大改”。

分成两个阶段：

第一批：先解决 1b

原因很简单：

现在 1b 已经存在明确的方法论错误 + 上下层冲突。

先把：

纯文本
1b
SKILL.md
competitor-analysis.md
1b 输出结构

打通。

验证一次完整执行结果。

第二批：1c + 1d 一起本地化

因为 1c、1d 是连续的：

纯文本
1c 用户画像
   ↓
1d 产品策略

两者的概念容易互相污染。

比如：

用户画像到底是“描述用户”，还是“指导产品决策”？

产品策略到底是“战略定位”，还是“产品层取舍”？

最好一起重新定义。

但注意：

不是简单翻译英文。

你应该先判断它们的方法论是否同样错位。

我甚至建议给 1c / 1d 做一次同样的检查：

检查项	1c	1d
是否与产品规划目标一致	✓/✗	✓/✗
是否存在商业分析内容	✓/✗	✓/✗
是否与 SKILL.md 冲突	✓/✗	✓/✗
是否有明确输出结构	✓/✗	✓/✗
是否有判断标准	✓/✗	✓/✗
是否中文本地化	✓/✗	✓/✗

先审，再翻。

不要把错误的英文方法论翻译成错误的中文方法论。

5. 怎么从机制上避免以后再出现这种冲突？

这是这套 Skill 最值得改的一层。

我建议建立一个非常简单的：

「规则 → 方法 → 输出 → 验收」四层架构
纯文本
                SKILL.md
             【规则 / 边界】
                    ↓
        references/*.md
             【方法论】
                    ↓
       docs/pm/.../*.md
             【最终输出】
                    ↓
          Validation / Check
             【验收规则】

四层分别负责不同事情。

第一层：SKILL.md = Constitution

只放：

任务定义
步骤顺序
输入输出
强制边界
禁止事项
各步骤之间的关系

例如：

1b 是产品竞品分析，不是市场商业分析。

这是不可被 reference 覆盖的规则。

第二层：reference = Playbook

负责：

怎么分析
分析维度
分析方法
判断标准
示例
常见错误

比如：

纯文本
竞品选择
↓
用户
↓
场景
↓
任务
↓
功能
↓
机制
↓
优势/不足
↓
机会
第三层：输出文档 = Contract

每个步骤都明确：

纯文本
输入：
...

必须产出：
...

最低章节：
...

不得出现：
...

这样 Agent 不需要猜。

第四层：Validation = Gate

执行结束以后再检查：

纯文本
1b 是否包含用户？
1b 是否包含场景？
1b 是否包含功能？
1b 是否包含优势/不足？
1b 是否提炼机会？

是否出现：
市场规模？
市场份额？
融资？
定价？
GTM？

发现违规就：

回退 → 修改 → 再验收

而不是直接交付。

最后给你一个我认为更重要的改造原则

你这套 Skill 现在的问题，很可能不只是 1b。

从你描述的情况来看，结构很可能是：

纯文本
SKILL.md
    ↓
引用一堆历史 reference
    ↓
reference 各自有自己的方法论
    ↓
不同文件来自不同阶段/不同作者
    ↓
最终出现“上层规则”和“底层方法”互相打架

所以我建议以后新增/修改 Skill 时，强制每个 reference 都有一个开头的 Scope / Boundary：

Markdown
# 方法论名称

## 0. Scope

本方法用于：
...

不用于：
...

上层约束：
...

最终目标：
...

并且每个阶段都维护一个输出契约表：

Step	目标	输入	必须输出	禁止内容
1a	明确需求	用户需求	需求文档	...
1b	产品竞品分析	需求	竞品分析	市场商业分析
1c	理解用户	需求+竞品	用户画像	...
1d	做产品取舍	1a-1c	产品策略	...
1e	明确使用场景	1a-1d	使用场景	...

这样以后你再增加 1f、2a、3a，就不会再出现“这个 reference 到底听谁的？”的问题。

一句话总结：

不要只修 1b 的英文文件；把 1b 建成“SKILL.md 定边界、reference 定方法、输出契约定结构、验收规则做兜底”的完整闭环。

而 1c / 1d 可以第二批一起做，但先审方法论，再做中文化。这比现在直接把三个英文文件全部翻译一遍稳得多。