PAUL HUANG · DEV MANAGER & BUILDER

我幫產品與工程團隊，
把模糊需求做成
能驗證、能上線的產品。

我帶團隊交付，也親自從 0 到 1 做產品。持續學新技術、做出第一版， 再用實際成果檢驗方向。

談談你的交付卡點 ↗ 看我正在做的產品 →
EMAIL[email protected] WEBpaulfun.net GITgithub.com/pin0513 BLOGdotblogs.com.tw/pin0513
15+
年軟體經驗
10+
產品上線
6:4
管理 : 技術
110+
週連續跑步
🏸
Badminton

最新文章

載入中…
S1 · ABOUT ME

關於我

Paul Huang
Paul Huang 黃一平
Software Dev Manager · Architect · Builder

目前擔任開發部主管，帶領工程團隊處理產品開發與系統整合。 下班後仍持續親手做產品：從問題、第一版到實際使用， 把新學到的技術變成可以驗證的成果。

「人生是唯一的 Main Project —
每段經歷、每間公司，都是淬煉你的 Side Project。
Life is your /master(main) Project! 」
// POSITIONING
管理 : 技術 = 6 : 4
帶團隊處理方向與優先順序，也持續親手寫 code、做架構、從 0 到 1 做產品。 實作讓我的管理判斷有現場證據。
💡 AI 讓實作更快；問題定義、品質標準與驗證方式，仍需要人負責。

教育背景

2007–2009
台灣科技大學
碩士，資訊管理
2003–2007
雲林科技大學
學士，資訊管理系
2000–2003
花蓮高商
資料處理科
S2 · CAREER

工作經歷與專案

技術細節在程式碼裡，這裡只呈現職涯路徑與關鍵產出。

MAYO Human Capital
2023/08 — Present
開發部主管

以 BPM 產品經驗，從 0 到 1 發展高度彈性的 BPM 產品平台。 2024/04 產品正式上線，2025 年擴展為 10 人團隊，提供 MAYO HR BPM Solutions。

專案歷程：

2023/08–
2024/06
表單產品開發 — 自定義表單上線
主任工程師兼表單/流程模組開發、設計、架構師。從 0 到 1 建立產品，導入 TDD 控制品質。
2024/06–
2025/12
表單整合平台（深度串接）— 標準表單上線
升任營運 + 開發團隊主管，負責產品整合模組與 BPM 平行簽核。團隊擴展至 10 人。
2025/08–
2025/12
表單營運與開發者工具
導入 AI Vibe Coding，提升開發效率與工具鏈建設。
2026/01–
2026/06
報表平台開發與上線
AI 原生開發體驗，以 Claude Code 協作加速產品交付。
2026/07–
2026/09
AI 團隊編排與 bot fleet
把個人 harness 放大成團隊 harness — bot fleet 常駐系統邊界，開發主軸從「我用 AI」轉為「團隊用 AI」。
2026/10–
now
管理專案價值化 評估中
主軸從自動化轉向價值交付 — 以人的管理視野為中心：傳統專業職能的職位設計正在弱化，連基層管理職位也一起弱化。在這個前提下重新設計軟體與開發的價值交付循環。
// AI-ERA LEVERAGE — 三個支柱
多年累積的 MIS × 產品 × 技術深度 三重經驗, 讓我在 AI 時代能快速把工具轉化為實際生產力與團隊紅利。
01 · MIS 維運經驗
Docker 容器化、VM 管理(SSH / Ubuntu)、Azure Pipeline 自動化 — 從機房到雲端的完整掌握度,讓開發環境到部署流程都能被 AI 串起來。
02 · 產品與管理經驗
從需求到上線,更在乎品質、全局性與團隊管理 — 不只寫 code,更懂得怎麼讓 10 人團隊用 AI 放大輸出。
03 · 技術深度深造
底層深度:TDD / C# / EF Core 長期深造 · AI 時代:對 Claude Code 的理解涵蓋 Vibe Coding、Agentic Coding、Context + Harness Engineering、Agent Bot Design。
Claude Code Docker Azure Pipeline .NET Core C# EF Core React Ubuntu / SSH Git E2E Test TDD SQL Server
商業思維學院（脈絡管理顧問）
2021/04 — 2023/07
資深研發工程師

