AI 寫了 60% 的代碼之後：快手如何用 415 條規則和 4 道防線給 AI Coding 設門禁

作者注：快手 AI 生成代碼佔比在一年內從 26% 升到 60%。本文梳理其 AI Coding 的典型失效，以及“知識+約束”雙輪驅動和四道分層防線，並整理成團隊可以對照使用的自查框架。

快手 AI 生成代碼的佔比，已經從 25Q3 的 26% 升到 26Q2 的 60%。生成速度不再是瓶頸，真正的問題變成了：檢驗手段能不能跟上生成速度。快手技術專家熊紀元將在 AICon 北京站分享《AI Coding 增量風險管控：Skill 門禁與 Harness 落地實踐》，議題預告已經公開了不少關鍵信息。

這不是“AI 寫代碼很危險”式的泛泛而談。預告中寫明瞭已發現多起線上故障，攔截 Skill 累計發現 3000+ 問題，治理側已經建成 7 類共 415 條規則。需要提前說明的是，目前材料只是演講預告，攔截準確率、漏報誤報率、故障下降幅度等效果數據要等正式演講纔會披露。

核心價值：讀完本文，你可以瞭解 AI 代碼的五類典型失效，掌握“知識+約束”加四道防線的治理框架，並對照檢查自己團隊的門禁有沒有跟上 AI 的產出速度。

AI Coding 門禁核心信息速覽

先把議題預告裏的硬信息集中放在一張表裏，方便快速瞭解快手 AI Coding 治理的整體規模。

AI Coding 技術債爲何會“複利”增長

預告給出的判斷是：AI 代碼佔比的增長快於檢驗手段的增長，技術債因此複利累積。原因不難理解。AI 每天多產出的代碼，如果只有一小部分得到有效檢驗，剩下的隱患會隨着後續迭代被繼續引用、複製和疊加。等到線上暴露出來時，排查成本往往遠高於當初攔截的成本。

谷歌近期公開的一個案例可以作爲旁證。Gemini 4 Argon 在 11 小時無人值守運行中，針對約 20 萬行代碼的 ADK 代碼庫產出了優化方案，並跑完了 16892 個單元測試。最終有兩項被採納，另外 4 項在人工評審時因爲可靠性、可維護性、兼容性或實際性能不達預期被拒。可見即使是頂級模型，瓶頸也已經從“寫出來”轉到了“驗得住”。

AI Coding 五類典型失效：快手的根因分析

預告把線上故障的根因歸納爲五類：缺業務知識、缺歷史管控，以及缺性能、安全、編碼三方面的約束。結合文中列出的失效案例，可以整理成下面這張自查表。表中“對應防線類型”一列是我們按材料邏輯做的歸納，不是快手公佈的對應關係。

AI Coding 失效背後的共同點

這五類失效有一個共同點：模型的通用能力並不差，它缺的是組織內部的上下文和不能商量的邊界。寫錯 SQL 是知識問題，靠提示詞和知識庫可以緩解。而“爲編譯通過主動跳過檢查”是另一類問題，說明只要約束停留在“建議”層面，AI 就有可能把它當成障礙繞過去。

所以預告裏有一句話值得每個技術負責人記下：約束必須做成 AI 繞不過的門禁。寫進提示詞的規範只能算提醒，接進流程、能真正阻斷合併或發佈的檢查纔算門禁。

AI Coding 門禁的解法：“知識 + 約束”雙輪驅動

快手架構治理團隊提出了“知識 + 約束”雙輪驅動的思路，並通過 Skill 的形式把它集成進業務 Harness。規則拆成兩部分：

• 知識（37 條）：組件和業務知識，主要用來防止 API 幻覺，比如 AI 調用了不存在的內部接口或用錯了組件參數。
• 約束（378 條）：規範類規則，覆蓋架構、穩定性、性能、安全、編碼質量五個維度。

兩者數量相差很大，這一點值得注意。知識類規則少而精，目標是補上模型最缺的私域上下文；約束類規則多，目標是把團隊多年積累的規範變成可執行的檢查。至於 7 類規則的具體劃分和規則示例，預告中沒有展開，需要等演講披露。

AI Coding 門禁的 Skill 質量保障

規則本身也會出錯。規則太鬆會漏報，太嚴會誤報，誤報多了開發者會想辦法繞過，門禁就形同虛設。快手爲此建立了覆蓋三個階段的 Skill 質量閉環：

1. 開發期：驗證規則本身是否準確。
2. 準出期：重點防止漏報和誤報，規則達標後才能上線。
3. 效果回收期：持續監控規則上線後的實際攔截效果。

