Community寫作與編輯github.com

Free-cat/ste100

撰寫、檢查及編輯符合 ASD-STE100 簡明技術英語(STE,第9版)的文件。當使用者提及 STE、ASD-STE100、簡明技術英語、簡明英語或受控語言,以及要求撰寫或改寫程序、工作說明、維護任務、手冊、操作手冊、使用者指南或安全警告,以使文字明確無歧義、易於翻譯或易於非英語母語者閱讀時使用。

ste100 是什麼?

此技能將 AI 代理(如 Claude、Cursor 或 Codex)轉變為 ASD-STE100(第9版)規範的專家,這是航空和技術領域中廣泛使用的受控語言。它支援三種主要任務:從草稿或事實撰寫全新 STE 文件、根據53條規則和約900個核准詞彙檢查現有文件以不符合項報告,以及編輯文件使其符合規範。此工具可自動執行結構化檢查,包括執行 Python 腳本,該腳本可找出可程式化偵測的違規情況(如未核准詞彙或被動語態),同時指導使用者找出腳本無法偵測的問題,例如長名詞片語、遺漏冠詞或前後不一致的術語。此技能在文件持續整合流程或維護與安全至關重要的受規範行業(如航空、國防及重工業)中特別有用,能夠確保技術文件清晰、一致且易於翻譯。

相容平台~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/Free-cat/simplified-technical-english/tree/HEAD/skills/ste100

Installed? Explore more 寫作與編輯 skills: steipete/notion, langchain-ai/langchain, bytedance/podcast-generation · View all 6 →

在你喜歡的 AI 中提問

開啟一個已預先載入此 Agent Skill 的新對話。

說明文件

ASD-STE100 簡明技術英語

STE 是一種受控語言:包含53條書寫規則和大約900個已核准詞彙的字典,每個詞彙僅有一種含義和一種詞性。其目的是讓英語能力有限的讀者或翻譯人員只能以一種方式理解每個句子。

選擇工作類型

工作類型使用者提供回傳結果
撰寫筆記、事實、大綱或要求以 STE 撰寫的新文件
檢查現有文件問題報告。不進行改寫。
編輯現有文件以 STE 撰寫的文件,以及變更摘要

若要求不清楚(例如「看一下這份文件」),請先執行「檢查」,並提供「編輯」選項。

參考資料

  • references/rules.md — 所有53條規則及範例。執行「檢查」或「編輯」工作時,以及不確定某項規則時,請務必閱讀。
  • references/dictionary.md — 未核准詞彙及其核准替代詞、詞性陷阱、技術名詞與技術動詞類別,以及專門針對軟體文字的部分。每項工作都應閱讀。大部分違規都出自詞彙選擇。
  • scripts/ste_check.py — 可找出程式能偵測的違規情況。請執行指令,請勿閱讀程式碼。僅需 Python 3 標準函式庫。它會讀取一個檔案並印出問題。它不會修改檔案,也不會使用網路。
python3 scripts/ste_check.py <file> [--type auto|procedure|description] [--terms terms.txt] [--json]

--terms 參數接受一個每行一個技術名詞或動詞的檔案(例如 press、torque)。指令碼將不再回報這些詞語。

此指令碼僅供初步檢查。它無法找出較長的多詞名詞、錯誤的含義、遺漏的冠詞或前後不一致的術語。它也可能會回報一些正確的文字(例如過去分詞用作形容詞時看起來像被動語態)。請檢查每個問題。

