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 文档中心