2026-11-09 22:34:21
9/10 月份还是看了不少的电影的，不过一直没顾上写总结；于是乎，继续写一下总结；
整个9/10月份一共看了 5 部电影，其中按顺序来分别是：
奥德赛真的很长，看的我中间还是出去上了趟厕所。不过，我觉得这部剧拍的还不错，特别是马特达蒙的部分，他经历过的事情，真的很考验人性。
看完这部电影的时候，我突然在想：今天 AI 生图、生视频如此盛行，我们为什么不做我们自己的史诗？这部剧是荷马史诗，我们为什么不能拥有中国的史诗？这部电影看得我心生澎湃，我希望同样的状态，可以让海外的人也可以心生澎湃。
这部电影我去看的时候，没预期到会被这么吓到|ﾟДﾟ)))，整体还是把握吓得一愣一愣的。看这部电影一大感受是 —— 顶楼的实验人员本身不够尊重人和尊重世界，才最终造成了这样的事故，不然或许有改观。
如果你不怕吓，我觉得还行，可以看看。全场最佳的外卖小哥，还挺好玩的。
龙餐馆听说是反战的，所以来看的时候心里有数，倒也没那么害怕。但我对于人性的残忍还是没有预计到位。。。看到里面的校长做的事情，真的心底对于战争的厌恶又多一分。相比之下，老扎好了很多。
后面在抖音上看到有一些老扎后面的片段，我感觉是二创，但也算是大家对于老扎的认可。
我是奔着昆汀来的，杀死比尔 1 看着确实很有昆汀暴力美学的意思 —— 满屋子必须都是血。很刺激；
但是。。。第二部就非常的拉跨了。。。突然峰回路转，感觉昆汀的暴力美学没了，给我一种第二部分是另外一个人拍的。
以及，我最终还是看到的里面的彩蛋《失落的篇章：由纪的复仇》
肖申克的救赎之前我在电脑上看过，这次重映，我决定到影院去交一张电影票钱，重新回顾一下。好电影不愧是好电影，去电影院看依旧很爽。
而且，真的在看这部电影之后，对于自由和希望的理解，真的是又进一步。
2026-10-29 23:11:11
这本书似乎是微信读书单独出版的，很简短，内容相对浅薄，适合职场新人读。
问题也正出在这里。对于很多基础岗位来说，工资这东西，通常体现的是岗位的预算，而不是你实时创造的价值分成。
作为资源的提供者，必须面对一个现实：市场只为当下的稀缺性买单，绝不会为你过去的辛苦自动加价。
作为资源提供者，想要改善当下的处境，有三条路比较现实。第一，设法提高单位时间的“身价”，去竞争那些需求更旺、议价权更高且不容易被替代的岗位。第二，别让自己太依赖单一的雇主，要通过积累作品、案例、证书，或者经营行业口碑和客户关系，来提升自己的可迁移能力。第三，试着把经验转化成能反复使用的成果，比如做成课程、工具、模板、书稿，或者咨询流程、软件插件、数据服务，甚至是能独立售卖的作品。这三条路走起来都不容易，既需要持续学习，也得有勇气面对市场的反馈。
名气的商业价值，本质上是降低了别人认识你、信任你并最终选择你的成本。
对大多数普通人而言，一份沉甸甸的可信度，远比一时的热闹更值钱。
这就是消费者视角和经营者视角的本质区别。消费者关心的是“值不值得买”，而经营者关心的则是“为什么有人会一直愿意付钱”。
一个成立的需求，起码得满足四个条件：有人确实遇到了问题，这个问题足够具体，对方愿意为了解决它而掏钱，而且你能以自己承受得起的成本把方案交付到人家手里。
生意的起点永远在外部，而不是你的内心。它源于别人的麻烦、恐惧，源于人们想要节省时间、提高效率、获得身份认同，或者是想降低生活中的不确定性。
扩大规模通常有这么几种路径。第一，产品标准化。把原本依赖个人经验的服务拆解成清晰的步骤，降低培训门槛。第二，流程复制。让不同的员工都能按照同一套标准完成接待、报价、交付和售后。第三，自动化交付。利用系统来搞定下单、付款、发货、提醒、记录和客户管理。第四，渠道稳定。降低每一单都要重新找客户的获客成本。第五，团队分工。把财务、法务、供应链、运营和客服这些专业的事，交给专业的人去处理。
很多人起初以为创业就是做自己喜欢的事，可真正入场后才发现，大把的时间其实都耗在了合同、发票、退款、招聘、培训、投诉、库存、税务以及研究平台规则上。经营者赚的那份钱，本质上是你在处理完这些琐碎麻烦之后，还能剩下来的利润。
想懂财务，就读会计和商业基础；想懂消费，就读行为经济学和社会观察；想懂投资，就读资产定价、企业分析和金融史；想提升表达，就读优秀的非虚构作品和写作手册。带着问题去读，知识才能转化为你的判断力。先行动后补课，并不代表莽撞行事。它的核心逻辑是：用极小的成本通过行动暴露问题，再针对这些问题去针对性学习。
支出越高，所需的资产规模就越大；如果欲望没有边界，自由就永远不会到来。债务最昂贵的代价，往往不在利息，而在你失去的选择权。
耐心，绝不意味着两手一摊、无所作为。相反，它要求你保持持续的储蓄习惯，不断学习新知，敏锐地观察市场，并反复审视自己的判断是否依然站得住脚。
真正危险的处境，往往不是上班本身，而是你除了工资一无所有：没有储蓄，没有可迁移的能力，没有可复用的成果，却背负着越来越高的固定支出。所谓的自由能力，首先体现在识别合同上。你要看清自己正在向谁提供什么，对方凭什么付钱，你的身价由谁说了算，增长的收益归谁，风险什么时候会转移到你头上，以及退出的成本有多高。
2026-10-26 23:14:58
在 Harness Engineering 这个概念逐渐流行甚至要过气之后，我终于理解了这个词背后的含义。作为一个笨人，决定用费曼学习法，把 Harness Engineering 这个词讲明白，也算是对自己的一个交代。
在 ChatGPT 刚出来的时候，大家面对一个空白的输入框，不知道说什么好，于是我们看到大量的教程、指南和分享中，大家开始提prompt这个词。而随之而来的，便是 Prompt Engineering。
大家希望通过修改自己的 Prompt，来让模型返回不同的内容，从而达成让模型完成不同的工作任务。在 2023 年的时候，Prompt Engineering 作为一个指引，帮助我们把 Prompt 写的更加结构化、更加明确化，向模型描述我们到底希望看到和使用的内容的框架，指引和帮助很多人走上了 AI 之旅。
其中的技巧即使在今天，也并非完全失效，在这个阶段，由于应用的形态以 ChatBot 为主，同时 API 主要也是在使用 Chat Completions API 为主，在这个阶段，我们的主要对于上下文的操作就是不断 Append，把用户的输入和模型的输入一起写入到整个会话的 Message。
但只有 Chatbot 是无法满足业务的需求的；我们开始研究使用 LLM 来完成更多的工作，并随着 GPT 3.5 Turbo /GPT4 支持 ToolCall ，LLM 开始可以稳定的输出更多的信息，从而延伸出了更多的功能和能力；我们开始在整个会话轮次中塞入更多的东西。Chat Completions API 在返回 Tool 的 Params 的时候，也需要我们将对应的 Tool 的 Response 一并回传给模型，整个会话的轮次也开始越变越长。
而模型的上下文和注意力机制决定了，模型的注意力预算有限；在这种持续的、长轮次的沟通方式累计下，整个上下文会快速累积（tool 的调用结果、system prompt、历史存储的状态、检索的内容都会进入到整个 Messages 序列里）。我们需要做出一些方式的优化，来确保在每次推理时，从不断增长的信息里，挑出最小但信号最强的那一组 token。
而随着 Agent 的概念开始出现，我们开始对 Agent 本身的能力开始做不同的上下文裁剪的方案，来确保 LLM 能够拿到最重要的信息。直到 2025 年中，Context Engineering 的概念被Karpathy、Tobi Lütke 等人提出，随后 Anthropic 发布 《Effective context engineering for AI agents》，我们开始正式用 Context Engineering 的理念来管理我们的 Agent 行为。
随着 Context Engineering 的实践逐渐成熟，我们开始能够更有效地管理有限的上下文预算，使 Agent 在复杂任务中保持更好的信息相关性和行为一致性（但这并没有彻底解决长程任务中的可靠性问题）。随之而来的是，我们迎来了 Agent 的时代；Claude Code 的横空出世，Claude 3.5 Sonnet 、Claude 4.0 Sonnet、Claude 4.0 Opus 等模型的推出，我们开始发现 Agent 可以很好的完成工作；
我们开始大量的使用这些 Coding Agent 来完成工作；但我们也不只满足于让 Agent 能完成工作，我们开始思考让 Agent 尝试更加长久的工作，完成长程任务。ReAct 等框架帮助我们初步探索了 Agent 长程任务的可能，但整体来说执行还是非常的不稳定的，依然需要人类介入其中，承担一些中间的粘合、持续推进的动力。
但很显然，我们不希望人类担任这个无价值的 Connector，与此同时，Anthropic 在长程 Agent 实践中展示了一种 Harness 设计方案《Effective harnesses for long-running agents》。不过这一版的 Harness 的定义和我们如今看到的 Harness 定义还是有很多变化的，它还定义了特定的 Feature List。如今我们用的 Claude Code 则是用了 Dynamic workflows 来完成了相同但更强的功能。
2026 年 2 月 5 日，HashiCorp 的 Co-Founder Mitchell Hashimoto 写下了 《My AI Adoption Journey》,在个人实践中明确使用并阐述这一概念，并定义了两种可能的形式：改进 AGENTS.md 和 改进编程工具。
I’m making an earnest effort whenever I see an agent do a Bad Thing to prevent it from ever doing that bad thing again. Or, conversely, I’m making an earnest effort for agents to be able to verify they’re doing a Good Thing.
Mitchell Hashimoto
紧随其后，OpenAI 在 2 月 11 日发布了他们自己的 《Harness engineering: leveraging Codex in an agent-first world》的文章，在这篇文章里， OpenAI 没有定义 Harness Engineering 是什么，但给出了不少他们做的修改的范式，并给出了他们认为重要的部分: 识别缺失的部分，并让 Agent 编写相关的部分。
Humans always remain in the loop, but work at a different layer of abstraction than we used to. We prioritize work, translate user feedback into acceptance criteria, and validate outcomes. When the agent struggles, we treat it as a signal: identify what is missing—tools, guardrails, documentation—and feed it back into the repository, always by having Codex itself write the fix.
Ryan Lopopolo, Member of the Technical Staff of OpenAI
至此，Harness Engineering 的画像变得清晰：不是改进模型本身，而是改进围绕模型的一切环境、产物和工具，通过这些环境和产物以及工具，来让模型正确的工作。
我们可以简单的将 Agent 的拆解为 Model + Harness，所有不在 Model 的部分，都在 Harness。当然，这不是严格的系统架构定义，而是一种工程视角上的简化：在模型权重不变的前提下，我们能够主动设计和优化的执行机制、上下文管理、工具调用、状态管理与验证反馈，可以统称为 Harness 的一部分。但这句话的关键不在于拆解方式，而在于解决问题的思路 —— 将目光从改进模型切换为改进 Harness。
这就好像我们试图让一个人去计算一个很难的题目，由于替换人的难度很大，成本很高，所以我们选择将目光转移到人可以用的工具上。我们可以用算盘去计算一个复杂的题目，但如果我同样还可以使用一个强大的计算器，那自然使用计算器可以更快的到达目的地。而好的工具（Harness），也给了我们让一个更差的模型获得更好的质量的可能。好的模型可以向下兼容算盘，但给它计算器，它才能把精力省下来做更难的部分。
当然，更强的模型往往能够驾驭更复杂的工具，完成更加困难的任务。但 Harness Engineering 的意义，不只是进一步提高模型的能力表现，而是降低任务成功对模型单次推理和执行正确性的依赖。
通过外部工具、状态管理、验证反馈与错误恢复，我们可以把原本需要模型独立完成的部分工作交给工程系统，让同一个模型更加稳定地完成任务。
Harness Engineering 的目标，是将模型具有不确定性的推理与执行能力，转化为可验证、可恢复、可持续的任务交付能力，提高任务的端到端成功率。
举个例子，假设我们希望一个 Coding Agent 完成一次代码重构。它不仅需要修改代码，还需要确保修改没有破坏现有功能。
这并没有改变模型本身的能力，却改变了整个系统完成任务的可靠性，帮助整个系统更加准确的交付结果。
很显然，Harness 存在的目标是帮助模型获得更好的结果。各个模型公司在训练环境的差异，会使得模型公司倾向于通过优化 Harness 来帮助自己获得更好的结果和智能。这也是为什么你会关注到，很多模型的 Benchmark 必须说清楚用的是什么 Harness 得到了这个分数，因为 Harness 就是会影响最终模型的结果。
而不同的模型公司在设计哲学上的变化最终演变出来了不同的 Harness，也让我们看到了不同的分类 —— Claude Code、Codex 、Pi、Deepseek Harness 。每个 Harness 背后都是对应模型公司或应用公司对于 Agent 的重新理解和定义。而对于这件事的理解，让我对于 Harness 的生态位既感到乐观，也感到悲观。
毫无疑问，我们可以将 Harness 区分为 Base Harness 和 Domain Harness / Business Harness：Base Harness 代表模型公司基于 Agent 能力抽象出来的最小集合；而 Domain Harness 是将特定领域的知识、工具、业务流程和验收标准封装成 Agent 可执行、可验证的工程系统。
我对 Base Harness 的生态位悲观，因为对于模型公司来说，他们会优先适配自己的 Base Harness，来帮助自己以最低成本获得最好的效果，同时，也会分配一部分精力去适配社区使用比较多的 Harness。但另一方面，这种和模型的深度绑定，让 开源的 Base Harness 会在持续发展的阶段中，逐步被抛下（除非你能成为 The One）。这让我们在选择 Base Harness 时要谨慎。
目前来看， Pi 可能会好一点，因为足够简单，和本身设计理念的简单，会让他大概率就算靠模型泛化，不做特定的优化，也能获得不错的结果。其他缺少独特系统能力、只追求复制官方 Agent 产品体验的通用 Harness，长期竞争空间可能被压缩；而和模型厂商绑定的 Harness，则会逐步在自己的 Harness 上拥有最佳表现，顶多再适配一下 Codex / Claude Code。如果一个第三方的 Harness 不够薄、不够可替换，就容易被模型厂商的官方 harness 挤压，最终失去自己的价值（回想我们之前看到的复杂的 Garry Tan 的 Gstack，你还用么？）
同时，我也对 Domain Harness 更加乐观，因为领域知识实在是太深太杂，以至于对于模型公司来说，这些东西可能也会吃下巨大的人力成本。与其花时间去做 Domain Harness，倒不如直接提供更好的开放度（比如 Pi / Deepseek Harness），来帮助领域专家构建 Domain Harness（从这个视角来看，我能理解 Deepseek Harness 的设计理念为何如此激进）。不过这些机会可能并不属于我（虽然我是 EE 背景的人， 但我的领域 Know How 约等于没有，自己的技能都点在互联网 & CS 相关了）。
当你理解 Harness 的存在价值和设计理念后，接下来就可以动手设计你的 Domain Harness 了，
过去，我们花费大量的精力研究如何写出更好的 Prompt，让模型尽可能一次性给出正确的答案。
后来，我们开始研究 Context Engineering，让模型在合适的时间看到合适的信息。
而今天，我们开始研究 Harness Engineering，不再只关注模型在某一次推理中是否正确，而是关注整个系统能否持续、稳定、可验证地完成任务。
从这个角度来看，Harness Engineering 的价值，不是让模型永远不犯错，而是让系统有能力发现错误、修复错误，并从错误中持续改进。
Prompt Engineering 优化的是表达，Context Engineering 优化的是信息，而 Harness Engineering 优化的是完成任务的整个过程。
当模型能力不断提高，我们真正需要积累的，可能不再是某个版本的 Prompt，也不是某个 Agent Framework 的使用技巧，而是那些能够被验证、执行和持续改进的工程经验与业务判断。
模型会不断迭代，Harness 也会不断演进。但如何定义正确、如何验证结果、如何把经验沉淀为可以复用的系统，依然是值得长期投入的事情。
我们正在从教模型如何做事，转向设计一个让模型能够把事情做对的系统。
2026-10-09 10:32:06
我把 Apple Watch 半退役了，身体记录的主力换成了 Fitbit Air。
Google Fitbit Air 是 Google 在收购了 Fitbit 之后，推出的一款无屏手环设备（对标 Whoop），其核心设计理念是在设备上彻底移除数据查看的能力，专注在数据追踪和全天候检测上。
得益于这样的设计思路，Fitbit Air 可以减少手环的最大热源和耗电源 ——屏幕；同时，还可以把整个设备做得更加轻薄，省电，官方标称最长 7 天，我实际大概 8 天。如果你对于 Apple Watch 的每日一充实在顶不住了，那么 Fitbit Air 就是你的最优选。
既然目标是用来做全天候健康检测，Fitbit Air 也集成了不少的传感器，可以满足你的日常需求，具体包含：
对于日常基础监控已足够，大部分时候我们使用 Apple Watch 所监控的基础健康指标也大概是这些了。
详细的技术 Spec 可以查看 https://store.google.com/product/google_fitbit_air_specs?hl=en-US
而且其售价也不算特别贵，相比于小米手环要贵一些（原价 99 美元；亚马逊买大概是 700 元人民币不到），但作为一个含智能属性的装饰品而言，我觉得还是可以接受的。
促使我购入 Google Fitbit Air 的核心原因，是我对于让 AI Agent 参与到我的个人健康数据分析，指引我进一步优化自己的身体健康状态有很强的诉求。
但目前我在用的产品不管是 Apple Watch 还是 Garmin，这方面做的都不够好，我没办法比较随意的将它们接入到 Claude / Grok 等不同的应用，这使得我非常不爽；我已经买了更好的模型，但受限于开放度，没办法把这些数据提供给 AI Agent 帮助我自己提升表现。而 Google Fitbit Air 在买之前，我就了解到它是基于 Google Health 的。而 Google Health 是给用户提供了开放的 Google Health API 的。
这就给了我更进一步分析自己的各种数据的可能性，不管是将其封装成 MCP 给到 AI Agent 使用，还是我把数据拉下来做其他分析，都有了机会。从这个视角来看，我还有个暴论： Google Fitbit Air 可能是迄今为止，最适合 AI User 的可穿戴智能设备。
如果你要购买，且有兴趣把 Fitbit Air 和你的 AI Agent 整合起来，我写了一个开源的程序，可以帮助你把 Google Health API 封装成 MCP 来使用：https://github.com/bestony/google-health-connector 。如果你对这些数据有隐私顾虑，可以直接自己部署一个；如果你懒得自己部署，也可以选择使用我部署好的线上服务：https://www.stillwarm.app/
得益于无屏幕的设计，使得 Fitbit Air 更加接近于一个装饰品，你几乎可以把它当成下面这样的硅胶手环来戴（当然，你戴的表带不同决定了实际的体感），如果你能够接受这样的硅胶手环，那么你大概率能接受 Google Fitbit Air。毕竟，Fitbit Air 主机 5.2 克，连上表带也只有 12 克，真的没什么感觉。
为什么这个无屏幕如此重要？因为无屏幕为用户提供了一种可能性：用极低的侵入感，提供装饰作用，从而让你可以一直戴着它。不管是我们更熟悉的小米手环，还是各种智能手表，你不可避免会遇到的问题是 —— 你的手腕上总是有一截「黑色」，即使是小米手环这样很细的，依然是有一截黑色。如果你还没感觉的话，下面这张图，可能会让你更有对比感；它们从左到右分别是 Fitbit Air、小米手环 7 、Apple Watch S12；
而也因为这种装饰品的属性，让我开始尝试一些更大胆的风格 ——我买了非常多不同的表带，可以根据场景、喜好、穿搭替换不同颜色的表带，来搭配自己的穿衣风格；
你可以在淘宝上找到各式各样、不同风格和颜色的表带，根据自己的喜好，把它搭配成你自己的风格。而得益于 Google Fitbit Air 以饰品的形态完成了身体指标的追踪，我开始买一些其他的腕表来配合着戴。
Google Fitbit Air 使用的是 Google Health App，需要单独下载，整个 App 设计的很简约，功能不多，从打开体验上来看，可能比 Apple Health 还好一点点。
在打开的那一刻，你可以快速看到一些你的基础信息，并可以根据这些基础信息来微调自己的规划。在这个界面中，最核心的是左上角的心肺负荷；Google Health 的基础假设是预期你能不断提升自己的心肺负荷，提升心肺能力；所以随着你使用的越久，它就会给你更加完整的心肺负荷的数据，同时帮你动态调整每周的目标。跟着这个目标，你会慢慢提升自己的心肺能力。
你如果是新买的 Fitbit Air，Google 官方还会给你送免费 3 个月的 Google Health Premium 会员（新用户和回归用户都算，活动截止到 2027-05-26。试用结束后自动按 $9.99/月续费），从而可以在 Google Health 中直接使用 AI 助手。而如果你已经购买了 Google 的 AI Pro 以上的会员，那你的 AI Pro 就包含了 Google Health 的 Premium 会员，可以畅快用 AI Agent 了；
除了基础的数据指标和 AI 助手，Google Health App 里还有类似 Keep 的运动库，你可以直接跟着练习；不过我有自己的训练计划，这部分用的很少；
在整个健康检测过程中，睡眠是一个很重要的指标，因此，Google Health 也给睡眠提供了一个单独的 Tab 方便你查看睡眠情况的分析。
以及独立的健康状态页面，记录你的身体的各项指标；你可以在这里去查看你的各项指标的趋势；
上面说了很多适合的，接下来还要说一些不适合的人群
我觉得今天的 Google Fitbit Air，是以一个饰品的姿态，做了一台合格的健康追踪器。它轻、续航长、戴着没负担，最关键的是数据开放，可以直接交给 AI Agent 去分析。
如果你和我一样，想让 AI 参与管理自己的身体，又受够了每天充电，它值得一试。
2026-10-05 22:50:30
作为一个工作狂，我的时间大部分被计算机所占据，但难免有休息的时候。近来，我和太太选择了以棋娱乐，消磨时间。
而当我们开始下棋后，我突然意识到并理解为什么过去老人们总是喜欢下棋了。
第一便是下棋对于人数的要求很低，只需要两个人就可以开始，非常符合如今的家庭结构，大多数只有两个人；
第二便是下棋本身也是一种动脑筋的游戏和活动，相比于刷抖音视频，显然下棋是一个更好的选择，能够动动脑筋，思考一下如何破局；同时，也不至于像编程一般烧脑。
第三便是和玩游戏相比，下棋是与人的博弈，人带来的变化让游戏本身乐趣无穷；同时，还可以在游戏的过程中，增进感情。
我们从一开始下五子棋、跳棋，慢慢拓展到了直接把常见的棋种都买了一份：五子棋、围棋、象棋、国际象棋、跳棋、军棋。不过，象棋还在学习过程中（我虽然看过很多老人下，但并不会下，还是需要开始学习。）
如果你和你的家人在家里无聊，那么不妨也买副棋回来，玩一玩。
（我也是认真开始玩才发现，五子棋竟然还有禁手一说。。。）
2026-10-04 20:55:21
在上一篇《开源，可能是新手软件工程师的唯一的路了，所以我做了 GoodFirstIssue.org》中，我介绍了 GoodFirstIssue.org ，今天我希望重点介绍一下其中的一个我个人很喜欢的项目 —— Near By Guru。 Near By Guru 可以帮助你找到你所在城市的开源开发者，你可以借此功能找到他们，并与他们取得联系，请他们帮助你，加入到开源社区当中。
对于新手来说，做贡献很难。开源和企业内部一个很不一样的点是，开源社区当中，没有人有义务为你提供帮助。大家会秉承着最大善意去帮你参与到社区的贡献当中；但并不意味着大家能像企业同事那样，做到当天甚至即时给你反馈；对于新手来说，这种等待反馈和确认无疑是煎熬的；而对于开源老炮们来说，这不过是他们参与到开源社区的一个又一个日常。
开源社区很好玩，但这些隐形规则的和企业内的不一样，容易让新手一开始就失去信心，使一个人放弃参与开源社区。这个时候，如果身边能够有一个已经在开源社区中浸润已久的人参与其中，给予心理支持，对于新手来说，可能就足以继续坚持下去。
当然，还不止于此，你身边的这些优秀的开源开发者们，他们可能已经成为很多企业的中流砥柱，你可以和他们取得联系，了解业界的最新进展，避免闭门造车，同时也可以对于业界有更多的了解。
在设计 Near By Guru 的时候，我核心设计了三个功能：
通过这样的方式，方便大家可以快速的找到自己城市的开源开发者们。同时，考虑到像湾区这种跨了好几个城市的地方或者是国内的京津冀、长三角、珠三角地区的情况，我还加了一个 60KM 的约束，一个城市地图上，除了加载本城市的开发者，还可以加载到自己所在城市周边 60KM 内的开发者，方便大家使用。
你可以直接打开 Near By Guru 的功能页面，浏览器会自动向你索要授权，并加载你的所在地，然后你就可以在地图上看到你所在地的开源开发者们。
需要注意的是，因为我们的精度是城市级别，所以固定大家是围绕着城市中心呈圆环状排列的。并不代表每一位开发者的真实位置。
你可以点击他的头像，或在地图或下方列表中查看他的详细信息（比如他的简介、Star 最多的项目）。我们在网站上并不直接提供联系方式，如果你需要和他取得联系，可以点击「前往 Github 联系 Ta」，通过他公开的联系方式，来和他取得联系。
此外，如果你所在城市没有人，但是你所在的省会有，你也可以向下滑动，找到你所在的国家和地区，按照城市级别去查找对应的人。
由于使用的是 Github 的 Location 字段，所以存在多种问题：
以及，如果你受益于这个功能，通过这个功能找到了志同道合的朋友，并加入到开源社区里，希望你也能以对应的善意，在 Github 上写清楚你的 Location，方便帮助更多的新人加入开源社区。
如果可以，我希望看到这篇文章的你，不管是开源新手，还是开源老炮，我们都能抱着善意，帮助我们身边的开发者。