搭配 Scrum Team，負責 LMS（學習系統）後端開發與相關模組設計， 並主要負責 Azure 自動化建立與測試，後期接下所有後端系統技術的設計開發與維運。

▸ 展開細節
  • Backend 軟體架構設計與開發（.NET Core + WebApi + Azure Functions + SQL Azure + EF）
  • Backend 單元測試與整合測試（核心專案 500+ 測試案例）
  • 管理後台全端開發（Vue.js + WebApi）
  • 第三方服務串接（Slack, OpenAI, LineBot, SSO, 藍新金流, Iterable, Metabase）
  • Official Site 維運（GCP + Linux Ubuntu + WordPress + MySQL）
  • Azure Pipeline 建置與維運（Azure DevOps）
.NET Core Azure Vue SQL Azure Redis Service Bus
英福達科技 / 邁梭科技
2017/09 — 2021/03
研發部總監

邁梭時期接觸 Open Source 技術（Python, Docker）， 英福達時期主導 OD6 公文系統 Flash→.NET 前後端分離重構， 後期擔任研發部總監，負責 OD6 上線驗收、壓力測試、多機關客戶駐點。

▸ 展開細節

邁梭科技（2017/09–2018/03）

  • Python 開發（Tornado + SQLAlchemy），串接 MariaDB, MongoDB, ElasticSearch, Cassandra
  • Docker 相關開發技巧、自動化部署 CLI 安裝包
  • 成立 paulfun.net Blog 記錄技術學習歷程

英福達科技 — 前期（2018/04–2019/06）

  • OD6 底層模組開發（Flash 第5代→.NET 第6代），前後端分離架構
  • 核心模組：RuleEngine、Portal、文件模組、流程模組、報表模組
  • 整合模組：公文流程模組、ESB 模組、客製模組開發

英福達科技 — 後期 研發部總監（2019/06–2021/03）

  • 負責 OD6 上線/驗收流程，外部系統整合、維運開發
  • 壓力測試（JMeter）與資安報告執行與問題排除
  • 參與專案：THSR、YML、TCBBILL、EPA、CPC、NCCU、OOP 等
  • 團隊人數：4–5 RD
.NET Python Docker ElasticSearch JMeter
TutorABC（麥奇數位）
2015/04 — 2017/04
主任研發工程師

線上教育產業。從資深研發工程師升任主任研發工程師， 負責內部後端系統統一、API 重構、Relay/DCGS 維運與開發。 2015 年度獲得最佳執行力人員獎。

▸ 展開細節

第一階段 資深研發工程師（2015/04–2016/01）

  • TutorABC 業務部門：3R 專案、業務招募自動化履歷匯入、JR 課程產品上線
  • 自動註冊整合、LinePay 金流專案
  • 專案開發 Team：API 系統重構與設計、新型課程類型後台 API、整合進教室流程

第二階段 主任研發工程師（2016/02–2017/04）

  • 主導內部後端系統統一：登入、進教室邏輯、合約堂數、作業/訂課模組
  • 底層機制強化：API 監控（Slack）、Log 集中（Grafana + Kibana + ES）、維運工具
  • 同時維運 2 個舊 API 與 1 個新 API 系統
  • Relay、DCGS 維運與開發（2016/07–2017/02）
  • API 週使用量達近 2000 萬次
ASP.NET MVC WebApi MS SQL jQuery Grafana ELK
鼎新電腦
2009/09 — 2015/03
副理

