成為真正的AI Native Coder,一個研究生實踐6個月的思考!

Datawhale乾貨

作者: 郭子揚 研究生,東南大學研究生

問題意識研究生:我們誤以為使用AI不需要學習

22年年底,ChatGPT橫空出世,一個字一個字地流式回答使用者問題,展示了AI工具的魅力時刻研究生

隨後,圍繞如何最大化發揮ChatGPT這類AI工具的能力,業內開始研究Prompt Engineering、Context Engineering、Harness Engineering(近期),並做出一批又一批容易上手使用的AI產品研究生

這些產品使用體驗太新穎太人性化了研究生,以至於我們在使用過程中,很少想到問自己:

我會用這個AI工具嗎研究生

我會寫提問詞(Ai工具的輸入)嗎研究生

我有意識主動提供足夠的上下文(完成這次任務所需的資訊)嗎研究生

我會用這個AI工具嗎研究生

我會寫提問詞(Ai工具的輸入)嗎研究生

我有意識主動提供足夠的上下文(完成這次任務所需的資訊)嗎研究生

很多時候,一旦體驗不好,我們作為使用者第一反應往往是:產品不行、引導太差、功能不夠強研究生

因為AI工具實在是太容易上手且太好用了,我們誤以為使用AI並不是一項需要學習的能力研究生

事實上,會使用和用的好是兩碼事,想把AI用好也是需要持續學習的研究生

能不能意識到這一點,決定了我們能不能隨著AI進步而進步,成為AI時代的Native研究生

本文以AI Coding為例,分享我個人使用AI工具提高自己專業(程式設計)能力的實踐經驗研究生

第一階段研究生:從傳統程式設計到Vibe Coding

在軟體開發的歷史程序中,每一次效率的飛躍都伴隨著抽象層次的提升研究生

從機器碼到組合語言到高階語言,從Terminal到IDE到AI聊天框,開發者們始終在尋求降本增效的開發方法研究生

成為真正的AI Native Coder,一個研究生實踐6個月的思考!

展開全文

最早是Cursor改變了大家對程式設計軟體只能程式設計的刻板印象研究生。其對使用者友好的視覺化介面,讓開發者可以很絲滑地和AI結對程式設計,進行理論上高效高頻的協作。

大家驚奇地發現研究生

原來隨手幾句話就能生成一個閉環的可執行模組研究生

原來隨便寫點prompt就能得到測試用例、精美UI研究生

原來隨手幾句話就能生成一個閉環的可執行模組研究生

原來隨便寫點prompt就能得到測試用例、精美UI研究生

於是vibe coding應運而生研究生

你只需要告訴AI你的想法,不斷反饋你的感覺,AI迅速幫你實現研究生

它把原來傳統的純人工開發,變成了與模型的即時對話,讓開發者快速拿到反饋,非常適合做原型來驗證想法研究生

想學習Vibe Coding可以參考以下內容研究生,這裡就不展開介紹(可以收藏):

Cursor團隊AI Coding經驗研究生

Claude Code團隊AI Coding經驗研究生

Claude Code實戰程式設計經驗研究生

Codex團隊AI Coding經驗研究生

Datawhale團隊Vibe Coding教程研究生

Cursor團隊AI Coding經驗研究生

Claude Code團隊AI Coding經驗研究生

Claude Code實戰程式設計經驗研究生

Codex團隊AI Coding經驗研究生

Datawhale團隊Vibe Coding教程研究生

初期,大家以為Vibe Coding的瓶頸似乎只在人工QA頻率研究生

只要一直坐在螢幕前問AI、催 AI,它就能像ChatGPT回答問題一樣,幫你搞定一切研究生

但當要求從能展示的 Demo提升到可上線的工程專案研究生,從個人程式設計走向團隊協作時, Vibe Coding暴露出很多缺陷:

語義漂移與不確定性:模型在理解模糊需求時會做大量假設,輸出結構與團隊意圖常常不一致,無法保證邊界條件與錯誤處理都被覆蓋研究生

不可解釋/可審計性差:vibe輸出往往是黑盒式的程式碼片段,缺少來源說明、設計決策與驗收標準,團隊難以審計、點對點找相關負責人維護研究生

知識固化風險:當程式碼和設計未同步成可機器理解的規範時,知識留存在人腦或散落在PR中,容易隨著人員變動流失研究生

技術債:當你臨時妥協草率完成一個需求,Agent會把這個當成good case研究生。隨著程式碼裡這裡草率處理越來越多,AI會放大這種草率,積累技術債。

