AI 助手（原型）
注意：本文档是英文原版的自动翻译。
AI 助手（原型）
DecAIHub 上的原型页描述的是常见的项目蓝图——加密 AI 项目如何被构建、它们提供什么，以及 AI 在其产品中扮演什么角色的反复出现的模式。“AI 助手”原型涵盖那些主打产品是一个 AI 助手的项目：一个通过检索相关信息并以有用方式呈现，来帮助用户回答问题、完成任务或做决策的系统。
简而言之： 在这一原型中，助手本身就是产品——一个响应用户请求、但不代表用户自主行动的对话式 AI 层。
是什么界定了这一原型
当一个项目的核心产品是一个对用户提示作出响应、给出情境感知的答案、推荐或分析的系统时，它就符合 AI 助手原型。与 AI 代理不同，助手不采取独立行动——它们告知和建议，但用户保留对执行的控制权。与简单的聊天机器人不同，助手通常融入检索、排名或特定领域知识，而非仅仅依赖通用文本生成。在助手–副驾驶–聊天机器人–代理光谱上，助手位于低到中等的自主性区间：比聊天机器人更有能力，但不如副驾驶或代理那样自主。
从产品角度看，这一原型由请求–响应交互界定：用户发起每一次有意义的交流，而系统的工作是组装一个有帮助的回复。对分类而言重要的边界是：助手是否避免在没有用户于单独一步中明确批准的情况下进行自主执行——这一区别把以助手为中心的项目与以代理为中心的项目区分开来。
常见模式
加密知识助手
面向区块链问题的对话式 AI。 这些助手回答用户关于代币、协议、钱包和链上活动的查询。它们通常把一个 LLM 与来自区块链数据源、文档和市场数据源的检索结合起来。其价值取决于助手提供的是准确、最新的加密专属答案，还是仅仅把提示转发给一个通用模型。
弱实现可能看起来很流畅，却在编造地址、参数或协议行为。
典型的 AI components：AI chat assistant for crypto、AI assistant for blockchain queries、NLP-based crypto Q&A。
交易与投资组合助手
面向交易和投资组合管理的决策支持。 这些助手帮助用户评估持仓、审视市场状况并考虑交易参数——但由用户来执行交易。AI 浮现分析；人来据此行动。这种模式在那些把 AI 与 DeFi 桥接、却不授予 AI 自主执行权的项目中很常见。
该原型描述的是产品结构，而非任何具体实现的可靠性。
典型的使用场景：AI-assisted trading、portfolio analysis assistant、AI-powered market insights。
社区与支持助手
面向项目社区的自动化帮助。 这些助手管理频道、回答常见问题、引导新用户入门，并总结治理讨论。它们运行在消息平台内部（Telegram、Discord），服务于项目的社区，而非外部终端用户。
典型的 AI 组件：AI community assistant、AI moderation bot、AI-powered FAQ assistant。
开发者助手
面向智能合约和 dApp 开发的 AI 工具。 这些助手帮助开发者编写、审查或审计智能合约，生成样板代码，或解释协议文档。其 AI 组件通常是一个为 Solidity、Rust 或 Move 而微调或提示的 LLM，有时辅以静态分析工具。
典型的 AI 组件：AI code assistant、smart contract auditor assistant、AI developer copilot。
应当核实什么
在阅读带有助手组件的项目卡片时，请检查：
- 真正的 NLP 还是关键词匹配？ 一个真正的助手使用机器学习——一个 LLM、检索增强生成（RAG）或一个微调模型。一个匹配关键词并返回预设回应的系统是自动化，而非 AI。
- 自有模型还是 API 包装器？ 该项目是训练、微调或有意义地定制了一个模型，还是把提示转发给一个第三方 API 并原封不动地返回结果？仅有一个 API 包装器并不构成一个专有的 AI 助手。
- 特定领域的检索 — 助手是否访问并基于加密专属数据（链上状态、协议文档、市场数据源）进行推理，还是仅仅依赖基础模型的训练数据？
- Tier-1 证据 — 公开演示、API 文档、模型卡或基准结果，能够展示助手的实际能力。
该原型在 DecAIHub 卡片中的体现
- 类别 — 通常为 AI/代理或某个特定领域的组合，取决于助手的聚焦领域。
- AI component — 应当指明一个具体机制：
AI chat assistant、NLP-based assistant、RAG-powered assistant。诸如“AI-powered”而无具体内容的含糊标签是一个警示信号。 - 使用场景 — 常见取值：
AI assistant for crypto、AI-assisted trading、AI community assistant、smart contract code review。 - ai_score — 反映针对助手 AI 能力存在多少可验证证据。参见 DecAI Fit。
该原型不能证明什么
- 拥有一个聊天机器人或助手界面并不能证明该系统使用了真正的 AI 或专有技术。许多助手只是围绕第三方 LLM 的、没有任何有意义定制的薄包装。
- 把一个产品标为“AI 助手”并不能证明其智能——该助手可能产出与一次裸 API 调用无法区分的通用、非专门化的回应。
- 一个回答加密问题的助手并不能证明该项目本身是去中心化的，或其代币对助手的运转是必要的。
- 用户对助手的高度参与并不能证明 AI 质量——用户可能频繁地与一个简单机器人交互，却没意识到它缺乏真正的 NLP。请查看证据表。
请勿混淆
- AI 代理原型 — 代理感知、决策并自主行动。助手响应用户请求，但不采取独立行动。
- 助手 vs 副驾驶 vs 聊天机器人 vs 代理 — 概念光谱页。本原型页专门描述以助手为中心的项目的常见产品模式。
- AI 基础设施层原型 — 基础设施项目向 AI 开发者提供工具和服务。助手是应用层的产品，而非基础设施。
- API 包装器 — 把提示转发给一个第三方模型并返回结果是一种透传，而非一个具有专有能力的助手。
常见问题
在 DecAIHub 上，助手与代理有何不同？
助手等待用户提示，并以信息或建议作出响应。代理（在本 wiki 所用的原型意义上）与更高的自主性相关联：规划、工具使用，以及在所定义的权限内行动。如果产品从不执行动作、除非用户在模型之外手动确认每一步，那么把它归类为助手优先。
一个项目能同时是助手和其他东西吗？
可以。原型描述的是主要的产品形态。一个项目可能以助手作为主界面，同时仍包含较小的自动化功能。使用卡片的 AI component 和使用场景字段，来查看 DecAIHub 记录了哪种模式为主导。
为什么 DecAIHub 关心助手的 RAG 和微调？
因为仅有流畅性不是领域胜任力的证据。检索和定制是加密助手为其主张提供依据的常见方式：它们把模型绑定到文档、链数据或项目特定的语料库。没有这些，助手可能与一个通用聊天产品无法区分。
外部参考
- Retrieval-augmented generation for knowledge-intensive NLP tasks — 关于 RAG 的基础性论文，RAG 是助手用来把答案植根于外部来源的标准模式。
- NIST AI Risk Management Framework — 关于 AI 系统可信度和治理预期的框架，在评估管理、安全和披露实践时相关。
No comments to display
No comments to display