contentm_agent/参考资料/技能优化建议-1b竞品分析方法论-ChatGPT-20261007-2.md

1b 竞品分析方法论 · 优化建议（ChatGPT）

时间：2026-10-07 通道：browser-harness 起独立 Chrome（9223）→ chatgpt.com → 同一会话追问 我发给它的内容：.workbuddy/tmp/chatgpt-prompt-优化.txt（5,078 字，全文内联：调整后的 reference 全文 ＋ 技能层 SKILL.md §1b 全段） 提问方式：只说明「背景与目标 ＋ 完整上下文」，不写控制指令；提问句为「看看还有哪里需要优化」。

---

ChatGPT 的回复（原文）

这版已经从“需要重构”进入了“可以用，但还有几个机制层细节值得收紧”的阶段。而且你这次有一个很重要的调整我赞成：**既然你的 Skill 设计原则明确要求只写正向规则，就不要为了防冲突把“禁止项”重新塞回正文。**我上一轮建议的负向检查，在你这套体系里确实可以删掉。我主要看到 6 个需要优化的点，其中 2 个比较重要。先给结论我会把当前版本评价为：方法论方向正确，结构基本成立，已经可以投入使用。现在不建议再“大改”；重点应该从“内容完整性”转向“减少重复、消除歧义、提高执行确定性”。尤其建议你改这 4 件事：把「优势与不足」改成「产品表现：优势与不足」或明确“优势”的判断来源解决 §4 / §5 / §6 三者边界重叠把“点名参考实装”的位置规则统一，不要同时出现 §一/§二 和 10 节结构的潜在冲突删掉几处不必要的“⛔”和历史性说明，让方法论更像 Skill，而不是审稿记录下面逐项说。1. 最大的问题：§4 / §5 / §6 有一定重叠现在是：纯文本§4 使用场景 用户怎么把事办成

§5 功能 功能 → 解决什么问题 → 起什么作用

