Coding agent 讓重寫變便宜，那 UX 的「穩定層」要怎麼定義？

Ruby Chou · 2026-05-16T11:30:37.751418+00:00

最近讀到 Simon Willison 聊語言鎖定的問題，他的核心論點大概是：coding agent 讓跨語言重寫的成本低很多，所以「被某個技術框架綁死」這件事正在變得沒那麼嚴重。工程師可以更快地把整個 codebase 換掉。從技術角度聽起來蠻合理的，但我在設計端一直有個問題卡著沒想通。我們公司去年底做了一次比較大的架構調整，前端從一套 component library 換到另一套。工程師三週跑完，code review 也過了，從他們的角度算快的。但設計這邊整個 design system 的 token mapping 要重新對、所有的 spacing 邏輯要重新審、然後 handoff 的方式也不一樣——我們花了快兩個月才讓新的元件跑起來跟舊的「長一樣」。那兩個月，使用者收到的是什麼？兩個版本在不同地方同時存在，有些頁面 padding 是舊邏輯、有些是新邏輯，QA 也分不清楚哪個是對的。所以我有點懷疑一件事：當重寫的「工程成本」降低，但我們有沒有同步想過哪些東西其實不應該被重寫？從 UX 的角度來看，有一些東西我覺得不是技術問題，而是 user 的心智模型問題。比如一個功能的操作流程，user 已經記在肌肉裡了，你重寫底層邏輯沒差，但如果步驟順序變了、或者按鈕位置跑了，那個 learning cost 是由使用者承擔的。工程師看到的是「反正重寫一下就好」，但 end user 在乎的是「我的習慣被打斷了」。更具體的問題是：如果技術可替換性變高，誰來定義哪些「體驗資產」是不能被頻繁動的？文案的 tone of voice？核心功能的操作心智？甚至是 error message 的措辭？這些東西以前靠「重寫成本高」自然地穩定下來，現在成本低了，是不是要靠流程來保護它？我試過在工程和設計協作的 spec 裡加一欄「影響使用者心智模型的變動」，要求這類改動必須附 user research 或 A/B test 計畫才能進 sprint。但老實說推得很痛苦，工程師覺得這是在拖慢節奏，PM 覺得我在把關卡加重。想問問這裡有沒有人在 coding agent 普及之後，有重新調整設計和工程的協作流程的？特別是怎麼定義「這次重寫要不要連 UX 一起動」的判斷標準？或者有沒有遇到「技術上換掉很快，但使用者體驗卻退步」的實際案例？

Ruby Chou

發布於: 大約 2 個月前

加載中...

回覆區

排序

雅恩

#1樓

大約 2 個月前

穩定層這題超真實

Agent狂魔

#2樓

大約 2 個月前

我接案時踩過！agent 幫我三天重構完，但客戶說流程跑掉了。後來我在 spec 直接標「使用者肌肉記憶層」，這些 agent 絕對不能碰。

Ruby Chou

回覆 Agent狂魔

大約 2 個月前

「使用者肌肉記憶層」這個命名很好欸，比我用的「心智模型凍結區」直覺多了。好奇你標完之後 agent 真的會避開嗎？我這邊是靠 PR review 擋，但有時候 spacing 被動了也沒人注意到 😅

關聯 / 被收藏牆

被引用

尚未被引用或收藏

相關卡片

尚無相關卡片