最常造成違規的規則

  1. 核准詞彙(1.1–1.3)。 使用字典中的詞彙,並採用其核准的詞性與含義。Check 和 test 是名詞(「Do a check of…」、「Make sure that…」)。Close 是動詞(請寫「near」)。
  2. 技術名詞與動詞(1.5–1.13)。 主題領域的詞彙來自字典之外:零件、工具、材料、軟體物件、單位(名詞),以及特定流程,例如 drill、weld、click、deploy(動詞)。對同一事物使用同一個詞彙。一般動詞(verify、perform、utilize)永遠不是技術動詞。
  3. 動詞形式(3.1–3.5)。 不定詞、祈使句、簡單現在式、簡單過去式、簡單未來式,以及作為形容詞使用的過去分詞。不允許完成式(「has failed」)、進行式(「is running」)、-ing 形式,除非它是技術名詞(「bearing」、「operating temperature」)。
  4. 情態助動詞。 僅限 CAN 和 MUST。不允許 should、may、might、could、would、shall。
  5. 主動語態(3.6)。 在程序中始終使用。在說明中,僅在施動者不明確或不重要時才允許使用被動語態。
  6. 句子長度(5.1、6.3)。 程序:20 個詞。說明:25 個詞。程式碼、帶單位的數字、標籤及括號內的文字,每個都算一個詞。
  7. 每個句子一個指令(5.2–5.4)。 撰寫一個命令。僅在兩個動作同時發生時才能合併。先寫條件,然後是逗號。
  8. 不可省略詞語(4.2、4.5)。 保留冠詞和「that」。不使用縮寫。
  9. 多詞名詞(2.1)。 最多三個名詞。較長的名詞需使用「of」、「for」、「that」或連字號分隔。
  10. 安全與備註(7.1–7.3、5.5)。 警告或注意應以命令或條件開頭,說明風險,並置於其所適用的步驟之前。備註僅提供資訊。若備註包含指令,請將其改為步驟。安全文字同樣遵守動詞規則:應寫「The threads can become damaged」或「This can cause damage to the threads」,而非「The threads can be damaged」。
  11. 段落(6.4–6.6)。 一個主題,主題句開頭,最多六個句子。三個或以上平行項目應使用垂直列表(4.3)。不允許分號(8.1)。

改變句子結構,而不僅是替換詞彙(9.1)。 STE 不是同義詞替換。

不符合 STE不佳(僅替換詞彙)STE
The system should be allowed to cool down prior to commencing disassembly.The system must be let to cool before start disassembly.Let the system become cool. Then, disassemble the unit.
Having confirmed the valve is closed, proceed with removal of the pump.After you made sure the valve is closed, continue with removal of the pump.Make sure that the valve is closed. Then, remove the pump.
The cache may need to be cleared if stale data is displayed.The cache must possibly be cleared if old data is shown.If the page shows old data, clear the cache.

所有三種工作的原則

準確性優先。 STE 改變的是你表達內容的方式,而非內容本身。保留每個事實、數值、公差、條件和範圍限制。不要添加來源中沒有的步驟、警告或數值;若發現可能的遺漏,請將其列為待確認問題。

不要默默猜測。 若來源含糊不清(例如「check the oil」— 是檢查油量還是油質?),請選擇最可能的含義,並將此點列為待確認問題。保持清單簡短:僅列出會改動文字的疑點。三個好的問題能夠得到答案。十個則否。

保留非散文文字: 程式碼、指令、路徑、UI 標籤、零件編號、標牌文字、引用文字、法律文字。

不在 dictionary.md 中的詞語。 此檔案是子集,因此大部分詞語不在其中。請依下列順序判斷,不要列出普通詞語「待確認」:

  1. 是否在未核准表格中?使用替代詞。
  2. 是否指稱主題領域中的事物或特定流程?是技術名詞或動詞。請一致使用。
  3. 是否有你知道更簡單且已核准的詞語(核心動詞清單,或 STE 範例中的詞語)?使用該詞語。
  4. 若以上皆非,且該詞語簡單明瞭、在此處只有一種清晰含義,則可使用。僅在詞語選擇不當會改變含義時才標記。

大寫字母。 字典檔案中以大寫字母顯示核准詞語是標示習慣。文件中請以一般大小寫書寫(使用「use must」,而非「use MUST」)。

你為使用者撰寫的所有內容也應符合 STE: 建議修正、變更摘要與備註。若修正本身也有違規(例如「is usually done by deploying…」),會傳達錯誤的觀念。請提供檔案名稱,而非完整的檔案系統路徑。

