企业官网建设流程全解析

• 数据集

本篇技术指南以 Remote In Tech（remoteintech.company）开源目录中的 src/companies/asana.md 这条真实公司档案为样本，逐层拆解 Asana 的公司介绍、远程政策、技术栈与申请方式，并对照仓库中的 frontmatter 模板、标签字典、集合逻辑与页面布局，还原一条「远程友好公司」档案从 Markdown 数据到静态页面的完整链路。读完后，你将掌握该目录条目的字段规范、取值约束、渲染机制与贡献流程，能够独立评估或新增同类公司档案。

档案速览：Asana 是谁，档案里写了什么

src/companies/asana.md 是 Asana 在目录中的完整档案，共包含七个信息块：公司简介（blurb）、公司规模、远程状态、覆盖区域、公司技术、办公地点与申请方式。先完整还原档案原文的核心事实：

• 公司定位：Asana 是一款工作管理平台（work management platform），帮助团队组织、跟踪并管理工作。据档案原文，其拥有超过 10 万付费客户，覆盖 190 多个国家与地区，使命是让团队无缝协作，从而带来更高生产力与成功率。
• 公司规模：LinkedIn 显示员工数 1700+（company_size: enterprise，对应「1000+ 员工」档位）。
• 远程状态：远程优先（remote-first），允许团队成员在全球任何地点工作，按价值观而非地理位置招聘。
• 覆盖区域：全球（Worldwide）。
• 技术栈：Go 与 JavaScript（frontmatter 中technologies: [go, javascript]）。
• 办公地点：美国旧金山、美国纽约、爱尔兰都柏林、澳大利亚悉尼四地。
• 申请方式：官方招聘页面（frontmatter 中careers_url: https://asana.com/jobs）。

这些事实全部来自档案正文与 frontmatter，是后续所有数据模型与渲染机制讲解的输入样本。

Frontmatter 数据模型：逐字段拆解 Asana 条目

一条公司档案由 YAML frontmatter 与 Markdown 正文两部分组成。Asana 条目的 frontmatter 完整内容如下（摘自 src/companies/asana.md）：

--- title: "Asana" slug: asana website: https://asana.com/ careers_url: https://asana.com/jobs region: worldwide remote_policy: remote-first company_size: enterprise technologies: - go - javascript addedAt: 2024-10-15 updatedAt: 2024-10-15 ---

对照 CONTRIBUTING.md 给出的标准模板，可逐字段理解其含义与约束：

Asana 档案的addedAt与updatedAt均为2024-10-15，说明该条目在该日期入库。注意 CONTRIBUTING.md 明确要求贡献者不要在 PR 中携带这两个日期字段——它们由维护者统一管理，用于驱动「最近新增公司」集合与页面底部的「Last updated」展示。

取值约束与标签字典：labels.js 单一事实来源

上述取值的「合法集合」并非散落各处，而是集中在 src/_data/labels.js 中统一维护。该文件是区域、远程政策、公司规模与技术标签的单一事实来源（single source of truth），同时被两处消费：

1. JS 侧：通过 src/_data/companyHelpers.js 的regionLabels、remotePolicyLabels、companySizeLabels、techLabels再导出，供集合逻辑使用；
2. 模板侧：通过 Eleventy 全局数据级联暴露为labels.*，供 Nunjucks 模板直接取用。

以 Asana 档案为例，其三个枚举字段在字典中的映射为：

technologies字段的取值同样受字典约束，labels.js 中定义的全部技术标签包括：javascript、typescript、react、nodejs、python、ruby、go、java、php、rust、dotnet、elixir、scala、swift、cloud、devops、docker、kubernetes、mobile、data、ml、sql、postgres、nosql、search。Asana 条目的go与javascript均属于合法取值，分别渲染为Go与JavaScript标签。

从源码结构看，字典化的好处在于：前端展示文本、浏览页分组键、集合计数三者共享同一套枚举，只要新公司条目的 frontmatter 取值落在字典内，其标签、分组与搜索归类就能自动一致，无需额外维护。这解释了为什么 CONTRIBUTING.md 会以表格形式强制约束字段取值范围。

从 Markdown 到页面：渲染管线与元描述生成

档案数据写好后，由 Eleventy 构建管线消费。目录中每家公司共用 src/companies/companies.json 指定的company布局，该布局模板实现在 src/_layouts/company.njk 中，其渲染要点包括：

