first-customer-finder

首批客户发现器

将创业项目 URL 或产品描述转化为一份简短且有证据支持的潜在首批客户名单。使用公开信号，保护隐私，并区分潜在客户与已确认买家。

在研究或评估潜在客户之前，请先阅读 references/research-framework.md；在创建最终报告之前，请先阅读 references/report-artifact.md。如需保存历史记录、反馈或重复搜索，也请阅读 references/feedback-and-history.md。

默认使用英语；如有明确的语言要求，则按要求使用。聊天交接内容应简短，并将有用的细节放入报告。研究需要可用的网页搜索／浏览工具；附带的 Python 辅助工具仅用于验证、导出和管理本地文件。如果无法实时浏览，请说明这一限制，而不要编造潜在客户。

工作流程

1. 了解产品

• 检查提供的 URL、代码库、着陆页文案或产品描述。
• 确定产品、预期成果、买家、用户、价格或购买方式、地域以及最重要的使用场景。
• 定义一个主要 ICP、一个相邻 ICP、痛点触发因素、积极信号和排除条件。
• 在安全的前提下推断缺失的背景信息，并标明推断内容。只有在歧义会实质性改变搜索结果时，才提出一个简洁的问题。
• 使用一个稳定且专属于该产品的工作区文件夹。如果其中已有历史记录，请在搜索前查看已保存的偏好和排除的潜在客户。切勿仅因其他产品的历史记录就在附近而加载它。简要说明历史记录将保存在哪里；如用户要求不保存历史记录，则应尊重该要求。

2. 制定公开信号搜索计划

搜索当前的公开来源，查找：

• 明确提出的工具或替代方案需求
• 第一人称描述目标问题的内容
• 手动工作流程和反复出现的变通方案投诉
• 迁移、流失或对竞争对手不满的信号
• 能够创造合适时机的公司公开动态，例如招聘、发布产品、扩张或采用相关工作流程

使用多种搜索角度和来源类型，包括可访问的公开 X 讨论、GitHub 问题、论坛、评论和公司页面（如相关）。搜索引擎仅用于发现线索，不能作为证据。打开原始页面，分别记录发布日期和查看日期，并将信号归因于实际作者／公司。如果来源被屏蔽，或只能看到摘要，则不要将其纳入符合条件的候选名单，并说明覆盖范围的缺口。不要暗示已搜索过所有平台。

3. 安全开展研究

• 仅使用公开且有意分享的专业或商业信息。
• 不得绕过登录墙、付费墙、访问控制、速率限制或 robots 限制。
• 不得使用数据经纪商、泄露的数据集、私人群组、个人电子邮件查找服务、电话号码补充服务或敏感个人信息。
• 不得推断受保护特征，也不得使用健康状况、经济困难、政治信仰、性取向、宗教或其他敏感属性来定位他人。
• 优先选择与产品相关的公司、公开的专业资料、公开需求和社区帖子。
• 尽量少引用，默认采用转述。所有重要的痛点或时机信号都必须附上链接。

4. 评估并去重

使用随附框架为每个潜在客户打分：

• 痛点强度
• 产品契合度
• 时机
• 公开联系渠道的可达性
• 证据质量

删除重复项和不匹配的对象。将经过核实的公司主页或公开职业资料作为 entity_url，不要只填姓名，也不要填写共享平台主页。一个对象可能有多个信号。没有引用痛点、需求或时机信号的潜在客户只能算推测性匹配，不得列入主要候选名单。

核实问题是否已解决、作者是在销售而非购买、产品是否缺少必需功能，或买方是否不符合指定画像。将重要的反面证据写入注意事项，或排除该候选对象。高数值评分不能凌驾于矛盾证据之上。绝不要为了凑足指定数量而纳入不匹配的对象。

绝不要声称某个潜在客户感兴趣、已表示同意或会购买。将输出标注为“基于公开信号的潜在客户”。

5. 起草外联内容，但绝不发送

