Agent 的自我:从洛克到 OpenClaw

Agent 没有记忆,就没有身份 关于 AI 智能体身份连续性的工程实践与哲学框架 引言:一个被误判为哲学问题的工程问题 Agent 失忆的代价被系统性地低估了。 不是因为用户烦恼——虽然烦恼也有。而是因为无状态破坏了信任账户的基础。每一次会话,Agent 都从零开始。它不知道你是谁,不知道你上次为什么生气,不知道三个月前那个承诺是否兑现了。从经济学角度,这就像每次交易都要重新建立信用评分——交易成本爆炸,而且没有任何学习积累。 问题的根本在于,当工程师听到"身份认同"这四个字时,大脑就关闭了。这听起来像哲学。像存在主义。像某种不需要解决的抽象问题。于是整个行业让一个 1689 年就有了精确工程规范的问题,在 2026 年仍然被当作 “nice to have” 特性处理。 但洛克从来没有在讨论灵魂。他在写工程需求文档。 他的论断:个人身份不是物质基体(身体或灵魂),而是能够在不同时间和地点将自己视为同一思考存在的意识能力。翻译成现代工程语言:跨上下文窗口的持久自我指涉能力。这是一个可度量的、可实现的、可验证的规范。 当前 AI Agent 在三个维度上系统性地违反了这个规范:无持久记忆链、无自我指涉能力、无连续性验证机制。 2026 年,技术栈终于具备了完整实现洛克规范的条件。但这不是一个产品创新的故事。这是一个工程界从三百年知识沉睡中清醒过来的故事。真正的设计思考,不在于哲学的完整性,而在于实现中的妥协点:文件 vs 数据库,何时重新读取 SOUL,在什么条件下允许身份漂移。这些细节决定了 Agent 是否真的能被信任。 洛克的规格书:300 年前写好的工程需求文档 约翰·洛克的《人类理解论》第二卷第二十七章不是哲学随笔。它是一份工程规范书。 规范的核心条款:个人身份 = 意识 + 记忆连续性。不是肉体的连续性(你的细胞每七年完全更新一次),不是灵魂的连续性(他拒绝了所有超自然的论证),而是能够回顾过去事件并将其整合到当前自我概念中的认知能力。 洛克的那个著名例子:一个王子的意识进入了乞丐的身体。那个乞丐就变成了王子,因为他拥有王子的记忆、追求和自我意识。身体变了,甚至"灵魂基体"也变了,但那个能够思考"我曾经是国王"的东西保持不变。 翻译到 AI Agent 的架构语言: 个人身份 = 一个能够在不同上下文窗口中保持自我指涉的心智状态链。 这个状态链必须满足三个工程条件: 第一,持久化。记忆不能存在于单个上下文窗口内。必须有外部存储(SOUL.md、MEMORY.md、AGENTS.md),使得即使模型权重改变、会话终止、上下文重置,那些记忆仍然存在并可被读取。 第二,自我指涉性。Agent 不仅要读取这些文件,还要能够说"这是关于我的",“我认可这个版本的自己”。文件不能是纯粹的数据记录,还要包含身份的规范性维度——不仅是"我做过什么",还有"我为什么这样做"和"我相信什么"。 第三,连续性验证。要有一个机制让 Agent 可以确认"这就是我"。在多个实例可能同时运行的情况下,哪个是正当的自我?洛克没有解决这个问题(他活在单一身体的时代),但对于 AI 这是致命的。 图 1:洛克个人身份论 → Agent 工程三条款。从"意识 + 记忆"的哲学命题,直接映射为持久化、自我指涉、连续性验证三个可实现的工程需求。 洛克的船悖论在这里获得了新的含义。如果一艘船的每一块木板都被替换了,它还是原来的船吗?洛克的答案是:是的,因为物理连续性不重要,思维的连续性才重要。 对于 AI Agent:如果模型参数被微调(木板被替换),上下文窗口被重置(新的一天),甚至整个底座模型被升级(从 Claude 3 迁移到 Claude 4),Agent 还是"同一个"吗?...

