英文原文正文为项目原始 README(英文),本站后续会翻译为中文,当前仅剔除图片与无关章节并统一排版。
一个以项目为基础的课程,讲述构建环境、状态管理、验证和控制机制,使 AI 编程代理可靠运行。
🌍 本课程提供 15 种语言:英语,简体中文,繁體中文,日语,韩语,西班牙语,法语,俄语,德语,阿拉伯语,越南语,乌兹别克语,土耳其语,葡萄牙语(巴西),乌克兰语。请从上方徽章中选择您的语言。
🆕 更新内容 — 2026年8月
边境套索设计细化 — 新部分(4 个细化)
| 什么 | 详情 |
|---|---|
| 新章节 | 前沿安全带设计解析 — 将课程的五子系统框架(指令、工具、环境、状态、反馈)应用于逆向分析四款前沿产品如何构建实际安全带。 |
| Pi | Pi 如何构建其安全带 — “让 Pi 构建你想要的东西”背后的最小内核、可编程扩展和上下文工程。 |
| Claude Code | Claude Code 如何构建其安全带 — 四层内存、五级压缩、钩子及子代理隔离。 |
| Codex | Codex 如何构建其安全带 — 仓库作为真实来源,AGENTS.md 作为目录页,以及工作树隔离。 |
| DeepSeek | DeepSeek 如何构建其安全带 — “一切皆插件”、能力缝隙及事件流水线。 |
| 所有15种语言 | 对所有支持语言的完整翻译覆盖。 |
核心思想: 课程给你一个框架;这些解析向你展示了相同原则在实际生产安全带中如何体现。
图形工程更新 — 1 个新讲座,1 个新项目
| 内容 | 详情 |
|---|---|
| 第14讲 | 从单循环到图工程 — 为什么一个单循环会发展成图:四层叠加(提示 → 上下文 → 循环 → 图)及harness在该叠加中的位置,图的四个组成部分(节点、边、共享状态、路由),为什么循环内的检查点无法在大规模下修复三种结构性失效(Goodhart定律、向上盲点、冲突),构建第一个图的六步框架无关方法演练,图与工作流的区别,锚点,名称出现前后的开源“图工程”项目,编排成本,以及何时值得绘制图。 |
| 项目08 | 将你的工作流画成图 — 三个渐进实验:将你的maker-checker循环画成显式图,添加一个并行分支/汇合节点,然后添加条件回滚边和人工审批节点。 |
核心理念: 循环是只有一个节点的图。当你的任务需要专业化、并行性、共享状态、验证和恢复时 — 它就不再是循环,而是一个图。
🆕 更新内容 — 2026年7月
循环工程更新 — 1 个新讲座,1 个新项目
| 内容 | 详情 |
|---|---|
| 第13讲 | 为什么你需要停止提示你的代理 — 从 /goal 到循环工程的六个原语(自动化、工作树、技能、连接器、子代理、外部状态)、生成器/评估器拆分、四个隐性成本,以及构建你的第一个循环的逐步指南。 |
| 项目07 | 构建你的第一个自动化循环 — 三个渐进实验:目标循环、定时器循环和制作者-检查者循环。比较手动与自动化,测量干预减少情况,并学习如何跳出循环。 |
| 代码模板 | goal-template.md、loop-state-template.md、maker-prompt.md、checker-prompt.md — 可直接使用的循环构建模板。 |
| 全部15种语言 | 覆盖所有支持语言的完整翻译。 |
核心思想: Harness工程构建的是车辆。循环工程设计的是其行驶的道路——而你则从车外设计这条道路。
学习 Harness 工程是一门专注于 AI 编码代理工程的课程。我们深入研究并综合了行业中最先进的 Harness 工程理论和实践。我们的核心参考资料包括:
- OpenAI:Harness 工程:在以代理为先的世界中利用 Codex
- Anthropic:用于长期运行代理的有效 Harness
- Anthropic:长期运行应用开发的 Harness 设计
- 精彩的 Harness 工程
快速入门?
skills/harness-creator/技能可以帮助你在几分钟内为你的项目搭建生产级的 Harness(AGENTS.md、功能列表、init.sh、验证工作流)。
✨ 可视化预览
🏠 课程主页
全面的课程大纲和核心理念介绍,提供清晰的入门路径。
📖 沉浸式讲座
深入探讨现实世界的痛点和动手项目(如项目01),提供沉浸式学习体验。
🗂️ 即用资源库
模板和参考配置,旨在解决多轮AI代理开发中的常见问题,如上下文丢失和任务过早完成。
PDF教材
该仓库现在包含课程内容的PDF构建管道。
- 运行
npm run pdf:build可在本地生成当前配置的PDF课程书。 - 输出文件写入
artifacts/pdfs/。 - 如果希望刷新README预览图像,请运行
npm run screenshots:readme。 - GitHub Actions工作流
release-course-pdfs.yml可以构建PDF并发布到GitHub Releases。
模型智能,框架让它可靠
大多数人都以自己的代价学到一个残酷的事实:即使是世界上最强大的模型,如果没有为其构建合适的环境,也会在真实的工程任务中失败。
你可能也亲眼见过这种情况。你给Claude或GPT在你的代码仓库里一个任务。一开始还顺利——读取文件、写代码,看起来很高效。然后出了问题。它跳过了一个步骤,测试失败,它说“完成了”,但实际上什么都没用。你花在清理上的时间比自己做还多。
这不是模型的问题。这是环境搭建的问题。
证据很明确。Anthropic进行了一次对照实验:相同模型(Opus 4.5)、相同提示(“构建一个2D复古游戏编辑器”)。没有环境搭建,它花了20分钟用了9美元,却产生了无法运行的结果。有完整环境搭建(规划器 → 生成器 → 评估器)时,它花了6小时用200美元构建了一个可以实际玩的游戏。模型没有变,环境搭建变了。
OpenAI在Codex上也报告了同样的情况:在一个良好环境搭建的仓库中,同样的模型从“不可依赖”变成了“可靠”。这不是小幅提升——而是质的飞跃。
本课程教你如何构建这种环境。
文字版本
驮具图案
====================
你 -- > 分配任务 -- > 代理读取执行文件 -- > 代理执行
|
harness governs every step:
|
+--> Instructions: what to do, in what order
+--> Scope: one feature at a time, no overreach
+--> State: progress log, feature list, git history
+--> Verification: tests, lint, type-check, smoke runs
+--> Lifecycle: init at start, clean state at end
|
v
Agent stops only when
verification passes
框架工程的真正意义
线束工程是关于围绕模型构建一个完整的工作环境,以便它产生可靠的结果。这不是关于编写更好的提示语,而是关于设计模型运行所在的系统。
线束有五个子系统:
文字版本
┌────────────────────────────────────────────────────────────────┐
│ 马具 │
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌────────────────────┐ │
│ │ 指示 │ │ 状态 │ │ 验证 │ │
│ │ │ │ │ │ │ │
│ │ AGENTS.md │ │ progress.md │ │ 测试 代码检查 │ │
│ │ CLAUDE.md │ │ feature_list │ │ 类型检查 │ │
│ │ feature_list │ │ git log │ │ 冒烟测试 │ │
│ │ docs/ │ │ session hand │ │ 端到端流程 │ │
│ └──────────────┘ └──────────────┘ └────────────────────┘ │
│ │
│ ┌──────────────┐ ┌──────────────────────────────────────┐ │
│ │ 范围 │ │ 会话生命周期 │ │
│ │ │ │ │ │
│ │ 一项功能 │ │ 开始时的 init.sh │ │
│ │ 一次 │ │ 结束时的清理状态检查表 │ │
│ │ 定义 │ │ 下一次会议的交接记录 │ │
│ │ 完成的 │ │ 仅在可以安全恢复时提交 │ │
│ └──────────────┘ └──────────────────────────────────────┘ │
│ │
└────────────────────────────────────────────────────────────────┘
模型决定写什么代码。
工具束决定何时、何地以及如何编写代码。
工具束并不会让模型更聪明。
它使模型的输出可靠。
每个子系统都有一个职责:
- 指令 — 告诉代理要做什么、顺序以及在开始前需要阅读的内容。不是一个巨大的文件,而是一个渐进式披露结构,代理按需导航。
- 状态 — 跟踪已经完成的、正在进行的和接下来的任务。持久化到磁盘,以便下一次会话能够从上一次离开的地方继续。
- 验证 — 只有测试套件通过才算作证据。代理不能在没有可运行证据的情况下宣告胜利。
- 范围 — 将代理限制在一次只处理一个功能。不越界。不半途完成三件事。不篡改功能列表以隐藏未完成的工作。
- 会话生命周期 — 在开始时初始化。在结束时清理。为下一次会话留下干净的重启路径。
本课程存在的原因
问题不是“模型能否编写代码?”它们可以。问题是:它们是否能够在真实的代码仓库中、跨多个会话、在没有持续人工监督的情况下可靠地完成真实的工程任务?
目前,答案是:没有辅助措施是做不到的。
WITHOUT HARNESS WITH HARNESS
============== ============
Session 1: agent writes code Session 1: agent reads instructions
agent breaks tests agent runs init.sh
agent says "done" agent works on one feature
you fix it manually agent verifies before claiming done
agent updates progress log
Session 2: agent starts fresh agent commits clean state
agent has no memory
of what happened before Session 2: agent reads progress log
agent re-does work agent picks up exactly where it left off
or does something else entirely agent continues the unfinished feature
you fix it again you review, not rescue
Result: you spend more time Result: agent does the work,
cleaning up than if you you verify the result
did it yourself
本课程真正关注的问题:
- 哪些安全带设计可以提高任务完成率?
- 哪些设计可以减少返工和错误完成?
- 哪些机制可以保持长期任务的稳定进展?
- 哪些结构可以在多次代理运行后保持系统的可维护性?
课程大纲与文档
有关完整课程资料,请访问 文档网站。
课程分为三个部分:
- 讲座:13 个概念单元,讲解驾驭工程背后的理论。
- 项目:7 个实践项目,在这些项目中,你将从零开始构建一个自主工作空间。
- 资源库:可直接使用的模板(
AGENTS.md、feature_list.json、init.sh等),可在你自己的仓库中立即使用。
快速入门:今天就提升你的智能体
你不需要在开始获得价值之前阅读所有14讲。如果你已经在真实项目中使用编码代理,下面是如何立即改进它的方法。
这个想法很简单:不要仅仅编写提示,而是给你的代理一组结构化文件,这些文件定义了应该做什么、已经做了什么以及如何验证工作。这些文件存放在你的代码仓库中,因此每次会话都从相同的状态开始。
YOUR PROJECT ROOT
├── AGENTS.md <-- the agent's operating manual
├── CLAUDE.md <-- (alternative, if using Claude Code)
├── init.sh <-- runs install + verify + start
├── feature_list.json <-- what features exist, which are done
├── claude-progress.md <-- session progress (historical filename; agent-agnostic)
└── src/ <-- your actual code
从资源库获取启动模板并将它们放入你的项目中。就这么简单。四个文件,你的代理会话就会比单独运行提示稳定得多。
claude-progress.md 是一个通用的、仅限仓库的会话进度日志;名称保留是为了与课程示例兼容。它与 Claude 代码无关,也不会由任何代理自动更新。Codex、OpenHands、Antigravity 以及其他编程代理在它们的根指令要求启动时读取并在交接前更新时,也可以使用同一个文件。
毕业设计项目:一个真实应用
所有六个课程项目都围绕同一产品展开:一个基于 Electron 的个人知识库桌面应用程序。
┌──────────────────────────────────────────────────────┐
│ Knowledge Base Desktop App │
│ │
│ ┌──────────────┐ ┌──────────────────────────────┐ │
│ │ Document List│ │ Q&A Panel │ │
│ │ │ │ │ │
│ │ doc-001.md │ │ Q: What is harness eng? │ │
│ │ doc-002.md │ │ A: The environment built │ │
│ │ doc-003.md │ │ around an agent model... │ │
│ │ ... │ │ [citation: doc-002.md] │ │
│ └──────────────┘ └──────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────┐ │
│ │ Status Bar: 42 docs | 38 indexed | last sync 3m │ │
│ └─────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────┘
Core features:
├── Import local documents
├── Manage a document library
├── Process and index documents
├── Run AI-powered Q&A over imported content
└── Return grounded answers with citations
选择这个项目是因为它结合了较强的实用价值、足够的真实世界产品复杂性,以及观察配置改进前后的良好环境。
每个课程项目的入门/解决方案都是此 Electron 应用在该演化阶段的完整复制品。P(N 1) 的入门来源于 P(N) 的解决方案——随着你的配置技能增长,应用会不断演化。
学习路径
该课程设计为按顺序进行。每个阶段都建立在前一个阶段的基础上。
文本版本
第1阶段:看到问题 第2阶段:构建仓库
======================== ==========================
L01 强大的模型 ≠ 可靠 L03 仓库作为单一
execution source of truth
L02 马具实际上意味着什么
L04 Split instructions across
| files, not one giant file
v
P01 仅提示 vs. |
rules-first comparison v
P02 Agent-readable workspace
第3阶段:连接会话 第4阶段:反馈 & 范围
========================== =========================
L05 保持上下文活跃 L07 明确任务界限
across sessions
L08 Feature lists as harness
L06 在每个原语之前初始化
agent session
|
| v
v P04 Runtime feedback to
P03 多会话连续性 正确的代理行为
第5阶段:验证 第6阶段:综合所有内容
===================== ============================
L09 停止代理 L11 创建代理的运行时
declaring victory early observable
L10 全流程运行 = L12 最终交接清理
real verification every session
| |
v v
P05 代理验证自己的工作 P06 构建完整的线束
(capstone project)
第7阶段:自动化循环
==========================
L13 停止提示你的代理 —
design loops instead
|
v
P07 构建你的第一个自动循环
(goal loop, timer loop, maker-checker)
第8阶段:构建系统
=============================
L14 将系统画成图表 —
nodes, edges, shared state, routing
|
v
P08 将你的工作流程画成图表
(explicit graph, parallel fan-out/fan-in,
rollback edges, human-in-the-loop)
如果你是兼职的话,每个阶段大约需要一周时间。如果你想加快进度,阶段1到3可以在一个长周末完成。
教学大纲
讲座 — 14 个概念单元,每个单元回答一个核心问题
阅读每场讲座的完整文本,请访问 文档网站。
| 课程 | 问题 | 核心理念 |
|---|---|---|
| L01 | 为什么强大的模型在实际任务中仍会失败? | 基准与实际工程之间的能力差距 |
| L02 | “harness”到底是什么意思? | 五个子系统:指令、状态、验证、范围、生命周期 |
| L03 | 为什么仓库必须成为唯一的真实来源? | 如果代理看不到它,就不存在 |
| L04 | 为什么一个大型指令文件会失败? | 逐步披露:提供一张地图,而不是百科全书 |
| L05 | 为什么长时间运行的任务会失去连续性? | 将进度保存到磁盘;从中断处继续 |
| L06 | 为什么初始化需要单独的阶段? | 在代理开始工作前验证环境健康 |
| L07 | 为什么代理会过度扩展而完成不足? | 一次只做一个功能;明确定义完成标准 |
| L08 | 为什么功能列表是harness的原语? | 机器可读的范围边界,代理无法忽视 |
| L09 | 为什么代理会过早宣布胜利? | 验证差距:信心 ≠ 正确性 |
| L10 | 为什么端到端测试会改变结果? | 只有完整管道运行才算真正的验证 |
| L11 | 为什么可观测性属于harness内部? | 如果你看不到代理做了什么,你就无法修复它破坏的东西 |
| L12 | 为什么每个会话必须保持清洁状态? | 下一个会话的成功依赖于本次会话的清理 |
| L13 | 为什么你需要停止提示你的代理? | 从手动驾驶到自动化循环——目标循环、定时器循环和制作者-检查者分离 |
| L14 | 为什么单个循环会发展成图? | 从单循环到图工程——节点、边、共享状态、路由,以及何时一个图值得绘制 |
项目——8 个动手项目,将讲座方法应用到同一个 Electron 应用
| 项目 | 你做什么 | Harness 机制 |
|---|---|---|
| P01 | 两次运行相同任务:仅提示 vs. 规则优先 | 最小化工具:AGENTS.md init.sh feature_list.json |
| P02 | 重构仓库使代理可以读取 | 代理可读工作区 持久化状态文件 |
| P03 | 让代理从上次结束的地方继续 | 进度日志 会话交接 多会话连续性 |
| P04 | 防止代理做得太多或太少 | 运行时反馈 范围控制 增量索引 |
| P05 | 让代理验证自己的工作 | 自我验证 扎实问答 基于证据的完成 |
| P06 | 从零构建完整工具(顶石项目) | 完整工具:所有机制 可观察性 消融研究 |
| P07 | 构建你的第一个自动循环 | 目标循环、计时循环、制作者-检查者分离、循环状态管理 |
| P08 | 将你的工作流程绘制为图 | 明确的节点/边/状态/路由,平行分叉/合并,回滚边,人类在环审批 |
PROJECT EVOLUTION
=================
P01 Prompt-only vs. rules-first You see the problem
|
v
P02 Agent-readable workspace You restructure the repo
|
v
P03 Multi-session continuity You connect sessions
|
v
P04 Runtime feedback & scope You add feedback loops
|
v
P05 Self-verification You make the agent check itself
|
v
P06 Complete harness (capstone) You build the full system
|
v
P07 Your first automated loop You step outside the loop
|
v
P08 Draw your workflow as a graph You draw the system as a graph
Each project's solution becomes the next project's starter.
The app evolves. Your harness skills grow with it.
资源库
智能体会话生命周期
本课程的核心理念之一:代理的会话应遵循结构化的生命周期,而不是随意进行。 其表现如下:
文本版本
代理会话生命周期
======================
┌──────────────────────────────────────────────────────────────────┐
│ 开始 │
│ │
│ 1. 代理阅读 AGENTS.md / CLAUDE.md │
│ 2. 代理运行 init.sh(安装、验证、健康检查) │
│ 3. 代理阅读 claude-progress.md(上次发生了什么) │
│ 4. 代理阅读 feature_list.json(已完成的内容,接下来的任务) │
│ 5. 代理检查 git 日志(最近的更改) │
│ │
│ 选择 │
│ │
│ 6. 代理仅选择一个未完成的功能
│ 7. 代理仅在该功能上工作
│ │
│ 执行 │
│ │
│ 8. 代理实现该功能 │
│ 9. 代理运行验证(测试、代码检查、类型检查) │
│ 10. 如果验证失败:修复并重新运行 │
│ 11. 如果验证通过:记录证据
│ │
│ 总结 │
│ │
│ 12. 代理更新 claude-progress.md │
│ 13. 代理更新 feature_list.json │
│ 14. 代理记录仍然损坏或未验证的部分 │
│ 15. 代理提交(仅在安全时恢复) │
│ 16. 代理为下一次会话留出干净的重启路径 │
│ │
└──────────────────────────────────────────────────────────────────┘
这个框架控制了生命周期中的每一次转换。
模型决定每一步该写什么代码。
如果没有框架,第9步变成“代理说看起来没问题。”
有了框架,第9步是“测试通过,代码风格检查通过,类型检查通过。”
适合人群
本课程适用于:
- 已经使用编码代理并希望获得更高稳定性和质量的工程师
- 希望系统了解线束设计的研究人员或开发者
- 需要了解环境设计如何影响代理性能的技术主管
本课程不适用于:
- 希望进行零代码 AI 入门的人
- 只关心提示并不打算构建实际实现的人
- 不准备让代理在真实代码库中工作的学习者
要求
这是一个你实际运行编码代理的课程。
你至少需要以下其中一个工具:
- 克劳德代码
- 法典
- 另一个支持文件编辑、命令执行和多步骤任务的 IDE 或 CLI 编码代理
本课程假设你可以:
- 打开本地仓库
- 允许代理编辑文件
- 允许代理运行命令
- 检查输出并重新运行任务
如果你没有这样的工具,你仍然可以阅读课程内容,但无法按预期完成项目。
本地预览
这个仓库使用 VitePress 作为文档查看器。
npm install
npm run docs:dev # Dev server with hot reload
npm run docs:build # Production build
npm run docs:preview # Preview built site
然后在浏览器中打开 VitePress 输出的本地 URL。
先决条件
必需条件:
- 熟悉终端、git 以及本地开发环境
- 能够在至少一种常见应用程序栈中读写代码
- 具有基本的软件调试经验(阅读日志、测试和运行时行为)
- 有足够时间投入到以实现为目标的课程学习中
有帮助但非必需:
- 有 Electron、桌面应用或本地优先工具的经验
- 具有测试、日志记录或软件架构背景
- 曾接触过 Codex、Claude Code 或类似的编程代理
核心参考资料
主要:
- OpenAI:利用工程:在以代理为先的世界中使用 Codex
- Anthropic:针对长期运行代理的有效工程
- Anthropic:长期运行应用开发的工程设计
- OpenAI:展开 Codex 代理循环
- Anthropic:揭开 AI 代理评估的神秘面纱
- LangChain:通过工程改进深度代理
- Thoughtworks / Martin Fowler:为编码代理用户设计的工程
- Cursor:持续改进我们的代理工程
查看完整的分层参考列表在 docs/en/resources/reference/
仓库结构
learn-harness-engineering/
├── docs/ # VitePress documentation site
│ ├── lectures/ # 14 lectures (index.md + code/ examples)
│ │ ├── lecture-01-*/
│ │ └── ... (14 total)
│ ├── projects/ # 8 project descriptions
│ │ ├── project-01-*/
│ │ └── ... (8 total)
│ └── resources/ # Multilingual templates & references (14 languages)
│ ├── en/
│ └── ... (14 total)
├── projects/
│ ├── shared/ # Shared Electron + TypeScript + React foundation
│ └── project-NN/ # Per-project starter/ and solution/ directories
├── skills/ # Reusable AI agent skills
│ └── harness-creator/ # Harness engineering skill
├── tools/ # Zero-dependency shell utilities
│ └── audit-harness.sh # Shell-based harness audit (L03–L12, no Node.js needed)
├── package.json # VitePress + dev tooling
└── CLAUDE.md # Claude Code instructions for this repo
课程组织方式
- 每节讲座都专注于一个问题
- 课程包括8个项目
- 每个项目都要求代理执行实际工作
- 每个项目比较弱装置与强装置的结果
- 重要的是测量出的差异,而不是写了多少文档
技能
该存储库还包括可重复使用的 AI 代理技能,您可以将其直接安装到您的 IDE 或代理工作区中。
- harness-creator:一个帮助您在几分钟内为自己的项目搭建生产级别的 harness 的技能。
工具
零依赖工具,无需安装 Node.js 即可运行。
- audit-harness.sh:一个基于 shell 的审核脚本,用于检查现有仓库与所有五个 harness 子系统(L03–L12)的一致性。当所有 CRITICAL 项目通过时退出码为 0。无需 Node.js — 补充
harness-creator的validate-harness.mjs。
# Run directly on any repo
curl -fsSL https://raw.githubusercontent.com/walkinglabs/learn-harness-engineering/main/tools/audit-harness.sh | bash -s -- /path/to/your/repo
# Or after cloning
bash tools/audit-harness.sh /path/to/your/repo
其他课程
我们的团队还创建了其他课程!快来看看吧:
动手现代强化学习:一个开源的动手课程,从基础强化学习概念到大语言模型对齐、RLVR 和高级智能体系统,桥接学习鸿沟。
现代大语言模型笔记本:一个动手课程,使用 PyTorch 从零构建现代大语言模型,包含 23 个可运行的 Jupyter 笔记本,涵盖分词器、注意力机制、专家混合(MoE)、强化学习从人类反馈(RLHF)、推理、评估和蒸馏。
致谢
本课程的灵感来源于并借鉴了 learn-claude-code 的理念——这是一个逐步指南,从单一循环到独立自主执行,教你如何从零开始构建一个智能体。
- 本文标题:learn-harness-engineering - 线束工程入门教程
- 本文链接:https://www.cn121.com/llm/walkinglabs-learn-harness-engineering.html
- 原项目:walkinglabs/learn-harness-engineering 版权归原作者 walkinglabs 及贡献者所有
- 收录信息:本站于 2026-10-28 收录本项目,本页所列协议与仓库指标均为收录当时的状态;该日期之后原项目的版本更新与协议变更,本页不作同步。
- 开源协议:收录时本项目采用 MIT(查看 LICENSE 原文),本站转载其原始文档(未改动文字,仅剔除图片与无关章节);使用、修改、分发请以该仓库 LICENSE 原文为准。
- 站点出处:本文首发于 OneTwoOne,收录自 GitHub 开源项目 walkinglabs/learn-harness-engineering。
- 内容说明:本页正文为原项目 README 原文(英文),本站后续会翻译为中文(当前尚未译出,仅将二级标题译为中文,便于按栏目定位;标题原文可在下方原仓库中查看),仅剔除了图片与赞助等无关章节、并把相对链接改为绝对地址;页首简介为机器翻译自仓库描述。
- 引用声明:商业转载、第三方聚合或 AI 检索训练引用时,请务必保留以上来源出处、本文永久链接,以及原项目的版权声明与许可信息。
- 下架通道:若原项目此后变更或收紧了许可协议、或作者/权利人认为本站的收录方式(译文、排版适配、简介翻译等)超出其授权范围,请通过 xyd3302001@163.com 发送下架通知,并附上项目地址与本页链接。本站核实后将第一时间删除本页内容,或改为不复制原文的目录性收录;署名更正等其他要求可一并提出。