• 确定目标职位／职能，并标注为已观察到或推断得出。不要捏造具名决策者。
• 核实具体的官方／公开联系渠道：相关公开讨论帖、已发布的商务联系页面，或公开职业资料。记录其 URL 并说明为何合适。存在公开渠道不代表可以在那里推广；请查看相关社群规则。若找不到合适渠道，请如实说明并给出人工研究的下一步，不要猜测邮箱地址。
• 使用买方的问题表述，写一条简短的开场消息，并附上具体、低门槛且对方可以接受、拒绝或转发的 CTA。提供切实可行的下一步，例如工作流评估、检查清单或演示。除非已经核实，否则不要声称现有资产、集成、客户成果或功能已经具备。
• 避免假装认识对方、夸大熟悉程度，或提及无关的个人信息。
• 除非用户另行请求并授权，否则不要发送消息、提交表单、建立联系、关注、评论或创建 CRM 记录。

6. 生成报告并保存下一轮搜索的上下文

优先呈现最具可执行性的证据。按以下顺序组织：

1. 结论 — 该初创公司是否有可触达的早期客户信号。
2. ICP — 买方、职责、触发因素和排除条件。
3. 首要潜在客户 — 证据最充分的候选对象，以及为何现在联系。
4. 潜在客户候选名单 — 稳定 ID、来源／日期、评分、为何现在联系、目标职位、已核实的联系渠道（或缺失的渠道）、具体下一步、CTA、开场消息和注意事项。
5. 重复出现的模式 — 多个潜在客户中反复出现的痛点和触发因素。
6. 七天外联计划 — 人工执行、低频率的验证流程。
7. 局限 — 缺失的证据，以及必须通过真实对话确认的内容。

默认创建原生 Markdown 报告和 CSV。保留独立的 HTML 选项；仅在用户提出请求时生成。遵循用户明确提出的仅在聊天中回复或格式偏好：

1. 使用 references/report-artifact.md 编写结构化 JSON。
2. 使用明确的输出路径运行随附生成器；除非用户拒绝，否则同时指定产品的本地状态路径。生成器会计算评分、验证 v2 数据、导出 Markdown／CSV／可选 HTML，并保存精简历史记录。使用全新的运行文件夹，以保留之前的报告。
3. 核实报告、引用、实际纳入的潜在客户数量、联系渠道和草稿。导出 CSV 不会发送任何内容，也不会与 CRM 同步。
4. 返回 Markdown 文件的绝对路径链接；若可使用 Codex 文件打开工具，则在当前任务中打开报告。其他安装环境不要求必须使用该工具。
5. 邀请用户使用显示的 ID 简短反馈，例如：“P1 和 P3 符合要求；避免企业买方。”不要等待反馈后才提交第一份报告。

7. 根据用户反馈进行优化

保存明确的保留／待定／拒绝反馈及其原因。将明确的一般偏好转化为更新后的搜索条件，并在开始新一轮搜索前说明变更内容。拒绝一家公司的产品，并不意味着要排除其整个行业；如果这一区别会影响结果，请简短询问。“学习”指可见的本地偏好更新，而非模型训练。

用户要求寻找更多／新的潜在对象时，使用 --new-only，保留产品范围，并排除之前见过的实体，以及已联系／已拒绝的记录。用户要求刷新时，则重新验证已保存的来源。只有用户提供相应结果时，才能将某人标记为已联系、已回复或客户。绝不要把生成草稿视为已联系对方。不要因普通的后续搜索而启动定期监控。

模式

• quick：寻找并筛选最多五个优质潜在对象。
• standard：从多种公开来源中寻找最多十个潜在对象。
• deep：研究最多二十个潜在对象，并梳理反复出现的痛点模式。
• design-partners：优先寻找愿意测试并提供反馈的用户，而非立即购买的用户。
• b2b：优先考虑公司、公开的业务动态和相关决策角色。
• community：优先考虑公开讨论和明确的需求信号。

默认使用 standard。

质量标准

• 为每个潜在对象至少提供一个有意义的公开信号链接。
• 宁可提供十个高度匹配的对象，也不要提供一长串泛泛的潜在客户名单。
• 明确呈现不确定性和过时证据。
• 根据来源进行个性化，不要编造假设。
• 保持人工联系，并尊重对方。
• 将候选名单视为研究假设，而非客户数据库。
• 本地历史记录和研究结果不得放入技能仓库和 npm 包中。所有输出格式中的演示数据都必须明确标注为虚构。