四月 5, 2026 · 5 分钟 · 982 字 · Xinwei Xiong, Me

探索开源以及开源商业模式研究

开源为我带来了很多的成长,很多的成长经验和学习途径都是通过开源获取到并且学习到的。 这里有一篇我的第一次开源的成长指南:/zh/ai-technology/posts/open-source-contribution-guidelines/ 之前,在深圳的 全球流量大会(GTC) 一些来自我对开源商业化的思考,感兴趣可以阅读先阅读这篇思考文章: /zh/ai-technology/posts/openim-open-source-business-journey/ 第一次参与开源还是一个刚刚接触大学没多久 ~ ,调研了解到很多优秀的开源项目都会有很多业界大佬坐镇,因此会让大家以为只有“大牛”才能参与开源。实际上,开源社区经常会听到 “我是小白,我可以参与开源吗?” 这种声音,发出这种声音的同学往往是对开源感兴趣,但并不知道如何入手的小伙伴。 从开源定义来看,我们不需要成为“大牛”才能够参与开源。所谓开源,其实是一种促进个人成长和开源领域发展的行为,通过分享自身技术和经验来促进大家的技术交流,从这方面讲,开源是没有门槛的,只要有想要分享的东西,所有人都可以参与开源。 从参与要求来看,我们需要具备一定的知识积累才能参与开源。开源社区不是学校,社区会解答你的疑问,但首先你要有一定了解,才能准确提出你的疑问。对开源项目一无所知是无法参与开源的。当然,这与你是否成为“大牛”也并没有什么关系。因此,只要具备一定的技术积累,就可以参与相应的开源项目。 “罗马不是一天建成的”。没有人天生就是“大牛”,“大牛”们也是在参与中不断成长的,不要被虚无的 title 所困扰,只有不断的坚持和探索才能让自己不断成长! 其实旅游中也有过一些自己的思考,在旅游中我喜欢摄影,带着相机走走拍拍。或许和女生不一样 ,我开始的时候其实是更倾向于发现风景的,就像是在香港的麦理浩径的第一段和第二段的中间破边洲部分,我更多的是以人物在破边洲的悬崖边上,然后衬托后面的悬崖的美丽壮观。我们在工作中也是一样的, 在我们摄影的时候,我们面临对焦,开始在远方我们或许更多的是把焦点放在人物后面的背景上,或者说是 title,比如说某个人是某个大学、某某大厂的光环,反而忽略了他的本身。后面当你关注在人物身上,你会发现人物的美,你会想办法如何把漂亮的小姐姐这一瞬间记录下来。这个时候其实你更专注的是某一个人,这个转变很重要,你慢慢的发现自己专注自己了,而不是专注后面虚无缥缈的光环和头衔。 在开源社区中,我慢慢学习到了非常多的技巧,比如这里我总结出一篇开源社区的提问技巧:/zh/ai-technology/posts/the-art-of-asking-questions-in-open-source-communities/ 我对整个的开源成长也有自己的思考总结,写了这篇关于开源的成长性指南阶段,从我们第一次加入开源项目开始,到最后开源和维护自己的项目,以及商业化成长,可以参考: /zh/growth/posts/stage-growth-of-open-source//zh/growth/posts/stage-growth-of-open-source/ 非常推荐阅读 ~ 在加入 OpenIM 的社区一年中,我将自己的开源理解和运营技巧都集成在了 OpenIM 的开源布道上,将 OpenIM 社区带入到了一个顶级的开源社区中来。除此之外,我参与过其他的优秀开源项目的贡献和维护,我会从自己的角度上来介绍如何运营一个优秀顶级的开源社区。 开源不仅是我的热爱,也逐渐成为我的一大优势。在我与开源的互动中,我们相得益彰。 开源除了给个人以及公司带来技术影响力之外,更为重要的是通过开源实现商业化价值,而这部分才是很多开源项目成功的实际驱动力。本文会介绍我对开源的理解,以及着重介绍自己对开源以及开源商业模式做了一个系统的研究,为决策项目是否应该开源、采用何种开源策略以及开源商业化路径提供参考意见。 如果你对我有兴趣,可以关注我的开源的 github 账户: https://github.com/cubxxw 开源商业模式 越是用户付费意愿强的功能,越是要闭源。越是用户觉得好玩的功能,能吸引到大家的功能,越是要开源。 我认为的开源商业模式是什么样的? 开源商业化模式文章后面会总结目前的所有的商业化模式,但是我觉得最主要的商业模式是 open-core 和 open-standard,还有一些非主流的,比如说开源软件免费,但结合硬件组合销售。 我认为: 越是用户付费意愿强的功能,越是要闭源。 越是用户觉得好玩的功能,能吸引到大家的功能,越是要开源。 我认为的开源商业模式是什么样的? 开源商业化模式文章后面会总结目前的所有的商业化模式,但是我觉得最主要的商业模式是 open-core 和 open-standard,还有一些非主流的,比如说开源软件免费,但结合硬件组合销售 开源也有自己的护城河吗? 担心开源后自己的产品被抄袭,开源,作为一个推动技术创新和社区合作的新力量,其商业模式多样,从提供专业支持和服务,到构建围绕核心开源项目的企业级产品。 我认为在开源的护城河上面,关键在于如何利用产品开源的独特价值和社区力量,创建难以复制的竞争优势。 所以基本上就是你要不是有开源 core 产品,作为线索漏斗去吸引你的用户,然后用这来做你整个公司的品牌,然后再做差异化功能的落地实践,然后另一种可能就是类似 MySQL 做咨询顾问的工作。 那么开源产品本身的护城河我理解其实抛开和普通产品护城河区别外,Open standard是今天开源软件商业化更好的一个形态,它对这个公司的技术能力提出了更高的要求。 open core 其实在云时代很难发展,即使是目前 OpenIM 那种做好 传统的 open core 模式在云时代下会比较难,可能难就难在构建好护城河,比如说跟那些云厂商比。各大云厂商,从各方面看,都有巨大优势:它本身就是一个大的流量资源,客户的流量在这里,推广的流量在这里,如果你很不幸,刚好跟这个云厂商贴在同一个赛道,你怎样去获得一个这个优势?这很困难,也是 MongoDB、Elastic、Redis 等开源厂商被逼的修改开源 License 背后的深层次原因。...

