初始化提交：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 只排运行时日志、脚本备份副本与一次性探针输出，其余按原样入库。

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

@@ -0,0 +1,673 @@
+# 技能修法反馈：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 可以第二批一起做，但先审方法论，再做中文化。这比现在直接把三个英文文件全部翻译一遍稳得多。