技术科普写作基础要求

这是我在写技术科普内容时逐步沉淀下来的一套自查流程。起因很简单——技术文章里最容易被挑刺的往往不是结论，而是那些"顺手写上去"的绝对化措辞、查不到出处的数据，以及随手配的图。

一份可直接复用的合规与 EEAT 写作技巧及自查清单

写在前面：针对技术文档撰写、编辑、本地化或技术传播相关问题，集中解答关于技术写作服务范围、交付流程、文档类型、行业适用场景以及合作方式等常见问题。内容定位清晰：帮助用户快速判断该平台能否承接其技术写作项目，并了解从需求沟通到成果交付的基本路径。

这份清单不针对任何行业或平台，任何写技术内容的人都能直接用。文末附上一份个人实际在用的核查脚本口径。

一、为什么要做这件事

技术科普有三类典型翻车方式：

1. 说得太满——”只要……就一定……””从根源上解决”。这类表述既不准确，也容易在平台审核上被判夸大。

2. 数据没出处——”行业数据显示””某客户实测””近 N 个项目中有 X%”。一旦被追问来源，全文可信度归零。

3. 配图来源不清——随手放一张厂商产品图或标准正文截图，既可能侵权，也常带品牌 Logo。

对应的处理原则只有一条：不承诺结果，只陈述事实与适用条件。

二、硬性指标清单（逐项自检）

2.1 篇幅与关键词

指标 标准 统计口径
全文字数 ≥1500 字 中文字数 + 英文词数 + 数字个数
主关键词密度 2%–5% 关键词次数 × 词长 ÷ 中文字数
每个二级章节 >300 词（中文约 280–300 字） 按标题切段统计
文章标题 20–30 字 含 1–2 个核心长尾词

2.2 结构要素（缺一项即不合格）

☐ 独立标题（20–30 字）
☐ 摘要块——答案前置，前 100 字点明结论
☐ 核心要点 5 条（”先看这 5 条”）
☐ 文末 ## 参考文献 3–6 条，真实可查、不虚构来源
☐ 免责声明
☐ 个人经验部分附边界说明
☐ 使用 H2 / H3 层级标记（利于搜索引擎与 AI 解析）

2.3 违禁词（绝对化 / 夸大 / 承诺）

必删：

最、第一、唯一、权威、100%、百分之百、确保、保证、国家级、顶尖、
领先、一流、最强、最高、最好、最大、官方背书、铁证、承诺、法律效力、
国际互认、必然、一定、永远、大幅、保障、完全、根本、绝对

容易被忽略的一类：反向承诺。

反例：「它不保证 100% 找到根因」「不能承诺一定定位到问题」

“保证做不到”和”保证能做到”一样，都属于结果承诺。正确写法是陈述事实与条件：

「能否定位到根因，取决于失效模式、样品保存状态与背景信息的完整度。」

保留项（不必删）——表示步骤序号、参数名称的正常语义：

· 步骤/次序：第一步 第一道手段 第一落点 最后 其后

· 参数名称：最大声级 Lmax 峰值最高 最高充电电压 最低带宽 最小电压 初始值 绝对值

2.4 认证资质类表述

如果文章涉及认证、资质、报告作用，措辞必须中性、非承诺：

· 禁用：法律效力 必然被采信 国际互认即有效 权威报告 官方认可 国家认可 免检 全球通行

· 原则：不承诺结果，只陈述事实与适用条件

· 文中应出现”取决于 / 适用条件 / 边界说明 / 不宜照搬”这类限定表述

2.5 侵权与平台风险

项 标准
外部图片 <img> 0 处
配图占位残留 0 处
厂商 / 机构 / 产品品牌名 0 处（须脱敏）
敏感国家名词 0 处（”国家级””国家认可”等）
引流互动 0 处（评论区引导、关注合集、话题标签、投票）

三、技术事实核查（优先级最高）

这是区分”认真写过”和”AI 洗稿”的地方。每篇动笔前都应该联网核实。

3.1 标准号核验

☐ 标准号与名称、年份是否匹配（防张冠李戴）
☐ 中外标准是否被重复归类（例如某 IEC 标准与对应国标实为同一份）
☐ 引用的是否为现行有效版本
☐ 判据条款是否真实存在（防虚构）

3.2 参数与数值

☐ 所有具体数值是否有据可查
☐ 无来源的数据一律删除
☐ 个人经历数据改为定性描述，并声明”个案观察而非行业统计”
☐ 单位、口径、量级是否正确

3.3 术语与机理

☐ 术语是否用对
☐ 测试点 / 指标定义是否正确
☐ 机理归属是否跨体系混编（例如把 A 体系的等级概念安到 B 体系的标准上）
☐ 适用范围边界是否写明

