基礎脈絡
文件脈絡 / 版本管理 / 報告 / 需求整理
流程地圖
先把流程整理清楚，工具才承接得住
通常會先把問題、規則、工具和驗證方式對清楚，再把它整理成團隊可以延續、也方便維護的流程。
規則與協作
共用規則 / Skills / Agents / 長期記錄
工具層
MCP / Browser / Appium / Playwright / Bot API
執行層
測試 / 除錯 / 審查 / 部署確認
驗證證據
截圖 / 報告 / 執行記錄 / 驗證結果
回饋迴路
回顧整理 / 經驗更新 / 可重用流程
做過的事
先看幾個有數字的結果
這些數字來自實際做過的流程，包含測試執行、除錯、程式審查、部署確認、行動測試和知識庫交接。
35+ 可重用流程與規則
9 審查 Agents
70+ UAT / E2E 測試案例
4-7h -> 1-2h 測試週期縮短
工作範圍
工作範疇落在 PM、工程和測試的交界
習慣先把問題、限制和驗證方式整理清楚，再往下推進。
把內部 AI 工具從想法做到可用版本
為早期產品團隊建立 QA 自動化
MCP 與工具串接
流程文件化與交接
營運流程用的 Bot 與自動化工具
核心能力
把 AI 能力落地成可維護流程
AI workflow 設計
將模糊任務拆成流程、規則、工具、驗證方式與失敗處理，讓 AI 助手能在明確邊界內協助執行。
流程設計 / 共用規則 / Skills / Agents / 長期維護MCP / 工具整合
設計 MCP 與工具串接方式，讓 AI 能查詢資料、操作工具、執行任務，同時把憑證與環境風險控在邊界內。
MCP / 工具串接 / 唯讀存取 / 憑證安全以證據為核心的 QA 自動化
將中文測試情境轉成瀏覽器或 App 操作、截圖存證、驗證結果與測試報告，降低人工重複測試與報告失真。
Playwright / Appium / UAT / E2E / 截圖證據作品案例
案例先交代問題，再說明怎麼處理
多工具協作案例
AI 協作流程、Skills / Agents 與 MCP 工具整合
把零散流程整理清楚，讓不同 AI 和不同工作階段都能延續。
當時的問題
AI 工具越用越多，但規則、工具、測試方式和交接脈絡很容易散掉。
問題怎麼來的
真正麻煩的不是單一工具，而是每次換一個工作階段、換一個 AI，很多背景和規則都要重新補，結果很難穩定延續。
處理方式
先把共用規則、Skills、Agents、知識庫橋接和 MCP 設定拆成可以分層維護的做法，再把常見任務對回對應的規則。
最後結果
後來很多測試、除錯、程式審查和部署確認，都能沿著同一套規則往下做，也比較容易把工作脈絡留給下一個工作階段。
自然語言測試情境到可驗證報告
AI 輔助 UAT / E2E 測試流程
把驗證流程整理清楚，讓 Claude Code 先承接重複、耗時的測試工作。
當時的問題
很多測試當時還得靠人工重跑，時間被吃得很兇。
問題怎麼來的
麻煩的不只是單一測試，而是每次驗證都得重新整理步驟、重跑流程，最後還要再人工確認一次。
處理方式
先把驗證流程拆開，再把重複、耗時，而且判斷條件相對清楚的部分交給 Claude Code。
最後結果
重複驗證先被承接之後，時間就能放回真正需要判斷的地方。單輪重複驗證大多可以先壓到十幾分鐘左右，整體測試週期則整理到 1-2 小時。
從個人需求長出來的工具案例
TimeTree 行事曆自動化
把活動整理這類零碎工作，拆成 Claude 可以安全承接的工具流程。
當時的問題
活動資訊常散在海報或訊息裡，手動整理到共享行事曆很瑣碎。
問題怎麼來的
真正麻煩的不是新增一筆事件，而是日期、地點和說明常分散在不同來源，整理時很容易漏。
處理方式
先把工具邊界、欄位規則和記錄保護整理清楚，再把建立或更新事件這類重複操作交給 Claude。
最後結果
後來這件事就從手動整理，變成在日常使用裡驗證這套串接方式、工具邊界和憑證保護能不能撐住。
另外也延伸做過 LINE Todo Bot 串接、Teams Bot 架構、AI 內容流程，以及預約自動化規劃。
公開筆記
把反覆用到的方法、規則和邊界整理成公開筆記
這裡不講單一專案做了什麼，而是把我平常怎麼判斷、怎麼拆流程、怎麼守住風險，整理成可以直接閱讀的版本。
怎麼判斷一段流程適不適合交給 AI
有些事很適合交給 AI 先做，有些事太早交出去只會把混亂放大。這篇記的是我怎麼判斷那條分界線。
為什麼我會把「驗不到就不算通過」寫成規則
這條規則聽起來很嚴，但它其實是拿來保護後面的判斷。沒驗到就先說沒驗到，遠比假裝通過安全。
我怎麼把 AI 規則拆成 shared rules、Skills 和 review agents
我後來把 AI 的使用方式拆成三層：底線、任務規則、獨立驗證。這樣工具和工作階段在換，規則還是接得住。
中文 Markdown 測試情境，為什麼比直接寫腳本更適合起步
我不是反對腳本，而是覺得很多流程太早寫成腳本，會先把誤解固定下來。先用中文情境，反而更容易對齊。
做 MCP 工具時，我會先處理哪些風險
我做 MCP 工具時，通常先處理風險，再談功能。因為工具能動，不代表它就適合真的放進日常使用。
怎麼讓不同工作階段還接得上前面的脈絡
這篇不是在講記筆記而已，而是在講怎麼讓下一次接手的人或下一個工作階段，不用再從零補背景。
工作方式
一件事通常會怎麼往下拆
通常會先釐清今天的問題、輸入輸出和驗證方式，再決定哪些步驟適合交給 AI，哪些還是要保留人工判斷。工具接上之後，再補證據、錯誤處理和文件，這樣下一次不用再從頭整理。
- 釐清任務
- 定義規則與邊界
- 接上合適工具
- 執行並留下證據
- 整理流程文件
- 把經驗整理成下次可重用的做法
適合的團隊
特別適合正在把速度和穩定性一起拉起來的團隊。
特別適合新創早期、內部工具剛起步，或 QA / automation 還沒被系統化的階段。
合作方向
如果團隊正在整理 AI workflow、工具整合或 QA 自動化，適合直接聊聊。
目前主要在找 AI workflow、工具整合和 QA 自動化相關角色。
背景原本來自心理學與神經科學，做事習慣先定義問題、設計驗證方式，再決定怎麼處理。這套習慣後來也延伸到 AI workflow 和 QA automation。
聯絡方式
- yicheng980919@gmail.com
- 104 履歷
- 公開履歷連結若 104 連結失效，歡迎直接 Email 聯絡。
- PDF 履歷
- 準備中新版 PDF 會對齊 AI workflow、工具整合、QA 自動化工程師的定位。
- GitHub
- 準備公開專案TimeTree 行事曆自動化、UAT 示範流程和流程規則案例，會先清理敏感資訊後公開。