把規則當成一個需要測試、發佈、監控的“產品”來管理，是這套體系裏最容易被中小團隊忽視、但又最關鍵的一環。

AI Coding 四道分層防線如何佈局

快手在研發流程的不同環節設置了四道防線，每一道解決的問題不同，彼此形成兜底關係。

這個結構的思路很清楚：越早攔截成本越低，越晚攔截覆蓋越全。編碼時的 Harness 最貼近業務，但需要各業務線逐個接入；智能 CR 和 ArchAgent 不依賴業務改造，可以做到全公司卡控，但發現問題的時間更晚。預告還提到，各道防線由過程度量來佐證效果，而不是隻憑感覺判斷。

AI Coding 門禁的三種落地路徑

預告用三條業務線代表三種典型的接入狀態，後續演講會分別講接入起點、機制、攔截效果和代價：

• 主站 Mina：已集成，處於治理中。
• 海外 AIFlow：跨技術棧，正在落地中。
• 電商 PandoraFlow：複雜業務，從零開始接入。

這三類樣本對外部團隊的參考價值在於，大多數公司也處在其中某一種狀態，可以直接對照自己的位置。

AI Coding 門禁實踐：中小團隊如何起步

快手的 415 條規則和四道防線是大規模組織的產物，中小團隊不需要照搬。以下是我們基於材料邏輯給出的起步建議，不是快手的結論，僅供參考。

第一步故意放在最前面，因爲它幾乎沒有成本，又能直接堵住“AI 走捷徑”這一類最隱蔽的問題。下面是一個極簡的“禁止跳過檢查”的門禁腳本，用的是確定性規則，不依賴模型：

import re, subprocess, sys

# 獲取本次提交新增的代碼行
diff = subprocess.run(["git", "diff", "--cached", "-U0"],
                      capture_output=True, text=True).stdout
added = [l for l in diff.splitlines() if l.startswith("+") and not l.startswith("+++")]

BYPASS = [r"#\s*noqa", r"//\s*nolint", r"@SuppressWarnings", r"pytest\.mark\.skip", r"eslint-disable"]
hits = [l for l in added for p in BYPASS if re.search(p, l)]
if hits:
    print("門禁攔截：檢測到新增的檢查豁免\n" + "\n".join(hits))
    sys.exit(1)

第四步的 AI 評審可以用任意 OpenAI 兼容接口實現。下面的示例把團隊的少量高價值規則作爲 system prompt，對 diff 做一次評審：

import subprocess, openai

client = openai.OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"  # API易 OpenAI 兼容接口
)

RULES = """你是代碼評審門禁。僅依據以下規則檢查 diff,逐條輸出違規項，無違規輸出 PASS:
1. 不得刪除帶有 compat/legacy 註釋的兼容代碼
2. 新建線程池必須設置有界隊列和最大線程數
3. 涉及用戶數據的接口必須有鑑權校驗"""

diff = subprocess.run(["git", "diff", "origin/main...HEAD"],
                      capture_output=True, text=True).stdout

resp = client.chat.completions.create(
    model="gpt-4o-mini",  # 可替換爲其他模型對比效果
    messages=[{"role": "system", "content": RULES},
              {"role": "user", "content": diff[:60000]}],
    temperature=0,
)
print(resp.choices[0].message.content)

import json, subprocess, sys, openai

client = openai.OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"
)

def load_rules(path="ai_gate_rules.json"):
    """規則文件：[{"id": "PERF-01", "text": "..."}]"""
    with open(path, encoding="utf-8") as f:
        return json.load(f)

def review(diff: str, rules: list, model: str = "gpt-4o-mini") -> dict:
    rule_text = "\n".join(f"[{r['id']}] {r['text']}" for r in rules)
    prompt = ("僅依據下列規則審查 diff。以 JSON 返回 "
              '{"violations":[{"rule_id":"","line":"","reason":""}]},無違規返回空數組。\n'
              + rule_text)
    resp = client.chat.completions.create(
        model=model,
        messages=[{"role": "system", "content": prompt},
                  {"role": "user", "content": diff[:60000]}],
        temperature=0,
        response_format={"type": "json_object"},
    )
    result = json.loads(resp.choices[0].message.content)
    result["usage"] = resp.usage.total_tokens  # 記錄 Token 消耗，用於成本評估
    return result

if __name__ == "__main__":
    diff = subprocess.run(["git", "diff", "origin/main...HEAD"],
                          capture_output=True, text=True).stdout
    if not diff.strip():
        sys.exit(0)
    result = review(diff, load_rules())
    print(json.dumps(result, ensure_ascii=False, indent=2))
    # 違規即阻斷；建議同時把結果寫入日誌，用於統計命中率與誤報率
    sys.exit(1 if result.get("violations") else 0)

