1. 项目概述这不是一本电子书而是一套可生长的个人知识操作系统“从零开始开源一本属于自己的 Pi 蓝皮书”——这个标题里藏着三个被多数人忽略的关键信号“Pi”不是圆周率而是Personal Intelligence个人智能的缩写“蓝皮书”不是政府白皮书的仿制品而是指代一套结构清晰、可验证、可迭代的个人能力基准文档“开源”二字是整个项目的灵魂它意味着透明、可协作、可 Fork、可部署而非仅限于“公开发布”。我最早在某高校数字人文实验室看到类似实践一位导师要求研究生不再交传统结课报告而是用 Markdown Git 搭建自己的“Pi 蓝皮书”仓库内容涵盖“我如何定义‘理解’一个概念”“我在处理模糊需求时的决策树”“我识别认知偏差的7个触发信号”等真实元认知痕迹。它不展示“我学会了什么”而是暴露“我如何学会”——这才是 Pi 的本质对自身学习机制的可观测、可调试、可版本化。这本蓝皮书的核心价值从来不在“出版”或“传播”而在于强制你把隐性经验显性化、把碎片直觉结构化、把临时方案沉淀为可复用模块。比如你今天调试一段 Python 爬虫失败了常规做法是查 Stack Overflow 改两行代码但在 Pi 蓝皮书框架下你必须记录触发场景目标网站反爬策略升级错误表征HTTP 429 响应但未触发 requests.exceptions.TooManyRedirects排查路径先确认是否 IP 封禁 → 再检查 headers 是否缺失 Referer → 最后发现是 Cloudflare 的 JavaScript 挑战未绕过解决方案改用 undetected-chromedriver3 自定义 User-Agent 轮询池反思锚点“下次遇到 429应优先检查 JS 挑战而非单纯加 delay”这些记录不是日志而是你个人智能的操作手册。当某天你接手新项目需要快速评估技术风险时直接检索自己蓝皮书里的“429 应对模式”比重读三篇教程更高效。它服务的对象只有一个未来的你自己。适合谁所有厌倦了“学完就忘”“用时再搜”“重复踩坑”的实践者——程序员、设计师、教师、研究员、自由职业者甚至备考学生。只要你需要持续提升解决未知问题的能力这本书就是你的底层基础设施。2. 整体设计逻辑为什么必须用 Git Markdown 而非 Notion 或飞书2.1 选择 Git 的底层动因版本即思考轨迹很多人第一反应是“用 Notion 多方便拖拽排版、实时协作、模板丰富。”但 Pi 蓝皮书的核心诉求是保留思考的熵减过程而 Notion 的编辑历史只存“最终状态快照”Git 却天然记录每一次git commit -m 修正对贝叶斯更新的理解prior 不是主观臆断而是上一轮 posterior 的继承。这种粒度让“知识进化”变得可追溯。我试过两种对比实验Notion 方案建立“认知模型”数据库每新增一个模型如双环学习模型新建一页填入定义、案例、应用步骤。三个月后想回顾“我最初如何理解单环学习”只能靠记忆翻找或依赖模糊的页面创建时间。Git 方案在models/learning.md文件中用 Git Blame 查看某段文字的作者和提交时间用git log --oneline -p models/learning.md直接看到“第7次修订时我把‘反馈批评’改为‘反馈系统输出与预期的差值’”并附带当时的注释“受控制论启发重新定义反馈本质”。提示Git 的分支功能在此场景有奇效。主干main保持稳定共识如已验证的思维模型draft/mental-models分支存放待验证假设如“注意力残留效应导致多任务切换损耗达40%”review/2024Q3分支集中处理季度复盘。这种结构让知识演进像软件开发一样可控。2.2 为什么坚持纯 Markdown可移植性是生存底线有人质疑“Markdown 太简陋不能画流程图、插公式、嵌视频。”但 Pi 蓝皮书的第一原则是长期可读性。2035 年当你硬盘老化、云服务停运、某平台格式变更时一个.md文件仍能用记事本打开。而 Notion 导出的 HTML 可能因 CSS 丢失乱码飞书文档导出 PDF 后无法搜索公式。实操中我用以下方式弥补 Markdown 的“简陋”公式用 KaTeX 语法$E mc^2$GitHub/GitLab 原生渲染VS Code 安装 Markdown Preview Enhanced 插件实时预览图表用 Mermaid 语法虽禁止在输出中使用但本地写作完全支持如graph TD; A[问题] -- B[假设]; B -- C[实验]; C -- D[结论]导出为 SVG 后嵌入交互关键模型配可运行代码块Python/JavaScript读者复制即得结果如计算“不同遗忘曲线参数下的复习间隔建议”。注意所有外部依赖如 Mermaid 渲染器、KaTeX CDN必须在 README 中明确标注且提供降级方案如 SVG 图片备份、LaTeX 原始代码注释。这是开源精神的体现——不制造锁定只提供便利。2.3 “蓝皮书”命名的深意拒绝浪漫化拥抱工程化“蓝皮书”一词常被误读为“权威指南”。但在这里它特指以标准文档形式承载个人能力基线。参考 NIST美国国家标准与技术研究院的 SP 800 系列安全指南其核心特征是可验证每条能力声明附带验证方法如“能独立完成端到端机器学习项目” → 验证提供 GitHub 仓库链接含数据清洗、特征工程、模型训练、AB 测试全流程代码可分解大能力拆解为原子技能“数据清洗” → “识别缺失值模式”“处理时间序列异常点”“评估插补算法误差”可度量避免“熟练掌握”等模糊表述改用“在 30 分钟内完成某类数据集的标准化清洗错误率 0.5%”。这种命名强迫你放弃“我觉得我懂了”的幻觉直面“如何证明我懂了”的拷问。它不是自我表扬的简历而是自我审计的账本。3. 核心内容架构四大支柱与十二个必建模块3.1 支柱一认知基模库Cognitive Schemas这是蓝皮书的“操作系统内核”定义你理解世界的基本单元。它不罗列知识点而收录你反复调用的思维原型。必建模块 1问题分类矩阵我自建的 3×3 矩阵横轴是“问题确定性”高/中/低纵轴是“解法可复现性”高/中/低。例如高确定性高可复现编译报错查文档→改语法→重编译低确定性低可复现用户说“这个界面感觉不对劲”需访谈→原型测试→A/B 验证。每次遇到新问题先定位矩阵坐标再调用对应解决协议。避免用“调试思维”处理“体验问题”。必建模块 2决策权重表记录你在关键决策中实际使用的隐性标准。例如选技术栈时我曾以为“社区活跃度”权重最高但翻看历史 commit 发现git diff显示我 7 次修改都聚焦于“本地构建耗时”于是将“构建速度”权重从 20% 提至 45%并量化为“CI 流水线平均耗时 8 分钟”。这张表每年重校准一次防止认知惰性。必建模块 3认知偏差自查清单不是背诵维基百科列表而是记录你亲历的偏差实例。如确认偏误2023年3月为验证“TypeScript 能提升前端效率”我刻意忽略团队中 3 位成员提出的类型维护成本案例只统计了 2 个成功项目。后续在蓝皮书中加入强制动作“引用反例前必须注明其来源与上下文”。实操心得每个基模模块必须包含“失效场景”子章节。例如“奥卡姆剃刀原则”在蓝皮书中注明“当问题涉及多主体博弈如用户、运营、法务三方需求冲突时过度简化将导致关键约束被忽略”。3.2 支柱二技能执行层Skill Execution Layer这是“知道”到“做到”的转换器重点记录技能落地的摩擦点而非步骤。必建模块 4工具链配置快照不写“安装 VS Code”而记录当前生效的settings.json关键项如editor.rulers: [80, 120],files.autoSave: onFocusChange插件版本与冲突说明如“Prettier v3.0 与 ESLint v8.50 冲突需禁用 Prettier 的 formatOnSave”本地环境变量陷阱如JAVA_HOME指向 JDK 17 但某旧项目强制要求 JDK 8解决方案用 SDKMAN 切换。必建模块 5高频操作速查表按场景组织非按工具组织。例如“紧急修复线上 Bug”流程git checkout -b hotfix/$(date %Y%m%d)-prod-bug main创建带日期的热修复分支git log --oneline -n 10 origin/main确认最近 10 次上线变更curl -X POST https://api.example.com/v1/debug/trace?span_idxxx调用内部诊断 API修复后执行npm run test:ci -- --grepcritical-path仅运行核心路径测试。每步附带“为什么这一步不可跳过”的解释如第2步避免在错误的 baseline 上修复。必建模块 6失败案例归档这是最易被忽视的宝藏。我归档的“Docker 构建缓存失效”案例包含现象docker build每次都从RUN npm install重新执行耗时 12 分钟根本原因.dockerignore文件遗漏了package-lock.json导致每次COPY . .都触发缓存失效验证方法docker build --no-cache对比耗时确认是缓存问题长期方案在 CI 脚本中加入ls -la .dockerignore | grep package-lock检查。注意所有失败案例必须标注“可复现条件”。如“仅当 Node.js 版本 18.17.0 且使用 pnpm workspace 时触发”否则会误导他人。3.3 支柱三知识连接网Knowledge Graph解决“信息孤岛”问题强制建立跨领域关联。必建模块 7概念映射表同一概念在不同领域的表达差异。例如“状态”前端 ReactuseState的返回值可变且需通过setState更新后端数据库transaction的 ACID 属性强调一致性控制理论state space中的向量描述系统动态心理学flow state一种意识专注的主观体验。表格最后一列是“我的统一理解”“状态是系统在特定时刻的可观测属性集合其变化规则由系统边界内的约束定义”。必建模块 8跨项目迁移日志记录某方案从 A 项目迁移到 B 项目的适配过程。如将“用户行为埋点 SDK”从电商项目迁移到教育项目差异点教育项目需追踪“视频暂停时长”电商项目无此需求修改在 SDK 初始化时增加trackVideoPause: true配置风险pause_duration字段名与现有 BI 系统字段冲突改用video_pause_ms验证在教育项目 QA 环境播放视频抓包确认上报字段正确。必建模块 9术语定义词典拒绝直接引用维基用“我的语言”定义。例如“微服务”我的定义“一组松耦合的进程每个进程封装单一业务能力通过网络协议通信独立部署与扩缩容。关键判据能否在不修改其他进程的前提下将某进程替换为完全不同的技术实现如用 Rust 重写 Java 服务”附验证案例曾将订单服务从 Spring Boot 迁移至 Actix-web仅修改 API 网关路由下游无感知。3.4 支柱四成长度量仪Growth Metrics用数据对抗“我以为我在进步”的错觉。必建模块 10技能熟练度雷达图每季度用 1-5 分自评1完全不会5可指导他人维度包括技术深度如对 TCP 拥塞控制算法的理解工具效能如 Vim 宏编写熟练度沟通精度如需求文档一次通过率系统思维如绘制完整业务链路图的准确率。雷达图用 Python matplotlib 生成脚本存于scripts/generate_radar.py输入为metrics/skill_q3_2024.csv。必建模块 11时间投资回报分析记录每周 20 小时学习时间的分配与产出时间投入学习内容产出物ROI 评估1-53hWebAssembly 内存模型实现 Canvas 图像滤镜加速45hFigma 插件开发发布开源插件“Auto-Layout Helper”3ROI 评估标准1无实际应用5直接解决当前项目瓶颈。每月分析“高 ROI 活动共性”如发现“动手实现 看视频教程”占比达 80%。必建模块 12认知负荷日志每日记录最高负荷时段如“上午 10:00-11:30处理 3 个并发需求评审”负荷类型认知超载/情绪耗竭/信息过载缓解动作如“启动番茄钟强制 25 分钟专注”效果验证“下午 14:00 重审需求发现上午忽略的 2 个合规风险点”。一年后该日志揭示出“连续会议超过 2 小时必然导致决策质量下降 40%”据此推动团队改用“异步文档评审15 分钟同步对齐”模式。4. 实操全流程从初始化到持续演进的七步法4.1 第一步初始化仓库与基础骨架15 分钟# 创建私有仓库初期可私有成熟后开源 gh repo create my-pi-bluebook --private --description My Personal Intelligence Bluebook # 克隆并初始化 git clone gitgithub.com:username/my-pi-bluebook.git cd my-pi-bluebook # 创建核心目录结构 mkdir -p {models,skills,knowledge,metrics,scripts,assets} touch README.md LICENSEREADME.md首要内容不是介绍项目而是使用协议## 使用前必读 - 本仓库所有内容均基于个人实践不构成专业建议 - 引用他人成果时已在对应文件顶部标注来源与许可 - 修改任何模块前请先阅读 CONTRIBUTING.md 中的“变更原则” - 每次 git push 前必须运行 make validate见 scripts/Makefile。实操心得CONTRIBUTING.md是蓝皮书的宪法。我规定所有新增模块必须包含“适用场景”“失效条件”“验证方法”三要素否则 PR 不予合并。这看似繁琐却杜绝了“半成品知识”的污染。4.2 第二步构建自动化验证流水线30 分钟在.github/workflows/validate.yml中定义name: Validate Bluebook on: [push, pull_request] jobs: markdown-lint: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - uses: DavidAnson/markdownlint-actionv6 with: config: .markdownlint.json link-check: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - name: Check internal links run: | # 使用 ripgrep 检查所有 .md 文件中的相对链接是否有效 rg -o \]\(([^)])\) --replace $1 **/*.md | xargs -I {} sh -c if [ ! -e {} ]; then echo Broken link: {}; exit 1; fiscripts/Makefile提供本地快捷命令.PHONY: validate lint check-links validate: lint check-links lint: echo Running markdownlint... markdownlint **/*.md check-links: echo Checking internal links... find . -name *.md -exec grep -l \]\( {} \; | xargs -I {} sh -c grep -o \]\([^)]*\) {} | sed s/](// | while read link; do if [ ! -e $$(dirname {})/$$link ] [ $$link ! # ]; then echo ERROR: Broken link in $$1: $$link; exit 1; fi; done注意验证脚本必须轻量。我曾用 Python 脚本做复杂校验结果 CI 耗时 3 分钟导致大家绕过验证。现在所有检查在 20 秒内完成配合pre-commit钩子真正实现“提交即验证”。4.3 第三步填充首期认知基模2 小时以“问题分类矩阵”为例创建models/problem-matrix.md# 问题分类矩阵 v1.0 ## 设计原理 基于 Cynefin 框架简化聚焦工程师日常场景。核心区分**问题是否可被明确定义**确定性**解法是否可被精确复现**可复现性。 ## 矩阵定义 | 确定性↓ / 可复现性→ | 高标准化流程 | 中需调参 | 低高度情境化 | |-------------------|------------------|--------------|------------------| | **高定义清晰** | 编译错误br• 现象SyntaxError: Unexpected tokenbr• 解法定位行号修正语法 | 性能优化br• 现象API 响应 2sbr• 解法火焰图分析调整数据库索引 | 用户体验问题br• 现象“这个按钮点击没反馈”br• 解法录屏观察用户访谈 | | **中部分模糊** | 需求歧义br• 现象“支持多语言”未定义语种范围br• 解法列出所有目标市场逐个确认 | 技术选型br• 现象选 GraphQL 还是 RESTbr• 解法按 QPS、团队熟悉度、工具链成熟度打分 | 跨部门协作br• 现象法务要求修改用户协议但未说明合规依据br• 解法请求出具 GDPR/CCPA 条款原文 | | **低定义困难** | 技术债评估br• 现象“代码很乱”br• 解法用 SonarQube 扫描 团队共识阈值 | 组织变革br• 现象“推行敏捷但效果不佳”br• 解法测量需求交付周期、缺陷逃逸率 | 战略方向br• 现象“下一个增长点在哪”br• 解法PESTEL 分析 客户痛点地图 | ## 使用指南 1. 遇到新问题先填写现象描述 2. 在矩阵中定位坐标 3. 查看对应“解法”列执行第一步 4. 若失败记录失败原因至 knowledge/lessons-learned.md。实操心得首期内容宁缺毋滥。我只填满 4 个格子高确定性高可复现、高确定性低可复现、中确定性中可复现、低确定性低可复现其余留空并标注“待验证”。这比填满虚假答案更有价值。4.4 第四步建立技能执行速查1 小时创建skills/emergency-fix.md# 紧急修复线上 Bug 操作速查 ## 前置检查 - ✅ 确认问题影响范围监控告警、用户反馈量级 - ✅ 检查是否已有相同告警避免重复修复 - ✅ 验证本地环境能否复现curl -v https://prod-api.example.com/health。 ## 标准流程 ### 步骤 1创建热修复分支 bash git checkout -b hotfix/$(date %Y%m%d)-prod-bug origin/main为什么确保修复基于最新生产代码避免合并冲突。步骤 2最小化修改仅修改引发问题的文件禁止重构、格式化、添加日志除非用于定位修改后立即运行npm run test:unit -- --testPathPatternaffected-file。步骤 3验证与上线在预发环境部署用 Postman 测试核心路径执行curl -X POST https://staging-api.example.com/v1/debug/trace?span_id$(uuidgen)获取全链路 trace通过后git push origin hotfix/$(date %Y%m%d)-prod-bug触发 CI 自动部署。失效场景❌ 当问题涉及数据库 schema 变更时此流程不适用需 DBA 审批❌ 当修复需修改第三方 SDK 时此流程不适用需 fork 并提 PR。### 4.5 第五步启动知识连接网1 小时 创建 knowledge/concept-mapping.md以“状态”为例 markdown # 概念映射“状态”State ## 前端视角React - **定义**组件内部可变数据通过 useState 声明setState 更新 - **关键约束**状态更新是异步的setState 后立即 console.log(state) 仍为旧值 - **我的实践**用 useEffect 监听状态变化而非在 setState 后写副作用。 ## 后端视角PostgreSQL - **定义**事务中数据的一致性快照通过 MVCC 实现 - **关键约束**SELECT 在事务内始终看到同一快照即使其他事务已提交 - **我的实践**在高并发计数场景用 UPDATE ... RETURNING 替代 SELECT UPDATE避免竞态。 ## 统一理解 “状态是系统在特定时刻的可观测属性集合其变化规则由系统边界内的约束定义。前端状态的约束是 React 的渲染生命周期数据库状态的约束是 ACID 事务隔离级别。” ## 迁移案例 - 将 React 状态管理逻辑迁移到后端 API原前端 useState({ loading: false, data: [] }) → 后端 API 返回 {status: loading, data: []}前端仅做展示。 - 教训迁移后前端失去对 loading 状态的细粒度控制如“加载中但可取消”需在 API 增加 cancel_token 字段。4.6 第六步部署成长度量仪45 分钟创建metrics/skill-assessment-q3-2024.md# 2024 年第三季度技能评估 ## 评估维度与得分 | 维度 | 得分 | 证据 | |------|------|------| | **技术深度** | 3.5 | • TCP 拥塞控制能解释 Reno 与 Cubic 差异但未实测过 BBRv2br• 阅读 Linux 内核 net/ipv4/tcp_cong.c 源码标注 12 处疑问 | | **工具效能** | 4.0 | • Vim编写 5 个常用宏如自动插入 import 语句br• Git熟练使用 git rebase -i 重构提交历史 | | **沟通精度** | 3.0 | • 需求文档一次通过率 65%目标 80%br• 主要问题未明确“响应时间 200ms”是指 P95 还是平均值 | | **系统思维** | 4.5 | • 绘制完整订单履约链路图含库存、支付、物流经 3 位同事验证 | ## 关键改进项 - **提升沟通精度**下季度起所有需求文档模板强制包含“指标定义”章节明确 Pxx、平均值、采样周期 - **深化技术深度**启动“TCP 实战计划”在本地 minikube 集群部署 3 种拥塞控制算法用 iperf3 对比吞吐量。配套scripts/generate_radar.pyimport matplotlib.pyplot as plt import numpy as np # 数据来自 metrics/skill-assessment-q3-2024.md 的表格 dimensions [技术深度, 工具效能, 沟通精度, 系统思维] scores [3.5, 4.0, 3.0, 4.5] # 绘制雷达图 angles [n / float(len(dimensions)) * 2 * np.pi for n in range(len(dimensions))] scores scores[:1] # 闭合图形 angles angles[:1] fig, ax plt.subplots(figsize(6, 6), subplot_kwdict(polarTrue)) ax.fill(angles, scores, colorblue, alpha0.25) ax.plot(angles, scores, colorblue, linewidth2) ax.set_xticks(angles[:-1]) ax.set_xticklabels(dimensions) ax.set_ylim(0, 5) plt.title(2024 Q3 技能雷达图) plt.savefig(assets/radar-q3-2024.png, dpi300, bbox_inchestight)4.7 第七步建立持续演进机制长期季度复盘仪式每季度最后周五下午关闭所有通知用 2 小时执行运行git log --since3 months ago --oneline | wc -l统计提交量git diff HEAD~30 HEAD --stat查看修改分布是否过度集中在某模块重读knowledge/lessons-learned.md将高频问题升格为新模块更新CONTRIBUTING.md中的“变更原则”。外部反馈通道在README.md添加## 参与共建 本蓝皮书欢迎外部视角。若发现 - 某模块的“失效场景”描述不准确 - 某验证方法存在更优解 - 跨领域概念映射有遗漏 请提交 Issue标题格式[Feedback] 模块名问题简述。防退化设计在scripts/check-degradation.sh中# 检查是否超过 30 天未更新 skills/ 目录 if [ $(git log -n 1 --pretty%at -- skills/) -lt $(( $(date %s) - 30*24*3600 )) ]; then echo WARNING: skills/ directory not updated for 30 days. Consider reviewing emergency-fix.md. fi5. 常见问题与实战排障那些没人告诉你的坑5.1 问题知识过载不知从何写起现象面对空白仓库大脑一片空白觉得“所有东西都该写但又不知写什么最重要”。排查思路这不是知识不足而是缺乏锚点。Pi 蓝皮书不是百科全书而是你的“问题响应日志”。解决方案倒推法打开最近 3 天的聊天记录/邮件找出让你花最多时间解释的概念如“为什么这个 API 要用 PUT 而不是 POST”截取法打开 IDE查看最近修改的 5 个文件针对每个文件的TODO注释写一个“为什么这个 TODO 如此棘手”的分析压力测试法想象明天要给新人培训你必须用 10 分钟讲清“我们如何做代码审查”把这 10 分钟的内容直接写成skills/code-review.md。实操心得我最初的蓝皮书只有 3 个文件models/problem-matrix.md、skills/emergency-fix.md、knowledge/lessons-learned.md。坚持写满 10 个真实失败案例后自然衍生出其他模块。不要追求完整追求“第一个可运行的版本”。5.2 问题Git 提交太琐碎历史难以阅读现象git log显示 50 行提交全是update readme、fix typo无法快速定位关键演进。根本原因混淆了“编辑行为”和“知识演进”。每次拼写修正不是知识更新而是编辑噪音。解决方案启用git add -p交互式暂存只提交语义相关的改动如一次提交只包含“问题分类矩阵新增低确定性行”制定提交信息规范在CONTRIBUTING.md中强制feat:新增能力模块如feat: add problem-matrix v1.0fix:修正知识错误如fix: correct TCP congestion control descriptionrefactor:重构模块结构如refactor: split knowledge/concepts.md into mapping and definitionsdocs:文档优化如docs: improve emergency-fix.md readability定期git rebase -i每季度将docs:类提交压缩为 1 行保留feat/fix/refactor的原始粒度。注意不要为了“整洁历史”而删除他人提交。开源精神的第一课是尊重贡献痕迹。5.3 问题内容越写越像教科书失去个人特质现象写的“认知偏差”模块和维基百科词条几乎一样读起来没有“我的味道”。排查思路你正在复述知识而非暴露思考。Pi 蓝皮书的价值在于“你的错误”而非“你的正确”。解决方案强制添加“我的第一次”章节每个模块开头写“我第一次遭遇这个问题是在 2022 年 5 月当时正在重构用户认证模块。我以为 JWT 的exp字段只需设为 24 小时结果导致凌晨 3 点大量用户会话失效……”用“错误代码”代替“正确代码”在skills/模块中先贴出你写过的典型错误代码如if (user.role admin)再分析为何错硬编码角色名最后给出改进方案user.hasPermission(manage_users)。引入“争议点”标签在models/模块中对有分歧的观点标注[争议] 我认为“微服务应按业务能力而非技术分层”但某公司架构师主张“先按技术分层API/Service/Data再逐步业务化”。我的证据……5.4 问题团队协作时知识冲突如何解决现象同事 A 认为“前端状态应完全由 Redux 管理”同事 B 认为“局部状态用 useState 更高效”蓝皮书该写谁的核心原则Pi 蓝皮书是个人智能档案不是团队规范文档。但可以成为团队共识的孵化器。实操流程各自记录A 在my-pi-bluebook/models/state-management.md写“Redux 全局状态优势”B 在 my-p 用Git+Markdown构建个人知识操作系统：Pi蓝皮书实践指南
1. 项目概述这不是一本电子书而是一套可生长的个人知识操作系统“从零开始开源一本属于自己的 Pi 蓝皮书”——这个标题里藏着三个被多数人忽略的关键信号“Pi”不是圆周率而是Personal Intelligence个人智能的缩写“蓝皮书”不是政府白皮书的仿制品而是指代一套结构清晰、可验证、可迭代的个人能力基准文档“开源”二字是整个项目的灵魂它意味着透明、可协作、可 Fork、可部署而非仅限于“公开发布”。我最早在某高校数字人文实验室看到类似实践一位导师要求研究生不再交传统结课报告而是用 Markdown Git 搭建自己的“Pi 蓝皮书”仓库内容涵盖“我如何定义‘理解’一个概念”“我在处理模糊需求时的决策树”“我识别认知偏差的7个触发信号”等真实元认知痕迹。它不展示“我学会了什么”而是暴露“我如何学会”——这才是 Pi 的本质对自身学习机制的可观测、可调试、可版本化。这本蓝皮书的核心价值从来不在“出版”或“传播”而在于强制你把隐性经验显性化、把碎片直觉结构化、把临时方案沉淀为可复用模块。比如你今天调试一段 Python 爬虫失败了常规做法是查 Stack Overflow 改两行代码但在 Pi 蓝皮书框架下你必须记录触发场景目标网站反爬策略升级错误表征HTTP 429 响应但未触发 requests.exceptions.TooManyRedirects排查路径先确认是否 IP 封禁 → 再检查 headers 是否缺失 Referer → 最后发现是 Cloudflare 的 JavaScript 挑战未绕过解决方案改用 undetected-chromedriver3 自定义 User-Agent 轮询池反思锚点“下次遇到 429应优先检查 JS 挑战而非单纯加 delay”这些记录不是日志而是你个人智能的操作手册。当某天你接手新项目需要快速评估技术风险时直接检索自己蓝皮书里的“429 应对模式”比重读三篇教程更高效。它服务的对象只有一个未来的你自己。适合谁所有厌倦了“学完就忘”“用时再搜”“重复踩坑”的实践者——程序员、设计师、教师、研究员、自由职业者甚至备考学生。只要你需要持续提升解决未知问题的能力这本书就是你的底层基础设施。2. 整体设计逻辑为什么必须用 Git Markdown 而非 Notion 或飞书2.1 选择 Git 的底层动因版本即思考轨迹很多人第一反应是“用 Notion 多方便拖拽排版、实时协作、模板丰富。”但 Pi 蓝皮书的核心诉求是保留思考的熵减过程而 Notion 的编辑历史只存“最终状态快照”Git 却天然记录每一次git commit -m 修正对贝叶斯更新的理解prior 不是主观臆断而是上一轮 posterior 的继承。这种粒度让“知识进化”变得可追溯。我试过两种对比实验Notion 方案建立“认知模型”数据库每新增一个模型如双环学习模型新建一页填入定义、案例、应用步骤。三个月后想回顾“我最初如何理解单环学习”只能靠记忆翻找或依赖模糊的页面创建时间。Git 方案在models/learning.md文件中用 Git Blame 查看某段文字的作者和提交时间用git log --oneline -p models/learning.md直接看到“第7次修订时我把‘反馈批评’改为‘反馈系统输出与预期的差值’”并附带当时的注释“受控制论启发重新定义反馈本质”。提示Git 的分支功能在此场景有奇效。主干main保持稳定共识如已验证的思维模型draft/mental-models分支存放待验证假设如“注意力残留效应导致多任务切换损耗达40%”review/2024Q3分支集中处理季度复盘。这种结构让知识演进像软件开发一样可控。2.2 为什么坚持纯 Markdown可移植性是生存底线有人质疑“Markdown 太简陋不能画流程图、插公式、嵌视频。”但 Pi 蓝皮书的第一原则是长期可读性。2035 年当你硬盘老化、云服务停运、某平台格式变更时一个.md文件仍能用记事本打开。而 Notion 导出的 HTML 可能因 CSS 丢失乱码飞书文档导出 PDF 后无法搜索公式。实操中我用以下方式弥补 Markdown 的“简陋”公式用 KaTeX 语法$E mc^2$GitHub/GitLab 原生渲染VS Code 安装 Markdown Preview Enhanced 插件实时预览图表用 Mermaid 语法虽禁止在输出中使用但本地写作完全支持如graph TD; A[问题] -- B[假设]; B -- C[实验]; C -- D[结论]导出为 SVG 后嵌入交互关键模型配可运行代码块Python/JavaScript读者复制即得结果如计算“不同遗忘曲线参数下的复习间隔建议”。注意所有外部依赖如 Mermaid 渲染器、KaTeX CDN必须在 README 中明确标注且提供降级方案如 SVG 图片备份、LaTeX 原始代码注释。这是开源精神的体现——不制造锁定只提供便利。2.3 “蓝皮书”命名的深意拒绝浪漫化拥抱工程化“蓝皮书”一词常被误读为“权威指南”。但在这里它特指以标准文档形式承载个人能力基线。参考 NIST美国国家标准与技术研究院的 SP 800 系列安全指南其核心特征是可验证每条能力声明附带验证方法如“能独立完成端到端机器学习项目” → 验证提供 GitHub 仓库链接含数据清洗、特征工程、模型训练、AB 测试全流程代码可分解大能力拆解为原子技能“数据清洗” → “识别缺失值模式”“处理时间序列异常点”“评估插补算法误差”可度量避免“熟练掌握”等模糊表述改用“在 30 分钟内完成某类数据集的标准化清洗错误率 0.5%”。这种命名强迫你放弃“我觉得我懂了”的幻觉直面“如何证明我懂了”的拷问。它不是自我表扬的简历而是自我审计的账本。3. 核心内容架构四大支柱与十二个必建模块3.1 支柱一认知基模库Cognitive Schemas这是蓝皮书的“操作系统内核”定义你理解世界的基本单元。它不罗列知识点而收录你反复调用的思维原型。必建模块 1问题分类矩阵我自建的 3×3 矩阵横轴是“问题确定性”高/中/低纵轴是“解法可复现性”高/中/低。例如高确定性高可复现编译报错查文档→改语法→重编译低确定性低可复现用户说“这个界面感觉不对劲”需访谈→原型测试→A/B 验证。每次遇到新问题先定位矩阵坐标再调用对应解决协议。避免用“调试思维”处理“体验问题”。必建模块 2决策权重表记录你在关键决策中实际使用的隐性标准。例如选技术栈时我曾以为“社区活跃度”权重最高但翻看历史 commit 发现git diff显示我 7 次修改都聚焦于“本地构建耗时”于是将“构建速度”权重从 20% 提至 45%并量化为“CI 流水线平均耗时 8 分钟”。这张表每年重校准一次防止认知惰性。必建模块 3认知偏差自查清单不是背诵维基百科列表而是记录你亲历的偏差实例。如确认偏误2023年3月为验证“TypeScript 能提升前端效率”我刻意忽略团队中 3 位成员提出的类型维护成本案例只统计了 2 个成功项目。后续在蓝皮书中加入强制动作“引用反例前必须注明其来源与上下文”。实操心得每个基模模块必须包含“失效场景”子章节。例如“奥卡姆剃刀原则”在蓝皮书中注明“当问题涉及多主体博弈如用户、运营、法务三方需求冲突时过度简化将导致关键约束被忽略”。3.2 支柱二技能执行层Skill Execution Layer这是“知道”到“做到”的转换器重点记录技能落地的摩擦点而非步骤。必建模块 4工具链配置快照不写“安装 VS Code”而记录当前生效的settings.json关键项如editor.rulers: [80, 120],files.autoSave: onFocusChange插件版本与冲突说明如“Prettier v3.0 与 ESLint v8.50 冲突需禁用 Prettier 的 formatOnSave”本地环境变量陷阱如JAVA_HOME指向 JDK 17 但某旧项目强制要求 JDK 8解决方案用 SDKMAN 切换。必建模块 5高频操作速查表按场景组织非按工具组织。例如“紧急修复线上 Bug”流程git checkout -b hotfix/$(date %Y%m%d)-prod-bug main创建带日期的热修复分支git log --oneline -n 10 origin/main确认最近 10 次上线变更curl -X POST https://api.example.com/v1/debug/trace?span_idxxx调用内部诊断 API修复后执行npm run test:ci -- --grepcritical-path仅运行核心路径测试。每步附带“为什么这一步不可跳过”的解释如第2步避免在错误的 baseline 上修复。必建模块 6失败案例归档这是最易被忽视的宝藏。我归档的“Docker 构建缓存失效”案例包含现象docker build每次都从RUN npm install重新执行耗时 12 分钟根本原因.dockerignore文件遗漏了package-lock.json导致每次COPY . .都触发缓存失效验证方法docker build --no-cache对比耗时确认是缓存问题长期方案在 CI 脚本中加入ls -la .dockerignore | grep package-lock检查。注意所有失败案例必须标注“可复现条件”。如“仅当 Node.js 版本 18.17.0 且使用 pnpm workspace 时触发”否则会误导他人。3.3 支柱三知识连接网Knowledge Graph解决“信息孤岛”问题强制建立跨领域关联。必建模块 7概念映射表同一概念在不同领域的表达差异。例如“状态”前端 ReactuseState的返回值可变且需通过setState更新后端数据库transaction的 ACID 属性强调一致性控制理论state space中的向量描述系统动态心理学flow state一种意识专注的主观体验。表格最后一列是“我的统一理解”“状态是系统在特定时刻的可观测属性集合其变化规则由系统边界内的约束定义”。必建模块 8跨项目迁移日志记录某方案从 A 项目迁移到 B 项目的适配过程。如将“用户行为埋点 SDK”从电商项目迁移到教育项目差异点教育项目需追踪“视频暂停时长”电商项目无此需求修改在 SDK 初始化时增加trackVideoPause: true配置风险pause_duration字段名与现有 BI 系统字段冲突改用video_pause_ms验证在教育项目 QA 环境播放视频抓包确认上报字段正确。必建模块 9术语定义词典拒绝直接引用维基用“我的语言”定义。例如“微服务”我的定义“一组松耦合的进程每个进程封装单一业务能力通过网络协议通信独立部署与扩缩容。关键判据能否在不修改其他进程的前提下将某进程替换为完全不同的技术实现如用 Rust 重写 Java 服务”附验证案例曾将订单服务从 Spring Boot 迁移至 Actix-web仅修改 API 网关路由下游无感知。3.4 支柱四成长度量仪Growth Metrics用数据对抗“我以为我在进步”的错觉。必建模块 10技能熟练度雷达图每季度用 1-5 分自评1完全不会5可指导他人维度包括技术深度如对 TCP 拥塞控制算法的理解工具效能如 Vim 宏编写熟练度沟通精度如需求文档一次通过率系统思维如绘制完整业务链路图的准确率。雷达图用 Python matplotlib 生成脚本存于scripts/generate_radar.py输入为metrics/skill_q3_2024.csv。必建模块 11时间投资回报分析记录每周 20 小时学习时间的分配与产出时间投入学习内容产出物ROI 评估1-53hWebAssembly 内存模型实现 Canvas 图像滤镜加速45hFigma 插件开发发布开源插件“Auto-Layout Helper”3ROI 评估标准1无实际应用5直接解决当前项目瓶颈。每月分析“高 ROI 活动共性”如发现“动手实现 看视频教程”占比达 80%。必建模块 12认知负荷日志每日记录最高负荷时段如“上午 10:00-11:30处理 3 个并发需求评审”负荷类型认知超载/情绪耗竭/信息过载缓解动作如“启动番茄钟强制 25 分钟专注”效果验证“下午 14:00 重审需求发现上午忽略的 2 个合规风险点”。一年后该日志揭示出“连续会议超过 2 小时必然导致决策质量下降 40%”据此推动团队改用“异步文档评审15 分钟同步对齐”模式。4. 实操全流程从初始化到持续演进的七步法4.1 第一步初始化仓库与基础骨架15 分钟# 创建私有仓库初期可私有成熟后开源 gh repo create my-pi-bluebook --private --description My Personal Intelligence Bluebook # 克隆并初始化 git clone gitgithub.com:username/my-pi-bluebook.git cd my-pi-bluebook # 创建核心目录结构 mkdir -p {models,skills,knowledge,metrics,scripts,assets} touch README.md LICENSEREADME.md首要内容不是介绍项目而是使用协议## 使用前必读 - 本仓库所有内容均基于个人实践不构成专业建议 - 引用他人成果时已在对应文件顶部标注来源与许可 - 修改任何模块前请先阅读 CONTRIBUTING.md 中的“变更原则” - 每次 git push 前必须运行 make validate见 scripts/Makefile。实操心得CONTRIBUTING.md是蓝皮书的宪法。我规定所有新增模块必须包含“适用场景”“失效条件”“验证方法”三要素否则 PR 不予合并。这看似繁琐却杜绝了“半成品知识”的污染。4.2 第二步构建自动化验证流水线30 分钟在.github/workflows/validate.yml中定义name: Validate Bluebook on: [push, pull_request] jobs: markdown-lint: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - uses: DavidAnson/markdownlint-actionv6 with: config: .markdownlint.json link-check: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - name: Check internal links run: | # 使用 ripgrep 检查所有 .md 文件中的相对链接是否有效 rg -o \]\(([^)])\) --replace $1 **/*.md | xargs -I {} sh -c if [ ! -e {} ]; then echo Broken link: {}; exit 1; fiscripts/Makefile提供本地快捷命令.PHONY: validate lint check-links validate: lint check-links lint: echo Running markdownlint... markdownlint **/*.md check-links: echo Checking internal links... find . -name *.md -exec grep -l \]\( {} \; | xargs -I {} sh -c grep -o \]\([^)]*\) {} | sed s/](// | while read link; do if [ ! -e $$(dirname {})/$$link ] [ $$link ! # ]; then echo ERROR: Broken link in $$1: $$link; exit 1; fi; done注意验证脚本必须轻量。我曾用 Python 脚本做复杂校验结果 CI 耗时 3 分钟导致大家绕过验证。现在所有检查在 20 秒内完成配合pre-commit钩子真正实现“提交即验证”。4.3 第三步填充首期认知基模2 小时以“问题分类矩阵”为例创建models/problem-matrix.md# 问题分类矩阵 v1.0 ## 设计原理 基于 Cynefin 框架简化聚焦工程师日常场景。核心区分**问题是否可被明确定义**确定性**解法是否可被精确复现**可复现性。 ## 矩阵定义 | 确定性↓ / 可复现性→ | 高标准化流程 | 中需调参 | 低高度情境化 | |-------------------|------------------|--------------|------------------| | **高定义清晰** | 编译错误br• 现象SyntaxError: Unexpected tokenbr• 解法定位行号修正语法 | 性能优化br• 现象API 响应 2sbr• 解法火焰图分析调整数据库索引 | 用户体验问题br• 现象“这个按钮点击没反馈”br• 解法录屏观察用户访谈 | | **中部分模糊** | 需求歧义br• 现象“支持多语言”未定义语种范围br• 解法列出所有目标市场逐个确认 | 技术选型br• 现象选 GraphQL 还是 RESTbr• 解法按 QPS、团队熟悉度、工具链成熟度打分 | 跨部门协作br• 现象法务要求修改用户协议但未说明合规依据br• 解法请求出具 GDPR/CCPA 条款原文 | | **低定义困难** | 技术债评估br• 现象“代码很乱”br• 解法用 SonarQube 扫描 团队共识阈值 | 组织变革br• 现象“推行敏捷但效果不佳”br• 解法测量需求交付周期、缺陷逃逸率 | 战略方向br• 现象“下一个增长点在哪”br• 解法PESTEL 分析 客户痛点地图 | ## 使用指南 1. 遇到新问题先填写现象描述 2. 在矩阵中定位坐标 3. 查看对应“解法”列执行第一步 4. 若失败记录失败原因至 knowledge/lessons-learned.md。实操心得首期内容宁缺毋滥。我只填满 4 个格子高确定性高可复现、高确定性低可复现、中确定性中可复现、低确定性低可复现其余留空并标注“待验证”。这比填满虚假答案更有价值。4.4 第四步建立技能执行速查1 小时创建skills/emergency-fix.md# 紧急修复线上 Bug 操作速查 ## 前置检查 - ✅ 确认问题影响范围监控告警、用户反馈量级 - ✅ 检查是否已有相同告警避免重复修复 - ✅ 验证本地环境能否复现curl -v https://prod-api.example.com/health。 ## 标准流程 ### 步骤 1创建热修复分支 bash git checkout -b hotfix/$(date %Y%m%d)-prod-bug origin/main为什么确保修复基于最新生产代码避免合并冲突。步骤 2最小化修改仅修改引发问题的文件禁止重构、格式化、添加日志除非用于定位修改后立即运行npm run test:unit -- --testPathPatternaffected-file。步骤 3验证与上线在预发环境部署用 Postman 测试核心路径执行curl -X POST https://staging-api.example.com/v1/debug/trace?span_id$(uuidgen)获取全链路 trace通过后git push origin hotfix/$(date %Y%m%d)-prod-bug触发 CI 自动部署。失效场景❌ 当问题涉及数据库 schema 变更时此流程不适用需 DBA 审批❌ 当修复需修改第三方 SDK 时此流程不适用需 fork 并提 PR。### 4.5 第五步启动知识连接网1 小时 创建 knowledge/concept-mapping.md以“状态”为例 markdown # 概念映射“状态”State ## 前端视角React - **定义**组件内部可变数据通过 useState 声明setState 更新 - **关键约束**状态更新是异步的setState 后立即 console.log(state) 仍为旧值 - **我的实践**用 useEffect 监听状态变化而非在 setState 后写副作用。 ## 后端视角PostgreSQL - **定义**事务中数据的一致性快照通过 MVCC 实现 - **关键约束**SELECT 在事务内始终看到同一快照即使其他事务已提交 - **我的实践**在高并发计数场景用 UPDATE ... RETURNING 替代 SELECT UPDATE避免竞态。 ## 统一理解 “状态是系统在特定时刻的可观测属性集合其变化规则由系统边界内的约束定义。前端状态的约束是 React 的渲染生命周期数据库状态的约束是 ACID 事务隔离级别。” ## 迁移案例 - 将 React 状态管理逻辑迁移到后端 API原前端 useState({ loading: false, data: [] }) → 后端 API 返回 {status: loading, data: []}前端仅做展示。 - 教训迁移后前端失去对 loading 状态的细粒度控制如“加载中但可取消”需在 API 增加 cancel_token 字段。4.6 第六步部署成长度量仪45 分钟创建metrics/skill-assessment-q3-2024.md# 2024 年第三季度技能评估 ## 评估维度与得分 | 维度 | 得分 | 证据 | |------|------|------| | **技术深度** | 3.5 | • TCP 拥塞控制能解释 Reno 与 Cubic 差异但未实测过 BBRv2br• 阅读 Linux 内核 net/ipv4/tcp_cong.c 源码标注 12 处疑问 | | **工具效能** | 4.0 | • Vim编写 5 个常用宏如自动插入 import 语句br• Git熟练使用 git rebase -i 重构提交历史 | | **沟通精度** | 3.0 | • 需求文档一次通过率 65%目标 80%br• 主要问题未明确“响应时间 200ms”是指 P95 还是平均值 | | **系统思维** | 4.5 | • 绘制完整订单履约链路图含库存、支付、物流经 3 位同事验证 | ## 关键改进项 - **提升沟通精度**下季度起所有需求文档模板强制包含“指标定义”章节明确 Pxx、平均值、采样周期 - **深化技术深度**启动“TCP 实战计划”在本地 minikube 集群部署 3 种拥塞控制算法用 iperf3 对比吞吐量。配套scripts/generate_radar.pyimport matplotlib.pyplot as plt import numpy as np # 数据来自 metrics/skill-assessment-q3-2024.md 的表格 dimensions [技术深度, 工具效能, 沟通精度, 系统思维] scores [3.5, 4.0, 3.0, 4.5] # 绘制雷达图 angles [n / float(len(dimensions)) * 2 * np.pi for n in range(len(dimensions))] scores scores[:1] # 闭合图形 angles angles[:1] fig, ax plt.subplots(figsize(6, 6), subplot_kwdict(polarTrue)) ax.fill(angles, scores, colorblue, alpha0.25) ax.plot(angles, scores, colorblue, linewidth2) ax.set_xticks(angles[:-1]) ax.set_xticklabels(dimensions) ax.set_ylim(0, 5) plt.title(2024 Q3 技能雷达图) plt.savefig(assets/radar-q3-2024.png, dpi300, bbox_inchestight)4.7 第七步建立持续演进机制长期季度复盘仪式每季度最后周五下午关闭所有通知用 2 小时执行运行git log --since3 months ago --oneline | wc -l统计提交量git diff HEAD~30 HEAD --stat查看修改分布是否过度集中在某模块重读knowledge/lessons-learned.md将高频问题升格为新模块更新CONTRIBUTING.md中的“变更原则”。外部反馈通道在README.md添加## 参与共建 本蓝皮书欢迎外部视角。若发现 - 某模块的“失效场景”描述不准确 - 某验证方法存在更优解 - 跨领域概念映射有遗漏 请提交 Issue标题格式[Feedback] 模块名问题简述。防退化设计在scripts/check-degradation.sh中# 检查是否超过 30 天未更新 skills/ 目录 if [ $(git log -n 1 --pretty%at -- skills/) -lt $(( $(date %s) - 30*24*3600 )) ]; then echo WARNING: skills/ directory not updated for 30 days. Consider reviewing emergency-fix.md. fi5. 常见问题与实战排障那些没人告诉你的坑5.1 问题知识过载不知从何写起现象面对空白仓库大脑一片空白觉得“所有东西都该写但又不知写什么最重要”。排查思路这不是知识不足而是缺乏锚点。Pi 蓝皮书不是百科全书而是你的“问题响应日志”。解决方案倒推法打开最近 3 天的聊天记录/邮件找出让你花最多时间解释的概念如“为什么这个 API 要用 PUT 而不是 POST”截取法打开 IDE查看最近修改的 5 个文件针对每个文件的TODO注释写一个“为什么这个 TODO 如此棘手”的分析压力测试法想象明天要给新人培训你必须用 10 分钟讲清“我们如何做代码审查”把这 10 分钟的内容直接写成skills/code-review.md。实操心得我最初的蓝皮书只有 3 个文件models/problem-matrix.md、skills/emergency-fix.md、knowledge/lessons-learned.md。坚持写满 10 个真实失败案例后自然衍生出其他模块。不要追求完整追求“第一个可运行的版本”。5.2 问题Git 提交太琐碎历史难以阅读现象git log显示 50 行提交全是update readme、fix typo无法快速定位关键演进。根本原因混淆了“编辑行为”和“知识演进”。每次拼写修正不是知识更新而是编辑噪音。解决方案启用git add -p交互式暂存只提交语义相关的改动如一次提交只包含“问题分类矩阵新增低确定性行”制定提交信息规范在CONTRIBUTING.md中强制feat:新增能力模块如feat: add problem-matrix v1.0fix:修正知识错误如fix: correct TCP congestion control descriptionrefactor:重构模块结构如refactor: split knowledge/concepts.md into mapping and definitionsdocs:文档优化如docs: improve emergency-fix.md readability定期git rebase -i每季度将docs:类提交压缩为 1 行保留feat/fix/refactor的原始粒度。注意不要为了“整洁历史”而删除他人提交。开源精神的第一课是尊重贡献痕迹。5.3 问题内容越写越像教科书失去个人特质现象写的“认知偏差”模块和维基百科词条几乎一样读起来没有“我的味道”。排查思路你正在复述知识而非暴露思考。Pi 蓝皮书的价值在于“你的错误”而非“你的正确”。解决方案强制添加“我的第一次”章节每个模块开头写“我第一次遭遇这个问题是在 2022 年 5 月当时正在重构用户认证模块。我以为 JWT 的exp字段只需设为 24 小时结果导致凌晨 3 点大量用户会话失效……”用“错误代码”代替“正确代码”在skills/模块中先贴出你写过的典型错误代码如if (user.role admin)再分析为何错硬编码角色名最后给出改进方案user.hasPermission(manage_users)。引入“争议点”标签在models/模块中对有分歧的观点标注[争议] 我认为“微服务应按业务能力而非技术分层”但某公司架构师主张“先按技术分层API/Service/Data再逐步业务化”。我的证据……5.4 问题团队协作时知识冲突如何解决现象同事 A 认为“前端状态应完全由 Redux 管理”同事 B 认为“局部状态用 useState 更高效”蓝皮书该写谁的核心原则Pi 蓝皮书是个人智能档案不是团队规范文档。但可以成为团队共识的孵化器。实操流程各自记录A 在my-pi-bluebook/models/state-management.md写“Redux 全局状态优势”B 在 my-p RELATED READING
延伸阅读
更多一线实战笔记与深度复盘，助您持续精进
