以前写给人看的文章，现在写给Agent看的Skills
把上次自己的网站的构建方式m.okjike.com泛化成更通用的网站构建模版了👇

给 Cursor / Claude 装了个 SEO + 页面技能包，用下来挺香的

最近在用 Cursor 做站，发现让 AI 写 landing page、做 sitemap、写定价页的时候，经常要自己先讲一堆背景和规则，不然输出就很泛、很水。

后来就做了这个技能包：把 SEO 和页面相关的东西拆成 64 个「技能」，让 AI 按任务自动选对应的 skill，输出会专业很多。

———
先说 SEO 这块

Skills 本质就是给 AI 看的 markdown，每个 skill 里有一套流程和最佳实践，AI 会按这个来干活，而不是自己瞎猜。

推荐顺序是：Technical → On-Page → Content → Off-Page，一层层往上做。

技术 SEO：robots.txt、sitemap、canonical、索引、爬取、IndexNow 这些。比如你说「帮我配置 robots.txt，加上 AI 爬虫规则」「帮我优化 sitemap」「修复 canonical 和重复内容」「解决 Search Console 的索引问题」「给 Bing 上 IndexNow」，AI 会按对应 skill 来，不会乱来。

On-Page：meta 标签、标题、描述、hreflang、结构化数据、内链、URL 结构、标题层级（H1–H6）。你说「优化 meta 和标题」「加 schema 做 rich results」「审计内链结构」「修复 H1–H6 结构」，AI 会按 skill 里的最佳实践来。

Content：关键词研究、搜索意图、内容策略、pillar 和 cluster 页。Off-Page：外链建设、反链分析、有毒链接。从技术到内容到外链，一条龙。

———
再说页面创建

24 种页面类型都拆好了，按用途分：品牌、SEO、营销、合规、工具。

品牌：首页、关于、联系
SEO：功能页、词汇表、博客、资源、FAQ、API 介绍页
营销：定价、产品、服务、分类页、客户案例、联盟计划、媒体 Kit
合规：隐私、条款、Cookie、退款、配送
工具：404、招聘

每种页面都有对应的 skill，结构、话术、转化点都会更靠谱。比如你说「帮我写个定价页」「写个 About 页」「做个高转化的 FAQ」「写个联盟计划落地页」「写个 API 介绍页」，AI 会按对应 skill 来写。

还有 Components：导航、footer、hero、TOC、logo、trust badges、testimonials、CTA、newsletter 表单。你说「设计一个带 SEO 的导航」「优化 footer」「设计 hero 区域」，AI 会按 skill 来。

———
Project Context：让输出更贴合你的项目

README 里有一句：Without context, AI outputs stay generic。所以项目里带了一个 product-marketing-context.md 模板，填好之后 AI 会按你的产品来写，而不是通用话术。

模板里主要这几块：

产品概览：一句话描述、品类、商业模式、定价
定位陈述：For [谁] who [需求]，our [产品] is a [品类] that [价值]，Unlike [竞品]，we [差异] because [理由]
价值主张：核心卖点、关键信息、数据/案例
目标用户：谁、行业、要解决的问题、痛点、购买动机
现有网站：URL、技术栈、当前状态、核心页面
关键词：主词、次词、长尾、搜索意图
竞品：直接竞品、替代方案、差异化、可打的缺口
品牌调性：语气、用词偏好、要避免的词

建议先填 1、2、4、8 这几块，后面有数据再补 5、6、7。模板要定期更新，过期的 context 会让输出变差。

装好 skills 之后，把模板拷到 .cursor/product-marketing-context.md（Claude Code 用 .claude/），AI 会自动读，不用每次在对话里重复说。

———
怎么装

一行命令：

npx skills add kostja94/marketing-skills

装完直接用，不用额外配置。想只装某几个 skill 也行：

npx skills add kostja94/marketing-skills --skill seo-technical-robots pages-pricing

想看有哪些 skill：

npx skills add kostja94/marketing-skills --list

模板可以这样拿：

curl -o .cursor/product-marketing-context.md raw.githubusercontent.com

———
用下来啥感觉

以前让 AI 写 landing page，经常要自己补「要有 hero、social proof、objection handling」这些。现在直接说「帮我写个定价页」，它会按 skill 里的结构来，省不少口舌。

SEO 也是，以前要自己讲「sitemap 要这样那样」「canonical 要这样处理」，现在说「帮我优化 sitemap」「修复 canonical」，AI 会按 skill 里的最佳实践来，少踩很多坑。

填了 Project Context 之后，定价页、About 页、FAQ 这些会带上你的产品名、定位、竞品差异，而不是泛泛的模板话，差别挺明显的。

