DSHIO/T 01—2026 標準編寫規則

---

1 範圍

本標準規定了 DSHIO 標準文件的結構、表述規則、編號規則與引用規則。

本標準適用於 DSHIO 標準體系內所有文件的編寫與修訂。

本標準不規定技術內容 —— 技術內容由各產品標準與方法標準規定。

1.1 實施獨立性聲明

本標準只規定文件的組織方式，不規定撰寫工具。用任何編輯器、任何標記語言寫出的文件，只要結構與表述符合本標準，即為符合。

---

2 規範性引用文件

非規範性引用： GB/T 1.1《標準化工作導則 第 1 部分：標準化文件的結構和起草規則》。本標準的體例參照該文件，但做了簡化。

---

3 術語和定義

DSHIO/T 00—2026 界定的術語適用於本文件。

本文件補充定義：

3.1 強制性條款

mandatory clause

使用者必須滿足的條款。使用「必須」「不得」「應」表述。

3.2 推薦性條款

recommended clause

建議滿足但非必需的條款。使用「宜」「不宜」表述。

3.3 允許性條款

permissive clause

允許但不要求的條款。使用「可」表述。

3.4 陳述性條款

informative clause

只描述事實、不構成要求的條款。使用「是」「為」表述，通常出現在注和資料性附錄中。

---

4 文件結構

4.1 必備要素

每份 DSHIO 標準必須包含下列要素，順序不得改變：

4.2 要素的省略

1、2、3、11 不得省略。

4 至 8 可省略，但必須在 1 範圍中說明理由。例如：

本標準為基礎標準，不規定技術要求，因此不含第 4 至 8 章。

4.3 不得缺少的可測性

如果一份文件寫不出第 5、6、7 章，它還不是標準 —— 是說明書。

遇到這種情況，應該：

1. 要麼把要求寫到可測為止
2. 要麼承認它是「指南」而非「標準」，不進入標準體系

---

5 表述規則

5.1 助動詞的使用

禁止混用。 同一份標準中不得用「需要」「建議」「最好」等替代上述助動詞。

5.2 禁止的表述

技術要求章節中不得出現不可測的表述：

5.3 條款的粒度

一條條款只規定一件事。

錯：

插件必須有 engines.dsh、main 字段，且不得依賴本地路徑。

對：

• 5.2.1 插件必須聲明 engines.dsh
• 5.2.3 插件必須聲明代碼入口
• 5.3.2 插件不得依賴本地路徑

理由： 一條條款包含多個要求時，無法逐條判定，也無法逐條複核。

5.4 注的位置

注只解釋，不構成要求。

注使用下列格式，放在被解釋條款之後：

> **注：** 這裡的解釋文字。

要求不得寫在注裡。 如果一句話是要求，它必須是條款。

5.5 示例的位置

示例使用「例：」引導，不出現在強制性條款內，除非是說明寫法。

代碼示例必須可複製粘貼且能運行。 不可運行的示例還不如沒有。

---

6 編號規則

6.1 標準號

DSHIO/T <序號>—<年份>

例： DSHIO/T 10—2026

6.2 序號區段

預留： 每區段向後延伸，不跳號；廢止的號不重用。

6.3 章節編號

1
1.1
1.1.1

最多三級。 超過三級說明條款組織有問題，應該拆分標準。

6.4 條款編號

技術要求與試驗方法章節的條款必須有編號，編號即為引用單元。

5 技術要求
5.1 結構要求
5.1.1 插件聲明          ← 這一級的編號可被引用
5.1.2 patch 文件存在

6.5 附錄編號

附錄 A（規範性）...
附錄 B（資料性）...

規範性附錄的條款與正文同等效力。 資料性附錄僅供參考。

6.6 與條款對應

試驗方法的編號宜與技術要求對應。

例：

• 技術要求 5.2.2 → 試驗方法 6.1 的表格中對應行
• 這樣可以機械地檢查「每條要求是否有對應測法」

---

7 引用規則

7.1 三種引用形式

默認使用日期引用。 標準的可預測性比自動更新更重要。

7.2 禁止循環引用

✗ DSHIO/T 10 → DSHIO/T 12 → DSHIO/T 10

檢查方法： 把每份標準的「規範性引用文件」章節建成有向圖，必須無環。

7.3 引用層級

上層可以引用下層，下層不得引用上層。

