用途
Naver Blog Maker 用于撰写或修订单篇 Naver 博客文章，目标是产出 Naver 现有系统能够展示、搜索者会点击并读完、且读者会认为是本人亲笔的文章。默认所有面向用户的交付物均使用韩语，包括标题候选、带图片与槽位标记的文章块、话题标签、说明与自检摘要；产品名、URL、命令、文件路径和引用原文保持原样。
它可以从一个关键词出发，先调研该查询、排名靠前文章的缺口及有来源的事实，然后起草，无需用户先提供事实包。
主要能力
- 产出符合 Naver 公开规则的文章，覆盖来源主题轨道、文档经验与原创性、意图切片匹配，不使用插入关键词、欺骗性标题或链接，并包含披露声明。
- 在每张照片必须出现的位置放置内联图片槽位，说明拍摄内容与配图文字所证明的事项；只有作者本人才能知道的内容标记为 [확인 필요] 槽位，而不是编造。
- 交付所选格式：纯文本为文本块，富文本为正文 HTML 加独立标题与标签。
- 在标题中给出具体承诺并在首屏内保持该承诺，使用改编后的模式库而非标题党词汇。
- 按嵌入式散文规则（rules/human-prose.md）在本次确定的语气下起草，使文本从一开始就没有机器写作质感。
- 支持两种模式：信息/经验型，用于无品牌的排名与阅读导向文章；转化型，用于为指定品牌生成咨询或访问的文章，使用用户自己的价值证明事实。模式由品牌关系和文章目标推导，不会单独提问。
- 在列大纲前先选择文章类型：判断客户意图、文章形式与业务目标，从 references/post-type-library.md 中选一个主类型（最多一个次类型），并记录在决策行。
- 当意图涉及做什么、选什么、多久、多少、多长时间或什么价格时，携带决策层：有来源的标准、有来源的选项、运营数字、会翻转建议的条件，以及恰好一个下一步行动。
- 对用户已写好的 Naver 文章进行修复：保留其语域和内容锚点，按 rules/repair-method.md 去除机器写作质感，而不是重写文章。
- 为每张生成的图片提供可移植的完整视觉简报：段落角色与模板、第一→第二→背景层级、颜色角色、材质与渲染、精确渲染文字、系列不变量与检查项，并在结构化对象旁附上可直接粘贴的自然语言提示。
使用方式
流程从接单开始：在一条消息中确认博客 URL、文章目标、可选的品牌/产品及其关系、可选 URL/材料、纯文本或富文本，以及可选的语气风格；然后等待回复。语气在此询问一次，之后不再重复询问，已回答的项目不会重复提问。
随后依次进行调研、关键词选择、结构搭建、起草、检查与交付。交付内容为：标题 → 所选格式正文 → 生成 JSON → 关键词 → 槽位 → 发布说明。富文本的标题与标签与正文 HTML 分开。若用户已提供草稿，则替换步骤 1 至 3：先记录其语域与锚点，再运行 rules/repair-method.md，步骤 5 和 6 不变，交付时在文本块外附加一到三行的变更摘要。
该技能是自包含的：它自带文章结构、Naver 规则与句子级自然度规则，不依赖任何已安装的其他技能。范围仅限文章内容与结构，不含登录、发布、互动行为或抓取。
适用场景
适用于以 Naver 博客文章（或其标题、大纲、改写）为交付物，且用户关心 Naver 搜索或 Naver App 曝光的情况。例如仅给关键词、要求针对某主题写可排名文章、为指定品牌提升咨询、撰写旅行后记并要求像真人所写、重写标题与开头以去除标题党，或对已写文章进行去 AI 痕迹的润色。
限制
- 目标为 Google、公司官网或技术 SEO 审计，超出范围。
- 用户只要原始 Naver 数据（搜索量、DataLab 趋势）而不需要文章，超出范围。
- 用户只提供韩语文本要求润色、不以 Naver 文章为交付物，超出范围。
- 平台为 Tistory、WordPress、Brunch 或通讯邮件，超出范围。
- 用户要求批量文章、定时自动发布或评论/邻居自动化时，拒绝自动化部分，仅提供一篇经过审阅的草稿。
- 博客 URL、文章目标、品牌关系、格式、语气风格等接单信息需先确认；模式由品牌关系与目标推导，不单独提问。
- 禁止编造经验、统计、引用、价格、资质或来源，缺口标记为 [확인 필요]。
- 禁止登录 Naver、调用 Naver API 端点或抓取。
- 不生成批次变体、排程、自动发布、评论/点赞/邻居诱导等任何互动操纵行为。