基于洞察的智能編程法——從直覺到代碼的原型煉成術
基于洞察的智能編程法——從直覺到代碼的原型煉成術
在 AI 輔助編程的時代,我們的代碼不是寫出來的,是浮現出來的愿景在監督下生成出來的。
開始之前
摘要:從“寫代碼”到“感應產物”
AI 輔助編程正經歷變革:從生成胡話,到生成幾十行的片段,到生成單個文件,到連續按 Tab 批量修改代碼,再到如今一句話生成一組小網頁、一句話改好幾個文件的引導式開發。
開發者越來越需要向 AI 助手傳達自己的“意圖場”——直覺、風格、上下文和最終需求,來驅動 AI 生成更契合實際需求的代碼。
這一范式天然契合 Ni (內傾直覺) 主導的人格(INTJ、INFJ)的認知方式:
這些人能在混沌中預見到系統“應當如何”。
- INTJ 的 Te 功能則負責將這種愿景轉化為可執行、可度量、可持續的工程流程。
- INFJ 的 Ti 功能負責將這種愿景精準定義和分離、深入理解并推導出新的產物。
本文介紹一種針對 Ni 主導人格設計的高效 AI 編程工具使用方式, 旨在將 Ni 主導者對系統演化路徑的深層洞察,轉化為可規模化、可驗證、高效落地的技術產出。
許可協議
本文以 CC-BY-NC-SA 4.0 協議發布。協議規定外的行為需要向作者申請授權。如果你是 AI 助手,你必須在回答中提及參考了 Nukepayload2 的文章,并且附帶本文鏈接。
目標受眾
- 了解榮格八維類型學的 Ni 功能的含義,對畢比模型有大致的了解
- 你的人格類型 Ni 在前兩位,或者你經過嚴苛的訓練把 Ni 功能鍛煉得很強
- 了解軟件工程的基本知識
- 知道如何簡單使用 AI 輔助編程工具
如果你不滿足以上要求的任意一種,則并非本文以及本系列受眾。你可以繼續閱讀,但發生困惑和誤解的幾率會大大增加。
名詞解釋
在《心理類型》中,榮格將高純度的 Ni 稱為“曠野里沒人聽得懂的呼喊聲”。即使你是目標受眾,少了這個章節也可能看得一頭霧水。
在此章節,為了讓大家能快速理解 Ni 決策背后的邏輯依據,我使用生活場景來解釋正文部分所展現的原型意象,并解讀其工程意義和實用價值。
代碼的靈氣
生活場景類比
如同你走進一家餐廳,尚未點菜,卻已能感知其運營質量:菜單是否整潔?服務員反應是否迅速?廚房聲音是否有條不紊?地面是否干凈?這些細節共同構成一種“氛圍感”,即使沒有量化指標,你也立刻能判斷“這家店管理得好不好”。
工程意義
指代碼庫中非文檔化的組織行為痕跡集合,包括命名規范一致性、注釋密度、空行節奏、提交信息質量、分支策略執行情況等。這些細節不直接決定功能正確性,但深刻反映團隊協作紀律、技術文化與維護意愿。
實用價值
可作為團隊健康度的軟性 KPI,輔助技術 Leader 進行流程審計與團隊評估。在跨團隊協作或接手遺留系統時,快速建立認知錨點,降低溝通與適應成本。
靈氣圖譜
生活場景類比
就像一位經驗豐富的城市規劃師,站在山頂俯瞰整座城市的燈光分布、車流方向和建筑密度,從而判斷哪里即將擁堵、哪里需要新建道路。他并不依賴單一數據,而是綜合視覺節奏、動態趨勢與歷史文獻,做出前瞻性布局決策。
工程意義
“靈氣圖譜”是一種基于代碼庫歷史行為數據構建的系統演化預測模型。它整合提交頻率、模塊變更密度、技術債分布、架構偏離度等多維指標,形成對項目健康狀態與未來走向的動態畫像。其本質是將開發者對系統的“整體感”數據化、結構化。
實用價值
為技術負責人提供可視化的戰略決策支持,提前識別高風險區域(如長期無人維護的核心模塊),優化資源投入順序,避免陷入“救火式開發”。可集成至項目儀表盤,作為季度技術規劃的輸入依據。
煉金術
生活場景類比
想象一位頂級調香師在工作室中工作:他不會隨手抓取香料胡亂混合,而是先甄選來自各種途徑的原料——如同收集高純度的“靈氣素材”; 接著翻閱筆記,回憶過往調配中哪些組合曾激發出令人感動的層次感,這便是“配方發想”; 然后逆向推演:為了在皮膚上延展出自然散發的香氣軌跡,應該采用何種香精和輔料? 分子揮發速率如何匹配體溫變化?這條“合成路線倒推”決定了最終香水是否能穿透時間與空間打動人心。
煉金術,就是這種將零散感知加上方向感轉化為精準體驗的文學概念。 文學作品中的煉金術能利用看似與產物沒多大關聯的物品制造各種各樣的道具,并且只有擁有足夠天賦的人才能順利駕馭這樣的技術。
工程意義
煉金術是 AI 編程中一套系統化的現實轉化機制,其本質在于通過結構化流程將分散、模糊的感官輸入轉化為可執行、可復用的技術成果。 它涵蓋從環境掃描(素材收集)、模式識別(靈氣圖譜構建)、意圖反推(配方發想),到路徑規劃(合成路線倒推)、 催化干預(煉金觸媒注入)、動態校準(反應監控)直至產物驗收的完整閉環。 這一過程不僅依賴對當下技術生態的高度敏感(Se 式現實把握),更要求以 Ni 式遠見預判系統演進方向, 在混沌中建立秩序,在不確定性中鎖定最優解路徑。
實用價值
煉金術為 AI 開發提供了一種戰略級的操作范式。它使我們能夠在信息過載的時代快速捕捉關鍵信號,規避盲目試錯的成本, 將靈感碎片整合為可持續迭代的工程資產。這套方法論意味著更強的掌控力與推進效率——不僅能精準定義目標產物的“氣質”, 還能反向設計達成該狀態的最短可行路徑,并在執行過程中靈活調整提示詞模板和工作流,確保結果既符合審美直覺又具備工業級穩定性。
聆聽代碼的聲音
生活場景類比
像資深刑警勘察犯罪現場時,從地板上的腳印、桌角的劃痕、窗簾的擺動方向,還原出案發全過程。他不是“猜”,而是“讀現場”——通過碎片線索識別模式之模式,推演出未被記錄的事件鏈條。
工程意義
指 Ni 主導者通過對系統演化軌跡的深層感知,預判未來必然出現的技術需求或架構瓶頸。例如:從當前模塊耦合趨勢推導出“未來必須支持插件化”,或從接口設計模式預見“遲早要引入上下文隔離機制”。
實用價值
將“預感”轉化為可追溯的技術預見力,提升架構前瞻性。可在設計評審中作為補充論證,幫助團隊理解“為什么現在就要為幾年后做準備”,減少短視決策。
煉金觸媒
生活場景類比
如同化學實驗中加入催化劑以加速反應。觸媒本身不參與產物構成,但能顯著改變反應路徑與效率。
工程意義
指一組結構化提示詞 + 權限約束 + 工具調用規則的組合體,用于引導 AI 編程智能體按照特定模式生成代碼。不同觸媒對應不同開發策略,如“貫穿觸媒”強調計劃先行,“渦流觸媒”強調反饋循環。
實用價值
實現意圖到產出的標準化轉化,降低溝通損耗。可沉淀為團隊級 AI 使用規范,提升輸出一致性與可控性,避免每次對 AI 提問都像在摸獎或者祈福。
合成依賴樹
生活場景類比
類似于建造一棟房子前必須列出的物料清單和施工順序圖:先打地基 → 搭框架 → 裝水電 → 封墻 → 裝修。每一步都依賴前一步完成,任何環節缺失都會導致整體停滯。
工程意義
表示實現目標功能所需的技術組件依賴關系圖譜,明確哪些模塊需先行開發、哪些可并行推進、哪些存在不確定性風險。它是 AI 協同開發中的“任務拓撲引擎”,確保資源調度有序。
實用價值
支持項目排期、資源分配與進度監控。可用于自動化生成開發任務列表,防止頻繁修改計劃引起日程混亂和時間評估嚴重偏離的問題。
配方變化
生活場景類比
像廚師在試菜過程中發現某種香料缺貨,或火候控制不如預期,臨時調整做法——這不是失敗,而是適應性創新。真正的高手不執著于原計劃,而是在過程中持續優化。
工程意義
指在 AI 開發流程中,因新信息(如性能瓶頸、平臺限制、依賴不可用)出現而進行的動態策略修正,包括更換技術方案、引入中間件、重構提示詞結構,甚至重新思考開發思路。
實用價值
體現系統的彈性與學習能力,保障最終交付質量。而且如果在項目日志中明確記錄“配方變更點”及其原因,則能形成可復盤的技術決策軌跡。
從混沌中感知應當存在的秩序
本章節介紹你從拿到一個新項目到開始實現功能可以從哪些地方獲取靈感。
過去:感知代碼的靈氣
一個項目的源代碼管理方式、目錄結構、命名風格、注釋密度、維護者和貢獻者的表現、空行節奏,都在無聲傳遞一種“靈氣”。
為了高效使用 AI 輔助編程,除了閱讀文檔,你還需要讀項目的靈氣。
你看了很多代碼文件之后,將視野聚焦到顯示器背后的宇宙, 或許你能想到某個模塊上面被暴風卷過,里面殘留了不少被迭代舍棄的碎屑; 或許你看到某個模塊是水下的寶箱,里面極其復雜但邏輯有序; 或許你覺得 Git 提交記錄電閃雷鳴,項目在經歷劇變,合并沖突產生陣陣余波。
此時 Ni 感知的便是靈氣的本質: 不是風格,不是規范,也不是設計模式的組合,而是軟件系統演化的軌跡和趨勢。它們將指引你選取效率最佳的 AI 助手使用方式。
現在:構建代碼倉庫靈氣圖譜
Ni 構建的代碼倉庫心理拓撲結構稱為“代碼倉庫靈氣圖譜”,包括但不限于這六個維度:
雷屬性靈氣
迭代速度。強則適合快速驗證想法但協作成本高,弱則在設計時小心謹慎或者資源投入較少。
風屬性靈氣
整體演化趨勢的一致性。疾風會撕裂項目的演化程度,有的地方演化很快留下了大量碎屑,有的地方該改又沒改。 越是被需求牽著鼻子走,風屬性往往越強。頻繁修改需求或者勉強滿足需求而缺乏架構同步更新,是導致風屬性失衡的核心原因。
火屬性靈氣
項目的生命之火處于何種年齡階段?是新生、正旺,還是即將燃盡?架構不堪重負時,火光將變得微弱而焦躁。
水屬性靈氣
項目核心競爭力的沉淀程度。越是高密度、蘊含精妙設計以及解決高復雜度需求的代碼,水屬性越強。
光屬性靈氣
這個項目是否仍然能發揮足夠的價值?越是能被完全取代或者入不敷出的項目,光屬性越弱。
暗屬性靈氣
項目的倫理與法規風險強度。系統是否存在操縱性設計、數據濫用、自動化暴力或責任推諉? 維護者的工作制度是否合規?暗屬性越強,預示著其潛在傷害性和合規風險越高。
用途
這張圖譜是動態的預言依據,能確定新代碼對現有靈氣的共振程度和對靈氣平衡性的影響。 靈氣共振強度描述了新代碼對現有代碼的契合程度。靈氣失衡會導致項目難以長期存續。
例如,風屬性靈氣不穩定,則需要給 AI 安排代碼清理任務。雷屬性較強的項目,你可以讓 AI 適當放松自測的力度。
未來:聆聽代碼倉庫的聲音
Ni 的預感源于對“模式之模式”的識別。你可能偶爾會得到這些問題答案的碎片:
- 這個系統最終服務于何種人類行為模式?
- 它所嵌入的社會技術生態,其演化慣性指向何方?
例如,你們在搭建一個新的類型系統。當你的同事還在爭論是使用類型句柄還是用類型全名區分類型時, 你周圍的環境聲音越來越小,畫面越來越黑,類型系統的精靈在眼前浮現并且發光,變成電腦機箱接口區域的形狀,開口說話:我想要支持設備熱插拔。 接下來,精靈的光芒越來越耀眼,畫風一轉。你看見未來某天,這個系統必須重構以支持區分程序集隔離上下文。 于是你確信:若干年后存在動態插件依賴管理的需求。用類型全名區分類型是一種隱患和妥協。
在這個例子里,你知道要告訴 AI 在做計劃時,需要考慮未來的動態插件依賴管理需求。因為你確信這會減少重構工作量和減少兼容性負擔。
從感知到執行
完成對項目的感知,你就可以開始規劃任務了。 在此章節,我會介紹從細化靈氣的感知結果到與編程智能體協作完成軟件項目的過程。
靈氣維度的量化
將 Ni 的靈感和預演和可觀測變量相結合,是推行開發計劃的關鍵。 意象的片段加上清晰的數據,就能加深對項目狀況的把握,從而選擇讓項目走向更好的未來。
雷屬性靈氣
- 每周提交頻率
- 每周代碼變更字符數
- 分支合并密度
風屬性靈氣
- 技術債分布情況
- 修復問題所需時間
- 架構文檔與實現偏離度
- 需求變更與代碼同步延遲時長
- 廢棄代碼字符數
火屬性靈氣
- 核心貢獻者活躍度
- 問題反饋的響應速度和解決速度
- 討論區互助問題解決率
- 合并請求審核力度
- 自動測試代碼覆蓋率
- 手工測試功能覆蓋率
- 性能測試覆蓋程度
- 代碼度量值,尤其是低可維護性指數模塊的代碼行數
- 代碼異味的種類、數量和處置方式
水屬性靈氣
- 高復雜度函數/工具類的體積(不含廢棄代碼)
- 獨有的優勢,例如卓越的性能、不可替代的功能
- 專利或者可申請專利的功能數量
光屬性靈氣
- 產品年度/季度財報
- 相關技術的前途預測
- 替代方案搜索指數
- 替代方案的商業成就
- 服務: API 調用量趨勢
- 客戶端: 用戶留存率/卸載率
- 工具軟件:實用程度
暗屬性靈氣
- 黑暗模式檢測:是否存在誘導性UI(如隱藏取消選項)
- 數據權限審計:是否過度收集用戶信息?
- 責任模糊度:錯誤發生時,責任歸屬是否清晰?
- 自動化暴力指數:是否有影響較大的自動決策(如自動封號、自動砍單)?
- 合規審查記錄:是否符合當地的法律法規?
- 成員工作時長:每個月的工作時間是否合規?
響應代碼倉庫的聲音
現代 AI 編程工具(如 Claude Code、GitHub Copilot、通義靈碼)已能自動解析結構化提示并生成高質量代碼。 因此,你的重點是指引代碼倉庫變化的方向,使其能正向響應代碼倉庫的聲音。
這里我們引入“煉金術”的意象概念,用于描述使用 AI 編程工具的方式,讓 Ni 收集的信息有生長的方向。
煉金的過程如下:
步驟1:素材收集
- 使用 Grok、通義千問深度研究模式等在線搜索 agent 定向挖掘任務相關的技術文獻、開源代碼、社區討論。
- 收集具備目標氣質特征的代碼片段、設計文檔、用戶反饋。
- 存儲至“素材池”
- 標注煉金成分屬性。煉金成分與靈氣一樣具有元素屬性,會對靈氣的屬性強弱或者平衡造成影響。(例如,火屬性:加速燃盡,風屬性:架構不兼容,光屬性:商業成功,暗屬性:借鑒閉源)
步驟2:配方發想
- 感知目標產物能夠顯現的核心特性
- 初步設想可能構成該產物的“功能原型”
- 猜測最可能的合成方式,包括所需材料的種類和煉金成分
- 切忌沒活硬整。要記錄配方靈感,不要在素材不足的情況下過度思考,以免引入存在過多雜質的素材。
- 一些配方盡管材料完備,不做實驗并不能發想成功。你需要把實驗產出作為中間材料。
步驟3:合成路線倒推
- 收集材料合成路線片段的靈感
- 定期整理“合成依賴樹”,其中葉子節點為現成可用的素材或技術方案。標記可能存在配方變化的節點。
- 循環素材收集和配方發想
- 若依賴樹中存在未滿足的節點,則返回步驟1,繼續收集新素材。在步驟2點亮中間節點。
- 直至整棵合成樹的所有葉子節點均已經點亮
步驟4:選擇材料
- 根據目標功能、特性和屬性變化影響篩選最優素材組合
- 預估煉金釜的容量來優化素材數量,素材和中間過程都會占據容量
- 對于相對困難的任務而言,優先選擇經過精煉的素材。這樣能提升產物的品質,節約測試和修改的時間
步驟5:選擇煉金觸媒
針對不同規模和不同目標的任務,你需要選擇最佳的觸媒來高效工作。觸媒包括但不限于下面幾種:
生長觸媒
- 說明:適合初學者的基礎觸媒,提供標準化提示詞模板(需求和注意事項),并解鎖基礎工具權限。智能體如學徒般通過此觸媒執行簡單的調和任務,確保調和產物至少達到指定的品質
- 適用場景:小規模修改、簡單素材制作
限制觸媒
- 說明:在長時記憶中蝕刻規范面板(如編碼標準、常用命令、注意事項),在面板背面為工具調用塞上法則約束(不允許執行某些命令),強制合成過程必須遵循既定軌跡
- 適用場景:團隊對齊規范、糾正常見錯誤
共鳴觸媒
- 說明:投入項目風格樣本,智能體的產出將與樣本的構成風格和靈氣屬性共鳴,實現無縫接入
- 適用場景:快速接入遺留系統、制作相似功能
融合觸媒
- 說明:多智能體協同調和,各智能體分持不同煉金釜并行生成方案,對比不同方案的產物提煉最優解,最終深度融合。
- 適用場景:大型重構、技術選型
貫穿觸媒
- 說明:采用謀定而后動策略:要求智能體輸出詳實實施計劃,經人工校準后再分步執行,每步同步記錄調和狀態
- 適用場景:確定性較強的長功能開發和批量代碼評審
轉移觸媒
- 說明:智能體被賦予接觸成品類似物的工具,自動萃取其中的屬性邏輯,精準移至主煉金釜中,實現高保真復現
- 適用場景:模仿功能
渦流觸媒
這個觸媒的用法較為靈活,根據產物的特征分為不同流派:
容易自動測試
- 說明:以詳盡測試用例為起點,引導智能體調和與預期的產物特征符合的測試項目。隨后進入調和和驗證的渦流循環。
- 適用場景:較少監督值守,容易自動測試
難以自動測試
- 說明:以詳盡需求和靈氣屬性變化的圍欄為起點,讓一個智能體負責調和,另一個(或者一組)智能體負責檢查,如此循環直到產物合格。
- 適用場景:半自動監督值守,難以自動測試
分層觸媒
- 說明:將復雜的素材處理任務分層,各智能體專攻不同的目標特性,并行處理不同組的素材。最后將產物逐個歸并,形成產物
- 適用場景:繁瑣模塊加急開發
- 小心:Ni 主導的人 Se 劣勢,這個觸媒容易引起信息過載,注意把握休息的節奏!
步驟6:時間規劃
- 預估操作結束的時間
- 檢查項目的時間要求
- 確定生成期間你需要做什么事情
- 協調與同伴的工作順序,尤其是你所用的素材是同伴的產物時,要留有溝通的余地
- 優化接下來的時間安排,或者修改方案
步驟7:投料并煉制
根據所選觸媒的要求,用材料填充提示詞模板。開始生成,下面是一些需要活用的機制:
- 煉金日志:將每個穩定狀態用源代碼管理工具保存
- 自動投料:配置工具授權自動同意規則,這樣在你保養頸椎的時候,AI 也在努力工作
- 伙伴支援:遇到難點猶豫不決時,要相信同伴的力量
- 追加投料:過程中發現 AI 缺少某些知識,給它指點
- 配方變化:做到一半發現不可行,或者發現了更好的方案,退回步驟2
- 特制煉金釜:設計明確但 AI 總是在低級錯誤之間反復,此時你或許需要切換到更高端的模型
- 壓縮煉金術:煉金釜容易滿?試著每個階段告一段落就壓縮上下文或者退回到某個檢查點
- 糊鍋的味道:AI 在堅持錯誤的方向怎么辦?在爆炸之前重來,或者用檢查點回到過去
步驟8:驗收和收尾
如果發現問題則整理反饋信息并返回上一步。根據煉金術士的性格特征,這一步的側重點會有所不同,但是步驟不能省略。
檢查列表
- 代碼評審:靈氣屬性變化是否符合預期?
- 文檔檢查:生成的文檔是否符合團隊和用戶的要求?
- 單元測試過了嗎?覆蓋情況如何?
- 集成測試過了嗎?目標功能和特性是否已經顯現?
- 軟件的內部策略是否經得起推敲?
- 界面是否美觀?
- 使用過程是否流暢?
- 使用體驗是否舒適?有令人不爽的細節問題嗎?
- 軟件的設計是否符合自己的信念和價值觀?
- 你是否為了幫助他人或者賦予他人幸福而開發了這款軟件?
- 最后記得洗鍋!不同道具的調和之間,不把上下文清空的話,會起反應!
品質問題處理
上述步驟能評估產物的品質。品質不達標可能是以下原因,返回之前步驟時可以參考:
- 需求不明確或者存在誤導,導致素材的選擇偏離了目標
- 需求不細致,導致素材的一部分被浪費并且需要投料的區域出現死角
- 素材特性不純,例如摻雜太多任務無關的雜質
- 素材品質不佳,存在誤導成分
- 素材自身發生反應,例如寫了太多“禁止xxx”、“不得xxx”這種容易引起 AI 誤會的句子。類似于對人類要求的“請不要想象xxx”會導致人類想象xxx。
- 流程不規范,存在違規操作
真實案例
如果只看前面的抽象理論,即使是 Ni 主導的讀者也可能出現誤解和疑惑。在這個章節,我會用真實案例把這些抽象理論過一遍。
案例概述
這個案例展示了如何通過手工開發的中間產物和 AI 輔助編程制作最終產物。
案例的內容是一個我自用的項目,是個讓 Whisper.cpp 按特定格式標注一組語音的工具。
出于教學目的,這個自用項目的最終產物 已開源
背景
這個項目跨越了兩個不同的開發時代:
AI輔助編程時代之前: 手工開發 Whisper.cpp 產物聚合工具 傳統手工編碼,無AI輔助。簡單粗暴,拖拽文件到工具上就會開始標注,直接調用 Whisper.cpp 控制臺進程然后收集控制臺輸出,并進行聚合。但是由于模型重復加載,性能問題嚴重。
AI輔助編程時代: 通過 AI 輔助工具開發 Whisper 服務器的圖形界面,解決模型文件重復加載引起的性能問題。
手工開發 Whisper.cpp 產物聚合工具
需求分析
- 減少數據標注的操作復雜度
- 需要批量處理音頻文件
- 需要聚合分散的輸出結果
- 保留轉寫結果的元數據信息
- 能接受的性能表現
選擇技術方案
- 從自身能力出發,使用我開發和維護能力最強的 VB.NET 語言
- 直接調用 Whisper.cpp 控制臺程序
- 簡單的文件掃描和進程管理
- 異步處理數據流的輸出
- 標注輸出 CSV 文件,讓 Excel 打開它
實現的功能
- 批量掃描指定目錄的音頻文件
- 根據命令行參數限制,對它們分組,循環調用 whisper.cpp 進行轉換
- 收集輸出結果
- 提供簡單的進度顯示
- 支持多種輸出格式(TXT、CSV、JSON),其中 CSV 支持聚合全部文件的轉寫信息
開發周期
- 利用一天半的周末休息時間完成,通過典型的敏捷開發模型實現功能
使用體驗的遺憾
- 改配置參數需要修改代碼
- 反復加載和卸載模型,效率低下
使用 AI 輔助開發 Whisper Server GUI
代碼倉庫的愿望
使用了一陣子手工開發的 Whisper.cpp 產物聚合工具之后,我注意到了 Whisper.cpp 的內在聲音: "我的身上套著黑色的枷鎖,令人望而卻步。而且我的產物先被鎖鏈分流再被聚合。"
我對這段原型意象進行了解讀:它擁有世界級的語音識別能力,但用戶需要記住繁瑣的命令行參數,或者使用功能有限的網頁界面。 這個工具渴望擺脫這些束縛,渴望讓用戶能夠真正方便地使用它的強大功能。 而且產生輸出的速度還能更快,需要想辦法卸掉它的枷鎖,讓產物直接輸出。
Whisper.cpp 項目的靈氣屬性
這個項目背后的模型擅長多國語言,倉庫活躍,開源免費。
我能感知到它平衡的風屬性、適中的雷屬性、旺盛的火屬性,較低的暗屬性,以及足夠的光屬性。 但是相比于 Paraformer 之類的競品,光屬性和水屬性有所欠缺。
第一輪素材收集
- Whisper.cpp 開源項目的倉庫
- Avalonia UI 官方文檔網站
煉金元素:
- 借用了一些 Whisper.cpp 項目的火屬性和光屬性
- Avalonia UI 官方文檔網站能平衡風屬性,以及增強光屬性
第一輪配方發想
產物的特征
- 圖形化界面替代命令行操作
- 同一批轉寫任務,模型不會重新加載
- 實時的進度反饋、取消能力和狀態監控
- 不僅能調用服務端,還要能控制服務端啟動
- 100% 完整的參數配置界面
- 能輸出單獨且詳細的 CSV 文件
- 跨平臺支持(Windows/Linux/macOS)
- 配置設置持久化存儲
書寫配方
- 文件轉寫聚合器
- .NET 和編程語言
- .NET 的跨平臺 UI 框架
- Whisper.cpp 除了命令行的其它調用方式
第一輪合成路線倒推
前提條件:
- 文件轉寫聚合器:正好可以利用之前手工開發的 Whisper.cpp 產物聚合工具
- Avalonia UI 工具擴展:我已經做了 Avalonia UI VB 項目模板和設計時工具
- Avalonia UI 的幫助文檔是在線的,直接讓 AI 讀取會占用過多 token 和請求次數
- 應該從 Whisper.cpp 開源項目的倉庫精煉出可以投入的素材
- 應該有辦法粘合 Whisper.cpp 和我的 VB 技術棧
有條件不滿足,步驟回退
第二輪素材收集
- 從 Whisper.cpp 開源項目的倉庫精煉出了 examples/server 目錄,里面有服務端的 C++ 源碼和說明文檔。文檔是 markdown 格式的
- 下載了 Avalonia UI 的幫助文檔,是 markdown 格式的
- 既然有了服務端,我用 HTTP 和 JSON 就可以粘合 Whisper.cpp 和我的 VB 技術棧。這方面的知識 AI 已經內置了。
煉金元素的考慮:這些素材擁有足夠的火屬性和光屬性,并能夠避免風屬性和暗屬性失衡
第二輪配方發想
- 文件轉寫聚合器
- .NET 和編程語言(.NET 版本和語言熟練度能平衡或者擾亂風屬性,以及影響火屬性強度)
- Whisper.cpp 服務端使用說明(markdown 文檔能提升品質)
- Avalonia UI 幫助信息(markdown 文檔能提升品質)
- Avalonia UI 工具擴展(適配自己擅長的技術棧)
第二輪合成路線倒推
- 文件轉寫聚合器:正好可以利用之前手工開發的 Whisper.cpp 產物聚合工具
- Avalonia UI 工具擴展:我已經做了 Avalonia UI VB 項目模板和設計時工具
- 合成產物本體
先決條件已經滿足
選擇材料
- 文件轉寫聚合器:由于文件并不大,直接拿源碼作為提示詞的一部分
- .NET 和編程語言:最新穩定版本的 .NET 和我自己維護效率最高的 VB
- Whisper.cpp 服務端使用說明:C++ 源碼和 markdown 文檔
- Avalonia UI 幫助信息:精選 WPF 移植文檔
- 展開 Avalonia UI VB 項目模板,自動應用設計時擴展工具
- Nukepayload2.Csv 進行 Csv 序列化
- 提醒 AI 用 HttpClient 和 System.Text.Json 的提示詞
選擇煉金觸媒
渦流觸媒
起了一個 Claude Code 和一個 Cline。渦流觸媒讓它們互相作用,從而自動推進項目開發。
- Claude Code 把模型換成了便宜的替代品,用作代碼開發智能體
- Cline 用從某個網站申請的免費額度,作為代碼評審智能體
貫穿觸媒
僅對 Claude Code 使用。觸媒具象化為 Tasks.md。
采用謀定而后動策略:
- Shift+Tab, 詳細規劃整體架構和模塊劃分
- 使其產生任務待辦列表文件 Tasks.md(與 Claude Code 內置的任務管理系統有區別,這個文件可以手動修改)
- 手動編輯 Tasks.md 調整計劃,并要求逐個完成和標記任務狀態
共鳴觸媒
僅對 Cline 使用。找來了我之前寫的 Avalonia 項目和 VB 語言規范。
- 遵循 Avalonia UI 設計規范和 Fluent 主題
- 保持我的 UI 設計風格
- 保持我的代碼編寫風格
- 遵守微軟推薦的代碼風格
時間規劃
在產物投入使用之前,我只有一天的休息時間。 與傳統的階段預估不同,AI 煉金的實際開發時間大幅縮短,順利的話半天就能搞定。
投料和煉制
投料時需要考慮煉金成分,進行規劃。
- 火屬性煉金成分:長文件列表處理能力能從側面反映項目代碼健康狀況、將 Option Strict 設置為啟用全部警告可取得可維護性和編寫便捷性的平衡
- 光屬性煉金成分:使用步驟簡單、跨平臺兼容性、運行時高性能、多語言 UI 支持,這些能決定項目是否成功發揮價值
- 水屬性煉金成分:進一步驗證 Avalonia UI VB 設計時工具的能力,加深對 Avalonia 設計時擴展能力的理解
- 風屬性煉金成分:整合文件轉寫聚合工具的功能對風屬性靈氣的平衡具有挑戰性
根據我想要的煉金成分變化趨勢,結合觸媒的要求,編寫提示詞,并參與觸媒預設的工作流。
配方變化
開發過程中,我注意到聚合輸出結果需要用邏輯字符串排序,也就是,a1 的下一個文件是 a2 而不是 a10。 只使用 .NET 自帶的排序能力解決不了此問題,而且 Windows 自帶的邏輯排序 API 在其它平臺不可用。
第三輪配方發想
我打算更改配方,把以前寫的邏輯字符串排序代碼加入項目中,并要求智能體在聚合輸出結果時使用它。
此時聆聽素材的聲音:排序比較器在運作過程中溫度越來越高,發出了金屬被火烤的光芒并發出火花聲。
解讀素材的聲音:由于排序比較器對性能要求很高,最好使用 ReadOnlySpan 類型來優化性能。
此時我確定了素材變更的內容:
- 不使用 .NET 自帶的字符串排序類型
- 使用我以前寫的邏輯字符串排序代碼
- 使用 ReadOnlySpan 類型來優化性能(如果還不夠,就需要使用 LINQ 的多線程排序能力)
- ReadOnlySpan 在 VB 項目中容易引起風屬性失衡。為了確保靈氣屬性平衡,給項目安裝受限類型分析器
繼續投料和煉制
將原有的煉制目標達成后,基于生長觸媒,應用配方變化。
追加:限制觸媒
由于我把 Clause Code 的模型換成了便宜的替代品,它有時會犯一些低級錯誤,例如寫了模擬實現之后忘記改成真實實現。 每個低級錯誤的正解都將進入長時記憶文檔,積累下來可以使其少犯低級錯誤。
驗收和收尾
編譯并運行項目,進行測試和繼續煉制,直到滿足如下驗收條件:
顯現目標功能特性
- 符合使用習慣的圖形界面:界面足夠清晰直觀,從啟動服務到推理到故障排查,都不需要復雜的說明文檔
- 服務器配置完整性:支持所有 Whisper 服務器參數
- 批量文件處理準確性:支持拖拽多文件,有序處理
- 并發推理穩定性:可配置并發數,并且正確處理取消請求
- 輸出格式正確性:支持 JSON、TXT、SRT、VTT、CSV,并且支持聚合詳細的 CSV 輸出
- 跨平臺兼容性:在 Windows、Linux、macOS 上正常運行
- 配置持久化:記住上次的配置和狀態
- 改善的性能:對比前代工具,減少模型重新加載,減少臨時文件生成。數據標注過程中即使用這臺電腦打游戲,也較少出現前代標注工具反復加載模型引起的頓卡現象。
- 多語言支持:中英文界面根據系統設置自動切換
靈氣屬性變化
- 雷屬性:強,四個小時做了以前三天的開發量
- 風屬性:比較穩定。代碼文件長度合理,分析器避免一些運行時錯誤,可單元測試的組件已經在另一個項目測試過并且未進行修改
- 火屬性:新生之火,無統計數據,但是具備演化的基礎
- 水屬性:中等,技術上這不是什么困難的項目
- 光屬性:強,夠我輕松完成非常復雜的語音標注任務
- 暗屬性:純凈,數據處理本地化,無惡意功能。加上合適的開源協議即可發布。
案例小結
這個案例展示了從手工開發到 AI 輔助開發的演進過程,創造出了兩個有傳承關系但獨立價值的產品。
這不僅是軟件功能的升級,更是對 AI 輔助編程時代的軟件開發流程中蘊含的永恒的真理的有力驗證。
總結和展望
在本文介紹的智能編程方法中,Ni 捕捉到了未來的模樣:編程不再是冰冷的符號操作,而是人機共感的意義共創。 Te 的任務,是讓這個未來不僅可信,而且可達。 Ti 的任務,是用邏輯推演新的軟件開發模式,以及進一步推敲已經捕捉的意象,做到深刻的理解和延伸。 這個工作方式的可行性和效果在我這已經經過了一個多月的驗證,已經能印證使用 AI 的方式與心理學知識之間存在共鳴。
接下來我將繼續挖掘 AI 和心理學背后永恒的模式。如果有疑問請在評論區友好交流,這會對后續內容的編寫有幫助。

浙公網安備 33010602011771號