> For the complete documentation index, see [llms.txt](https://docs.jobdone.cc/user_guide/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.jobdone.cc/user_guide/cpm/bc/drawings/web/list/draft.md).

# 草稿列表與送審

### 01｜版本更新與送審

在系統邏輯中，「建立圖說」只是第一步，這動作就像是在雲端櫃子裡建立了一個專屬的「圖說管理資料夾」。後續無論是因為設計變更或是現場套圖修正，所有的圖紙更新都是在同一個圖說資料夾下持續新增「草稿」。

**一、 草稿列表：圖紙的版次紀錄**

進入特定圖說的「草稿列表」後，您可以查看該圖號過往上傳的所有版本。這讓內業與現場人員能隨時對照舊版與新版草稿的差異，確保設計脈絡不中斷。

<figure><img src="/files/moResHPbz0OVeALNfhee" alt=""><figcaption><p>圖一 - 點選草稿欄位</p></figcaption></figure>

**二、 核心功能：加入待審**

草稿列表最主要的操作就是 ![](/files/FpHIw0OExcRvzkbFAOj3)。當您上傳了新的修正檔，必須手動將該筆草稿推入審核流程，否則該圖檔僅會停留在草稿區，不會對現場生效。

{% hint style="info" %}

#### **嚴謹的審核限制：「一圖一審」原則**

為了避免版本衝突與審核混亂，系統設定了嚴格的控管機制：

* 一次僅限一筆：在同一個圖說資料夾（同一個圖號）中，一次只能選擇一筆草稿進入『內審』流程。
* 循序執行：必須等到當前的草稿審核完畢（無論是通過或退回）後，系統才會允許您將該圖號下的下一筆草稿加入待審。
* 實務目的：這是為了確保審核者與現場人員面對的是唯一的「當前待核定版」。防止多份草稿同時送審導致的作業錯誤。
  {% endhint %}

<figure><img src="/files/SiG7W93v5pSUQs2cR4g0" alt=""><figcaption><p>圖二 - 加入待審</p></figcaption></figure>

**三、下載 /** **清理多餘草稿**

如圖三，若上傳了錯誤的草稿或誤選加入待選之草稿，可直接在列表移除，保持管理目錄的乾淨。

{% hint style="info" %}
草稿在加入「待審區」後，並不代表流程已經鎖定。只要尚未點選最終的「提交送審」，該筆草稿皆可隨時刪除。
{% endhint %}

<figure><img src="/files/6U0NbUtZBXD4R7tEv5dM" alt=""><figcaption><p>圖三 - 下載 / 刪除草稿</p></figcaption></figure>

***

#### 01 - 1｜草稿送審

當您在個別圖說下完成 ![](/files/0oDc9V1ab1WnmAQTZ9Xy) 的動作後，請回到圖說列表頁面。

如圖四，在頁面的最右側，您會看到一個 ![](/files/FaRRRG19r1jQBXDrHLCK) 的圖示（通常帶有數字標示目前待處理的件數）。點選該圖示後，系統會開啟一個總表視窗，列出目前所有「已勾選待審」但「尚未正式發出」的圖說草稿。

{% hint style="info" %}

#### 最終檢核

此為提交給審核者前的最後確認機會。您可以在此視窗中再次核對清單內的圖說名稱、檔案名稱是否正確，確保送出的資料完整無誤。
{% endhint %}

<figure><img src="/files/wA7u70ub7PJWpr2bfIFd" alt=""><figcaption><p>圖四 - 點選<kbd><mark style="color:purple;"><strong>待送內審</strong></mark></kbd></p></figcaption></figure>

**送審附件與補充說明**

如圖五，在提交每一批待送內審的圖說草稿時，系統支援「上傳附件」功能。這些附件會隨同圖紙一併進入審核區，供審核者在覆核圖面時作為參考依據。

<table><thead><tr><th width="152.9400634765625">補充</th><th>附註</th></tr></thead><tbody><tr><td><strong>1. 附件的實務用途</strong></td><td><p>附件通常用來存放「非圖紙類」但與施工依據密切相關的證明文件，例如：</p><ul><li>會議紀錄： 註明本次圖面修正是依據哪一次工地協調會的結論。</li><li>計算書：結構或機電的計算數據，證明圖面變更後的安全性。</li><li>建築師/業主公文：官方發出的變更令 (VO) 或指示函，確認變更來源。</li><li>現場照片：提供施工現況照片，解釋為何圖面需要配合現場微調。</li></ul></td></tr><tr><td><strong>2. 操作邏輯</strong></td><td><p>透過附件補充，可以減少審核者因不了解變更背景而產生的退件（駁回）率，縮短圖說從草稿轉為正式版的時間。</p><ul><li>整批關聯： 您在此處上傳的附件會關連至「這一整批」送審的草稿中。審核者進入審核介面後，可以同時開啟圖檔與附件進行比對。</li></ul></td></tr><tr><td><strong>3. 提醒</strong></td><td>附件是用來「輔助說明」的。若該文件本身就是一張需要被發布到現場的「施工圖」，則應透過前面提到的「建立圖說」流程上傳，而非僅僅作為附件。</td></tr></tbody></table>

<figure><img src="/files/B9SK0Kuv0go671KXKohL" alt=""><figcaption><p>圖五 - 附件上傳 &#x26; 送審</p></figcaption></figure>

**狀態變更：審核中 (Under Review)**

原先標示為「未送審」的檔案，狀態會統一更新為 「審核中」。

{% hint style="info" %}
權限鎖定： 為了確保審核過程中的資料一致性，處於<kbd><mark style="color:$primary;">**審核中**<mark style="color:$primary;"></kbd>的草稿將暫時無法再進行刪除。
{% endhint %}

<figure><img src="/files/OEYC4S8IuoK4dzdmVpwl" alt=""><figcaption><p>圖六 - 草稿狀態</p></figcaption></figure>

***

### 02｜設為正式版

圖說系統執行嚴格的權責管控機制：唯有經審核者判定為「通過」之草稿，方具備轉換為「正式版」之資格。

此機制為確保發布至現場施工的圖資，皆已落實專業核定程序，嚴禁未經審核之草稿直接投入實務使用。

**一、 選取目標圖說**

如圖五，於「圖說列表」中，針對欲執行發布作業的圖說項目，於該筆圖說之<kbd><mark style="color:purple;">**草稿**<mark style="color:purple;"></kbd>欄位執行點選動作。系統隨即開啟管理視窗，詳列該圖號下所有相關的草稿紀錄（包含審核通過、駁回或送審中之版次）。

<figure><img src="/files/JQDrC7Y8fxoTDVnxIFTB" alt=""><figcaption><p>圖七 - 開啟草稿列表</p></figcaption></figure>

**二、 版本確認與檢視**

在此視窗中，管理員可執行以下核對：

* 歷程查閱： 查看該圖號從上傳至今的所有草稿更迭紀錄，確保選取的版本正確。
* 狀態過濾： 確認目標草稿是否已標註為「審核通過」。系統僅允許通過核定之草稿執行正式發布作業，避免錯誤資訊流向現場。

<figure><img src="/files/UUcXB2tfCVGRO2ywaZSE" alt=""><figcaption><p>圖八 - 點選<kbd><strong>發布為正式版</strong></kbd></p></figcaption></figure>

完成畫面如下：

<figure><img src="/files/62vijbiedWyoQRkdCYmF" alt=""><figcaption><p>圖九 - 完成畫面</p></figcaption></figure>

***

#### 02 - 1｜圖說主檔

在確認草稿已發布為正式版本後，管理人員可進入該圖說的「主檔頁面」進行全方位檢視。此頁面整合了該圖號的所有核心資訊，是進行圖資追溯與管理最重要的介面。

進入主檔頁面後，系統將透過以下四大區塊呈現該圖資的全生命週期：

{% tabs %}
{% tab title="圖說基本資訊" %}
此處詳列圖說的原始定義，包含：

* 圖號與圖名： 確保圖資識別的唯一性。
* 專業分類： 如結構、建築、機電等歸類。
  {% endtab %}

{% tab title="全版本清單 (草稿 + 正式版)" %}
系統會以列表形式，完整收錄該圖號下產生的所有版本：

* 歷次草稿： 包含過去曾送審、被駁回或修改中的所有草稿紀錄。
* 歷史正式版： 若該圖說經過多次變更設計，舊版的正式圖說也會保留於清單中供隨時回溯。
* 狀態標籤： 每一筆紀錄旁皆會清楚標註其狀態，方便管理員區分哪些是過程文件，哪些是核定文件。
  {% endtab %}

{% tab title="當前正式版詳情" %}
此區塊會特別突出顯示目前生效中的圖說資訊：

* 最新版次： 顯示當前現場應採用的最新版本號。
* 快速查閱： 提供直接開啟當前正式版圖檔的捷徑，確保管理員能第一時間調閱正確圖資。
  {% endtab %}

{% tab title="檔案歷程" %}
請見下方說明
{% endtab %}
{% endtabs %}

{% hint style="info" %}

#### 異動人員與時間戳記

為了落實營建管理的嚴謹性，主檔頁面中的每一項資訊欄位與版本紀錄，均具備「透明化」的修改履歷：

1. 最後修改人： 系統會自動抓取並顯示最後一位執行儲存動作的操作者名稱。不論是修改了說明文字、調整了標籤，或是執行了版本發布，都能清楚辨識負責人員。
2. 最後修改時間： 精確紀錄最後一次存檔的確切時間。這在釐清「誰最後動過這張圖」或「資訊是否為最新更新」時，提供了無可爭議的數據支持。
   {% endhint %}

<figure><img src="/files/QDJIzi23qgM5Tw6sXZSm" alt=""><figcaption><p>圖十 - 圖說主檔</p></figcaption></figure>

***

#### 02 - 2｜檔案歷程

{% hint style="danger" %}
請務必注意： 「檔案歷程」功能僅會在該圖說具備「正式版」狀態後才開啟顯示。
{% endhint %}

在圖說尚未取得正式版本地位前（仍處於草稿階段或初次送審中），系統不會預先顯示歷程資訊。此設計係為了確保歷程紀錄的權威性，僅針對已定案、具備施工效力的圖資提供完整的追蹤鏈結。

一旦圖說發布為正式版，使用者進入詳細頁面即可查閱該圖號的「全紀錄」。每一筆動態皆會精確標註 「執行人員」 與 「確切時間（精確至分秒）」：

<table><thead><tr><th width="132.8792724609375">紀錄</th><th>說明</th></tr></thead><tbody><tr><td>草稿異動</td><td>紀錄草稿的初次上傳、檔案替換及編修過程。</td></tr><tr><td>簽核程序</td><td>紀錄由誰在何時發起送審、由哪位審核元受理。</td></tr><tr><td>審核結果</td><td>包含審核通過或駁回的判定，以及當時填寫的原始審核評語。</td></tr><tr><td>正式發佈</td><td>紀錄草稿正式轉為現場施工依據（正式版）的關鍵時間點。</td></tr><tr><td>後續更迭</td><td>包含後續的版次更新、廢止紀錄，乃至最終的『竣工圖』歸檔軌跡。</td></tr></tbody></table>

{% hint style="info" %}

#### 實務管理效益

透過檔案歷程，專案管理團隊能隨時釐清：

1. 責任歸屬：明確掌握誰在何時核准了該份圖說，作為法律與合約上的紀錄支撐。
2. 時程追蹤： 精確回溯某次設計變更從「提案」到「生效」所耗費的時間，優化行政效率。
3. 錯誤排查： 若現場發現施作版本有誤，可立即透過歷程確認是哪一個環節的核定出現偏差，避免責任推諉。
   {% endhint %}

<figure><img src="/files/hPpDX1sTaqJVh7259zYM" alt=""><figcaption><p>圖十一 - 檔案歷程</p></figcaption></figure>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.jobdone.cc/user_guide/cpm/bc/drawings/web/list/draft.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.