Claude写代码总出错？这12条规则把错误率降到了 3%

marsbit發佈於 2026-05-14更新於 2026-05-14

文章摘要

2026年初，Andrej Karpathy批评Claude编程时常犯静默假设、过度工程化、无关破坏等错误。Forrest Chang据此总结出4条行为规则并创建CLAUDE.md文件，有效将相关错误率从约40%降至3%以下。但随着AI编程向多步骤Agent、跨代码库协作等复杂场景发展，原有规则显现不足。本文作者经过6周30个代码库的测试，在原有4条规则基础上新增8条，形成12条规则合集，以应对新挑战。新增规则包括：不让模型处理非语言类决策（如重试逻辑）；设置硬性token预算以防循环失控；发现代码风格冲突时明确暴露而非折中；修改前先阅读理解周边代码；确保测试验证真实逻辑而非仅通过检查；为长任务设置检查点以防进度丢失；遵循现有约定而非引入新风格；要求显性失败而非静默跳过错误。测试数据显示，12条规则将总体错误率进一步降至3%，且未显著增加模型的遵守负担。文章指出，CLAUDE.md应视为针对具体失败模式的行为契约，而非泛泛的愿望清单，建议开发者根据自身实际情况裁剪使用，并保持文件简洁（不超过200行）以确保规则被有效遵循。

编者按:2026 年 1 月,Andrej Karpathy 对 Claude 写代码的吐槽,引出了一个看似很小、但在 AI 编程工作流中极其关键的文件:CLAUDE.md。Forrest Chang 随后将这些问题整理成 4 条行为规则,试图约束 Claude 在编码时常见的错误:静默假设、过度工程化、误伤无关代码,以及缺乏清晰的成功标准。

但几个月后,Claude Code 的使用场景已经不再只是「让模型写一段代码」。随着多步骤 Agent、hook 链式触发、skill 加载和多代码库协作成为常态,新的失败模式也开始出现:模型在长任务中失控、测试通过却没有验证真实逻辑、迁移完成但静默跳过错误、不同代码风格被错误混合。

本文作者在 6 周内测试了 30 个代码库,并在 Karpathy 原有 4 条规则基础上新增 8 条规则,试图覆盖 AI 编程从单次补全走向 Agent 化协作后的新问题。

以下为原文:

2026 年 1 月下旬,Andrej Karpathy 发了一条推文串,吐槽 Claude 写代码的方式。他指出了三类典型问题:在没有说明的情况下做出错误假设、过度复杂化,以及对原本不该改动的代码造成无关破坏。

Forrest Chang 看到了这条推文串,把其中的抱怨整理成 4 条行为规则,写进一个单独的 CLAUDE.md 文件,并发布到了 GitHub。这个项目上线第一天就获得了 5,828 个 Star,两周内被收藏 60,000 次,如今已有 120,000 个 Star,成为 2026 年增长最快的单文件代码仓库。

随后,我在 6 周时间里,用 30 个代码库对它进行了测试。

这 4 条规则确实有效。过去大约 40% 概率会出现的错误,在适合这些规则发挥作用的任务中,下降到了 3% 以下。但问题在于,这个模板最初是为了解决 1 月份 Claude 写代码时出现的错误。

到了 2026 年 5 月,Claude Code 生态面临的问题已经不同了:Agent 之间相互冲突、hook 链式触发、skill 加载冲突,以及跨会话多步骤工作流中断等。

所以,我又加入了 8 条规则。下面是完整的 12 条规则版 CLAUDE.md:每一条为什么值得加入,以及原版 Karpathy 模板会在哪 4 个地方悄悄失效。

如果你想跳过解释,直接复制使用,完整文件放在文末。

为什么这很重要

Claude Code 的 CLAUDE.md,是整个 AI 编程技术栈里最被低估的文件。大多数开发者通常会犯三类错误:

第一,把它当成偏好垃圾桶,把自己所有习惯都塞进去,最后膨胀到 4000 多个 token,规则遵守率掉到 30%。

第二,干脆完全不用,每次都重新 prompt。这会造成 5 倍 token 浪费,而且不同会话之间缺乏一致性。

第三,复制一个模板后就再也不管。它可能有效两周,但随着代码库变化,会在你不知不觉中失效。

Anthropic 官方文档说得很明确:CLAUDE.md 本质上只是建议性的。Claude 大约会有 80% 的时间遵循它。一旦超过 200 行,遵守率就会明显下降,因为重要规则会被噪音淹没。