協作衝突:多人各自和AI互動生成程式碼,如果沒有統一規則,就會導致風格、介面和測試覆蓋嚴重碎片化研究生

語義漂移與不確定性:模型在理解模糊需求時會做大量假設,輸出結構與團隊意圖常常不一致,無法保證邊界條件與錯誤處理都被覆蓋研究生

不可解釋/可審計性差:vibe輸出往往是黑盒式的程式碼片段,缺少來源說明、設計決策與驗收標準,團隊難以審計、點對點找相關負責人維護研究生

知識固化風險:當程式碼和設計未同步成可機器理解的規範時,知識留存在人腦或散落在PR中,容易隨著人員變動流失研究生

技術債:當你臨時妥協草率完成一個需求,Agent會把這個當成good case研究生。隨著程式碼裡這裡草率處理越來越多,AI會放大這種草率,積累技術債。

協作衝突:多人各自和AI互動生成程式碼,如果沒有統一規則,就會導致風格、介面和測試覆蓋嚴重碎片化研究生

這些問題隨著Vibe Coding客觀存在,不能指望以後模型程式設計能力越來越強、理解能力越來越棒,就像再強大的汽車引擎也需要認路的老師傅駕馭,才能不跑偏研究生

第二階段研究生:掌握讓AI持續對齊的能力1. 讓AI持續對齊你的意圖

AI在問答任務上已經展示了極強的能力和潛力,但在程式碼任務裡卻容易跑偏研究生

因為問答依賴上下文的往往很短研究生,而且使用者意圖明確,模型只需要圍繞一個問題生成答案;

但是程式碼任務依賴的上下文大得多,包括業務背景、歷史實現、技術選型、團隊規範,甚至還包括這次為什麼要這麼改,以後要怎麼改研究生

Ai很難透過問答的形式對齊理解這麼多的意圖研究生。比如,GPT-4o等先進模型在1K Token時的準確率為99.3%,而當上下文擴充套件到32K Token時,準確率會暴跌至69.7%。

所以AI Coding很容易出現兩類典型問題研究生

上下文中毒:持續AI Coding時研究生,難免混入一些無關資訊,而模型無法分辨出這些,一視同仁難免跑偏;

注意力漂移:某次AI Coding偏離了目標,會導致後續生成結果看起來差不多合理,但積累到最後失之千里研究生

上下文中毒:持續AI Coding時研究生,難免混入一些無關資訊,而模型無法分辨出這些,一視同仁難免跑偏;

注意力漂移:某次AI Coding偏離了目標,會導致後續生成結果看起來差不多合理,但積累到最後失之千里研究生

因此研究生,AI Coding 的核心問題從來不是:這部分程式碼怎麼交給AI寫的更好

而是:如何把聊天式、靈感式的編碼過程研究生,轉換為團隊可依賴、可驗證、可治理的工程流程?

2. 讓AI持續對齊你的任務

很多人使用AI Coding的工作流是研究生:收到需求→開啟AI對話方塊→直接讓AI寫程式碼

這種方式把需求分析、方案設計、程式碼實現和驗收判斷都壓縮排了同一個對話過程研究生。AI一邊理解你的意圖,一邊生成方案,一邊完成實現,一邊再為自己的結果找理由,最後很容易在多輪對話中逐漸偏離目標。

為了減少這種偏差,我們需要將理解任務與生成程式碼顯式地解耦研究生

成為真正的AI Native Coder,一個研究生實踐6個月的思考!

AI Coding 任務對齊對比圖

如上圖所示, 穩定 AI Coding 的本質是從對話對齊轉向檔案對齊研究生。透過引入檔案(如design.md),我們將原本碎片化的聊天記錄,轉化為一份透明、可修訂、易協作的文件。

3.基於檔案的AI Coding方案

基於任務上下文和AI對話:透過初始對話讓AI快速理解原始需求研究生

生成設計文件:不急於寫程式碼,先要求AI輸出設計方案,由你確認架構是否正確研究生

按文件AI Coding MVP:AI嚴格基於文件內容進行開發,確保每一步都有據可依研究生

Review & Update:實現後回看文件研究生。如果程式碼偏離了設計,或者設計需要調整,先更新文件,再進入下一輪。

基於任務上下文和AI對話:透過初始對話讓AI快速理解原始需求研究生

生成設計文件:不急於寫程式碼,先要求AI輸出設計方案,由你確認架構是否正確研究生

按文件AI Coding MVP:AI嚴格基於文件內容進行開發,確保每一步都有據可依研究生

