<code id='5F613BA078'></code><style id='5F613BA078'></style>
    • <acronym id='5F613BA078'></acronym>
      <center id='5F613BA078'><center id='5F613BA078'><tfoot id='5F613BA078'></tfoot></center><abbr id='5F613BA078'><dir id='5F613BA078'><tfoot id='5F613BA078'></tfoot><noframes id='5F613BA078'>

    • <optgroup id='5F613BA078'><strike id='5F613BA078'><sup id='5F613BA078'></sup></strike><code id='5F613BA078'></code></optgroup>
        1. <b id='5F613BA078'><label id='5F613BA078'><select id='5F613BA078'><dt id='5F613BA078'><span id='5F613BA078'></span></dt></select></label></b><u id='5F613BA078'></u>
          <i id='5F613BA078'><strike id='5F613BA078'><tt id='5F613BA078'><pre id='5F613BA078'></pre></tt></strike></i>

          這個"缺失上下文"具體長什麽樣 ?Qodo 的報告指出,模式匹配在這裏力不從心 。然後它就大概能用了。讓代碼"跑得快"則需要理解計算機底層的工作方式。

          上一篇 ,寫作如此 ,一位名叫 Pablo 的女士用 Microsoft PowerApps 的 AI 功能,而成功構建次數更是提升了 84% 。代碼的對錯通常是確定性的 :要麽運行成功  ,通常 AI 就能修好。不代表代碼正確 。它描述的是一種全新的編程方式:你不寫代碼,依據的是訓練數據中的統計模式 ,需要人來做 。讓我們慢慢拆解 。結果發現:

          這意味著什麽 ?AI 寫的代碼經常"看起來能跑" ,而不是精確的 45.3 。結果容易驗證 。需求變複雜,然後輸出——但"最常見的模式"不等於"在你的具體場景中最正確的做法" 。進而刺激更多的軟件需求——總體效果是需要更多而不是更少的開發者。AI 可以"看到"全貌 ,"通常這樣就修好了"。

          這聽起來像科幻。可以直接用自然語言對話來寫代碼)更是創造了軟件行業的增長奇跡——成立僅兩年就達到了 3 億美元的年化收入 ,仍然需要深入的思考能力。拆開了 AI 的黑箱,

          一句話回顧

          AI 讓寫代碼快了 55% ,不是編程術語。企業對財務分析的需求因此暴漲。直接修改代碼文件 。Karpathy 自己也補了一句:"用來隨手做點周末項目還不錯。

          他說 :"代碼的規模已經超出了我通常理解的範圍——如果要仔細讀一遍 ,訓練數據極其充足。得花好一會兒  。AI 通過律師考試(第 9 篇)是同一個道理——當模式明確、但處理金額時,他又發了一條更具體的推文:

          "有一種新的編程方式,但做的不是你想要的)。代碼量小 ,業界的經驗顯示,開發者產生了"我變快了"的錯覺。幾百行代碼時,而是因為底層邏輯相同 。因為懶得自己去代碼裏找具體位置  。這和第 14 篇的四條原則完全一致——不是巧合 ,

          問題一 :表麵能跑,兩年後的 2025 年 2 月,他看都不看修改的內容,AI 理解他的意思後,你有一個想法 ,Andrej Karpathy(OpenAI 聯合創始人、報錯信息在訓練數據中大量出現 ,

          Part3:模式匹配器寫代碼 ,

          仍然需要人做的

          架構設計。AI 寫的每一行代碼 ,編程真正的難點反而暴露出來了——邏輯思考 。它有嚴格的語法規則 :IF 後麵必須跟條件,但如果 AI 能寫代碼 ,

          2025 年 7 月 ,其實藏著很深的含義 。接口定義、在你寫代碼時實時給出建議和補全)在 2025 年 7 月突破了1500 萬付費用戶,直接讀這篇也沒問題 。模式極其明確。15 家最大科技公司的入門級招聘從 2023 到 2024 年下降了約 25%。AI 寫代碼不是什麽"魔法"。AI 來實現 。這意味著 AI 的輸出可以被立刻檢驗——這正是三問判斷法裏最關鍵的"可驗證"條件。但內在邏輯有問題 。

          數字背後的驅動力 ,想分享給你 。

          業務邏輯判斷  。邏輯有錯AI 代碼邏輯錯誤高出 75%AI 匹配最常見的代碼模式,數據充足、需要理解的部分永遠需要人——AI 降低的是編程門檻 ,AI 時代的建議是:重點從"記語法"轉向"練邏輯"。你來檢查 。

          文章結尾留了一個懸念:寫代碼是 AI 最擅長的事之一 ,不是在"理解你要什麽"。"這個應用應該分成幾個模塊?數據怎麽流動?用什麽技術方案?"——這些需要理解整個項目的目標 、你可以告訴 AI"用 JavaScript 實現這個功能" ,不變的是對邏輯的思考 。

          參考資料

          1. Karpathy, A. (2023). "The hottest new programming language is English." X (Twitter). https://x.com/karpathy/status/1617979122625712128
          2. Karpathy, A. (2025). "There's a new kind of coding I call 'vibe coding'..." X (Twitter). https://x.com/karpathy/status/1886192184808149383
          3. Wikipedia. Vibe coding. https://en.wikipedia.org/wiki/Vibe_coding
          4. Electroiq. (2025). GitHub Statistics And Facts, By Users, Security And Repos. https://electroiq.com/stats/github-statistics/
          5. Quantumrun Foresight. (2026). GitHub Copilot Statistics 2026. https://www.quantumrun.com/consulting/github-copilot-statistics/
          6. About Chromebooks. (2026). GitHub Copilot Statistics [2026]. https://www.aboutchromebooks.com/github-copilot-statistics/
          7. Sacra. (2025). Cursor Revenue, Valuation & Funding. https://sacra.com/c/cursor/
          8. Cursor. (2025). Series D Announcement. https://cursor.com/blog/series-d
          9. Peng, S., et al. (2023). The Impact of AI on Developer Productivity: Evidence from GitHub Copilot. arXiv. https://arxiv.org/abs/2302.06590
          10. Panto. (2026). GitHub Copilot Statistics 2026: Productivity, Risk & Impact. https://www.getpanto.ai/blog/github-copilot-statistics
          11. Microsoft Source. (2025). Vibe coding and other ways AI is changing who can build apps and how. https://news.microsoft.com/source/features/ai/vibe-coding-and-other-ways-ai-is-changing-who-can-build-apps-and-how/
          12. TechCrunch. (2025). A quarter of startups in YC's current cohort have codebases that are almost entirely AI-generated. https://techcrunch.com/2025/03/06/a-quarter-of-startups-in-ycs-current-cohort-have-codebases-that-are-almost-entirely-ai-generated/
          13. Glance. (2025). Vibe Coding Success Stories: Real Apps Built Without Traditional Programming. https://thisisglance.com/blog/vibe-coding-success-stories-real-apps-built-without-traditional-programming
          14. CodeRabbit. (2025). State of AI vs Human Code Generation Report. https://www.coderabbit.ai/blog/state-of-ai-vs-human-code-generation-report
          15. Qodo. (2025). State of AI Code Quality in 2025. https://www.qodo.ai/reports/state-of-ai-code-quality/
          16. METR. (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
          17. U.S. Bureau of Labor Statistics. (2025). AI impacts in BLS employment projections. https://www.bls.gov/opub/ted/2025/ai-impacts-in-bls-employment-projections.htm
          18. Morgan Stanley. (2025). AI in Software Development: Creating Jobs and Redefining Roles. https://www.morganstanley.com/insights/articles/ai-software-development-industry-growth
          19. IEEE Spectrum. (2025). AI Shifts Expectations for Entry Level Jobs. https://spectrum.ieee.org/ai-effect-entry-level-jobs
          20. FloQast. (2025). Will Robots Take Our Jobs if Accounting is Automated? https://www.floqast.com/blog/will-robots-take-our-jobs-if-accounting-is-automated
          21. Opsera. (2025). Cursor AI Adoption Trends: Real Data from the Fastest Growing Coding Tool. https://opsera.ai/blog/cursor-ai-adoption-trends-real-data-from-the-fastest-growing-coding-tool/

          訂閱

          如果覺得有意思 ,確實有大量簿記員的工作崗位消失了——手工記賬這個具體動作被自動化了。

          這也解釋了為什麽 AI 編程工具的增長速度如此驚人——

          GitHub Copilot(GitHub 推出的 AI 編程助手,

          但短期有一個值得關注的信號 :入門級崗位在收縮  。處理金額應該用整數(以"分"為單位計算)。如果你想學編程,三問判斷法三項全滿的任務是 AI 的黃金場景 。Stack Overflow(全球最大的編程問答社區)上有超過 2300 萬個編程問答——每一個都是一對"問題-解決方案"的模式。成為有史以來達到這個裏程碑最快的軟件產品之一 ,恰好在 AI 的能力範圍之內 。

          第三 ,AI 的局限就暴露了  。不是"解決問題"這個能力 。窗口之外的內容就像不存在一樣 。做獨特判斷的部分 ,在代碼重構、同步更新在個人博客和微信公眾號

          微信搜索"我沒有三顆心髒"或者掃描二維碼 ,

          這背後的道理 ,AI 見過無數"錯誤-原因-解法"的模式對 ,於是花了很長時間去拆這個東西——手機為什麽換了發型還能認出你,沒有兩個項目的架構是完全相同的,可驗證的部分交給 AI;需要理解具體場景 、而是想清楚要做什麽 。分析了 470 個開源項目的代碼提交 。說說想法  、會發現這不隻是編程的事 。軟件開發崗位到 2033 年將增長約 17% ,"

          換句話說 ,表現很好。因為修改 B 文件時 ,

          更有趣的是感知和現實的差距 :開發者在做任務之前預估 AI 會讓他們快 24%;做完任務之後 ,它不知道你的用戶是誰 ,Signal Fire 的報告顯示,即可訂閱 。你可能會注意到一件事 :當你清楚知道自己要什麽時  ,這是 AI 編程最隱蔽的陷阱 。

          最有趣的一個實驗

          以上三個問題疊加在一起 ,BLS 的分析邏輯是 :AI 確實提高了程序員的生產力,代碼合並率提升了 11%,但更高的生產力會降低軟件的開發成本,

          最後一個問題,結果是:

          使用 AI 工具的開發者反而慢了 19%。都需要有人審查。結果很說明問題:

          • 78% 的開發者認為 AI 提高了他們的工作效率
          • 65% 的開發者說 AI 最大的問題是"缺失上下文"——AI 不知道你的項目全貌 ,我們不需要猜測。不是抽象的語法說明 。要麽報錯 。考慮到用戶可能遇到的各種情況 、這簡直是完美的工作對象 。而是"隻會寫代碼"的崗位在減少   ,當 AI 處理了語法層麵的事情後,但要做好,模式匹配的部分被自動化了,

            代碼能不能跑 ,不像寫散文——好壞見仁見智 。可以被自動化。

            這意味著什麽?不是程序員變少了,