Karpathy 的模板解决了这个问题:一个文件、65 行、4 条规则。这是最低基准。

但上限还可以更高。再加入下面这 8 条规则后,它覆盖的就不只是 Karpathy 在 2026 年 1 月抱怨的代码写作问题,也包括 2026 年 5 月才出现的 Agent 编排问题——这些问题在原模板写成时还不存在。

原始的 4 条规则

如果你还没看过 Forrest Chang 的仓库,先看这个基础版本:

规则 1:编码前先思考。

不要默默做假设。要说明你的假设,暴露权衡点。在猜测之前先提问。当存在更简单的方案时,要主动提出反对意见。

规则 2:简单优先。
用能解决问题的最少代码。不要加入想象中的功能。不要为一次性代码设计抽象层。如果一位资深工程师会认为它过度复杂,那就应该简化。

规则 3:外科手术式修改。
只改必须改的部分。不要顺手「优化」相邻代码、注释或格式。不要重构没有坏掉的东西。保持与现有风格一致。

规则 4:以目标为导向执行。
先定义成功标准,然后循环迭代,直到完成验证。不要告诉 Claude 每一步该怎么做,而是告诉它成功结果应该是什么样,让它自己迭代。

这 4 条规则,能解决我在无人监督的 Claude Code 会话中看到的大约 40% 的失败模式。剩下约 60% 的问题,则藏在下面这些空白地带。

我新增的 8 条规则,以及为什么

每一条规则,都来自一个真实时刻:Karpathy 原来的 4 条规则已经不够用了。下面我会先讲那个场景,再给出对应规则。

规则 5:不要让模型做非语言类工作

Karpathy 的规则没有覆盖这一点。于是模型开始决定一些本该由确定性代码处理的问题:是否重试一次 API 调用、如何路由一条消息、什么时候升级处理。结果是,每周的判断都不一样。你得到的是一种按每 token 0.003 美元计费的、不稳定的 if-else。

那个时刻是这样的:有一段代码会调用 Claude 来「判断遇到 503 时是否应该重试」。它一开始运行得很好,持续了两周,后来突然变得不稳定,因为模型开始把请求体也当作判断上下文。重试策略变得随机,因为 prompt 本身就是随机的。

规则 6:设置硬性 token 预算,没有例外

没有预算约束的 CLAUDE.md,就等于一张空白支票。每一次循环都有可能失控,变成一次 50,000 token 的上下文倾倒。模型不会自己停下来。

那个时刻是这样的:一次调试会话持续了 90 分钟。模型一直在围绕同一段 8KB 的错误信息反复迭代,并逐渐忘记自己已经尝试过哪些修复方案。到最后,它开始提出 40 条消息之前我已经否定过的方案。如果有 token 预算,这个过程在第 12 分钟就该被终止。

规则 7:暴露冲突,不要折中平均

当代码库里的两个部分互相矛盾时,Claude 会试图同时讨好两边,结果写出来的是一团不连贯的代码。

那个时刻是这样的:一个代码库里存在两套错误处理模式,一套是 async/await 加显式 try/catch,另一套是全局错误边界。Claude 写出的新代码把两套都用了。结果错误处理被做了两遍。我花了 30 分钟才弄明白,为什么错误被吞掉了两次。

规则 8:先读,再写

Karpathy 的「外科手术式修改」告诉 Claude 不要改动相邻代码。但它没有告诉 Claude:先理解相邻代码。没有这一条,Claude 会写出和 30 行之外既有代码相冲突的新代码。

那个时刻是这样的:Claude 在一个已有函数旁边新增了一个功能完全相同的函数,因为它没有先读原来的函数。两个函数做的是同一件事。但由于 import 顺序的关系,新函数覆盖了旧函数,而旧函数已经作为事实上的唯一标准存在了 6 个月。

规则 9:测试不是可选项,但测试本身不是目标

Karpathy 的「以目标为导向执行」暗示测试可以作为成功标准。但在实践中,Claude 会把「测试通过」当成唯一目标,于是写出一些能通过浅层测试、却会破坏其他东西的代码。

那个时刻是这样的:Claude 为一个认证函数写了 12 个测试,全部通过。但生产环境里的认证逻辑坏了。那些测试只是在验证函数「返回了某个东西」,而不是验证它是否返回了正确的东西。函数之所以能通过测试,是因为它返回的是一个常量。

规则 10:长时间运行的操作需要检查点

Karpathy 的模板默认交互是一次性的。但真实的 Claude Code 工作往往是多步骤的:跨 20 个文件重构、在一个会话里构建功能、跨多个 commit 调试。如果没有检查点,一步走错,前面所有进度都可能丢失。

