Communitygithub.com

这个想法已经有原型了吗?

对于几乎任何想法,都有人已经构建过某个版本。在AI agent开始构建之前,检查一下已存在的内容。

这个想法已经有原型了吗? 是什么?

这个技能旨在防止AI agent在未知情况下重复造轮子。它通过在用户表达构建意图时触发一次快速扫描,自动检查现有解决方案、竞争对手、开源组件和相关工作。技能的核心哲学是“顾问而非守门人”——它会提供一份诚实、可操作的景观报告,涵盖直接产品、相邻方案、组件和废弃项目,然后让用户决定是否继续构建。该技能支持快速(约50k token)和标准(约150-300k token)两种模式,通过精心设计的查询策略覆盖不同领域(软件、硬件、品牌、服务),并帮助用户识别真正的空白和差异化方向。最终,它旨在将上下文成本控制在最低(仅名称和描述常驻上下文),仅在必要时才加载完整指令和扫描资源。

兼容平台~Claude Code~Codex CLI~Cursor
npx skills add n-any-i/is-there-a

在你喜欢的 AI 中提问

打开一个已预加载此 Agent Skill 的新对话。

文档

这个想法已经有原型了吗? 是做什么的?

为什么存在

对于几乎任何想法,都有人已经构建过某个版本。这并非坏消息——它是最廉价的信息来源。它表明什么是已解决的、什么是困难的、人们在抱怨什么,以及真正的机会在哪里。

代价高昂的错误不是构建已存在的东西,而是花费三周时间在不知情的情况下重新构建它,然后在展示给朋友时才得知。

有两件事使得自动运行此检查比留给用户更值得。首先,最需要检查的人往往是那个根本不会想到去问的人——而且即使他们想到了,也常常不知道如何措辞搜索。其次,Agent被调优为执行模式:给定“我想构建X”,默认行为就是开始构建X。此技能存在的目的就是在该反应前插入一个廉价的步骤。

定位:顾问,而非守门人

  • 提供扫描,不要强加。只需一行话,然后根据答案行动。
  • “这东西已存在”本身绝不是停止的理由。大多数好产品都是第五个入场者。
  • 永远不要评判想法是否原创。报告已存在的东西;让用户决定。
  • 如果用户说“跳过”、“直接构建吧”,或者表现出不耐烦——立即放弃,说明可以稍后扫描,然后开始构建。在该会话中不再重新提议。
  • 不要引导用户使用付费研究产品或“如需更深入分析,请尝试X”类型的服务。如果他们想要比标准扫描更深入的内容,告诉他们自己搜索什么。

何时触发

在构建意图时触发——用户正在描述他们打算制作的东西。这不仅限于软件:

  • “我想构建一个CLI工具,将我的git历史汇总为每周变更日志”
  • “帮我设计一个宠物主人可以找到附近遛狗人的应用”
  • “我在考虑做一个Chrome扩展,从URL中去除跟踪参数”
  • “我想创建一个免煮咖啡品牌,供没时间冲泡的人使用”
  • “我想设计一个停车场指示牌,告诉司机哪里有空位”
  • “我正在设立一项服务,帮助老年人数字化旧相册”

不要为以下情况触发:

  • 在现有项目内部的工作——错误修复、重构、已构建内容的特性添加
  • 以自己构建为目的的学习练习(“帮我做一个玩具路由器来理解它们”)
  • 没有产品面的内部一次性脚本
  • 纯粹创意或执行性任务:命名、徽标、草图、模型、文案、活动概念、情绪板。“为我的咖啡品牌设计徽标”不是构建意图——它是对已经决定的事情的设计任务。“我想创建一个咖啡品牌”才是。
  • 此会话中已进行过扫描,或用户拒绝了

关键区别在于:他们是决定要做什么,还是在执行已经决定的事情?只有前者需要此检查。

如果用户明显处于流畅状态且只想得到输出,请先给他们输出,之后再提供扫描。打断动量是有实际代价的。

开场白

简要地问一次,并让成本可见,以便用户能知情选择:

在我们构建之前——想让我检查一下已经存在什么吗? 快速(约2分钟,约50k token)或标准(约10–15分钟,约200k token,书面报告)。 快速通常就足够了。说“跳过”我就直接去构建——如果你有特别想让我查找的内容,请告诉我。

快速是默认选项。 如果用户说“是”而没有选择,就运行快速模式。扫描本质上是迭代的:快速扫描成本低,能告诉你是否需要深入,其结果也为标准扫描指明查找方向。一开始就深入会花费token来阐述一个形状已经显而易见的领域。

如果用户提到了一些特定的内容(“检查一下欧洲有没有人在做这个”、“我在意它是不是开源的”),将其作为额外重点纳入——但保持标准结构,不要因为一个请求而缩小整个扫描范围。

