更宽松的规范,更好的结果:Kent C. Dodds 论原语思维

X AI KOLs Following 新闻

摘要

Kent C. Dodds 主张,在代码库中定义和维护设计良好的原语,可以让 AI 代理以更宽松、更高层次的规范更自主地运行,从而提高软件开发的效果。

更宽松的规范,更好的结果:Kent C. Dodds 论原语思维 https://t.co/7RO21WOyFN
查看原文
查看缓存全文

缓存时间: 2026/08/28 19:46

规范越宽松,效果越佳:Kent C. Dodds 谈原语思维

https://t.co/7RO21WOyFN


规范越宽松,效果越佳:Kent C. Dodds 谈原语思维

摘要: 要让AI智能体更自主、更高效,关键在于在代码库中构建并维护一套定义良好的“原语“(可复用、具语义的构建模块)。这使你能给予它们更宽松、更高层次的规范。

过于严格的规范之弊

Kent C. Dodds 指出了一个常见问题:缺乏良好原语的开发者,常常不得不编写冗长详尽的规范来约束AI智能体,试图防止它们偏离轨道。解决之道并非制定更大的规范,而在于夯实更好的基础。其核心论点是:一份规范需要越详细,就说明你的原语越糟糕。 一个优秀的开发环境应让智能体专注于任务本身,而非费力解读庞大的规则手册。这就是原语为何如此重要。

什么是原语?

原语是你代码库或智能体可用工具中最小的语义单元。它们是系统暴露的、命名的能力单元,可组合使用,且无需重新实现内部逻辑。这并不意味着你代码库中的每个函数都是原语,也不仅仅是指智能体文档中一段400行的描述。如果智能体需要重新发明某个功能,那它就不是一个可用的原语。智能体的大部分工作应是组合现有原语,而非添加新原语或从头创造。

原语示例

原语可以横跨技术栈的所有层级。Kent 列举了几个类别:

  • 应用层: React 本身就是一个原语。在其之上,你构建组件原语,这些组件可组合成更复杂的组件。路由机制也是原语。
  • 后端层: 数据模型、授权模式和访问控制系统都是原语。有些构建在其他原语之上,有些则是独立的。
  • 工具层:Kodi(Kent 开发的用于连接外部系统并赋予智能体自主权的框架)这样的工具就是原语。在最初的示例中,Kodi 赋予了智能体访问 Discord 的权限,使其能在该环境中自主行动。
  • 特定工具包: Google 工具包(消除了对 API 端点的猜测)、函数库以及 Stripe 支付包 都是 “Kodi Video” 示例中的关键原语。

设计良好的原语

如何判断你的原语设计是否良好?Kent 提出了一个简单的测试标准:一个初级智能体,能否通过组合原语并接到一个一句话的任务指令,就产出好的结果? 如果不能——如果它需要发明新原语或采用变通方案——那就意味着原语缺失、难以发现,或者构建新功能比使用现有功能更容易。你应避免这种情况。

评估原语质量的一个关键指标是,在智能体完成工作后,检查它是如何使用现有原语的。你的原语优化得越好,你的“软件工厂“在产出高质量软件方面的能力就越强。

管理原语生命周期

原语并非构建一次后就束之高阁。它们需要持续演进:修改、移除、扩展和组合。这需要产品工程师的思维模式——深刻理解产品的目的、愿景和数据模型。作为产品工程师,你的职责是将产品决策转化为代码实现,这包括设计系统及其可用的原语。

审慎引入新原语

引入新原语必须是一个经过深思熟虑的决策。例如,Kent 曾考虑引入一个新原语,用于“无需打包存储即可订阅事件的代码片段“。他与AI智能体(Grok 4.6)讨论了这个想法,但最终决定推迟,表示:“我想仔细思考这个设计。” 并非每个潜在的原语都值得采纳;你必须决定哪些能真正使系统受益。

裁剪冗余原语

同样重要的是移除冗余原语——Kent 称之为**“原语裁剪”,就像修剪花园一样。他举了一个例子:计划移除一个 value store 原语,用包存储、内存和仓库来替代。他指示智能体在操作前分析生产数据**,因为移除原语可能很困难,且必须以数据为依据。他认识到这个早期的 “value store” 已经变成了一个“垃圾堆“,被更好的原语所取代。智能体甚至提出了一个为期一个月的迁移计划,这是弃用原语的典型方法。

另一个例子是移除一个 persistence service 原语,因为其他原语更好地覆盖了它的功能,而且它甚至在特定场景下表现不佳。考虑业务可持续性至关重要,要询问智能体相关原语的成本,以避免陷入“成本否认“的陷阱。

故障排查:智能体与原语的交互

Kent 指出了智能体与原语交互时的三种常见失败模式:

  1. 找不到原语。 解决方案是改进路由文档,确保你的 agents.md 文件指向所有相关文档。
  2. 它发明了一个新原语,而不是使用现有的(例如,构建一个新组件而不是使用当前组件)。这表明该原语过于僵化或难以发现,你需要对其进行优化。
  3. 你无法追踪它使用了哪些原语。 因此,拉取请求应包含系统差异图,而不仅仅是代码差异。Kent 在他的 YouTube 系列 “Better with Kent” 中介绍了这一点。

架构决策记录 (ADR) 是指导原语使用的重要工具。它们通过明确声明“我们不会做 X;我们将做 Y,原因是…“来提供方向。这有助于智能体理解为何不应走一条看似显而易见的路径。

强大原语的力量

拥有健壮的原语系统,你就可以命令智能体执行复杂的、自主的任务。Kent 列举了他现在可以委派的几项能力:

  • 检查他的收件箱并执行操作。
  • 管理他的 Discord 社区。
  • 自主部署功能。
  • 通过 Sentry 实现自我修复,醒来后发现智能体已自动修复了许多问题。

Kent 给出的最终测试和任务是:在你的实际代码库中,给智能体一个一句话的任务。 观察它是否能有效地组合原语。如果成功了,那么你的原语基础就走在了正确的道路上。

来源

视频:@kentcdodds: 规范越宽松,效果越佳:Kent C. Dodds 谈原语思维 (https://www.youtube.com/watch?si=4v8S1Q0mTKt7rZRP&v=QMi8UHhTZgs&feature=youtu.be)

相似文章