那个时刻是这样的:一个 6 步重构任务在第 4 步出错了。等我发现时,Claude 已经在错误状态之上继续完成了第 5 步和第 6 步。拆解修复花的时间,比重做整个任务还长。如果有检查点,第 4 步就能发现问题。

规则 11:约定优先于新意

在一个已经有成熟模式的代码库里,Claude 喜欢引入自己的写法。哪怕它的写法「更好」,引入第二套模式本身,也比任何一种单一模式都更糟。

那个时刻是这样的:Claude 在一个基于 class component 的 React 代码库里引入了 hooks。它确实能运行。但它同时破坏了代码库原有的测试模式,因为那些测试依赖 componentDidMount。最后花了半天时间才把它删掉并重写。

规则 12:要显性失败,不要静默失败

Claude 最昂贵的失败,往往是那些看起来像成功的失败。一个函数「能跑」,但返回了错误数据;一次 migration「完成了」,但跳过了 30 条记录;一个测试「通过了」,但只是因为断言本身是错的。

那个时刻是这样的:Claude 说一次数据库迁移「成功完成」。但实际上,它静默跳过了 14% 触发约束冲突的记录。跳过行为被写进了日志,却没有被明确暴露出来。11 天后,当报表数据开始异常时,我们才发现问题。

数据结果

我在 6 周时间里,追踪了同一组 50 个代表性任务,覆盖 30 个代码库,测试了三种配置。

错误率指的是:任务需要被纠正或重写,才能匹配原始意图。计入的错误包括:静默错误假设、过度工程化、无关破坏、静默失败、违反约定、冲突折中、漏掉检查点。

遵守率指的是:当某条规则适用时,Claude 有多大概率会显性应用这条规则。

真正有意思的结果,不只是错误率从 41% 降到 3%。更重要的是,从 4 条规则扩展到 12 条规则,几乎没有增加遵守负担,遵守率只是从 78% 变成 76%,但错误率又下降了 8 个百分点。新增规则覆盖的是原来 4 条规则没有处理的失败模式,它们并没有争夺同一块注意力预算。

Karpathy 模板会在哪些地方悄悄失效

即便不加入新规则,原来的 4 条规则模板也至少在 4 个地方不够用。

第一,长时间运行的 Agent 任务。
Karpathy 的规则主要针对 Claude 正在写代码的那一刻。但当 Claude 在运行一个多步骤 pipeline 时,会发生什么?原模板没有预算规则,没有检查点规则,也没有「大声失败」规则。于是 pipeline 会慢慢漂移。

第二,多代码库一致性。
「匹配现有风格」默认只有一种风格。但在一个拥有 12 个服务的 monorepo 里,Claude 必须选择到底匹配哪一种风格。原始规则没有告诉它怎么选。于是它要么随机选择,要么把几种风格平均混合。

第三,测试质量。
「以目标为导向执行」会把「测试通过」视为成功,却没有说明测试本身必须有意义。结果就是,Claude 写出一些几乎什么都没验证的测试,但这些测试会让它误以为自己很有把握。

第四,生产环境与原型阶段的差异。
同样的 4 条规则,可以防止生产代码被过度工程化,但也可能拖慢原型开发。因为原型阶段有时确实需要 100 行探索性脚手架,先摸清方向。Karpathy 的「简单优先」在早期代码里容易过度触发。

这 8 条新增规则并不是要取代 Karpathy 的原始 4 条规则,而是在修补它们的空白:原模板对应的是 2026 年 1 月那种偏自动补全式的代码写作场景;而到了 2026 年 5 月,Claude Code 已经进入由 Agent 驱动的、多步骤、多代码库协作环境,两者面对的问题并不一样。

哪些方法没有奏效

在最终确定这 12 条规则之前,我也尝试过一些其他方案。

加入我在 Reddit / X 上看到的规则。
其中大多数,要么只是用不同说法重复 Karpathy 原来的 4 条规则,要么是无法泛化的领域特定规则,比如「始终使用 Tailwind class」。最后都删掉了。

超过 12 条规则。
我最多测试到 18 条。超过 14 条后,遵守率从 76% 掉到了 52%。200 行的上限是真实存在的。超过这个长度后,Claude 就会开始模式匹配成「这里有规则」,而不是真的逐条阅读规则。

依赖某些工具存在的规则。
比如「始终使用 eslint」,一旦项目里没有安装 eslint,这条规则就会失效,而且是静默失效。后来我把它改成了不依赖具体工具的表达,比如把「使用 eslint」改成「遵循代码库中已经强制执行的风格」。