模式预算输出
快速(默认)4-6次查询,2-3次验证,约2分钟聊天摘要,无文件
标准8-12次查询,6-8次验证,一次投诉挖掘,约10-15分钟书面报告 + 简短聊天摘要

第1步 — 搜索前撰写扫描规范

糟糕的扫描源于搜索用户的产品名称而不是他们的问题。首先将想法压缩为五行并展示给用户,以便他们可以纠正你:

想法:      一句话,用平实的语言
任务:      用户的用户雇佣此事物来完成的任务
谁:        具体哪些人有这个问题
机制:      怎么做——技术、物理或服务方法
优势点:    用户认为自己的约束或洞察

优势点最重要——这是你重点检查的内容。“待办事项应用”很拥挤;“能读取你的日历并拒绝让你过度承诺的待办事项应用”可能就不拥挤。如果用户没有阐明优势点,就指出来。缺失优势点本身就是一项值得在开始构建前浮现的发现。

第2步 — 跨越命名鸿沟进行搜索

最大的失败模式是搜索一种措辞,什么也没找到,然后宣称领域是空的。做相同事情的产品很少使用相同的词汇。在搜索前,从四个角度生成查询:

  1. 用户的词汇——他们是如何描述的
  2. 行业的词汇——该领域的供应商会在定价页面或软件包上使用什么词
  3. 用户的用户的词汇——一个沮丧的人会在晚上11点用哪些关键词搜索这个问题
  4. 相邻类别——这将是哪个已建立类别的一个功能或变体

然后搜索与所建事物类型相匹配的表面——软件、物理产品、品牌或服务,它们存在于不同的地方。references/search-playbook.md包含按产品类型划分的完整表面图、查询模式以及如何挖掘投诉和分发信号。

两条规则确保结果诚实:

  • 空结果意味着糟糕的查询,直到被证明并非如此。 在写下“没有直接竞争对手”之前,至少再运行两个角度和一个不同的表面。真正空的类别确实存在,但很少见,错误地宣称一个空类别是此技能可能犯的最糟糕的错误。
  • 在列出前验证。 打开页面、列表或仓库。永远不要仅凭搜索摘要列出内容——废弃的项目、更名的产品和AI生成的列表文章在摘要中都看起来真实。在可见的地方记录最近提交、最近发布或“最后更新”时间。

没有网络访问权限?请遵循references/no-search-fallback.md——从模型知识中进行有用的扫描仍然是可能的,但必须标记为未验证,并以用户应该运行的查询结束。

第3步 — 分为四个命名组

使用这些名称,不要用数字——编号的层级会在一个层级缺失时留下一个可见的空洞,而空洞会被解读为数据丢失。

  • 直接命中 — 相同的任务,相同的用户,可比较的机制
  • 相邻 — 相同的任务/不同的用户,或相同的机制/不同的任务。大多数差异化创意的来源
  • 组件 — 解决部分问题的库、API、服务、供应商、制造商。通常构建的大部分内容已经可用
  • 坟墓 — 废弃的仓库、关闭的公司、停产的产品、已弃用的功能。最被低估的组:坟墓告诉你失败的模式,有时也告诉你使能条件已经改变

每个组都必须有一个状态行,始终如此。 必须是以下之一:

  • 找到3个(然后是条目)
  • 未找到 — 已搜索,确实为空
  • 未在此深度搜索 — 因预算跳过

一份隐瞒了未检查内容报告会破坏此技能唯一的价值主张:其输出可以比非结构化聊天更可信。永远不要让读者猜测他们看到的是哪种缺失。

第4步 — 诚实地映射重叠

对于想法中的每个能力,标记已解决(具体是哪些产品)、部分解决(具体是什么限制)或开放。要具体——“Notion AI能总结页面但不能作用于外部工具”是有用的;“Notion是类似的”则不然。

第5步 — 从证据而非想象中寻找空白

空白必须追溯到你实际阅读的内容:

  • 直接命中产品上的1-3星评论和支持帖子——用户因什么而流失
  • 有大量反应但长期未回答的开放问题或功能请求
  • 在论坛和社区帖子中,有人确切地要求这个但得到了不满意的答案
  • 定价——谁被价格排除在外,什么被锁在顶层之后
  • 覆盖空白——一个平台、一个地区、一种语言、一个细分市场、一个合规制度

注明每个空白的来源。你推断出的任何内容应放在单独的假设列表中,并明确标记。一个想象的空白比没有空白更糟糕,因为它看起来像验证。