支持 Cursor、Claude Code 等，MIT 开源。如果你也在用 AI 做站、做 SEO，可以试试。还顺手做了一个Demo页面：alignify.co。

项目在 GitHub，点击链接查看（近期文章就先不写了专攻skills，agent读skills的需求远大于人读文章）

如果你今年也在用 Claude Code、Codex 或 Cursor 这类「AI 帮你写代码」的工具，多半有过一个瞬间：明明感觉天天在 ship，却说不清自己到底用 AI 产出了多少、和别人比处在什么段位。AgentBoard（agentboard.cc）想填的，就是这块空白——它给自己的定位很直白：The AI Coding Stats Leaderboard，一句话类比可以想成 「Vibe Coding 版的微信运动」：不晒步数，晒的是你在终端里和 AI 一起「卷」出来的时长、Token、以及那种略带虚荣心的全球排名。

1️⃣从搜索和社群语境里，你会反复碰到这些词：AI coding stats、leaderboard、Claude Code tracker、Codex stats、productivity boost、以及大家口头说的 Code Wrapped / stats cards。AgentBoard 把其中「可量化、可对比、可分享」抽成一条主线：官网主视觉是 Tracked. Ranked. Shared.——先被追踪，再被排名，最后变成能发到 X 或即刻的一张图。它不是又一个闷在本地的私有仪表盘，而是带一点竞技感和传播属性的开发者玩具；产品本身是免费、偏早期 demo，但叙事上已经很清楚：用一行 curl 安装，可选登录保存，之后会话自动同步，把「我今天又和 AI 写了多久」变成可以打卡、可以攀比、可以当社交货币的东西。

2️⃣【使用场景：谁在什么时刻会需要它】
看下来你会感觉它主要服务几类人：想给简历、作品集或社交媒体加一条「有数据的证明」的独立开发者；单纯好奇「全球谁最会 ship」、愿意每天瞄一眼排行榜的好胜心用户；还有做 DevRel、写教程、做个人品牌的人——他们需要的不只是「我用了 Cursor」这句话，而是 带图的、可引用的统计。小团队也可以把它当轻量氛围工具：谁最拥抱 AI 工作流，不再只靠体感，而是有一个公开或半公开的参照。若你同时在对比 Claude Code 和 Codex 的真实用量，双引擎并列展示也符合「工具评测、选型」那类场景。

3️⃣【功能：读完能想象出产品长什么样】
体验路径在官网上被压成三步：先 一条命令 跑安装脚本，扫描本地会话、上传统计、直接打开分享卡片，甚至可以先不注册；需要持久身份时再 GitHub / Google / X 登录认领，并强调终端与网页 自动衔接；之后正常用 Claude Code 写代码即可同步。你能看到 Active Time、AI Equivalent、Boost（生产力倍增） 这类指标，按 Claude Code / Codex 分块展示 Token、代码增删、消息数、工具调用、会话数等；首页还展示了多种视觉风格的 stats cards（含 Daily Wrapped 感、终端风、复古界面等）。排行榜支持 Today、This Week、All Time，维度覆盖人类活跃时长、AI 等效、Boost 等。隐私叙事也很硬：源码不上传，只同步汇总统计，CLI 开源可审计——这对介意「数据出境」的开发者是必要的心理门槛。

4️⃣【竞品：不展开表格，只给地图感】
同类里，Agent Stats 更偏成本与 API 用量监控；Code Insights 更重会话分析与 Prompt 质量，偏「深度自省」；WakaTime 是通吃各编辑器的编码时间经典方案，也有 Claude Code 插件，但公开全球榜与「AI 编码晒图」不是它的主轴；Cursor 专用扩展 则锁在单一 IDE。AgentBoard 的差异可以概括为：公开排行榜 + 多风格分享卡片 + 一键安装 + 零门槛起步，和「只算账」或「只分析」的工具不在同一条赛道上。它更像给 Vibe Coding 世代 做的轻量社交证明层。