企業 ERP 產業。從程式設計師一路升至副理，歷經軟體代工、雲技術中心、 中小企業雲智慧商圈（Microsoft Azure）、A1 雲端帳簿產品開發、移動技術部設計器組。

▸ 展開細節
  • 2009/09–2009/12：軟體代工中心 程式設計師（Delphi）
  • 2010/01–2011/12：集團研發本部 雲技術中心 研發工程師（.NET C#, MS SQL）
  • 2012/01–2012/12：中小企業雲智慧商圈事業部 技術組 副理（Microsoft Azure, M-Cloud Platform）
  • 2013/01–2015/01：公共平台部 應用開發組 副理 — A1 雲端帳簿 Phone 版/Web 版開發（財務、進銷存模組上線）
  • 2014/12–2015/03：移動技術部 設計器組 副理（團隊：1 主管、1PM+SD、9PR）
.NET SQL Server Microsoft Azure Delphi
S3 · AI MINDSET

AI 時代的職涯思維

不只是用 AI 寫 code — 重新定義「人 × 工具 × 團隊」的 leverage。

從 2009 Delphi 到 2026 Claude Code，我經歷過至少 5 次工具大躍進。 AI 是這 5 次裡第一次「使用者自己也在被改變」的革命 — 過去工具是「我用 X 取代 Y」，這次是「我跟 AI 一起變成新的開發者」。 AI 誕生也才多久，我對它的思考也還在演化 — 從 loop、到 harness、到 systematic， 再到今天的模糊性與判定（ambiguity → judgment）。持續找尋它的潛力與上限，是我目前最大的好奇心所在。
S3 · AI 進行式
// FOUNDATION — 這條 arc 底下的那條線
下面那五站看起來是「我怎麼用 AI」，但真正在推動它的是另一條更早的線： 對人的理解 —— 也就是管理 —— 是我理解 AI 的上游。 管理不是給我一套技巧，是給我一個長期觀察人的現場： 人怎麼接收指令、怎麼誤解、怎麼迴避回饋、怎麼在組織裡被結構卡住。 這些看懂之後，再看 AI 與「人用 AI」，很多事情就不意外了。
01 · 失敗模式同源
AI 學的是人類語料，所以它的毛病是人的毛病放大版。懂人在哪裡會含糊、會過度自信、會給一個聽起來合理的答案，就預測得到 AI 會在哪裡出錯。
02 · 同一把尺
我怎麼判斷一個資淺工程師的交付可不可信，就怎麼判斷 AI 的輸出可不可信。帶人練出來的驗收直覺，直接轉移。
03 · 人帶著習性用 AI
不會接受人類回饋的人，也不會接受 AI 的回饋；不會拆問題的人，給他 AI 一樣拆不開。工具換了，習性沒換 —— 管理讓我看得到這些習性。
04 · 組織決定上限
同一支 Claude Code 放進不同組織，產出差很多。決定上限的不是模型，是溝通結構 —— 這是 Conway's Law 在 AI 時代的版本。
≈ The Media Equation（Reeves & Nass 1996）· Conway’s Law（1968）· Socio-technical Systems（Tavistock 1951）
// THINKING ARC — 我怎麼想「用 AI」這件事的演化
01 · LOOP ENGINEERING
讓 AI 跑迴圈把事做完
≈ Agentic Loops · ReAct · Self-Refine
最早的用法是「給 prompt、丟 context、讓它 loop 到答案」。快，但天花板是我的 prompt 想像力 — AI 只會做我想到的事。
02 · HARNESS ENGINEERING
幫 AI 搭鷹架、切工具、上護欄
≈ Agent Harness · Context Engineering · Situational Leadership
後來在做的是「幫 AI 搭鷹架」— 切工具、給邊界、設檢查點。這時候「AI 能做什麼」不再由模型決定，而是由我搭的 harness 決定。Claude Code 對我來說本身就是一個 harness。
+ HUMAN HARNESS
帶人也是 harness：guides 是前饋、sensors 是回饋。差別在 AI 的 harness 能寫進 CLAUDE.md 讓 linter 機械式執行，人不行 — 人那邊還多一軸心理安全感。
03 · SYSTEMATIC ENGINEERING
識別生活裡的系統，用 AI 補平流程斷點
≈ Compound AI Systems · Systems Thinking
團隊回顧是系統、PR flow 是系統、oncall 是系統、我每天讀什麼寫什麼也是系統。看見系統，才能用 AI 補平那些長年斷掉的節點。
04 · AMBIGUITY ENGINEERING
模糊是人性，而 AI 不會卡住
≈ Common Ground · Conversational Repair · Ubiquitous Language
過去「人讀了覺得怪、跑去問一句」看似沒產值的摩擦，其實是整條鏈唯一的除錯機制。AI 接手的正是那一步 — 它不會卡住，只會給你一個合理答案。而合理跟正確是兩件事。
05 · JUDGMENT ENGINEERING ← 現在階段
產生可以外包，判定不行
≈ Test Oracle Problem · Falsifiability · Verification & Validation
斷層線在產生跟判定之間，不在思考跟執行之間。思考跟執行我都能丟給 AI，但「什麼算對」要我定義、「這次對不對」要我確認 — 判定這格外包出去，等於沒做。多代理沒有解決這個問題，它把這個問題乘上 N。
systematic 階段長出兩種手感：bot engineering（讓 AI 常駐在系統邊界成為第二意識）與 kanban engineering（把知識與流程物件化、可流動、可回顧）— 具體長成了下方的 // TEAM AI STACK。 而系統真的接起來之後才看見：卡住的從來不是技術，是語意，那是 04 在處理的。 語意對齊之後只剩一個問題：誰說了算。可被推翻性是思考的入場券，想得對是後面的事 — 05 就是在蓋那道入場閘門。
// FIVE PRINCIPLES — 我對 AI 時代的五條主張
01 · AI 是工具 — 但這次工具不一樣
我看過 .NET 取代 Delphi、雲端取代機房、Docker 取代手工部署。 這幾次革命的本質都是「換工具」 — 我用新工具做一樣的事。 但 AI 不只是工具，它會把我變成不一樣的開發者 — 決策節奏、debug 思路、架構表達方式都被它重塑。 這是我堅持每天親手用 Claude Code 寫產品的原因 — 不下場用，就會失去判斷 AI 上限的能力。
02 · 人類決定上限 — 那個「使用 AI 的人」的上限
模型能力的上限是 OpenAI / Anthropic 決定的。 但「AI 在某個人手上能做出什麼」這個上限， 完全由那個人的好奇心、價值判斷、與品質意識決定。 同樣一支 Claude Code，有人拿來糊弄交差， 有人拿來把報表平台壓進 3 個月 v1 上線。 差別不在工具，在人。
03 · 管理 × 技術，不是二選一
人家問我「管理大於技術嗎？」我說： 「會管理的技術人 >>> 純技術人 + 純管理者各自做事」。 管理是 leverage，技術是判斷力的根 — AI 時代，主管脫離技術會失去判斷團隊產出是「真有效率」還是「假繁榮」的能力。 我的管理:技術 = 6:4 不是平衡，是堅持不脫離手感。 而真正驅動職涯前進的，是好奇心 + 價值判斷： 好奇心讓你追新東西，價值判斷讓你知道哪些新東西值得追。缺一個都不行。
04 · 品質意識 >>> 執行、練習、學習
「先有再無」不是 typo — 是「敢做、敢砍、敢重做」的迭代心態。 執行才知道是不是真的會，練習才能讓品質意識長到骨子裡， 學習才能在下一輪做得更好。 連同價值都能追根究底，那很多事情都會迎刃而解。 AI 時代，砍掉重練的成本變得極低 — 但有沒有「敢砍」的判斷力，才是真正的分水嶺。
05 · AI × 團隊 — 從個人 leverage 到團隊 leverage
2026 上半年帶 10 人團隊完成報表產品極限開發 — Q1 第一階段 3/31 v1 上線，Q2 第二階段 5/29 phase 2 上線。 同時把 AI 初步成功應用在多維度敏捷團隊管理的四個面向：
Retro
回顧自動化彙整
TeamMember Reviews
個人成長對焦
PR Flow
Code review 加速
Oncall Survey & Solve
值班案件智能診斷
目前持續好奇與嘗試的方向：新舊（Legacy）SaaS Software Issues 的處理 — 找尋 AI 在「歷史包袱」這個維度上的真實潛力與上限。AI 誕生才多久，路還很長。
// TEAM AI STACK — Bot Fleet + 團隊看板編排
近期在 10 人開發團隊實驗 systematic 思維的具體實作 — 信念是 「整合系統，不是寫系統」：Jira 已經是 kanban、 Azure DevOps 已經是 PR、Grafana 已經是 observability， 真理源留在原地，只加一層薄薄的、會自我進化的 AI 編排。
// BOT FLEET · 10 active（+ 少數 archived · 依需求復活）
Ops 系 · pm / qa / sre — 進度、品質、SLO
反思系 · team-coach / supervisor — 敏捷教練 + 進化引擎
Review 系 · 嚴謹派 + 挑戰派 PR 二審
QnA 系 · 問卦所（用實證回答團隊疑問）
每隻 bot 一個目錄：CLAUDE.md 人格 + profile.yaml。 新 bot 加入 = 複製結構 + 寫人格。bot 一律走 service principal，不冒用人類 token。
// 內部看板 · 每天真的會看的那幾張
Daily 主持台 · AI 分析報表 · Bot 艦隊看板 · 卡單追查台 · AI 使用統計 · 團隊部落格 · 問卦所 · aikanban（poc）· QA 工作台（poc）
全部 self-host 在同一台 VM。晨會照著 Daily 主持台 8 段 rundown 走 — rundown 是設定檔，改順序刷新即生效、免重建 image。
// 讓整合誠實的六條不變量（節選）
• 真理源留在外部 — 不搬資料、不造第二份 kanban（drift 不會報錯，只會讓兩邊各自都覺得自己是對的）
• 能 deterministic 就別用 LLM — 撈取/產圖走純 script，LLM 只用在判斷與提問；省 token、可重現、不飄
• 硬閘門 · machine/human boundary — bot 可以自由讀、觀察、在 Discord 講話；動作一旦「對外」或「不可逆」，一律停在人類批准閘門前
• 去識別化 + 身分軌 — 統計去識別化；bot 一律走 service principal
// 現階段最大的功課 · 誠實揭露
數據都有了，但 insight 的萃取還在調整 — 從資料到「值得寫進晨會的一句話」中間那層，目前還在 iterate。 規則寫死終究會 drift，next step 是讓 supervisor bot 在 weekly retro 提規則改進 proposal，讓系統自我進化。 這是 POC 的痛，也是 systematic engineering 真正要練的部分。
集中化本身就是 leverage — 團隊的 tacit knowledge 有了 self-hosted 的家， AI 才有真正的長期記憶。 工具會過時，整合的判斷不會。 // 完整心得寫在 paulfun.net · 整合系統，不是寫系統 · Bot Framework 半年心得。
// 模糊性工程 — 系統接起來之後，才看見真正的瓶頸
上面那個 insight 痛點，追下去發現卡住的不是技術，是語意。 一句「同一位主管，不要叫他簽兩次」，會議室裡沒有人追問 — 因為每個人都覺得自己懂了，而每個人懂的都不一樣。 程式沒寫錯、測試沒漏、規格照原話寫，一個月後整批還原， 回頭查，找不到犯錯的人。
// 核心命題 · 模糊被吸收的位置變了
過去「人讀了覺得怪、跑去問一句」那個看似沒有產值的摩擦， 是整條鏈上唯一會卡住的地方 — 它是除錯機制，不是效率損耗。 而 AI 接手的那一步，剛好就是過去吸收模糊的那一步。 AI 不會卡住 — 它會給你一個合理的答案，而合理跟正確是兩件事。
≈ Grounding in Communication（Clark 1991）· Conversational Repair（Schegloff 1977）· Ubiquitous Language（DDD）
這條線讓我開始認真讀心理學與溝通理論 — 不是為了管理技巧。 管理給我的是觀察人的現場，心理學給我的是解釋它的語言： 「模糊」是人類溝通的預設值，不是缺陷。 要設計 AI 工作流程，得先理解人是怎麼傳遞理解的。
// 四個降低模糊的機制
01 · 面板
讓「現在怎麼樣」沒有解釋空間
≈ Information Radiator
每天早上看的是同一張圖、同一個數字。狀態不再靠各自解讀 — 大家對的不是印象，是同一個事實。
02 · 版本
一個編號，再多縫一針回簽
≈ Requirements Traceability · Definition of Done
每條意圖一個編號，工程師標、測試引用、交付掃孤兒。但編號只驗「做完對不對得回去」， 不驗「一開始有沒有翻錯」 — 所以要多一道回簽：提出的那一端回一句 「這條等於我要的」。一個名字、一個日期，不用開會。
03 · AI 溝通學
output definition — 把只有一半的協議補完
≈ Design by Contract（多數人只寫了 precondition）
大家都在調 prompt 跟 CLAUDE.md — 那些都在設定「我怎麼對 AI 說話」。 「AI 怎麼對我說話」那一半，多數人從沒設定過。 密度、順序、詞彙、繁簡與排版，都該被明確定義。
04 · 價值共識
AI 不是只有成本，output 也要被設計
≈ Outcomes over Outputs · Value Stream
DORA 和 token 用量說服不了經營層 — 因為那些量的是「把已定的決定寫出來」那一段， 而價值是「結果」減掉「處境」。談 AI 的價值，得把軟體的 output 長什麼樣一起設計進去，不是只算省了多少工時。
// 模糊是一筆會計入帳的成本
• 溝通成本 — 同一件事被問三次，每次答案略有不同。開會的作用從決定，退化成確認上次講了什麼
• 交付成本 — 品質沒問題，做的是不該做的，只能整批退回。最貴，且事後才出現
• 阻礙成本 — 沒有人拒絕，也沒有人決定，於是停在原地。最隱形，帳上完全看不到
三者的共同點：都不會出現在任何報表上。 沒有一個欄位叫「這個月因為需求不明確損失了多少」。
// 完整論述：模糊是人類溝通的天性，而 AI 不會卡住 · 你只設定了輸入，沒設定輸出
💡
一起來探索這個未知的世界。
MAYO 提供至少 $100 USD / 月 Claude Max Teams 額度， 歡迎對 AI × 敏捷團隊管理有興趣的工程師、PM、TL 一起加入。 // 可從 paulfun.net 找到我，或從 LinkedIn / Email 直接打招呼。
S4 · BUILDER LOG