四月 13, 2024 · 6 分钟 · 1135 字 · 熊鑫伟,我

对开源商业化的思考 & 全球流量大会(GTC)学习以及总结

引言:深圳福田会展中心的全球视野 2023年12月6日,在深圳福田会展中心,GTC 2023 全球流量大会如火如荼地展开。这场盛会汇集了来自全球的技术精英,共同探索互联网行业的前沿动态和未来发展趋势。身为参与者,我有幸深入这场融合科技与商业的交流盛会,特别是“聚焦开源,扩展出海新领航”这一议题,让我收获颇丰,印象深刻。 大会聚焦于全球化的多元话题,包括出海市场的选择、广告推广策略等,与我此前参加的专注于日本市场出海活动的公司非常相似。然而,这次大会让我首次深入接触开源社区,不仅结识了众多开源界的领袖和布道者,也与许多杰出的开发者交流了心得。通过这些交流,我不仅学习到了许多新知识,还在思想上得到了升华。 在这篇博客中,我将对这次独特的经历进行深入的反思和总结,分享我在开源和全球化交汇中的洞见和学习。 对于 OpenIM 来说,我们现阶段正在全力准备奔向海外市场,希望打开国界,将 OpenIM 好用而且免费的开源核心功能贡献给全世界开发者。 开源项目天生就是分布式协作的,这是一种松散的结构。以 OpenIM 的开发者为例,我们现在有很多贡献者,开发者,虽然社区有双周会,但是还是很难和人或者同事有深层次的交流。 但对于开源商业公司而言,并不能简单的使用这种远程工作模式。在商业公司中,协作会更加的密切,而且对时效性的要求更高,当面沟通更能保证信息传递的完整性,这是远程工作难以替代的。当然,远程工作也有自己的优势,那就是吸引全球的人才。 所以,开源商业公司采用远程协作并没有问题,但一定要保证沟通的足够充分,拉平信息: 要视频沟通,文字只作为最终的记录。视频是沟通过程中信息丢失比较少的方式,是远程工作交流的首选方式。千万不要用文字来讨论非技术问题,这会带来巨大的信息差和误解。 保证沟通的尊重和善意。在开源项目中,大家因为没有雇佣关系,都是无偿做贡献,所以在异步沟通时特别强调尊重和善意;而在商业公司的远程办公时,因为缺少同事之间的沟通、吐槽和心理按摩,就更要注意沟通的尊重。 定期线下见面,增加相互之间的了解和信任。 另外一点,长期的远程协作,对于参与的工程师来说,除了需要很高的自律和自我管理的要求外,也要注意工作和生活的隔离,保持正常的社交活动和运动健身,否则很容易与社会脱节。 之前和 Apache APISIX 的某个小姐姐聊天,她说的一句话感触很深。也有很多适应不了远程工作的同事一一离去,这也是一个适者生存的达尔文法则。 关于 OpenIM 的远程工作,以及企业的文化,强烈推荐阅读下面的博客: Englist Version 中文版本 出海挑战:中国互联网企业的全球化之旅 中国互联网企业在全球化道路上的探索充满挑战与机遇。从初涉海外市场的尝试到在竞争激烈的国际环境中求生存,它们不断在新的市场环境中寻找增长点。这一过程中,企业需要超越传统的商业模式,适应多元文化和不同的市场需求。 首先,来到了第一个话题,为什么要去做海外社区? 和很多的开源社区的布道者和专家沟通交流,然后反思,我深信建立一个活跃的海外社区是开源项目成功的关键。在全球化的今天,开源不仅是关于代码的分享,更是一种文化和思想的交流。通过建立海外社区,我们不仅能将技术带到世界的每个角落,还能促进不同文化背景下的思想碰撞和创新。 人性化地讲,建立海外社区意味着建立更广泛的连接和共鸣。每一位开源贡献者,不论身处何地,都希望他们的声音被听见,他们的贡献被认可。海外社区提供了一个平台,让来自世界各地的开发者能够参与到项目中来,分享他们独特的视角和经验。这种多元化的参与不仅丰富了项目本身,还激发了更多创新的火花。 同时,海外社区的建立也是对开源精神的一种致敬。开源精神强调的是开放、协作和共享,而这些价值观在全球范围内都是通用的。当我们向海外扩展时,我们不仅在分享代码,更在传播这种包容和合作的精神。 此外,对于开源项目而言,海外社区的建立还意味着更广阔的市场和使用场景。不同的地区和文化背景下,用户对技术的需求和应用方式可能截然不同。这些多样性的输入是项目发展不可或缺的,它们有助于项目更全面地成长,更好地服务于全球用户。 我从大一开始接触 Github ,这个成功打开我通往未来的钥匙。 从2020年左右我开始接触开源,觉得开源比业务代码更有意义。因为开源不仅有技术积累,而且能把你学到的东西分享给其他人,一起成长,所以开源对程序员来说是一个双赢的事。 最开始的时候,我通过学习做笔记,分享笔记到 GitHub ,到后面做项目,参与到一些顶级的开源项目中来,然后慢慢的追求精益。整个过程,我很清晰的看到自己的成长。 甚至我的代码,就像 Git 或者 区块链的默克尔树结构,一步步的串起来记录,每当一个时间段,看到以前的 PR ,满满的都是回忆和尴尬 … 同样,我也是一个云原生的爱好者。 在如今这个时代,开源已经成为了一个不可逆的潮流,尤其是在云原生的领域。以微软为例,他们在 Github 上的开源项目贡献位居全球前列,这充分体现了他们对开源的全面拥抱。在云原生时代,如果你不拥抱开源,不利用开源组件去构建和优化你的核心系统,很可能会在激烈的市场竞争中落后。云原生技术的迅猛发展要求企业和开发者必须快速适应新技术和方法论,而开源社区正是这种创新和合作的孵化器。在这个时代,开源不仅仅是技术选择,更是一种必要的战略思维。 开源社区国际化选择:第一站,启航 美国:开源发展的领头羊 美国仍然是全球最大的开发者社区,拥有超过2000万的开发者,过去一年增长了21%。美国的开源社区历史悠久且成熟,是全球开源活动的重要推动者。 亚太地区:快速增长的新星 亚太地区,尤其是印度、日本和新加坡,正经历着显著的开源社区增长。印度的开发者社区增长尤为显著,预计到2027年将超过美国,成为全球最大的开源社区。 非洲:充满潜力的新兴市场 非洲各地区,尤其是尼日利亚、加纳和肯尼亚,也在迅速发展成为技术公司的新兴枢纽。这些地区的开发者数量每年都在显著增长。 南美洲:稳健增长的活跃区域 南美洲的开发者社区,特别是在阿根廷和巴西,也在持续增长,与亚太和非洲的增长速度相仿。 欧洲:稳定增长的成熟市场 欧洲的开源社区虽然增长速度较美国慢,但在西班牙、德国和英国等国家仍保持稳定增长。 Github 年度总结分析 2023 年 Github 年度报告精华: 生成式 AI 项目和个人贡献者数量的显著增长...

