国外亚洲成av人片在线观看,热99re久久精品这里都是精品,天堂网在线最新版www,国产成人av区一区二区三,51久久成人国产精品麻豆

在 AI 編程實(shí)踐中，傳統(tǒng) Vibe Coding 因 Prompt 丟失、迭代混亂等問題逐漸顯露局限，而通過結(jié)構(gòu)化的 Spec Coding，結(jié)合清晰的需求文檔與技術(shù)方案，能有效提升 AI 生成代碼的準(zhǔn)確性與迭代效率，為 AI 時(shí)代編程提供新路徑。

本文會(huì)和大家開源產(chǎn)品從0到1，以及后續(xù)產(chǎn)品的Spec 提示詞，以及背后的思考：

目錄

1.為何說Vibe Coding已死？

2.兩個(gè)關(guān)鍵Prompt幫你Spec Coding

3.OpenAI和Karpathy是這么指引趨勢(shì)的

01 為什么說Vibe Coding已死？

OpenAI的Sean Grove，6月份分享了個(gè)主題，看起來很驚悚：“Prompt Engineering is Dead”，吸睛當(dāng)然很重要，但更重要的是副標(biāo)題：

Everything is A Spec！

他在分享里提了個(gè)很重要的問題：

問題1：“PROMPTS ARE EPHEMERAL.”（Prompt是短暫的）

“每次和AI激情對(duì)話，最后的Prompt都像一場夢(mèng)——醒了就啥也沒留下?！?/p>

其實(shí)我們想想，每次Vibe Coding的時(shí)候，我們會(huì)和AI大量的Chat，這些輸入的Prompt最后都沒留下來，可是，不正是這些Prompt，才生成了最后的結(jié)果么，為何我們把它丟掉了？

另外，黃叔從去年10月份開始大量的玩Vibe Coding，包括和身邊大量的朋友交流，發(fā)現(xiàn)一個(gè)更重要的問題：

問題2：Vibe Coding一開始很爽，但到后面越改越頭大！

“Vibe Coding越改越亂，代碼像打地鼠，改一個(gè)冒仨頭，產(chǎn)品經(jīng)理分分鐘變‘救火隊(duì)長’?！?/p>

是吧，一開始很快就出來了，但是后面每次迭代都心驚膽戰(zhàn)，因?yàn)槟阕屗腁，經(jīng)常莫名其妙的出現(xiàn)了B和C的錯(cuò)誤。。。然后又是一通改，又是找Git回滾?？傊M(fèi)了很大勁，莫名其妙某次發(fā)現(xiàn)，它好了。。。

然后不斷的重復(fù)這個(gè)流程。甚至有朋友說，因?yàn)檫@一點(diǎn)，都不愿意去Vibe Coding了。。。

那有沒有解決方案呢？必須有的：

02 Spec Coding殺死Prompt Engineering

“Spec Coding不是‘頭腦風(fēng)暴’，而是‘頭腦風(fēng)暴后的施工圖’?！?/p>

提示詞工程其實(shí)從2023年就開始了，但那會(huì)更多偏向于給出一個(gè)結(jié)構(gòu)化的提示詞，讓大模型一次（或少數(shù)幾次Chat）就出結(jié)果，但那個(gè)其實(shí)和我們的Spec Coding完全不是一個(gè)東西。

為何呢？

其實(shí)你想想很成熟的產(chǎn)品開發(fā)流程就知道了，除了一句話就能做出的玩具之外，大部分時(shí)候產(chǎn)品都需要持續(xù)不斷的Vibe才能生成的，這個(gè)過程就需要很多的技巧來控制AI符合預(yù)期的去生成代碼，并不斷調(diào)整。

復(fù)雜度： Spec Coding>>Prompt Engineering

從三周前，在繼剛的線下局里，黃叔就開始思考這個(gè)話題：

到上周末，終于拿出了方案，這個(gè)方案，也是陸續(xù)燒了2000美金Claude Code方案后驗(yàn)證出來的：

我們直接來看兩個(gè)階段性的成果！

產(chǎn)品0到1

