從7月到11月使用cursor pro，把零碎的輸出讓AI整理了一遍

核心觀點(diǎn)

• 工作空間更高效：可合并多倉、聯(lián)動改代碼。
  比如說我有個產(chǎn)品文檔，api文檔，使用文檔需要寫，可以用源代碼倉庫+文檔md倉庫(md有一定的輸出規(guī)范和格式，等于給出參考答案)
• 三類能力：Agent 寫代碼、Ask 問答、Plan 制定步驟。
• 需要架構(gòu)引領(lǐng)：開發(fā)者提供鏈路與關(guān)鍵點(diǎn)，AI 才能少走彎路。
  要放松嚴(yán)格解析json一個openapi的，從調(diào)用點(diǎn)- client端生成-proto生成-工具庫里面生成方法，每一個地方都可以有很多方法改，但是哪個地方是最好的，根據(jù)時序和使用場景，需要開發(fā)人員思考。不過有時候從一堆代碼里面找東西找解決方案，它也能靈機(jī)一動，這時候就要開發(fā)人員發(fā)現(xiàn)這個靈機(jī)一動是不是可以做某種擴(kuò)展和實(shí)踐。

能力與定位

• 代碼閱讀與理解
  • 先梳理模塊、調(diào)用鏈與關(guān)鍵結(jié)構(gòu)，明確輸入輸出與邊界。
• 代碼編寫 Agent
  • 適合樣板、適配、重復(fù)性重構(gòu)；需約束風(fēng)格、依賴與驗(yàn)收標(biāo)準(zhǔn)。
    這個模式下面，第一次寫模版的時候，組內(nèi)提了很多意見，我用腳本結(jié)合ask整理了一些規(guī)范，然后寫相似業(yè)務(wù)的時候讓它檢查這些問題是不是有再犯。
• 問答 Ask
  • 用于概念澄清與已知錯誤模式定位，不負(fù)責(zé)業(yè)務(wù)黑盒的根因分析。
• 計劃 Plan
  • 產(chǎn)出步驟與里程碑，Plan & Resolve 強(qiáng)調(diào)先計劃再執(zhí)行與修正。
    plan的一些實(shí)踐，拆分mr，巨大的mr需要做拆分，可以讓它出計劃甚至可以直接提分支代碼，通常太復(fù)雜的東西我自己來劃分會決策癱瘓，可能這是我一個人的問題

方法與實(shí)踐

• ReAct：檢索—思考—實(shí)踐循環(huán)，逐步收斂到可行解。
• Plan & Resolve：先給 1-2-3 關(guān)鍵步驟與檢查點(diǎn)，再按反饋迭代。
• 參考優(yōu)先：提供可復(fù)用樣例與“標(biāo)準(zhǔn)答案”，加速穩(wěn)定收斂。

經(jīng)驗(yàn)與邊界

• Cursor 有時“方案蠢”的原因：缺少約束與目標(biāo)度量，復(fù)雜代碼缺關(guān)鍵路徑指引；另一方面它不能寫出很優(yōu)雅簡潔的代碼，有點(diǎn)喜歡堆積功能。
• 開發(fā)者應(yīng)補(bǔ)位：設(shè)計模式與產(chǎn)品理解、整體鏈路架構(gòu)、底層原理；可能還是需要自己理解語言特性來熟練掌握。
• 風(fēng)險控制：
  • 防惰性與理解退化，定期無輔助編碼校驗(yàn)基本功。
  • Bug 定位更依賴熟悉業(yè)務(wù)的人腦，AI 用于證據(jù)與覆蓋面補(bǔ)充。
  • 先收斂后生成，控制上下文與版本一致性，節(jié)約時間與算力。

新AI工具一些可能：
自動評論，現(xiàn)在review mr會浪費(fèi)開發(fā)人員不少時間 --問了字節(jié)的朋友可以用知識庫搭rag
生成規(guī)則，和lint很像，給AI一些編程約束，一個團(tuán)隊(duì)和組有自己的編程約束，AI應(yīng)該和人一樣學(xué)習(xí)好 --這個初級的可以用cursor的rules

對我個人不好的地方：
我很想要進(jìn)入心流的狀態(tài)，但是使用ai只有在找尋方案的時候能很好的進(jìn)入
本來編碼，反復(fù)思考，這一步是可以很容易心流的，和我寫文章和寫題目答案，喜歡打字直接輸出一樣，所以要把這個撿起來，直到這些代碼對于我個人來說過于重復(fù)，沒什么好寫的