現在親手做的兩個產品

Side project 是我的練習場：遇到新問題就學、做出第一版，再用實際畫面和測試結果驗證方向。

發現問題→快速學習→做出第一版→驗證與調整
CoachApp 羽球範本庫與篩選畫面
範本庫
CoachApp 比賽影片與姿態骨架並排學習畫面
動作學習
CoachApp 範本與自有錄影的動作比對分析畫面
動作比對

CoachApp — 動作比對教練 App

錄下自己的動作，與範本影片比對。從範本工廠、版本商店到 iPhone App，把羽球實驗做成能跨運動重用的產品流程。

練的能力：Flutter、影片姿態分析、範本版本與產品發布流程。

0→1 成果：羽球與滑板範本、影片學習畫面、動作比對與版本同步。

正在驗證：同一條「工廠 → 商店 → App」流程能否支援不同運動。

↗ 看五天的產品決策紀錄
● 開發中 · v0.3.7
生活英文 App 選擇照片和學習難度的畫面，示範照片以色塊代替
照片與難度
生活英文 App 學習包完成與 AI 成本明細畫面
產出與成本
生活英文 App 離線學習包的中翻英選擇練習畫面
離線練習

生活英文學習 App

從一張日常照片出發，選學習難度，用 AI 產生可離線使用的英文學習包，再用圖卡和練習題學習。

