github-profile-optimization

GitHub 个人资料优化

你正在处理这样一个页面：开发者在听完演讲、看到软件包列表、搜索结果或招聘信息后会访问它；评估者也会打开这个页面，判断项目背后的人是否真实可信。你的任务是依据证据诊断这个页面，然后围绕所有者明确说出的一个目标重新打造它。

两项限制决定了所有工作：

• 个人资料 README 和六个置顶项目是账号唯一可编辑的内容；页面上的其他内容（星标、语言、贡献图）都是自动生成的，无法人为调整。
• 自动生成的内容在两个方向上都属于薄弱证据：复刻、非默认分支和未关联的提交邮箱都不会显示在贡献图上，因此重度贡献者可能看起来毫无活动，而贡献微不足道的人却可能显得十分活跃。

校准你的承诺

这类建议大多来自有工具或课程要卖的人，而独立证据远没有他们说的那么充分。在引用数据或预测结果前，请先阅读 ./references/published-findings.md。其中明确了以下几点：

• 个人资料是一个验证页面，而非发现页面。打开它的评审者已经产生了兴趣，他们会核实其他地方的说法是否属实。证据最充分的信号来自早于个人资料 README 出现的访谈研究：真实的活动历史，以及参与他人已经在使用的项目；资料内容稀疏与否，都无法向评审者说明什么。
• 这里的每个门槛都是自行设定的。 个人资料优化没有公开的评分标准、发布频率或基准，因此下方的及格标准只是工作默认值，证据文件中也明确标注了这一点。请把它们作为所有者可以调整的默认值，而非行业标准。
• 同样不存在经过验证的框架——目前流传的那个自创缩写，除其原始文章外无人采用。不要重复使用它，也不要另创替代方案；下方的受众问题和评分卡已经完成了框架本应承担的工作。

承诺这项工作确实能带来的结果：让页面不再与所有者的其他材料相互矛盾，并有意引导访客。不要承诺能带来面试、星标或注册——没有研究衡量过重写个人资料是否会产生这些结果。还要说明适用范围：这里引用的已发表证据以英语内容和美国情况为主；如果所有者的招聘或市场环境在其他地方，请明确指出。

请聚焦个人资料页面本身。如果用户的实际问题属于以下情况，请引导他们转向相关技能，而不是让个人资料承担超出范围的任务：

• 单个仓库的 README：samber/developer-relations-skills@readme-optimization
• 发布公告：samber/developer-relations-skills@oss-launch
• 持续维护渠道影响力：samber/developer-relations-skills@oss-distribution-strategy
• 首次贡献流程：samber/developer-relations-skills@oss-contributor-onboarding
• 赞助等级和筹款目标：samber/developer-relations-skills@oss-sponsors-fundraising
• 职业定位、面试和职业发展：samber/developer-relations-skills@devrel-career

常见请求：“审查我的 GitHub 个人资料”“重写我们组织的个人资料 README”“应该置顶哪六个仓库”“我们每周都在发布，但 GitHub 看起来像没人维护”“让我的个人资料更适合会议组织者阅读”。

有些请求应该引导用户转向别处，而不是直接重写。“帮我获得更多星标”和“填满我的贡献图”都是要求伪造证据；“让我的个人资料排名更高”则是在要求使用平台并不提供的手段。说明这属于哪种情况，解释这样做会如何损害他们在重要评审者眼中的可信度，并提出进行审查——即便请求本身不妥，其背后的目标通常仍然正当。

访谈

每次只问一个问题；能提供选项时就提供选项，并跳过你能从审计结果自行判断的问题。问题 1-4 决定是否改写：回答之前不要起草文案。

记忆：保存少量与当前任务或项目背景有关的信息。记忆存储在文件中时，使用 devrel-context.md；如果使用的是其他记忆系统，则沿用该系统。将不同任务的信息分开存放在不同章节中。任务完成后将其删除。为任务添加日期；通用项目背景不添加日期。不同任务的部分访谈回答可能有所不同。

