AI 写代码，真正难的是让人愿意合并

很多人评价 AI 写代码，第一反应是看测试能不能过。这个标准当然重要，但它远远不够。真实项目里的代码不是一次性答案，而是会被团队继续阅读、修改、排障、扩展和维护的资产。

Cognition 发布的 FrontierCode 把这个问题摆到了台面上：AI 编程评测不能只看“代码是否正确”，还要看它是否真的达到可以合并进生产项目的标准。

这件事值得关注，不是因为又多了一个 benchmark，而是因为它击中了 AI 编程落地里最容易被忽略的问题：能写出来，和能进仓库，是两件事。

测试通过只是工程质量的下限

在真实开发里，测试通过通常只说明一件事：当前测试覆盖到的路径没有失败。它不能自动证明代码设计合理，也不能证明没有遗漏边界，更不能证明未来维护成本可控。

一段 AI 生成的代码可能有这些问题：

• 改动范围过大，顺手重写了不该碰的模块；
• 为了通过当前测试，写了脆弱的特殊判断；
• 新增测试只覆盖 happy path，没有覆盖异常和边界；
• 命名、抽象和项目风格不一致，后续维护者读起来费劲；
• 引入安全风险，但普通单元测试不会暴露；
• 修掉一个问题，又把另一个场景弄坏。

这些问题不一定会在第一次运行测试时爆出来，但会在后续维护中不断消耗团队时间。AI 编程如果只追求“能跑”，很容易把成本转移到未来。

FrontierCode 的关键变化：把维护者判断放进评测

FrontierCode 的方向，是用更接近真实开源和生产工程的标准来评估 AI 生成代码。它关注的不只是功能正确性，还包括代码是否高质量、可维护、适合合并。

这个方向比传统 coding benchmark 更接近团队真实需求。因为维护者 review 一个 PR 时，通常不会只问“测试过了吗”，还会问：

• 这个改动是不是解决了真正的问题？
• 有没有引入不必要的抽象？
• 是否符合项目已有风格？
• 测试是否证明了关键行为？
• 有没有隐藏回归？
• 未来别人接手时能不能读懂？

这些判断很难压缩成一个简单分数，但它们才是代码能不能进入项目的核心。

AI coding agent 越强，合并标准越重要

过去我们用 AI 写代码，常见模式是让它补一个函数、写一段脚本、解释一段报错。风险相对可控，因为人类仍然掌握主要上下文。

现在情况变了。越来越多工具开始支持长时间代理式开发：读仓库、拆任务、改多个文件、运行测试、修复失败、继续迭代。能力变强以后，风险也变了。

一个 agent 如果可以连续修改几十个文件，但团队没有清晰验收标准，就会出现一种危险错觉：它跑完了，所以它完成了。

真正稳的做法应该反过来：AI 越能自主执行，团队越需要更严格的合并门槛。不是为了降低效率，而是为了避免把不可维护的改动快速带进主分支。

对团队的实践建议

第一，把“可合并”拆成清单。

不要只写“通过测试即可”。更好的检查项包括：改动范围是否最小、是否符合项目架构、是否新增关键测试、是否影响安全边界、是否更新必要文档、是否有回滚方式。

第二，让 AI 输出证据，而不是只输出结论。

一个可靠的 coding agent 应该告诉你它改了什么、为什么改、运行了哪些命令、哪些测试通过、哪些地方没有覆盖。没有证据的“已完成”，在工程里价值很低。

第三，保持小步提交。

AI 很容易一次性改大块内容。人类团队要主动把任务切小，让每次 diff 都能被 review。小步提交不只是流程习惯，也是风险控制。

第四，不要把测试当唯一审计。

测试是必要条件，不是充分条件。安全扫描、类型检查、lint、代码 review、依赖审计和运行日志同样重要。尤其是认证、权限、文件、网络、支付、数据库等区域，AI 输出必须更谨慎。

第五，区分“原型代码”和“可合并代码”。

AI 很适合快速做原型，但原型能跑不代表能长期维护。团队要允许 AI 快速探索，也要明确进入主仓库前需要经过哪几道门。

普通开发者能学到什么

如果你是个人开发者，FrontierCode 这样的评测也有直接启发：不要把 AI 给出的代码当成最后版本。

更稳的使用方式是：

• 先让 AI 解释方案和可能风险；
• 再让它小范围改代码；
• 自己读 diff；
• 跑测试和静态检查；
• 让另一个模型或工具做一次 review；
• 最后再合并。

这听起来比“复制粘贴直接运行”慢，但长期看更快。因为真正浪费时间的，往往不是写代码，而是排查那些看似能跑、实际埋雷的代码。

Kunpeng AI 观察

FrontierCode 代表的不是一个孤立评测，而是 AI 编程进入下一阶段的信号：我们正在从“AI 会不会写代码”，走向“AI 写出来的代码能不能进入真实团队”。

这和我们在 Agent workflow、Harness Engineering、GEO / AI Search 里反复强调的逻辑一致：不要只看输出，要看证据链；不要只看一次成功，要看长期可复查；不要只追求自动化，要给自动化加上边界、审计和回滚。

AI 写代码不是坏事。相反，它会继续成为开发者的重要能力。但越是重要，越不能用玩具标准去验收。未来真正成熟的 AI 编程工作流，核心不只是“生成”，而是“生成之后如何被可信地合并”。

参考来源

• Cognition: Introducing FrontierCode
• Latent Space: AINews: FrontierCode: Benchmarking for Code Quality over Slop
• arXiv: An Empirical Evaluation of LLM-Generated Code Security Across Prompting Methods
• arXiv: Minimal Prompt Perturbations Lead to Code Vulnerabilities