• 标题与返回链接：页面头部渲染{{ title }}与「← All Companies」返回链接（见 company.njk）；
• 按钮与标签：优先使用careers_url生成「Apply Now」主按钮，否则回退到website的「Visit Website」；随后按region、remote_policy渲染可点击的分类标签，链接到对应的/browse/{region}/、/browse/{remote_policy}/浏览页（见 company.njk）。对 Asana 而言，即渲染Worldwide与Remote First两个标签；
• 技术栈区块：遍历technologies数组，将go、javascript渲染为/browse/go/、/browse/javascript/下的技术标签（见 company.njk）；
• 更新时间：页面底部依据updatedAt字段展示「Last updated: October 15, 2024」（见 company.njk）。

另一处关键机制是元描述（meta description）的自动生成，实现在 src/companies/companies.11tydata.js 的eleventyComputed.description中。其算法逻辑为：

1. 若 frontmatter 已显式设置description则直接采用（companies.11tydata.js）；
2. 否则用正则/##\s*Company\s*blurb\s*\n+([\s\S]*?)(?=\n##|$)/i从原始 Markdown 中提取## Company blurb小节的内容（companies.11tydata.js），Asana 档案即命中该路径；
3. 清理 Markdown 语法（剥离text链接、*_等标记、合并换行与多余空格）；
4. 截断到约 155 字符，优先在句号处截断，其次在空格处截断并补...（companies.11tydata.js）。

由于 Asana 的 blurb 正文超过 155 字符，其最终元描述会落在第一个句号之后——这正是面向搜索引擎与社交分享的规范做法。

集合与分类：档案如何进入浏览与检索体系

Asana 档案并非孤立页面，它通过 src/_config/collections.js 中定义的多个集合进入站点的浏览与检索体系。该文件先将./src/companies/**/*.md的全部档案做内存缓存（collections.js，可避免约 850 个条目被多次过滤），再派生出：

• getAllCompanies：全部公司按title字母序排序，供/companies/列表页使用（collections.js）；
• getRecentCompanies：按addedAt倒序取最近 12 条。Asana 的addedAt为 2024-10-15，是判断其是否进入「近期新增」区块的依据（collections.js）；
• getCompaniesByRegion：按region分组，Asana 的worldwide使其进入 Worldwide 浏览组（collections.js）；
• getCompaniesByTech：遍历每家公司technologies数组建立技术分组，Asana 同时出现在 Go 与 JavaScript 两个技术组中（collections.js）；
• getCompanyTags：汇总technology、region、remote-policy三类标签，附上公司计数并按数量倒序，供标签浏览页使用（collections.js）。

值得一提的边界：首页的「Featured Companies」使用 src/_data/companyHelpers.js 中手工维护的featuredCompanySlugs精选列表（automattic、stripe、netlify、github、linear、zapier、buffer、vercel），Asana 不在其中——说明该目录同时存在「算法分组」（区域/技术/政策）与「人工精选」（首页推荐）两套并行的曝光机制。

如何贡献或维护一条这样的档案

理解了 Asana 档案的结构，就可以按 CONTRIBUTING.md 的流程新增或维护同类条目。核心步骤如下：

1. 在src/companies/下新建{slug}.md文件，文件名必须与 frontmatter 的slug一致；
2. 按模板填写 frontmatter（title、slug、website、careers_url、region、remote_policy、company_size、technologies）；
3. 正文必须包含三个##小节：## Company blurb、## Remote status、## How to apply（CONTRIBUTING.md）；## Company size、## Region、## Company technologies为常用可选小节——Asana 档案七个小节全部齐备，是符合规范的标准样例；
4. 运行npm run build验证构建，然后提交 PR。

仓库通过Validate Company ProfilesGitHub Action 对涉及公司文件的 PR 自动校验，机器人会在 PR 评论区指出问题并阻塞合并，直到修正（CONTRIBUTING.md）。此外目录设有明确的准入红线（CONTRIBUTING.md）：公司必须直接雇佣员工（不接受训练营、中介或自由职业平台）、必须提供真实远程岗位（纯佣金或独立承包销售不计数）、必须属于或围绕科技行业，且careers_url必须指向公司自有招聘页。维护者还会拒绝内容过少或重复的档案。

在本仓库中验证与构建

该档案是仓库的一部分，可本地构建验证。按 README.md 的说明：

npm install # 安装依赖 npm run start # 开发服务器，支持热重载 npm run build # 生产构建

环境要求为 Node.js 22+。构建完成后，Asana 档案会与其他约 850 条公司档案一起，经 src/_config/collections.js 的集合逻辑与 src/_layouts/company.njk 的布局模板渲染为静态页面，供 CONTRIBUTING.md 中的校验机器人与本仓库维护流程持续验证。

综上，一条看似简单的 Asana 公司档案，实际串联了 frontmatter 数据模型、labels.js标签字典、companies.11tydata.js元描述生成、company.njk页面布局与collections.js分类体系五层机制。以它为样例，可以快速掌握 remoteintech.company 目录条目的全部规范与实现细节。

• 数据集