1. 是哪个账号？它是个人资料还是组织资料？
2. 你是负责维护项目并吸引贡献者的人、致力于提升开发者认知度的公司，还是其个人资料会受到招聘审查的工程师？后续所有步骤都取决于这个答案。
3. 你希望这个页面主要促成哪一种结果：更多项目采用、更多贡献者、更多公司主动联系、更多演讲和合作邀请、更多求职或客户线索，还是更多赞助？
4. 哪类访客最多：从代码仓库或软件包页面跳转而来的开发者、从演讲或文章跳转而来的开发者、招聘经理和招聘人员，还是想了解某个工具背后团队的公司评估人员？
5. 面向个人采用还是公司采用？独立做决定的开发者会关注能力；团队会关注维护情况、许可，以及出现问题时该联系谁。两者兼顾也是合理答案。
6. 读者接下来必须能够做什么——打开某个特定代码仓库、阅读文档、加入社区、预约通话，还是联系你？
7. 关于当前活跃度，哪种说法符合事实：每周发布、持续维护、项目间歇期，还是已停止维护？
8. 页面上有没有你很在意、不希望改动的内容？
9. 如果是组织：哪些内容是开源的，哪些是商业内容？你是否希望明确说明？
10. 今天之后由谁负责这个页面？发生什么情况时会触发下次审核？
11. 这个页面必须在某个日期前准确无误吗——例如发布、演讲、融资或面试流程的日期——还是只是早该更新了？
12. 你需要在该日期之前一次性整理页面，还是希望它长期发挥作用：制定一句定位语，并养成可沿用多年的审核习惯？
13. 你的投入上限是什么——一个下午、一周的工时、固定负责人，还是对外表述需要法务或市场部门批准？

问题 10 并非行政事项。无人负责的个人资料会一直保留撰写时曾经属实的说法；过时的说法比空白页面更损害信任。

问题 11-13 的答案会调整步骤 2 中的修复优先级；呈现建议时，请说明哪个答案改变了哪项修复的优先级：

• 有明确期限时，将几乎零成本的修复提到优先位置，并将完整重建页面从本轮工作中移除。
• 如果目标是长期积累成效，则优先制定定位语，它会延伸到简介、组织标语和每个链接预览中；同时提高审核习惯的优先级，否则按投入产出比来看，它往往永远排不上。
• 如果投入上限内没有固定负责人，就彻底取消这项习惯，而不是把它记作未来工作。

如果问题 2 的答案指向求职场景，在建议投入大量工作之前，先确认目标岗位。这个领域里唯一公开了方法论的调查发布于 2018 年，因此应视为过时；该调查发现，作品集主要受到小型公司和创始人主导的公司的重视，而已有的招聘人员证言大多对这种表面展示并不在意。

目标是大型雇主的候选人应优先打磨简历，并确保个人资料不与简历相矛盾即可。按阶段划分、针对不同受众的建议见 ./references/published-findings.md。

第 1 步——收集事实

绝不要凭对优质个人资料的印象来审查。

1. 如果个人资料位于 GitHub，且你可以执行命令并访问网络，请运行 scripts/profile-audit.py <account>——该脚本会调用 GitHub 自有的 REST 和 GraphQL API，无法用于 GitLab、Codeberg 或自托管代码托管平台。它会报告个人资料字段是否超出限制、个人资料 README 是否能正常显示及其位置、字数／链接／图片数量、第三方小组件、带时效性的措辞，以及未设置置顶项目时访客会看到的仓库。设置 GITHUB_TOKEN 可纳入置顶项目并提高速率限制。在其他平台上，请直接查看个人资料页面，并手动应用同一份检查清单。
2. 如果无法运行脚本，请自行打开个人资料页面（浏览查看，或请用户粘贴 README 并列出置顶项目）。如实说明哪些事实无法核实，不要擅自假定。
3. 打开页面上的每个链接，并记录失效的链接——失效链接会导致阻断项不通过，而且只需几分钟就能修复。
4. 像陌生访客那样查看置顶仓库：每个仓库是否都有描述、主题标签和近期推送记录？
5. 如果你的环境有持久化记忆，请加载该账号已保存的定位陈述、受众定义或竞争对手列表，并沿用这些内容，不要重新推导。

脚本报告的是事实，而非评判。图片有 15 张并不一定有问题；需要对此作出判断。

第 2 步——为页面评分

按照 ./references/profile-scorecard.md 的要求，逐字生成其报告格式：四项阻断检查、八项评分检查（每项 2 分），然后按下文给出修复顺序。

为每一行附上证据——引用的句子、字段值或脚本输出。展示评分，并在重写前征得所有者同意。你无法从外部看到的约束（例如雇主政策或有意为之的极简风格）可以作为某项得 0 分的理由，而所有者有时确实是对的。

展示评分时，只需说明一次：这些检查项和及格线是本技能自定的基准，并非已发布的标准。所有者有理有据地调整标准，并不代表审查失败；如果所有者只是因为不想改动页面而降低标准，则不然。

对修复项排序

按每小时投入能带来的回报对修复项排序，而不是按能挽回多少损失，也不是按完成速度排序——这三种排序并不一致，因此要分别列出，并以最后一种为先：

