从两轮到万亿级知识图谱：AI编程的边界在哪里
上周，Dev.to 上有一篇有趣的文章：有人用两天时间、130 个 Rust 源文件、55,963 行代码、1,647 个测试用例，构建了一个完整的 CLI 工具。真正有意思的不是这个数字——而是这个团队在设计之初就定下了一条铁律：八个 crate 之间必须保持单向无环依赖，政策运行时注入而非编译期导入。这意味着什么？意味着即使有了 AI 帮助，架构设计依然需要人来拍板。
极简提示词的力量
先说一个更极端的例子。PowerToys 团队想给 Bitwarden 写一个浏览器扩展，他们只用了两轮 Copilot 对话，AI 就自主阅读了官方文档，生成了完整的可用原型。
这个案例让我意识到一件事：AI 编程的门槛已经低到尘埃里了。不是比喻，是字面意义上的两句话就能出原型。背后的技术栈也很清晰：Context7 负责拉取最新文档，Tavily 做搜索增强——这已经成为当下 AI 编程的典型配置。
但这里有个问题：出原型和出产品之间，隔着多少个边界 case？
当 Vibe Coding 触碰生产级复杂度
还是用数据说话。
FoJin 最近用 Claude Code 构建了一个佛教知识图谱系统：聚合 440+ 数据源、包含 9,600+ 实体、跨越 30 种语言。这个规模已经触及当前最强模型的极限——不是说做不出来，而是每一步都需要精细的工程判断。
再看另一个案例。Nicole 的团队花了两个多月，把一个 C++ 量子张量网络项目完整迁移到了 PyTorch，重构比例高达 80%。两个多月、80% 重构——这不是那种"把 CRUD 表单交给 AI"的小活儿。
这两个案例放在一起，指向一个共同结论：Vibe Coding 已经不再是玩具项目的专属，它正在进入真实的复杂生产场景。
那条看不见的线
但问题来了：AI 编程的边界到底在哪里？
我观察到一个核心矛盾：AI 放大的是架构能力，而不是替代它。
拿那个 Rust CLI 来说，八个 crate 的单向依赖图不是 AI 画出来的，是人设计的。政策运行时注入而不是编译期导入，这条规则是架构决策，AI 只是忠实地执行。sqry 工具验证零循环图快照——这是工程纪律，不是灵感。
更典型的例子是 Unicode 处理。当项目需要处理天城文这样的极端边缘 case 时，AI 会生成看起来合理的代码，但天城脚本的组合字符规则连人类工程师都要查 Unicode 规范才能写对。这种情况下，AI 的"自信"反而是危险的。
所以我的判断是：完全依赖 AI 但不懂底层的人，最终会丢失判断力。你必须具备基础，才能用好 AI 辅助。这不是唱反调，这是工程实践的基本常识。
自我验证：Agent 的新范式
还是回到开头那篇 Dev.to 文章。这次他们用 AI 生成的文章配图，用 Agent 提交草稿到平台——实现了"工具自举式"的实用性验证。框架不仅生成文档，还完成了文档的发布投递。
这让我想到一个有趣的问题：如果一个 Agent 能验证自己的输出，它是不是就"活着"了？
当然不是。至少现在还不是。但这种自我验证正在成为新的范式：不是人在验证 AI 的输出，而是 AI 在验证 AI 的输出。循环依赖检测是第一步，接下来可能是性能基准测试、安全扫描、合规检查……
写给实践者的话
写了这么多，我不确定自己能给出什么确定的结论。唯一确定的是：AI 编程的边界不在工具本身，而在使用工具的人。
如果你有扎实的基础，AI 能把你放大十倍。如果你没有，AI 会让你在错误的方向上跑得更快。
下一次当你准备把一个复杂项目交给 AI 时，先问自己一个问题：如果 AI 在最关键的地方出错，我能发现吗？
如果答案是否定的，也许那个边界，比你想象的更近。
综合来源：How We Built a Safety-First Rust Agent CLI in Two Days（Dev.to）与《社区速递 136》（少数派）