Stephan_

看完了老羅採訪周鴻禕的三個半小時的播客，能聽出來老周是確實有很多切實的行業經驗的，可惜老羅問的問題不夠深入和專業，有點遺憾
比如老羅說到海外頂尖模型是這個觀點，我覺得是有些偏頗了。因爲不同領域有不同的最佳模型，比如在編程領域目前claude-4和gpt-5-codex可能都優於；又比如老周不止一次提到的LLM幻覺問題，在360是如何優化的？並沒有追問下去
聽完整體感覺最有價值的點就是老周說到的垂直+訂閱的收費模式，老周還提到收費模式上應該是token按量計費+membership會員費的方式，這種方式確實是一種長期看更可行的收費模式。單純賣token的模式壁壘太低，用戶付費的動機應該是在LLM之上，產品提供的垂直Agent的能力

OpenAI 发布了一篇 "GPT-5 编码指南", 给出了6条使用GPT-5进行AI编程的最佳实践：
# 1. 指令应精确，避免信息冲突
新款GPT-5模型在遵循指令方面的能力有了显著提升，但这也带来一个副作用：当面对模糊或相互冲突的指令时，它可能会难以处理。这种情况在你的 .cursor/rules 或 配置文件中尤其需要注意
# 2. 设定合适的推理级别
GPT-5 在解决问题时总会进行一定程度的推理。若想获得最佳效果，处理复杂任务时应使用 "high reasoning effort" 。如果你发现模型对简单问题有“想太多”的倾向，可以给出更具体的指令，或选择 medium 或 low 的推理级别
# 3. 使用类似XML的语法来帮助结构化指令
我们与Cursor合作发现，使用类似XML的语法可以为模型提供更多上下文，从而使GPT-5更好地工作。例如，你可以给模型以下编码指南：


- 每个组件都应该是模块化和可重用的


- 样式：TailwindCSS


# 4. 避免使用

爲啥我用AI結對編程的感覺是，它能給我的輸入比輸出要有價值的多😅
經常讓它幫我在開源代碼倉庫裏找有價值的信息、梳理系統架構，總能給我非常不錯的體驗
但如果讓它寫代碼體驗就很差，它寫的代碼不放心，自己得review一遍，review完總能發現一些或大或小的問題，然後就得不斷修修補補
難道這就是古法編程程序員在面對vibe coding時最大的障礙：不敢放手😂
而且這和帶實習生感覺還不一樣，聰明的實習生磨合一陣就會越帶越順手了，我知道實習生會犯錯，但也知道他會成長。但AI不會啊，它的全局記憶都需要我給它灌😤

那麼如果推理速度快20倍，我們vibe coding的方式會有什麼變化呢？

我感覺隨着AI編程工具的發展，我對MCP工具的理解也在改變
之前常用的 sequential thinking、task_manager，現在隨着模型計劃和推理能力的提升，有了plan mode和think harder/ultrathink，我更願意在原生工具內部完成，而不是借助mcp
另一類是context7、deepwiki這類上下文增強工具，對於上下文工程，我需要更加精細化和準確，這類mcp目前還無法達到這個要求。所以我更傾向於自己深度整理而不是使用mcp
上下文整理的過程可能會借助Deep Research和NotebookLM等外部工具，在代碼之外，先收集好高質量、且足夠全面的上下文
還有一類能提高測試效率和準確度的mcp工具我是推薦的，比如playwright mcp
總結一下就是，mcp工具應該作爲AI編程能力的延伸，就像手腳的作用，而不是增強大腦

Deep Research解決“構建什麼”的產品化決策問題，它兼具深度和廣度，幫助我們打破信息繭房，看清方向
Claude Code幫助解決具體的實施細節，讓我們有精力更focus在系統架構、模塊拆分和重構這些high level層面，提升迭代和試錯效率
未來肯定會有更先進的AI生產力工具，但以上三步我認爲應該是不變的底層邏輯