§6 产品机制与交互 为什么这样设计方向没错，但 Agent 实际执行时很容易出现：§4 写一遍流程§5 又写一遍功能§6 再把流程和功能解释一遍。最后 1b 会重新变成“文字很多的说明书”。我建议给三个章节加非常明确的职责边界。改成：§4 场景 = 什么时候用 + 要完成什么事关注：When / Why例如：场景：用户需要一次生成 20 条短视频脚本。不要在这里详细解释按钮、功能机制。§5 功能 = 有什么能力 + 能解决什么问题关注：What例如：批量生成：一次生成多条脚本，解决逐条创建效率低的问题。§6 机制 = 为什么这样解决 + 怎么运作关注：How / Why例如：通过“批量输入主题 → 自动拆分 → 并行生成 → 批量编辑”的机制降低重复操作。所以建议把三个章节的判据直接改成：纯文本§4：能说清「什么时候、为什么使用」 §5：能说清「有什么能力、解决什么问题」 §6：能说清「怎么解决、为什么这样设计」这个修改我认为非常值得做。2. §7「优势」其实还缺一个非常重要的判断基准你现在写：优势：批量处理能力强；场景：一次要处理大量内容时；作用：减少重复操作；结果：更快出稿。这已经很好。但还差一个隐含问题：“强”是相对于谁？否则模型很容易写出：A 的 AI 能力很强。这句话依然没有比较基准。建议把 §7 的判断公式升级成：优势 / 不足 = 能力表现 × 使用场景 × 对比对象 × 用户价值例如：A 在批量生成场景下比 B 少 3 个重复操作步骤，因此更适合高频批量生产。不一定要求每次都写“少 3 个步骤”这么精确，但至少要有比较基准。建议把 §7 判据改成：每个「好 / 差 / 强 / 弱」的判断，都要能够说明相对于谁、在哪个场景、为什么、给用户带来什么结果。这是当前版本里我认为第二重要的优化点。3. §2 的「点名参考实装」现在有一点结构冲突你这里写：点名参考实装与通用竞品分成两层。SKILL 又写：两者并成一份的 §一 / §二。但是你的方法论正式结构是：纯文本1 分析目标 2 竞品选择 3 竞品用途 4 场景 5 功能 ...也就是说：§一 / §二到底是文档章节，还是竞品分类？目前存在轻微歧义。如果实际输出要求是：纯文本一、通用竞品 二、点名参考实装那么它和现在的 10 节结构是两套不同的目录系统。我更建议：不要让“通用竞品 / 点名参考实装”成为顶层章节。而是把它定义成：竞品来源的两种类型。然后统一进入同一个分析框架。例如：纯文本竞品池 ├── 通用竞品 │ ├── A │ ├── B │ └── C └── 点名参考实装 └── D然后所有竞品统一经过：纯文本用途 ↓ 场景 ↓ 功能 ↓ 作用 ↓ 机制 ↓ 优势这样你就不会出现：“点名竞品到底是不是另外一种分析方法？”这一点建议你统一。如果你确实已经在 SKILL.md 其他地方规定了最终文档必须是：§一 通用竞品§二 点名参考实装那就保留，但应该在本方法论 §2 明确：§一 / §二属于最终文档组织方式，不改变后续 10 节分析方法。否则执行模型可能不知道到底听哪个目录。4. §1 的“五问”非常好，但可以进一步降权这一段：用途 / 场景 / 功能 / 作用 / 优势其实已经成为这套 1b 的核心认知模型。我建议你把它从“章节映射”进一步提升成整个方法论的主线。现在：纯文本用途 → §3 场景 → §4 功能 → §5 作用 → §5 优势 → §7可以再加一句：五问是分析主线，10 节是执行结构。这样很重要。因为未来你可能发现：某个品类没有必要单独做“产品机制”，或者某些能力需要拆成两个章节。此时：10 节可以调整，五问不能丢。也就是：纯文本核心模型 用途 / 场景 / 功能 / 作用 / 优势 ↓ 执行结构 10 个章节 ↓ 最终输出 1b-竞品分析.md这会让你的 Skill 更耐用。5. §8「能力矩阵」建议再加一个原则：矩阵不需要强制覆盖全部功能你现在：一张横向矩阵收口。这句话容易导致一个问题：模型可能为了完成矩阵，最后搞出：30 行功能矩阵。然后整份竞品分析又开始膨胀。建议改成：只纳入影响核心用户任务或产品决策的能力。判据可以变成：矩阵能够帮助识别核心场景中的共识能力、差异能力、独有能力和机会点即可，不追求穷举。这样非常符合你之前强调的：不要像说明书。6. 你现在的文案略微有点“审稿痕迹过重”这个主要是：纯文本⛔ 不另立文档 ⛔ 不按竞品逐个写 ⛔ 只答这三件事 ⛔ 不许因为…… ⛔ 未达标 ⛔ 不给固定字段表 ⛔ 不许凭空提出机会我理解为什么这么写：你是在把 Agent 的行为钉死。但从 Skill 工程角度，我建议你逐渐把这些：“不要做 X”转化为：“正确做法是 Y”尤其你已经确定了“正文只保留正向规则”的原则。例如：现在：⛔ 不按竞品逐个写可以直接改成：按用户场景横向组织，竞品作为同一场景下的比较对象。现在：⛔ 只答这三件事改：本节聚焦产品形态、目标用户和核心用途，功能进入 §5。现在：⛔ 不给固定字段表改：比较维度根据产品类型和核心任务动态确定。这样会更干净。我会怎么修改你现在这版如果不大动结构，我建议只做下面这些局部修改。§0基本不动。但：「并回头修正本档」可以稍微工程化一点：两者出现不一致时，以技能层规则为准，并将问题记录到方法论修订中。这样不会产生“运行过程中自己修改 reference”的歧义。§4改成：场景 = 什么时候使用、为什么使用、用户要完成什么任务。§5改成：功能 = 产品提供什么能力、解决什么问题、对用户产生什么作用。§6改成：机制 = 产品通过什么方式解决问题，以及为什么采用这种方式。这样三章基本就锁死了。§7我建议直接把判据换成：每个「好 / 差 / 强 / 弱」的判断，都要说明相对于谁、在哪个场景、为什么，以及给用户带来什么结果。§8增加：只纳入影响核心用户任务或产品决策的能力，不追求穷举。§9现在已经很好。尤其你这句：每一条都要能追回 §4 / §5 / §7 的某一条。建议保留。这是整套方法里很有价值的“防拍脑袋”机制。还有一个我建议你做，但不需要现在做你现在的：references/competitor-analysis.md已经承担了两个角色：方法论 + 验收标准。这完全可以接受，而且对于你的单机自用 Skill，我反而不建议为了架构洁癖拆成两个文件。但是以后如果 1a～1e 都采用这种方式，我建议统一成：纯文本references/ ├── requirement-analysis.md ├── competitor-analysis.md ├── user-personas.md ├── product-strategy.md └── usage-scenario.md每个 reference 都统一：纯文本0. Scope

1. 方法目标
2. 分析/执行方法
3. 判断标准 ... 附：输出检查而 SKILL.md 只负责：纯文本谁先谁后 每一步输入什么 每一步产出什么 最低交付要求这样你现在已经为 1b 建好的模式，就可以成为 1a～1e 的统一模板。最后，我给你一个明确判断这版不需要推倒重来。如果是我现在维护这个 Skill，我会按下面优先级改：优先级修改原因P0明确 §4 / §5 / §6 边界防止三章重复、导致文档膨胀P0强化 §7 的“相对谁”防止“优势”变成主观形容词P1统一“点名参考实装”的章节归属消除目录结构歧义P1§8 增加“不追求穷举”防止能力矩阵变成大表格P2将部分 ⛔ 句式改成正向规则与你的 Skill 设计原则一致P2把“五问”定义为核心模型提高整个方法论的稳定性尤其是 P0 的两个，我建议一定改。其他部分已经比较成熟，不建议继续加章节、加规则、加检查项了。再往里塞，很容易重新走回你最初想解决的那个问题：方法论越来越完整，但 Skill 本身越来越像说明书。