优化 GitHub 个人或组织主页：把访客落地的页面重建为可…

当有人要优化 GitHub 主页、profile README、置顶仓库或组织主页，或准备发布、演讲、求职时，用审计加重建的方法让页面不再自相矛盾并主动引导访客。

适用场景

解决思路

1. 先校准承诺：说明主页是验证面而非发现面，所有阈值都是本技能自设的默认值而非行业标准，不承诺面试、star 或注册量，并说明现有证据以英语和美国为中心。
2. 把不属于主页范围的需求转给兄弟技能：单个仓库 README、发布公告、渠道分发、首次贡献引导、赞助分层、职业定位分别路由到对应技能。
3. 对『刷 star』『填满贡献图』『让主页排名』这类要求直接说明其性质、在评审者眼中的代价，并改提供审计。
4. 按顺序逐个提问，能自行从审计结果判断的就跳过；问题 1-4 未回答前不要起草文案：账号与类型、角色（维护者/公司/求职工程师）、页面要产生的唯一结果、主要访客来源。
5. 继续提问：个人采用还是公司采用、读者下一步要能做什么、当前真实活跃度、不愿被改动的部分、组织需说明开源与商业边界、页面归属人、下次复审触发事件、截止日期、一次性清理还是长期机制、时间与审批上限。
6. 根据问题 11-13 重新排序修复项：有硬截止就提升近零成本修复并砍掉整页重建；要长期复利就提升定位句和复审习惯；没有常驻负责人就删除复审习惯而非列为待办。
7. 若问题 2 落在求职场景，先检查目标公司：大公司应优先投入简历，主页只用于避免与简历矛盾。
8. 第 1 步收集事实：在 GitHub 上运行 scripts/profile-audit.py <account>（设置 GITHUB_TOKEN 以包含置顶项并提高速率限制），其他平台按同一清单手工核对。
9. 无法运行脚本时自己打开主页或让用户粘贴 README 与置顶列表，并明确说明哪些事实未能核实。
10. 打开页面上每个链接，记录死链。
11. 以陌生人视角阅读置顶仓库：是否各有描述、topics 和近期推送。
12. 若环境有持久记忆，加载该账号已存的定位句、受众定义和竞品列表复用。
13. 第 2 步按 references/profile-scorecard.md 逐项打分，严格按其报告格式输出：4 项阻断检查、8 项各 2 分的计分检查，再给修复顺序。
14. 每一条都附证据（引用句、字段值、脚本输出行），先呈现分数并取得所有者同意再改写；外部看不见的约束可以解释某项零分。
15. 呈现分数时说明检查项和及格线是本技能自设基线而非公开标准。
16. 按效率排序修复项并说明三种排序的差异：false claims == render prerequisites > pins > positioning sentence > private-contribution toggle > page rebuild > review habit。
17. 默认先做前三项（约一个下午）；当所有者已能说清账号用途时推进定位句；仅当冷读测试在更高层级未覆盖的问题上失败时才做整页重建。
18. 在以下情况把复审习惯提升到最前：回答 7 是『每周发布』或账号属于组织；这是同一账号的第二次审计。
19. 根据执行者重新排序：已有定位句的所有者先做该层；置顶已明确则跳过该行；被回答 13 上限排除的修复项直接删除并记录原因。
20. 第 3 步先修『错误』再改『薄弱』：删除或更新可被证伪的声明（已归档的『正在构建』、前雇主、死链、过期职位）。
21. 修复破坏渲染的问题，参照 references/platform-mechanics.md 中让 profile README 显示的四个前提及组织对应项。
22. 把无日期的时效性表述改为带日期或删除。
23. 第 4 步写定位句前先头脑风暴：沿不同轴线（机械地构建什么、为读者消除什么问题、读者可以不再做什么）起草三个候选句，给出各自取舍与推荐，让所有者选择。
24. 用一句话检验每个候选：竞品账号能否原样粘贴？能则说明它什么都没说。
25. 第 5 步按 references/profile-skeletons.md 选择匹配读者决策的骨架（维护者、DevRel、建立可信度的工程师、组织），逐节起草并逐节确认。
26. 按采用方式调整：个人采用强调能否构建、作品可运行、有入口；团队采用强调许可、维护节奏、支持与安全路径、具名用户、资金模式、团队可见性；首屏两者相同，靠下方评估区块兼顾。
27. 所有骨架通用规则：每个图片、徽章、组件上方先放一句文字；装饰不超过三个视觉元素，各有 alt 文本且各有用处；写明『不成立』的事（不维护什么、什么是商业的、不接受哪些功能请求）；置顶前先给仓库写描述和 topics；在剥离 HTML 渲染处仍可读，不靠颜色或图片内文字传达含义。
28. 把成稿文案过一遍常用的人性化处理，避免读起来像生成的。
29. 第 6 步按目标而非 star 数选择六个置顶（组织为六个公开加六个成员可见），四套方案不互相排名，由回答 3 直接选定，但每套内部顺序有意义：采用型（旗舰第一、新用户所需 SDK 或集成第二）、贡献者型（有 curated good-first-issues 的在前、贡献文档最好的其次）、可信度或求职型（体现判断力的作品，即使 star 低）、组织型（入口导览而非排行榜，覆盖 README 未提及的仓库）。
30. 绝不置顶已归档仓库、未实质修改的 fork 或空占位；也不要留空，否则平台自动选『Popular repositories』，常显示已废弃项目。
31. 第 7 步先读 references/platform-mechanics.md 再评论贡献图和成就，按效率排序：private-contribution toggle > mechanical graph causes > merged pull requests elsewhere。
32. 对受雇开发者贡献图显得死寂时，先打开私有贡献开关——这是设置问题而非需要新的公开工作。
33. 其次修复导致图虚假空白的机械原因：未关联的提交邮箱、只落在功能分支的工作、fork 中未合并上游的贡献；一小时诊断后形成习惯。
34. 当回答 3 是可信度、求职或合作邀请时，把『在他人仓库中已合并的 PR』提升到第一位——这是全技能中证据最强的信号，且可核查。
35. 绝不建议刷提交、刷 streak、买 star 或刷成就：回填提交只需一个环境变量，公开工具可在图上作画，star 造假已成产业（五年半研究统计约六百万疑似假 star，涉及一万八千多个仓库）。
36. 当所有者提出这类要求时点名拒绝：说明手法是什么、评审者会打折、以及你会改做什么；这些选项应被删除而非排在最后。
37. 把 streak 和奖杯组件视为可信度交易而非中性装饰：对资深技术评审者是噪音，且看不到私有工作。
38. 第 8 步复审：重跑计分卡，四项阻断检查全过且计分达到 13/16 才发布，低于则继续迭代。
39. 运行冷读测试：45 秒浏览后回答四个问题（组织五个），全对才算通过；可用无上下文的新 agent 会话代替真人，但不能用自己阅读代替。
40. 记录负责人和触发下次复审的事件（发布、演讲、融资、大版本、角色变动、求职）；不设固定日历周期，把触发列表和上次复审日期写进文件注释。
41. 若有持久记忆，存下商定的定位句、受众、目标和最终分数，供发布帖、会议简介和文档落地页复用。
42. 后续追踪按效率排序：tagged click-through > pinned-repository traffic > qualified inbound。
43. 先建 tagged click-through：从主页到自有目的地（文档、产品、社区）的带标签链接，一小时搭建，数据归所有者，是唯一经得起审视的数字。
44. 其次看置顶仓库流量：免费但单独几乎无用，仅限最近 14 天且限于可推送的仓库。
45. 最后看 qualified inbound：需要常驻习惯和一个季度才说话；组织场景下这是页面改变行为的唯一证据，应提升并自发布日起计数。
46. 从计划中删除两个数字而非排在最后：README 浏览计数徽章（经匿名代理、含机器人和重复加载、可被公开脚本灌水）和主页改动后的 star 增长（不可归因，公司层面被主动刷）。
47. 避免常见失败模式：先装饰后诊断、对所有受众用同一清单、过度承诺、按 star 排序置顶、依赖第三方组件、把组织主页写成第二个营销站、把贡献图当记分牌、页面无人负责、整份照抄模板。

适用边界 · 注意事项

• 用户真正的问题是单个仓库的 README、发布公告、渠道分发、首次贡献引导、赞助分层或职业定位——应转给对应兄弟技能，而不是硬塞进主页。
• 用户要求刷 star、填满贡献图或让主页排名——这些是制造证据或平台不具备的能力，应说明并改做审计。
• 目标公司是大型雇主时，应优先投入简历，主页只用于避免与简历矛盾。