从一个反复出现的问题，到 Tap to Share

我最早是在给 KikiMajo Studio 调研 NFC 冰箱贴时想到 Tap to Share 的。当时已经有商家把 NFC 用在 Google Review 上：顾客碰一下，就能直接打开评论页面，不用再自己搜索。

但我很快意识到，打开页面其实只是第一步。真正麻烦的是后面：写什么、怎么写、配什么图、发到哪里，都需要顾客继续花时间。

我自己作为顾客也经常这样。体验明明不错，也愿意支持商家，但一想到还要写内容、找图、选平台，最后往往就算了。

对商家来说，这套流程同样麻烦。做社交参与活动时，员工常常要反复说明活动规则、在哪里发、怎样发，以及有哪些图片或海报可以用；如果活动设有奖励，还要处理兑换和发放。这里说的是社交活动奖励，不是用奖励换取正面的 Google Review。

顾客在特别满意的当下，可能已经愿意分享，只是后面的操作和表达成本让他们停了下来。Tap to Share 想测试的是：如果在这个时候减少步骤，再提供可修改的文案和现成素材，参与会不会变得更容易。这个判断仍需要真实数据验证。

我在 BabySquare 也见过这个问题的另一面。一位不满意的顾客曾公开批评门店的售后体验，但门店当时其实一直在协助处理厂商保修。具体身份和沟通内容不会出现在案例里。真正让我记住的是：不满意的顾客往往更有动力公开发声，满意的顾客却很可能什么都不发。

第一版 Framer Demo 是我刻意做得很简单的：先给顾客一段可以直接使用的文案，让他们不用从零开始写。分享确实更快了，但新问题也很快出现——不同顾客拿到的内容太相似，发出来容易像统一发稿，而不是各自的真实表达。

预设文案让分享更省事，却也让内容越来越容易被看出规律。下一步很自然：改用 AI，让不同顾客拿到不同的文案。但真正难的并不是“写出不同版本”，而是让这些版本符合具体的顾客、场景、语言和平台，不要换了措辞，读起来却还是同一种“AI 味”。

文字不同，不代表表达自然。普通 AI 输出仍可能反复使用相似句式、泛泛的营销语言，或者写得过度完整，和实际平台上的表达习惯不符。因此，Tap to Share 需要一套带有具体背景和规则的生成方式，而不是简单的“提示词 → AI → 文案”。

主要证据

以前，一个想法要变成可以测试的产品，前面有很多工作：先查市场、整理信息、判断值不值得做，再把想法写成开发需求，找开发者沟通、等待、验收、反馈、修改。很多时候，假设还没开始测试，时间已经花在来回沟通上。

研究时，我会做市场探索、查询词和关键词发现，也会分析搜索意图。我也会通过 Monid 这类 API 工具做结构化的关键词和搜索研究，再结合结果判断市场里常用什么说法、用户怎样搜索，以及后续内容可以往哪里走。工具提供信息，产品判断仍由我来做。

研究方向、产品决定、MVP 范围、需求、AI 行为规则、QA 和迭代都由我负责。AI 用在研究、分析和需求整理上，Codex 负责代码开发。这样，构建、测试和调整之间少了很多外部交接。

以前，一个想法要真正做出来测试，往往先要投入开发时间和沟通成本。现在，我可以先自己把研究、MVP 和第一轮测试跑起来，再决定值不值得继续投入更多资源。

数据本身不会直接告诉商家答案。要先看顾客实际选了什么、用了什么、在哪里参与，再结合样本量和业务背景判断这些行为可能说明什么。一次选择不等于已经证明了偏好。等积累了足够的真实数据后，我再评估 SEO/GEO、获客和转化表现。