我最早开始想这件事时，想法也很常见：我做过几个项目，有过一些判断成功的经验，就会越来越容易相信自己的第一反应。但第一反应并不总是可靠。尤其是当你在做一些自己真正投入、也真正喜欢的东西时，人会天然高估它的完整度和独特性。
但真正进到产品迭代现场后，我先撞上的并不是"怎么写一份竞品分析"，而是更基础的几个问题：如果一个产品长期只活在自己的内部叙事里，就很容易停在自我感觉良好里。你会越来越熟悉自己的说法，也越来越容易被自己的说法说服。短期看，这种状态会给人一种推进顺畅的错觉；但时间一长，很多本该尽早暴露的问题，反而会被内部共识包住。
所以我后来更认可的一种做法是：竞品分析不只是信息搬运，而是一种成长机制——既帮助产品识别下一步怎么走，也帮助做产品的人修正自己的判断。
先看结论
我做竞品分析，不只是为了知道别人做了什么，而是为了让产品和做产品的人一起成长。
我不会一开始就先看竞品，而是先长出自己的判断，再用外部世界来校准它。
当这件事足够高频、足够关键，它就不该只是一次性动作，而值得被沉淀成一个 skill。
这篇文章想讲什么
我不是一个典型的产品角色，但只要我在推动一个项目、产品或者机制，我就会很在意一件事：它最后能不能经得起评价。
这里说的评价，不只是某一次会上别人点头认可，也不只是某一份材料看起来逻辑完整，而是把时间拉长以后，这个东西放到更大的参照系里，是否仍然站得住。它解决的是不是真实问题，走的是不是值得继续走的路径，和外部已经被验证过的方案相比，到底强在哪里、弱在哪里、还缺了什么。
如果一个产品长期只活在自己的内部叙事里，就很容易停在自我感觉良好里。你会越来越熟悉自己的说法，也越来越容易被自己的说法说服。短期看，这种状态会给人一种推进顺畅的错觉；但时间一长，很多本该尽早暴露的问题，反而会被内部共识包住。
这也是我越来越看重竞品分析的原因。对我来说，它不是一个附属动作，而是一种成长机制：它既帮助产品识别下一步该怎么走，也帮助做产品的人修正自己的判断。也正因为这样，我最后没有把它停留在"偶尔做一份分析"的层面，而是把它慢慢沉淀成了一个 skill。
为什么我不会一开始就先看竞品
一句话说，我更相信"先长出自己的判断，再接受外部挑战"。
如果要把我更习惯的工作顺序画出来，大概是这样：
我不会一开始就把自己的想法完全交给外部答案，但我也不会让一个雏形长期停留在自己的内部叙事里。
这一步看上去有点"重复造轮子"的味道，效率上也不一定总是最优，但我一直觉得它有价值。因为只有先自己想过一遍，你才会真正知道：你眼里的问题到底是什么问题，你第一反应会怎么拆，你最自然会优先哪些能力，你为什么会觉得某个机制值得存在。
如果没有这一层自己的思考，后面的竞品分析很容易退化成信息搬运。你看了很多东西，也列了很多功能点，但说不清什么地方真正重要，什么地方只是表面相似，什么地方才值得拿来作为自己的判断参照。
竞品分析到底让谁成长
一句话说，它同时服务于产品成长和人成长。
对产品
竞品分析最直接的价值，是帮助产品更早看到这些问题：
- 哪些能力已经是行业共识
- 哪些地方别人确实做得更成熟
- 哪些原来以为是优势的东西，其实没有想象中那么独特
- 哪些方向才真正值得继续拉开
它能让这些问题更早暴露出来，而不是等到后面再用更大的试错成本去补课。
对人
做产品的人也很容易陷入经验惯性。你做过几个项目，有过一些判断成功的经验，就会越来越容易相信自己的第一反应。
但第一反应并不总是可靠。尤其是当你在做一些自己真正投入、也真正喜欢的东西时，人会天然高估它的完整度和独特性。竞品分析在这里的意义，是帮你修正自己。它逼着你去建立比较维度，重新理解别人的解法为什么成立，承认某些地方别人确实做得更好，也识别哪些地方自己有机会走出不一样的路。
所以对我来说，竞品分析不是单向地为产品服务，它同时也是训练做产品的人的方法。
为什么这件事值得被做成一个 skill
一句话说，我不是想把"搜索"自动化，而是想把"进化输入"稳定化。
当这件事重复发生几次之后，我开始意识到：如果每次都只是临时做一轮竞品分析，它的质量其实很不稳定。
常见的问题是：
- 找到的是表面上很像、但并不值得深比的对象
- 列出了一堆功能差异，却没有进入真正的判断层
- 结论写出来了，后面却没有真正回流到迭代里
这也是我最后决定把它做成一个 skill 的原因。
真正让我想沉淀的，不是"怎么更快搜到资料"，也不是"怎么更快写出一份竞品分析"，而是怎么让这件事更稳定地发生。也就是说，什么值得比较，应该用哪些维度去比较，比较完以后哪些判断要进入后续迭代，这些都不能每次都靠临时发挥。
这个 skill 在我这里，主要是在做三件事：
- 识别什么值得比较
- 建立稳定的比较维度
- 让比较结果回流到后续迭代
如果把这件事画得再具体一点，它更像这样一个闭环：
以 Maglev 为例：竞品分析怎样进入真实迭代
Maglev 是一套帮助团队在 AI Coding 时代稳定协作的软件研发对齐方法。
一句话说，Maglev 不是"分析过"，而是已经把这些分析真正用起来了。
Maglev 已经产出过真实的竞品分析材料，并且这些材料已经在实际迭代中使用过。更重要的是，这种作用不只发生在已经完成的迭代上，也发生在正在准备的迭代上。
如果只抽几个更有代表性的例子，大概能看到三种很典型的作用。
案例 1：帮助定位变化
Combo Stack 趋势分析：Superpowers + OpenSpec + gstack
在对组合式工具栈的分析里，Maglev 不再只是把自己理解成"一个更完整的一体化方案"，而是进一步长出了"集成优先、接口开放"的判断。
这类分析带来的不是一句口号，而是很具体的后续动作，比如要不要把 spec 输出、tasks 输入、validation 结果这些关键接口标准化，让用户既能享受一体化深度，又不会因为过重而放弃采纳。
案例 2：帮助把方向压成动作
GitHub Spec Kit 深度研究报告
在对 GitHub Spec Kit 的研究里，价值不只是确认了很多理念上的相似性，更重要的是它把一些原本比较抽象的演进方向压成了可执行项。
比如多平台适配层、不同场景的 preset 初始化模板、以及未来 skill 分发可能需要的 extension 方向，这些都已经不是"知道别人怎么做"，而是能直接进入后续设计和实现准备的输入。
案例 3：帮助把短板说具体
Maglev vs Superpowers：客观深度对比
在和 Superpowers 这类体系做对比时，Maglev 也不是只在找自己的优势。更有价值的是，它把一些短板说得更具体了，比如编码纪律的强制程度还不够、subagent 并行和独立 review 的能力还没有真正建立起来、上手门槛和概念负荷依然偏高。
这种分析的意义，不是让自己显得更强，而是让后面的补强方向更清楚。
而当你看到最新版本的 Maglev 这个结合已经完成了。
如果只看 Maglev 这个例子，这个关系可以再压缩成一张更直观的图：
我真正想沉淀下来的是什么
一句话说，我想沉淀的不是一份报告，而是一种工作方式。
回头看，我真正想沉淀下来的，其实不是一篇竞品分析报告，也不是一个看起来很厉害的工具，而是一种工作方式：
- 先允许自己长出判断
- 再主动把这个判断放回更大的外部参照系里
- 用这个过程推动产品继续成长，也推动做产品的人继续成长
当这套能力慢慢稳定下来以后，它也会自然帮助我把很多判断讲得更清楚。无论是对齐认知、做阶段性表达，还是准备一些正式的材料，它都会让"为什么这样判断、接下来为什么这样做"这件事更容易说清楚。
也许我不是产品经理，但只要我认真推动一个产品、机制或者项目，我就不希望它停在原地，也不希望我自己的判断停在原地。
这也是我持续做竞品分析，并最终把它沉淀成一个 skill 的原因。
相关资源：
competitive-analysisSkill：https://github.com/Idea-Maglev/alpha-agents/tree/main/competitive-analysis- Maglev 项目：https://github.com/Idea-Maglev/maglev
evolution-observatorySkill：配合 Maglev 的特化版 competitive-analysis