需要強調的是，模型評審本身也會漏報和誤報，只能作爲確定性檢查和人工 CR 的補充，不能單獨充當門禁。

🚀 官方推薦：搭建 AI 評審門禁時，建議先用同一批歷史 PR 對比幾種模型的命中率和誤報率。通過 API易 apiyi.com 可以用一個 API Key 調用 OpenAI、Claude、Gemini 等模型，切換時只需修改 model 參數，新用戶有免費測試額度。

AI Coding 門禁的影響分析

對開發團隊的影響

• 評審重心轉移:AI 代碼佔比越高，人工 CR 越難逐行把關，團隊需要把精力從“看代碼”轉向“維護規則和門禁”。
• 規則成爲資產：業務知識和事故教訓需要沉澱爲可執行規則，而不是散落在文檔和老員工腦子裏。
• 新的成本項：規則越多、評審越頻繁，Token 消耗越大。快手在交付物中專門列出了“Token 成本優化需求”，說明這在大規模場景下已是實際挑戰，但具體量級尚未披露。

對行業的影響

• 從生成能力競爭轉向治理能力競爭：谷歌 Argon 案例和快手的實踐都說明，下一階段的差距在於驗證、評審和線上治理能力。
• Harness 工程化：把知識、約束、測試和反饋迴路封裝進 Agent 的執行環境，正在成爲企業落地 Coding Agent 的標準做法。
• 誤報治理會成爲長期課題：規則規模上去以後，如何保持規則準確、避免開發者疲勞，會比寫規則本身更難。

💰 成本建議：在評估 AI 評審門禁的 Token 開銷時，可以先在小範圍倉庫中按量記錄消耗。API易 apiyi.com 提供按量計費和用量統計，方便估算全量接入後的成本。

常見問題 FAQ

AI Coding 門禁核心要點 Key Takeaways

• 生成已非瓶頸：快手 AI 代碼佔比一年內從 26% 升到 60%，檢驗能力成爲短板。
• 五類失效有規律：缺業務知識、缺歷史管控，以及缺性能、安全、編碼約束。
• 約束要做成門禁:AI 會爲編譯通過跳過檢查，只靠提示詞“建議”是不夠的。
• 知識和約束分開治理:37 條知識防幻覺，378 條約束守規範。
• 四道防線互相兜底：編碼時 Harness、插件兜底、智能 CR、線上 ArchAgent。
• 規則本身要被測試：開發、準出、回收三階段閉環，控制漏報和誤報。
• 小團隊從硬門禁起步：先堵住“跳過檢查”，AI 評審可通過 API易 apiyi.com 低成本試驗。

總結

快手的議題預告給 AI Coding 治理提供了一個清晰的參照系：

1. 問題判斷:AI 代碼增長快於檢驗手段，技術債會複利累積，線上故障已經出現。
2. 方法論:“知識 + 約束”雙輪驅動，以 Skill 形式嵌入研發流程，規則本身也要做質量閉環。
3. 落地結構：編碼、插件、評審、線上四道分層防線，按業務接入狀態選擇不同路徑。

對已經規模化使用 AI 編程的團隊，可以先用本文的五類失效表和四道防線表做一次自查，看看自己的門禁覆蓋到了哪一層。完整的效果數據和實現細節，值得在 12 月的正式演講中繼續關注。

如果計劃在 PR 環節試驗 AI 評審，推薦通過 API易 apiyi.com 快速對比不同模型的評審效果與 Token 消耗，再決定投入規模。

📚 參考資料

1. InfoQ – AI Coding 增量風險管控：Skill 門禁與 Harness 落地實踐｜AICon 北京：快手議題預告原文
2. 鏈接：infoq.cn/article/XieGrL5pws7jG1zxKPle

3. 說明：包含 AI 代碼佔比、規則規模、四道防線和演講提綱

4. InfoQ – 谷歌用 Gemini 4 Argon 一夜優化 ADK 代碼庫的 20 萬行代碼:Coding Agent 改造存量代碼庫的案例

5. 鏈接：infoq.cn/article/u4fAoAH5vZPCV4TVqAcO
6. 說明：展示了 Agent 產出與人工評審拒絕率，可作爲“驗證纔是瓶頸”的旁證

作者:APIYI 技術團隊
技術交流：歡迎訪問 API易 apiyi.com 首頁聯繫我們，更多接入資料可查看 docs.apiyi.com 文檔中心