• 投入，最少优先：false claims == render prerequisites > private-contribution toggle > pins > positioning sentence > page rebuild > review habit
• 价值，最高优先：false claims > positioning sentence > pins > page rebuild > render prerequisites > review habit > private-contribution toggle
• 效率，先做：false claims == render prerequisites > pins > positioning sentence > private-contribution toggle > page rebuild > review habit

消除错误声明和修复渲染问题在两个维度上都并列，因此效率也并列。两者各需几分钟，且都属于阻断性问题；每项修复的都是一个_有误_而非仅仅薄弱的页面——读者根本无法评估这两类有问题的页面。私有贡献开关的排名低于其近乎为零的投入所暗示的水平，因为它只对那些公开活动图无法如实体现真实私有工作的特定账号有帮助；对其他人来说，它毫无影响。

默认先做前三项，三项加起来也就一个下午。等负责人已经能说清账号的用途后，再处理定位句；只有当冷读者测试在前三项未涉及的问题上失败时，才重建页面。

这种排序会把定期审查习惯挤到最后：这是一个持续性的工作，而其他修复只需几分钟，因此它每轮都落败。它却是唯一能阻止页面再次过时的事项，而这正是本技能认为代价最高的失败。

遇到以下情况时，将它提到所有事项之前：

• 第 7 题的答案是“每周发布”，或账号属于某个组织；这类页面过时得最快，也没人会注意到。
• 这是对同一账号进行的第二次审计。

这套排序是默认方案，不是铁律，而且会随执行者而变化。根据你已知的情况重新排序：

• 已经从发布会或演讲中提炼出定位句的负责人，几乎可以不费力地完成该项，应当先做。
• 置顶内容已经经过周密安排的账号，应当直接删除这一项，而不是重新考虑。

如果第 13 题的限制条件排除了某项修复，就直接删除它，不要把它列在最后——没有营销审批权限的组织，不应把“说明哪些内容具有商业性质”这句话放在计划末尾，而应删除这一项并记录原因。

第 3 步——先修正错误之处，再改进薄弱之处

这些是修复顺序中优先级最高的事项。它们能排在这里，是因为回报率高，而非尽管回报率高——每项只需几分钟，就能消除让页面确实出错、而非仅仅薄弱的内容。

1. 删除或更新所有读者可以证伪的声明：已归档项目却标着“正在开发”，前雇主，失效链接，已过时的职位。
2. 修复所有导致渲染失败的问题——参见 ./references/platform-mechanics.md，了解让个人资料 README 得以显示的四项前提条件，以及组织账号的对应条件。
3. 将过时的限时声明替换为带日期的内容，或直接删除。没有日期的“目前正在探索 X”，是在声明今天的情况，却没人会更新。

完成这些后，再处理定位和结构。

第 4 步——先构思定位，再动笔

不要拿起第一个说法就用。从不同角度起草三种候选定位句——你在具体做什么、为读者解决什么问题、读者因此可以不再做什么。列出每种说法的取舍，并给出你的建议。让负责人做选择。

这句话会延伸到个人简介、组织标语、链接预览和搜索结果中，因此值得多推敲一轮。用一个问题检验每个候选说法：竞争对手的账号能否原封不动地贴上这句话？如果可以，那它就没有表达任何信息。

步骤 5 - 重建页面

从 ./references/profile-skeletons.md 中选择一个符合读者决策类型的框架——维护者、DevRel 从业者、打造个人可信度的工程师，或组织。一次只起草一个部分，并在继续之前征求认可；一次性重写的个人资料页，也会被一次性否决。

根据采用方式进行调整，因为两种采用路径在首屏之后就会分道扬镳：

	个人开发者独立采用	团队或公司采用
核心问题	这个人能打造我需要的东西吗？	我们依赖什么？出了问题该找谁？
必须尽早呈现	实际作品、运行状态和入口	许可立场、维护节奏、支持和安全渠道
有说服力的证据	已合并的拉取请求、演示、易读的代码库	明确的用户、发布节奏、资金模式、团队透明度
致命遗漏	没有明显的首选代码库	没有回答“谁在维护这个？”

两种情况下的首屏都一样：这是一个什么样的人、他们打造什么、应该先查看哪个项目。可以在页面靠下的位置添加简短的评估内容来兼顾两类受众，不必把顶部内容重写两遍。

适用于所有框架的规则：