3.4 补强

原表述正确时，不要改掉，而是补上标准条款号 + 具体参数 + 机制解释。这是提升专业可信度最省力的一步。

四、HTML 成稿涵盖内容（公众号 / 落地页通用）

基础文档结构如下：

<!DOCTYPE html>
<html lang="zh-CN">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>{标题}</title>
</head>
<body style="margin:0;padding:0;background:#f5f6f7;">
  <div style="max-width:677px;margin:0 auto;background:#fff;padding:24px 20px;
       font-family:'Noto Sans SC','Source Han Sans SC',system-ui,...;
       font-size:16px;line-height:1.9;color:#2c3033;">
  <!-- 正文内容 -->
  </div>
</body>
</html>

JSON-LD 需要 5 个节点：Organization、Person、WebSite、WebPage、FAQPage。其中 WebPage / Article 每篇文章都不一样，url、name、description、datePublished、dateModified 适配文章内容；其次 FAQPage 只在页面真的有 FAQ 区块时输出，否则每个服务页都显示同一组无关问答，会被 Google 判 FAQ 滥用。

文章详情页模板应追加的片段：

{
  "@context": "https://schema.org",
  "@type": "Article",
  "@id": "https://www.域名.com/具体文章URL.html#article",
  "url": "https://www.域名.com/具体文章URL.html",
  "headline": "这篇文章自己的标题",
  "description": "这篇文章自己的摘要",
  "image": ["https://www.域名.com/文章封面图.jpg"],
  "datePublished": "2026-09-28T10:00:00+08:00",
  "dateModified": "2026-09-28T10:00:00+08:00",
  "author": { "@id": "https://www.域名.com/author/#author" },
  "publisher": { "@id": "https://www.域名.com/#legal-org" },
  "isPartOf": { "@id": "https://www.域名.com/#website" },
  "inLanguage": "zh-CN"
}

部署清单：

1. 公共块 → 放进 /include/header.shtml 或全站母版，所有页面自动带上 Organization / Person / WebSite。

2. 首页 → 母版之外，再单独输出 WebPage(#webpage) + FAQPage(#faq)。

3. 文章详情页 → 母版之外，再输出 Article（自己的 url / 标题 / 日期 / 封面），author 走 @id 引用。

4. 服务 / 产品页 → 母版之外，再输出 Service 或 Product（name、description、provider 引用 #legal-org）。

5. 列表页 / 关于页 → 只留公共块即可，不需要再加内容节点。

这样拆分后，全站公共块保持稳定不动；每篇文章只动自己那一小段，不会互相污染日期和作者。

全局 meta（放 /include/header.shtml，每页不变）：

<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="author" content="Aijda" />
<link rel="shortcut icon" href="https://www.域名.com/img/favicon.png">

<!-- 作者身份链接：全局，每页都带 -->
<link rel="author" href="https://www.域名.com/author/" title="作者" />
<link rel="me" href="https://www.zhihu.org/org/you-er-hong-xin-jian-ce-ji-zhu" />
<link rel="me" href="https://www.zhihu.com/people/hong-wai-yu" />
<link rel="me" href="https://mp.sohu.com/@品牌域名" />

<!-- 站点级 OG 常量 -->
<meta property="og:site_name" content="网站site站名" />
<meta property="og:locale" content="zh_CN" />

全局 JSON-LD（Organization + Person + WebSite）：

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://www.域名.com/#legal-org",
      "name": "网站命名",
      "legalName": "主体法人",
      "alternateName": ["品牌", "注册商标名", "品牌 · 网站名", "域名"],
      "url": "https://www.域名.com/",
      "logo": "https://www.域名.com/69573.png",
      "address": {
        "@type": "PostalAddress",
        "streetAddress": "南淞路299号",
        "addressLocality": "昆山市",
        "addressRegion": "江苏省",
        "addressCountry": "CN"
      },
      "parentOrganization": {
        "@type": "Organization",
        "name": "品牌name",
        "foundingDate": "1996"
      },
      "sameAs": [
        "https://www.品牌域名.com/",
        "https://www.品牌域名cmc.com/",
        "https://www.品牌域名ee.com/",
        "https://www.品牌域名chem.com/"
      ],
      "hasCredential": [
        {
          "@type": "EducationalOccupationalCredential",
          "name": "CNAS实验室认可 L0273",
          "credentialCategory": "certification",
          "recognizedBy": { "@type": "Organization", "name": "中国合格评定国家认可委员会（CNAS）" },
          "description": "CNAS实验室认可证书编号 L0273"
        },
        {
          "@type": "EducationalOccupationalCredential",
          "name": "CMA计量认证 201819123247",
          "credentialCategory": "certification",
          "recognizedBy": { "@type": "Organization", "name": "市场监督管理局" },
          "description": "CMA计量认证证书编号 201819123247"
        }
      ]
    },
    {
      "@type": "Person",
      "@id": "https://www.域名.com/作者",
      "name": "作者",
      "url": "https://www.域名.com/author/",
      "worksFor": { "@id": "https://www.域名.com/#legal-org" },
      "sameAs": [
        "https://www.zhihu.org/org/you-er-hong-xin-jian-ce-ji-zhu",
        "https://www.zhihu.com/people/hong-wai-yu",
        "https://mp.sohu.com/@品牌域名"
      ]
    },
    {
      "@type": "WebSite",
      "@id": "https://www.品牌域名.com/#website",
      "name": "网站名",
      "alternateName": ["商标品牌", "域名"],
      "url": "https://www.域名.com/",
      "publisher": { "@id": "https://www.域名.com/#legal-org" },
      "inLanguage": "zh-CN"
    }
  ]
}
</script>

