一个人给 AI 编辑器搭了“四层质量闸门“：AI 写完自己查、自己修、跑通才交付

## 背景：AI 生成代码最大的问题不是写不出来

现在 AI 生成代码的工具很多，但我用下来发现一个共性痛点：它们只负责生成，不负责结果。

代码贴给你之后呢？语法错了谁管？单测谁写？跑不起来怎么办？环境谁配？

所以我做了一个 AI 代码编辑器（AimCode），核心思路只有一句话：交付能跑的结果，而不是交付代码。

这篇文章聊聊支撑这句话的核心机制——四层质量闸门，以及一个人开发时踩过的坑。

整体流程

用户输入一句话需求（比如"做一个学生成绩管理系统"），后端流程是这样的：

用户需求 → LLM 规划架构 + 拆分文件 → 多文件代码生成 → 闸门1：语法检查 → 闸门2：单元测试生成与执行 → 闸门3：失败自动修复（错误信息回喂 LLM） → 闸门4：运行验证（编译/启动/探活） → 通过才交付，弹 diff 预览给用户确认写入 内测期统计下来，这套闸门放行的项目一次编译通过率 98%——注意这不是"生成得准"，而是"没跑通的压根不会到用户手上"。 闸门设计的关键决策 1. 语法检查放最前面，成本最低拦截最早 生成完先做静态语法校验（按语言选编译器/解释器 --check 模式），这一层拦截了大部分低级错误，避免后面更贵的单测和运行环节浪费轮次。 2. 单测由 AI 自己写，但执行环境要隔离 AI 给自己写的代码生成单测，然后跑在临时目录里。一定要隔离——我早期吃过亏：生成的代码里有个死循环，直接把我主进程卡死了。 3. 自动修复有轮次上限，防止死循环 修复的本质是把失败输出（报错栈/测试失败信息）回喂给模型重新生成。这里最容易出事的是修复死循环：模型反复给出同样错误的代码。 我的方案是轮次上限 + 每轮失败信息截断拼接，超过上限直接标记"该文件需人工介入"，宁可诚实地失败，也不要无限烧 token。 4. 运行验证是唯一诚实的标准 前三层都过了，最后还是要真的把它跑起来：编译/启动 → 探活接口 → 确认进程活着。这一层没法偷懒，也是用户感知最强的一层——"它真的能跑"和"它应该能跑"之间差着十万八千里。 一个人开发踩过的坑 LLM 幻觉：模型会自信地调用不存在的 API，闸门是唯一的防线 Windows 打包：Electron 类桌面应用 + Node 后端 + MySQL，安装包签名和路径兼容占了我不小的精力 成本控制：每次修复轮次都是真金白银的 token，轮次上限设计既是质量兜底也是成本兜底 写在最后 这个编辑器叫 AimCode，已上架微软商店：https://apps.microsoft.com/detail/9NQ2LBX0CFMX 官网也可以直接下载 Windows 版：twinclawai.com 正在开放内测（免费名额，注册送体验积分），欢迎各位来踩——特别是让它生成你们熟悉领域的项目，看看闸门放出来的代码到底几斤几两。骂声和 PR 一样珍贵。 PR 一样珍贵。