“写笔记”支持四种格式——Word 文档、Excel 表格、Markdown、纯文本，起稿或二次编辑时都能随时切换，同一篇笔记想用哪种形态来记，都由你说了算。
md、txt、csv、json 这类纯文本则原样载入，不做多余加工。拿一张现成的表倒进来、改几笔、再导出去，等于白用一台免费的格式转换器。
要带走就在右上角点“下载”，可导出 PDF、Word、Markdown、Excel、TXT 等格式；列表卡片“⋯”菜单里，也有同样的下载入口。
在“工具”页点“＋ 上传工具”即可发布：填好名称与链接，再用 Markdown 把使用方法写清楚——能解决什么问题、怎么装、怎么用，比堆介绍实在。
要分发安装包就一并上传压缩包（ZIP、RAR、7Z、TAR.GZ，最大 35MB），别人在详情页一键下载；只放链接不带附件也可以。
工具按大家的收藏热度排序，好用的自然会被顶上来。发布后可在详情页或卡片菜单里编辑、下架。
写笔记时勾上“隐藏”，这篇就只存在于你自己的账号里：不进列表、不进搜索、不上首页精选，也不会出现在任何公开的页面，链接发给别人同样打不开。
适合放密码、草稿、日记这类只给自己看的内容；想公开，去“发布”打开它，把“隐藏”的勾去掉再保存，之后编辑会默认保持原状态，不会悄悄变回公开。
你的内容会同时保存在多个副本上，系统定期做备份与完整性校验，再配合异地容灾机制：就算某台机器出问题，数据也不会丢，可以长期放心存放；特别重要的资料，仍建议你另外再留一份备份。
全站跑在容器化、模块化的现代架构上，更新、部署、回滚都很快，扩展性和稳定性都按长期运营的标准来设计（Built for reliability, designed to scale）。
这个网站最早只是一个人的笔记仓库，后来慢慢长成现在的知识中枢。设计上很克制——没有广告、没有追踪、没有推荐算法，只是干干净净地存放一些东西；既然做好了，就公开出来，万一有人用得上呢。
不做大而全，不做平台梦，保持简单、保持克制、保持好奇。所有内容都由用户贡献、由用户维护：不会突然冒出付费墙，不会在角落塞广告位，也不会把你的数据卖给第三方。
产品会持续迭代，站内日志页记录着每一次改动，改了什么都有迹可循；想了解这个站是怎么一步步走到今天的，翻翻日志就能看到来龙去脉。
如果在这里看到涉嫌违规的内容，点对应卡片右侧的“举报”按钮就能提交，我们会尽快核实处理；也谢谢你花一点时间，一起把这里维护干净。
读代码之前，我先跑这 5 条 Git 命令
本文介绍在阅读任何代码之前，通过 5 条 Git 命令快速诊断代码库健康状况的方法，帮助开发者优先定位高风险文件和潜在问题。
读代码之前，我先跑这 5 条 Git 命令
当我接手一个新代码库时，第一件事通常不是打开代码，而是打开终端，运行几条 Git 命令。在看任何文件之前，提交历史就能给我一张关于项目的诊断图：谁构建了它，问题集中在哪，团队是自信地发布还是在地雷阵中小心翼翼地踮脚走路。
1. 什么文件改动最频繁
bash
git log --format= --name-only --since='1 year ago' | sort | uniq -c | sort -nr | head -20
我通常从 app/ 或 src/ 目录执行这条命令，而不是仓库根目录——否则锁文件、变更日志和生成代码会霸占列表。
过去一年中改动最多的 20 个文件。排在最顶端的文件，几乎总是别人会警告我的那个：“哦，那个文件啊，没人敢碰它。”
高改动频率（churn）并不一定意味着文件质量差，有时只是活跃开发的表现。但如果一个高改动频率的文件没人愿意负责，那这就是我所知道的最清晰的麻烦信号。每次改动都是在一个补丁上再打个补丁，小改动的爆炸半径不可预测，团队因此会给估算加上缓冲，因为他们知道这个文件会“反抗”。
2005 年微软研究院的一项研究发现，相对 churn（按组件大小归一化的改动量）能很好地预测缺陷密度，而单独的绝对 churn 计数并不是好的预测指标。上面的命令属于绝对 churn 类型，所以我通常取前 5 个文件，再和下面的 bug 热点命令交叉比对。一个既高 churn 又高 bug 的文件，是你最大的风险点。
Adam Tornhill 的《Your Code as a Crime Scene》围绕 churn 分析构建了完整的方法论，包括这些原始命令所不覆盖的复杂度叠加视角。
2. 这个项目是谁建的
bash
git shortlog -sn --no-merges
按提交数量排列的每位贡献者。如果一个人占了 60% 以上，那就是你的“公交车因素”（bus factor）——一旦这人被公交车撞了，项目就停摆了。如果这个人六个月前就离开了，那就是一场危机。
如果总 shortlog 中的头号贡献者没有出现在最近六个月的记录中（用 git shortlog -sn --no-merges --since='6 months ago' 单独查看），我会立刻向客户标记这一点。
我还会看列表尾部。30 个贡献者，但过去一年只有 3 个人活跃——说明构建这个系统的人和现在维护它的人已经完全不同了。
一个重要的注意事项：squash-merge 工作流会压缩作者信息。如果团队把每个 PR squash 成单个 commit，这个输出反映的是“谁合并的”而不是“谁写的”。在得出结论之前，值得先问清楚团队的合并策略。
3. Bug 聚集在哪里
bash
git log -i -E --grep='fix|bug|broken' --name-only --format= | sort | uniq -c | sort -nr | head -20
这个命令的结构和 churn 命令一样，只是过滤出带有 bug 相关关键词的提交。把这个列表和 churn 热点对比——同时出现在两个列表中的文件就是最高风险代码：它们不断出问题、不断被打补丁，但从未被真正修复。
这个方法依赖提交信息的规范性。如果团队每次提交都写“update stuff”，你什么也得不到。但即使是一张粗略的 bug 密度地图，也比没有地图好。
4. 项目在加速还是走向死亡
bash
git log --format='%ad' --date=format:'%Y-%m' | sort | uniq -c
这个命令显示了整个仓库历史上每月的提交数量。我观察输出的“形状”：
- 稳定的节奏是健康的。
- 某个月份数量骤降一半——通常意味着有人离开了。
- 连续 6 到 12 个月的下降曲线——团队正在失去动力。
- 周期性尖峰加上沉默期——团队把工作堆积到发布批次中，而不是持续交付。
我曾经给一位 CTO 看他们的提交速度图表，他说“那个时间点我们失去了第二位资深工程师。”他们之前从未把时间线联系起来。这是团队数据，不是代码数据。
5. 团队有多频繁在“救火”
bash
git log --oneline --since='1 year ago' | grep -iE 'revert|hotfix|emergency|rollback'
Revert 和 hotfix 的频率。一年下来有几个是正常的；每几周就有 revert 则说明团队不信任自己的部署流程。这些 revert 是深层问题的证据：不可靠的测试、缺失的预发布环境，或者让回滚比本应更难操作的部署管道。
零结果也是一个信号——要么团队非常稳定，要么没人写描述性的提交信息。危机模式很容易识别：要么存在，要么不存在。
总结：两分钟换来精准的阅读起点
这五条命令只需几分钟就能运行完。它们不会告诉你一切，但你能知道该先读哪段代码，以及到了那里该找什么。这才是“第一天有条理地阅读代码库”和“第一天漫无目的地闲逛”之间的区别。
这也是我做完整代码库审计时第一个小时所做的工作。
延伸阅读：
- Why Your Engineering Team Is Slow (It's the Codebase, Not the People)
- Your Setup Script Should Support Git Worktrees
- How I Audit a Legacy Rails Codebase in the First Week
- Most of Your Tech Debt Is Free
- How to Be a Good Open Source Maintainer
原文链接：https://piechowski.io/post/git-commands-before-reading-code/