MCP出來這麼久了，真正能用的好像沒幾個？
我指的能用指的是對於AI編程，能夠穩定且高頻使用，對編程效果有實質性提升的
分享幾個我認爲還可以的：playwright、Context7、Sequential Thinking
前兩個解決上下文準確性問題，第三個解決規劃思考

程序設計領域，有一個詞叫“bad smell”
說的是對於有經驗的程序員，應該能嗅到系統中的“壞味道”，而提前預防，進行架構優化和升級
還有一個詞叫“過度設計”
就是說一開始想的太多，設計了很多沒有必要的可擴展性和模塊解耦，帶來龐大且無用的維護成本，反而容易引入bug
這兩個詞，都是需要放在時間和語境裏來看的
沒有最好的架構設計，只有最合適當下（以及未來一段時間）的架構設計
這個度的把握，目前的AI還遠遠做不到
但是引入AI之後，讓我們能用更多的時間來思考架構，去在合適的時機進行重構、解耦、拆分或合並
這就是人的價值

程序員最喜聞樂見的就是，各大AI廠商卷上天😂
剛註冊了下Jules，好像可以免費試用

Google家又要放大招了？

vibe coding真的要在懂編程的人手裏才有作用，不懂的就是💩山和各種安全漏洞😅

非常棒的經驗，內容營銷、流量、獲客、轉化、品牌、設計、競爭壁壘、合作放大，各個方面都需要思考和執行
AI時代，最不缺的就是idea和研發能力了😂

恭喜恭喜，值得學習👍
希望有更多像熠輝這樣賣課的人，讓“賣課”這個詞變得不再那麼負面
想想看什麼樣的知識付費博主能成功，我總結以下幾點：
真誠、利他、價格合適、快
真誠：做自媒體的根基，無論賣什麼，首先都要和你的客戶建立信任關係。真誠的輸出自己的知識和認知，不端不裝，人設才不容易崩
利他：不爲了滿足自己而輸出，而是隨時站在市場的一邊，站在用戶的一邊，輸出真正有價值、能解決用戶痛點的內容
快：這個快不僅僅是快速切入市場，我認爲更重要的是快速迭代和試錯。不要想着做一個完美的產品，而是快速推出MVP，得到市場的驗證和反饋，比閉門造車要強100倍

這個方法來制作AI rules看起來不錯，準備嘗試一下，等試完回來報道！感謝分享☺️

很贊同吳恩達老師的觀點，AI輔助編程確實可以讓已有編程語言基礎的人可以快速上手一門新語言，同時他也強調了理解語言背後的核心概念的重要性：
---
但是，理解不同語言背後的概念仍然很重要。這就是爲什麼學習至少一門像 Python 這樣的語言，仍然能爲你打下堅實的基礎，去更好地提示 LLM 生成 Python 或其他語言的代碼。如果你從一種編程語言轉向另一種能完成類似任務但語法不同的語言——比如，從 JS 到 TS，或者 C++ 到 Java，或者 Rust 到 Go——一旦你掌握了第一門語言的概念，你也就掌握了提示 LLM 用第二種語言編寫代碼所需的大部分概念。（雖然 TensorFlow 和 PyTorch 不是編程語言，但學習了 TensorFlow 背後的深度學習概念，同樣能讓你更容易地讓 LLM 爲你編寫 PyTorch 代碼，反之亦然！）此外，你也能看懂大部分生成的代碼（可能需要 LLM 稍微幫你解釋一下）。
不同的編程語言反映了組織計算的不同思路，理解這些概念依然很重要。比如，如果一個人不理解數組、字典、緩存和內存這些概念，那麼他讓 LLM 用大多數語言寫代碼時，效果就會差一些。
同樣地，一個想用 JS 做更多前端開發的 Python 開發者，如果能學習一些前端系統背後的概念，將會受益匪淺。比如，如果你想讓 LLM 用 React 框架構建前端，那麼理解以下內容會對你很有