让 AI 少猜 API：我们用 Rust 统一了 52 个常用开发工具
内容提要
TeaQL Tool 在成熟 Rust crate 上构建统一门面，将 52 个常用工具归入 T::xxx()，减少团队和 AI 记忆多套 API 的负担。它分 core、std、extra、facade 和 context 五层，并通过类型系统要求代码说明调用意图，未执行 audit_as 则副作用不会发生。该设计缩小 AI 可用 API 面，但仅适合高频场景，存在依赖、编译体积和维护成本。
延伸解读
统一门面如何降低AI编程的API猜测成本
文章指出，AI生成代码时常混淆不同crate的API，导致编译错误。TeaQL Tool通过将52个工具统一到T::xxx()入口，缩小了AI可用的API表面积，使生成空间更收敛。这并不能消除幻觉，但能把错误从“任意猜测第三方API”限制为“在有限工具集合中选择”，再交由Rust编译器校验。
类型系统强制意图说明的机制与局限
teaql-tool-context通过comment()、purpose()和audit_as()要求代码显式说明操作意图。对于副作用，MustAuditAs<T>保存待执行动作，未调用audit_as则操作不会发生。这由API结构而非lint保证执行顺序。但文章也承认，意图描述如何进入日志或审计存储仍由应用运行时决定，目前集成尚在完善中。
Facade模式的适用边界与维护代价
文章明确，该设计仅适合高频常规操作，需要底层crate高级功能时直接依赖更合理。extra层引入网络、图片等重依赖，编译时间和二进制体积需持续测量。稳定facade还要求维护者谨慎对待命名、兼容性和错误语义，一旦业务广泛依赖，随意改名会放大迁移成本。
项目现状与后续演进方向
目前标准工具已全部覆盖context入口，但扩展工具中的cron、proxy、server和watcher尚未适配。项目计划增加API兼容性和compile-fail测试，测量不同feature组合的编译时间与体积，完善异步IO和剩余context适配，并将意图描述接入TeaQL runtime的审计与链路追踪。
Q&A
TeaQL Tool 是什么？它解决了什么问题？
TeaQL Tool 是一个在成熟 Rust crate 之上构建的统一工具门面，将 52 个常用工具统一到 T::xxx() 入口。它主要解决团队和 AI 需要记忆多套不同 API 的问题，通过提供窄而稳定的 facade 来减少 API 猜测，尤其有助于 AI 辅助编程时避免混淆不同 crate 的调用方式。
TeaQL Tool 的 52 个工具是如何分层的？
项目由五个 crate 组成：teaql-tool-core 是基础；teaql-tool-std 包含 26 个标准工具（文本、时间、ID、金额、JSON 等）；teaql-tool-extra 包含 26 个扩展工具（HTTP、命令执行、ZIP、Excel 等）；teaql-tool 是统一的 T:: facade；teaql-tool-context 提供 UserContext 与业务意图适配。默认 minimal feature 启用标准工具，需要额外能力时显式启用 extra。
TeaQL Tool 如何通过类型系统强制表达业务意图？
teaql-tool-context 为 UserContext 增加了三类意图约束：comment() 说明计算含义，purpose() 说明读取目的，audit_as() 说明并执行带副作用的操作。计算和读取结果使用私有字段包装，必须显式调用意图方法才能取值。对于副作用，MustAuditAs<T> 保存待执行动作，只有调用 .audit_as(...) 才会真正执行，否则文件写入、命令执行等不会发生。
TeaQL Tool 对 AI 编程有什么帮助？
统一 facade 后，AI 生成代码的 API 表面积缩小，工具入口固定为 T::xxx() 或 ctx.xxx()，相似能力命名一致，底层依赖升级不会扩散到业务代码，编译器还能通过包装类型提示缺少业务意图。这并不能消除幻觉，但把错误从“任意猜测第三方 API”收敛为“在有限工具集合里选择”，再由 Rust 编译器校验。
使用 TeaQL Tool 的 facade 有哪些代价或限制？
facade 只能覆盖高频能力，需要底层 crate 的高级细节时直接依赖更合理；extra 会引入网络、图片、Excel 等较重依赖，编译时间和二进制体积需持续测量；稳定 facade 要求维护者认真对待命名、兼容性和错误语义，随意改名会放大迁移成本；context 适配仍在完善，扩展工具中 cron、proxy、server 和 watcher 还没有 context 入口。
TeaQL Tool 项目接下来计划做什么？
计划包括：为 facade 增加 API 兼容性和 compile-fail 测试；测量不同 feature 组合的编译时间与二进制体积；完善异步 IO 和剩余 context 适配；将意图描述接入 TeaQL runtime 的审计与链路追踪；根据真实业务使用情况收缩或调整工具 API，而不是单纯追求数量。