練的能力：Flutter、AI 影像理解、單檔離線互動與成本追蹤。

0→1 成果：選照片與難度、產出學習包、顯示 AI 成本、離線練習。

正在驗證：不同照片與年級難度下，產出內容的品質與成本。

● 開發中
看完整作品與實驗紀錄 →
S5 · HOBBIES & ACHIEVEMENTS

興趣與成就

人生不只有寫碼 — 但寫碼確實佔了不少。

💻 技術寫碼 Coding S5a

早期深入鑽研過 91 極速開發流、單元測試與 TDD 重構, 個人累積超過 10 萬元的技術課程投資 😆

對於 91 流派的開發非常喜歡，歡迎有志一同的人士一起交流。

paulfun.net — 部落格學習記錄， dotblogs — 設計模式筆記。

🏸 羽球 S5b

愛好裝備：Victor TI-99 · Li-Ning 貼地飛行 Max

🥇
2003
大專盃 乙組金牌
🏆
2020
清晨盃 乙組冠軍
🥇
2025
一線入魂 混雙乙組 第一名
🥈
2025
一線入魂 男雙乙組 第二名
🏃 慢跑 S5c
110+ 週連續不間斷
2024 年 8 月開始，每週 12 公里，已累積超過 110 週不間斷。 持續累積中，相關紀錄圖片後續更新。
⛰️ 親子走山記錄 S5d

