毫無疑問，Marscode 能解決非常多基礎(chǔ)問題，特別對于編程新手而言，它能相對準(zhǔn)確地生成各種代碼，完成編程任務(wù)，但其底層并不神秘，本質(zhì)上就是在傳統(tǒng) IDE 基礎(chǔ)上，搭配足夠好的交互與足夠好的 LLM，從而超越傳統(tǒng) IDE。交互方面，它在 VS Code 基礎(chǔ)上，補充提供了：

• 提供了幾乎毫無門檻的代碼自動補全能力，并且支持多行編輯，這在一些場景，如修改變量名時，非常好用。
• 行內(nèi)、獨立問答面板，可用于快速解答問題。

在此基礎(chǔ)上，配合豆包模型，算得上是國內(nèi)最好的編程輔助工具了。但工具再好，錯誤的用法下生成效果很可能不能達(dá)到預(yù)期，因此，這里根據(jù)我個人的使用經(jīng)驗，匯總一些最佳實踐技巧。

1.  頻繁提交代碼

切記，LLM 始終是隨機的，無法保證下次執(zhí)行結(jié)果的正確性，在使用過程務(wù)必養(yǎng)成習(xí)慣頻繁提交代碼，方便出現(xiàn)問題時隨時回滾。我個人的操作習(xí)慣大致是：

• 使用 Marscode 各類面板生成代碼后，先做一遍簡單的代碼 Review，修改變量名、循環(huán)結(jié)構(gòu)等基礎(chǔ)問題；
• 在軟件上下文中集成調(diào)試，初步驗證正確性后立即提交代碼；
• 審閱代碼設(shè)計，重點關(guān)注：函數(shù)輸入輸出結(jié)構(gòu)、模塊導(dǎo)入導(dǎo)出內(nèi)容、邏輯與循環(huán)分支處理等等，在這個節(jié)點通常會持續(xù)讓 LLM 按我的想法優(yōu)化代碼，或者自己上手做些小修改，迭代多次持續(xù)提交代碼，這個過程通常耗時最多；
• 代碼初步穩(wěn)定后，繼續(xù)讓 LLM 幫我生成單測代碼，這個階段通常需要迭代多次，提交多次，直至單測通過，覆蓋率達(dá)標(biāo)為止；
• 功能代碼、測試代碼均準(zhǔn)備就緒后，提交 PR 準(zhǔn)備合碼；

這個過程中，每次調(diào)用 LLM 都可能得到不符合預(yù)期的結(jié)果，但只要基本達(dá)標(biāo)我都會立即 Commit，后續(xù)遇到問題隨時 Revert 即可，雖然這會產(chǎn)生大量 Commit History ，但合碼前使用 Rebase 等操作調(diào)整歷史記錄即可。

2.  重視 Code Review

其次，建議將更多時間精力放在 Code Review 上，因為 Marscode 生成的代碼可能是局部最優(yōu)，但可能因為缺失相對抽象的全局架構(gòu)信息，而并不能做到全局最優(yōu)，例如重復(fù)編寫組件，或破壞某些約定俗成的架構(gòu)規(guī)則等，日積月累同類代碼可能最終導(dǎo)致可維護(hù)性、可讀性都逐步劣化到無法繼續(xù)迭代的程度(公正點說，人類智能也會導(dǎo)致這類問題)。

因此非常建議重視建立嚴(yán)謹(jǐn)?shù)?Code Review 文化，理想情況應(yīng)該是由 Marscode 生成盡可能多的代碼，盡可能代替人類完成編碼工作，再由人類智能負(fù)責(zé)驗證、審查這些代碼的合理性，保證結(jié)果正確且長期可維護(hù)。

3.  更好的工程化體系

如前所述，Marscode，或者說 LLM 生成的結(jié)果是隨機的，無法保證每次都得到正確的結(jié)果，每次變更都有可能影響存量代碼的穩(wěn)定性，如果這些變更都必須由人類手動驗證，那么測試成本會搞起不下，測試環(huán)節(jié)會成為工程中新的效率卡點。

更好的方式，應(yīng)該是投入更多精力建設(shè)更穩(wěn)健的工程化體系(這部分需求也可由 Marscode 輔助實現(xiàn))，使用自動化工具代替人力完成諸多基礎(chǔ)質(zhì)檢任務(wù)，例如引入 UT/E2E 完成運行質(zhì)量測試，CI/CD 中加入 TS 類型檢查、ESLint 風(fēng)格檢查等保證代碼質(zhì)量，等等。重點在于，使用更高效、成本更低的方式不斷驗證 AI 產(chǎn)物質(zhì)量，更敏捷地應(yīng)對變化。