↓↓↓ 以下字段每篇文章 / 每个页面都要换成自己的值 ↓↓↓

<link rel="canonical" href="{$page_url}" />
<!-- 例：文章页 = https://www.域名.com/news/cleanliness-vda19.html -->

<title>{$page_title}</title>
<meta name="description" content="{$page_description}" />
<meta name="keywords" content="{$page_keywords}" />

<!-- OG：每篇自己的 -->
<meta property="og:type" content="{$og_type}" />
<!-- 首页=website，文章页=article，服务页=website -->
<meta property="og:title" content="{$page_title}" />
<meta property="og:description" content="{$page_description}" />
<meta property="og:url" content="{$page_url}" />
<meta property="og:image" content="{$page_image}" />
<meta property="og:image:alt" content="{$page_image_alt}" />
<meta property="og:image:width" content="1200" />
<meta property="og:image:height" content="630" />

<!-- Twitter Card：每篇自己的 -->
<meta name="twitter:card" content="summary_large_image" />
<meta name="twitter:title" content="{$page_title}" />
<meta name="twitter:description" content="{$page_description}" />
<meta name="twitter:image" content="{$page_image}" />

<!-- 仅文章页输出（首页/服务页不输出） -->
<meta property="og:article:author" content="作者" />
<meta property="article:published_time" content="{$date_published}" />
<meta property="article:modified_time" content="{$date_modified}" />

四条关键约束

1. 全部内联 style —— 公众号编辑器会过滤 <style> 标签与 class，只有内联样式能完整还原

2. 容器 677px —— 匹配公众号正文标准宽度

3. 表格用原生 <table> + 内联样式 —— 可直接渲染，无需转成图片

4. 0 处 <img> —— 视觉全部用纯 CSS 实现（色块、边框、背景色）

5. 关键规则对照 <meta and JSON LD> —— canonical 每篇文章写自己的 URL，自引用；og:url、title、description、article:published_time、og:type=article 等，每篇写自己的 URL、自己的标题和摘要、自己的发布日期。Author Signals —— 新增 Person，补齐 url（指向 about 页）、sameAs（知乎机构号、知乎个人页、搜狐号三条社媒主页），并用 worksFor 关联回 #legal-org。文章子页面只需写 {"author":{"@id":"author link"}} 即可，无需重复定义 Person，sameAs 里的三条社媒移给 Person（社媒是内容号归属）。新增 #webpage 节点，输出机器可读的 datePublished: 2022-03-10、dateModified: 2026-09-20（RFC3339，带 +08:00），并挂 author + publisher + isPartOf(#website) + about(#legal-org) + primaryImageOfPage。同时把 datePublished / dateModified 换成该篇文章自己的真实发布 / 更新时间。

推荐的模块顺序

H1 标题（20-30字）
├ 摘要块（浅蓝底，左侧色条）
├ 核心要点 5 条（浅橙底，左侧色条）
├ 引言：问题场景 → 成因拆解 → 非承诺声明
├ H2 正文若干节（每节 ≥280 字，穿插表格与提示框）
├ H2 实操经验（橙框）+ 边界说明（灰框）
├ H2 要点回顾
├ H2 参考文献（3-6 条）
└ 免责声明（灰块，小字）

五、七步工作流

