計問題：一次性的可運行原型如何沉淀為真實決策)
用 prototype 技能回答設(shè)計問題一次性的可運行原型如何沉淀為真實決策【免費下載鏈接】skillsSkills for Real Engineers. Straight from my .agents directory.項目地址: https://gitcode.com/GitHub_Trending/skills13/skills導(dǎo)讀prototype是本倉庫Skills for Real Engineers中一個模型可自動調(diào)用的工程技能當(dāng)團隊遇到這個狀態(tài)模型對不對這個界面應(yīng)該長什么樣這類無法靠討論拍板的設(shè)計問題時它指導(dǎo)你寫一段回答問題的臨時代碼throwaway code快速產(chǎn)出一個可運行、可分享、可由非開發(fā)者親手把玩的產(chǎn)物。讀完本文你將掌握 prototype 技能的雙分支選型邏輯邏輯原型 vs UI 原型、兩份分步實操指南LOGIC.md 與 UI.md、原型即一手資料primary source的留存紀律以及它與 wayfinder、to-spec、handoff 等技能如何組成一條完整的設(shè)計決策流水線。一、prototype 是什么一次性代碼回答一個問題技能入口定義在 SKILL.md 中元信息寫得很克制Build a throwaway prototype to answer a design question. Use when the user wants to sanity-check whether a state model or logic feels right, or explore what a UI should look like.一句話概括prototype 寫的是回答問題的臨時代碼問題是第一位的問題決定后面一切產(chǎn)物的形狀。一個回答了錯誤問題的原型無論做得多么漂亮都是純粹的浪費。關(guān)鍵澄清兩點一次性是寫代碼方式的約束不是銷毀代碼的承諾。不寫測試、不做超出能跑起來的錯誤處理、不抽象、不持久化——因為這些都不會幫助你學(xué)到那個唯一想學(xué)的東西。真正幸存下來的是答案答案被折疊進真實代碼原型本身則停在 main 之外的一個臨時分支上作為答案確實來自這里的證據(jù)。從倉庫結(jié)構(gòu)看該技能是一個獨立的技能目錄skills/engineering/prototype/包含SKILL.md總綱、LOGIC.md邏輯分支、UI.mdUI 分支和agents/openai.yaml面向 Codex 等 Agent 的顯示名配置僅聲明display_name: Prototype。它在 README.md 的 Reference 中被歸為Model-invoked模型可調(diào)用技能——既可以被用戶主動/prototype喚起也可以在任務(wù)匹配時由 Agent 自動接取。二、何時使用把談不攏變成看一眼2.1 觸發(fā)時機當(dāng)你遇到一個靠對話無法解決的問題時就該動用它一個狀態(tài)機的邊界情況你在腦子里裝不下一個界面你沒看到三個版本并排放在一起就無法想象它。grilling 系列會話恰恰容易在這類問題上膨脹Agent 反復(fù)改述、你不斷猜測、范圍隨著不確定性越滾越大。停止追問構(gòu)建一次性版本看一眼然后一行字回答。這正是原型存在的意義——把高保真討論轉(zhuǎn)化為一個可反應(yīng)的實物。2.2 與相鄰技能的邊界如果已經(jīng)構(gòu)建好的東西行為異常、你想知道它為什么壞了應(yīng)該用 diagnosing-bugs。原型探索的是該構(gòu)建什么而不是已構(gòu)建的東西為什么壞了。如果你已經(jīng)知道要構(gòu)建什么下一步是 implement。只有某個具體的設(shè)計問題真正懸而未決、且對話無法解決時才值得進入原型。2.3 被動進入你也會在沒主動選擇的情況下到達這里wayfinder 會在它的地圖上為prototype決策簽發(fā)決策工單decision ticket處理這個工單本身就是本技能。詳見下文技能生態(tài)。三、兩條分支先選對再做對問題決定分支兩條分支產(chǎn)出截然不同的產(chǎn)物。選錯分支會浪費整個原型。分支要回答的問題產(chǎn)物形態(tài)適用場景邏輯分支Logic這個邏輯 / 狀態(tài)模型感覺對嗎單個可分享的 HTML 文件業(yè)務(wù)邏輯、狀態(tài)遷移、數(shù)據(jù)結(jié)構(gòu)UI 分支UI這應(yīng)該長什么樣同一路由上多個結(jié)構(gòu)迥異的 UI 變體頁面布局、信息層級、視覺方向如果問題確實模棱兩可且用戶不在場SKILL.md 給出的默認策略是以周圍代碼判斷——后端模塊傾向于邏輯分支頁面或組件傾向于 UI 分支并在原型頂部顯式聲明這個假設(shè)。3.1 邏輯分支一個能雙擊打開、能發(fā)郵件的 HTML 文件詳盡的邏輯分支操作手冊見 LOGIC.md。它的目標產(chǎn)物是一個自包含的單個 HTML 文件shareable demo無構(gòu)建、無服務(wù)器任何人雙擊即可打開能被當(dāng)作郵件附件轉(zhuǎn)發(fā)。頁面背后的邏輯是一個純凈的小模塊reducer、狀態(tài)機或一組函數(shù)保持與 DOM 解耦這樣經(jīng)過驗證的版本能直接抬升lift進真實代碼。適用場景的典型表述我不確定這個狀態(tài)機能不能處理 X 然后 Y 的邊緣情況。這個數(shù)據(jù)模型真的能表達……這種情況嗎我想在動手寫之前感受一下這個 API 應(yīng)該長什么樣。任何想按按鈕、看狀態(tài)變化的訴求。文件結(jié)構(gòu)自上而下的清晰層級標題 一句話說明這個 demo 讓你探索什么即第一步寫下的問題。這段說明要放在可見的引言區(qū)而不是只寫進代碼注釋——因為需要確保問題可被事后核查無論用戶是在旁觀看還是之后 AFK 回來。當(dāng)前狀態(tài)面板完整相關(guān)狀態(tài)以可讀的面板渲染帶標簽的字段而不是原始 JSON dump每次點擊后重新渲染讓變化可見在有助于非開發(fā)者跟上時標注剛才發(fā)生了什么。自由探索按鈕每個動作一個按鈕始終可用任何人可以任意順序戳模型每次點擊派發(fā)對應(yīng) action 并重新渲染。引導(dǎo)式演練guided walkthroughs一組場景每個場景一個標簽頁。每個標簽頁包含一段場景的通俗描述它建立什么情境、該觀察什么下方是該場景按順序要按的按鈕。每個步驟都是真實按鈕點擊執(zhí)行該動作并進入下一步。啟動演練會重置到已知初始狀態(tài)保證場景每次以相同方式運行。場景應(yīng)選擇紙上推理困難的情況快樂路徑、棘手的邊緣情況、一次應(yīng)該被判定為非法的嘗試。邏輯的四種形狀取決于問題類型純 reducer(state, action) state——動作是離散事件、狀態(tài)是單一值狀態(tài)機顯式的狀態(tài)與遷移——當(dāng)前哪些動作合法本身就是問題的一部分一組純函數(shù)作用于普通數(shù)據(jù)類型、沒有隱式當(dāng)前狀態(tài)、只有變換類或帶清晰方法面的模塊邏輯確實擁有持續(xù)的內(nèi)部狀態(tài)。核心紀律保持邏輯純凈——不碰 DOM、不碰document、內(nèi)部不放按鈕處理器。頁面調(diào)用模塊反向不成立。這是原型在其生命周期之外仍然有用的原因一旦問題得到回答被驗證的 reducer / 狀態(tài)機 / 函數(shù)集能獨立抬升進真實模塊。HTML 殼是臨時性的邏輯模塊不是。3.2 UI 分支幾個結(jié)構(gòu)迥異的變體一個浮動切換條詳盡的 UI 分支操作手冊見 UI.md。目標產(chǎn)物是在同一條路由上生成幾個結(jié)構(gòu)迥異的 UI 變體通過浮動的底部切換條和?variantURL 參數(shù)切換。用戶在瀏覽器里翻來翻去挑一個或從每個里偷一點然后把其余的扔掉。關(guān)鍵約束變體必須在結(jié)構(gòu)上分歧而不是顏色。三個微調(diào)過的卡片網(wǎng)格只是壁紙不是原型。變體盡量在真實頁面里渲染——真實頁頭、真實側(cè)邊欄、真實數(shù)據(jù)、真實密度——因為在真空中評判的變體永遠顯得不錯。兩種子形態(tài)強烈優(yōu)先子形態(tài) A子形態(tài) A改造現(xiàn)有頁面首選。路由已存在變體在同一路由上渲染由?variant搜索參數(shù)門控?，F(xiàn)有的數(shù)據(jù)獲取、參數(shù)、鑒權(quán)全部保留只有渲染子樹切換。即便原型針對的是還沒有頁面、但天然會住進某個頁面的東西dashboard 的新區(qū)塊、設(shè)置頁的新卡片、現(xiàn)有流程的新步驟也歸為 A——把變體掛載進宿主頁面。子形態(tài) B新頁面最后手段。僅當(dāng)原型對象確實沒有可寄居的現(xiàn)有頁面時使用例如全新的頂級界面或無法嵌入任何合理位置的流程。創(chuàng)建一次性路由時遵循項目既有的路由約定不要發(fā)明新的頂層結(jié)構(gòu)路徑或文件名里包含prototype字樣以便一眼可辨。提交到 B 之前先自檢真的沒有現(xiàn)有頁面可以嵌入嗎空路由會隱藏布滿真實數(shù)據(jù)時才會暴露的設(shè)計問題。兩種子形態(tài)的浮動切換條完全一致。四、UI 分支實操流程含可復(fù)制的切換器代碼4.1 第一步陳述問題并確定 N默認 3 個變體超過 5 個就不再是結(jié)構(gòu)迥異而開始變成噪聲所以上限是 5。在原型所在位置或文件頂部注釋里寫一行計劃例如設(shè)置頁的三個變體通過?variant切換位于現(xiàn)有/settings路由上。4.2 第二步生成結(jié)構(gòu)迥異的變體每個變體必須對照頁面目的與其可訪問的數(shù)據(jù)項目的組件庫 / 樣式體系TailwindCSS、shadcn、MUI、純 CSS……一個清晰的導(dǎo)出組件名如VariantA、VariantB、VariantC。變體必須在**布局、信息層級、主操作primary affordance**上真正不同。如果兩個草案過于相似用不要用卡片網(wǎng)格的明確指引重做其中一個。4.3 第三步接線——單一切換器組件在路由上創(chuàng)建一個切換器組件UI.md 給出了可直接參考的偽代碼需按項目框架適配// pseudo-code, adapt to the projects framework const variant searchParams.get(variant) ?? A; return ( {variant A VariantA {...data} /} {variant B VariantB {...data} /} {variant C VariantC {...data} /} PrototypeSwitcher variants{[A,B,C]} current{variant} / / );子形態(tài) A所有既有數(shù)據(jù)獲取保持在切換器之上只有渲染子樹按變體切換。子形態(tài) B/prototype/name下的一次性路由掛載同一個切換器。4.4 第四步構(gòu)建浮動切換條一個固定在屏幕底部居中的小條包含三件套左箭頭循環(huán)切到上一個變體可回繞變體標簽顯示當(dāng)前變體鍵若變體導(dǎo)出了名稱則一并顯示如B (Sidebar layout)右箭頭循環(huán)切到下一個變體可回繞。行為要求點擊箭頭更新 URL 搜索參數(shù)用框架的路由器Next 用router.replace、React Router 用navigate等使變體可分享、刷新后仍穩(wěn)定鍵盤←/→也能循環(huán)當(dāng)input、textarea或[contenteditable]獲得焦點時不得攔截方向鍵與頁面視覺明顯區(qū)分高對比膠囊、微妙陰影讓人一眼看出它不屬于被評估的設(shè)計在生產(chǎn)構(gòu)建中隱藏用process.env.NODE_ENV ! production或等價檢查門控防止一次意外的原型合并把切換條發(fā)給真實用戶。切換器放進單一共享組件兩種子形態(tài)復(fù)用放在項目共享 UI 通常所在的位置。4.5 第五、六步交接與收尾把 URL 和?variant鍵交給用戶。最有趣的反饋通常是我想要 B 的頁頭配 C 的側(cè)邊欄——那才是他們真正想要的設(shè)計。變體勝出后捕獲答案哪個變體、為什么然后把原型按 SKILL.md 的方式歸檔見下一節(jié)。收尾映射子形態(tài) A把勝者折疊進現(xiàn)有頁面從 main 中移除落選變體和切換器子形態(tài) B把勝者提升為真實路由從 main 中移除一次性路由和切換器。完整變體集合是一手資料所以它落在臨時分支上而不是垃圾桶——因為變體組件和切換器留在 main 分支會快速腐化并誤導(dǎo)后來的讀者。4.6 UI 分支反模式清單變體只在顏色或文案上有差異那是微調(diào)不是原型真正的變體在結(jié)構(gòu)上分歧變體間共享太多代碼共享Header沒問題共享Layout就破壞了意義每個變體應(yīng)能自由推翻布局把變體接到真實寫操作只讀原型沒問題若變體需要變更數(shù)據(jù)指向樁stub——問題在于應(yīng)該長什么樣而不是后端能不能跑把原型直接提升到生產(chǎn)變體代碼是在原型約束下寫的無測試、最小錯誤處理折疊時必須用正確方式重寫。五、邏輯分支的反模式與真相時刻LOGIC.md 同樣給出反模式清單別加測試——需要測試的原型就不再是原型別接真實數(shù)據(jù)庫——除非問題本身就關(guān)于持久化否則用內(nèi)存狀態(tài)別泛化——沒有萬一以后要支持 X原型只回答一個問題別把邏輯和頁面攪在一起——純模塊一旦引用 DOM、document或按鈕處理器就不可抬升了別上框架、打包器或服務(wù)器——單個可雙擊文件一個 React 應(yīng)用或 dev server 就毀了可分享別把 HTML 殼發(fā)到生產(chǎn)——頁面是為被人手工點擊而優(yōu)化的它背后的邏輯模塊才是值得保留的部分。交接時的真相時刻把文件發(fā)過去或幫對方打開讓他們點演練、自由探索。真正有價值的瞬間是當(dāng)他們說出等等這不應(yīng)該可能發(fā)生或咦我還以為 X 會不一樣時——那是想法本身的 bug而這正是原型的全部意義。如果他們想要新動作或新場景就加上原型是會演化的。六、原型是一手資料答案進 main證據(jù)留分支這是 prototype 方法論最獨特的一環(huán)完成后的原型留下兩樣?xùn)|西它們?nèi)ネ煌牡胤健４鸢附Y(jié)論 它所解決的問題被持久化捕獲一條 commit message、一份 ADR、或?qū)崿F(xiàn)工單。這是 main 分支保留的內(nèi)容——折疊進真實代碼。原型是答案來自哪里的可運行證據(jù)不刪除。但它同樣不屬于 main那里沒有需要維護它的東西而且它腐化得很快。因此它被提交到 main 之外的一個一次性分支prototype/name永不合并并在實現(xiàn)工單上留下指向該分支的上下文指針context pointer。main 保持干凈探索保持可查找、可重跑——無論下一個接手工作的人是誰。6.1 圍繞是否刪除的演進等等原型不是應(yīng)該刪掉嗎——曾經(jīng)確實如此構(gòu)建、保留答案、扔掉代碼。對這種做法最尖銳的反對從來與速度無關(guān)而是下一個接手的會話有什么可依據(jù)一份散文式總結(jié)會丟掉讓原型有說服力的東西。所以現(xiàn)在原型被當(dāng)作一手資料對待它落在 main 之外的prototype/name分支上實現(xiàn)工單指向它。改變的是代碼存放的位置不是紀律本身——它仍然永不合并進 main。6.2 那個終端應(yīng)用去哪了邏輯分支以前產(chǎn)出終端應(yīng)用現(xiàn)在改為產(chǎn)出單個可分享的 HTML 文件。原因很實際終端應(yīng)用只能由克隆了倉庫且裝了運行時的人驅(qū)動這恰好把原型最需要其意見的人排除在外——設(shè)計師、PM、知道狀態(tài)模型本該表達什么的領(lǐng)域?qū)＜?。而一個雙擊即開、可被郵件轉(zhuǎn)發(fā)的自包含文件任何人都能驅(qū)動。底層的純邏輯模塊不變它依然是可以抬升進真實代碼的部分。七、常見問題與邊界澄清Agent 在應(yīng)該實現(xiàn)的時候叫我/prototype。已知問題而且是個命名問題。prototype是個通用而有吸引力的詞對不了解流程的 Agent 來說一旦工單存在原型讀起來像顯而易見的下一步所以它會在設(shè)計已經(jīng)通過對話完全敲定的情況下被按名字推薦。如果你已經(jīng)知道要構(gòu)建什么下一步是 implement只有當(dāng)某個具體設(shè)計問題真正懸而未決、且對話解決不了時才動用原型。我應(yīng)該在構(gòu)建任何生產(chǎn)功能之前先原型整個應(yīng)用比如給潛在客戶演示嗎那是戴著本技能名字的另一種產(chǎn)物。這里的原型范圍限定為一個問題整個應(yīng)用是什么不是一個問題。全應(yīng)用原型沒有自然的停止點于是會靠慣性變成生產(chǎn)應(yīng)用清理永遠不會發(fā)生在原型規(guī)則下寫的代碼無測試、無錯誤處理會跑到用戶面前。需要銷售演示就把它當(dāng)作演示刻意構(gòu)建并明確說明其中沒有什么是生產(chǎn)級的需要解決設(shè)計問題就把范圍切到那個問題上。怎么在自己的會話里運行它原型生活在自己的目錄里會產(chǎn)生大量你不想留在提問線程里的上下文所以要在別處運行、只把答案帶回來。handoff 是雙向的橋梁——它把當(dāng)前會話壓縮成一份交接文檔供新的 Agent 繼續(xù)并在文檔中列出下一步應(yīng)調(diào)用的技能。這不是最快的燒 token 方式嗎可能是——如果你對能用對話回答的問題做原型或讓一個原型蔓延到整個功能。真正有意義的比較不是 token 對比零而是token 對比構(gòu)建了錯誤的狀態(tài)模型、等它有生產(chǎn)調(diào)用者之后才發(fā)現(xiàn)。把問題收窄、運行時間縮短開銷就始終成比例。八、它正在工作的標志驗收清單原型文檔 給出了可操作的驗收清單你能用一句話說出原型要回答什么問題而且它寫在 demo 頂部不只是在你腦子里一個不讀代碼的人能驅(qū)動邏輯 demo打開文件、按演練標簽頁里的按鈕、用自己的話描述所見有人說等等那不應(yīng)該可能發(fā)生或咦我以為 X 是這樣——那是想法的 bug而這正是全部意義所在UI 變體在布局和信息層級上分歧而不只是顏色和文案你收到的反饋是我要 B 的頁頭配 C 的側(cè)邊欄在一次會話內(nèi)得到回答——如果一天后你還在構(gòu)建它說明問題太大拆開它結(jié)束時main 包含決策且不包含任何原型代碼實現(xiàn)工單指向仍然持有原型的分支。九、技能生態(tài)prototype 在決策流水線中的位置從 README.md 和 skills/engineering/README.md 的技能分類看prototype是一個隨時可用的獨立技能reach-for-it-anytime standalone你切入它解決一個設(shè)計問題然后切出它同時也是另一套機制賴以運行的機器。9.1 最大消費者wayfinder它的最大消費者是 wayfinder。wayfinder 地圖由決策工單構(gòu)成而prototype是工單的四種類型之一另外三種是research、grilling、task用于阻塞性問題屬于這應(yīng)該長什么樣 / 這應(yīng)該怎么表現(xiàn)、任何討論都無法解決的情況。wayfinder 通過制造一個具體的可反應(yīng)物來提升模糊討論的保真度而本技能就是這個具體物如何被構(gòu)建出來。在 wayfinder 中原型工單是 HITL人在回路類型的原型工單由答案解決原型作為資產(chǎn)從地圖鏈接。9.2 上下游鄰居上游grill-me 與 grill-with-docs 回答可盤問的問題不可盤問的問題轉(zhuǎn)到本技能一行字的答案再回到訪談里。下游驗證過的狀態(tài)模型或 UI 方向成為 to-spec 的既定輸入。值得注意的是to-spec 的規(guī)范模板有一個針對原型的專門條款當(dāng)原型產(chǎn)出的代碼片段狀態(tài)機、reducer、schema、類型形狀比散文更精確地編碼了決策時允許在對應(yīng)決策中內(nèi)聯(lián)該片段并簡要注明它來自原型——但要裁剪到承載決策的部分而不是一份可運行的 demo。這正是原型即一手資料在規(guī)范環(huán)節(jié)的落點。兜底路由其他任何情況ask-matt 會在整個技能集合之上為你指路。十、如何在你的項目中落地該技能已存在于本倉庫安裝與使用方式如下本技能目錄位于 skills/engineering/prototype/按 README.md 的安裝說明可用npx skillslatest add mattpocock/skills把選中的技能文件復(fù)制進你的項目后按需修改Claude Code 用戶可用claude plugins install mattpocock-skills安裝整套受管只讀插件。對 Codex 等 Agent技能通過agents/openai.yaml僅含display_name: Prototype聲明接口。落地時建議先通讀三份核心文件SKILL.md總綱與公共規(guī)則、LOGIC.md邏輯分支、UI.mdUI 分支再結(jié)合 wayfinder、to-spec、handoff 理解它在整條決策流水線中的位置。最后的提醒一旦你發(fā)現(xiàn)自己開始加固某個原型——加測試、接真實數(shù)據(jù)庫、為一個以后可能會用到的情況做泛化——你就已經(jīng)停止了原型化。保持問題窄、運行時間短、產(chǎn)物可分享、答案落 main、證據(jù)留分支這六條紀律合在一起就是原型從燒 token 的臨時腳本變成工程設(shè)計的一手資料的全部秘密?！久赓M下載鏈接】skillsSkills for Real Engineers. Straight from my .agents directory.項目地址: https://gitcode.com/GitHub_Trending/skills13/skills創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考 用 prototype 技能回答設(shè)計問題：一次性的可運行原型如何沉淀為真實決策
用 prototype 技能回答設(shè)計問題一次性的可運行原型如何沉淀為真實決策【免費下載鏈接】skillsSkills for Real Engineers. Straight from my .agents directory.項目地址: https://gitcode.com/GitHub_Trending/skills13/skills導(dǎo)讀prototype是本倉庫Skills for Real Engineers中一個模型可自動調(diào)用的工程技能當(dāng)團隊遇到這個狀態(tài)模型對不對這個界面應(yīng)該長什么樣這類無法靠討論拍板的設(shè)計問題時它指導(dǎo)你寫一段回答問題的臨時代碼throwaway code快速產(chǎn)出一個可運行、可分享、可由非開發(fā)者親手把玩的產(chǎn)物。讀完本文你將掌握 prototype 技能的雙分支選型邏輯邏輯原型 vs UI 原型、兩份分步實操指南LOGIC.md 與 UI.md、原型即一手資料primary source的留存紀律以及它與 wayfinder、to-spec、handoff 等技能如何組成一條完整的設(shè)計決策流水線。一、prototype 是什么一次性代碼回答一個問題技能入口定義在 SKILL.md 中元信息寫得很克制Build a throwaway prototype to answer a design question. Use when the user wants to sanity-check whether a state model or logic feels right, or explore what a UI should look like.一句話概括prototype 寫的是回答問題的臨時代碼問題是第一位的問題決定后面一切產(chǎn)物的形狀。一個回答了錯誤問題的原型無論做得多么漂亮都是純粹的浪費。關(guān)鍵澄清兩點一次性是寫代碼方式的約束不是銷毀代碼的承諾。不寫測試、不做超出能跑起來的錯誤處理、不抽象、不持久化——因為這些都不會幫助你學(xué)到那個唯一想學(xué)的東西。真正幸存下來的是答案答案被折疊進真實代碼原型本身則停在 main 之外的一個臨時分支上作為答案確實來自這里的證據(jù)。從倉庫結(jié)構(gòu)看該技能是一個獨立的技能目錄skills/engineering/prototype/包含SKILL.md總綱、LOGIC.md邏輯分支、UI.mdUI 分支和agents/openai.yaml面向 Codex 等 Agent 的顯示名配置僅聲明display_name: Prototype。它在 README.md 的 Reference 中被歸為Model-invoked模型可調(diào)用技能——既可以被用戶主動/prototype喚起也可以在任務(wù)匹配時由 Agent 自動接取。二、何時使用把談不攏變成看一眼2.1 觸發(fā)時機當(dāng)你遇到一個靠對話無法解決的問題時就該動用它一個狀態(tài)機的邊界情況你在腦子里裝不下一個界面你沒看到三個版本并排放在一起就無法想象它。grilling 系列會話恰恰容易在這類問題上膨脹Agent 反復(fù)改述、你不斷猜測、范圍隨著不確定性越滾越大。停止追問構(gòu)建一次性版本看一眼然后一行字回答。這正是原型存在的意義——把高保真討論轉(zhuǎn)化為一個可反應(yīng)的實物。2.2 與相鄰技能的邊界如果已經(jīng)構(gòu)建好的東西行為異常、你想知道它為什么壞了應(yīng)該用 diagnosing-bugs。原型探索的是該構(gòu)建什么而不是已構(gòu)建的東西為什么壞了。如果你已經(jīng)知道要構(gòu)建什么下一步是 implement。只有某個具體的設(shè)計問題真正懸而未決、且對話無法解決時才值得進入原型。2.3 被動進入你也會在沒主動選擇的情況下到達這里wayfinder 會在它的地圖上為prototype決策簽發(fā)決策工單decision ticket處理這個工單本身就是本技能。詳見下文技能生態(tài)。三、兩條分支先選對再做對問題決定分支兩條分支產(chǎn)出截然不同的產(chǎn)物。選錯分支會浪費整個原型。分支要回答的問題產(chǎn)物形態(tài)適用場景邏輯分支Logic這個邏輯 / 狀態(tài)模型感覺對嗎單個可分享的 HTML 文件業(yè)務(wù)邏輯、狀態(tài)遷移、數(shù)據(jù)結(jié)構(gòu)UI 分支UI這應(yīng)該長什么樣同一路由上多個結(jié)構(gòu)迥異的 UI 變體頁面布局、信息層級、視覺方向如果問題確實模棱兩可且用戶不在場SKILL.md 給出的默認策略是以周圍代碼判斷——后端模塊傾向于邏輯分支頁面或組件傾向于 UI 分支并在原型頂部顯式聲明這個假設(shè)。3.1 邏輯分支一個能雙擊打開、能發(fā)郵件的 HTML 文件詳盡的邏輯分支操作手冊見 LOGIC.md。它的目標產(chǎn)物是一個自包含的單個 HTML 文件shareable demo無構(gòu)建、無服務(wù)器任何人雙擊即可打開能被當(dāng)作郵件附件轉(zhuǎn)發(fā)。頁面背后的邏輯是一個純凈的小模塊reducer、狀態(tài)機或一組函數(shù)保持與 DOM 解耦這樣經(jīng)過驗證的版本能直接抬升lift進真實代碼。適用場景的典型表述我不確定這個狀態(tài)機能不能處理 X 然后 Y 的邊緣情況。這個數(shù)據(jù)模型真的能表達……這種情況嗎我想在動手寫之前感受一下這個 API 應(yīng)該長什么樣。任何想按按鈕、看狀態(tài)變化的訴求。文件結(jié)構(gòu)自上而下的清晰層級標題 一句話說明這個 demo 讓你探索什么即第一步寫下的問題。這段說明要放在可見的引言區(qū)而不是只寫進代碼注釋——因為需要確保問題可被事后核查無論用戶是在旁觀看還是之后 AFK 回來。當(dāng)前狀態(tài)面板完整相關(guān)狀態(tài)以可讀的面板渲染帶標簽的字段而不是原始 JSON dump每次點擊后重新渲染讓變化可見在有助于非開發(fā)者跟上時標注剛才發(fā)生了什么。自由探索按鈕每個動作一個按鈕始終可用任何人可以任意順序戳模型每次點擊派發(fā)對應(yīng) action 并重新渲染。引導(dǎo)式演練guided walkthroughs一組場景每個場景一個標簽頁。每個標簽頁包含一段場景的通俗描述它建立什么情境、該觀察什么下方是該場景按順序要按的按鈕。每個步驟都是真實按鈕點擊執(zhí)行該動作并進入下一步。啟動演練會重置到已知初始狀態(tài)保證場景每次以相同方式運行。場景應(yīng)選擇紙上推理困難的情況快樂路徑、棘手的邊緣情況、一次應(yīng)該被判定為非法的嘗試。邏輯的四種形狀取決于問題類型純 reducer(state, action) state——動作是離散事件、狀態(tài)是單一值狀態(tài)機顯式的狀態(tài)與遷移——當(dāng)前哪些動作合法本身就是問題的一部分一組純函數(shù)作用于普通數(shù)據(jù)類型、沒有隱式當(dāng)前狀態(tài)、只有變換類或帶清晰方法面的模塊邏輯確實擁有持續(xù)的內(nèi)部狀態(tài)。核心紀律保持邏輯純凈——不碰 DOM、不碰document、內(nèi)部不放按鈕處理器。頁面調(diào)用模塊反向不成立。這是原型在其生命周期之外仍然有用的原因一旦問題得到回答被驗證的 reducer / 狀態(tài)機 / 函數(shù)集能獨立抬升進真實模塊。HTML 殼是臨時性的邏輯模塊不是。3.2 UI 分支幾個結(jié)構(gòu)迥異的變體一個浮動切換條詳盡的 UI 分支操作手冊見 UI.md。目標產(chǎn)物是在同一條路由上生成幾個結(jié)構(gòu)迥異的 UI 變體通過浮動的底部切換條和?variantURL 參數(shù)切換。用戶在瀏覽器里翻來翻去挑一個或從每個里偷一點然后把其余的扔掉。關(guān)鍵約束變體必須在結(jié)構(gòu)上分歧而不是顏色。三個微調(diào)過的卡片網(wǎng)格只是壁紙不是原型。變體盡量在真實頁面里渲染——真實頁頭、真實側(cè)邊欄、真實數(shù)據(jù)、真實密度——因為在真空中評判的變體永遠顯得不錯。兩種子形態(tài)強烈優(yōu)先子形態(tài) A子形態(tài) A改造現(xiàn)有頁面首選。路由已存在變體在同一路由上渲染由?variant搜索參數(shù)門控?，F(xiàn)有的數(shù)據(jù)獲取、參數(shù)、鑒權(quán)全部保留只有渲染子樹切換。即便原型針對的是還沒有頁面、但天然會住進某個頁面的東西dashboard 的新區(qū)塊、設(shè)置頁的新卡片、現(xiàn)有流程的新步驟也歸為 A——把變體掛載進宿主頁面。子形態(tài) B新頁面最后手段。僅當(dāng)原型對象確實沒有可寄居的現(xiàn)有頁面時使用例如全新的頂級界面或無法嵌入任何合理位置的流程。創(chuàng)建一次性路由時遵循項目既有的路由約定不要發(fā)明新的頂層結(jié)構(gòu)路徑或文件名里包含prototype字樣以便一眼可辨。提交到 B 之前先自檢真的沒有現(xiàn)有頁面可以嵌入嗎空路由會隱藏布滿真實數(shù)據(jù)時才會暴露的設(shè)計問題。兩種子形態(tài)的浮動切換條完全一致。四、UI 分支實操流程含可復(fù)制的切換器代碼4.1 第一步陳述問題并確定 N默認 3 個變體超過 5 個就不再是結(jié)構(gòu)迥異而開始變成噪聲所以上限是 5。在原型所在位置或文件頂部注釋里寫一行計劃例如設(shè)置頁的三個變體通過?variant切換位于現(xiàn)有/settings路由上。4.2 第二步生成結(jié)構(gòu)迥異的變體每個變體必須對照頁面目的與其可訪問的數(shù)據(jù)項目的組件庫 / 樣式體系TailwindCSS、shadcn、MUI、純 CSS……一個清晰的導(dǎo)出組件名如VariantA、VariantB、VariantC。變體必須在**布局、信息層級、主操作primary affordance**上真正不同。如果兩個草案過于相似用不要用卡片網(wǎng)格的明確指引重做其中一個。4.3 第三步接線——單一切換器組件在路由上創(chuàng)建一個切換器組件UI.md 給出了可直接參考的偽代碼需按項目框架適配// pseudo-code, adapt to the projects framework const variant searchParams.get(variant) ?? A; return ( {variant A VariantA {...data} /} {variant B VariantB {...data} /} {variant C VariantC {...data} /} PrototypeSwitcher variants{[A,B,C]} current{variant} / / );子形態(tài) A所有既有數(shù)據(jù)獲取保持在切換器之上只有渲染子樹按變體切換。子形態(tài) B/prototype/name下的一次性路由掛載同一個切換器。4.4 第四步構(gòu)建浮動切換條一個固定在屏幕底部居中的小條包含三件套左箭頭循環(huán)切到上一個變體可回繞變體標簽顯示當(dāng)前變體鍵若變體導(dǎo)出了名稱則一并顯示如B (Sidebar layout)右箭頭循環(huán)切到下一個變體可回繞。行為要求點擊箭頭更新 URL 搜索參數(shù)用框架的路由器Next 用router.replace、React Router 用navigate等使變體可分享、刷新后仍穩(wěn)定鍵盤←/→也能循環(huán)當(dāng)input、textarea或[contenteditable]獲得焦點時不得攔截方向鍵與頁面視覺明顯區(qū)分高對比膠囊、微妙陰影讓人一眼看出它不屬于被評估的設(shè)計在生產(chǎn)構(gòu)建中隱藏用process.env.NODE_ENV ! production或等價檢查門控防止一次意外的原型合并把切換條發(fā)給真實用戶。切換器放進單一共享組件兩種子形態(tài)復(fù)用放在項目共享 UI 通常所在的位置。4.5 第五、六步交接與收尾把 URL 和?variant鍵交給用戶。最有趣的反饋通常是我想要 B 的頁頭配 C 的側(cè)邊欄——那才是他們真正想要的設(shè)計。變體勝出后捕獲答案哪個變體、為什么然后把原型按 SKILL.md 的方式歸檔見下一節(jié)。收尾映射子形態(tài) A把勝者折疊進現(xiàn)有頁面從 main 中移除落選變體和切換器子形態(tài) B把勝者提升為真實路由從 main 中移除一次性路由和切換器。完整變體集合是一手資料所以它落在臨時分支上而不是垃圾桶——因為變體組件和切換器留在 main 分支會快速腐化并誤導(dǎo)后來的讀者。4.6 UI 分支反模式清單變體只在顏色或文案上有差異那是微調(diào)不是原型真正的變體在結(jié)構(gòu)上分歧變體間共享太多代碼共享Header沒問題共享Layout就破壞了意義每個變體應(yīng)能自由推翻布局把變體接到真實寫操作只讀原型沒問題若變體需要變更數(shù)據(jù)指向樁stub——問題在于應(yīng)該長什么樣而不是后端能不能跑把原型直接提升到生產(chǎn)變體代碼是在原型約束下寫的無測試、最小錯誤處理折疊時必須用正確方式重寫。五、邏輯分支的反模式與真相時刻LOGIC.md 同樣給出反模式清單別加測試——需要測試的原型就不再是原型別接真實數(shù)據(jù)庫——除非問題本身就關(guān)于持久化否則用內(nèi)存狀態(tài)別泛化——沒有萬一以后要支持 X原型只回答一個問題別把邏輯和頁面攪在一起——純模塊一旦引用 DOM、document或按鈕處理器就不可抬升了別上框架、打包器或服務(wù)器——單個可雙擊文件一個 React 應(yīng)用或 dev server 就毀了可分享別把 HTML 殼發(fā)到生產(chǎn)——頁面是為被人手工點擊而優(yōu)化的它背后的邏輯模塊才是值得保留的部分。交接時的真相時刻把文件發(fā)過去或幫對方打開讓他們點演練、自由探索。真正有價值的瞬間是當(dāng)他們說出等等這不應(yīng)該可能發(fā)生或咦我還以為 X 會不一樣時——那是想法本身的 bug而這正是原型的全部意義。如果他們想要新動作或新場景就加上原型是會演化的。六、原型是一手資料答案進 main證據(jù)留分支這是 prototype 方法論最獨特的一環(huán)完成后的原型留下兩樣?xùn)|西它們?nèi)ネ煌牡胤健４鸢附Y(jié)論 它所解決的問題被持久化捕獲一條 commit message、一份 ADR、或?qū)崿F(xiàn)工單。這是 main 分支保留的內(nèi)容——折疊進真實代碼。原型是答案來自哪里的可運行證據(jù)不刪除。但它同樣不屬于 main那里沒有需要維護它的東西而且它腐化得很快。因此它被提交到 main 之外的一個一次性分支prototype/name永不合并并在實現(xiàn)工單上留下指向該分支的上下文指針context pointer。main 保持干凈探索保持可查找、可重跑——無論下一個接手工作的人是誰。6.1 圍繞是否刪除的演進等等原型不是應(yīng)該刪掉嗎——曾經(jīng)確實如此構(gòu)建、保留答案、扔掉代碼。對這種做法最尖銳的反對從來與速度無關(guān)而是下一個接手的會話有什么可依據(jù)一份散文式總結(jié)會丟掉讓原型有說服力的東西。所以現(xiàn)在原型被當(dāng)作一手資料對待它落在 main 之外的prototype/name分支上實現(xiàn)工單指向它。改變的是代碼存放的位置不是紀律本身——它仍然永不合并進 main。6.2 那個終端應(yīng)用去哪了邏輯分支以前產(chǎn)出終端應(yīng)用現(xiàn)在改為產(chǎn)出單個可分享的 HTML 文件。原因很實際終端應(yīng)用只能由克隆了倉庫且裝了運行時的人驅(qū)動這恰好把原型最需要其意見的人排除在外——設(shè)計師、PM、知道狀態(tài)模型本該表達什么的領(lǐng)域?qū)＜?。而一個雙擊即開、可被郵件轉(zhuǎn)發(fā)的自包含文件任何人都能驅(qū)動。底層的純邏輯模塊不變它依然是可以抬升進真實代碼的部分。七、常見問題與邊界澄清Agent 在應(yīng)該實現(xiàn)的時候叫我/prototype。已知問題而且是個命名問題。prototype是個通用而有吸引力的詞對不了解流程的 Agent 來說一旦工單存在原型讀起來像顯而易見的下一步所以它會在設(shè)計已經(jīng)通過對話完全敲定的情況下被按名字推薦。如果你已經(jīng)知道要構(gòu)建什么下一步是 implement只有當(dāng)某個具體設(shè)計問題真正懸而未決、且對話解決不了時才動用原型。我應(yīng)該在構(gòu)建任何生產(chǎn)功能之前先原型整個應(yīng)用比如給潛在客戶演示嗎那是戴著本技能名字的另一種產(chǎn)物。這里的原型范圍限定為一個問題整個應(yīng)用是什么不是一個問題。全應(yīng)用原型沒有自然的停止點于是會靠慣性變成生產(chǎn)應(yīng)用清理永遠不會發(fā)生在原型規(guī)則下寫的代碼無測試、無錯誤處理會跑到用戶面前。需要銷售演示就把它當(dāng)作演示刻意構(gòu)建并明確說明其中沒有什么是生產(chǎn)級的需要解決設(shè)計問題就把范圍切到那個問題上。怎么在自己的會話里運行它原型生活在自己的目錄里會產(chǎn)生大量你不想留在提問線程里的上下文所以要在別處運行、只把答案帶回來。handoff 是雙向的橋梁——它把當(dāng)前會話壓縮成一份交接文檔供新的 Agent 繼續(xù)并在文檔中列出下一步應(yīng)調(diào)用的技能。這不是最快的燒 token 方式嗎可能是——如果你對能用對話回答的問題做原型或讓一個原型蔓延到整個功能。真正有意義的比較不是 token 對比零而是token 對比構(gòu)建了錯誤的狀態(tài)模型、等它有生產(chǎn)調(diào)用者之后才發(fā)現(xiàn)。把問題收窄、運行時間縮短開銷就始終成比例。八、它正在工作的標志驗收清單原型文檔 給出了可操作的驗收清單你能用一句話說出原型要回答什么問題而且它寫在 demo 頂部不只是在你腦子里一個不讀代碼的人能驅(qū)動邏輯 demo打開文件、按演練標簽頁里的按鈕、用自己的話描述所見有人說等等那不應(yīng)該可能發(fā)生或咦我以為 X 是這樣——那是想法的 bug而這正是全部意義所在UI 變體在布局和信息層級上分歧而不只是顏色和文案你收到的反饋是我要 B 的頁頭配 C 的側(cè)邊欄在一次會話內(nèi)得到回答——如果一天后你還在構(gòu)建它說明問題太大拆開它結(jié)束時main 包含決策且不包含任何原型代碼實現(xiàn)工單指向仍然持有原型的分支。九、技能生態(tài)prototype 在決策流水線中的位置從 README.md 和 skills/engineering/README.md 的技能分類看prototype是一個隨時可用的獨立技能reach-for-it-anytime standalone你切入它解決一個設(shè)計問題然后切出它同時也是另一套機制賴以運行的機器。9.1 最大消費者wayfinder它的最大消費者是 wayfinder。wayfinder 地圖由決策工單構(gòu)成而prototype是工單的四種類型之一另外三種是research、grilling、task用于阻塞性問題屬于這應(yīng)該長什么樣 / 這應(yīng)該怎么表現(xiàn)、任何討論都無法解決的情況。wayfinder 通過制造一個具體的可反應(yīng)物來提升模糊討論的保真度而本技能就是這個具體物如何被構(gòu)建出來。在 wayfinder 中原型工單是 HITL人在回路類型的原型工單由答案解決原型作為資產(chǎn)從地圖鏈接。9.2 上下游鄰居上游grill-me 與 grill-with-docs 回答可盤問的問題不可盤問的問題轉(zhuǎn)到本技能一行字的答案再回到訪談里。下游驗證過的狀態(tài)模型或 UI 方向成為 to-spec 的既定輸入。值得注意的是to-spec 的規(guī)范模板有一個針對原型的專門條款當(dāng)原型產(chǎn)出的代碼片段狀態(tài)機、reducer、schema、類型形狀比散文更精確地編碼了決策時允許在對應(yīng)決策中內(nèi)聯(lián)該片段并簡要注明它來自原型——但要裁剪到承載決策的部分而不是一份可運行的 demo。這正是原型即一手資料在規(guī)范環(huán)節(jié)的落點。兜底路由其他任何情況ask-matt 會在整個技能集合之上為你指路。十、如何在你的項目中落地該技能已存在于本倉庫安裝與使用方式如下本技能目錄位于 skills/engineering/prototype/按 README.md 的安裝說明可用npx skillslatest add mattpocock/skills把選中的技能文件復(fù)制進你的項目后按需修改Claude Code 用戶可用claude plugins install mattpocock-skills安裝整套受管只讀插件。對 Codex 等 Agent技能通過agents/openai.yaml僅含display_name: Prototype聲明接口。落地時建議先通讀三份核心文件SKILL.md總綱與公共規(guī)則、LOGIC.md邏輯分支、UI.mdUI 分支再結(jié)合 wayfinder、to-spec、handoff 理解它在整條決策流水線中的位置。最后的提醒一旦你發(fā)現(xiàn)自己開始加固某個原型——加測試、接真實數(shù)據(jù)庫、為一個以后可能會用到的情況做泛化——你就已經(jīng)停止了原型化。保持問題窄、運行時間短、產(chǎn)物可分享、答案落 main、證據(jù)留分支這六條紀律合在一起就是原型從燒 token 的臨時腳本變成工程設(shè)計的一手資料的全部秘密?！久赓M下載鏈接】skillsSkills for Real Engineers. Straight from my .agents directory.項目地址: https://gitcode.com/GitHub_Trending/skills13/skills創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考