关于郑天祺
一处属于自己的线上自留地，记录编程路上的点滴学习与思考。如果你同样热爱代码，期待与你交流切磋，结伴前行，一同进步。
打赏支持
赞助通道
整理文档耗费大量时间精力，自愿小额赞助即可，感谢支持！
2024/6/16小于 1 分钟
凌晨两点，我又一次从梦中惊醒。
不是噩梦，只是那种说不清的焦虑感：项目进度会不会延期？技术选型是不是错了？同龄人已经升职加薪，我还在原地踏步？
这种时刻，你经历过吗？
我们这一代人，活得比任何一代都"信息充足"，却也活得比任何一代都焦虑。朋友圈里人人都在"搞钱"、"创业"、"上岸"，社交媒体上充斥着"30 岁前必须实现财务自由"、"25 岁没做到 P7 就废了"的论调。
但真相是：焦虑的根源不在外部，而在我们如何看待自己与世界。
这篇文章，我想和你聊聊两个命题：内视自己，摆脱焦虑；外观世界，借力而行。前者是修心，后者是做事。内外兼修，才是成年人该有的成长姿态。
2026/7/6大约 12 分钟
「我觉得用户需要这个功能」——凭感觉做产品决策的时代过去了。从数据埋点到指标体系，从 A/B 测试到决策落地，本文建立完整的数据驱动产品决策闭环。
一、数据埋点
1.1 埋点设计原则
埋点设计三层模型：
┌─────────────────────────────────────┐
│ 业务指标层 │
│ GMV / DAU / 转化率 / 留存率 │
└──────────────┬──────────────────────┘
│ 拆解
┌──────────────┴──────────────────────┐
│ 行为事件层 │
│ 点击 / 浏览 / 下单 / 支付 / 分享 │
└──────────────┬──────────────────────┘
│ 关联
┌──────────────┴──────────────────────┐
│ 属性维度层 │
│ 用户ID / 设备 / 渠道 / 版本 / 时间 │
└─────────────────────────────────────┘
设计原则：
1. 业务优先：先定业务指标，再倒推需要哪些事件
2. 命名规范：动词_名词（click_button / view_page）
3. 最小够用：不是什么都埋，埋关键路径
4. 可扩展：属性设计留扩展空间2026/7/3大约 8 分钟
OKR 是很好的目标管理工具，但很多技术团队的 OKR 要么变成了 KPI 换皮，要么 KR 写成了 Todo List。本文从 OKR 设计到落地执行，帮你把技术团队的 OKR 做到真正有效。
一、OKR vs KPI
OKR 与 KPI 的本质区别：
KPI（Key Performance Indicator）：
- 自上而下分配
- 与绩效/奖金挂钩
- 强调「必须完成」
- 员工倾向定低目标
- 适合：成熟业务、标准化运营
OKR（Objectives and Key Results）：
- 上下对齐 + 自下而上
- 与绩效解耦
- 强调「挑战目标」
- 鼓励设定有野心的目标
- 适合：创新业务、技术团队
┌──────────┬──────────────────┐
│ KPI │ OKR │
│ 考核工具 │ 目标对齐工具 │
│ 必须完成 │ 70% 完成算优秀 │
│ 与奖金挂钩│ 与奖金解耦 │
│ 自上而下 │ 上下结合 │
│ 定低目标 │ 定有挑战的目标 │
└──────────┴──────────────────┘2026/7/3大约 5 分钟
向上管理不是拍马屁，而是让主管成为你达成目标的资源。理解主管的风格和诉求，用正确的方式沟通和汇报，既能获得支持，又能保持自主性。
一、识别主管风格
四种主管风格：
┌──────────────┬──────────────────────────┐
│ 细节型 │ 关注过程和数据 │
│ (Detail) │ 要你汇报每一步 │
│ │ 擅长发现漏洞 │
│ │ 沟通：用数据说话 │
├──────────────┼──────────────────────────┤
│ 结果型 │ 只看结果，不关心过程 │
│ (Result) │ 要你给结论 │
│ │ 讨厌长篇大论 │
│ │ 沟通：结论先行 │
├──────────────┼──────────────────────────┤
│ 愿景型 │ 关注方向和意义 │
│ (Vision) │ 要你讲为什么 │
│ │ 不喜欢细节 │
│ │ 沟通：先讲价值再讲方案 │
├──────────────┼──────────────────────────┤
│ 流程型 │ 关注规范和流程 │
│ (Process) │ 要你按规矩办事 │
│ │ 重视文档和记录 │
│ │ 沟通：按流程+留痕迹 │
└──────────────┴──────────────────────────┘2026/7/3大约 5 分钟
技术文档写了很多，但没人看？方案写了几十页，评审时大家还是在问「这个方案到底要做什么」？问题不在技术深度，而在表达方式。本文从结构化思维到图表规范，帮你写出真正有人看的技术文档。
一、技术文档分类
技术文档四大类型：
┌──────────────┬──────────────────────┬────────────────┐
│ 类型 │ 读者 │ 核心目标 │
├──────────────┼──────────────────────┼────────────────┤
│ 设计文档 │ 技术团队 │ 方案对齐+评审 │
│ API 文档 │ 调用方开发者 │ 快速接入 │
│ 运维手册 │ 运维/SRE │ 故障处理 │
│ 复盘报告 │ 团队+管理层 │ 总结教训 │
└──────────────┴──────────────────────┴────────────────┘
写作黄金法则：
1. 先说结论，再说过程（金字塔原理）
2. 读者优先（写给谁看就站在谁的角度写）
3. 一图胜千言（能用图不用表，能用表不用段落）
4. 可执行（每个段落读者读完知道下一步做什么）2026/7/3大约 6 分钟
1on1 是管理者与团队成员最重要的沟通工具，但很多 1on1 变成了「项目进度汇报」或「没事就取消」。本文从话题清单到不同阶段策略，帮你把 1on1 变成团队成长的加速器。
一、1on1 的核心原则
1on1 不是什么：
❌ 项目进度汇报（那是站会的事）
❌ 绩效面谈（那是季度评审的事）
❌ 批评教育（那是即时反馈的事）
❌ 没事就取消（那说明你不重视人）
1on1 是什么：
✅ 专属的成长对话时间
✅ 倾听员工的想法和困难
✅ 帮助员工排除障碍
✅ 建立信任关系
核心原则：
1. 员工主导（让员工说 80%，管理者说 20%）
2. 定期坚持（每周或每两周一次，30-45 分钟）
3. 不取消（取消 1on1 = 传递「你不重要」的信号）
4. 跟进（上次聊的问题这次要跟进）2026/7/3大约 5 分钟
技术评审是技术团队最重要的质量保障环节，但现实中往往变成「走过场」——评审会变成念文档会，问题没人提，上线后才发现方案有硬伤。本文从评审前准备到评审后跟踪，建立完整的技术评审体系。
一、为什么要做技术评审
1.1 评审的价值
技术评审的四大价值：
1. 风险前置
评审前发现架构问题 = 修改方案 1 天
开发中发现架构问题 = 修改代码 + 方案 5 天
上线后发现架构问题 = 紧急修复 + 数据修复 15 天
2. 知识共享
方案作者独自理解系统 → 团队成员不理解
评审会讲解方案 → 团队对齐理解
后续维护时不会只有一个人懂
3. 架构演进
评审是架构对齐的机会
避免各模块各自为政导致架构碎片化
新方案与已有架构的一致性检查
4. 质量兜底
即使优秀工程师也会遗漏边界条件
多人审查降低低级错误概率
生产事故的最有效预防手段2026/7/3大约 8 分钟
Scrum 和 Kanban 都是敏捷方法，但适用场景截然不同。强行套用只会水土不服。本文从核心差异到选型决策，从落地实践到混合模式，帮你找到适合团队的敏捷之路。
一、Scrum 与 Kanban 核心差异
1.1 对比矩阵
Scrum Kanban
──────────────────────────────────────────────────────
节奏 固定 Sprint（1-4周） 持续流动（无固定迭代）
计划 Sprint Planning 按需拉取
承诺 Sprint 承诺范围 无承诺，持续交付
角色 SM / PO / Dev Team 无强制角色
仪式 站会/评审/回顾 站会（可选）
变更 Sprint 内不变 随时可变
限制 限制范围（Sprint 容量） 限制 WIP（在制品数）
度量 Velocity（故事点/迭代） Lead Time（端到端时间）
适用 需求相对明确 需求随机到达
产品开发 运维/支持/持续交付2026/7/3大约 6 分钟
业务要快，技术要稳。永远是一个矛盾。完全还债不迭代业务会死，完全迭代不还债也会死。本文建立技术债管理框架，帮你在业务交付和技术健康之间找到平衡点。
一、技术债分类
技术债四种类型：
┌────────────────────────────────────────┐
│ 有意识的技术债 │
│ 「我们知道有捷径，为了赶时间」 │
│ → 主动选择，有计划地还 │
│ → 危险性：可控 │
├────────────────────────────────────────┤
│ 无意识的技术债 │
│ 「不知道这样写有问题」 │
│ → 能力不足或经验不够 │
│ → 危险性：高（隐蔽性强） │
├────────────────────────────────────────┤
│ 环境演变的技术债 │
│ 「当年是对的，现在过时了」 │
│ → 框架升级/业务变化/规模变化 │
│ → 危险性：中（逐渐积累） │
├────────────────────────────────────────┤
│ 复杂度的技术债 │
│ 「系统太复杂没人敢动」 │
│ → 补丁打补丁，架构腐蚀 │
│ → 危险性：最高（可能导致系统重写） │
└────────────────────────────────────────┘
债务利息模型：
技术债就像信用卡：
本金：当初走捷径省下的时间（如省了 3 天）
利息：每次修改相关代码多花的时间（如每次多 0.5 天）
第 1 次修改：省 3 天 - 多 0.5 天 = 净省 2.5 天 ✅
第 5 次修改：省 3 天 - 多 2.5 天 = 净省 0.5 天 ⚠️
第 7 次修改：省 3 天 - 多 3.5 天 = 净亏 0.5 天 ❌
结论：技术债必须定期偿还，否则利息会超过本金2026/7/3大约 7 分钟