聚焦日 · 公司 AI 知识库构建与文档规则

AI friendly 官网构建与内容发布流程介绍

From pages-for-eyeballs to data-for-machines

公司官网是产品知识库对外的集中体现，是对客户输出产品信息的主要平台。今天与大家以新型官网构建为例，探讨约束内部文档规则的必要性，展示发布流程 AI 化的效率提升。主讲：李炎东。

5
章 · 从为什么到开放讨论
1
份 YAML · 单一数据源
5+
个出口 · 人 + AI 共享
2
场现场演示
Chapter 01 · Why AI-friendly

为什么要重构官网Why we had to rebuild the site

先说清楚这次做的不是把官网做好看。这两年大家都有体会，客户和工程师找型号，越来越习惯先问 AI，再翻官网。可我们现在大部分产品资料，AI 是读不明白的。

传统网站，AI 其实读不到

01
规格书是 PDF

关键参数常常是图片或扫描件，AI 抓不到具体数值，只能跳过。

02
目录靠 JS 渲染

很多爬虫和 AI 抓到的是空页面，型号列表根本没进去。

03
满屏营销词

"行业领先""高性能"这类词对 AI 没用，它判断不了产品到底能不能选。

客户现在是先问 AI，再翻官网
  • 很多人第一步是问 ChatGPT、豆包、Kimi："有没有国产的某某传感器推荐"。
  • 如果 AI 读不到我们的数据，我们在它给客户的答案里就直接不出现——不是排名靠后，是根本没有。
  • 它会拿能读到的竞品来回答（AS5600、TI、Allegro），这道题就让给了对手。

那什么才算对 AI 友好

✓结构化：每个参数都是机器能解析的字段
✓单一数据源：一份数据只维护一处，改一次处处变
✓机器可读入口：REST API、MCP、llms.txt
✓把人和 AI 当成同等的读者
提醒一句：挂个聊天框 ≠ AI-friendly
  • 很多公司的"AI 化"就是在官网角上挂个聊天机器人，这只是在旧数据上套了层壳。
  • 底下接的还是锁在 PDF、散落各处的数据，这个聊天框要么答不出，要么照样瞎编。
  • 真正要做的是底层：先把数据变成结构化、单一来源、机器可读，聊天助手只是上面自然长出来的一个出口。
Chapter 02 · Platform overview

网站概览What it does, and how it got here

它不是一堆零散页面，而是同一份产品数据往外长出来的多个出口。一句话先记住：一份数据，两类读者。

单一数据源
一份 YAML
每个产品一份 · 放在 data/products 下按 BU 分目录
↓ 自动同步，从源头长出 ↓
给人用
看得懂、用得顺的页面
产品详情页 选型工具 应用方案 AI 选型助手 /chat/
给机器读
AI 和程序直接读的入口
llms.txt llms-ctx.txt REST API /api/v1 MCP /mcp
对外是 chat.connteck.com（VitePress 静态站），后面是一个 Cloudflare Worker（conntek-aibridge，带数据库、聊天、MCP，还有跑磁场仿真的容器）。对内是 internal.connteck.com，同一套代码，用企业邮箱登录才进得来。因为都来自同一份 YAML，所以不会出现"网页一个数、API 另一个数"。

"一份 YAML"长这样（以 KTH5701 为例）

这就是 AE 维护的那一份。结构化的字段，机器一读就懂。产品页、选型表、API、AI 助手全从它来。

yaml 
# data/products/BU1/KTH5701.yaml
product_id: KTH5701
name: KTH5701 - Full-function 3D Position Sensor
category: 3d-hall   bu: BU1   status: active
# --- display: 决定它进不进选型矩阵，没有就搜不到 ---
display:
  family: '3D 霍尔 3D Hall'
  type_zh: '3D 磁角度传感器·57 系列'
  matrix: { res: '16-bit', interface: 'SPI / IIC', rate: '30 KSPS' }
owner: zuoxinchi
# --- documents: 下载资源，每条都带版本和出处 ---
documents:
  datasheets:
    - name: KTH5701 AQ1 Datasheet (中文)
      url: /downloads/KTH5701/KTH5701AQ1_DS_CN_V2.0.pdf
      version: v2.0   grade: AQ1

从静态官网，到 AI friendly，走过这三步

第一步
静态官网
产品信息散在手写页面里，改一处要改好多地方，容易对不上。
→
第二步
数据驱动
引入 YAML 单一数据源，每个产品一份，自动同步页面、选型表、API。
→
第三步
AI friendly
长出 AI 选型助手、llms.txt、MCP、磁场仿真，AI 读同一份数据。
Chapter 03 · See it work

流程演示The update workflow, live

演示 A：一份规格书怎么更新上线

真实案例：KTH5701 / KTH5791 的 datasheet 从 V1.x 升到 V2.0，当时就是这么走的。

