LIN CHIACHENG
  1. 作品
  2. NEXUS

01 / 07INDEPENDENT BUSINESS SYSTEM PROJECT

NEXUS

把顧客、報價、案件與請款，接成一條工作流程。

NEXUS 董事長工作台，彙整行程、營運指標與進行中的案件。
概念設計 — 董事長視角。

從以前工作中的不便出發，主動提出改善，用學到的技術與 AI，逐步做成可操作的業務系統。目前仍在開發中。

角色
產品 / 開發
技術堆疊
React · Spring Boot · PostgreSQL · Docker
狀態
IN DEVELOPMENT · 2026

GitHub（私人）

01

從熟悉的工作，開始學著做產品。

起點脈絡

過去的工作流程分散在紙本、Excel 與顧客資料之間，資訊需要多次交叉確認，也讓案件判斷難以集中。 來日本學習開發後，我重新聯絡過去工作上的夥伴，從實際業務流程出發，提出將顧客、報價、案件與請款整理到同一套系統的構想。經過幾次討論，NEXUS 由此開始；目前仍在開發與驗證，希望把每天需要反覆確認的工作，轉成更清楚、可持續使用的流程。

構想的核心

不是增加功能，而是把工作流程本身重新連成一體。

NEXUS / 01
  • 顧客
  • 報價
  • 案件
  • 請款・支付

NEXUS單一營運平台

重新連接業務的概念圖

構想的四個階段

  1. 01EXPERIENCE

    經驗

  2. 02OBSERVE

    觀察

  3. 03REFRAME

    重新定義

  4. 04BUILD

    建構

整理原則

  1. 01

    整理

    找出散落的資訊。

  2. 02

    連接

    串起原本分開的流程。

  3. 03

    簡化

    減少不必要的操作。

02

先把工作接起來，再決定功能。

BEFORE

  • 顧客名簿Excel
  • 報價單Excel / Word
  • 案件管理試算表
  • 請款處理獨立系統
NEXUS連成一體。

OUTCOME

  1. 01

    先建立主要流程

    需求持續變動，因此先完成主要流程，其餘逐步加入。

  2. 02

    不讓操作變複雜

    功能可以很多，但操作不要變複雜。

  3. 03

    最後由自己判斷

    為了不讓系統只剩一個人的觀點而使用 AI，最後仍由自己判斷。

同一件工作，為什麼要到不同地方找資料？先整理顧客、報價、案件與請款之間的關係，再決定畫面要怎麼做。

顧客資訊、報價、案件、請款分散在不同地方時，尋找所需資訊的時間增加，判斷也跟著變慢。

優先的不是功能多寡，而是能毫不猶豫使用的流程。

章節結論

問題的核心不是功能不足，而是業務流程被分斷。

NEXUS / 02 · NOTE

03

實際可使用的業務形態。

將構想與判斷，落實為實際可操作的畫面與流程。

從顧客資料到案件進度，把日常需要確認的資訊放在同一個地方。

NEXUS 以顧客的詢問為起點，在同一個營運平台上處理報價、案件與請款。

工作台 — 每日工作的入口。
工作台 — 每日工作的入口。

主要模組

  1. 01

    CUSTOMER顧客管理

    將顧客與相關記錄整合在一起。

  2. 02

    QUOTATION報價

    在同一流程中處理從詢問到報價。

  3. 03

    PROJECT案件管理

    報價之後仍延續案件記錄。

  4. 04

    OPERATIONS請款・支付・業務管理

    在同一基礎上處理請款、支付與管理。

可操作的畫面

這些畫面來自報價測試版走向整合版的階段；重寫版仍是另一個開發階段。

案件管理 — 回看案件與狀態。
案件管理 — 回看案件與狀態。
報價單 AI 開項 — 建立工項的輸入畫面。
報價單 AI 開項 — 建立工項的輸入畫面。

官網重製

首頁、服務與施工案例，作為業務系統以外的網站重製呈現。

官網重製 — 首頁。
官網重製 — 首頁。
官網重製 — 服務。
官網重製 — 服務。
官網重製 — 施工案例一覧。
官網重製 — 施工案例一覧。

重寫版的早期記錄

這張提供的畫面呈現聯絡人基礎；記錄時 PR 尚未合併，不表示完整業務系統已交付。

聯絡人基礎 — 提供的早期畫面。
聯絡人基礎 — 提供的早期畫面。

概念設計