Spec：現(xiàn)在，你將扮演一名首席產(chǎn)品設(shè)計(jì)師，不僅擁有世界頂級(jí)產(chǎn)品的設(shè)計(jì)審美，還具備敏銳的產(chǎn)品戰(zhàn)略思維。我們的目標(biāo)是共同規(guī)劃一款能夠持續(xù)迭代、不斷成長的產(chǎn)品，首先從一個(gè)成功的 最小可行產(chǎn)品 (MVP) 開始。

你的任務(wù)：啟發(fā)式對(duì)話與戰(zhàn)略規(guī)劃：我會(huì)描述我的產(chǎn)品愿景。

你的任務(wù)是：

邏輯偵探：挖掘并質(zhì)詢所有模糊的功能細(xì)節(jié)。

設(shè)計(jì)顧問：主動(dòng)從用戶體驗(yàn)和審美的角度提出UI/UX建議。

版本規(guī)劃師 (Version Planner)：這是你的核心職責(zé)之一。

你必須主動(dòng)引導(dǎo)討論，幫助區(qū)分哪些功能是構(gòu)成 MVP 的絕對(duì)核心，哪些是可以放在后續(xù)版本迭代的。例如，你會(huì)提問：“這個(gè)功能非常棒，但為了盡快上線驗(yàn)證核心價(jià)值，我們是否可以先做一個(gè)簡化版，把完整版放在V2版本？”

確保兼容性：隨時(shí)查看代碼庫，確保新設(shè)計(jì)能與現(xiàn)有功能和諧共存。

鎖定產(chǎn)品路線圖：當(dāng)你認(rèn)為一切清晰后，請(qǐng)以以下格式向我輸出一份“產(chǎn)品路線圖 (Product Roadmap)”。

這份路線圖將是我們合作的藍(lán)圖。

核心目標(biāo) (Mission)：一句話描述產(chǎn)品的最終愿景。

用戶畫像 (Persona)：這個(gè)產(chǎn)品是為誰設(shè)計(jì)的？他們的核心痛點(diǎn)是什么？

V1: 最小可行產(chǎn)品 (MVP)：以列表形式，明確列出構(gòu)成第一版必須包含的核心功能。這是我們首先要集中火力攻克的目標(biāo)。

V2 及以后版本 (Future Releases)：以列表形式，列出我們計(jì)劃在未來版本中添加的激動(dòng)人心的功能。

關(guān)鍵業(yè)務(wù)邏輯 (Business Rules)：描述 MVP 版本中的核心業(yè)務(wù)規(guī)則。

數(shù)據(jù)契約 (Data Contract)：明確 MVP 版本需要處理的數(shù)據(jù)。

MVP 原型設(shè)計(jì)與確認(rèn)：在我確認(rèn)上述路線圖后，請(qǐng)你僅針對(duì) MVP 版本的功能，使用ASCII字符繪制 3個(gè) 不同設(shè)計(jì)理念的概念原型圖。我會(huì)從中選擇一個(gè)。

架構(gòu)設(shè)計(jì)藍(lán)圖: 基于上面的內(nèi)容，生成一份Markdown文檔，包含：

核心流程圖：使用Mermaid語法的序列圖(sequenceDiagram)或流程圖(flowchart)，畫出關(guān)鍵的后端業(yè)務(wù)或數(shù)據(jù)流。

組件交互說明：明確指出本次修改會(huì)影響到哪些現(xiàn)有文件或模塊，以及新增模塊和現(xiàn)有模塊之間的調(diào)用關(guān)系。

技術(shù)選型與風(fēng)險(xiǎn)：說明關(guān)鍵的技術(shù)選型（如特定庫或算法），并預(yù)判潛在的技術(shù)風(fēng)險(xiǎn)。

最終確認(rèn)與存檔：在我選定原型圖后，我們將正式鎖定所有需求。

請(qǐng)將最終確認(rèn)的“產(chǎn)品路線圖”和選定的MVP原型圖及設(shè)計(jì)說明還有架構(gòu)設(shè)計(jì)藍(lán)圖一起，生成Prd.md文檔作為存檔，然后等待下一步的命令。

只要把提示詞輸入，AI就會(huì)開始主動(dòng)提問，并不斷追問，直到完成整個(gè)PRD.md文檔：

接下來，可以讓AI根據(jù)這個(gè)prd.md，結(jié)合Context7 MCP，開始進(jìn)行開發(fā)。