1. 每张图片、徽章和小组件上方都要放一句说明文字。
2. 装饰性元素最多三个，每个都要有替代文本，且都必须有存在的价值。第三方统计和连续贡献卡片属于外部依赖，托管平台的图片代理可能会无限期缓存过期内容；冻结的小组件还不如没有。
3. 说明哪些事情不属实：你不维护什么、哪些内容是商业性质的、哪些功能请求你不会受理。这是页面上最能建立信任的内容，只需一行。
4. 每个固定的代码库都要先添加描述和主题标签，再固定到个人资料页——空白固定项浪费六个名额之一。本指南只要求这些信息存在；关于如何写好它们，请参阅 samber/developer-relations-skills@readme-optimization 中的配套步骤。
5. 即使渲染后的 HTML 被剥除，页面也要保持可读：不要只靠颜色传达含义，也不要让任何说明只存在于图片中。

用你偏好的去 AI 化技能检查最终文案。读起来像 AI 生成的个人资料文案，会削弱页面原本要建立的可信度。

步骤 6 - 谨慎设置固定项

六个固定项（六个公开项，以及组织账号的六个成员可见项）是你唯一能用来影响访客下一步点击什么的手段。根据问题 3 的目标来选择，而不是看星标数量。

这四组方案互不排名，也不应互相排名：问题 3 的答案会直接选定其中一组，而设置任何固定项的成本都为零，因此对它们强行排列效率顺序，只是在制造虚假的精确性。每组内部的顺序则确实重要——它决定访客首先打开哪个代码库。

• 促进采用：先放旗舰项目，再放新用户需要的 SDK 或集成。
• 吸引贡献者：先放精心整理了适合新手的问题的代码库，再放贡献者文档最完善的代码库。
• 建立可信度或招聘：放最能展现判断力的作品，即使星标较少也没关系——经过充分评审的工具胜过热门链接列表。
• 组织：提供入口导览，而不是排行榜；涵盖 README 文案尚未提及的代码库，让这两个展示区域合起来提供更完整的信息。

切勿固定已归档的代码库、你没有实质性修改过的分叉项目，或空白占位项目。不设置固定项更糟：平台会自动选择“热门代码库”，其中往往会显示已被弃用的项目。

第 7 步——诚实处理贡献信号

在评论图表或成就之前，请阅读 ./references/platform-mechanics.md。

有三种诚实的做法，优先级相差一个数量级：

• 效率优先，先做：private-contribution toggle > mechanical graph causes > merged pull requests elsewhere

• 当在职开发者的图表看起来毫无动静时，首先启用私有贡献开关。只需更改一个设置，而且他们的大部分工作都是私有的——因此这里的“活跃度”取决于设置，而不是新的公开工作。

• 接下来修复导致图表看似空白的机械性原因：未关联的提交邮箱、只进入功能分支的工作、在从未合并到上游的分支中完成的贡献。花一小时排查，然后养成持续维护的习惯。

• 这个排序把其他人的代码库中已合并的拉取请求放在了次要位置：它们是真实工作的一部分，因此按比例来看永远排不到前面。不过，它们仍是整个技能中证据最充分的信号：访谈研究中的评审者认为，在其他人已在使用的项目上做出的工作，比页面上的其他任何内容都重要。当第 3 个答案涉及可信度、招聘或合作邀请时，应把它们提到首位——在这些情况下，没有更省力的替代方案，而且它们可以核实，图表却不能。

• 切勿建议刷提交、刷连续贡献记录、买星，或利用成就系统牟利。关注这一领域的评审者早已对这三种信号打了折扣：

  • 只需设置一个环境变量，就能把提交日期改到过去。
  • 公开工具可以在图表上绘制图案。
  • 星标欺诈已发展到工业化规模：一项为期五年半的公开事件数据研究统计出，超过一万八千个代码库中约有六百万个疑似虚假星标。

• 如果代码库所有者提出此类要求，要明确拒绝：指出这是什么策略、评审者会对其打折，以及你会改用什么办法。这些做法应从选项中删除，而不是排在最后——若只是在计划中把某种策略搁置到末尾，它之后就会作为工作范围再次出现，而这种做法带来的将是伪造的证据。

• 把连续贡献记录和奖杯组件视为对可信度的取舍，而不是中性的装饰：资深技术评审者会把它们看作噪声，而且完全看不到私有工作。

第 8 步——验证，然后持续维护