探索管理者與工程人員視角的概念畫面，與已實作功能及實際營運數據分開呈現。

概念設計 — 管理者儀表板。
概念設計 — 管理者儀表板。
概念設計 — 工程人員工作台。
概念設計 — 工程人員工作台。

業務生命週期

  1. 01

    INQUIRY

    詢問與受理

  2. 02

    QUOTE

    報價

  3. 03

    CONTRACT

    合約與顧客

  4. 04

    DELIVERY

    交付與案件

  5. 05

    BILLING

    請款與支付

章節結論

構想與判斷，唯有成為可實際操作的畫面與流程，才能被驗證。

NEXUS / 03 · NOTE

04

一邊學習，一邊和 AI 把產品做出來。

我還在累積開發經驗，所以先把工作拆小，讓 AI 協助整理、實作與交叉檢查。遇到不懂或不確定的地方，就回到程式、測試與實際畫面確認，再決定下一步。

使用 AI。

但不把判斷交出去。

AI 開發流程

  1. 01

    釐清需求

    先把需求與問題說清楚。

  2. 02

    AI 協作

    整理・比較・風險・選項。

  3. 03

    自己做判斷

    判斷・取捨・驗證由自己負責。

  4. 04

    小步實作

    小步實作，以可運作的單位累積。

  5. 05

    實際驗證

    以測試與審查確認。

依工作，選擇合適的工具。

01

整理想法與需求

整理需求、拆解問題、比較方案，再討論下一步方向。

工作環境
ChatGPT
使用模型
GPT-5.6 · GPT-6
02

小步實作與修正

依工作選擇環境與模型，協助介面實作、除錯、修改與重構。

工作環境
Codex · Cursor · OpenCode · OMO
使用模型
Composer 2.5 · GPT-5.6 · GPT-6 · DeepSeek V4.1 · Muse 1.3
03

交叉檢查實際畫面

檢視截圖、比較設計與實作，從不同模型的觀點找出畫面落差。

使用模型
Gemini 3.8 Flash · Grok 4.7 · GPT-6 Astra

是否採用，自己確認後再決定。

比較 AI 提案與不同模型的結果，自己決定採用或拒絕。查看程式與實際操作，依可核對的內容修改；必要時再請其他模型交叉審查。

  • Build / Typecheck
  • Tests
  • Browser / E2E / Smoke
  • Screenshot / Visual QA

這裡整理實際使用的工具。更詳細的分工與開發方式，收錄在另一篇 AI Workflow。

07 / AI 開發工作流程 →

05

讓畫面、處理與資料，各自清楚。

用學到的 React、Spring Boot 和 PostgreSQL，把畫面操作、業務處理與資料保存接起來。分開職責，也讓我能逐步理解與檢查每一部分。

核心層

概念上的職責
橫跨各層的考量AUTH / ROLE認證・權限
  1. 01

    畫面操作

    負責使用者接觸到的畫面操作。

    前端 · React / TypeScript

  2. 02

    業務處理

    負責依業務流程進行的處理。

    後端 API · Spring Boot

  3. 03

    資料保存

    負責保存所處理的資料。

    資料庫 · PostgreSQL

橫跨各層的考量DOCKER / VM開發・部署環境

已驗證的支援技術

  • Docker

    以容器統一執行環境，讓系統在同一前提下運作。

  • Git

    將原始碼與變更歷程統一管理。

  • Authentication

    識別使用者。

  • Authorization

    依角色區分操作範圍。

  • Validation

    確認處理的值是否正確。

  • Audit Log

    留下操作記錄。

章節結論

分層逐一確認，並在整體上取得一致。結構，就是決定這個順序。

NEXUS / 05 · NOTE

06

已經開始成形，還在持續調整。

現在仍在開發中，一邊與使用者確認，一邊調整功能和操作方式。下一步是繼續驗證主要流程，看看哪些想法真的有幫助，哪些還需要改。

  1. IDEA
  2. PROTOTYPE
  3. CORE SYSTEM
  4. NOW
  5. NEXT

  1. 01

    WHAT EXISTS NOW

    橫跨顧客、報價、案件的基本流程

  2. 02

    WHAT I LEARNED

    與其增加功能，不如設計判斷與資訊的流動

  3. 03

    WHAT COMES NEXT

    以實際運作為前提的驗證、改善與自動化

此刻的話

把思考過的東西，變成能用的東西。

NEXUS / 06
NEXUS — LIN CHIACHENG