此處不再贅述。

4.  使用 AI 友好的技術(shù)棧

在使用 Marscode 或其他同類輔助編程工具時，應(yīng)盡可能選用各類 AI 友好的技術(shù)棧，以前端為例，如：Tailwind 優(yōu)于原生 CSS/Less 等；Typescript 優(yōu)于 JavaScript、CoffeeScript 等；React 或 Vue 等 MVVM 框架優(yōu)于原生 JS + HTML + CSS；GraphQL 優(yōu)于 Restful 等。

為什么技術(shù)棧之間會出現(xiàn)這種差異呢？關(guān)鍵在于 LLM 底層是基于概率推導(dǎo)實現(xiàn)內(nèi)容生成的，結(jié)果好壞取決于模型質(zhì)量、訓(xùn)練語料、上下文完整度、Prompt 等諸多因素，單就輔助生產(chǎn)代碼這一任務(wù)而言，LLM 對技術(shù)棧的理解越充分必然效果越好；代碼結(jié)構(gòu)越聚焦，推導(dǎo)時信息噪音越低，結(jié)果也會越好；業(yè)務(wù)實現(xiàn)中的特化場景越少，通用規(guī)則越多，LLM 需要理解的內(nèi)容越少，效果通常也會越好；等等。

基于這些維度，我個人總結(jié)了幾類簡單規(guī)則可用于輔助評估某種技術(shù)棧是否更適用于 AIGC 場景，包括：

• 社區(qū)熱度：社區(qū)越繁榮，意味著使用者越多，相關(guān)的技術(shù)討論、技術(shù)資料也必然越豐富，LLM 訓(xùn)練或執(zhí)行時所能索引的信息就越完整，那么也就越容易推導(dǎo)出較好的結(jié)果。舉個例子，假設(shè)你工作中遇到了某個非常具體而棘手的問題，若剛好有人也遇到過，并將該問題形成的底層原因、解決方案整理成文章并發(fā)布到互聯(lián)網(wǎng)上，若 LLM 運行時能檢索到該文章，則可以基于文章內(nèi)容推導(dǎo)給出最終解決方案；若網(wǎng)絡(luò)上沒有這類信息，考慮到 LLM 并不具備復(fù)雜邏輯推理能力，那么大概率無法給出有效的解決方案。
• 結(jié)構(gòu)化：技術(shù)棧本身的結(jié)構(gòu)化、模塊化水平越強，則其信息表現(xiàn)形式越是聚焦，越容易被 LLM 正確推導(dǎo)。比如，原子 CSS(如 Tailwind) 就是一個很好的例子，原生 CSS 是通過具體的屬性的鍵值對表達(dá)頁面元素的視覺效果，而原子化 CSS 則是通過原子類名表達(dá)某類樣式規(guī)則集，信息更聚焦更容易被 AI 理解；并且受層疊規(guī)則影響，使用原生 CSS 時，元素樣式可能受全局、祖先級元素、多種選擇器等層級的樣式規(guī)則影響，這對 LLM 而言意味著具體信息分散在項目的多個角落，需要消費、理解更多上下文才能推導(dǎo)出正確的結(jié)果，相對而言原子化 CSS 框架下，大部分樣式信息都聚焦在元素對應(yīng)的 Class 列表上，信息高度聚焦，推理成本更低，結(jié)果也會更可靠。
• 通用規(guī)則優(yōu)于特化設(shè)計：技術(shù)棧的設(shè)計規(guī)范越是通用，則越容易被 LLM 理解，也就越是適用于 AIGC 場景。例如，GraphQL 明顯優(yōu)于 Restful，因為 GraphQL 提供了一套用于描述實體 + 實體關(guān)聯(lián)關(guān)系的通用語言規(guī)則，足夠用于表達(dá)絕大多數(shù)數(shù)據(jù)存、取、刪、改等常規(guī)業(yè)務(wù)操作，因而對 LLM 而言只需理解這套通用語言規(guī)則，配合具體業(yè)務(wù)領(lǐng)域中的實體與實體關(guān)系即可基于 GraphQL 靈活編寫出各類數(shù)據(jù)操作邏輯；而 Restfull 規(guī)范則更多聚焦在實體上，除幾種基礎(chǔ)的數(shù)據(jù)操作外，涉及復(fù)雜數(shù)據(jù)結(jié)構(gòu)場景時，出于實用性、性能等角度考慮，通常不得不特化設(shè)計、特化開發(fā)，而這些特化處理對 LLM 而言會顯得過于具體，相應(yīng)的上下文復(fù)雜度與噪音也會更高，也就更難以推導(dǎo)出正確的答案。
• 自動化質(zhì)檢：技術(shù)棧的質(zhì)檢工具越強大，則能夠越早、越全面地發(fā)現(xiàn)質(zhì)量問題，進(jìn)而更能低效 LLM 隨機性帶來的質(zhì)量風(fēng)險，也就更適用于 AIGC 場景了。例如，Typescript 之于 JavaScript，前者具有更強的類型聲明系統(tǒng)，因此在靜態(tài)代碼分析階段即可找出諸多類型不匹配問題，那么即使 LLM 生成了類型不匹配的代碼，也能夠在運行代碼之前發(fā)現(xiàn)問題，糾錯成本要低很多。