Review & Update:實現後回看文件研究生。如果程式碼偏離了設計,或者設計需要調整,先更新文件,再進入下一輪。

這個閉環的目標是:AI Coding個人任務,確保可靠交付研究生

但如果我們希望這種能力不只停留在個人習慣層面,而是進一步沉澱為團隊可複用、可驗證、可維護的工程資產,僅靠幾個檔案遠遠不夠研究生。因為隨著專案推進,文件不只是寫給AI看的指令,還是團隊共享的事實來源,持續驅動整個工程的協作開發。

我們需要將基於檔案的個人級別對齊轉變為基於規範的工程級別對齊研究生。接下來,討論如何透過 SDD(Specification-Driven Development,規範驅動)Coding來實現這一工程化轉變。

第三階段研究生:從個人提效到團隊協作的SDD Coding1. 軟體開發協作正規化演變

Talk is cheap研究生,show me your code / prompt / skill / specification

這句話最早的版本是Linux社羣裡那句很有名的:Talk is cheap, show me your code.它背後代表了一種很樸素的工程觀:在軟體開發裡,真正能讓團隊對齊的,從來不是空泛討論,而是可以被檢查、被複現、被協作的具體載體研究生

在傳統開發時代,這個載體是code研究生。 你說再多,不如把程式碼寫出來、把介面跑起來、把測試補完整。團隊成員之間很多共識,最終都是靠程式碼來確認的。

軟體開發協作載體演進圖

但AI Coding時代,當寫程式碼這件事開始部分交給模型完成時,團隊協作的重點從你親手寫了什麼程式碼,轉變為你是如何引導模型寫出這些程式碼的研究生。於是出現了新的協作載體:

最開始是prompt:你怎麼提問、怎麼拆任務、怎麼描述約束研究生,開始影響結果質量;

再往後是skill:團隊把一些重複有效的經驗沉澱成可複用的能力模組研究生,讓 AI 在不同任務中複用相同的方法;

再進一步,當專案需要團隊協作來長期維護、工程落地時,prompt和skill有點不夠用了,因為它們更偏生成過程的技巧,而不是團隊共享的事實來源研究生。因此協作載體落到specification上。它不只是告訴 AI 該怎麼做,更在規範定義開發應該做到什麼程度、如何判斷做對了沒有、如何團隊協作。

最開始是prompt:你怎麼提問、怎麼拆任務、怎麼描述約束研究生,開始影響結果質量;

再往後是skill:團隊把一些重複有效的經驗沉澱成可複用的能力模組研究生,讓 AI 在不同任務中複用相同的方法;

再進一步,當專案需要團隊協作來長期維護、工程落地時,prompt和skill有點不夠用了,因為它們更偏生成過程的技巧,而不是團隊共享的事實來源研究生。因此協作載體落到specification上。它不只是告訴 AI 該怎麼做,更在規範定義開發應該做到什麼程度、如何判斷做對了沒有、如何團隊協作。

從這個角度看研究生,軟體開發裡的協作介質,其實一直在升級:

從 talk 到 code,從 code 到 prompt,從 prompt 到 skill,再從 skill 走向 specification研究生

這並不是說前面的東西不重要了,而是說當工程複雜度不斷上升時,團隊需要一個更穩定、更明確、更可驗證的中間層,來承接人與人、人與 AI、以及 AI 與程式碼之間的協作關係研究生。這也是為什麼,在AI Coding繼續發展的今天,越來越多人開始關注SDD Coding。

2. 什麼是SDD Coding

SDD Coding(Specification-Driven Development Coding,規範驅動開發)是一種方法論: 用形式化、詳盡、可驗證的規範作為可執行藍圖,驅動 AI 進行程式碼生成研究生。規範不再只是輔助說明,而是事實來源,用來指導後續的生成、校驗與維護;你負責編寫清晰的需求與約束,AI 負責基於規範實現程式碼。

傳統開發通常是開發者寫需求 + 寫程式碼研究生,流程是:需求 → 設計 → 手寫程式碼 → 測試

而規範驅動開發則進一步變成研究生:需求 → 詳細規範 → AI 生成 → 驗證

兩者最關鍵的差異在於:前者是先有實現,再不斷補充理解;後者則是先把理解儘可能沉澱為規範,再讓 AI 基於規範實現研究生

也就是說,程式碼不再是唯一的核心產物,規範開始前置,成為整個開發流程中的事實來源研究生

這意味著研究生,開發者的重心也會發生轉移:

不再把主要精力放在親手寫出每一行程式碼上研究生,而是更多放在架構設計、需求澄清、邊界定義和結果驗證上;

不再主要依賴個人經驗確保程式碼質量,而是透過系統化的規則、驗收條件和反饋閉環研究生

不再把主要精力放在親手寫出每一行程式碼上研究生,而是更多放在架構設計、需求澄清、邊界定義和結果驗證上;

不再主要依賴個人經驗確保程式碼質量,而是透過系統化的規則、驗收條件和反饋閉環研究生

變化如下圖:規範前置、流程重排、重心轉移,並最終落到需求 → 規範 → 生成 → 驗證 → 規範更新的最小閉環中研究生

成為真正的AI Native Coder,一個研究生實踐6個月的思考!

SDD Coding並不是要求開發者寫更多的文件,而是把原本散落在聊天記錄、個人經驗和程式碼歷史裡的隱性知識,提前沉澱成可執行、可驗證、可複用的規範研究生

它的核心不只是先寫規範給 AI 看,還需要用規範驗證結果,並把新發現的問題繼續回寫到規範裡研究生

一個最小可執行的 SDD Coding 流程研究生,通常可以概括為四步:

清晰需求,寫明規範:在實現前,先產出結構化的specification研究生。明確解決的問題、輸入輸出、邊界條件及驗收標準,將模糊需求轉化為人機共識的唯一事實來源。

依據規範,精準生成:讓 AI 嚴格基於規範生成程式碼與測試研究生。AI不是在自由發揮,而是作為執行者,交付規範要求的程式碼。

對齊規範,嚴格驗證:驗證重點從能否執行轉向是否達標研究生。對照規範檢查 I/O、邊界覆蓋及設計意圖,讓規範充當裁判角色。

回寫規範,沉澱資產:將實現中暴露的遺漏、誤解或新約束補回specification研究生。不只是修程式碼,而是透過更新系統事實,避免重複犯錯。

清晰需求,寫明規範:在實現前,先產出結構化的specification研究生。明確解決的問題、輸入輸出、邊界條件及驗收標準,將模糊需求轉化為人機共識的唯一事實來源。

依據規範,精準生成:讓 AI 嚴格基於規範生成程式碼與測試研究生。AI不是在自由發揮,而是作為執行者,交付規範要求的程式碼。

對齊規範,嚴格驗證:驗證重點從能否執行轉向是否達標研究生。對照規範檢查 I/O、邊界覆蓋及設計意圖,讓規範充當裁判角色。

回寫規範,沉澱資產:將實現中暴露的遺漏、誤解或新約束補回specification研究生。不只是修程式碼,而是透過更新系統事實,避免重複犯錯。

這套流程真正改變的,不只是 AI 寫程式碼的方式,而是團隊理解需求、協作開發和積累工程知識的方式研究生

3. 規範是AI Coding時代的團隊資產

前面的SDD Coding解決的是如何讓 AI 基於規範穩定生成程式碼研究生,那麼這些規範,最後會沉澱成什麼?

答案:它們會逐漸沉澱成一種新的團隊資產研究生

這裡先簡單介紹一個很常見的技術棧:RAG(Retrieval-Augmented Generation,檢索增強生成)研究生。核心思想是不把所有知識都硬塞進模型引數裡,而是在模型生成之前,先從外部知識庫中檢索出和當前任務最相關的資訊,再把這些資訊作為上下文提供給模型。

這樣AI Coding的效果不再只取決於模型本身,還會越來越取決於團隊沉澱了什麼,以及這些沉澱下來的內容能不能被複用研究生。所以規範本身就是一種非常適合同步的團隊資產。

因為一份高質量的 specification研究生,往往同時包含了:需求背景、設計意圖、介面約束、邊界條件、驗收標準

這些內容,恰恰就是 AI 在寫程式碼、補測試、改實現、做審查時最需要、也最容易缺失的高價值上下文研究生

如果這些資訊只停留在聊天記錄裡,留在個人腦子裡,或者散落在 PR 評論和會議紀要中,它們就很難成為團隊長期可複用的知識研究生。但如果它們被結構化地沉澱為規範,就可以進一步進入團隊知識庫,被檢索、被引用、被複用。

也正因為如此,規範在 AI Coding 時代的意義,已經不只是幫助這一輪開發不跑偏的文件,而是在逐漸變成一種被同步、被團隊共享、被 AI 持續呼叫的團隊記憶研究生

