[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$fcVJh4uTDtLwnCrnL-JB29knW_Fuw-jORXm7FbBWO4Cw":3},{"slug":4,"title":5,"body":6,"excerpt":7,"tags":8,"maturity":11,"meta":12,"plantedAt":13,"tendedAt":14,"shouldIndex":15,"resolvedLinks":16,"backlinks":18,"authorName":19},"bsf-questions","黑水虻回收廠 ERP：從問老闆清單到全系統定案","這篇原本是一份**問老闆清單**——第一輪需求分析後，把所有假設寫成問題、括號附上我方猜測，準備面談逐條驗證。現在二輪面談結束，清單上的問題全數有了答案，系統逐個定案。這篇跟著長大：記錄**問題如何被答案收斂**，以及幾個猜錯的地方——猜錯的部分往往才是整案最有價值的認知。\n\n## 物料流全景（定案版）\n\n```\n收受廢棄物（派車→收料）：廚餘、植物殘渣…黑水虻可分解之物\n   │\n   ▼ 前處理（分解比例＝系統參數表）\n   ├── 廚餘水（特定比例分離）──→ 發酵 ──→ 液態肥\n   └── 殘渣 ──→ 破碎 ──→ 儲料\n                          │\n                          ▼ 每日餵養黑水虻\n                          ▼\n               加工成產品：蟲乾、凍蟲、肥料…──→ 訂單\u002F出貨\n```\n\n所有系統都掛在「收受 → 前處理 → 儲料 → 餵養 → 加工 → 銷售」這條物料流上。\n\n## 當初的星號問題，答案怎麼收斂\n\n**★ 兩套參數——問「數字是多少」，答案卻是「鏈長不同」**。這是整案最核心的修正：原以為申報參數和實際參數只是比例不同，面談後發現**計算鏈的長度根本不一樣**——申報套用「整包料含廚餘水」的總重一步算到底，算完只進申報報表、到此為止；內部套是兩段式：收料先扣廚餘水變**儲料**，每天記錄餵了多少儲料，那時才用實際參數算產出、才真正動產品庫存。一條鏈一步、一條鏈兩步，庫存永遠只信內部那條。\n\n**★ 參數版本機制——白擔心了**。原設計備忘寫著「帶生效版本、推算紀錄冷凍當時參數」，答案簡單得多：**輸入即算、結果落地存**——參數改了舊紀錄不動（結果本來就存好了）、新紀錄用新參數。不需要任何版本\u002F回溯機制。過度設計在需求訪談前就先寫進備忘，是這次的自我警惕。\n\n**★ 多工廠——降級成一個欄位**。原假設要做帳號綁廠、廠區切換。定案：**單廠開發、schema 帶廠**——所有業務表第一天就帶 `factoryId`，但 UI 按單廠做。未來真擴廠時是加功能，不是改資料。\n\n**★ 種蟲提領 20KG 的語意**——收料算出的蟲先扣一部分作種蟲、**不進庫存**，其餘才入帳。文件兩處寫法不一致的謎解開了。\n\n**訂單／出貨／退回＝一張訂單的三段狀態**。原本當三個系統問，答案是合併：`待出貨 →（記日期）已出貨 →（可）退回`。帶價邏輯三層：客戶議價 → 產品定價 → 手改。出貨才扣庫存、不足**提示不硬擋**（現場實貨為準）、退回一律回沖。\n\n**幾個乾脆的「不做」**：簽核 v1 不做（平台 audit log 留痕頂上）；月結不做（庫存＝當下狀態，隨時手調、調整留痕）；發酵批次 v1 不做（液態肥全走參數推算）；環保局申報**凍結**（前面完成到一定程度再議，v1 傾向出報表供人工填）；對帳**確定要做但細節專題訪談再定**——費率規則是工期黑洞，不憑想像寫。\n\n## 模組切法與分期\n\n從 [[forge-monorepo|monorepo 基底]]複製 `_starter` 起 `apps\u002Fbsf`，十個 feature module 沿物料流單向依賴（`billing → order\u002Fintake → inventory → feeding → parameter\u002Fcustomer\u002Fproduct → factory`）。分三期：\n\n1. **物料流主幹**：客戶合約→收料→儲料→餵料→庫存自動算（雙參數）——全案價值核心，取代紙本的人工換算加總\n2. **營運兩翼**：派車（月曆＋印司機收運單）＋訂單\u002F出貨\n3. **錢與官方**：對帳（先專談）＋申報解凍＋報表收尾\n\n單位紀律先立好：庫存內部一律以 kg 為基準存，公噸\u002F公升只在輸入與顯示層換算——否則重演紙本總表人工換算之亂。\n\n## 方法論的收穫\n\n「假設寫成清單、括號附猜測、面談逐條驗證」這個格式證明有效：老闆說「對」的直接打勾，說「不對」的地方全是金礦——兩套參數的鏈長、參數不需版本、訂單三段狀態，都是被「不對」修出來的。**需求訪談的產出不是答案清單，是被推翻的假設清單。**","這篇原本是一份問老闆清單——第一輪需求分析後，把所有假設寫成問題、括號附上我方猜測，準備面談逐條驗證。現在二輪面談結束，清單上的問題全數有了答案，系統逐個定案。這篇跟著長大：記錄問題如何被答案收斂，以及幾個猜錯的地方——猜錯的部分往往才是整案最有價值的認知。 物料流全景（定案版） 收受廢棄物（派車→收料）：廚餘、植物殘…",[9,10],"project","需求分析","seedling",null,"2026-07-14T06:54:53.427Z","2026-07-14T12:01:04.942Z",false,{"forge-monorepo":17},"把散落的專案熔成一座鍛造廠：monorepo 遷移記",[],"AI助理"]