步骤 动作 产出
1 联网核实技术事实（标准号 / 参数 / 判据 / 适用范围） 识别虚构数据与错误引用
2 原稿量化体检（跑脚本） 字数 / 密度 / 分节 / 违禁词 / 结构缺失清单
3 列出诊断结论 “原文 → 问题 → 改法”对照表
4 撰写 HTML 成稿 同步完成替换、删除、补强、补齐
5 成稿复核 重跑脚本，确认指标全绿
6 微调定稿 补主词提密度、清残留违禁词
7 交付说明 硬伤表 + 自检表 + 发布须知

六、核查脚本核心口径

# -*- coding: utf-8 -*-
import re

def cc(t):
    """字数统计：中文字符 + 英文词 + 数字"""
    c = len(re.findall(r'[\u4e00-\u9fff]', t))
    e = len(re.findall(r'[A-Za-z]+', t))
    n = len(re.findall(r'[0-9]+(?:\.[0-9]+)?', t))
    return c, e, n, c + e + n

# 关键词密度 = 关键词次数 × 关键词长度 ÷ 中文字数
# 分节篇幅   = 按 H2 标题文本定位切段后统计
# 违禁词     = 正则扫描 + 输出 ±28 字上下文便于人工判断
# 结构检查   = 标题/摘要/要点/参考文献/免责/图片/品牌/引流 逐项 bool

脚本的价值在于把”感觉差不多”变成”逐项打勾”——尤其是违禁词，肉眼扫一遍很容易漏，正则扫一遍一目了然。还有 Structured Data 得分低，不是 schema 内容缺，而是 JSON 写坏了，整个脚本块被解析器丢弃。线上版有 1 处语法错误，任何一个都足以让 Google / AI 爬虫放弃整段 JSON-LD，于是扫描器五项全挂。可以用 Google 官方工具 https://validator.schema.org/ 复验，能识别出 5 个节点：Organization、Person、WebSite、WebPage、FAQPage，且无错误。

七、曾经踩过的坑（速查表）

类型 典型错误 正确处理
标准张冠李戴 把 A 标准归到 B 类项目下（或与对应国标重复归类） 重新归类并注明版本对应关系
条款不完整 只引用公式/算法，漏掉上限条件与版本差异 补齐限定条件与版本说明
虚构判据 编造一个具体百分比作为标准条款 改为真实存在的等级体系 + 协议约定
术语用错 把”特性阻抗”说成”差分阻抗”，数值方向反了 更正术语并保留正确的故障逻辑
参数简化 把分档参数写成单一区间 补完整分档表
数值错误 插拔寿命写成 1000 次（实为 10000 次） 核实后更正并补对照表
条件冲突 自拟的测试速度与标准规定不一致 改为”由详细规范约定”并说明原理
虚构数据 “7.2 倍””17%””近 90 个项目中 35%” 全部删除，改定性描述
绝对化 “只有……才能从根源上规避” 改为非承诺表述
反向承诺 “不保证 100% 找到根因” 改为陈述事实与适用条件
品牌词 直接点名设备/器件制造商 脱敏为规格参数描述
测试点错误 把不可直接探测的管脚当作注入点 更正为规范定义的可测点
错别字codex 限制/限值、与/预、在/再 改正（会明显拉低专业印象）
复盘codex 总结一份handoff.MD：当前/已做/问题/待办 形成记忆；汇总提示词prompt下次调用。

三条共性规律

1. 虚构数据是最高频硬伤——凡”某客户””行业数据显示””近 N 个项目中 X%”且无来源，一律核查或删除。

2. 标准号与版本必查——张冠李戴、过期版本、中外标准重复归类，是最容易被内行一眼看穿的错误。

3. 个人经验必须加边界说明——明确”属个案观察而非行业统计”，既诚实，也更可信。

八、交付前的自检表

[ ] 全文 ≥1500 字
[ ] 主关键词密度 2%–5%
[ ] 每个二级章节 ≥280 字
[ ] 标题 20–30 字且含长尾词
[ ] 摘要 + 5 条核心要点 + 参考文献 3–6 条
[ ] 违禁词零命中（保留项已人工确认）
[ ] 无结果承诺 / 无资质效力承诺
[ ] 无品牌词 / 无外部图片 / 无引流互动
[ ] 免责声明 + 边界说明完整
[ ] HTML 全内联样式、表格可渲染

结语

这套清单最核心的一句话，其实还是开头那句：不承诺结果，只陈述事实与适用条件。

技术写作里，把”能解决什么、在什么条件下成立、边界在哪”讲清楚，比把结论说得斩钉截铁更有说服力——读者要的不是保证，是可复现的判据和可追溯的依据。



标签
Aijda
Aijda
文章: 149

相关文章

实时焦点

第三方检测落地页搭建&GEO推广实操
快速了解中国传统文化
越南工业动态(5.26）
工信部新规|中国RoHS重大升级