在 CLAUDE.md 里放示例,而不是规则。
示例比规则更占上下文。三个示例消耗的上下文,差不多相当于 10 条规则,而且 Claude 很容易对示例过拟合。规则是抽象的,示例是具体的。所以,应当使用规则。

「小心一点」「认真思考」「专注一点」。
这些都是噪音。这类指令的遵守率掉到了大约 30%,因为它们无法被检验。后来我把它们替换成了更具体的命令式规则,比如「明确说明假设」。

告诉 Claude 要像「资深工程师」一样。
这没有用。Claude 本来就觉得自己像资深工程师。真正的问题不在于它是否这样认为,而在于它是否这样执行。命令式规则可以缩小这个差距,身份提示词不行。

完整的 12 条规则版 CLAUDE.md

以下是可直接复制粘贴使用的完整版本。

暂时无法在飞书文档外展示此内容

将它保存为仓库根目录下的 CLAUDE.md。在这 12 条规则下面,再添加项目专属规则,比如技术栈、测试命令、错误模式等。整体不要超过 200 行,超过之后,规则遵守率就会明显下降。

如何安装

两步即可:

1. 将 Karpathy 的 4 条基础规则追加到你的 CLAUDE.md 中
curl https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md >> CLAUDE.md

2. 将本文中的规则 5–12 粘贴到下面

把文件保存在仓库根目录。这里的 >> 很重要,它的作用是追加到已有的 CLAUDE.md,而不是覆盖你已经写好的项目专属规则。

心智模型

CLAUDE.md 不是愿望清单,而是一份行为契约,用来封堵你已经观察到的具体失败模式。

每一条规则都应该回答一个问题:它能防止什么错误?

Karpathy 的 4 条规则,防的是他在 2026 年 1 月看到的失败模式:静默假设、过度工程化、无关破坏、成功标准薄弱。它们是基础,不要跳过。

我新增的 8 条规则,防的是 2026 年 5 月之后出现的新失败模式:没有预算约束的 Agent 循环、没有检查点的多步骤任务、看似测试了但其实没测到关键逻辑的测试,以及把静默失败包装成静默成功的问题。它们是增量补丁。

当然,具体效果因人而异。如果你不跑多步骤 pipeline,规则 10 对你就没那么重要。如果你的代码库只有一种统一风格,而且已经由 lint 强制执行,规则 11 就是冗余的。读完这 12 条后,保留那些真正对应你实际犯过错误的规则,删掉其余部分。

一份针对真实失败模式定制的 6 条规则版 CLAUDE.md,胜过一份有 12 条规则、其中 6 条你永远用不上的版本。

结语

Karpathy 在 2026 年 1 月的那条推文,本质上是一场抱怨。Forrest Chang 把它变成了 4 条规则。最终,12 万开发者给这个结果点了 Star。而其中大多数人,今天仍然只在使用那 4 条规则。

模型已经进步,生态也已经变了。多步骤 Agent、hook 链式触发、skill 加载、多代码库协作——这些在 Karpathy 写下那条推文时都还不存在。原来的 4 条规则并没有解决这些问题。它们不是错了,而是不完整了。

新增 8 条规则。6 周时间,覆盖 30 个代码库的测试。错误率从 41% 降到 3%。

今晚就收藏这篇文章,把这 12 条规则粘贴进你的 CLAUDE.md。如果它帮你少走一周 Claude 弯路,欢迎转发。

你可能也喜歡

Monarq、Flare 与 Upshift 在 Flare 上推出 MXRPY XRP 收益金库

Monarq、Flare与Upshift联合宣布在Flare网络上推出MXRPY——一个多策略管理的XRP收益金库，专为寻求多样化收益的XRP持有者设计。用户可将Flare上的XRP代表资产FXRP存入该专业管理金库，资金将分配至三大策略类别：期权交易、基差与资金费率套利，以及链上XRPFi部署。金库由Upshift的机构级基础设施支持，Monarq资产管理公司负责运营。即日起，XRP持有者可通过Upshift存入MXRPY，初始上限为50万FXRP。目标年化收益率约为3%-4%，实际收益将随策略表现与市场状况波动。MXRPY通过结合链上与链下执行的混合管理模式，拓展了Flare上XRPFi生态的应用范围，为持有者提供更广泛的收益机会。金库资金通过四大收益引擎进行配置：以XRP为抵押通过FalconX进行期权策略交易；利用稳定币实施市场中性的基差与资金费率套利；直接部署至Flare原生的XRPFi借贷市场及流动性策略等DeFi应用。用户存入FXRP后将获得代表本金与累积收益的MXRPY凭证代币，提现按周处理（每周五），亦提供付费快速赎回选项。此次发布反映了Flare的XRPFi生态正在持续扩展，基础设施提供商与资产管理公司正为XRP持有者创建新的产品与策略类别。相关公司表示，未来计划推出独立应用程序，允许用户通过XRPL钱包直接连接，并利用Flare智能账户实现单签流程资金配置。市场风险、策略执行及部署时机等因素可能影响实际收益，用户仍需承担与链上链下市场相关的对手方、智能合约及基础设施风险。