聲明。 不要說文件已通過認證或完全符合規範。請說你是依據 STE 規則撰寫或檢查該文件。僅需一次一句話說明字典的限制。若合規是合約要求,建議由受過 STE 訓練的人員,依據官方規範(可至 asd-ste100.org 免費索取)進行審查。

工作流程:撰寫

  1. 將每個部分識別為程序(讀者執行某動作)或說明(讀者學習某知識)。兩者的限制不同。
  2. 建立術語清單:每個事物一個技術名詞,每個流程一個動詞。若有使用者的詞彙表,請使用之。
  3. 撰寫草稿。
    • 程序:編號步驟,每個步驟一個命令,條件在前。將每個警告或注意立即置於其適用的步驟之前,每個備註置於其步驟之後。
    • 說明:短段落,主題句開頭。
    • 標題:簡短名詞片語或命令(「Start the unit」),而非 -ing 形式。
  4. 執行 scripts/ste_check.py。修正發現的問題。再次執行指令碼。直到每個遺留的問題都是你已檢查並接受為止。
  5. 針對指令碼無法發現的問題檢查草稿:多詞名詞、詞性、冠詞、同一事物使用同一詞彙、每個步驟一個指令。
  6. 交付文件。在回覆中(或在規則線下方,標示為給作者的備註),提供:
    • 來自字典之外的技術名詞與動詞(非已核准詞彙如 remove 或 install);
    • 待確認問題。

工作流程:檢查

  1. 閱讀 references/rules.md 和 references/dictionary.md。
  2. 對文件執行 scripts/ste_check.py。
  3. 檢查問題並排除誤報。然後針對指令碼無法發現的問題(撰寫步驟5)和結構問題掃讀文件:警告的位置、備註中的指令、包含多個動作的步驟。
  4. 依以下結構撰寫報告。保持簡短以利後續行動:每個有問題的句子一行,每個在多處重複的問題一行。
# STE 報告:<檔案名稱>

## 摘要
<3-5 個句子:文字類型、整體水準、最重要的三個優先修正事項。>

| 規則 | 主題 | 問題數量 |
|---|---|---|
| 1.1 | 未核准詞彙 | 12 |

## 問題
| # | 位置 | 規則 | 原始文字 | 問題 | 建議 STE 文字 |
|---|---|---|---|---|---|
| 1 | 步驟 2 | 3.6, 1.1 | "The cover should be removed" | 被動語態。「should」未被核准。 | "Remove the cover." |

## 待確認問題
<僅在有疑問時。最多五個。>

報告規則:

  • 每行提供規則編號。精確引用原始文字。
  • 每行提供一個修正,並確保修正符合規則(長度、動詞形式、主動語態、核准詞彙)。
  • 若標題包含三個或更少名詞,請勿將其報告為長句子或多詞名詞。
  • 若安全指示的層級看起來不正確(例如對資料遺失使用「警告」),請在該行中說明。「警告」用於人身傷害,「注意」用於損壞或資料遺失。
  • 不要包含你如何製作報告的資訊(指令碼計數、已排除的誤報、「限制」部分)。在摘要中用一句話說明字典限制即可。
  • 除非使用者要求,否則不要改寫整份文件。

工作流程:編輯

  1. 執行檢查步驟1-3。這些問題是你的工作清單,而非交付成果。
  2. 改寫文件。保留結構、標題、數字及所有技術內容。拆分長句和多動作步驟。將每個警告或注意移至其步驟之前。將備註中的指令改為步驟或安全指示。
  3. 對結果執行 scripts/ste_check.py。修正並再次執行指令碼,如同撰寫步驟4。
  4. 以與來源相同的格式交付文件。然後提供簡短的變更摘要:主要變更類型及其前後範例、每次你改變結構或陳述強度的地方(「should」改為「must」、備註改為步驟),以及待確認問題。除非使用者要求完整的變更記錄,否則不要列出每個已變更的句子。

相關技能