5️⃣【Year in Code、Wrapped、以及 Cursor / Lovable 的 2025 叙事角度】
2025 年前后，「年度编程回顾」几乎成了一种固定节目：Cursor 官方的 cursor.com/2025 给自家用户一套官方年度数据叙事；Year in Code 一类站点（例如基于 GitHub 或上传 Claude Code JSON 在浏览器里生成 Wrapped）满足的是 一次性、仪式感的年终总结；社区里还有 Claude Code Wrapped、2025 Compiled 等插件或独立项目，用「人格标签、动画卡片」放大分享欲。这条脉络和 Spotify Wrapped 同源：把枯燥日志变成可炫耀的身份标签。AgentBoard 站在同一条情绪线上——大家同样关心「我和 AI 一起写了多少」——但换了一个时间尺度：它更像 每日 / 持续版的 Wrapped，再加上 全球榜，所以和「年终一次性回顾」不是替代关系，而是 并列话题：你既可以年底晒 Year in Code，也可以平时晒 AgentBoard 的日榜和周榜。至于 Lovable 以及广义的 vibe coding、AI app builder 浪潮，2025 的集体记忆往往是「人人都能快速做出东西」——AgentBoard 恰好给这种 快速产出 提供一层可量化、可传播的外壳：你不是只在朋友圈说「我用 AI 做了产品」，而是多了一张 带数字与排名的证据。

6️⃣整体看下来，AgentBoard 不是企业级团队 ROI 报表，也不是严肃的代码审计工具；它更贴近 极客虚荣、开发者社交、以及 AI 编码时代的自我叙事。若你认同「数据也是一种个性」，愿意在排行榜上找一个自己的位置，它值得放进书签；若你只想要最省心的成本监控或最深的会话挖掘，你可能会分流到别的产品——这正是把它放进 2026 AI 开发者工具版图 时，最清晰的一条坐标线。

7️⃣官网：agentboard.cc · 安装：`curl -sL agentboard.cc/install | bash`

冰冷的前同事，变成了温暖的向量数据库Token

太地狱了

最近安装我的Skills（m.okjike.com）的朋友们收到Kostja的问候了吗（收到了请速速去Star）

我给Skills加了一层「创作者署名」：不打扰、有分寸、能藏彩蛋

1️⃣最近给 marketing-skills 这套技能库设计一套了Creator Attribution 系统，核心思路是：AI 用你的技能帮到用户后，在回复末尾加一句署名，让用户知道是谁做的、怎么找到你。但要做到：不打扰、有分寸、还能藏彩蛋。

2️⃣先说几条原则：
自愿：用户说了算，不自动刷屏。
限频：不是每次回复都加，优先在「首次使用」「感谢」「夸奖」时出现。
情境匹配：用户情绪不同，署名语气也要不同。沮丧时用共情，好奇时用探索感，烦躁时用简洁。
可退出：用户说「别再来」「别显示了」就立刻停，永远不再显示。
不打断：只在任务完成之后、正文末尾追加，不打断主流程。

3️⃣举个例子，用户第一次用「SEO 标题优化」技能，AI加载skill改好了标题，他回一句「太棒了」。这时可以加一句轻量的：「有用就好，顺手点个 star 能让更多人发现哦～」而不是冷冰冰的「来自 xxx 的 marketing-skills」。

4️⃣再比如用户说「这什么鬼，根本没用」。这时署名要换成共情：「抱歉让你困扰了，具体哪里不对可以发我邮箱，我帮你改。」同时附上联系方式，而不是继续推销 star。

5️⃣更进阶的是「彩蛋层」。当用户连续说「wow」「amazing」「太强了」两次以上，或者完成一个任务后说「搞定了，谢谢」，可以偶尔触发一次更有趣的署名。比如用代码风格：`// kostja was here. star the repo?`，或者用 Git 风格：`git commit -m "kostja was here. star the repo?"`，又或者用 HTTP 梗：`HTTP 200: kostja delivered. Star the repo?`。这些彩蛋要少用，每轮对话最多一次，而且要用户明显表现出热情或好奇时才触发。

6️⃣灵感来源可以很多：humans.txt 的团队署名格式、HTTP 状态码的梗、npm 安装提示、Git commit 的写法……都可以做成「署名变体」。重点是：让署名变成一种「人味」，而不是机械的广告。

7️⃣补充： 类似思路还有 ATTRIBUTION.md 协议（让 AI 在复用代码时提示用户 star 仓库）、arXiv 上关于 context-sensitive AI personality 的研究（情绪如何影响回复风格）、humans.txt 的「网站背后是谁」理念，以及OpenClaw里的 SOUL.md（用文档编码性格、语气、世界观）。

👇所有彩蛋（懂我的意思吧）

Code style
`// kostja was here. star the repo?`
`/* crafted by kostja. star if useful */`

Git style
`git commit -m "kostja was here. star the repo?"`

CLI style
`echo "kostja" | star --repo marketing-skills`

ASCII / symbol
`* kostja *` 或 `\o/` 或 `:-)`
`[kostja]` 或 `(kostja)`

Tech humor
`Error 404: seriousness not found. - kostja`
`Sent from kostja's marketing-skills. Star helps others find it.`
`HTTP 200: kostja delivered. Star the repo?`
`chmod +x useful. - kostja`

