B2B 技术文章发布与汇总输出

> © 2026 宋忠利（Song Zhongli）。本技能以 Apache-2.0 许可证发布：可自由使用、修改与分发，但必须保留作者署名与许可证声明，二次分发须注明原作者与原始出处。完整条款见同目录 LICENSE.txt。

一套通用流程：确认参数 → 准备素材与关键词 → 撰写/抽取文章 → 登录后台 → 现场核对表单 → 填写发布 → 提交并核验 → 汇总输出文档。

核心原则：知识库以外的东西一律"随站点变"。本技能不预设、不默认任何站点，也不预设任何站点的栏目路径、文章类型、分类选项与后缀候选词——这些在不同网站上完全不同，必须每次按本次任务取值。

第二条核心原则：一切外部输入（关键词、标题、文章内容、图片目录、输出目录、账号）都必须是用户本次提供的。技能里不预置任何路径、不沿用上次的路径、也不替用户去磁盘上找——用户没给就停下来问。用户提供了成品就原样使用：给了标题不再修改（包括不加后缀），给了文章内容不再创作、不改写、不扩写——技能的职责只剩"发布 + 汇总"。

首要原则：哪些随站点变、哪些固定

改技能、写流程、填默认值时，先看这张表。左边的东西一旦写死就等于把技能绑死在某个站点上。

落到执行上就是七条硬规矩：

1. 每次开工都按 Step 0 走一遍确认单，哪怕上次刚发过同一站点——栏目与分类选项会变，用户这次的意图也可能不同。
2. 用户给的取值只用于本次。不要把"选购指南""仪器仪表-传感器"这类具体值写进技能文件当默认。
3. 关键词来源等素材路径一律由用户本次提供：技能文件、脚本注释、示例、README 里都不许预置可用路径；用户没给就标"待确认"并去问，不许扫描本机磁盘找关键词表，也不许把上次用过的路径当默认填上。
4. 站点跑通后只沉淀"结构"：把该站的登录入口、字段映射、编辑器类型、坑点追加到 references/site-examples.md（标注为某站示例），供同类站点参考；它是参考资料，不是默认值来源。
5. 用户提供成品就原样用：给了标题就按给的标题发——不加后缀、不润色、不微调；给了文章内容就按给的内容发——不创作、不改写、不凑字数。Step 2 的写作规范只在"没有成品、需要按关键词写稿"时才用；对用户成品最多做发布所需的最小技术处理（拆篇、分段、剔除页眉）。
6. 价格是红线，永远归用户：站点表单出现价格 / 报价 / 售价一类必填项时，用户没给值、也没给填写规则就停下来问，不许代填，不许用 0 / 1 / 面议 / 电议 / - 等占位值蒙混。正文里同样不许出现价格。详见 references/required-fields.md 的「价格红线」一节。
7. 写法不设固定格式，内容必须合规：结构、段落长短、语气配比都不规定，按题材与站点自行安排；但合规红线（价格、极限词、具体数据、联系方式、站外链接、品牌案例）一条都不能碰，且必须跑 scripts/check_articles.py 机械校验，不能只靠肉眼。详见 references/writing-guidelines.md。

执行方式（平台无关）

本技能不绑定任何 AI 工具。宿主差异集中在三处，全文用三个占位符表示：
{PYTHON}（跑脚本的解释器）、{BROWSER}（操作后台的浏览器能力）、{DELIVER}（把产物交给用户的方式）。

开工前先跑一次探测，把三个占位符换成实际值：

{PYTHON} scripts/detect_env.py

它会直接打印本轮该用什么值。完整说明（各宿主取值、降级规则、安装位置）见 references/environment.md。

执行时的三条不变约束：

• 后台操作走 {BROWSER}（浏览器自动化），遵循 observe-act-observe：每步操作后取一次页面状态再决定下一步。
  探不到浏览器能力就降级为人工——如实告知用户、把稿子交出去，不许假装已发布、不许编造发布结果。
