随着 AI 编码工具的普及，由模型生成但实际不可运行的代码（“幻觉”）的问题日益凸显。本文深入剖析了导致 AI 代码生成失效的根源，即原始终端输出作为大模型上下文的局限性。文章系统介绍了一种基于 TypeScript 编译器 API 提取结构化诊断信息，并结合 Vitest 程matic 测试运行器捕获测试失败的技术方案。通过搭建“Agent TDD 闭环 harness”，实现了代码生成、编译检查与测试验证的自动化迭代。实验数据表明，该方法显著降低了 token 消耗，并大幅提升了代码修正成功率。文章还诚实地列举了方案的边界与局限性，并展望了未来在更广阔语言生态中的应用潜力，为构建可靠的 AI 编码代理提供了可落地的技术路径。
为什么 AI 编码助手总是“胡说八道”？
在当前的生成式 AI 浪潮中，编程辅助工具已成为开发者日常工作的重要组成部分。无论是 GitHub Copilot 还是 Cursor，这些基于大语言模型（LLM）的系统都展现出了惊人的代码生成能力。然而，任何尝试过自动化重构或让 AI 完成复杂功能的开发者都深知一个顽固的痛点：AI 明明写出的代码语法看起来无懈可击，却往往在编译或运行阶段崩塌。这种现象在 TypeScript 等静态类型语言中尤为明显。
为什么会这样？核心原因在于大模型处理代码时，往往缺乏对代码实际执行环境的实时感知。传统的 AI 编码流程通常遵循“生成-提交”模型：模型根据提示词输出代码片段，开发者手动检查或运行测试发现问题，然后人工将错误信息反馈给模型进行修正。这种人工闭环不仅效率低下，而且每一次反馈都会消耗大量的上下文 token，导致成本飙升和上下文窗口溢出。
原始终端输出的盲区
现有的许多 AI 编码代理在面对编译错误时，只能依赖粗线条的终端输出文本。这些文本往往包含大量噪声、路径信息和非结构化的堆栈追踪，对于大模型来说，解析其中的关键修正点极其困难。模型需要自行从海量的错误日志中定位问题所在，这不仅增加了Token的消耗，更容易因为信息过载而产生方向性错误，导致修正后的代码依然存在根本性缺陷。
结构化诊断：从“盲”到“眼”的跨越
要打破这一僵局，本文提出的核心思路是利用 TypeScript 编译器 API 提供的结构化诊断能力。与其让模型去解析混乱的文本输出，不如在编译阶段就捕获精确的类型错误信息，并以机器可读的 JSON 格式返回。
TypeScript 编译器 API 允许开发者以编程方式访问编译过程中的所有详细信息。通过该接口，可以提取出包括错误类型、错误位置、受影响的源文件以及具体的错误描述在内的结构化数据。这种机器友好的格式，意味着大模型不再需要进行模糊的自然语言理解，而是可以直接定位问题的代码行和列，获知错误的本质（如未定义的变量、类型不匹配等）。这种“精准打击”的反馈方式，极大地提升了模型修正代码的效率和准确性。
捕获测试失败的链条
编译通过并不等于代码正确。为了构建一个健壮的反馈循环，必须将编译诊断与测试失败机制结合。文章详细介绍了如何利用 Vitest 的程序化运行器。Vitest 作为一个现代化的 JavaScript 测试框架，提供了极其友好的 API 来在代码运行时动态获取测试结果。
通过程序化调用 Vitest，可以在 AI 代理生成代码后，自动运行相关的测试用例。当测试失败时，系统可以捕获详细的断言错误、预期值与实际值的差异以及失败的测试用例名称。这些信息与编译诊断相结合，形成了一个完整的“代码健康图谱”。现在的反馈不再是简单的“报错了”，而是“在第 X 行的类型定义有问题，且测试 Y 的预期结果与实际结果不符”，这为模型的自我纠错提供了明确的方向。
尽管该方案前景广阔，但也并非万能药。文章诚实地指出了其适用的边界。首先，该方案深度依赖 TypeScript 的类型系统和编译器生态，对于其他语言或动态类型语言的直接移植可能需要较大的适配工作。其次，复杂的运行时错误或逻辑漏洞，仍然需要测试覆盖面的扩大来解决。
展望未来，这种基于编译器诊断和 TDD 闭合的思路可以扩展到其他静态语言或更广泛的开发工具链。随着编译器 API 的成熟和大模型对结构化数据处理能力的提升，我们有理由相信，未来的 AI 编码助手将不再是“概率性的代码生成者”，而更接近一个能够理解代码底层规则、主动保证代码质量的可靠工程合作伙伴。