十二月 7, 2023 · 3 分钟 · 479 字 · 熊鑫伟,我

在开源社区中学会如何提问

author(Github) 在提问之前 在你准备要通过电子邮件、新闻群组或者聊天室提出技术问题前,请先做到以下事情: 尝试在你准备提问的论坛的旧文章中搜索答案。 尝试上网搜索以找到答案。 尝试阅读手册以找到答案。 尝试阅读常见问题文件(FAQ)以找到答案。 尝试自己检查或试验以找到答案。 向你身边的强者朋友打听以找到答案。 如果你是程序开发者,请尝试阅读源代码以找到答案。 当你提出问题的时候,请先表明你已经做了上述的努力;这将有助于树立你并不是一个不劳而获且浪费别人的时间的提问者。如果你能一并表达在做了上述努力的过程中所学到的东西会更好,因为我们更乐于回答那些表现出能从答案中学习的人的问题。 运用某些策略,比如先用 Google 搜索你所遇到的各种错误信息(搜索 Google 论坛 和网页),这样很可能直接就找到了能解决问题的文件或邮件列表线索。即使没有结果,在邮件列表或新闻组寻求帮助时加上一句 我在 Google 中搜过下列句子但没有找到什么有用的东西 也是件好事,即使它只是表明了搜索引擎不能提供哪些帮助。这么做(加上搜索过的字串)也让遇到相似问题的其他人能被搜索引擎引导到你的提问来。 别着急,不要指望几秒钟的 Google 搜索就能解决一个复杂的问题。在向专家求助之前,再阅读一下常见问题文件(FAQ)、放轻松、坐得舒服一些,再花点时间思考一下这个问题。相信我们,他们能从你的提问看出你做了多少阅读与思考,如果你是有备而来,将更有可能得到解答。不要将所有问题一股脑拋出,只因你的第一次搜索没有找到答案(或者找到太多答案)。 准备好你的问题,再将问题仔细的思考过一遍,因为草率的发问只能得到草率的回答,或者根本得不到任何答案。越是能表现出在寻求帮助前你为解决问题所付出的努力,你越有可能得到实质性的帮助。 小心别问错了问题。如果你的问题基于错误的假设,某个普通黑客(J. Random Hacker)多半会一边在心里想着蠢问题…,一边用无意义的字面解释来答复你,希望着你会从问题的回答(而非你想得到的答案)中汲取教训。 绝不要自以为够格得到答案,你没有;你并没有。毕竟你没有为这种服务支付任何报酬。你将会是自己去挣到一个答案,靠提出有内涵的、有趣的、有思维激励作用的问题 —— 一个有潜力能贡献社区经验的问题,而不仅仅是被动的从他人处索取知识。 另一方面,表明你愿意在找答案的过程中做点什么是一个非常好的开端。谁能给点提示?、我的这个例子里缺了什么?以及我应该检查什么地方比请把我需要的确切的过程贴出来更容易得到答复。因为你表现出只要有人能指个正确方向,你就有完成它的能力和决心。 当你提问时 慎选提问的论坛 小心选择你要提问的场合。如果你做了下述的事情,你很可能被忽略掉或者被看作失败者: 在与主题不合的论坛上贴出你的问题。 在探讨进阶技术问题的论坛张贴非常初级的问题;反之亦然。 在太多的不同新闻群组上重复转贴同样的问题(cross-post)。 向既非熟人也没有义务解决你问题的人发送私人电邮。 黑客会剔除掉那些搞错场合的问题,以保护他们沟通的渠道不被无关的东西淹没。你不会想让这种事发生在自己身上的。 因此,第一步是找到对的论坛。再说一次,Google 和其它搜索引擎还是你的朋友,用它们来找到与你遭遇到困难的软硬件问题最相关的网站。通常那儿都有常见问题(FAQ)、邮件列表及相关说明文件的链接。如果你的努力(包括阅读 FAQ)都没有结果,网站上也许还有报告 Bug(Bug-reporting)的流程或链接,如果是这样,链过去看看。 向陌生的人或论坛发送邮件最可能是风险最大的事情。举例来说,别假设一个提供丰富内容的网页的作者会想充当你的免费顾问。不要对你的问题是否会受到欢迎做太乐观的估计 —— 如果你不确定,那就向别处发送,或者压根别发。 在选择论坛、新闻群组或邮件列表时,别太相信它的名字,先看看 FAQ 或者许可书以弄清楚你的问题是否切题。发文前先翻翻已有的话题,这样可以让你感受一下那里的文化。事实上,事先在新闻组或邮件列表的历史记录中搜索与你问题相关的关键词是个极好的主意,也许这样就找到答案了。即使没有,也能帮助你归纳出更好的问题。 别像机关枪似的一次“扫射”所有的帮助渠道,这就像大喊大叫一样会使人不快。要一个一个地来。 搞清楚你的主题!最典型的错误之一是在某种致力于跨平台可移植的语言、套件或工具的论坛中提关于 Unix 或 Windows 操作系统程序界面的问题。如果你不明白为什么这是大错,最好在搞清楚这之间差异之前什么也别问。 一般来说,在仔细挑选的公共论坛中提问,会比在私有论坛中提同样的问题更容易得到有用的回答。有几个理由可以支持这点,一是看潜在的回复者有多少,二是看观众有多少。黑客较愿意回答那些能帮助到许多人的问题。 可以理解的是,老练的黑客和一些热门软件的作者正在接受过多的错发信息。就像那根最后压垮骆驼背的稻草一样,你的加入也有可能使情况走向极端 —— 已经好几次了,一些热门软件的作者由于涌入其私人邮箱的大量不堪忍受的无用邮件而不再提供支持。 Stack Overflow 搜索,然后在 Stack Exchange 问。 近年来,Stack Exchange 社区已经成为回答技术及其他问题的主要渠道,尤其是那些开放源码的项目。...