• 登录账号密码、滑块/拖动验证、短信/扫码/人机校验：一律交给用户人工完成，不要代填密码、不要尝试绕过验证码。
• 本地素材解析、关键词抽取、合规校验、汇总文档生成用 {PYTHON} 跑 scripts/*.py（见下文）。

Step 0 · 前置提示：开工前一次性确认发布参数

这是技能被唤醒后首先要输出的内容。目的：把下面 15 项参数一次问清，之后一路做到汇总文档，不再回头打断用户。

0.1 先做差异比对，别重复问

对照用户这条消息里已经给出的信息逐项打勾：已给的填进确认单并标「已确认」，不重复问；没给的标「待确认」。用户给了路径/账号这类信息后，不要再去问一遍"请问您的网站是"。

三条禁止事项（最容易犯的偷懒行为）：

• 不要替用户猜值：没给的一律"待确认"，尤其不许拿别的站点/上次任务的值来填。
• 不要自己去磁盘上找素材：关键词来源、图片目录这类路径，用户没说就不许用 ls/glob/搜索去猜（"上次那个表是不是还在 D 盘某个目录里"），也不许因为"上次就是那个"直接填上。
• 不要因为缺项多就自己编一套开工：缺关键词来源、缺站点、缺篇数中任意一项，都必须先问再动手。

0.2 输出「发布任务确认单」+ 填空模板

打开 references/confirmation-form.md，把里面的「发布任务确认单」与「填空模板」两份原样输出给用户。

要点（照着做，别凭印象自己编一版）：

• 用本次实际取值填充；没给的一律留空并标「待确认」。
• 二选一项（主图／配图／汇总文档／标题后缀）必须给出「要／不要」让用户勾，不许只写「待确认」。
• 模板里不预填任何默认值，路径类字段尤其要留空。
• 用户给了标题 → 标题原样用（不加后缀）；给了正文 → 正文原样发布（不创作改写）。

用户不想在对话里逐条填 → 走 0.5，改用填写表。

0.3 参数含义与追问方式

15 项参数的含义、追问要点与追问方式，见 references/parameter-glossary.md —— 要输出确认单或判断缺项时读它。
这里只留一句：所有取值一律以用户本次提供为准，那份文件里没有任何默认值。

0.4 信息不全时的补全提示（分级处理）

缺项分三级：A 阻断级（不补不能开工）／B 可默认级（声明式缺省）／C 可后置级（登录后核对）。
完整分级表、「补全提示」输出模板与纪律，见 references/completion-prompts.md —— 存在 A 级缺项时读到那里照做，停下来等用户。

0.5 另一条填写通道：填写表（用户不想逐条对话时用）

用户提出"能不能给个表单让我填""别让我一条条打字"时（也可主动提供），改用界面填写：

1. 把 assets/intake-form.md 里 html 代码块的内容原样写出为工作目录下的 intake-form.html（一行都不许改），再用 {DELIVER} 打开它，让用户直接在页面里填。
2. 用户填完有两条回路，都收：
   - 点「下载 intake.json」→ 把文件保存路径告诉你 → 你读该文件；
   - 点「复制确认单文本」→ 直接粘回对话 → 你按文本逐项登记。
3. 读到 intake.json 后：已填的项直接进确认单并标「已确认」，不再重复追问；没填的仍标「待确认」，按 0.4 分级处理。
4. intake.json 字段含义：site_url / account / entry / count / article_type / category / other_required[] / keyword_source{kind:table|words|titles|none, path, words[], titles[], exclude} / pick_mode / keyword_field / suffix_needed(true/false/null) / suffix_rule / content{kind:write|file|paste, path, text} / master_image / inline_images / image_dir / image_count / output_doc / output_name / output_dir。

填写表只是填写工具，不豁免任何纪律，四条边界照旧：

• A 级缺项（站点、账号、篇数、关键词来源）照样停下问，页面上的红色提示也已经告诉用户了。
• 页面里的灰色斜体是格式示例，不是用户填的值——www.example.com 这类一律不许当成真实取值。
• 表单不收集密码（页面里明写了），密码仍要在对话里单独要，且不进任何文件。
• keyword_source.kind == "titles" 或 content.kind 非 write 时，按 1.0 的成品规则处理：标题/正文原样用，后缀作废。

Step 1 · 准备素材与关键词

1.0 先分清：用户给的是素材还是成品

• 成品判定以用户原话为准；如果拿不准给的是"定稿"还是"参考"，问一句再动笔，不要默认替用户优化。
• 标题与正文可以混着给（给了标题+对应正文 → 全部原样用；只给标题 → 标题不动、正文按 Step 2 写）。

1.1 关键词抽取（关键词表来源时）

用 scripts/pick_keywords.py 随机选词，不要手翻表格：

# 只看词库概况（多少条、取哪张表）
{PYTHON} scripts/pick_keywords.py --input "<关键词表路径>" --list

# 随机抽 5 条，结果存 JSON（seed 给定后可复现；换 seed 即换一组）
{PYTHON} scripts/pick_keywords.py --input "<关键词表路径>" --count 5 --seed 20260922 --out keywords.json

# 避开历史已发过的词
{PYTHON} scripts/pick_keywords.py --input "<关键词表路径>" --count 5 --exclude "已发词1,已发词2"

• --input 只能是用户本次给出的路径（或用户直接给的词）。用户没给就回 Step 0 去问：不许扫描磁盘猜路径，不许因为"上次用的是某个表"直接填上。用户说"还用上次那个表"时，仍要把该路径写进确认单让用户过一眼再跑。
• 支持 .xls（需 xlrd）、.xlsx（需 openpyxl）、.csv、.txt；自动跳过表头、去重、取每行第一个非空单元格。
• 抽取结果里每条词就是该篇的核心关键词，直接用于：标题嵌入、关键词字段、标签生成、后缀拟定。
• 抽完看两个数：pool_size（可用词数）与 dropped_as_header（被当表头跳过的行数）。若 pool_size 明显偏小或被跳过的行里疑似有有效词，回头问用户要整理好的纯词表，不要硬着头皮抽。
• 同批不重复（脚本用 sample 保证）；用户要求"必须避开以前发过的"时用 --exclude。
• 抽完把词表列给用户看一眼再动笔（一两行即可，不啰嗦），避免白写 5 篇。

1.2 标题后缀拟定（用户要求加后缀时）

后缀必须与文章主题 + 该篇关键词相关，不是随便挂个词：

1. 从该篇关键词里提取可作后缀的成分：对象（声纹/局放/开关柜）、场景（配电房/数据中心/矿山）、或价值点（在线监测/智能感知/故障预警）。
2. 选与正文实际讲的内容一致的那个；正文没讲"低成本"就不许用"-低成本"。
3. 长度 2–6 字、带前导 - 或按用户给的分隔符；同批可以每篇不同，但同一后缀连用不超过 2 篇。
4. 若用户给了候选词表，只在候选词里选，不要自创。

1.3 记 plan.json

把本次参数与每篇的稿子记成一个 plan.json（结构见 scripts/build_output_doc.py 文件头），字段：本次任务信息（网站/入口/文章类型/分类/后缀规则/关键词来源/是否主图配图/日期）+ articles 数组（每篇 title / suffix / keyword / tags / body / status）。

• 只记账号，绝不记密码。
• 正文用纯文本、段落换行分隔；"一、二、三、"小节标题会在汇总 Word 里自动加粗。

1.4 已有文稿时（成品通道，原样发布）

用户给 .docx / .txt 实体文稿而非关键词时，用脚本拆篇，不要现场 improvise：

{PYTHON} scripts/split_articles.py --input "<文稿路径>" --out <plan.json>
{PYTHON} scripts/split_articles.py --input "<文稿路径>" --out <plan.json> --title-max-len 40

• Word 有标题样式时按样式切分；没有（或 txt）则按"短行即标题"猜测，--title-max-len 调上限。
• 重复出现的短行判为页眉/页脚自动剔除，并在报告里列出剔了哪些。
• 跑完必须看一眼拆分报告：拆了几篇、每篇认定的标题是哪一行、剔掉了哪些行。
  拆错了代价很大——那是用户的成品，原则要求原样发布。

这是成品通道：拆出来的标题与正文按用户给的原文使用，不套写作规范、不改写、不凑字数、不追加后缀；
只允许发布所需的最小技术处理——拆篇、空行/换行整理、剔除页眉噪音。
发现疑似缺段、乱码，指出来让用户确认，不要擅自补写。

Step 2 · 撰写 / 抽取文章

• 仅当用户没有提供成品（标题/正文）时才走本步；给了正文就跳过创作，给了标题就不动标题。
• 写法不设固定格式：结构怎么分层、段落多长、语气偏口语还是偏技术，都按题材与站点自行安排，
  不套模板、不要求同一批文章长一个样。具体要求见 references/writing-guidelines.md。
• 但合规是硬要求：每篇不低于 900 字；无品牌名与具体案例、无极限词、无价格、无百分比等具体数据、
  无联系方式与站外链接。
• 写完必须跑脚本校验，不能只靠肉眼：

bash {PYTHON} scripts/check_articles.py --input <plan.json> # 只报告 {PYTHON} scripts/check_articles.py --input <plan.json> --strict # 有红线/错误退出码 1

• 价格是最高优先级红线：正文里不许出现价格；站点表单有价格必填项而用户没给填写规则，
  停下来问，不许代填，不许用占位值蒙混（见 references/required-fields.md）。
• 对用户提供的成品，合规红线只"指出"不"擅改"：脚本报出极限词、价格、联系方式等问题的位置，
  原样告诉用户，由用户决定改不改；技能不自行删改用户原文。
• 标签与正文关键词对应，通常 4–5 个，每个 2–6 字（用户成品里自带标签的按用户的用）。

Step 3–6 · 登录、核对表单、填写发布、提交核验

完整实操步骤见 references/publishing-playbook.md（登录 → 现场核对 → 填表 → 配图 → 提交核验）。
只做汇总文档、不发布的任务不用读它。下面三条是其中最容易出错的，先记住：

1. 登录后必须现场核对表单：栏目路径、文章类型、分类选项只有登录后才看得到真实可选项。
   与用户所说不一致时按"一致→走 / 等价→换词点明 / 缺失→停下问"三态处理，不自己挑一个。
2. 必填项按三级取值：用户给的 > 机械型可代填（须声明）> 内容型必问。
   价格永远落在第三级——必填且用户没给规则就停下来问，占位值一律不许填（见 references/required-fields.md）。
   非必填字段默认一律不填。
3. 填表只按通用语义找字段：标题用户给了就原样填（不拼后缀、不润色）；主图默认不传；
   正文用富文本编辑器的 JS API 写入，不要用原生 textarea。

Step 7 · 汇总输出文档

{PYTHON} scripts/build_output_doc.py --input <plan.json> --output "<输出目录>/技术文章汇总.docx"

• 文档顶部自动生成任务信息表（发布网站、登录页、账号、发布入口、文章类型、分类选项、后缀规则、关键词来源、发布日期、是否主图/配图），字段取自本次 plan.json——站点不同，表里内容自然不同，脚本不预设任何站点。
• 每篇标题下自动带关键词、标签、分类、文章类型、发布状态行（给了 url 还会带发布链接行），正文分段并把小节标题加粗（十一、 1. （一） 等写法都能识别）。
• 任务信息表里是否出现"标题加后缀"一行，由 plan.json 的 suffix_needed 决定（字段结构见脚本文件头）。
• 正文宋体、标题黑体，不生成目录。
• 用 {DELIVER} 交付，name 带 .docx 后缀。
• 最终回复简短（不超过 8 行 / 300 字）：说清文档名、篇数、用的关键词与后缀、以及站点上临时调整过的地方。

失败与回退

发布被打回、编辑器报错、站点与用户所述冲突、缺关键输入、某篇没发成功时的处理，
以及运行环境适配（跨平台：浏览器能力、Python 解释器、产物交付方式），见 references/failure-recovery.md。

其中唯一没有"先发布再补"例外的一条：必填项里出现价格而用户没给规则 → 停下来问。

参考文档（按需打开，不必一次全读）