funcinating-guides
Skill4 starsChanged 3 months agoMITView on GitHub
为 Funcinating(范趣町)Shopify guides 博客写「能带流量、能留人、可直接发布」的长文指南。
In this repository22 other files it gives its agents.
- aihotSkill
- bilibili-creator-finderSkill
- douyin-scraperSkill
- feishu-cli-managerSkill
- funcinating-newsSkill
- hot-topicsSkill
- humanizerSkill
- humanizer-zhSkill
- imap-smtp-emailSkill
- lark-base-replicaSkill
- oss-uploadSkill
- seedance-promptSkill
- shopifySkill
- skill-publisherSkill
- skill-vetterSkill
- slider-captchaSkill
- tikhub-querySkill
- tiktok-scraperSkill
- video-downloadSkill
- wechat-scraperSkill
- weibo-scraperSkill
- xiaohongshu-scraperSkill
The file
Files
funcinating-guides:生成 Funcinating 指南长文
何时用
用户要写 guides 博客文章(长文指南/攻略/对比/教程),或说「按每周内容节奏出一篇 guides」。 news 短资讯不归这里,用 funcinating-news。
输入
- 选题(或让本 skill 按「选题方法」节提案 2-3 个供用户选)
- 目标集合/IP(内链去处,必给)
硬规则(违反直接作废)
- FAQ 结构:FAQ 节 =
<h2>FAQ</h2>,每组问答 =<h3>问题?</h3><p>答案</p>。 禁止<p><strong>问题?</strong> 答案</p>(2026-07-11 三篇混排事故根源,已修,别再犯)。 发布前跑体检正则(见验收节)。 - 不渲染 metafield FAQ、不加 FAQPage schema:owner 2026-07-09 已决定文章不展示
custom.faq且 FAQPage schema 从文章移除——别画蛇添足加回来。FAQ 就写在正文里。 - 事实不编造:销量/价格/IP 背景查证后才写;拿不准就删掉那句。
- IP 名(GISMOW/TARTI/CALOR/KOUCOMI/Labubu 等)保持拉丁原文,任何语言不译。
- 链接:站内链接用相对路径且不带国家前缀(
/collections/gismow);guides 文章互链用/blogs/guides/{handle}。外发推广链接才按 UTM 规范,正文内链不加 UTM。 - 成稿必须过 humanizer(英文)去 AI 味;中文版过 humanizer-zh。
选题去重闸(动笔前必过,四道)
- 拉现状:
{ blogs(first:5){ nodes{ handle articles(first:50){ nodes{ handle title } } } } }——新题的核心关键词与任何既有 handle/title 重叠 → 换题或换意图(换意图须在文首规划里写明与既有篇的差异一句话)。 - 查关键词台账(需求侧 SSOT):飞书多维表格「【正式】Funcinating 关键词台账」
base=
MsmGbvtMuaI9jos8y0qcItnmnif/ table=tblu9AIxGSTVIgC8(wiki: https://jcnp2psokv2t.feishu.cn/wiki/E6SWwc7mlivZd8kFcNNc1Mslnyh)。 选题=从台账视图「02 内容机会池」(三轴状态-决策=铺新内容 且 执行阶段=待执行)里挑, 优先级按 身份-分层(P0>P1>P1.5>P3)再叠时效性/数据动量; 新词先入台账(词族/分层用表内既有选项)再动笔。台账候选 <6 个时按下方选题方法补一批。 - 查竞品拆解表(供给侧线索,2026-08-17 接入):飞书多维表格「竞品Blog-News亮眼内容拆解」
base=
JYO8bk3doa9YF5sZ0mWcPMXwnCe/ table=tblk9g87FdpmFx3X。 筛借鉴优先级∈ {P0 直接抄作业, P1 排期跟进},取每条的锁定关键词(推断)。
命中的词若不在台账,先入台账再动笔(逻辑键=关键词,先拉全量比对防重复): 三轴状态-状态=lark-cli api GET /open-apis/bitable/v1/apps/JYO8bk3doa9YF5sZ0mWcPMXwnCe/tables/tblk9g87FdpmFx3X/records \ --params '{"page_size":200}' --as user手动录入、决策列留空(空=待判定,周一 AI 预判会接手、周二默认同意定案)、 身份-词族/分层与同类词对齐、备注=竞品 {站点} {发布日} 已发:{URL}。
为什么要这一步:GSC 只能告诉你已经有曝光的词,永远告诉不了你还没进场的战场。 竞品每发一篇文章就等于替我们做了一次关键词调研,不接这根管子,那份调研就烂在拆解表里。 实测(2026-08-17):Utopia Toys 两周 27 篇锁定的词,在台账里命中 0 个。 现阶段这一步是人工执行的;它被写成"读表→比对→batch_create"三步纯机械动作, 没有 LLM 判断,将来要自动化直接搬进周一脚本即可,判定仍走已有的默认同意制。POST .../tables/tblu9AIxGSTVIgC8/records/batch_create # 每批≤100,校验 code==0 - 发布后回填(2026-08-03 列名清理后的口径,勿用旧短名):
- 台账该词:承接信息-承接页=相对路径(
/blogs/guides/{handle})、承接信息-承接类型=guides长文、 三轴状态-执行阶段=已完成(词随即进「04 已完成监控」视图); - 动作表
tblHYcmFLNHsroFx(此表保留短名,勿改):新增一条,动作ID=act-YYYYMMDD-{slug}、 动作类型=新内容、状态=已上线、词族必须与台账该词一致、 基线28天指标按台账真实 GSC 值写——无曝光的假说词如实写「发文前 GSC 28 天窗口内无曝光,基线=0」,严禁编造; - GA4 7/14/28 天数据由周报脚本自动回填动作表,不用手动。 文章内容与同步状态在「商品内容与SEO-GEO字段表」的 Articles 表,不在台账重复记。
- 台账该词:承接信息-承接页=相对路径(
选题方法(三类,按 GA4 已验证的优先级)
- 蹭热词对比型(流量最大):
{顶流IP} alternatives、{顶流} vs {自家IP}、best {品类} {年份}。 范本 = labubu-alternatives-2026(蹭 Labubu 热度,60 天浏览量全站第一,site: 检索可被搜出)。 热词从当下顶流找:Labubu/Sonny Angel/Smiski/新爆款,常换常新。 - 实操教程型(留人最强):how-to 具体问题(挂件朝向/清洗保养/展示收纳)。 范本 = how-to-attach-bag-charm(人均停留 72 秒、参与率 67%)。
- 礼物场景型(转化导向):gifts under $30 / desk companions / 送礼清单,直连场景集合页。
- 竞品缺口型(情报驱动):拆解表里 P0/P1 的词,挑「对手已占坑、我们没有承接页」的做。
注意只抄打法不抄品类——对手写高达/手办,我们写盲盒/毛绒,句式可移植、内容必须自己的。
已验证可移植的句式:
where to buy authentic {品类}、how to avoid bootleg {品类}、{A} vs {B}、best {品类} brands、are {品类} worth buying、{品类} under ${价}。
选题自查:目标关键词有人搜吗(常识判断+顶流关联)?能自然内链到至少一个集合页吗?两个都否 = 换题。
结构模板(流量骨架 × 留人要素)
以 labubu-alternatives-2026 的骨架为准,揉进教程文的留人写法:
<p>导语 2-3 句:直击读者痛点场景(抢不到/买贵了/摆不好),一句共情 + 一句本文承诺。
范本口吻:"...half of them are sold out or resold at triple the price. If you're here,
you probably want that same hit without the hunt."</p>
<h2>先解构:{热点}为什么火</h2> <!-- 蹭词型专用;教程型换成"问题为什么会发生" -->
<p>2-3 句给读者"被理解"的感觉,顺势立起判断标准(后文推荐都围绕这几条标准)。</p>
<h2>如果你想要{需求场景A}</h2> <!-- 每节 = 一个需求场景,对应一个自家 IP -->
<p>推荐 + 为什么符合标准 + <a href="/collections/gismow">集合内链</a>。每节配一张商品图。</p>
<h2>如果你想要{需求场景B}</h2>
<p>同上,换 IP。场景节 2-4 个,宁少勿滥。</p>
<!-- 教程型此处换成 Step 1..N:每步一个 h2、短句、具体动作、无需工具/时间承诺 -->
<h2>诚实节:{对方/现状}仍然赢在哪</h2> <!-- 信任杠杆,labubu 文的点睛之笔,别删 -->
<p>大方承认对方优点,反而让前面的推荐可信。</p>
<h2>怎么买不挨黄牛刀</h2> <!-- 购买引导:official/sealed/直发,内链集合 -->
<h2>FAQ</h2> <!-- 3-5 组,硬规则结构 -->
<h3>问题一?</h3><p>答案。</p>
<h3>问题二?</h3><p>答案。</p>留人要素(修 labubu 停留仅 9 秒的短板,来自教程文):
- 首屏(导语后第一节内)就给出"本文清单预览"一句话,让扫读者知道往下有什么;
- 短句、具体名词、可执行动作;每节 ≤150 词;
- 每个场景节配图(商品图 CDN 链接),纯文字大段是跳出主因。
- 正文配图终版配方(2026-08-03 四轮排查定稿,每一条都是必要条件):
①图片先在本地裁成 16:9 成品(标准 1200×675;原图短边不足就用其内的 16:9 如 800×450,CDN 不放大);
②通过 Theme Access token 上传为主题 asset(
PUT themes/{live_id}/assets.json,纯新增文件; 别用 Files API——文件库域名的图在正文里渲染异常); ③写进正文必须包在<p>里:<p><img src="https://www.funcinating.com/cdn/shop/t/1/assets/{名字}.jpg" alt="{描述}" width="1200" height="675" loading="lazy" style="max-width:100%;height:auto;border-radius:8px"></p>——裸<img>(不包 p)渲染宽度会失控,这是 2026-08-03 连修四版才找到的根因; ④禁用 URL 动态裁剪参数(?width=&height=&crop=),尺寸一律在文件层面定死; ⑤范本=how-to-attach-bag-charm 的五张图,新文图片与它逐字节同构即正确。
篇幅:3500-5000 字符 HTML 是建议区间不是硬指标(两篇范本分别 4958/3822), 上限可放宽到 6000(owner 2026-08-12 确认)。超出别硬砍内容——为凑字数删掉一段有信息量的 正文,比多 500 字符糟得多。真正要防的是灌水到万字。数据表、清单这类结构化标记不计入判断, 按正文长度看。
写入 Shopify
# blog: guides 的 gid 现查 { blogs(first:5){ nodes{ id handle } } }
mutation { articleCreate(article: { blogId: "...", title: "...", handle: "...",
body: "<HTML>", summary: "<meta描述,150字符内>", isPublished: false,
author: { name: "Funcinating Team" }, # author 必填,缺了报 INVALID_VARIABLE
tags: ["guides"], image: { url: "...", altText: "..." } }) {
article { id } userErrors { field message } } }发布流程(2026-08-03 owner 确立,永久人工闸):一律先 isPublished: false 隐藏创建
→ 给 owner 后台预览链接(admin.shopify.com/store/qs0nxk-ft/content/articles/{id})
→ owner 确认后才 articleUpdate 置 isPublished: true,然后才做四语言与台账回填。
未确认前公开 URL 404、搜索引擎不可见。
SEO 标题与描述必须单独写(2026-08-17 补,此前整条流程漏了这一步):
Article 类型上没有 seo 字段(查了会报 Field 'seo' doesn't exist on type 'Article'),
SERP 上那两行走两个 metafield。title 是 H1、summary 是博客列表页摘要,都不是 SERP 标题/描述。
mutation { metafieldsSet(metafields:[
{ownerId:"gid://shopify/Article/{id}", namespace:"global", key:"title_tag",
type:"single_line_text_field", value:"<SERP 标题,≤60 字符>"},
{ownerId:"gid://shopify/Article/{id}", namespace:"global", key:"description_tag",
type:"single_line_text_field", value:"<SERP 描述,≤155 字符>"}
]) { metafields{key value} userErrors{field message} } }Shopify 读写一律走 gql.mjs(应用凭证通道 D-011;默认禁写,改数据要加 --allow-mutations;绝不跑 shopify store auth)。
H1 和 SERP 标题的分工(2026-08-17 的教训,别再犯):
H1 可以有文学性、可以埋 IP 名;SERP 标题必须直答主词的搜索意图,句式跟着主词走
(问句词就用问句、best/trend 词就带年份和品类)。
反面教材:bag-charm-trend-2026 的 H1 是「Bag Charm Trend 2026: What Comes After Labubu」,
SEO 标题为空 → Google 拿 H1 当结果标题。而它最大的词是 are bag charms still in 2026
(问句)。结果:平均位次 6.7(该位置正常 CTR 3-6%),实际 CTR 0.5%,
周 1765 曝光只换来 8 个点击。排名到手了,点击丢在标题上。
更讽刺的是它的 description_tag 第一句就是 "Are bag charms still in for 2026?"
——当初写的人清楚意图,只是没把它写进标题。
坑(与 funcinating-news 共享):
- handle 全小写连字符英文,带年份的热词题建议 handle 也带年份(labubu-alternatives-2026);
- title(H1)≤60 字符,把热词放最前;summary 是列表页摘要,不是 meta description,别混;
- 四语言翻译(th/es/zh-CN/zh-TW):
translatableResource取各 key 的 digest → 各语言translationsRegister(key: title/body_html/summary_html 以及 meta_title/meta_description, digest 用当前源文的,源文再改则翻译须重注册)。译文里 FAQ 结构同样必须 h3+p。 ★meta 两键必须在写完 SEO metafields 之后注册(先写 EN 的 title_tag/description_tag, 再重查 translatableContent 拿它们的 digest)——漏了它,小语种页面的 SERP 标题/描述回退英文 (2026-09-01 审计:13 篇已发布 guides 里 12 篇缺,已批量补齐)。translationsRegister是 per-key upsert,分次注册不会清掉已有翻译键(2026-09-01 实证); 但流程仍按「先读现有翻译、只注册缺失/过期的键」写,幂等。
验收(全过才算完)
- FAQ 体检(机器查,零容忍):
re.findall(r'<p[^>]*>\s*<strong>[^<]{5,200}[??]</strong>\s*[^<]{40,}', faq节)必须为空;<h3>…?</h3>数量 = FAQ 组数。 - humanizer 过稿(中文版 humanizer-zh)——必须跑完整三步,不许只跑机器可查的那半: ①起草 → ②停下来自问「这段为什么一眼就是 AI 写的」并逐条写出答案 → ③按答案重写。 零破折号 / 零弯引号 / 无 AI 高频词 / 正文无装饰性加粗 / 句长交错,这五项只是硬指标, 全绿不等于过稿。真正要靠判断抓的是:权威腔开场(「The honest part:」「The real question is」)、 格言化表达(「X is the Y of Z」「where the odds are least unkind」)、同义词轮换 (同一段里 sits at / sits outside / sits between)、每句都像金句的碎句堆叠、 问一句自答一句的假坦诚(「Chasing rather than collecting? 」)。 这些机器正则一条都查不出来。 反面教材:2026-08-12 写 desk / vinyl / plush 三篇时只跑了硬指标就报「humanizer 通过」, 判断轮整个跳过——同一轮里概率篇跑了完整流程,改掉了上面列举的四类问题,对比明显。
- 内链:≥3 个集合页链接(2026-08-12 上调,原为 ≥1)、相对路径、无国家前缀、无 UTM。
为什么加码:2026-08-11 查到 TARTI 合集页在「tarti」主词上被自家博客截胡(博客位置 6.9、
合集页接不到),根因是只有 2 篇文章链 /collections/tarti,而 GISMOW 有 7 篇——
文章给合集页的内链就是合集页在站内的权重来源,只链 1 个等于白写。
做法:只在正文已经提到那个东西的地方包
<a>,读起来自然;硬塞不相干的集合是负分。 品牌合集(gismow/tarti/calor/koucomi/moco)和场景合集(gifts-under-30/desk-companions/ bag-charms/vinyl-figures/plush/blind-box)都算,优先链本文真正在讲的那个。 - SEO 标题与描述非空(机器查,零容忍——2026-08-17 全站体检:guides 18 篇里 14 篇缺标题、
11 篇缺描述,news 5 篇全缺,根因就是本清单此前没这一条):
两个都必须有值;标题 ≤60 字符且句式对得上主词的搜索意图(问句词配问句);描述 ≤155 字符。{ blogs(first:5){ nodes{ handle articles(first:60){ nodes{ handle tt:metafield(namespace:"global",key:"title_tag"){value} dd:metafield(namespace:"global",key:"description_tag"){value} } } } } } - 四语言注册成功且 userErrors 为空,IP 名未被翻译;
- 发布状态回读:回读
isPublished与publishedAt,与约定的可见时间核对(比较用 ISO 原值, 给 owner 展示时转 GMT+8)。当前/过去时间应为公开;未来时间应保持排期状态,别误判成失败。 任何不一致都不得声称已发布/已排期。 - 作者名回读:
article.author.name归一化(trim+NFKC)后必须等于Funcinating Team, 不一致即验收失败(写入模板里带了 author,但漏写时会静默变成操作者名字,必须回读兜底)。 - HTML 实体检查:标题/summary/meta 的HTML 解码后值应与预期原文一致——不列实体黑名单 ("/' 只是常见样本,黑名单永远漏),解码比对一步到位。
- 缓存验证口径:整页缓存黏且忽略
?cb=,肉眼验证须加?preview_theme_id=<LIVE_THEME_ID>; 注意它只是这条 URL 绕过缓存,不代表全站缓存已清,给用户的链接生效要等缓存自然过期。 - 发布后:GSC 对文章 URL 请求编入索引;
- 一周后回看 GA4(pagePath 含 /blogs/guides/):浏览量、人均停留——停留 <15s 说明首屏没钩住,回炉。
环境备忘
- 泰语页面路径是市场化的
/th-th/(或英文-泰国/en-th/),裸/th/不是路由(404 属正常,别当缺陷修)。
组合与相关
- 去 AI 味:humanizer(英)/ humanizer-zh(中)
- 短资讯:funcinating-news(五拍骨架、固定信源)
- 站点约定 SSOT:飞书《Funcinating 多语言适配指南(复用手册)》、UTM 规范文档
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