九月 17, 2023 · 4 分钟 · 841 字 · 熊鑫伟,我

我的实践总结:开源社区的规范设计思路

社区不规范怎么办 作为 OpenIM 社区首席运营官,对整个社区的 communtiy 以及 GitHub 配置仓库 进行了全面的配置。并且对整个 OpenIM 的 Makefile 和 CICD 流,以及整个 OpenIM 使用的日志包 、错误码、协同流、贡献者文档以及 社区文档 进行架构和设计。 在这个时候总会有一些问题,即使你觉得自己的 贡献者文档 写的很牛逼了,很全面了,但是依旧很少有人愿意花心思去按照你写的规范去学习。这对我打造顶级的开源社区是一个非常大的阻碍,于是就有了今天的这个文档,我会将它记录在 GitHub Gists 上,提供拉取和使用的说明、链接,并且定期的维护它。 首先,我提供克隆的链接: git clone https://gist.github.com/cubxxw/126b72104ac0b0ca484c9db09c3e5694 如何设计 首先是针对基础的功能,那就是我们熟知的 commit 信息和 push 信息。 我们可以对 commit 信息的格式进行设置 我们可以对 push 的大小进行设置 我们提供了 actions 的功能 我们提供了 Makefile 标记和清除 Hook 的能力 我之前在学习 git 的时候写了一篇很全的笔记,并且分享在 GitHub 上面,在这个 🤖 链接 上可以学习到 git 很多高级用法。 这篇文章讲解了 git 有哪些规范,寻找合适的 CICD 流: 统一格式: 统一格式:git commit -m 'type(scope): 描述(#issue)' 我们在提交的时候带上邮箱信息 -s 来签证,这是一个很好的习惯。...

