2026-07-19 05:31:21
黑洞足迹本是我的第二个一人 APP。第一个是黑洞健身。
大家有没有想过,我们这辈子去了很多很多的地方,但是很多地方最后都忘记了。有些时候想找也找不到那个地方在哪儿了。
另外,在工作方面,我们需要记录大量的合作伙伴的地址,方便出差的时候拜访。但是这些地址并没有一个特别方便的地方保存和查询。
我之前是在高德地图上把相关的地址收藏起来,再加上相应的标签和备注。但是这些信息并不容易搜索,也不方便对我的 AI 大模型开放。
于是我做了黑洞足迹本。这是一个 AI 时代的一人 APP。结合了 AI 大模型对自然语言理解的能力和向量检索数据库。
黑洞足迹本有两个功能。
第一个功能是可以对一个地址添加相关的图片和文字描述。如下图:

AI 会根据你的描述对地址进行分类,打上相关的标签。如下图:

第二个功能是可以用 RAG 向量检索的方式查找之前索引的所有地址。比如我问它,我之前吃过的一家面馆很好吃,它就帮我找到了我刚刚记录的那条。

在未来,我还打算让它关联我的相册,自动把我的足迹与照片匹配,并且开放 MCP 接口。
这样,以后这些问题 AI 都可以帮我回答了:
“3 年前的大学同学聚会,我们在学校附近的餐馆聚餐,具体是哪家餐馆?”
“过去 5 年我去了哪些城市?”
“下周我要去上海拜访达人,帮我把达人 A、B、C 的地址都调出来,安排一下相关的行程,尽可能顺路。”
“我去年去新疆旅游的时候,吃过一家面馆,特别好吃。帮我找出来是哪家。”
“我 10 年前的小学地址现在不见了,你帮我找一下当时的地址上现在是什么建筑”
是不是很有意思?技术实现上,我用了 Deepseek v4 PRO 的 API 做语义识别,用 Cloudflare 搭的免费服务器和向量数据库,用高德地图 SDK 做的本地地图渲染和 POI 获取。
如果你感兴趣,你也去开发一个自己的一人 APP 吧。
2026-07-12 22:05:00
平台:macOS(Apple Silicon / Homebrew)· 版本:CLIProxyAPI 7.2.65
如果你手上有 ChatGPT/Codex 的订阅账号,却想在自己的脚本、IDE 插件或第三方工具里以「标准 OpenAI API」的方式调用它,CLIProxyAPI 就是干这件事的。它能把 Gemini CLI、Codex、Claude Code、Qwen Code 这类基于 OAuth 登录的 CLI 工具,统一包装成一个本地的、OpenAI 兼容的 HTTP 服务。
本文记录一次真实的安装与配置过程:从 brew install 到登录 Codex,再到起服务、验证,最后还踩了一个 Surge 代理拦截本地请求 的坑。
1 |
brew install cliproxyapi |
安装完成后,几个关键路径值得记一下(Apple Silicon 下的默认位置):
| 项目 | 路径 |
|---|---|
| 可执行文件 | /opt/homebrew/bin/cliproxyapi |
| 配置文件 | /opt/homebrew/etc/cliproxyapi.conf |
| 认证目录(存放 OAuth token) | ~/.cli-proxy-api |
| 默认监听端口 | 8317 |
看一下它支持哪些登录方式:
1 |
cliproxyapi --help |
输出里能看到一堆 -xxx-login 选项,我们关心的是这两个:
1 |
-codex-login Login to Codex using OAuth |
这是整个流程的核心。直接运行:
1 |
cliproxyapi -codex-login |
它会:
/opt/homebrew/etc/cliproxyapi.conf,把 token 存到 ~/.cli-proxy-api;登录成功后,你会在认证目录里看到一个以账号命名的 JSON 文件:
1 |
$ ls -la ~/.cli-proxy-api |
没有图形界面 / 远程服务器? 改用设备码流程或禁止自动开浏览器:
1
2 cliproxyapi -codex-device-login # 设备码,在别的设备打开链接授权
cliproxyapi -codex-login -no-browser # 不自动开浏览器,自己复制链接
打开配置文件 /opt/homebrew/etc/cliproxyapi.conf,默认的 api-keys 是一组占位符:
1 |
api-keys: |
这是客户端调用你这个代理时要携带的密钥(Bearer Token),和上面的 Codex 登录是两码事。建议换成你自己的一个强随机值。生成一个:
1 |
echo "sk-$(openssl rand -hex 24)" |
然后把配置改成(只保留你需要的即可):
1 |
api-keys: |
配置文件里其它值得留意的字段:
1 |
port: 8317 # 监听端口 |
用 Homebrew 的 services 管理,后台常驻 + 开机自启:
1 |
brew services start cliproxyapi |
确认状态和端口:
1 |
brew services list | grep cliproxy # 应显示 started |
如果只想临时前台运行、方便看日志,直接跑
cliproxyapi即可。
服务地址是 http://127.0.0.1:8317/v1,接口是 OpenAI 兼容格式。
1 |
KEY="sk-你的密钥" |
能返回一批模型(Codex 账号可用的 gpt-5.x 系列,如 gpt-5.5、gpt-5.4、gpt-5.4-mini、gpt-5.3-codex-spark、codex-auto-review 等)就说明 token 生效了。
1 |
curl http://127.0.0.1:8317/v1/chat/completions \ |
拿到类似下面的响应(content: "ok"、usage 有计费),就彻底打通了:
1 |
{ |
第一次 curl 验证时,我拿到的不是 JSON,而是一个 Surge 的错误页:
1 |
<h1>Connection Closed</h1> |
原因:系统里开着 Surge,curl 默认走了系统代理,发往 localhost:8317 的请求被 Surge 拦下并试图代理,结果失败。
临时绕过(命令行直连本地):
1 |
curl --noproxy '*' http://127.0.0.1:8317/v1/models -H "Authorization: Bearer $KEY" |
长期解决(在 Surge 配置里让本地环回直连)——把这条规则放在 [Rule] 的靠前位置:
1 |
[Rule] |
几点说明:
127.0.0.0/8 是整个环回段(IANA 保留),全部直连安全,涵盖 127.0.0.1;no-resolve 表示匹配这条规则时不做 DNS 解析,只对 IP 字面量请求生效——正好对应我们用 127.0.0.1 直连的场景,还能避免为域名请求触发多余解析;⚠️ 注意:因为加了
no-resolve,这条规则不匹配localhost这个主机名。如果你习惯用http://localhost:8317,再补一条:
1 DOMAIN,localhost,DIRECT
改完重载 Surge 配置后,curl 就不用再加 --noproxy '*' 了。
除了改 YAML + 敲命令,CLIProxyAPI 还内置了一个 WebUI 管理面板(CLI Proxy API Management Center,简称 CPAMC)。它由服务从 GitHub 自动下载并托管,不用单独安装。
http://127.0.0.1:8317/management.html
不过它默认是关闭的:配置里的 remote-management.secret-key 为空时,整个管理 API(/v0/management/*)会返回 404——面板页面能打开,但里面所有操作都用不了。这也是安全默认值。
1. 设置管理密钥(配置文件 remote-management 段):
1 |
remote-management: |
生成一个密钥:
1 |
echo "mk-$(openssl rand -hex 24)" |
2. 重启服务:
1 |
brew services restart cliproxyapi |
3. 打开面板并用这个 key 登录:
1 |
http://127.0.0.1:8317/management.html |
启用后可以验证一下:管理 API 会从 404(禁用)变成 401(启用并强制鉴权),带上 key 则返回 200:
1 |
SK="你的管理密钥" |
管理 OAuth 账号(登录 / 登出 / 多账号池)、增删 API key、编辑配置、查看模型与请求状态等——基本就是把前面手动改 YAML、跑命令的事图形化了。
⚠️ 两个坑要注意
- 明文密钥保存好:服务启动时会把配置里的
secret-key自动改写成 bcrypt 哈希($2a$10$...),之后配置文件里就看不到明文了。明文只有你自己留存的那份,弄丢就得重设一个再重启。- 访问前确认 Surge 规则生效:浏览器打开
127.0.0.1:8317同样会被 Surge 拦,先确保上一节那条IP-CIDR,127.0.0.0/8,DIRECT,no-resolve已生效。安全上
allow-remote保持false(仅本机)。真要跨机访问,务必配 TLS + 强 key,别把账号管理接口裸暴露到网络上。
由于是 OpenAI 兼容接口,绝大多数支持自定义 base_url 的工具都能直接接:
1 |
export OPENAI_API_KEY="sk-你的密钥" |
Python SDK 示例:
1 |
from openai import OpenAI |
1 |
brew services restart cliproxyapi # 改配置后重启生效 |
整套流程其实很短:
brew install cliproxyapicliproxyapi -codex-login 登录 Codexapi-keys
brew services start cliproxyapi 起服务curl 验证唯一容易卡住的地方,是本机开着 Surge 这类代理时,本地请求会被拦——一条 IP-CIDR,127.0.0.0/8,DIRECT,no-resolve 规则即可解决。之后,你就有了一个本地的、OpenAI 兼容的 Codex 网关,可以接到任何认 base_url 的工具里。
如果不想一直跟 YAML 打交道,别忘了还有内置的 WebUI 管理面板(http://127.0.0.1:8317/management.html)——设个 secret-key 重启就能用,账号、密钥、配置都能图形化管理。
2026-07-07 08:23:34
提示词:如何写一篇 AI 味很重的文章,给我一个范例。
希望大家都能借此识别 AI 生成的文章。
以下是成品。
在当今信息化、数字化、智能化浪潮风起云涌、日新月异的时代背景下,写作已经不再只是简单的文字表达,而是观点输出、信息传递、价值塑造和认知建构的重要方式。随着人工智能技术突飞猛进、方兴未艾,越来越多的文章开始呈现出结构清晰、逻辑严密、表达规范、内容全面的特点。如何写出一篇 AI 味很重的文章,已经成为一个值得深入探讨、系统梳理、持续优化的重要课题。
首先,要注重文章结构的完整性和层次感。一篇 AI 味很重的文章,通常需要具备清晰的开头、主体和结尾,做到有条不紊、层层递进、环环相扣。在开头部分,可以先从宏观背景切入,强调时代发展、技术进步、社会变革和产业升级等宏大主题。例如,可以使用“随着时代的发展”“在数字化浪潮的推动下”“在人工智能不断赋能千行百业的背景下”等表达方式,从而让文章显得高屋建瓴、立意深远、格局宏大。
其次,要善于使用抽象而全面的表达。AI 味较重的文章往往不会拘泥于某一个具体场景,而是会从多个维度进行系统分析。例如,在讨论写作方法时,可以从内容、结构、语言、逻辑、表达、传播、价值、生态等方面展开论述。这样不仅能够增强文章的完整性,也能够体现出系统化思维、全局化视角和综合性判断,给人一种面面俱到、滴水不漏、条分缕析的感觉。
再次,要合理使用连接词和过渡句。为了让文章看起来更加流畅自然、逻辑清晰,可以大量使用“首先”“其次”“再次”“最后”“与此同时”“值得注意的是”“从某种意义上说”“不可忽视的是”“综上所述”等表达。这些词语能够有效增强文章的秩序感和节奏感,使读者感受到内容之间循序渐进、由表及里、由浅入深的逻辑关系。
此外,AI 味很重的文章通常需要保持客观、中立、理性和全面。不要轻易表达过于鲜明的个人态度,也不要使用过于情绪化、口语化、个性化的语言。可以多采用“既有机遇,也有挑战”“既要看到积极意义,也要警惕潜在问题”“不能一概而论,需要具体问题具体分析”等句式。这样的表达方式能够让文章显得稳扎稳打、左右逢源、进退有据,既避免偏激,又显得成熟稳重。
在语言风格上,也应当尽量选择规范、正式、宏观的词汇。例如,可以多使用“赋能”“优化”“提升”“推动”“促进”“构建”“完善”“生态”“闭环”“路径”“机制”“体系”“抓手”“底座”“支撑”等词语。同时,还可以适当加入“与时俱进”“因地制宜”“统筹兼顾”“行稳致远”“久久为功”“精益求精”“守正创新”“多措并举”“协同推进”等成语和四字表达。虽然这些词语不一定能提供非常具体的信息,但能够有效提升文章的正式感、厚重感和时代感。
更进一步,想要增强 AI 味,还可以大量使用成对出现的排比句。例如,可以写道:“既要立足当下,也要着眼未来;既要脚踏实地,也要高瞻远瞩;既要守正创新,也要久久为功;既要统筹兼顾,也要精准施策。”这种表达方式节奏鲜明、朗朗上口、气势充沛,能够让文章呈现出一种庄重、规范、全面而又略显空泛的风格。
除了成语和四字词之外,类比也是写出 AI 味的重要方法。一个典型的 AI 味类比,通常并不追求多么新颖独特,而是追求通俗易懂、稳妥安全、看似形象。例如,可以把写作比作“搭建一座大厦”,结构是地基,观点是梁柱,案例是砖瓦,语言是装饰。也可以把文章比作“一棵大树”,主题是树根,逻辑是树干,论据是枝叶,结尾是果实。这样的类比虽然并不惊艳,但能够有效增强文章的可读性,让内容显得深入浅出、形象生动、老少皆宜。
举例来说,如果要说明 AI 味文章的写作方法,可以这样类比:“写一篇 AI 味很重的文章,就像搭建一套标准化样板间。开头是宽敞明亮的大门,负责营造宏观氛围;主体是分区明确的客厅、卧室和书房,负责承载不同维度的内容;过渡句则像走廊,将各个空间有机连接;结尾则像一盏明亮的吊灯,在最后时刻进行主题升华,使整篇文章看起来完整、协调、统一。”这种类比看似生动,实则安全,既不会过于锋利,也不会偏离主题,非常适合用于增强文章的 AI 风格。
在具体举例时,也要避免过于真实、尖锐和细节化的表达。比如,在教育领域,可以写道:“人工智能技术正在持续赋能教育场景,推动教学模式从传统化向智能化、个性化和高效化方向转变。”在医疗领域,可以写道:“人工智能有助于提升医疗服务效率,优化诊疗流程,推动医疗资源更加科学、高效、合理地配置。”在企业管理领域,则可以写道:“AI 技术正在帮助企业降本增效、提质增效、协同增效,推动组织管理从粗放式向精细化、智能化、体系化方向转型。”
这些表达虽然没有涉及具体的人物、具体事件、具体数据和具体矛盾,但能够体现出文章的广泛适用性、宏观概括性和高度稳定性。它们像万能钥匙一样,可以打开很多话题的大门;也像标准模板一样,可以被灵活套用到教育、医疗、金融、制造、零售、传媒等多个领域,做到举一反三、触类旁通、一通百通。
最后,文章结尾应当适当拔高主题,做到收束有力、余音绕梁、意味深长。可以从未来趋势、长期价值、社会意义和时代使命等角度进行总结。例如,可以写道:“总体来看,写出一篇 AI 味很重的文章,不仅需要掌握规范化的表达方式,也需要具备系统化、结构化和综合化的思维能力。未来,随着人工智能技术的持续发展,相关写作方式也将不断演进,并在更多场景中发挥不可替代的重要作用。”
综上所述,写一篇 AI 味很重的文章,关键在于结构清晰、表达全面、语言规范、观点平衡、成语丰富、类比稳妥、结尾升华。只要能够合理运用宏观背景、抽象词汇、标准句式、四字成语和安全类比,就能够有效写出一篇具有典型 AI 风格的文章。唯有如此,方能在内容表达中做到有章可循、有据可依、有的放矢,并在持续优化中实现从规范写作到高质量表达的稳步迈进。
2026-07-04 07:00:34
事情得回到三个月前,当时为了体验某个 AI 开发工具,我用它做了一个叫”黑洞健身”的 App(黑洞这个名字取自我家的黑猫)。
用了一段时间之后,我把 App 代码导出到 GitHub,开始用 Opus 来继续迭代它。
刚开始黑洞健身还是 Web 版本,以 PWA 模式安装到桌面。后面我又抽空让 AI 把它重写成 Android 原生版本。
下图就是这个 App 首页现在的样子:

这是一个典型的一人 App。下面说说这个 App 的进化和感受。
第一个形态:极简原型。 黑洞健身的第一版特别简单,只有一个极简地记录我的俯卧撑次数+组间休息倒计时的功能。它帮助我知道了,这是不是我想要的需求。
第二个形态:完善。 使用了一周后,我确定我需要它。所以我开始完善它。我加了运动项目管理,组间休息时间设定,每周和每日的数据统计,后面又加了运动计划。
第三个形态:数据同步和开放。 当我的数据变多,我增加了账号系统,提供了 MCP 接口。这是我想强调的进化阶段:未来每个一人 App 都必须开放数据接口。

有了 MCP 接口以后,我开始让我的 Agent 拉取数据,与我的体检报告整合,给我运动建议。这个 App 变成了我的个人 AI 助理的一个数据源。
第四个形态:自进化。 我把 GitHub 上面代码设置了相关的 hook,我或者其它授权的人只需要发 issue 就可以唤醒 claude 迭代代码,发出 pull request。其实我的 AI Agent 愿意,它也可以发 issue。

App 在这个阶段,可以自我进化,也可以被 Agent 通过 issue 进化,而我只需要确认即可。
Web 版本的详细进化 log 都记录在:https://fit-time.pages.dev/changelog,感兴趣的可以翻阅。
Web 版本虽然我不用了,但是网址还在,如果你想围观可以用 Chrome 打开:https://fit-time.pages.dev/
我个人定制的”黑洞健身”一人 App 帮助我在过去三个月坚持做到了锻炼,以下是刚刚过去的 6 月的健身记录(紫色🟣表示无氧运动,绿色🟢表示有氧运动):

AI 时代的一人 App 会经历:原型、完善、开放数据、自进化的演化过程。
如果你还没有一个自己的”一人 App”,赶紧用你的 AI 造一个吧。
2026-06-27 03:04:00
最近读完了宝玉的《图解 Skill —— AI 提效实战指南》,这是一本难得的 Skill 入门好书。趁着记忆还热乎,把心得整理成这篇读书笔记,也分享给同样在折腾 AI Agent 的朋友。
宝玉是国内 AI 圈非常活跃的分享者,常年在推特(X,账号 @dotey)、微博和 GitHub 上输出大量实用的 AI 技巧和 Skill。他在 GitHub(用户名 JimLiu)开源的 baoyu-skills 仓库,目前已经积累了约 1.8 万 star,覆盖内容创作、配图生成、自媒体发布等一整套工作流,被很多自媒体作者日常使用。
这本《图解 Skill》系统讲解了如何设计、编写、安装和迭代 Skill,并配有完整示例和章节配套资源(官方示例仓库为 JimLiu/Illustrated-Agent-Skills),属于「边读边能上手」的那一类书。
先从最基础的问题说起:一个 Skill 到底长什么样?
一个 Skill 就是一个文件夹,里面有一个 SKILL.md 文件。
展开 SKILL.md,可以看到它分成两部分:
除此之外,Skill 还有一个可选的第三部分——配套资源包。如果你的 Skill 需要一些参考文档或静态资源,可以放进资源包里。资源包没有严格的命名规则,也没有数量限制,比较自由。
书中举了一个稍微复杂一点的例子:一个带有脚本、参考文档和静态资源的 Skill,把这三类内容分成三个文件夹,统一放在 Skill 文件夹下面。如下图所示:

description 是 Skill 里非常关键的一部分,因为它直接决定了模型在什么时候会调用这个 Skill。
一个好的 description 应该包含两样东西:功能定义和触发场景。
举个例子:
description 需要尽可能简洁,最好控制在 100 个字左右,最多不超过 200 个字。写得太长,反而会稀释关键信息。
关于正文长度,官方建议不超过 5000 token,对应大概是 3800 个字,行数不超过 500 行。换句话说,Skill 正文要克制,不要把它写成一篇长篇大论。
书中给出了一个具体的、可直接套用的内容框架,分成四步:
书中以「写作风格 Skill」作为例子,把上面这套框架完整展开了一遍,是个很好的范例,建议对照原书细读。
书里还提出了一个我很认同的观点:技能写得好不好,应该做对比测试。
不过书中没有展开讲具体怎么测——核心思路是让模型一次加载 Skill、一次不加载 Skill,跑同一个任务做对照,看效果差异。这一节我顺着这个思路,补一套可以直接上手的做法,供大家参考。
对比测试要回答的其实只有一个问题:有了这个 Skill,模型的输出到底变好了没有,还是只是多了一堆噪音?
所以最朴素的做法是这样三步:
光靠”感觉好像更好了”是不够的,容易自我欺骗。更靠谱的做法是事先写下验收标准(断言)——也就是一条条明确、可判断的检查项。比如做一个”周报 Skill”,验收标准可以是:
标准越客观、越可验证越好。但要注意:写作风格、设计美感这类主观的东西,不适合硬套断言,更适合人工定性判断,别为了”可量化”而扭曲它。
人在评判时容易有先入为主的偏见——知道哪份是”带 Skill 的”,就会下意识觉得它更好。一个解决办法是盲评:把两份输出隐去身份,交给另一个模型实例(或另一个人)来判断哪个更好、并说明理由,评判者并不知道哪份来自哪个版本。这样得到的结论更可信。
值得一提的是,Anthropic 在 2026 年 3 月已经把这整套对比测试能力做进了官方的 skill-creator 工具里,而且全程不需要写代码。它能帮你:
这也呼应了我前面的延伸想法:对比测试的框架本身,完全可以交给 AI 来自动设计和执行。 书里点出了”要做对比测试”这个方向,而官方工具已经把它落地成了开箱即用的能力。
顺带一提,官方还提到一个很有意思的观察:如果某天你发现不加载 Skill、模型也能通过全部 eval,那不是 Skill 坏了,而是模型自身能力已经进化到把这个 Skill 的技巧内化了——这个 Skill 可以”功成身退”了。这对判断一个 Skill 还有没有维护价值,是很实用的信号。
书的最后还给出了不少落地的使用技巧,几个我印象比较深的:
整体读下来,我认为《图解 Skill》是一本很好的 Skill 入门书。它把 Skill 的结构、写法、测试到使用技巧讲得清晰又系统,配图和示例也很到位,能帮助读者对 Skill 的设计和使用建立起一个全面的认识。
如果你正打算开始用 Skill、或者想把手头的 Agent 用得更顺手,这本书很值得一读,推荐给大家。
最后,感谢人民邮电出版社英子老师的赠书。
2026-06-13 10:00:46
斑马玩教具业务从 22 年底到现在,已经快 4 年了。我们团队从研发课程的赠品出发,做出了斑马思维机这款爆款产品,连续三年销量第一。我一直在思考,我们在积累什么能力,我们的护城河在哪里,这里记录一下我的思考。
玩教具要解决“在玩中学”,所以需要把知识用有趣的方式在玩具中呈现出来。让孩子用“习得”的方式掌握知识。
动画片、儿歌、故事、游戏、音乐,这些任何让孩子感兴趣的方式,都变成了知识的载体。
但不是简单地把知识强行嫁接游戏就能成功。我见过一个失败的案例,把一个模拟经营的游戏变成了做题,孩子只能做题才能拿到游戏经营的金币,这种把游戏的快乐与做题的痛苦强行结合的方式,就像我们用奖励来鼓励孩子学习一样,只会让学习本身变得更加索然无味。
好的教研应该更进一步:把儿童发展目标转化为游戏规则、材料结构、交互路径和难度梯度。
斑马思维机在这方面帮我们收获了很多的经验。我们发现“过家家”似的角色扮演游戏是孩子非常感兴趣的游戏形式,我们就让孩子扮演过家家里面的某些角色,通过场景来构造知识的容器:
这就是更加融合知识的游戏结构。
做教育产品需要有双用户洞察的视角:家长关心教育价值,孩子只关心好不好玩。很多产品失败,是因为只满足了家长,没有满足孩子——包装上写满”逻辑思维、空间认知、专注力、数学启蒙”,但孩子玩 5 分钟就放弃。反过来,如果只好玩但家长看不到成长价值,就会变成普通玩具,被一堆公司模仿,没有壁垒。
好的产品应该:
现在售卖渠道变得多元化。天猫、京东、拼多多、抖音、快手、私域、线下门店,甚至海外渠道,都是需要投入建设的。每一个渠道虽然有部分用户与其他渠道重合,但是也有着它自己的忠实用户。
我们在每个渠道都花了三年时间深耕。比如:
我们的短期壁垒是教研、产品、渠道。
教研壁垒使得我们的竞争对手还是聚焦在教育领域,我们也可以尝试进攻那些非教育领域的品牌。就像学习机领域那样,最终教育公司(学而思、阿尔法蛋)把硬件公司(步步高、读书郎)打败了。非教育公司很难招聘和拥有大量的教研团队,同时他们的品牌也不支持用户心智,所以就容易放弃竞争。
产品壁垒是我们的创新带来的时间窗口。我们会在产品上领先同行 6-12 个月,这使得我们可以更早开展营销获客,获得用户和品牌心智,竞争对手需要考虑同质化竞争的难度,或差异化竞争的方案。
渠道壁垒是我们在各大渠道积累的合作经验,这使得我们可以在新品售卖的时候复用这部分的能力。
我们的长期壁垒是构建教育品牌心智、产品内容矩阵。这种心智会产生长期的主动搜索和主动购买,从而让我们过得一天比一天好。
我们当前的优秀产品数量还太少,无法形成“产品矩阵”,但是我们又不能像搭积木一样,快速堆砌新产品,而是需要从用户需求出发,重新挖掘市场机会,这注定让我们的速度是慢的。
等我们有 3-5 款像斑马思维机一样的爆款产品,我们的品牌心智才有可能相对稳固。
玩教具行业的核心竞争力,是把儿童发展规律、教育内容、游戏机制整合成一个可持续复购的产品系统,并产生品牌心智,形成长期口碑和复购。