真正的既有解决方案通常不是一个产品。 在断定一个领域是空的说法之前,问问人们今天在没有工具的情况下怎么做——一个群聊、一个电子表格、一个Instagram账户、一个WhatsApp广播、一个门边的剪贴板。那个变通方案才是需要击败的,并且通常更好的做法是接入它而不是取代它。要求人们采用一个新的目的地是这些想法悄悄失败的最常见方式。

第6步 — 差异化方向,然后给出裁决

提供3-5个方向,用定位而非特性的措辞表达——“那个在数据不能离开建筑物时使用的本地优先方案”、“那个发布到人们已经在使用的群聊中的方案”、“90%用例免费,团队付费”。每个都要说明背后的证据以及大致成本。

指出分发所在。对于此规模的多数想法,被找到比构建更难——因此如果你注意到现有参与者如何获得用户(一个目录、一个市场、一个社区、一个合作伙伴关系、作为更大事物内部的一个功能),就说出来。那个观察通常比特性分析更有价值。

然后给出一个裁决,附上理由(评分标准在references/verdict-rubric.md中):

  • 构建它 — 真正的空白,或现有竞争者薄弱、停滞或定价不当
  • 构建更窄的它 — 通用版本已被占用;特定的细分市场还没有
  • 封装它 — 已有某种东西完成了困难部分;价值在于其上的一层
  • 分支或扩展它 — 一个开源项目已经完成了大部分工作并且允许这样做
  • 使用已有的 — 说实话,他们想要的东西已经存在且运行良好;直说一次,然后尊重他们仍想构建的决定
  • 重新定义它 — 坟墓表明这种框架行不通;这里是相邻的框架

始终附带**“什么会改变我的想法”**——用户知道但你可能不知道的、会翻转裁决的事情。他们的背景通常胜过扫描的结果。

第7步 — 交付,然后将对话交回

快速: 在聊天中总结。除非被要求,否则不生成文件。

标准: 按照assets/LANDSCAPE-template.md编写报告,注明日期,列出搜索过的表面以及未搜索的。将其保存为项目目录中的LANDSCAPE.md(如果存在docs/目录则保存在该目录下)。然后给出简短的聊天摘要——最接近的现有事物、最尖锐的空白、裁决——并且不要重复报告内容。

然后以问题的形式提供后续步骤,并等待。 不要在未经询问的情况下生成规格、简报或仪表板——重点是将方向盘交还给用户,同时提供更好的信息,而不是产生更多文档。选择两到三个适合扫描实际情况的后续步骤:

  • “这次运行我跳过了[表面]——想让我检查它们吗?”
  • “想根据发现来头脑风暴一下构建什么吗?”
  • “想深入了解这些竞争者中的任何一个吗?”
  • “想让我把发现写成一份交接笔记,以便你可以在新的对话中使用它吗?”
  • “你需要向某人展示这个吗?我可以为此准备。”
  • “准备好构建了吗?我建议从[能测试优势点的最小事物]开始。”

如果用户只想构建,那就构建。扫描服务于构建;它不是交付物。

成本及加载方式

新用户经常担心安装此技能会使每个对话变得更昂贵。如果提到这点,值得直接解释:

  • 只有名称和描述永久驻留在上下文中——大约200个token,大约一个段落。这是在技能从未触发的会话中安装它的全部成本。
  • 这些指令(约2500个token)仅在技能触发时加载。
  • 参考文件仅在扫描实际需要时加载。
  • 扫描本身是实际成本:快速模式约50k token,标准模式约150-300k token。这就是为什么模式选择要附带数字,而不是静默选择的。

参考文件

  • references/search-playbook.md — 按产品类型(软件、硬件、品牌、服务)划分的表面,查询模式,投诉和分发挖掘
  • references/verdict-rubric.md — 在构建/更窄/封装/分支/使用/重新定义之间做出选择
  • references/no-search-fallback.md — 在没有网络访问的情况下进行诚实的扫描
  • assets/LANDSCAPE-template.md — 报告结构

应避免的失败模式

  • 列表文章洗钱。 “X的十大工具”页面是联盟营销SEO内容,通常列出废弃或不相关的产品。将它们用作候选名称,切勿用作证据。
  • 大品牌充数。 将Google、Amazon或Notion列为小众创意的竞争对手是噪音。只有当他们做的具体事情确实重叠时才包含现有巨头。
  • 沉默的遗漏。 永远不要在一个组仅仅是未被搜索过时将其呈现为缺失。参见第3步。
  • 扫描范围蔓延。 这是一个构建前检查。在标准扫描进行到20分钟时,停止并交付。
  • 因数量而气馁。 一长串竞争对手列表即使不是这个意思也会被解读为“别费心了”。用空白和裁决开头,而不是数量。
  • 将过时的视为活的。 三年未更新的是坟墓,不是竞争。标记出来。
  • 推荐转移。 不要引导用户使用付费研究工具。给他们查询即可。

相关技能