技能介绍

问题：写出来的 API 根本不存在

LLM 生成代码时最容易犯的错不是啰嗦，而是凭空捏造函数。fs.readFileLines() 在 Node.js 里并不存在，path.combine() 是 .NET 的写法，csv.read_csv() 属于 pandas 而不是 Python 标准库的 csv 模块。这类调用看着像最小实现，实际是"自信地写垃圾代码"，代价是用户一小时的调试时间。

更隐蔽的是框架混淆：render_template 是 Flask 的，render() 才是 Django 的；useForm() 来自 react-hook-form，React 本身没有内置这个 API；app.listen() 是 Express 的写法，原生 Node.js http 模块用的是 server.listen()。每个框架都有一个"听起来很像"的孪生兄弟。

还有一类是已废弃的 API：写一个下个版本就会报错的调用，等于主动埋雷。

工作方式：一条规则，四个动作

核心规则只有一条：在写任何函数调用、import 或方法访问之前，先回答"它在用户当前运行的版本里存在吗？" 答案是"大概"或"应该是"时，立即停下，承认你不知道。

具体流程分四步：

识别所有 API 表面：即将写下的 import、方法调用、类实例化，一个都不能漏。
逐一对照版本：按用户声明的版本核实；用户没给版本就问一次，不要反复追问。
标注不确定项：用行内注释而不是静默猜测，例如 // verify fs.openAsBlob exists in your Node.js version (>= 20.0)。
宁可啰嗦也要对：一段注释不花钱，一次错误的静默调用要花用户一小时。

如果不确定性太高，直接问："我需要先确认 X 在版本 Y 中是否存在，你用的是哪个版本？"

适用边界

这个技能是写代码前的现实检查层，不是代码生成器，也不内置任何框架的完整 API 知识。它能拦住"凭印象写 API"，但前提是你知道或能问到用户的版本——如果用户自己都说不清，核实本身就无从谈起。它不替代文档阅读和 IDE 自动补全，遇到真的没有把握的 API，正确做法仍然是查文档。

可以和 minimalist 配合使用：一个减少代码量，一个保证写下的代码是对的。如果你的困扰超出 API 范畴（比如参数类型、语义层面的幻觉），zero-hallucination-coder 覆盖面更广；如果你想要更系统的行为护栏，karpathy-coder 提供了 Karpathy 风格的编码约束。