在区块链和加密货币这个创新以惊人速度推进的世界里，AI agents 被吹捧为下一个重大变革。这些由大型语言模型（LLMs）驱动的智能工具，承诺将彻底改变我们的编码方式、自动化任务和构建项目的流程。但根据 Spearbit CEO、前 Solidity 贡献者 Hari Krishnan 在 X（前 Twitter）上的一条推文，事情似乎并不完全如宣传所说。

Hari（X 帐号 @_hrkrshnn）分享了他的看法：“我对 AI agents 有种奇怪的感觉。当我查看那些用 LLM 构建编码工作流的人的 GitHub 时，我没有看到贡献量呈指数级增长。到底发生了什么？”这一观察引发了开发者之间的讨论，凸显出 AI 辅助编码的炒作与现实之间的差距。

对于不熟悉这些术语的人来说，AI agents 是利用 LLMs 执行写代码、调试甚至管理整个项目等任务的自主程序。LLMs 是像 ChatGPT 这样的工具背后的“大脑”——基于海量数据训练的大型 AI 模型，能够生成类人文本，包括代码片段。在区块链开发中，这可能意味着更快地创建 smart contracts、DeFi 协议，甚至 meme tokens——这些通常是受互联网表情包启发的简单但传播迅速的加密资产。

像 Dogecoin 或在 Solana 和 Ethereum 上出现的新 meme tokens，往往依赖快速发布和社区炒作。试想如果 AI agents 能自动化代币创建流程：生成 ERC-20 的 Solidity 代码、部署它们，甚至处理初期营销。这对想要试验或抓住潮流的区块链从业者来说，听起来像是颠覆性的改变。然而，Hari 的观点表明我们还没到那一步。

深入回复：社区观点

这条推文引来了许多回应，揭示了可能的原因。用户 Andreas Bigger (@andreaslbigger）认为 GitHub 贡献数可能不是最好的衡量标准。“Contributions 是个糟糕的指标，也许试试 LoC？一些好的 agent 提示你就能在本地构建整个项目。最终一次 commit + push，就算作 1 次贡献，而人类完成相同工作可能会有 100 次贡献——数量级差距极大。”

LoC 指的是 Lines of Code（代码行数），用来衡量写了多少代码。Andreas 的意思是 AI 让开发者能更高效地在本地工作，把改动打包成更少的提交。这可以解释为什么公开的 GitHub 数据看不到激增——工作确实在进行，但被合并、浓缩了。

另一位回复，Abhishek Singh（@natoshi_sakmoto）简洁地写道：“受限于人类思维。”即便有强大的 AI，开发者仍然是瓶颈，需要引导、验证并在 AI 输出上反复迭代。

更细致的观点来自 @0xterrah：“我从观察有能力的 vibecoders 得出的看法是，他们不断努力将损害最小化。LLM 做出的小而错误的决定会累积并最终爆炸。所以你真的不想/也不能这样做得快。正确做的话更像是在监督初级开发者。”

这在区块链领域尤其有共鸣，因为智能合约中的一个编码错误就可能导致巨额损失——想想臭名昭著的 DAO 攻击或近期在 meme token 发布中出现的漏洞。AI agents 可能很快生成代码，但没有谨慎的监督，它们可能引入被老练的黑客利用的漏洞。

其他回复有 @lgrowingupl 的“放飞自我”，以及 @R5Z5G 的“AI 需要时间成熟”，反映出乐观与现实并存的心态。

对 meme token 创造者和区块链开发者的影响

在 Meme Insider，我们追踪像 AI 这样的新兴技术如何与 meme tokens 和更广泛的区块链生态交叉。如果 AI agents 还没有带来指数级的生产力提升，可能是因为这项技术仍在成长阶段。当前的 LLMs 擅长生成模板化代码，但在像优化 Ethereum 合约的 gas 费用或确保 meme token 流动性池安全等复杂、依赖上下文的任务上仍然困难重重。

对有志于打造 meme tokens 的人来说，这意味着 AI 可以在基础工作上提供帮助——例如使用 Cursor 或 GitHub Copilot 草拟代币合约——但人工专业知识仍然至关重要。过度依赖 AI 而不进行审计，可能导致 rug pulls 或失败的发布，损害项目的名誉。

展望未来，随着 AI agents 改进，我们可能会看到真正的爆发。像 Devin 或开源替代品这样的项目，或许能让独立开发者在数小时内发布 meme tokens，从而使加密创建民主化。但目前，Hari 那句“奇怪的感觉”提醒我们需要压低预期。

你怎么看？AI agents 是被过度炒作了，还是只是还没被正确衡量？在评论中分享你的经验，并继续关注 Meme Insider，了解 AI 如何塑造 meme token 的格局。

要查看原推文，请在此查看原推文: 在此查看原推文。