資料連動自 hiking.paulfun.net 步道資料庫 — 步道名稱、距離、難度自動同步，點卡片可看完整資訊。

2026
硬漢嶺
親子挑戰完成
看完整步道資料庫 →
⛺ 露營 Camping S5e

裝備：Snow Peak 鎖地獸 SDE-671 · 雨棚帳 TP-260 · 天幕 HD-250 · IGT 系統

⚔️ 魂系遊戲 · 目標導向的挑戰 S5f

我把魂系遊戲當成有終點的挑戰：設定目標、反覆練習、調整打法，直到完成。Elden Ring 白金獎盃是一次具體的驗證。

⚔️
隻狼：暗影雙死
Sekiro: Shadows Die Twice
練習觀察節奏、修正出手時機，直到能穩定過關。
🏆
艾爾登法環
Elden Ring 🏅 白金獎盃
設定白金目標，按步驟完成探索與挑戰。
🥃 Highball 專欄作家（誤） S5g

下一個目標：成為 Highball 專欄作家 🍋
自調 Highball — 日本式、台式、中式、韓式，持續研究中。

「寫程式寫累了就調一杯，debug 效率提升 200%。」— 未經證實

S6 · CONSULTING

讓團隊的下一步更清楚

適合已有產品與工程團隊，正在處理需求不清、交付卡關，或想把 AI 從個人工具帶進團隊流程的人。