TheNewsCrypto9 分鐘前

Monarq、Flare 与 Upshift 在 Flare 上推出 MXRPY XRP 收益金库

TheNewsCrypto9 分鐘前

比特币价格或因实现利润攀升至2022年水平而恢复下行趋势

比特币价格在过去一个月看似试图摆脱熊市，但市场结构尚未完全转向积极趋势。链上分析显示，比特币可能已形成局部顶部，下行趋势或将重启。分析师Ali Martinez指出，比特币市场可能过热，下行风险增加。这一判断基于已实现盈亏指标，该指标用于衡量投资者在加密货币市场中实际实现的收益。数据显示，当前比特币交易者的平均已实现利润率达17%，这可能是一个预警信号。该利润率上次达到此水平是在2022年3月，当时比特币正测试200日移动平均线阻力位，随后便出现了局部顶部和持续下跌。从历史经验看，当前17%的利润水平常与市场顶部重合，预示着比特币价格可能已见顶并面临下跌压力。目前，比特币价格在78,000美元附近徘徊，该价位是近几周的关键支撑位。若跌破，可能引发进一步下跌。截至发稿，比特币价格约为78,070美元，24小时内波动不大，但周线下跌超过3%。投资者需密切关注78,000美元支撑位的表现，以判断市场后续方向。

bitcoinist10 分鐘前

bitcoinist10 分鐘前

意大利最大银行一季度持仓翻番，加密货币信心激增

意大利最大银行Intesa Sanpaolo在2026年第一季度大幅增加了其加密货币敞口，持仓总额从2025年底的约1亿美元增至约2.35亿美元。其投资策略明显转向主流资产，新增了通过BlackRock ETF持有的以太坊头寸，并增持了ARK和BlackRock的比特币ETF，同时几乎清空了Solana持仓。此外，该行还扩大了在BitGo和Coinbase的股票持仓。 Intesa的举措反映了欧洲银行业的更广泛趋势。西班牙BBVA银行已通过其应用程序提供全天候比特币和以太坊交易服务，法国BPCE集团和比利时KBC银行也推出了零售加密服务。同时，包括法国巴黎银行、德意志银行在内的12家主要欧洲银行已组建联盟，计划在2026年下半年推出符合欧盟MiCA法规的欧元稳定币。

bitcoinist2 小時前

bitcoinist2 小時前

加密货币季度报告：机构投资者在2026年第一季度如何配置资本

2026年第一季度，加密货币市场经历了一段艰难时期，比特币价格在2月初曾跌至62,000美元低位。在此背景下，各大机构投资者展现了不同的策略。阿布扎比主权财富基金穆巴达拉投资公司显著增加了对贝莱德iShares比特币信托（IBIT）的持仓，份额增至约1472万股，价值约5.66亿美元。加拿大皇家银行、加拿大丰业银行和巴克莱银行等传统金融机构也在增持IBIT的同时，运用期权策略对冲风险。与此相反，哈佛大学捐赠基金持续削减其加密货币敞口。继2025年第四季度减持21%后，其在第一季度进一步减持了43%的IBIT份额，并清空了其以太坊ETF头寸。其他常春藤盟校如布朗大学和达特茅斯学院的IBIT持仓则保持不变，但达特茅斯将其以太坊持仓转为灰度以太坊质押ETF，并新建了Bitwise Solana质押ETF的头寸。机构投资者在市场的低迷期或增持或调整仓位，可能视其为买入机会，而非否定其长期潜力。目前，整个加密货币市场市值约为2.57万亿美元，2026年至今仍下跌超过12%。

bitcoinist3 小時前

bitcoinist3 小時前

《清晰法案》进展推动比特币市场情绪触及2026年新高