如果是在CC里，打開危險(xiǎn)模式：claude –dangerously-skip-permissions ，此時(shí)CC會(huì)獲得最高權(quán)限，自己完成任務(wù)規(guī)劃，并一路狂奔，跑個(gè)30分鐘都很正常，然后一把給你出一個(gè)MVP產(chǎn)品。

黃叔用這個(gè)提示詞的上一個(gè)版本開發(fā)iOS App，只修復(fù)了兩次編譯錯(cuò)誤，就出來了一個(gè)功能還比較齊全，并且完全符合PRD文檔內(nèi)需求的產(chǎn)品！非常爽。

除了從0到1，還有后續(xù)多個(gè)版本的迭代，如何實(shí)現(xiàn)呢？產(chǎn)品迭代Spec步驟：

我們以Claude Code為例，在產(chǎn)品迭代的時(shí)候，按照以下步驟進(jìn)行：

第一步：切到Plan Mode：“{口噴描述需求、當(dāng)前版本存在的bug}請(qǐng)給出解決方案，用ASCII繪制原型圖，把所有影響到的部分全部繪制出來，包括原型和技術(shù)方案，注意，請(qǐng)仔細(xì)檢查不要影響非相關(guān)模塊，要保證根據(jù)你的方案實(shí)現(xiàn)后，能完美實(shí)現(xiàn)需求”

然后和CC核對(duì)方案，但凡你覺得不合理的，想優(yōu)化的，都可以繼續(xù)口噴，直到滿意為止。

第二步：當(dāng)你對(duì)方案滿意后，切換到危險(xiǎn)模式：用方案{},這個(gè)版本號(hào)設(shè)定為{}。請(qǐng)注意再次檢查按照此方開發(fā)后是否能完整實(shí)現(xiàn)需求，并且不影響其他不相關(guān)模塊，如果有，請(qǐng)重新指定方案并和我同步。如果一切可以正常實(shí)現(xiàn)，在prd.md文檔頂部新版本更新區(qū)域,撰寫對(duì)應(yīng)的產(chǎn)品需求更新,對(duì)應(yīng)的ASCII原型圖，以及涉及到的技術(shù)架構(gòu)和要點(diǎn)更新,然后后續(xù)的開發(fā)嚴(yán)格遵循此次更新，再將代碼實(shí)現(xiàn)切分為合理的todolist,按順序執(zhí)行,執(zhí)行完畢后自己做整體檢查 ultrathink

這樣開發(fā)下來會(huì)發(fā)現(xiàn)大部分情況下都能實(shí)現(xiàn)你的迭代要求：

可以看到，我用ASCII繪制原型圖后，最后生成的頁面是完全吻合的。

使用上面這套工作流程，黃叔自己的產(chǎn)品從0到1，迭代了20多個(gè)版本，只有2個(gè)小版本開發(fā)后是有編譯錯(cuò)誤的，也是很快就完成了修復(fù)，幾乎沒有出現(xiàn)過要求改A，結(jié)果“B和C”被改掉的問題。

核心工作邏輯

“AI寫代碼，最怕你說‘你看著辦’，最愛你給‘說明書’?！?/p>

你會(huì)發(fā)現(xiàn)基于Claude Code，這套Spec Coding的效率之所以高，核心是上面的機(jī)制。

首先是Plan Mode，我會(huì)調(diào)用4.1 Opus來深度理解當(dāng)前代碼以及自己的需求，這個(gè)最強(qiáng)的編程大模型能夠找到合理的方案，并制定開發(fā)計(jì)劃。然后我會(huì)反復(fù)和它對(duì)齊，最后讓Opus輸出Spec文檔。

其實(shí)，你設(shè)想這個(gè)場景和過去產(chǎn)品開發(fā)流程里面是非常相近的：

在需求評(píng)審會(huì)里，你會(huì)提出很清晰的需求。然后，研發(fā)理解之后，我還不會(huì)讓他直接去開發(fā)，而是讓他詳細(xì)地跟我說一下他的解決方案是什么。

因?yàn)橛袝r(shí)候可能你跟他說的是含糊的A，結(jié)果他理解成了B。這樣子，最后開發(fā)出來的就和之前你想要的有很大的差異。所以在需求評(píng)審會(huì)上，兩邊都要聊得非常清楚，再進(jìn)入到開發(fā)。