當(dāng)然，上述規(guī)則僅僅是我的一家之言，隨著大模型的迭代發(fā)展，具體規(guī)則后續(xù)必然還會新增或刪改，這不重要，重要的是非常建議讀者后續(xù)在做技術(shù)選型時，不要只是基于個人 or 團(tuán)隊喜好做決定，應(yīng)該更多考慮技術(shù)棧對 AI 的適用性，甚至可以以此為首要原則，盡可能選用對 AI 友好的技術(shù)與工具，使得 LLM 更好、更準(zhǔn)確地輔助完成各類開發(fā)任務(wù)，充分融入到日常工作中，提升個體與團(tuán)隊的整體效率。

5. 降低預(yù)期

對，標(biāo)題沒寫錯，你需要降低預(yù)期！前面也說過幾次，LLM 并不是魔法，它有幻覺，有知識漏洞，有隨機性，不擅長解決復(fù)雜問題，有各種各樣的缺點，從我的使用經(jīng)驗來說，多數(shù)時候它還遠(yuǎn)沒有達(dá)到我預(yù)期的狀態(tài)，需要我參與到各種代碼細(xì)節(jié)中。

例如，生成單測通常都跑不通，需要各種修改微調(diào)測試；生成的文檔可能也會缺失某些重要內(nèi)容，需要調(diào)整 Prompt 后多次重試，才有可能達(dá)到預(yù)期效果；生成的代碼，即使在 Marscode 各種上下文引用能力的加持下，也經(jīng)常會在細(xì)節(jié)處犯錯，導(dǎo)致執(zhí)行失敗。以 LLM 的底層實現(xiàn)邏輯來說，這些結(jié)果都太正常不過了。

因此，建議降低對 Marscode 或者其他 LLM 工具的預(yù)期，它并不是魔法，無法完全代替人類智能，當(dāng)下你還是需要認(rèn)真做好導(dǎo)演角色，引導(dǎo) Marscode 更準(zhǔn)確更好地解決你的問題，認(rèn)真研讀理解倉庫已有的代碼與 LLM 生成的代碼。更進(jìn)一步的說，你自身還是需要有比較強的技術(shù)能力，理解各類技術(shù)底層細(xì)節(jié)，才能及時發(fā)現(xiàn)、修復(fù)問題。某種程度上，Marscode 就像一把刀，它的鋒利程度取決于你自身的功力。

總結(jié)

本文討論了 Marscode 作為編程輔助工具的優(yōu)勢、使用中的最佳實踐技巧以及需要注意的問題。Marscode 在傳統(tǒng) IDE 基礎(chǔ)上，搭配良好的交互與 LLM，能為編程新手準(zhǔn)確生成代碼，但仍存在局限性。

關(guān)鍵要點包括：

• 頻繁提交代碼：使用 Marscode 生成代碼后，經(jīng)過簡單 Review、調(diào)試、審閱設(shè)計等步驟，多次迭代并及時提交，方便回滾。
• 重視 Code Review：Marscode 生成的代碼可能局部最優(yōu)但非全局最優(yōu)，應(yīng)重視人工審查以保證長期可維護(hù)性。
• 建立更好的工程化體系：投入精力建設(shè)穩(wěn)健的工程化體系，用自動化工具代替人力完成基礎(chǔ)質(zhì)檢任務(wù)。
• 使用 AI 友好的技術(shù)棧：選用社區(qū)熱度高、結(jié)構(gòu)化強、通用規(guī)則優(yōu)、自動化質(zhì)檢好的技術(shù)棧，以提升 LLM 輔助效果。
• 降低預(yù)期：LLM 有諸多缺點，無法完全替代人類智能，使用者自身需具備較強技術(shù)能力。