以規格來開發應用，規格之外的重點是什麼？以實做微軟研究院的 Claimify 主張提取器為例
我想，開好規格，然後一次性就完成心中的應用，應該是大家夢寐以求的目標。
最近剛好有兩個專案，一個是透過 OpenSpec 來進行規格開發；另一個則是因為最近招生過程中，有一位學員的需求，讓我最近都在探索「如何做好事實查核」這件事。追到最後，發現有一個最根本的基本功夫：要先把內文中所有內含主張（Claims）的句子都分析好，才能夠進一步做到所謂的查核動作。所以我翻找了一下目前最新的研究動態，然後找到了微軟研究院所提出的 Claimify 分析流程以及分析框架。
仔細閱讀一下它的分析過程，個人覺得還不錯，整個處理過程清晰，而且處理了一些重要的動作。最重要的是，評估框架也有了，驗證資料集也提供了，所以要拿來作為使用 Agentic Coding 的重要素材都有了，可以讓我專注在實驗：可以如何用最「輕鬆」的方式，一溜煙地把處理程序甚至最後的展示內容就生成好了。所以就決定拿它來開刀，順便以最近另一個常被討論到的 Matt Pocock 的 Engineering Skills 來實做。
最後實做的成果，其實第一眼看來真的滿驚豔的，大家可以看到本文分享的那個頁面，就是它最後生成的 codex sites。但是仔細看，其實有蠻多問題的，這個也是我這次除了理解 Matt Pocock 的設計理念之外，第二個讓我印象深刻的 lesson learned。下面就來跟大家分享：
這個過程中，我第一個收穫最大的是 Matt Pocock 對於他 skills 的設計精神。大家有沒有想過，我們不論是自行撰寫程式碼，又或者現在已經提升為提供規格來讓強大的 AI 幫我們自動撰寫程式，表面上速度變快了，但是還是有很多地方搞不好；又或者，其實快歸快，但好像遇到的是新的、不知道該怎麼解才好的問題；又或者修了左邊又壞了右邊，怎麼修都修不好。最根本是什麼原因，又如何處理呢？
難處一、人們永遠都搞不清楚自己要什麼
Matt Pocock 的 Skill 中有兩個最經典的指令，一個是 /grill-me，一個是 /grill-with-docs，直接用中文來理解就是靈魂拷問。為何要有這個指令？而且這個也是作者最推薦大家使用的指令之一。
所以這個指令可以作為你開發系統的第一個動作。像我這次實做 Claimify，其實觸發指令很簡單，就是：
/grill-with-docs 我想實做這個文獻裡面提到的，文獻主張提取功能。{claimify 文獻檔案}
為何這樣有效？其實就是透過讓 agent 主動提問，來對齊雙方對於目標 & 過程中的想法。
難處二、Agent 的訊息太過於囉嗦
大家有沒有發現，尤其是我們帶著一個新的專案和 agent 討論時，一開始需要交代很多的知識背景，有時候甚至一個概念雙方有些許的誤差，所以會需要去溝通那個概念確實的含義，也就是定義的問題。
這個其實也是我在第一點有提到的、我使用 /grill-with-docs 來啟動討論的原因。這個與 /grill-me 有何不同呢？兩者都會進行所謂的靈魂拷問，而 /grill-with-docs 有一個很重要的動作，就是在討論過程中，會幫我們建立類似【詞彙表】的東西，可以讓我們事後對某個特定概念有相同的定義。
難處三、最後生成的程式碼，還是會壞掉
就算我們與 agent 在實際動手實做程式碼之前，同步了再多的概念 & 想法，實際實做的過程，總是還是會有壞掉的可能。在這裡我們不深入思考有沒有可能將所有該定義的、討論到的都交代清楚，然後一次達到要求；不過有一個最基本可以做到的是，不要一次把要做的事情定義得太過於龐大，大到不可控。我們應該將細節控制在小而且有針對性的目標，然後透過回饋驗證的機制，確保小步邁進。
關於這個難處，Matt Pocock 的 skill 內提供了 /tdd 的指令，可以幫我們透過一種回饋循環機制，讓我們整個程序的生成，不是只是生成程式碼，最後也會自動帶上自動化測試。
這個也是我當初認為 Claimify 這個文獻很適合拿來實驗的原因，因為測試的資料集都已經完整提供給我們了。實際運作時，也有看到 Matt Pocock skill 的確很盡責地設計 & 代入測試案例。
只是，後來仔細看，測試案例的設計其實有點不盡理想。不過怎麼做得更好，會是題外話了，今天就暫且不談。
最後一個、我們最終建造了一團【爛泥】
我想有實際使用過 agentic coding 的朋友，應該對【建造了一團爛泥】會很有感。
AI Coding 加速了軟體撰寫的速度，複雜度也是以前所未見的速度在增長。這個難處的解決之道是，採用以 AI Coding 概念為核心的全新開發方法；簡單來理解，就是我們應該更加關注這些程式碼更之前的【設計】。
這一點，在我這次的實驗就更有感了。
就像我開頭提到的，這次實驗的成果，初步看起來很驚豔，但是仔細看實做的細節，自己才發現，這是什麼鬼？
非但整個預設的操作過程看起來好像很複雜，而且畫面上的表達，也看不出有仔細揣摩過需求；AI 使用的測試資料，其實也與原意有不少的出入。
最後我也才深深體會，果然規格開發也是垃圾進、垃圾出。
你一開始用最籠統的【我想實做這個文獻裡面提到的，文獻主張提取功能。】來做觸發點，就是得到一個什麼都實做給你、外包裝看起來很華麗，但是不知道在表達什麼的成果。
那麼，最後最重要的心得是什麼呢？
下次你要想透過提供規格就得到符合你期待的成果的話，最少你要表達出：
- 你認為的重點是什麼
- 你想要表達的層面是如何
- 還有最重要的，需要遵守的原理原則為何
- 如果想線上查看實做的成果，或者下載最終的「主張提取」agent skill，你可以點擊這裡： https://claimlens-showcase.iyuyan.chatgpt.site
- 如果需要有人協助你釐清你的需求，並且實做你專屬的知識工作流原型，時間只剩下一個星期，請即刻填表申請：
https://forms.gle/VZYbbTW6Bymkk1iSA
