> For the complete documentation index, see [llms.txt](https://quteng.gitbook.io/ke-hu-wen-da-ji/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://quteng.gitbook.io/ke-hu-wen-da-ji/yan-wu-gong-si/pi-ci-xin-zeng-yan-wu-dan-cao-gao-yan-wu-gong-si-ban-ben.md).
# 批次新增驗屋單草稿（驗屋公司版本）
系統中的驗屋單據是以「組別（建案）」進行分類。若要建立新的專案並批次新增單據草稿，請透過「新增整棟」功能來完成基礎建置。請依循系統引導的五個步驟完成設定。
### **步驟一：創建新建案**
* 登入系統後台，在首頁（公司總覽）右上方點擊 **新增整棟**。\
輸入「建案名稱」，並選擇該建案為「單棟」或「多棟」建築。
### **步驟二：棟別規劃 (若為多棟)**
* 若步驟一選擇「多棟」，系統會請您進行棟別設定：\
依據實際規劃，輸入「棟別數量」並為各棟別命名（例如：A 、B 、C ）。
### **步驟三：樓層與戶數規劃**
* **依序對各棟別進行設定**\
輸入「建案樓層數」，勾選並填入「跳過樓層」（如無 4 樓，請填入 4）。\
接著選擇「每層戶數」，系統會自動產生該樓層的戶別編號（如 A1, A2, A3），可自行編輯戶別編號。
### **步驟四：房型與格局設定**
在此步驟中，您需要建立建案所有的房型範本，並將這些房型與空間套用至對應的戶別。
1. **新增房型 / 格局範本**\
在畫面左側，點擊綠色的 **+ 新增房型 / 格局範本** 按鈕，建立該建案會使用到的所有房型名稱（如：三房兩廳、兩房一廳）。
2. **進行空間設定**\
新增完房型格局後，列表上的房型旁邊會出現 **空間設定** 按鈕（齒輪圖示）。
* 點擊打開彈跳視窗，在此勾選該房型範本需要套用的詳細空間（例如：全室內、客廳、客衛浴等）。
* 點擊右下角 **儲存**，系統將自動更新該房型範本的空間清單。
3. **確認與前往下一步**
在右側樓層平面圖中，將戶別打勾選取（支援整層全選、單層全選、新增額外樓層），並為選取的戶別指定對應的「房型 / 格局」。
\
**注意**： 必須確認所有戶別皆已完成房型設定，才能進入下一步。若為多棟建案，請依序完成各棟別的設定。
### **步驟五：加入參與員工**
* 畫面將列出系統內各部門的員工名單。請勾選需要參與此建案的人員（支援部門全選）。被勾選的員工才能在系統中查看並操作該組別（建案）資料。
### **完成設定**
* 進入「恭喜完成初始設定」頁面。\
您可在此點擊「上傳建案封面照片」，完成後點擊右下角「回到儀錶板」，組別（建案）與驗屋單草稿正式建立完成並可接續在執行驗屋作業前，針對產出的單據進行詳細資料的補充與編輯。
---
# 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 by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://quteng.gitbook.io/ke-hu-wen-da-ji/yan-wu-gong-si/pi-ci-xin-zeng-yan-wu-dan-cao-gao-yan-wu-gong-si-ban-ben.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
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.