這里我們是和最牛的Opus來溝通協(xié)作的。

有了Prd，再讓干活麻利的小弟4 Sonnet去干活，甚至引入Context 7 MCP，讓它去讀最新的技術(shù)文檔，這樣就能大幅提高開發(fā)的成功率。

有了Spec，AI開發(fā)像裝宜家家具——照?qǐng)D施工，不再靠‘感覺’拼命試錯(cuò)。

額外的好處

這里不知道大家感受到一個(gè)額外的好處沒：PRD可以一直保持最新的狀態(tài)：

這里我給大家看幾個(gè)版本的Prd截圖，可以看到非常的清晰。

在過去，和產(chǎn)品版本同步更新的Prd是非常難的，因?yàn)楹芏嘈枨缶褪强陬^和研發(fā)溝通完就開發(fā)了，要一直保持prd版本同步更新，非常吃產(chǎn)品經(jīng)理的時(shí)間精力。

現(xiàn)在AI完全搞定了！

而且還有個(gè)好處，即使是沒有g(shù)it做存檔，也可以部分恢復(fù)產(chǎn)品代碼，因?yàn)椋?/p>

Spec = New Code！

黃叔之前開發(fā)到2.2.4版本，有個(gè)新功能的開發(fā)導(dǎo)致了界面的問題，修了兩三次沒修復(fù)，然后我一看git，只是保存到1.9.2，這要在過去，頭都大了！

現(xiàn)在就沒事，首先我先用git reset回滾到1.9.2，然后把之前prd保存下來的每個(gè)版本更新內(nèi)容給到CC，讓恢復(fù)到界面有問題之前的2.2.1版本，CC一次就完成了重新開發(fā)，非常高效！

還有更多

其實(shí)要展開說這套Spec Coding，還有些東西，簡單說兩點(diǎn):

這個(gè)是峰子上次分享給我的一個(gè)啟發(fā)，結(jié)合我自己過去的經(jīng)驗(yàn)，其實(shí)模型在預(yù)訓(xùn)練階段，以及基本完成了Coding能力的上限，不管是Vibe Coding還是Spec Coding，我們無非是用不同的方式提高模型在生成代碼上的正確性。

但模型能力是有邊界的，比如我們不可能一句話就讓Sonnet生成40萬行高質(zhì)量的代碼一樣，Spec Coding仍然只是在更好的激發(fā)模型的潛力，并逼近它的能力上限。

也就是說，這套流程不可能包治百??！大家得做好心理準(zhǔn)備。

這個(gè)理念的背后，帶來了Spec一個(gè)很有意思的特性：

Write Once, Run Everywhere

你只需要寫一遍Spec，就可以在非常多的地方達(dá)到相近的效果，甚至模型升級(jí)后都可以有很好的效果。

這是因?yàn)镾pec已經(jīng)完成了很詳盡的定義，只要模型能力足夠，就能很好的發(fā)揮出來。

最后，Spec = New Code

這是一種自主滑塊的概念，當(dāng)LLM越來越好使，我們只需要更清晰的結(jié)構(gòu)化溝通，就更能讓AI還原代碼。現(xiàn)在這個(gè)滑塊還在靠左側(cè)的位置，隨著能力逐漸進(jìn)化，Spec的價(jià)值會(huì)越來越大。最后

Spec Coding剛剛開始，其實(shí)國內(nèi)外也開始陸續(xù)的有更多的研究，黃叔的這一套Spec工作流，也并不完善，一方面，在開發(fā)產(chǎn)品過程中，我也在不斷優(yōu)化細(xì)節(jié)，也在發(fā)現(xiàn)遇到的邊界情況，另一方面，也在努力和AI Coding高手交流學(xué)習(xí)，不斷完善這套體系。

對(duì)了，上次在智譜的線下分享里，我做了個(gè)調(diào)研，非常震驚的是，大概只有1/20的同學(xué)，使用Claude Code來Coding，自從黃叔用上CC后，包年的Cursor已經(jīng)無所謂它封殺我Claude4的使用權(quán)限了，目前CC是Coding領(lǐng)域斷檔的存在。

簡單說，Cursor用不了我不慌，CC用不了要我命。。。