這也是為什麼,AI Coding 落地的終極目標,不應該只是讓個體開發者寫得更快,而是要提升整個團隊的知識資產質量研究生。AI 的編碼能力不應隨著對話視窗的關閉而消失,而應該沉澱為一種可以持續積累、持續複用的團隊記憶。

在這個理念下,規範並不是唯一的團隊資產研究生。隨著AI Coding 逐步落地,團隊通常會形成三類互相配合的知識資產。

Specification(定義做什麼):它是整個流程的事實來源研究生。負責沉澱需求約束、邊界與驗收標準,定義什麼才算做對了。

Skill(沉澱怎麼做):它是團隊高頻經驗的封裝研究生。負責固化程式碼風格、設計習慣與安全規範,讓 AI 像老員工一樣幹活,熟能生巧。

MCP / 知識庫(提供做過什麼):它是團隊的外部記憶研究生。透過連線歷史程式碼、文件與避坑指南,讓 AI 能在組織經驗中尋找最優解。

Specification(定義做什麼):它是整個流程的事實來源研究生。負責沉澱需求約束、邊界與驗收標準,定義什麼才算做對了。

Skill(沉澱怎麼做):它是團隊高頻經驗的封裝研究生。負責固化程式碼風格、設計習慣與安全規範,讓 AI 像老員工一樣幹活,熟能生巧。

MCP / 知識庫(提供做過什麼):它是團隊的外部記憶研究生。透過連線歷史程式碼、文件與避坑指南,讓 AI 能在組織經驗中尋找最優解。

三者結合,AI 才真正有機會從一次性的生成工具,進化為團隊長期可依賴的工程夥伴研究生。所以AI Coding的真正目標,不是讓開發者今天多寫 500 行程式碼,而是讓團隊在每一次專案迭代中,把經驗持續沉澱下來,變成未來可以反覆呼叫的組織能力。

這才是AI Coding真正從原型工具走向生產工具的關鍵研究生

4. SDD Coding實戰經驗

使用基於Vibe、document的AI Coding,只要稍微注意上下文和任務拆分,就已經能明顯提升效果研究生

但要把SDD Coding這項利器引入現有工作流,需要先判斷一件事:它的前期成本,對當前團隊來說是否可接受研究生

這一步很重要研究生。因為SDD Coding的價值主要體現在中長期的工程。

如果團隊當前還停留在快速試錯、單人原型階段研究生,那麼完全不需要一上來就做的很規範;

但如果專案已經開始進入多人協作、反覆迭代和長期維護,是否引入SDD Coding,就值得認真評估了研究生

在這個過程中,團隊通常會有三個最常見的顧慮研究生

顧慮一:先寫規範研究生,會不會拖慢開發速度?

這是一個典型的以短期投入換取長期回報是否值得的問題研究生

如果把 SDD 理解成先補很多文件,它會帶來很多額外的工作了;但如果藉助AI工具把規範生成、規範回寫和規範同步儘可能自動化研究生。這樣前期增加的額外工作,本質上是在做更清晰的建模,後續則由工具和流程幫助團隊維持一致性。

而很多團隊是願意在研發前期多付出一點整理和建模成本,避免在上線後承擔更高昂的返工、維護和溝通代價研究生

從這個角度看,SDD 並不是額外增加了一層工作,而是在把原本分散在溝通、除錯、返工和補救裡的隱性成本提前顯性化研究生

顧慮二:如果AI誤解了規範怎麼辦研究生

這恰恰是SDD Coding要解決的問題研究生。SDD Coding不是把理解需求完全交給AI,而是儘可能把理解結果沉澱成可校驗的規範,例如明確的驗收標準、輸入輸出示例、邊界條件和測試用例。AI誤解自然語言很正常,但只要規範本身足夠結構化,生成結果就仍然可以繼續被人工驗證和約束。

SDD Coding的核心不是假設AI永遠理解正確,而是透過AI減小偏差,這肯定比只靠Vibe Coding更穩定,也更適合團隊協作研究生

顧慮三:如何選取規範模版並形成自己團隊的規範研究生

規範到底該怎麼寫?模板從哪裡來?這也是 SDD 落地裡一個很現實的門檻研究生。 因為大多數團隊並不缺寫規範的能力,缺的是一套既不復雜、又能驅動實現並且適合自己專案的規範模板。

與其從零開始造一套規範體系研究生,不如先借助現成的開源框架,快速迭代然後再根據自己專案來最佳化:

OpenSpec( AI推出的輕量級SDD工具研究生。透過一組斜槓命令驅動規範 → 實現的過程,用openspec/specs/與openspec/changes/兩個區域分別管理系統規範和變更記錄。每個階段都需要手動觸發,整體控制感比較強,比較適合還在摸索SDD Coding的團隊。

Spec-kit(研究生。透過在constitution.md中定義不可輕易違背的架構原則,用來約束後續所有規劃和實現過程中的技術決策。它的每個階段也均需手動觸發,還在程式碼生成前設有預實現門禁確保質量,適合對架構有嚴格約束的專案。

Superpowers(研究生。它把SDD Coding從手動執行流程推進到流程內嵌進代理行為,只要有一定機率某個技能適用,智慧體就會自動觸發相應能力。

OpenSpec( AI推出的輕量級SDD工具研究生。透過一組斜槓命令驅動規範 → 實現的過程,用openspec/specs/與openspec/changes/兩個區域分別管理系統規範和變更記錄。每個階段都需要手動觸發,整體控制感比較強,比較適合還在摸索SDD Coding的團隊。

Spec-kit(研究生。透過在constitution.md中定義不可輕易違背的架構原則,用來約束後續所有規劃和實現過程中的技術決策。它的每個階段也均需手動觸發,還在程式碼生成前設有預實現門禁確保質量,適合對架構有嚴格約束的專案。

Superpowers(研究生。它把SDD Coding從手動執行流程推進到流程內嵌進代理行為,只要有一定機率某個技能適用,智慧體就會自動觸發相應能力。

成為真正的AI Native Coder,一個研究生實踐6個月的思考!

SDD 團隊框架選型指南

第四階段:把AI使用內化為本能研究生,成為真正的AI Native Coder

現在這句話應該沒有爭議:AI是時代洪流,而AI Coding是其中最先落地、最影響工作正規化的場景研究生

程式設計師程式設計建立了AI,AI也重塑了程式設計師的程式設計正規化研究生

AI Coding 時代的 AI Native Coder,不只會用最貴的模型,最潮流的工具,是既享受AI驅動帶來的速度,也不放棄工程化所需要的規範研究生。只有這樣,AI才能和你發揮出結對程式設計的效果。

對個人開發者來說研究生,這意味著你需要重新學習如何與AI協作程式設計;

對團隊來說,這意味著要重新思考如何把AI整合到已有的開發流程中研究生

誰更早完成這種轉變,誰就更有可能在下一階段的軟體開發市場裡佔據優勢研究生

我個人認為研究生,還有幾個方向值得探索:

1、AI能否在更長時間尺度上自驅動完成工程任務: 現在大多數AI Coding,仍然是人類高頻盯控、持續糾偏的短程任務模式研究生。當我們給出足夠清晰的需求+規範後,系統能否在非人類工作時間連續執行,自主完成任務拆解、沙盒編譯、跑測試用例、查閱日誌並自我糾錯?這種非同步結對程式設計的實現,才是真正意義上的人力解放。

2、AI提效能否從程式設計擴充套件到其他場景: AI Coding 只是開始研究生。類似的工作正規化,是否也適用於自媒體個人IP運營、個人終身學習管理,甚至人生規劃,本質上相同且都值得探索。如果這些領域也能逐漸形成自己的規範—生成—驗證—迭代閉環,那麼AI Native就不只是程式設計師內部的自嗨,會引發更廣泛的工作方式變革。

3、工程經驗能否外掛化: 真正有價值的不是Prompt寫得多好,而是如何沉澱高訊雜比的知識研究生。那些被驗證過的 Specification、Skill 和架構約束,如何逐漸演變成可插拔、可複用的外掛。當這些沉澱下來的規範資產足夠多時,甚至可以作為數字員工,自主完成相應任務。

最後回答這篇文章的標題:AI Coding 時代如何做 AI Native Coder研究生

我的答案是:將AI嵌入自己的工作流,並把相關用法內化為本能研究生

個人認為,這不僅僅是學習如何熟練使用AI工具,更是重塑工程師的角色研究生。未來手寫程式碼程式設計的價效比越來越低,而與AI結對程式設計的價效比會越來越高,也許這是我們應該重視學習的新的程式設計正規化。

一起“ 點 贊 ” 三連 ↓

本站內容來自使用者投稿,如果侵犯了您的權利,請與我們聯絡刪除。聯絡郵箱:[email protected]

本文連結://haizhilanhn.com/tags-%E9%9B%BB%E6%B1%A0%E5%AE%B9%E9%87%8F.html

🌐 /