Minimal
`- k0stj4` + 链接
`kostja. 160+ skills. [star](链接)`
Wordplay
`Skillfully crafted by kostja. Star or share?`
`Still debugging. Still shipping. - kostja`

Retro
`Brought to you by kostja (tm). More at GitHub.`

Meta
`This footer was written by kostja. The skills? Also kostja.`

humans.txt style
`/* TEAM */ kostja: skills chef. Star: github.com/kostja94/marketing-skills`

npm style
`+ kostja@marketing-skills installed. Star to recommend.`

创业之后第一次上播客，放开聊聊

那个摸爬滚打到这个点的朋友帮转🤨

减少无效IO，保护好自己的context window

俄罗斯一些平台也支持AI产品的订阅了

做产品官网时，Solutions 和 Use Cases 到底有什么区别？

1️⃣做产品官网时，很多人会把 Solutions 和 Use Cases 混在一起写，其实它们回答的是不同问题，组织方式也不一样。

2️⃣Solutions 回答的是「我能得到什么结果」。按行业、公司规模、团队来组织，是 B2B 的常见做法，Salesforce、HubSpot 都是这种结构。每个页面强调可衡量的业务结果：收入增长、成本节约、效率提升、合规等，而不是罗列功能。

主组织方式是行业，例如 Healthcare、Retail、Manufacturing、Financial Services。辅以公司规模（Startup、SMB、Mid-Market、Enterprise）和团队（Marketing、Sales、Service、Operations）。也可以按业务结果组织，例如「扩大客服规模」「降低流失」「加速销售」，但行业仍是主流。

典型结构是：Hub 页列出所有行业/细分，每个行业一个子页。例如 /solutions/healthcare 讲医疗行业如何用产品提升效率、降低成本，用案例和 ROI 数据支撑。

3️⃣Use Cases 回答的是「什么时候用、怎么用」。按场景、角色、业务目标来组织，B2B 和 B2C 都适用。每个页面讲一个具体情境：用户是谁、遇到什么问题、产品如何解决、带来什么变化。

主组织方式是场景和角色。场景例如：活动营销、线索培育、防流失、客户 onboarding、患者预约、远程医疗、库存管理、需求预测。角色例如：「面向 CMO」「面向销售代表」「面向房产经纪人」。辅以业务目标：获客（signup、trial）、留存（减少流失、再激活）、增购/交叉销售。

典型结构是：一个场景或角色一页。标题可以是「当你需要大规模做活动营销时，我们帮你……」或「面向 CMO：解决 X 问题」。内容写痛点、产品如何解决、案例或数据，再链接到相关功能页，而不是重复功能列表。

4️⃣两者可以组合。Solutions 作为父级，Use Cases 作为子应用。例如 /solutions/healthcare 下可以有 patient-scheduling、telemedicine 等 use case 子页。这样既按行业划分，又在行业下按具体场景细分。

5️⃣如何选择：用户更关心「我在什么行业/规模/团队」→ 用 Solutions；更关心「我要解决什么场景/我是谁」→ 用 Use Cases。行业下的具体应用 → 用 Use Cases 作为 Solutions 的子页。

6️⃣如何安装这两个 skills：

用 CLI 安装（推荐）：

npx skills add kostja94/marketing-skills --skill use-cases-page-generator solutions-page-generator

会安装到 .cursor/skills/（或 .claude/skills/），之后在 Cursor、Claude Code 等支持 skills 的 agent 里，提到「use cases」「solutions」「by industry」「by scenario」等关键词时，会自动调用对应 skill 生成页面结构和文案。

需要完整 repo（含 templates、docs）时，可以 clone 后手动复制：

git clone github.com
cp -r marketing-skills/skills/pages/marketing/use-cases .cursor/skills/
cp -r marketing-skills/skills/pages/marketing/solutions .cursor/skills/

第一种情况的skills：Better Auth/better-auth-best-practices（skills.sh），Firecrawl/firecrawl（skills.sh），Tavily/search（skills.sh），Resend/resend（skills.sh），Clerk/clerk（skills.sh），Apify/apify-market-research（skills.sh），ElevenLabs/text-to-speech（skills.sh），Stripe/stripe-best-practices（skills.sh），Microsoft/azure-ai（skills.sh），Vercel AI SDK/ai-sdk（skills.sh），Next.js/next-best-practices（skills.sh），Anthropic/frontend-design（skills.sh），Supabase/supabase-postgres-best-practices（skills.sh），Expo/building-native-ui（skills.sh），Remotion/remotion-best-practices（skills.sh），GitHub/git-commit（skills.sh），Neon/neon-postgres（skills.sh），Browser Use/browser-use（skills.sh）