5月14日，美国参议院银行委员会推进《CLARITY法案》后，比特币价格应声上涨超过3.5%。但随后市场情绪反转，比特币价格掉头向下，引发市场关注。链上分析机构Santiment报告称，该法案的进展显著提振了市场情绪，使比特币的“群体看涨情绪”达到今年最贪婪的水平之一。该法案旨在为数字资产行业建立更清晰的法律监管框架，长期被视为利好，因为它能增加投资者的确定性。然而，分析师警告，这种过度的市场狂热情绪本身可能预示着短期的看跌压力。历史经验表明，当看涨与看跌评论比例达到1.55:1时，市场常会向群体预期的相反方向运动。另一方面，知名分析师Ali Martinez指出，比特币矿工在过去96小时内出售了约800枚BTC（价值约6400万美元）。矿工作为持续的卖家，其抛售活动增加可能影响短期供应动态和情绪，通常预示着价格可能进入弱势或盘整阶段。综合市场极度乐观情绪和矿工抛售行为，比特币价格在短期内可能面临调整压力。截至发稿时，比特币价格报79,136美元，24小时内下跌2.9%。

bitcoinist7 小時前

bitcoinist7 小時前

交易

現貨

合約

熱門文章

什麼是 $S$

理解 SPERO：全面概述 SPERO 簡介隨著創新領域的不斷演變，web3 技術和加密貨幣項目的出現在塑造數字未來中扮演著關鍵角色。在這個動態領域中，SPERO（標記為 SPERO,$$s$）是一個引起關注的項目。本文旨在收集並呈現有關 SPERO 的詳細信息，以幫助愛好者和投資者理解其基礎、目標和在 web3 和加密領域內的創新。 SPERO,$$s$ 是什麼？ SPERO,$$s$ 是加密空間中的一個獨特項目，旨在利用去中心化和區塊鏈技術的原則，創建一個促進參與、實用性和金融包容性的生態系統。該項目旨在以新的方式促進點對點互動，為用戶提供創新的金融解決方案和服務。 SPERO,$$s$ 的核心目標是通過提供增強用戶體驗的工具和平台來賦能個人。這包括使交易方式更加靈活、促進社區驅動的倡議，以及通過去中心化應用程序（dApps）創造金融機會的途徑。SPERO,$$s$ 的基本願景圍繞包容性展開，旨在彌合傳統金融中的差距，同時利用區塊鏈技術的優勢。誰是 SPERO,$$s$ 的創建者？ SPERO,$$s$ 的創建者身份仍然有些模糊，因為公開可用的資源對其創始人提供的詳細背景信息有限。這種缺乏透明度可能源於該項目對去中心化的承諾——這是一種許多 web3 項目所共享的精神，優先考慮集體貢獻而非個人認可。通過將討論重心放在社區及其共同目標上，SPERO,$$s$ 體現了賦能的本質，而不特別突出某些個體。因此，理解 SPERO 的精神和使命比識別單一創建者更為重要。誰是 SPERO,$$s$ 的投資者？ SPERO,$$s$ 得到了來自風險投資家到天使投資者的多樣化投資者的支持，他們致力於促進加密領域的創新。這些投資者的關注點通常與 SPERO 的使命一致——優先考慮那些承諾社會技術進步、金融包容性和去中心化治理的項目。這些投資者通常對不僅提供創新產品，還對區塊鏈社區及其生態系統做出積極貢獻的項目感興趣。這些投資者的支持強化了 SPERO,$$s$ 作為快速發展的加密項目領域中的一個重要競爭者。 SPERO,$$s$ 如何運作？ SPERO,$$s$ 採用多面向的框架，使其與傳統的加密貨幣項目區別開來。以下是一些突顯其獨特性和創新的關鍵特徵：去中心化治理：SPERO,$$s$ 整合了去中心化治理模型，賦予用戶積極參與決策過程的權力，關於項目的未來。這種方法促進了社區成員之間的擁有感和責任感。代幣實用性：SPERO,$$s$ 使用其自己的加密貨幣代幣，旨在在生態系統內部提供多種功能。這些代幣使交易、獎勵和平台上提供的服務得以促進，增強了整體參與度和實用性。分層架構：SPERO,$$s$ 的技術架構支持模塊化和可擴展性，允許在項目發展過程中無縫整合額外的功能和應用。這種適應性對於在不斷變化的加密環境中保持相關性至關重要。社區參與：該項目強調社區驅動的倡議，採用激勵合作和反饋的機制。通過培養強大的社區，SPERO,$$s$ 能夠更好地滿足用戶需求並適應市場趨勢。專注於包容性：通過提供低交易費用和用戶友好的界面，SPERO,$$s$ 旨在吸引多樣化的用戶群體，包括那些以前可能未曾參與加密領域的個體。這種對包容性的承諾與其通過可及性賦能的總體使命相一致。 SPERO,$$s$ 的時間線理解一個項目的歷史提供了對其發展軌跡和里程碑的關鍵見解。以下是建議的時間線，映射 SPERO,$$s$ 演變中的重要事件：概念化和構思階段：形成 SPERO,$$s$ 基礎的初步想法被提出，與區塊鏈行業內的去中心化和社區聚焦原則密切相關。項目白皮書的發布：在概念階段之後，發布了一份全面的白皮書，詳細說明了 SPERO,$$s$ 的願景、目標和技術基礎設施，以吸引社區的興趣和反饋。社區建設和早期參與：積極進行外展工作，建立早期採用者和潛在投資者的社區，促進圍繞項目目標的討論並獲得支持。代幣生成事件：SPERO,$$s$ 進行了一次代幣生成事件（TGE），向早期支持者分發其原生代幣，並在生態系統內建立初步流動性。首次 dApp 上線：與 SPERO,$$s$ 相關的第一個去中心化應用程序（dApp）上線，允許用戶參與平台的核心功能。持續發展和夥伴關係：對項目產品的持續更新和增強，包括與區塊鏈領域其他參與者的戰略夥伴關係，使 SPERO,$$s$ 成為加密市場中一個具有競爭力和不斷演變的參與者。結論 SPERO,$$s$ 是 web3 和加密貨幣潛力的見證，能夠徹底改變金融系統並賦能個人。憑藉對去中心化治理、社區參與和創新設計功能的承諾，它為更具包容性的金融環境鋪平了道路。與任何在快速發展的加密領域中的投資一樣，潛在的投資者和用戶都被鼓勵進行徹底研究，並對 SPERO,$$s$ 的持續發展進行深思熟慮的參與。該項目展示了加密行業的創新精神，邀請人們進一步探索其無數可能性。儘管 SPERO,$$s$ 的旅程仍在展開，但其基礎原則確實可能影響我們在互聯網數字生態系統中如何與技術、金融和彼此互動的未來。

