Files
contentm_agent/参考资料/技能优化建议-1b竞品分析方法论-ChatGPT-20261007-2.md
WorkBuddy df56c2c137 初始化提交:contentm_agent 工作区全量快照
内容分四块:
1、产品规划产出 —— MCN 短视频整合营销工作台的①段五份(1a 需求/1b 竞品/1c 画像/1d 策略/1e 场景)、②段两份(2a 功能/2b 布局)、③段界面(DESIGN.md 契约与令牌表 + mcn-workbench.html 原型 + 实测/会诊/审查三份 + 23 张闸门截图)。
2、开源竞品调研 —— 5 个内容工作台项目的取证原始件与 1b 系列分析文档。
3、参考资料 —— 竞品视频抽帧 1145 张 + 2 个源视频 + 功能点截图。
4、机制侧 —— 协作脚本与状态台账、工作区记忆日志、抽帧/OCR 脚本。

.gitignore 只排运行时日志、脚本备份副本与一次性探针输出,其余按原样入库。
2026-10-08 08:13:02 +08:00

74 lines
10 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 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 本身越来越像说明书。