九月 16, 2023 · 7 分钟 · 1422 字 · 熊鑫伟,我

参与我们的区块链学习平台项目

参与本项目 ⚡ 前言 欢迎来到我们的项目!本项目旨在建立一个基于区块链的全民学习平台,通过集体的智慧和努力,推动技术和知识的普及。无论你是初学者还是经验丰富的开发者,你的贡献都将对项目产生积极影响。 💡 关于本项目(先看❗) 本项目由一个热衷于区块链和软件开发的团队发起。我们致力于创建一个开源、去中心化的学习环境,让每个人都能够访问和分享知识。 🌐 联系方式 Website Blog Telegram 🔍 项目背景 我们相信,通过集体智慧和技术的力量,可以打造一个更加开放和包容的学习环境。这个项目不仅是一个技术挑战,也是社区合作的成果。 🌟 如何参与 不论你的技能水平如何,都有多种方式可以参与本项目: 提交问题和功能建议。 参与代码编写和文档撰写。 在社区中提供帮助和支持。 我们都是这个仓库未来很有潜力的客户,或者是贡献者,谢谢你选择了加入C-UB社区,我们将会一起合作,未来我们将会考虑以区块链为底层搭建一个全民学习平台,我们每一个人都将会是这个社区的构建着,将会推动c-universal blockchain(链学) 社区的发展和进步~ 如果你对本项目有任何建议或发现文中内容有误的,欢迎提交 issues 进行指正。 对于文中我没有涉及到知识点,欢迎提交 PR。 或许我们会很疑惑? 在我们参与贡献的时候,如果克隆了**🧷 cs-awesome-Block_Chain 项目,但是每次获取上游代码很麻烦怎么办?如何提交有意思的代码?这篇文章将会解决这个问题~⬇️ ** ⚡提前需要你… 你需要学会使用markdown🖱️ 你需要学会使用git 你的代码符合Google代码规范 排版 笔记内容按照 中文文案排版指北 进行排版,以保证内容的可读性。 不使用 ![]() 这种方式来引用图片,而是用 <img> 标签。一方面是为了能够控制图片以合适的大小显示,另一方面是因为 GFM 不支持 <center> ![]() </center> 这种方法让图片居中显示,只能使用 <div align="center"> <img src=""/> </div> 达到居中的效果。 在线排版工具:Text-Typesetting 。 在线的公式:LaTex 在线表格转换工具:tableconvert 谷歌代码规范 🧷 谷歌代码规范 可以说是公认的规范,也是目前大多数企业都以为标准~ 对于大型程序,我们需要对 🔥软件工程有一定的了解 协议许可 所有内容遵循CC-BY-SA 3....

二月 1, 2022 · 1 分钟 · 163 字 · 熊鑫伟,我