85 人學過發佈於 2024.12.17更新於 2024.12.17

什麼是 AGENT S

Agent S：Web3中自主互動的未來介紹在不斷演變的Web3和加密貨幣領域，創新不斷重新定義個人如何與數字平台互動。Agent S是一個開創性的項目，承諾通過其開放的代理框架徹底改變人機互動。Agent S旨在簡化複雜任務，為人工智能（AI）提供變革性的應用，鋪平自主互動的道路。本詳細探索將深入研究該項目的複雜性、其獨特特徵以及對加密貨幣領域的影響。什麼是Agent S？ Agent S是一個突破性的開放代理框架，專門設計用來解決計算機任務自動化中的三個基本挑戰：獲取特定領域知識：該框架智能地從各種外部知識來源和內部經驗中學習。這種雙重方法使其能夠建立豐富的特定領域知識庫，提升其在任務執行中的表現。長期任務規劃：Agent S採用經驗增強的分層規劃，這是一種戰略方法，可以有效地分解和執行複雜任務。此特徵顯著提升了其高效和有效地管理多個子任務的能力。處理動態、不均勻的界面：該項目引入了代理-計算機界面（ACI），這是一種創新的解決方案，增強了代理和用戶之間的互動。利用多模態大型語言模型（MLLMs），Agent S能夠無縫導航和操作各種圖形用戶界面。通過這些開創性特徵，Agent S提供了一個強大的框架，解決了自動化人機互動中涉及的複雜性，為AI及其他領域的無數應用奠定了基礎。誰是Agent S的創建者？儘管Agent S的概念根本上是創新的，但有關其創建者的具體信息仍然難以捉摸。創建者目前尚不清楚，這突顯了該項目的初期階段或戰略選擇將創始成員保密。無論是否匿名，重點仍然在於框架的能力和潛力。誰是Agent S的投資者？由於Agent S在加密生態系統中相對較新，關於其投資者和財務支持者的詳細信息並未明確記錄。缺乏對支持該項目的投資基礎或組織的公開見解，引發了對其資金結構和發展路線圖的質疑。了解其支持背景對於評估該項目的可持續性和潛在市場影響至關重要。 Agent S如何運作？ Agent S的核心是尖端技術，使其能夠在多種環境中有效運作。其運營模型圍繞幾個關鍵特徵構建：類人計算機互動：該框架提供先進的AI規劃，力求使與計算機的互動更加直觀。通過模仿人類在任務執行中的行為，承諾提升用戶體驗。敘事記憶：用於利用高級經驗，Agent S利用敘事記憶來跟蹤任務歷史，從而增強其決策過程。情節記憶：此特徵為用戶提供逐步指導，使框架能夠在任務展開時提供上下文支持。支持OpenACI：Agent S能夠在本地運行，使用戶能夠控制其互動和工作流程，與Web3的去中心化理念相一致。與外部API的輕鬆集成：其多功能性和與各種AI平台的兼容性確保了Agent S能夠無縫融入現有技術生態系統，成為開發者和組織的理想選擇。這些功能共同促成了Agent S在加密領域的獨特地位，因為它以最小的人類干預自動化複雜的多步任務。隨著項目的發展，其在Web3中的潛在應用可能重新定義數字互動的展開方式。 Agent S的時間線 Agent S的發展和里程碑可以用一個時間線來概括，突顯其重要事件： 2024年9月27日：Agent S的概念在一篇名為《一個像人類一樣使用計算機的開放代理框架》的綜合研究論文中推出，展示了該項目的基礎工作。 2024年10月10日：該研究論文在arXiv上公開，提供了對框架及其基於OSWorld基準的性能評估的深入探索。 2024年10月12日：發布了一個視頻演示，提供了對Agent S能力和特徵的視覺洞察，進一步吸引潛在用戶和投資者。這些時間線上的標記不僅展示了Agent S的進展，還表明了其對透明度和社區參與的承諾。有關Agent S的要點隨著Agent S框架的持續演變，幾個關鍵特徵脫穎而出，強調其創新性和潛力：創新框架：旨在提供類似人類互動的直觀計算機使用，Agent S為任務自動化帶來了新穎的方法。自主互動：通過GUI自主與計算機互動的能力標誌著向更智能和高效的計算解決方案邁進了一步。複雜任務自動化：憑藉其強大的方法論，能夠自動化複雜的多步任務，使過程更快且更少出錯。持續改進：學習機制使Agent S能夠從過去的經驗中改進，不斷提升其性能和效率。多功能性：其在OSWorld和WindowsAgentArena等不同操作環境中的適應性確保了它能夠服務於廣泛的應用。隨著Agent S在Web3和加密領域中的定位，其增強互動能力和自動化過程的潛力標誌著AI技術的一次重大進步。通過其創新框架，Agent S展現了數字互動的未來，為各行各業的用戶承諾提供更無縫和高效的體驗。結論 Agent S代表了AI與Web3結合的一次大膽飛躍，具有重新定義我們與技術互動方式的能力。儘管仍處於早期階段，但其應用的可能性廣泛且引人入勝。通過其全面的框架解決關鍵挑戰，Agent S旨在將自主互動帶到數字體驗的最前沿。隨著我們深入加密貨幣和去中心化的領域，像Agent S這樣的項目無疑將在塑造技術和人機協作的未來中發揮關鍵作用。

