由Linux內核專家Chris Mason編寫的人工智慧輔助代碼審查提示可以加快Linux內核和Systemd補丁審查過程。它可以通過bash腳本輕鬆安裝，然後在Claude等工具中使用/kreview和/kdev等斜線命令。這些命令自動加載項目上下文，將巨大的差異分解為子任務，將Token成本降低40%-60%，並發現更多漏洞。
利用收入：
- 代碼審查速度提高30%-50%
- 降低成本、減輕疲勞
- 在不取代手動審查的情況下提高代碼質量
支持GPT-4、Claude等型號，搭配semcode具有最佳導航效果。
有些項目乍一看會「非常簡單」，甚至有點簡單而難以提及--沒有複雜的架構，沒有華麗的UI，也沒有一堆自動化管道。但當你真正使用它後，你會發現它悄悄地改變了你。您思考代碼的方式。
審閱提示就是這樣一個項目。
它的作者是Chris Mason，他是Linux內核開發的長期參與者。所以這個項目以一種明顯的氣質開始：它不是為了教你「如何寫代碼」，而是為了教你如何懷疑代碼。
許多人使用人工智慧的方式實際上是相似的：編寫代碼、完成代碼和更改錯誤。但很少有人認真思考一件事--人工智慧能幫你做「代碼審查」嗎？而且不是那種溫和的建議，而是一種接近核心社區風格的評論：直接、嚴格，甚至有點無情。
這個項目所做的事情本質上是受到限制的。它不會嘗試構建一個複雜的系統、實現自動差異分析或將其包裝到一個完整的代理中。它只是提供了一組精美的提示，例如 /kreview、/kdev 此類命令的本質是「角色設定+審查策略」。
但關鍵是，這些提示的編寫方式與你平時隨意詢問AI的方式完全不同。
您可能會問：「這個代碼有問題嗎？"
人工智慧通常會給你一個禮貌甚至保守的答案。
在這個項目中，問題被重寫為另一種形式--更像現實世界的代碼評論：
作為長期維護複雜系統的工程師，請識別此更改最可能出現的問題，包括邊界條件、性能下降和潛在的並發風險。
僅僅這個角度的改變就會導致輸出質量的顯著變化。
您會開始看到容易忽視的事情，例如：
- 極端輸入下分支就會崩潰
- 變化引入了不必要的鎖競爭
- 長期維護過程中某些邏輯變得難以理解
這些並不是人工智慧「更聰明」，而是你把它放在一個更合適的位置。
這也是這個項目真正有趣的部分。它並沒有試圖讓人工智慧成為「更強大的程式設計師」，而是讓人工智慧更像是一個你通常覺得很難扮演的角色：一個願意不斷質疑你的評論員。
如果您寫過有關項目的文章，尤其是多人協作的文章，您可能知道好的代碼審查實際上很稀缺。許多評論要麼只是形式，要麼由於時間壓力而變得「只是一瞥」。隨著時間的推移，代碼的質量不會突然崩潰，而是慢慢變得不可控制。
審核提示提供了一種「低成本模擬」：您可以讓人工智慧在本地和提交之前充當最嚴格的審核者，提前暴露問題。
它甚至可能在某種程度上改變您編寫代碼的方式。因為當你習慣了在提交之前被挑剔時，你就會開始在編寫代碼時提前思考：
- 這個功能的邊界在哪裡？
- 是否有隱藏的副作用？
- 如果我是評論家，我會詛咒哪一段？
這種思維本身就是核心開發等工程文化的核心。
當然，對於這個項目存在很多誤解。有人會將其描述為「自動代碼審查系統」，甚至說它可以自動拆分差異，並降低一定數量的代幣成本。事實上，這些並不是它本身正在做的事情。它沒有複雜的工程能力，也不是一個完整的代理。
它更接近一個非常簡單的工具：
一個小組將「如何詢問人工智慧」的問題變得更加專業。
但正是因為它很簡單，所以更容易嵌入到您自己的工作流程中。
例如，如果你正在做一些人工智慧項目、自動化流程或撰寫博客或視頻，你實際上可以使用相同的一組想法：在「生成內容」之後，添加「審查」步驟。讓人工智慧發現問題，而不僅僅是負責輸出。
寫完文章後，你可以要求它從「讀者是否會無聊」的角度進行批評。
設計一個您可以從「失敗路徑」的角度分解的代理流程。"
即使你在學習物理，你也可以讓它專門發現你推導中的漏洞。
當你將人工智慧從「創造者」轉變為「審查者」的那一刻，它的價值實際上開始放大。
畢竟，審查提示的作用很簡單，但它會提醒您一些容易被忽視的事情：
真正拉開差距的不是你能寫多少代碼，而是你是否能發現哪些代碼不應該以這種方式寫。
這種能力原本很大程度上依賴經驗。但現在，你有了一個可以隨時調用的「外部大腦」，前提是你必須學會以正確的方式詢問它。
Github：https://github.com/masoncl/review-prompts
輸油管：