可以一起處理的問題

需求不斷改變，團隊難以判斷先做什麼；AI 工具已經用上，卻還沒有清楚的驗證、交接與品質流程；技術方向需要有人協助取捨。

第一個月會帶走什麼

先釐清問題與成功標準，再選定一個優先主題。顧問型交付討論摘要與方向建議；陪跑型進一步留下決策紀錄、一次流程實驗與月度回顧。

業主買的不是「使用 AI 的時間」，而是判斷、取捨、責任與信任。 AI 讓我用更短的時間交付更好的成果 —— 那是能力提升，不是折價的理由。
S6 · 合作原則
// 先談卡點，不先談錢
第一次聊聊不收費——前提是題目我有興趣。我想先聽你卡在哪、已經試過什麼， 才知道這件事我幫不幫得上。幫不上我會直說，不會先報一個數字再回頭湊內容。
// 聊之前可以先想的四件事
01 現在最卡的是哪一件事？卡多久了？
02 三個月後它解決了，團隊會有什麼不一樣？（這就是驗收標準）
03 已經試過什麼？為什麼沒成？
04 誰會跟我一起推這件事？他能決定到哪裡？
這四題答得出來，第一次就能談出方向；答不出來也不要緊——那第一次就先一起把它們答出來。
▸ 談完上面四題，再談錢 — 展開收費方式▾ 收起收費方式
// 月費方案 — 以服務深度定價，不以案件數定價
方案差異在「同時推進幾個主題、多久對齊一次、多快回應、固定交出什麼」， 不在「這個月可以處理幾件事」。
顧問型
同時主題　1～2 個
固定對齊　每月 2 次
回應時間　3 個工作天內
固定產出
摘要與方向建議
NT$8,000 / 月
陪跑型
同時主題　2～3 個
固定對齊　每週 1 次
回應時間　2 個工作天內
固定產出
決策紀錄、實驗與月度回顧
NT$16,000 / 月
深度共創型
同時主題　依共同路線圖
固定對齊　每週 1～2 次
回應時間　下一個工作天內
固定產出
路線圖、協調、驗證與落地追蹤
另議
需求超出當月容量時不按件加價，而是三選一：延後低優先工作、下個月升級深度， 或獨立的大型建置另外成立專案。
單次諮詢 · 按時計價
NT$800 / 小時
技術討論、第二意見、架構與程式 review、臨時問題分析。最低一小時起。
首月試用 · 限新客戶
NT$4,000 / 首月
標準價值 NT$8,000 的五折。只限首月、同時推進一個主要目標，以折扣交換真實回饋與案例。這是正式合作的第一個月，與前面的免費首談是兩回事。
維護待命 · 驗收後
NT$3,000 / 月
每月運行檢查、脈絡保留、小型維護、兩個工作天內回應。不含新增功能與大幅改版。
保固範圍 · 無償修正
· 成果不符書面約定的功能或驗收標準
· 交付內容有明顯錯誤、遺漏或無法依約使用
· 約定環境與合理操作下，出現可重現的程式錯誤
· 未依已確認的需求製作（非因業主資料或指示錯誤）
需求變更 · 另行報價
· 原始規格與驗收標準中未曾約定的功能
· 驗收後新增或改變的商業規則、流程、使用情境
· 業主或第三方修改程式、設定、資料或環境所致
· 要求「更好看、更完整」但原驗收條件已經達成
// 一句話判定 Bug 還是新需求
成果完全符合當初的規格、範例與驗收條件，而業主現在希望它有不同表現 —— 這是需求變更。
成果沒有做到當初明確承諾的行為 —— 這是缺陷。
仍有爭議時回到原始紀錄、會議摘要、原型與驗收標準共同判定，不由任何一方單方面定義。
// 合作前會一起確認的事
□ 問題、目標與成功標準
□ 可驗收成果與排除項目
□ 會議、討論與修改額度
□ 雙方負責人與回覆期限
□ AI、雲端與第三方成本負擔
□ 資料安全、保密與工具範圍
□ 驗收、保固與新需求界線
□ 付款節點與變更流程
□ 智慧財產權與原始檔歸屬
□ 中止時的結算與交接
用透明建立信任，用邊界保護信任。 讓業主知道自己買到什麼，讓顧問知道自己承諾到哪裡。
想談談卡點？
✉ [email protected] 來信講你卡在哪、已經試過什麼就好，不用先問價格。題目對得上，我們先免費聊一次。