北京
Quicknode 的 Builder's Guide 里，每个工具条目要填满 60 多个结构化字段。这个数字本身就说明了问题：一个目录站的内容模型，得同时支撑发现和对比两种用途，光生成一段读得通的简介，只解决了出版问题的一小块。
他们公开的案例里，跑在 LangGraph 上的是一条 5 节点工作流：检索、生成、分类校验、质量评分，最后才进入发布环节。这套结构给出的经验很直接——每个环节都得有明确的职责边界。找证据、写文案、做分类、决定发不发，四件事的验收标准本来就不一样。
目录站的内容模型，定义的是让一个条目能被应用真正用起来的字段和关系。它同时提供了一个更细粒度的评估入口：不用再笼统判断"这份简介读起来像不像真的"，而是可以逐字段去问，这个值到底站不站得住。
设计类似流水线时，第一步是描述每个字段需要什么证据。描述性摘要要有足够上下文解释工具用途；定价字段要有正在被描述的那个报价的信息；分类归属则需要一个可以拿来核对的定义。这是三个不同的问题，拆开处理，才能判断哪些字段适合生成，哪些必须直接连到来源。
缺失信息怎么表示，也得提前定。空字段、明确标注未知、模型生成的猜测，对读者的后果完全不同。在让模型补全条目之前先选好这个行为，否则"完整性"会变成一种激励，逼着系统去填没有依据的细节。
证据收集环节，他们用的是 Tavily 的 API 去找网站、文档和社交链接，再用 GPT-4o 生成描述、定价档位和使用场景。对同类目录来说，真正有用的设计问题是：检索回来的材料，能不能支撑你打算发布的那些字段。找到某个工具的页面，只是确立了一个候选来源，还得判断这个页面到底确立了什么、能支撑条目里的哪一部分。
定价字段值得单独拿出来看。接受一个生成值之前，先确认来源描述的是当前报价、限时促销，还是旧公告。这个区分给了审核者一个具体的核对目标，而不是只判断生成文案流不流畅。
评估过程中，证据和解释的界限要一直保持可见。使用场景可以跨来源综合，引用价格则必须有精确支撑。对两者用同一套审核方法，会掩盖"有用的解释"和"没有依据的事实断言"之间的差别。
分类校验这一步，用的是 AI 推理去对照 Contentful 里的定义。这划出了一条实用边界：目录的分类体系、它定义的类别词汇，应该提供被接受归属的含义。一个标签看起来合理没用，除非它对应得上目录组织内容的方式。
自己搭工作流时，要把这些定义喂给分类环节，拿它们去评估模型给出的归属。如果类别之间有重叠，先决定内容模型里这种重叠该怎么处理。定义本身留着的编辑歧义，让模型去选是解决不了的。
分类还可以和文案质量分开审。一个条目可能把工具解释得很准，却放进了不合适的类别；反过来，类别正确也说明不了定价描述有没有支撑。分开评估，这些失败更容易被识别和讨论。
发布前的质量评分走的是 Contentful Management API，条目创建和资源关联都由它处理。案例里没有给出评分细则和通过阈值。落到自己的实现上，得先定义分数衡量什么、对应什么动作——事实支撑、必填字段完成度、类别匹配度可以分开评。这些是待验证的标准，在拿来决定发布之前，得先拿有代表性的条目测一遍。
评估结果要能落地。低分应该指向具体需要处理的字段或断言，这样才有明确选择：补证据、改文案，还是把条目挂起来等人工审。
Quicknode 的目录起步于 700 个手工整理的工具，报告中的潜在规模是 5000 多个条目。这个数字描述的是潜在容量。评估类似自动化时，除了系统能生成多少条，还得盯住有多少条真正达到了发布标准。被接受的条目数，才是判断该先加大处理量、还是先改进工作流的依据。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