1. 重新运行评分表。只有四项阻断性检查全部通过，且评分总分达到 13/16 时才交付——这是本技能自身设定的基准，并非公开标准。低于此分数时应继续迭代，而不是附带保留意见就交付。
2. 按评分表进行冷读测试：给读者 45 秒浏览页面，然后提出四个问题（组织的情况为五个）。所有答案都正确才算通过——四题全对；组织的情况则是五题全对。如果没有人可用，没有上下文的全新 Agent 会话可以作为替代；但自己阅读不算。
3. 记录所有者，以及会触发下次审查的事件——发布、演讲、融资、重要版本发布、角色变更、求职。没有证据支持固定的日历周期；没人会遵守的季度提醒，还不如所有者认可的触发事件清单。如果没有其他合适的保存方式，就把清单和上次审查日期作为注释放入文件。
4. 如果你的环境支持持久记忆，就保存商定的定位句、受众、目标和最终分数，这样发布公告、会议简介和文档首页就能使用同一套措辞。

之后要追踪什么

• 效率，优先追踪：tagged click-through > pinned-repository traffic > qualified inbound

按上述顺序依次建立这三项：

• 带标签的点击率：从个人资料页指向所有者可控目标的带标签链接——文档、产品、社区。设置需要一小时，目标站点的分析数据归所有者所有，而且这是这里唯一经得起审视的数字。
• 置顶仓库流量：免费，但单独来看几乎没有用；仅限于过去 14 天的时间窗口，而且只能统计所有者有推送权限的仓库。
• 有效入站联系：这种排序最容易忽略的指标——需要长期坚持阅读，并且要过一个季度才有参考意义。对组织而言，这是唯一能证明页面改变了他人行为的证据，因此应优先提升它，并从发布之日起开始计数。

不同受众对有效入站联系的定义不同：对组织而言，是已经了解你们所构建内容、不会再询问这点的潜在客户；对从业者而言，是提及了个人资料页展示内容的演讲或合作邀约。

其他一切都只是片面的。没有任何托管平台提供个人资料级别的分析数据，而且这里没有任何指标能单独反映个人资料页的影响——记下发布日期，并为每个干扰因素添加注释。

与其把以下两项排在最后，不如直接从计划中删掉：

• README 浏览量计数徽章统计的是通过匿名代理发出的图片请求（包括机器人和重复加载），而且公开脚本会让计数虚高，所以它只是装饰，不是数据。
• 个人资料页改版后的 Star 增长无法归因，而且在公司层面还会被人刻意操纵。众所周知，Star 往往是推广活动（发布、演讲、其他地方的提及）带来的，而非页面本身带来的。

这里的其他所有数字也都应如此看待。

常见失误

• 未诊断就先装饰。 如果页面的首要说法不实，添加小部件只会让错误说法更好看。先评估。
• 对所有受众套用同一份清单。 连续贡献小部件会向职场新人群体传达参与度，但对所有者真正需要触达的维护者或招聘经理来说，这只是噪音。推荐任何单一元素前，先回答问题 2。
• 夸大页面的作用。 没人测量过改版是否会带来面试或贡献者；承诺这两者中的任何一个都是凭空编造效果，而如果承诺始终没有兑现，所有者会察觉。承诺清晰和一致——这正是页面确实能做到的。
• 按 Star 数量排序置顶项。 平台已经显示 Star 数量。按热度排序置顶项，等于浪费唯一的编辑手段去重复访客能直接看到的信息。
• 依赖小部件。 每张第三方卡片都依赖一个可能宕机、触发速率限制，或在图片代理中卡住的服务。最多保留一个，并检查未登录状态下是否能正常显示。
• 把组织资料页写成第二个营销网站。 访客来 GitHub 是为了看代码。页面的工作是说明应该先打开哪个仓库，以及哪些内容是开源的——网站已经负责其余部分。
• 把贡献图当作排行榜。 建议任何人填满贡献图，就是在建议他们伪造证据；而了解计数规则的读者反正也不会把这张图当回事。
• 让页面无人负责。 无人负责的个人资料页会逐渐变得不实：写下时还正确的说法，会在过时后继续留在那里。改版时就同时指定负责人和审核触发条件。
• 照搬整套模板。 读起来和其他一万个个人资料页一样的页面，读者会直接跳过。框架可以决定顺序，但具体文字必须来自本人。

参考资料

• ./references/published-findings.md - 哪些数据已发布、哪些为自行设定、针对不同受众的分阶段指导，以及应拒绝的说法
• ./references/profile-scorecard.md - 阻断性检查与评分项、阈值、冷读测试和报告格式
• ./references/profile-skeletons.md - 针对不同受众的章节顺序、正反示例，以及已发布组织档案中观察到的模式
• ./references/platform-mechanics.md - README 的前置要求、字段和置顶数量限制、贡献图计数规则、成就及图片代理行为
• samber/developer-platform-skills@github-engagement-playbook - 一个置顶仓库自有的 GitHub 页面：Discussions、发布通知、主题、星标政策