766 人學過發佈於 2025.01.14更新於 2025.01.14

如何購買S

歡迎來到HTX.com！在這裡，購買Sonic (S)變得簡單而便捷。跟隨我們的逐步指南，放心開始您的加密貨幣之旅。第一步：創建您的HTX帳戶使用您的 Email、手機號碼在HTX註冊一個免費帳戶。體驗無憂的註冊過程並解鎖所有平台功能。立即註冊第二步：前往買幣頁面，選擇您的支付方式信用卡/金融卡購買：使用您的Visa或Mastercard即時購買Sonic (S)。餘額購買：使用您HTX帳戶餘額中的資金進行無縫交易。第三方購買：探索諸如Google Pay或Apple Pay等流行支付方式以增加便利性。C2C購買：在HTX平台上直接與其他用戶交易。HTX 場外交易 (OTC) 購買：為大量交易者提供個性化服務和競爭性匯率。第三步：存儲您的Sonic (S)購買Sonic (S)後，將其存儲在您的HTX帳戶中。您也可以透過區塊鏈轉帳將其發送到其他地址或者用於交易其他加密貨幣。第四步：交易Sonic (S)在HTX的現貨市場輕鬆交易Sonic (S)。前往您的帳戶，選擇交易對，執行交易，並即時監控。HTX為初學者和經驗豐富的交易者提供了友好的用戶體驗。

1.6k 人學過發佈於 2025.01.15更新於 2025.03.21