01
AE 填 Issue
中文表单，改哪个型号、改什么。没有 YAML、没有命令、没有代码。
→
02
Claude 改 YAML
只改那一份 YAML，重生页面、跑校验，开 PR 逐行看 diff。
→
03
CF Pages 出 Preview
合并前就能看到、和正式上线一模一样的页面。
→
04
AE / PM 审
CODEOWNERS 按 BU 自动通知该谁审，不用自己记得找谁。
→
05
合并即上线
两三分钟后，产品页 / 选型表 / API / AI 助手同时变。

演示 B：让外部 AI 通过 MCP 读我们的产品库

在 Claude Desktop / Cursor 里配上我们的 MCP 端点，问同一个问题，差别一目了然。

没接 MCP 的普通 AI
"3.3V 的线性霍尔，推荐一颗？"
要么答不出昆泰型号，要么直接推 TI、AKM——因为它训练数据里没有我们。
VS
接了 MCP 的同一个 AI
"3.3V 的线性霍尔，推荐一颗？"
给的是昆泰在售型号和真实参数——因为它现在能调工具、读我们的库。
  • 这就是这章想说的：谁的数据 AI 读得到，谁就在 AI 的推荐里。
  • 再往前一步，客户的、分销商的、第三方选型工具的 agent，都能通过这个口读懂并推荐我们的产品，相当于给昆泰开了一个一直在线、和产品库同源的 AI 前台。
Chapter 04 · Data governance

数据治理：几条不能破的规矩Why the data matters more than the tooling

前面讲的是网站和流程，"快"和"自动"是能做到的。这一章要说点不一样的：流程再顺，喂进去的若是错参数、编的数，AI 只会更快、更有底气地把错的告诉客户。

垃圾进，垃圾出
  • 我们把 AE 从填 Issue 到上线压到两三分钟，但流程只解决了"快"和"一致"，没解决"对不对"。
  • 一份 YAML 同时喂五个出口，错一处，五处一起错，而且对外是同一个"事实"。
  • AI 不会说"这个我不太确定"，它会用很顺、很肯定的语气把编的数说出来。一个填错的数字，杀伤力跟过去发错一整版 datasheet 差不多。

四条底线（不是建议，碰线不许合并）

一
YAML 是唯一数据源

只有那份 YAML 是"事实"，其它都是下游。要改参数就改它这一处，别在出口上打补丁。

二
md / yaml / pdf 三版本同源

三个都要能追回同一份数据，不能 pdf 里的值和 yaml 对不上。

三
PDF 必须用统一 LaTeX 模板

不许个人 Word 自排一版发出去。格式一致、可复现、能批量重生。

四
每个数据真实、可追溯

参数、竞品、案例都要有出处（datasheet 第几节第几版 / 实测）。不确定就标"待确认"，别填差不多的数。

三个版本各管各的

YAML
给机器读 · 唯一事实源，所有自动化和 AI 都从这取数。
Markdown
给人 + AI 读，能在 PR 里逐行 diff，谁改了哪个参数一目了然。
PDF
正式交付物，盖章、给客户存档、对外发布，由 LaTeX 模板生成。

同一份数据的 Markdown 版长这样

人能直接读，AI 能直接读，改了哪个参数在 PR 里一行行看得清。它和上面那份 YAML、和最终的 PDF，讲的是同一组数。

markdown 
# KTH5701 全功能 3D 位置传感器
## 概述
集成 X / Y / Z 三轴霍尔元件，16-bit ADC，支持 SPI / I²C。
## 电气特性
| 参数     | 符号 | 最小 | 典型 | 最大 | 单位 |
|----------|------|------|------|------|------|
| 供电电压 | VDD  | 2.8  | 3.3  | 5.5  | V    |
| 工作温度 | Ta   | -40  | —    | 150  | °C   |
> 来源：KTH5701 AQ1 Datasheet V2.0 第 3 节

这事不是某个人的事，是每个人的事

AE

对产品参数的真实和可追溯负责。填 Issue 带上出处，审 PR 要核对值和来源，不只是看格式。

PM

对一款产品对外信息的整体一致负责，参数、定位、应用场景之间别打架。

FAE

客户常见 FAQ 主要由 FAE 提交和审核，把一线最常被问到的问题沉淀进知识库。

平台部门

审核并把关编程器、硬件 CAD、EVB 等设计资料的入库与发布，确保量产资源准确可用。

谁审谁担责

CODEOWNERS 已按 BU 把 PR 路由给对应的人。"看一眼就点同意"和"核对来源后同意"，是两回事。

共同的底线

不确定的数，宁可标"待确认"，也别填一个看着差不多的——因为它会被 AI 当真。

Chapter 05 · Open discussion

开放讨论Open discussion

?
AI native 怎么理解？

如果你有想法，说说看——到底怎么算是 AI native？我们现在这套，做到了吗，还差在哪？

?
在你的岗位上，哪个动作其实是"机械搬运"，可以交给 AI 先出初稿？

AE 把 datasheet 整理成参数、FAE 回常见 FAQ、平台部门整理资料清单——哪些是在创造信息，哪些只是换个格式？只是换格式的那些，是不是该让 AI 先做、人来审？

主讲 李炎东  |  聚焦日分享  |  CONNTEK 内部培训