`awesome-agentic-ai-zh` 风格指南¶

这份指南是这份 catalog 的单一真实来源——术语、entry 结构、license 标注、写作风格、禁用词，全部以这份文件为准。

PR 之前请先读完本文。项目维护者也会用这份指南做 review。

📋 目录¶

1. 项目 entry schema
2. 推荐星等定义
3. 禁用词与替代
4. 可保留的英文名词
5. License 标注惯例
6. Stage 页面模板
7. Branch 页面模板
8. 写作风格规范
9. 链接与引用

1. 项目 entry schema¶

每个 project entry 统一格式如下：

### [Repo Name](https://github.com/owner/repo) ⭐⭐⭐⭐

| 字段 | 内容 |
|---|---|
| 语言 | Python |
| License | MIT |
| 推荐度 | ⭐⭐⭐⭐ |

**教什么**：1-2 句话，这个 project 在这个 stage 教什么具体的东西。

**适合谁**：1 句话，谁应该读这个、为什么。

**备注**：1-3 句个人评价。哪里好、哪里弱、哪里可以跳。（可省略）

**怎么跑**：
\`\`\`bash
# 最小安装指令、第一次跑该执行什么
\`\`\`

必填字段（GitHub repo entry）¶

对“真实 GitHub repo”的 entry：

License（SPDX ID 或标注例外，见 5）
推荐度（⭐ × N，见 2）
教什么、适合谁

必填字段（非 repo entry：article / course / video / protocol / documentation）¶

某些 entry 不是 GitHub repo 而是文章、视频、官方文件、catalog hub。对此类：

推荐度（必填）
教什么、适合谁（必填）
形式（必填，标明是 文章 / 视频 / 课程 / 精选列表 / 规格文件 等）

范例：Anthropic — Building Effective Agents 博客文章用 形式 = 文章 + 推荐度，不需要 repo 的 License 字段。

全站资源选择规则¶

推荐度是每个 entry 必填的编辑判断。

用现行官方文档、规范和 model card 核查事实。
新收录的第三方 GitHub repo 在核查时至少要有 1,000 stars，再用知名或广泛使用、可实作的 repo，给读者一条动手路径。供应商官方文档、标准规范、model card 和不可替代的 canonical source 不是第三方 repo，不适用这个门槛。
1,000 stars 只是收录门槛，不是质量分数；它不能替代维护、License、安全、相关性与教学价值检查。页面仍不保存会变化的 stars 数字。
每个 project 都要说明它教什么、适合谁，以及当前状态或限制。

选填字段¶

语言 — 主要编程语言（Python / TypeScript / 中文等）
最后更新 / 状态 — 已停滞或维护放缓时加注
备注、怎么跑

标题格式¶

Stage 1-4 / 6 用 ### [Repo](url)
Stage 5 / 7 / branches 用 #### [Repo](url)（已有上层 H3 分类时）
标题后可接星等：### [Repo](url) ⭐⭐⭐⭐⭐ 或副标题：### [Repo](url) ⭐ 官方

2. 推荐星等定义¶

星等	含义	何时用
⭐⭐⭐⭐⭐	必读 / 必做	该 stage 不读这个会卡住
⭐⭐⭐⭐	强烈建议	深入学该主题的好材料
⭐⭐⭐	扎实范例	值得跑一遍、互相对照
⭐⭐	有用参考	有兴趣再看
⭐	利基 / 进阶 / 为了完整性	多数读者可跳

这些是编辑评分，不是 GitHub stars。只有资源用途、质量或维护状态的查证结果改变时，才能连同理由调整评分。

准则：

同一个 repo 出现在不同 stage / branch 时，星等应一致（除非有明确 audience-specific 理由，且注明在备注）
不要因为“想要看起来推荐”就给高星等。诚实 > 客气
商业产品（Cursor、LangSmith 等）也照同一套标准

3. 禁用词与替代¶

这份文件以简体中文（zh-Hans，中国大陆惯例） 为准。下表列出常见的 zh-TW 用词与替代。

📌 语言代码惯例（BCP 47 / W3C i18n）：repo 用 .zh-Hans.md（不是 .zh-CN.md）标记简体中文档。Hans / Hant 是 BCP 47 script subtag，跟地区解耦——简体中文不只用在中国大陆（也用在新加坡、马来西亚），用 Hans 比 CN 更准确。canonical README 的内容是 zh-Hant-TW（繁体中文，台湾惯例），但档名保持无 suffix 的 README.md 作为 GitHub 默认首页。未来若要分地区可再扩成 zh-Hans-CN / zh-Hant-HK 等。感谢 @xfq（W3C i18n lead）在 #9 指出这个问题。

繁简用词替换¶

禁用（zh-TW）	改用（zh-Hans）
使用者	用户
軟體	软件
資料	数据
專案	项目
腳本	脚本
預設	默认
設定	设置
連結	链接
練習	练习
動手	动手
飛書	飞书
個	个
兩	两
「」	“”
整合	集成
系統	系统
點	点
為	为
過	过
還	还

Overclaim（夸大）用语禁用¶

禁用	改用
全世界最好的 / 业界最强	完整的 / 知名的 / 广泛使用的
production-grade（描述教材时）	教学导向 / 用来学 production pattern 的教材
首选 / 唯一选择	不错的选项 / 入门选择之一
最紧迫 / 最重要	（直接不要修饰）
权威参考（除非真的是官方 spec）	重要参考实作 / 官方范本
没问题（法律或 license 判断时）	使用前先读条款 / 条款还是要自己看过

中夹英（English-in-Chinese）禁用句型¶

禁用	改用
follow 条款	遵守条款
ready-made 教材	现成可改的教材
Gemini Notebook-like 工具	类 Gemini Notebook 的工具 / 类似 Gemini Notebook 的工具
视觉化 node-based	视觉化节点式
Anthropic host 的 server	Anthropic 维护的 server
coding 流程	开发流程 / 程序开发流程

4. 可保留的英文名词¶

技术写作中保留英文比硬翻译读起来更自然的词：

LLM、API、SDK、MCP
agent、tool use、function calling、prompt、prompt caching
framework、library、repo、commit、PR、branch
RAG、embedding、vector DB、retrieval、chunk、token
streaming、async、batch、webhook
marketplace、plugin、skill、hook
project、repo （可保留也可改用“项目”）
production（指“正式环境”时）— 但本 catalog 多数场合刻意避免（见 3）
动手练习、hello-world — 保留

判准：技术文件圈读者习惯的英文术语就保留，避免“太政治正确的中文化”。

5. License 标注惯例¶

常见 license 直写¶

MIT
Apache-2.0
BSD-3-Clause
GPL-3.0
LGPL-3.0

需要加注的特殊情况¶

情况	写法
上游无 SPDX	`NOASSERTION（上游未提供 SPDX；使用前请读 LICENSE）`
AGPL（传染性）	`AGPL-3.0` + 备注：`AGPL-3.0 license（传染性开源）— 修改后散布的衍生产品需遵守条款。`
自定义非商用	`NOASSERTION（自定义非商用）` + 备注：`License 是自定义非商用条款，使用前请先读原始条款。`
多元 license（每个 plugin 自己有）	`NOASSERTION（每个 plugin 独立 license，请看各自目录）`
Creative Commons	直写 `CC-BY-4.0`、`CC-BY-NC-SA-4.0` 等

规则：永远不要把 license 解读成法律建议。“研究 / 个人使用没问题”这种句子禁用。改成“使用前先读原始条款”。

6. Stage 页面模板¶

同一个模板适用于两个位置： - stages/0X-*.md — 共用基础（0-2）+ Track B（Stage 3-8） - tracks/cli/AX-*.md — Track A（A1-A3）的 sub-stage，也照同一模板，只是 cross-link 比例较高（多数 entry 引用既有 Stage 5 / 7 / cli-agents-guide）

每个 stage（Stage 0 除外）都应该有：

# Stage N — 主题

> [English](./0N-slug.en.md) | **简体中文**

[1-2 句话描述这个 stage 的核心问题]

## 📌 学习目标
- bullet 1
- bullet 2
...

## 🧩 先认识核心词

### **正确术语（需要时附中文）**
用一句白话定义。再给一个不会扭曲概念的生活比喻，并说明后面的哪个练习会用到它。

## 🚪 进入条件（Stage 1+ 才需要）
<details markdown="1">
<summary>⏱ 开始前先看：时间、先备工具与预算</summary>

**时间估算**：N-M 周（约 X-Y 小时）

你应该已经：
- ...

</details>

## 📚 必修阅读
先列出 1–3 个完成眼前练习真的会用到的来源。这些链接保持可见，不能只藏在折叠区。

1. [必要链接](url) — 会在哪一步用到
2. ...

<details markdown="1">
<summary>展开：完整阅读顺序与延伸来源</summary>

1. [延伸链接](url) — 描述
2. ...

</details>

## 🛠 动手练习（不是看过就好）

### 练习 N：标题
一句话描述完成后会看到什么。标题留在 details 外，让深链接可见。

<details markdown="1">
<summary>展开详细步骤</summary>

时间、费用、代码、预期输出与疑难排解。

</details>

可运行文件夹必须先提供可直接复制的 PowerShell 指令，再用默认收合的 `<details>` 提供 macOS/Linux 替代指令；同时提供 Path A 和 Path B 脚本，以及不调用 API 的 offline mock tests。SDK 依赖要限制 major version，cloud model 要使用钉住的 model ID；执行前必须验证不受信任的工具名称和参数。Cloud 成本写成 token 公式并标注核对日期，不要假设一个固定金额。不同 framework 的示例各自创建 Python 3.11 `.venv`，不要合并 requirements。测试必须走过核心行为；只验证 import 成功不算通过。

[3-5 个动手练习 items]

## 🎯 精选 Projects

### [Project Name](url) ⭐⭐⭐⭐
[entry schema 见 1]

[N 个 entries]

## ✅ 进 Stage N+1 前的自我检查
你能不能：

- [ ] ...
- [ ] ...

如果可以 → 进 Stage N+1。
如果不行 → ...

## 💡 接下来（选填，多在最后一个 stage 用）

保留标题、成果和第一步可见。次要 <details> 默认不加 open。Ollama Path A 仍是主要路径，但不要看到 Path A 就一律展开：只有它是读者眼前唯一要做的事，而且内容很短时才可加 open。长代码和排错默认收合；Anthropic Path B 也默认收合。不要把可被链接的 heading 放进 <details>，也不要使用三层以上的嵌套收合。

如果一个进阶主题已有自己的必读、核心术语、练习与精选资源表，应使用可独立阅读的三语页面。概览必须提供可见入口；独立页的页首与页尾都要链接回同语系的 Stage。重要术语、必读与带评分的资源保持可见；只有设置、成本、替代方案与排错收合。旧 anchor 要落在语意相符的可见 gateway。

全站白话规则（ELI5）¶

这条规则适用于整个学习地图。目标是让五岁孩子也能明白“现在要做什么”，但不能牺牲技术准确性，也不要使用幼稚的语气。

技术词第一次出现在可见教学文字时，要用粗体标出；H1 章名可以直接使用，但正文第一次使用仍要遵守这条规则。接着先说明它的白话用途，再保留正确术语。例如：“让程序获取数据的入口（API）”。
一句话只讲一个想法。一个步骤只要求一个主要动作。遇到长句、缩写或 jargon，先拆开，或补一句定义。
指令、文件名、错误码、模型名称、价格、数字和安全提醒必须保持精确。
即使不展开任何 <details>，读者也应该知道下一步要做什么，以及成功时会看到什么。
Review 时抽查可见主线。如果第一次来的读者无法用自己的话说出下一步，就先改写。需要多段的原理移入默认收合的内容。

核心词写法¶

每个完成回溯的 Stage／Track，都要在第一个练习前放一个可见核心词区。核心词名称与最短解释不能放进 <details>。
每个核心词独立回答四件事：它是什么、它像什么、这章用它做什么、正确术语是什么。需要更深原理时，再把补充放进默认收合区。
新建页面或轮到该章进行阅读体验重整时，若核心词有四个以上，或能分成两组以上，不要堆成长串小标题。改用一张保持展开的 HTML 表格，栏位固定回答“先处理什么／正式核心词／白话说法／本章用途与技术边界”。同一组用独立 <tbody> 和真正的 <th scope="rowgroup" rowspan="N"> 合并；详细限制可在表格后补充，但不可再复制一份同内容的速记清单。尚未轮到重整的既有页面依 stacked PR 顺序迁移，不因新增本规则而一次改写全站。
只收后文、练习或 self-check 真的会用到的关键概念。不要把每个普通名词拉出来凑数，也不能用“太细”当理由删掉 Zero-Shot、Token、MCP 等必要术语。
三语的概念、顺序、用途与限制一致；英文名、缩写、指令与规格名称保持精确。
scripts/reader-ux-pages.yml 的 core_terms 会记录核心区、第一个练习、三语 term／label、顺序与最低解释长度。加入后只能维持或加强，不能静默移除。

概念图写法¶

先在正文用白话定义核心词，再用图整理它们的关系；不要让图片成为读者第一次遇到术语的地方。
默认参考主页 README：奶油白底、深蓝主字、少量亮色、圆角卡片、简单线条 icon、充足留白和一个主要阅读方向。每张图只回答一个核心问题；信息太多时拆成两张，不缩小文字硬塞。
新画或重画的概念图优先使用现行 GPT-Image-2.5 Sunburst 生成 PNG，不用临时 SVG 代替；如果执行工具没有暴露可选择的 model ID，只能记录“使用当前内置 image generation”，不能假称指定了 Sunburst。旧图轮到该章重画时再套用，不一次迁移所有历史图片。
顶部 Banner 试版例外：明确批准的 README banner 使用自包含动画 SVG，内嵌各语言的原版插图，不重画构图、字体、图标或配色。三语共用路线顺序与 18 秒时间轴，光点沿各自原图的连线移动、节点外框短暂加亮。原版代表性图标也要有意义地动：CLI 光标输入、工具轻转、Hub 箭头旋转、清单确认及角色反馈；13 个裁切区域复用原图，不另换图标，文字与卡片不动。A、B 依次动，最后 2 秒完全静止。内嵌原图使用高质量压缩，同版 PNG 用于静态、减少动态效果与 PDF；文档站有停止／播放控制，README 有静态图入口。SVG 不含 JavaScript 或外部资源，不转 GIF，不提高容量上限；其他教学图仍按上面的 PNG 规则。
三语图保持相同画布比例、构图、共同网格、顺序、数字和限制，并分别提供正确语言的图片与 alt text。卡片位置、外边距、内边距和同层高度应一致。
图里的精确数字也要有官方依据。没有固定规则时，写“多个”“依模型而异”等诚实文字，不要为了好看造出范围。
箭头只走留白通道，不穿过文字、icon 或其他卡片；arrowhead、icon、标签和框线不得互相重叠。同层卡片使用共同网格、等高和一致内边距。
逐张以原始尺寸检查安全边距、文字、简繁字形、箭头、共同网格和对比；任何文字、icon、箭头或边框重叠都视为失败。最后运行 image-locale gate 和三语 MkDocs build。
角色图试版例外：用户批准 branch-decision-tree 沿用原画加入五个代表性图标的小动作，一次只动一个角色，文字、卡片、连线固定。18 秒循环的最后 2 秒静止；三语沿用各自原画布，不另换图标或重排文字。保留静态 PNG、PDF、减少动态与停止／播放控制，仍用 lazy loading。此试版不表示原图三语文字已重新核对：采用前须校正旧英文角色名称等差异；其他图仍用 PNG，旧学习地图先修内容再做动画。
文档站会自动为非首屏教学图加入 lazy loading、async decoding 和可用键盘操作的“打开原图”入口；README 顶端 banner 保持 eager，不要在各章重复手写这些 HTML。新增或替换图片必须通过 scripts/check-image-delivery.py 的单图、单页、总量和构建后 HTML ratchet，并以 320／375／768／1440 px 人工确认 caption、表格、触控目标和图中文字确实能读。

Eval 教学写法¶

第一次解释 Eval 时，先说清楚 Outcome（要得到的结果），再依次介绍 Eval Case、Eval Suite、Reviewed Eval Set。读者看懂这三层后，再补充 Golden Set／Reference Set 等外部常见叫法。
一个 Eval Case 不只是输入。完整案例至少要写明输入、初始状态、成功条件、禁止行为、可选参考答案、grader 与 case metadata；没有参考答案时，也要靠明确条件判断结果。
Reviewed Eval Set 是本项目的主要教学名称，指一组由人检查、可重复使用的完整案例。Golden Set／Reference Set 的实际含义因团队而异；第一次出现时说明当前来源中的含义，不能直接当成跨供应商标准。
Golden／Reference Set 用来检查系统，不只是 input，也不等于训练数据或 Few-shot 示例。图中要把 input 画成完整案例的一部分。
视需要再补充 Trial、Grader、Baseline、Regression、Development Set、Holdout Set。每个词先用白话说明用途，再保留正式术语；重要定义、图、完成条件和学习资源保持可见。
Development／reference cases 用来反复改进；frozen holdout 只在 release candidate 或最后验证时使用。报告至少记录 dataset version、split、case ID、trial 次数、grader、Outcome／Trajectory 和 baseline。
能精确判断就先用 deterministic grader；模型或人工 grader 必须附 rubric 和版本。Regression 要依据多次 trials、预先定义的阈值和失败案例判断，不能把一次随机波动写成必然退步。

Reader UX ratchet¶

只有在一个章节完成三语迁移和人工复查后，才把它加入 scripts/reader-ux-pages.yml。这是逐章收紧规则；尚未整理的页面不必一次通过全部检查。
scripts/check-reader-ux.py 使用保守的 source-level proxy，计算第一次打开页面时可见 Markdown 的非空白字符。默认展开内容与可见 fenced code 会计入；HTML comment 与收合内容不计入。这是可重复的 ratchet，不是浏览器 DOM 字数。
配置会保存各语言的字数上限、允许默认展开的区块数量、必须保持可见的精确 heading／anchor、核心词契约，以及资源表的分组行数。没有重新审查，不得提高上限或删除保护项。
自动 gate 只能防止已知的结构倒退。人工 review 仍须确认：不展开任何 <details> 时，读者知道要做什么，也知道成功时会看到什么。

分组资源表¶

同一分类连续出现两行以上时，改用 HTML <table>，并通过 <th scope="rowgroup" rowspan="N"> 合并分类栏。
每个 <thead> 列标题 <th> 都要加 scope="col"。
每个分类使用一个独立的 <tbody>；分类第一行保留 <th scope="rowgroup" rowspan="N">。
只合并真正共用的分类。不同分类不能因为状态、Context 或其他文字相同就跨组合并。
转换后保留原有资源数量、顺序、链接和三语对应，并用 MkDocs 检查实际渲染。
没有重复分类的短表格继续使用 Markdown，避免增加不必要的维护成本。

含模型、价格、context、授权或生命周期状态的页面，把可见核查日期用小字放在受影响的表格或段落附近。只有该内容本身是补充资料时，日期才跟着收起；页首只保留不显示的机器 marker：

<small>资料核查：YYYY-MM-DD UTC</small>

<!-- freshness: canonical=stages/0N-slug.md; verified_on=YYYY-MM-DD; scope=models,pricing,availability,deprecations; max_age_days=90 -->

日期只写核查范围与日期，不重复加入“资料不会永久正确”等通用提醒。三语 marker 必须完全一致；canonical 一律指向繁中主页。官方没有公布的字段写“官方未公布”，不要从第三方榜单反推；第三方 benchmark 只能教读者怎样自行评测。

Stage 0 例外：可以省略 精选 Projects、进入条件，因为它是 prerequisite gateway。可见主线依次保留跳过判断、4 个学习目标、1 个整合练习、18 项五星学习资源和简短完成检查；时间、环境、补充练习与名词默认收起。

7. Branch 页面模板¶

# 给 [audience] — 专业分支

> [English](./for-X.en.md) | **简体中文**

> [← 回主路线 README](../about.md) · 从 Stage 7 结尾分支出来

## 使用情境
- bullet 1
- bullet 2

## 精选 Projects

### 子分类 1
#### [Project](url) ⭐⭐⭐⭐
[entry]

### 子分类 2
...

## 必修阅读
1. ...

## 必练流程
- bullet 1
- bullet 2

Branch 的 entry 格式可以比 stage 简洁（不一定要完整 schema 表格），但链接 + 星等 + 1-2 句描述是最低门槛。

8. 写作风格规范¶

句长¶

单句不超过 60 字（中文标点计入）
太长就断成两句
英文 rhythm 强迫塞进中文 = 翻译腔，要避免

标点¶

中文用全角：，。：；“”（）
句中夹英文时，英文前后可以留空格也可以不留，但全文要一致
避免 ASCII 逗号 , 在中文句中（会中夹英）

主动 vs 被动¶

偏主动句：“Claude 调用工具” ✓
避免被动句：“工具被 Claude 调用” ✗

“你” vs “我们”¶

“你”优先——这是给读者的学习材料
“我”用于作者发表意见时：“我建议...”
避免“我们”（除了合著者实际存在的场合）

连接词¶

偏好简单：“但、所以、因为、不过”
避免：“然而、因此、由于、之所以”

9. 链接与引用¶

角色路线页¶

完成回溯并加入 scripts/reader-ux-pages.yml 的角色页，在每个语系都保留可见主线 📌 → 🎯 → 🧩 → 🛠 → 📚 → ✅：先说明这条路线解决什么，再列学习目标、用粗体定义核心词、给出可复制的小任务、提供入口，最后做完成检查。先用白话定义核心词，再保留准确的英文术语；不能因为简化而删除后文会用到的技术词。

第一个任务必须小、可测试、可回滚。若任务会修改文件，要写清 read-only plan、人工批准、diff、test、rollback，以及 agent 不得自行 push／merge／deploy。必修阅读、精选项目、完整五星学习资源和安全警告保持可见；替代方案、费用、进阶流程和排错才放进默认关闭的 <details markdown="1">。专门的大型 catalog 可以让每个分类入口与安全边界可见，再让读者按分类展开其中上百项内容。把已有深链接的空 anchor 放到语意对应的新 heading 或 summary 旁，并保留可见的回到主路线链接。

工具的核心身份和 surface 分开写。IDE、CLI、desktop、cloud、CI、SDK 可以同时出现，不能当成互斥分类。OpenRouter 是 Provider／Router，Ollama 是 Model／Runtime，coding agent／harness 是另一条身份轴。

角色页的分组资源表遵守上面的 rowspan 规则。三种语系保留相同 URL 顺序、状态、授权、限制和稳定编辑评分（⭐⭐⭐–⭐⭐⭐⭐⭐）；不写易变的 GitHub stars。ELI5 白话仍须保留等价语意、技术名称和安全边界。

Cookbook¶

Cookbook 的用途、选择表、核心词、六份 recipe 标题、成果、第一个可复制动作、必读、精选资源和完成检查应保持可见；九个完整步骤／替代路径／排错区块默认收合，使用闭合的 <details markdown="1">，且不得添加 open。每个核心词第一次出现时都要用粗体和通俗语言定义；不得把可执行命令或产品名称翻译成另一种东西。

完整资源表固定使用六个独立 <tbody>，分类单元格使用 scope="rowgroup" 和 rowspan。三种语言的 URL、命令、日期、许可证、安全边界和编辑评分必须一致。社区集成必须标明非官方、可能失效，并提供官方 fallback。易变事实附上核查日期，但不得承诺“永远最新”。

Resources 工具柜入口¶

resources/README* 先问读者卡在哪里，再用粗体和白话定义 Reference、Guide、Cookbook、Catalog 与 Glossary。12 份 reference 的入口、用途、限制与回到主路线的链接保持可见；只折叠分文件的理由与 maintainer 规则。不要添加会变化的行数、GitHub stars，也不要把旧产品名称写成当前名称。

完整入口表固定使用五个独立 <tbody>，分类行数为 4／2／3／2／1。同类型只在第一行出现一次，使用 scope="rowgroup" 与真正的 rowspan；不能用重复文字或空白单元格假装合并。每种语言都链接自己的 mirror，并保持相同顺序与语意。

Glossary 查词入口¶

Glossary 的快速地图、工具身份表、每个词的 heading 和一句白话定义保持可见；不能把最短答案藏进 <details>。只有 maintainer 完整分类表、来源与核查说明默认收合。核心词第一次出现在可见文字时继续用粗体标出，并保留准确的技术名称。

工具身份表必须分清 Provider API、Router、Model Runtime、Coding Agent／Agent Harness 与 Agent Framework。不要把容易变化的型号、价格、context 或固定 token 换算复制进 Glossary；改为链接有 freshness gate 的章节或官方文档。

内部链接¶

Stage 之间：相对路径 [Stage 4](./04-agent-frameworks.zh-Hans.md)
Branch ↔ README：[← 回主路线](../about.zh-Hans.md)
跨 stage 引用同一 repo：用全名 + 链接，不要只写“之前提过”

外部链接¶

GitHub repo：https://github.com/owner/repo ✓ 不加 trailing slash
文章 / 部落格：完整 URL，标题用粗体
商业产品（Cursor、Make.com 等）：用官方网址，不是 affiliate
正文第一次提到 repo、规范或官方工具时，就加上超链接；不要让初学者看到裸露的 owner/repo 后还要自己搜索。完整资源表再补状态、授权、限制与评分。

链接文字惯例¶

Repo entry 标题：[owner/repo](url) 或 [Project Name](url)
句中引用：[Repo Name](url) 或 owner/repo（短引用用 inline code）
链接文字避免“点这里”、“按这个”

修改本指南¶

这份指南本身也欢迎 PR。修改前请先开 Issue 讨论——术语决策会影响三语中的许多 entry。

当前 maintainer：@WenyuChiou。

awesome-agentic-ai-zh 风格指南¶