PRC-01 · Process
合作流程與報價方式
客製工具最怕做完不好用。所以流程的重點是「先確認，再開發」：確認功能範圍與報價後， 先驗證核心操作，再完成其餘功能。交付內容、原始碼提供方式、驗收標準與維護範圍， 會在報價或合約中列明。合作以遠端為主，全台灣都能配合。
PRC-02
五個階段
Stage 01
需求訪談
視訊了解目前的操作流程、CAD 版本與授權、每週重複的次數與耗時。
Output初步判斷：是否適合自動化
Stage 02
確認範圍與報價
確認技術做法，列出功能範圍、交付內容、驗收標準與時程，雙方確認後才開始。
Output功能範圍與報價單
Stage 03
核心操作驗證
確認報價後，先完成並驗證最關鍵的操作，讓實際使用的人確認方向，再完成其餘功能。
Output可驗證的核心功能
Stage 04
交付與驗收
在你們的環境安裝測試，依報價列明的驗收標準逐項確認。
Output報價中列明的交付項目
Stage 05
維護與擴充
維護範圍依報價或合約約定；CAD 改版或新增需求時，另外評估。
Output依約定的後續支援
PRC-03
報價方式：依確認的功能範圍
依雙方確認的功能範圍報價；若新增功能或調整需求，會先說明費用與時程影響，確認後再執行。以下是評估工時時會看的因素。
影響報價的因素
因素
看的是什麼
為什麼影響工時
功能範圍
看的是什麼要自動化幾個動作、流程有幾個分支與例外
為什麼影響工時例外越多，判斷邏輯越複雜
操作介面
看的是什麼一個指令直接執行，或需要對話框、預覽、設定檔
為什麼影響工時介面通常佔不少工時
外部串接
看的是什麼是否讀寫 Excel、資料庫、PDM 或 ERP
為什麼影響工時取決於對方系統開放的程度
工具形式
看的是什麼簡單的指令就能完成，或需要整合進選單、串接其他系統
為什麼影響工時整合範圍越大，開發與測試越久
版本與環境
看的是什麼需要相容的軟體版本數、使用人數與部署方式
為什麼影響工時每多一個版本就多一輪測試
既有程式
看的是什麼從零開發，或接手沒有文件的舊巨集
為什麼影響工時接手需要先花時間讀懂
常見的規模參考
輕量
Scale S
單一動作的巨集或 LISP：批次轉 PDF、屬性一次寫入、固定格式匯出 BOM。
中型
Scale M
含對話框與規則判斷的工具：自動出圖、圖面規範檢查、標準件庫。
大型
Scale L
跨系統整合或參數化產品：與 ERP／PDM 串接、輸入規格自動產生模型與圖面。
PRC-04
常見問題
同樣叫「自動出圖」，規則簡單與例外很多的工時可能差好幾倍，所以沒有固定價目表。了解操作流程後，我會列出功能範圍、交付內容與時程並提供報價，確認後才開始開發。
可以調整。報價依雙方確認的功能範圍計算；若新增功能或調整需求，我會先說明對費用與時程的影響，你確認後再執行。
一開始只要描述目前的操作流程即可，有截圖或錄影更好。評估需要時，再提供代表性的模型或圖面範例；涉及敏感資訊的檔案，可以先移除後再提供。
原始碼是否提供、以什麼方式提供，會在報價或合約中列明，確認後才開始開發。