管理标准 (30-39)
    ↓ 可引用
方法标准 (20-29)
    ↓ 可引用
产品标准 (10-19)
    ↓ 可引用
基础标准 (00-09)

理由： 方法標準不應該依賴某個產品標準存在，否則加新產品標準就要改方法標準。

例外： 同層之間可互相引用，但不得形成環。

7.4 引用官方文件

引用 DSH 官方文檔時，必須註明：

• 文件名
• 取證方式（文檔章節 / 命令輸出）

例：

依據： 官方 README 第 39 行；dsh --dump-config-schema 輸出的 entry 定義。

不得只寫「官方文檔」。

---

8 版本規則

8.1 版本號

v<主版本>.<次版本>

標準號中的年份不變。 年份是首次發布年，不是版本年。

8.2 狀態

8.3 轉為現行的條件

標準從「草案」轉為「現行」必須同時滿足：

1. 有參照實現 —— 見 DSHIO/T 00—2026 第 3.6.5 條
2. 公示期滿 —— 不少於 14 天
3. 意見已處理 —— 每條意見都有「採納」或「不採納 + 理由」的回覆
4. 無未解決的反對意見 —— 或反對意見已記錄並說明

8.4 廢止

廢止的標準：

• 標準號不再使用
• 頁面保留，標記「廢止」
• 說明被哪個標準取代

不得刪除已廢止標準的頁面。 已發布的引用需要能查到原文。

---

9 修訂記錄

9.1 格式

每份標準末尾必須有修訂記錄表：

9.2 利益關聯聲明

每份標準的修訂記錄必須聲明：

本次修訂由誰提出、誰參與、是否有商業利益關聯。

為什麼： DSHIO 自身也開發插件。如果不聲明，標準就成了給自己開後門的工具。

聲明範例：

DSHIO 自身開發插件 @liangjiehappy/dsh-deepseekbase，本標準全部條款對該插件同樣適用；參照實現即為該插件。

9.3 變更的描述

變更要寫到可核對的程度。

不合格： 「優化了部分條款」

合格： 「5.2.1 的嚴重度從 major 降為 minor，理由：缺少 engines.dsh 不導致安裝失敗」

---

10 多語言規則

10.1 原文語言的確定

每份標準必須聲明原文語言（source_lang）。

當前默認為簡體中文。

10.2 譯文的要求

譯文：

• 必須使用 DSHIO/T 00 附錄 A 的術語對照表
• 必須標記對應的原文版本
• 不得引入原文沒有的要求

10.3 譯文落後

譯文版本與原文版本不一致時，頁面必須顯示：

⚠️ 本译文对应 v0.9，原文已更新到 v1.0。请以简体中文原文为准。

10.4 語言優先級

1. 简体中文 (zh-Hans)   ← 原文
2. English (en)
3. 繁體中文 (zh-Hant)
4. 其他（按引用量决定）

---

附錄 A（規範性）標準編寫檢查清單

發布前逐項核對：

結構

• [ ] 標準頭完整（標準號、名稱、版本、狀態、原文語言、層級）
• [ ] 1 範圍，含 1.1 實施獨立性聲明
• [ ] 2 規範性引用文件（無引用時寫「無」並說明）
• [ ] 3 術語和定義
• [ ] 4–8 齊備，或說明省略理由
• [ ] 修訂記錄表

表述

• [ ] 助動詞只用「必須/不得/應/宜/可/能」
• [ ] 技術要求章節無不可測表述
• [ ] 一條條款只規定一件事
• [ ] 要求沒有寫在注裡
• [ ] 代碼示例可運行

編號

• [ ] 標準號用長破折號
• [ ] 章節最多三級
• [ ] 技術要求和試驗方法條款有編號
• [ ] 附錄標明（規範性）或（資料性）

引用

• [ ] 無循環引用
• [ ] 上層未引用下層之外的方向（除同層）
• [ ] 引用官方文件註明章節與取證方式
• [ ] 日期引用為默認

版本

• [ ] 版本號與變更類型匹配
• [ ] 轉現行前有參照實現
• [ ] 修訂記錄含利益關聯聲明

多語言

• [ ] 聲明原文語言
• [ ] 譯文使用術語對照表
• [ ] 譯文標記對應版本

---

附錄 B（資料性）常見寫作問題

---

修訂記錄