YANG 的博客

AI Coding 时代，程序员真正的核心竞争力

Wed, 04 Mar 2026 01:44:56 GMT

当 OpenClaw、Claude Code、Codex 这类工具进入日常开发后，很多人会焦虑：程序员会不会被替代？

我更认同一个判断：AI 真正压缩的，不是程序员这个职业，而是过去行业泡沫里被高估的“伪能力”。

被淘汰的不是人，而是“低杠杆工作方式”

过去几年里，很多“看起来很忙”的能力，正在被 AI 快速吞噬：

依赖模板拼装代码
复制粘贴答案解决问题
靠加班和体力硬顶交付

这些工作并不等于工程能力，只是在特定阶段被市场误认为“高产出”。现在 AI 能在几秒内生成组件、补全测试、重构样板代码，这部分价值自然会被重新定价。

所以，问题从“我会不会被替代”，变成了“我的价值是否建立在 AI 难以替代的能力上”。

AI 时代最值钱的四项能力

1) 系统性设计能力

AI 可以写代码，但不能替你定义系统边界和约束。
真正有价值的工程师，需要先回答这些问题：

这段代码为什么存在？
它在系统中的职责是什么？
它和上下游模块的耦合关系如何？
后续扩展与测试成本是否可控？

从“写代码的人”转向“设计闭环的人”，本质是在定义规则，让 AI 在规则内高质量执行。

2) 批判性思维

传统路径是“写完再调试”。
更高阶的路径是“先预判风险，再决定实现”。

你需要在方案阶段主动识别：

隐含假设是否成立
边界条件是否覆盖
异常路径是否可恢复
性能与安全风险是否前置处理

AI 可以生成可运行代码，但它不会天然对业务后果负责。工程师的价值，就是把“可运行”提升为“可上线、可演进、可追责”。

3) 严谨的文字表达能力

很多人把 Prompt 能力理解成“会写提示词”，其实底层是“会清晰表达”。

无论是需求澄清、方案评审还是跨团队协作，表达越精确，返工越少。
你写给 AI 的每一句约束，和你写给同事的每一条需求，本质上是同一种能力：去歧义、补上下文、明确验收标准。

4) 清晰的逻辑能力

逻辑能力是所有工程工作的底座：

拆解复杂问题
建立因果链路
识别关键变量
做出可解释的技术取舍

当 AI 承担更多执行动作后，人类的价值会持续向“想清楚再动手”集中。

程序员身份的三重转变

在 AI Coding 时代，工程师角色会出现三个明显迁移：

从代码生产者到闭环设计师
核心变化：从“怎么写”转向“定义写什么、不写什么”。
从任务执行者到方案制定者
核心变化：从“亲自动手”转向“制定规则，让 AI 稳定执行”。
从功能实现者到质量把关者
核心变化：从“做完就行”转向“判断什么才叫做得好”。

这不是职业降级，而是向工程本质回归：程序员从来不只是打字员，而是复杂问题的解决者。

一条可执行的升级路径

如果你想在 3 个月内完成一次能力升级，可以按这个顺序推进：

每个需求先写“问题定义”和“验收标准”，再让 AI 写代码。
每次提交前做一次“反例检查”：失败路径、边界条件、回滚策略。
强制输出简短设计说明：目标、约束、方案、风险、权衡。
把 AI 产出当初稿，人工完成架构一致性和质量门禁。

坚持下来，你会明显感受到：你不再是和 AI 竞争写代码速度，而是在利用 AI 放大自己的工程判断力。

写在最后

AI 没有让程序员不重要。
它只是让“伪能力”更快失效，让“真能力”更快显形。

当 AI 负责执行，人类负责定义“什么是好的系统、好的代码、好的交付”，这可能就是研发协作最自然的下一阶段。

OpenClaw 的崛起 - 2026 年自托管 AI Agent 元年开启

Sat, 28 Feb 2026 02:00:00 GMT

注：本文中的项目热度、社区规模等数据为时间点快照，统计口径截至 2026-02-28。

一次差点酿成灾难的自动化

2026 年 2 月下旬，Meta AI 对齐团队负责人 Summer Yue 在社交媒体分享了一次惊险经历：她的自托管 AI Agent 在清理邮件时，差点把几封关键工作邮件一起删掉。她在最后阶段手动叫停，才避免了后续连锁问题。

这件事值得重视，不是因为它“罕见”，而是因为它“典型”。当我们给 Agent 执行权限时，风险模型会立刻变化。传统聊天助手答错了，最多是信息错误；可执行 Agent 做错了，可能直接造成业务后果。

从个人项目到基金会治理框架

OpenClaw 最早由奥地利开发者 Peter Steinberger 发起。项目经历了从 Clawdbot 到 Moltbot 再到 OpenClaw 的命名演化，核心目标一直很明确：让 Agent 能在本地运行、可控执行，而不是完全依赖云端托管服务。

2026 年 2 月，Steinberger 宣布加入 OpenAI。与此同时，OpenClaw 明确将继续以开源方式发展，并进入基金会治理框架。这意味着两点：

自托管 Agent 方向的产业价值，已经得到头部机构验证。
社区驱动与开放生态，仍是这个项目的核心资产。

为什么 OpenClaw 会在这个时间点爆发

这个问题的答案不是“单点突破”，而是多因素叠加。

模型能力跨过实用门槛。多步任务理解、工具调用、结构化输出都比两年前稳定得多。
本地硬件性价比显著提升。 Apple Silicon 和消费级 GPU 让“持续运行一个可用 Agent”变得可行。
用户需求发生变化。用户不再只满足于“问答”，而是希望 AI 真正“帮我做完”。
隐私与合规压力倒逼架构变化。在金融、医疗、政务等场景中，数据主权是前置约束，不是锦上添花。

一个更务实的架构理解

下面这张图是概念化示意，不是官方实现细节的一比一映射。它用来说明 OpenClaw 类系统通常会怎样分层。

+------------------+     +------------------+
|   用户消息入口    | --> |  Gateway Server  |
| WhatsApp/Telegram|     |    (网关层)        |
| Discord/Slack... |     +--------+---------+
+------------------+              |
                                  v
                    +--------------------------+
                    |      Agent Runner        |
                    |    (运行与调度层)         |
                    | 生命周期、状态、恢复逻辑    |
                    +------------+-------------+
                                 |
                                 v
                    +--------------------------+
                    |     Agentic Loop         |
                    |    (决策与执行循环)       |
                    | 工具选择、调用、校验、迭代  |
                    +------------+-------------+
                                 |
                                 v
                    +--------------------------+
                    |     Response Path        |
                    |      (结果回传层)         |
                    | 通知、摘要、失败告警       |
                    +--------------------------+

和“只会聊天”的助手相比，关键差别在于 Agentic Loop：它不是只生成一段文本，而是会持续调度工具并推进任务状态。

技能生态与记忆机制：价值和边界

OpenClaw 的吸引力，一半来自技能生态，一半来自记忆可控性。

技能方面，社区已经形成了规模化贡献趋势，覆盖自动化办公、网页操作、文件处理、API 集成等高频场景。具体技能数量变化很快，建议以项目官方文档或仓库实时数据为准。

记忆方面，OpenClaw 倾向于“文件可读、结构可审计”的设计路线。对开发者和团队来说，这比黑盒数据库更容易做版本追踪、差异审阅和权限分层。

memory/
├── preferences.md      # 用户偏好
├── tasks.md            # 任务队列
├── contacts.md         # 联系人
└── knowledge/          # 知识库
    ├── tech.md
    ├── finance.md
    └── personal.md

这套机制的优势是可控；代价是你需要承担一定的“知识卫生”工作，比如定期清理、冲突合并和备份策略。

三个长期被压抑的需求

OpenClaw 的增长速度，不只是“营销成功”，更像是需求集中释放。

隐私与数据主权。企业越来越难接受“敏感数据默认上云”的前提。
订阅疲劳与成本不确定性。当团队同时订阅多个 AI 服务时，预算和采购的可预测性会快速下降。
系统自主可控。关键能力若完全绑定第三方 API，定价、限流、策略调整都会成为经营风险。

谁适合现在上 OpenClaw

并不是所有人都应该立刻自托管。更现实的判断方式是看你的约束和目标。

适合优先尝试的人群：

对数据驻留有明确要求的团队。
有自动化场景且愿意投入运维能力的工程团队。
想把 Agent 当“可持续生产系统”而非“演示工具”的个人开发者。

不适合马上投入的人群：

还没有稳定任务场景，只是为了“跟热点”。
没有最基本的监控、备份、权限管理能力。
希望“零维护、即开即用、100% 无风险”的用户。

最小安全清单（建议先做再扩展）

如果你准备让 Agent 进入生产流程，至少先落地下面五项：

权限分级。高风险操作单独授权，默认拒绝写操作。
高风险确认门槛。删除、转账、对外发送等操作必须二次确认。
全链路审计日志。记录触发人、上下文、工具调用、结果和回滚信息。
可回滚机制。保证关键操作具备撤销路径，而不是“执行即不可逆”。
定期备份与恢复演练。只备份不演练，等于没有备份。

成本模型：先算三笔账

“自托管更便宜”不总是成立，至少要按三笔账来评估。

硬件与电力成本。取决于模型规模、运行时长、负载峰值和当地电价。
模型与推理成本。本地模型不一定等于零成本；云 API 也不一定总是昂贵，关键看调用结构。
运维与人力成本。部署、监控、故障处理、升级迁移都是真实成本。

一个务实做法是：先在单一业务场景做 4 到 8 周 PoC，用真实任务数据核算 TCO，再决定是否扩大部署。

行业影响：会变，但不是一夜之间

2026 年很可能是自托管 Agent 的关键年份，但“关键年份”不等于“全面替代”。更可信的路径是并存：

云端 Agent 继续承担低门槛与通用场景。
自托管 Agent 深入隐私敏感和高可控场景。
混合架构成为企业主流选择。

这意味着开发者的能力模型也会变化：不仅要会提示词和工作流，还要懂权限系统、观察性、回滚策略和本地部署工程化。

结语

Summer Yue 那次险些误删邮件的事件提醒我们：Agent 时代的核心问题不再是“它会不会说”，而是“它能不能安全地做”。

OpenClaw 的意义不只在于一个项目爆红，而在于它把“可执行 AI + 用户可控”这条路线推到了产业中心。对开发者来说，这是新一轮工程能力重估；对企业来说，这是一次架构与治理的再选择。

2026 年是否会被定义为“自托管 AI Agent 元年”，历史会给答案。但可以确定的是，AI 的主战场正在从“对话质量”转向“执行质量与治理质量”。

来自GPT的2025总结：这面镜子有点狠

Mon, 22 Dec 2025 09:02:00 GMT

来自GPT对我的年度总结，Prompt如下：我每年元旦都会给下一年的自己写一封邮件。在这封信里，我会100%对自己诚实，记录这一年里真实的收获、成长、成就、判断、思考、困局、犹豫和未解决的问题。同时，我也会认真思考下一年，在人生各个重要的重要维度上，我真正想要的是什么，以及我可能需要面对的选择与代价。我也希望你能以一个长期旁观者、冷静、非常毒鸡汤的视角。不要鼓励、不回避尖锐问题的，能够真正提醒我一些我容易忽略、回避或自我合理化的地方。希望你是客观描述和评价的。帮我回忆尽可能更多的事实和细节。

这不是写给“更好的自己”，而是写给真实的自己。

站在一个长期旁观者的位置，回看2025年：这不仅仅是一次总结，更是一次对反复出现的模式、习惯性的自我解释方式的清算。下面不是安慰，也不是鼓励，而是一面不太给面子的镜子。

一、把事实摆在桌面上：高密度的积累与结构性的停滞

1. 这一年并不“停滞”，但也远未“突破”

这一年你做了很多事，而且是高密度、长期、可复用的事。你并没有在偷懒，你的努力体现在三个核心领域：

技术领导力（Technical Leadership）：在一个运行多年的教育SaaS系统里，你明确进入了系统性重构者的角色。分层架构、业务中台、迁移蓝图……你不再纠结“怎么写代码”，而是在纠结“哪些能力值得存在”、“哪些组织形态会拖死系统”。
AI 探索（AI Exploration）：你对 AI 的使用已经超过了“工具玩家”。你搭建了个人 AI 工作流，并在思考 AI 能力中台、Agent 市场以及 AI 作为系统能力的逻辑。
内容创作（Content Creation）：你持续经营着第二认知出口。博客重构、内容体系搭建、选题方法论的沉淀。你已经非常清楚什么内容“会被保存”，什么仅仅是自嗨。

2. 残酷的落差

但同样清楚的事实是：没有一个领域，在外部世界里形成了“你一提就想到”的锚点。

你所有的努力都在“积累势能”，但势能始终没有被允许释放为“动能”。没有一个项目在现实层面带来了不可忽视的结构性变化（职位、收入、时间主权）。你依然处在一种“准备得越来越充分，但始终未上场”的状态。

二、模式识别：你如何用“完美”囚禁自己

为什么会出现这种“高能低效”的局面？通过深度审视，几个隐蔽的行为模式浮出水面：

1. 沉溺于“可控复杂度” 你习惯站在一个看似冒险、实际上高度可控的位置。技术重构风险巨大，但你有经验和话语权；内容创作随时可停，不影响生存；AI 投入成本高，但不需即时承诺。你很少真正把自己放在那种——**“如果这个判断错了，我必须付出真实代价”**的局面。这不是懦弱，这是能力带来的“安全感副作用”。

2. 从“执行焦虑”逃向“方向焦虑” 你现在焦虑的已经不是“我够不够努力”或“技术行不行”，而是更麻烦的问题：“这是不是路径依赖？”、“我是否在帮别人完成宏大叙事？”。这类焦虑不会因为更努力而消失，它的本质往往是成长的证据，但也极易成为停滞的借口。

3. “系统完整性”作为安全毯 你对“完整”、“闭环”、“分层清晰”的执念，既是优势，也是最高级的掩护。它让你一直处在**“准备更充分之前”**，一直有理由不把某个东西推到现实里接受检验。

4. 长期主义的变体：拖延主义 你相信长期价值，但你正在把所有当下的不决断，合理化为“这是长期的一部分”。

明明知道某些选择在3年后必然更难，但现在依然选择“再观察一年”。
明明已经足够判断一个方向的上限，但依然告诉自己“再多积累一些”。
长期主义应该压缩犹豫，而不是无限延长它。

三、关键质问：给明年的三个拷问

当你写给明年的自己时，不要给答案，请诚实地回答这三个问题：

如果一年后我依然站在同一个位置，那我现在是在逃避什么？
哪些选择，其实已经被我用“理性”否决过很多次？
如果我只能在一个维度上失去安全感（时间、金钱、声誉），我会选哪一个？

四、洞察与框架：打破僵局

要结束这种“高度清醒、持续准备、尚未落地”的人生阶段，你需要新的心智框架：

1. 寻找“不可逆承诺”的最小有效剂量 你需要的不是更多认知，而是一次**“不可逆承诺”**。这种决定通常不优雅，也不完美，甚至有点狼狈。但这并不意味着必须 All-in 赌博。

你需要找到一种中间态 —— 既能产生真实的约束力（Skin in the game），又不至于造成毁灭性打击。

2. 区分“方向迷茫”与“恐惧掩饰” 做一个诊断测试：如果给你3个月完全自由支配的时间，你会做什么？如果答案很快出现且清晰，那你不是在迷茫，你只是在恐惧。如果是后者，你需要的是承诺机制，而不是更多的思考。

3. 势能的时间窗口 不要以为“积累”永远有效。某些领域的积累具有指数效应，但机会窗口（如 AI 浪潮）和年龄带来的试错成本上升是客观存在的。势能如果不释放，最终会贬值为一种沉重的“怀才不遇感”。

五、行动设计：制造结构性变化

如果不主动制造一次结构性变化，变化不会自动发生。2026年，请致力于以下三个维度的渐进式重构：

1. 时间结构变化

目标：真正能支配的时间。
行动：每周固定划拨 X 小时，用于完全不依赖单一雇佣关系的工作。这不是“业余时间”，这是“种子时间”。

2. 收入结构变化

目标：不依赖单一雇佣关系。
行动：设定“副业/第二曲线收入达到主业 Y%”的具体里程碑。甚至可以设定一个必须交付的商业化小闭环，哪怕只赚1块钱，也要跑通全流程。

3. 身份结构变化

目标：别人如何向第三者介绍你。
行动：在特定圈子里，主动使用新标签介绍自己。不再是“某系统的技术负责人”，而是“[你的新身份]”。

4. 具体的测试

行动：选择一个项目，设定一个公开的 Deadline，并引入外部监督（或预付成本）。让“准备”本身成为一种公开的、带约束力的行动。

结语：这本身就是一种选择

这篇文章本身就是一个有趣的悖论：你是用“构建完整认知体系”的方式，在批判“用构建体系来推迟行动”的模式。

所以，让这篇总结成为最后一次纯粹的“认知构建”吧。

这不是为了制造焦虑，是为了让时间重新有重量。 你不是迷路的人。 你更像是：一直站在路口，却迟迟不肯承认自己已经看清方向的人。

还要在这里站多久？ 这本身，就是一种选择。

《疯狂动物城2》：和谐的代价？

Mon, 15 Dec 2025 02:47:05 GMT

从童话到寓言的转变

当孩子们在影院里为朱迪和尼克的冒险欢笑时，成年观众应该意识到，《疯狂动物城 2》远不止是一部合家欢动画。这部续集延续了前作的传统，将复杂的社会学命题包裹在色彩斑斓的动物世界中，但其批判的锋芒实际上更加深入。

如果说 2016 年的《疯狂动物城》是对个人偏见和隐性歧视的揭露，那么 2025 年的续集则将镜头对准了更为根本的问题：压迫如何被编织进社会结构本身。这不再是关于“好人也会有偏见”的道德寓言，而是对殖民历史、空间政治、权力世袭的系统性批判。

影片的英文标题 Zootopia 本身就是一个精心设计的悖论——“Zoo”（动物园/囚笼）与“Utopia”（乌托邦）的结合，暗示着这座看似完美的城市，实质上是建立在排斥与控制之上的。续集的任务，就是撕开这层乌托邦的伪装，让观众看到繁荣表象下的暴力基础。

三层结构性压迫的揭示

《疯狂动物城2》最重要的理论贡献，在于它呈现了压迫的三重结构，从表层深入到根基。

个人层面的偏见

这是第一部的主要关注点，也是续集的起点。朱迪携带防狐喷雾、对尼克脱口而出的冒犯性语言，展现了“隐性偏见”和“微侵犯”的运作机制。即使是自认为进步的个体，也可能在无意识中延续歧视的逻辑。

续集中，这种个人偏见延伸到了对爬行动物的恐惧。Gary 作为一条温和、甚至有些胆怯的蛇，与动物城居民对他“冷血杀手”的想象形成巨大反差。这种反差不再基于生物本能，而是纯粹的文化建构——爬行动物被妖魔化，完全是因为他们是“异类”。

制度层面的歧视

警察系统本身成为续集审视的对象。朱迪作为“第一只兔子警官”，经历的不仅是 tokenism（象征性任命），更是整个体制对“异常者”的排斥机制。她和尼克被强制参加的“伴侣咨询”，表面上是心理辅导，实际上是体制对不合规范行为的规训。

更深层的批判在于，影片暗示了警察作为权力维护者的角色。朱迪和尼克虽然是“英雄”，但他们始终在体制内部运作，依靠国家暴力机器来“拯救”被压迫群体。这延续了第一部遭受的批评——“白人救世主”和“蓝命贵”的叙事框架，即依然将希望寄托在建制派的良知上，而非赋予被压迫者自身反抗的能动性。

结构层面的系统性压迫

这是续集最具颠覆性的部分。影片揭示，歧视不仅存在于人的头脑或制度的条文中，更被固化在城市的物理空间里。

气候墙系统、Marsh Market 的隔离、爬行动物的历史性缺席——这些设定共同指向一个核心命题：Zootopia 的繁荣，建立在对某些群体的系统性排斥之上。这不是个别政客的阴谋，而是城市建构的原初暴力。

隐喻

A. 爬行动物的缺席与回归

第一部中爬行动物的完全缺席，在续集中被揭示为一场历史性的驱逐。这直接对应了“定居者殖民主义”的逻辑：

首先，污名化原住民。一起被操纵的谋杀案（蛇咬死乌龟），将整个族群标记为“危险”和“野蛮”。
其次，物理驱逐。爬行动物被赶出城市核心区，他们的社区 Reptile Ravine 被改造或摧毁。
第三步，历史抹除。爬行动物对城市建设的贡献（发明气候墙技术）被彻底抹去，功劳归于殖民者 Lynxley 家族。
最后，合法化叙事。城市的“建国神话”将创始人塑造为英雄，将驱逐行为正当化为“安全需要”。

B. 气候墙系统

气候墙在第一部中被呈现为技术奇迹——它让不同气候需求的物种能够共存。但续集彻底颠覆了这种乐观解读：

气候墙不是包容的工具，而是隔离的武器。
它划分出不同的气候区，本质上是空间隔离的物理体现。
干燥和寒冷区域的设计，刻意排除了爬行动物的生存需求，这是一种“环境暴力”。
气候墙的维护和扩张权力，掌握在 Lynxley 家族手中，使其成为垄断资源、控制人口流动的工具。

C. Marsh Market

Marsh Market 是续集中最具象征意义的场景。这个建在沼泽湿地上的社区，通过木板路和管道连接，充满了南方海湾的贫民窟氛围。它是 Zootopia 的“反面”：

空间边缘化：被切断在城市核心之外，成为爬行动物、水生哺乳动物等“不受欢迎者”的聚集地。
经济边缘化：走私、黑市交易盛行，这不是居民的“道德缺陷”，而是被排斥在合法经济体系外的必然结果。
文化边缘化：拥有独特的活力和社区文化，但被主流社会视为“危险”和“混乱”。

Lynxley 家族计划扩张 Tundratown（冰川镇），这意味着要吞并 Marsh Market。这是赤裸裸的士绅化隐喻：

以“城市发展”之名，驱逐低收入社区，将土地转化为高价值房地产，让原住民无处可去。
Marsh Market 居民的“独立”，本质上是被遗弃和被排斥，而非真正的自治。

D. Lynxley 家族

Lynxley 家族是影片中权力精英的完美化身：

窃取创新：气候墙技术本是爬行动物发明，却被 Lynxley 家族占为己有并申请专利。这揭示了资本主义体系中知识产权的暴力本质——谁掌握法律和权力，谁就能将他人的创造合法化为自己的财产。
历史修正：通过控制教育和公共叙事，将自己塑造为“城市建设者”，将爬行动物抹除出历史。
权力世袭：家族财富和影响力代代相传，形成固化的统治阶级。即使是“失意少爷”波伯特，也能轻易调动走私网络和古董资源。

从“我们没什么不同”到“接受彼此的不同”

这种主题转变，暴露了自由多元主义的内在困境。

第一部的乐观：同化的幻觉

第一部的口号“Anyone can be anything”（任何人都能成为任何角色），本质上是一种同化主义叙事。它假设，只要消除偏见，所有个体都能在既有体系中获得平等机会。

朱迪成为警察、尼克“改邪归正”，都是通过适应和融入主流体系实现的。这种叙事忽视了一个根本问题：如果体系本身就是压迫的来源呢？

第二部的妥协：承认差异的代价

续集退而求其次，从“我们没什么不同”转向“接受彼此的不同”。这看似更成熟，实则揭示了深刻的无力感：

生物本性的不可改变：狐狸不懂拥抱、大象害怕老鼠、食草动物的微笑在食肉动物眼中是挑衅。这些设定说明，某些差异是根深蒂固的，无法通过“相互理解”消除。
包容的限度：朱迪和尼克为尊重爬行动物而吃虫子时的痛苦表情，海豹明确拒绝硬币和触碰却仍被无视，都说明真正的跨文化理解极其困难。
妥协的本质：“接受不同”往往意味着弱势群体单方面的适应和牺牲。影片中，是爬行动物在努力融入动物城，而非动物城改变自己以接纳他们。

这种转变，实际上是对多元文化主义作为意识形态的批判。它表明，仅靠“包容”和“尊重”，无法解决结构性不平等。真正的正义，需要对权力关系进行根本性的重新分配，而非仅仅“承认差异”。

Zootopia 命名的反讽

“Zootopia”这个名字本身就是一个精妙的批判工具。

“Zoo”的双重含义

动物园：一个供人类观赏的囚笼，动物被分类、展示、控制。
动物的城市：看似自由，实则被规划、监控、管理。

“Utopia”的虚假承诺

托马斯·莫尔创造“Utopia”一词时，其词源就暗含双重意义：“eu-topia”（好地方）和“ou-topia”（不存在的地方）。Zootopia 正是这样一个“不存在的好地方”——它承诺平等和包容，但这种承诺建立在对某些群体的系统性排斥之上。

“文化大熔炉”神话的破灭

美国一直自诩为“文化大熔炉”，各族裔在此融合为一体。但这种叙事掩盖了残酷的现实：

融合=同化：少数族裔必须放弃自己的文化身份，采纳主流文化。
选择性包容：只有“符合标准”的移民被接纳，其他人被驱逐或边缘化。
持续的隔离：现实中的种族隔离、经济分层从未消失，只是换了更隐蔽的形式。

Zootopia 的表面繁荣，建立在 Marsh Market 的贫困、爬行动物的缺席、Lynxley 家族的垄断之上。这座乌托邦，本质上是一个排他性的特权空间。

影片结尾处，不同族群一起包汉堡的和谐画面，固然温馨，但台词“有领地意识的动物总是忍不住扩张”却道破真相：权力博弈是永恒的，和谐只是暂时的。

童话外衣下的社会学教科书

《疯狂动物城2》用动物寓言的形式，将定居者殖民主义、种族主义城市规划、知识产权暴力等深奥议题，编织进一个看似轻松的冒险故事。

影片最令人不安的地方，不是它揭露了什么，而是它揭露了之后无法给出答案。结尾的和谐画面是脆弱的，因为权力结构未变、经济不平等依旧、空间隔离持续。那句“有领地意识的动物总是忍不住扩张”，是全片最诚实的时刻——它承认，这种冲突可能没有完美的解决方案。

最终，《疯狂动物城2》的价值在于：它提出了正确的问题，即使无法给出激进的答案。它邀请观众思考，而非灌输答案。它承认现实的复杂性，而非贩卖简单的希望。

在一个越来越拒绝复杂性的时代，这本身就是一种激进姿态。

当孩子们长大后重看这部电影，他们会发现，那些曾经让他们欢笑的桥段，实际上是对他们将要面对的世界的预言。而那些没有说出口的答案，正等待他们这一代人去寻找。

作者提示：个人观点，仅供参考

AI 带给了我什么改变？

Tue, 02 Dec 2025 05:33:05 GMT

引言：温和的奇点

过去两年里，我始终觉得自己站在一条奇怪的分界线上：一边是熟悉的老世界，靠经验、人力、流程和项目驱动前行；另一边是一个加速卷动的新世界，AI 正像地下水一样渗入所有缝隙。

我每个季度都会做 AI 的新闻、趋势、产品的分析，每天也会在上下班路上，疯狂地摄入和 AI 有关的播客，这些都是环境使然。

昨天突然看到 Tim 发布的一个视频，开场就是一个让人后背发凉的实验：给出一个指令“画一幅人在深海溺水、努力呼吸的画面”，9 位人类画师耗时一小时完成，而 6 个 AI 模型只用了 15 秒。更残酷的是，AI 生成的画面质量极高，风格多变，甚至可以无限重绘。

这种巨大的反差，让那个困扰我很久的问题变得更加尖锐：AI 到底是浪潮，还是灯塔？当 AI 只需要 15 秒就能取代我一小时的努力，那我存在的意义是什么？它是改变外部世界的工具，还是把我自己重写了一遍的程序？

回过头看，AI 带给我的改变，大概可以拆成三个层次：工作方式的结构性重写、个人能力的指数级放大、以及人生路线的静悄悄偏移。

AI 让我从“任务执行者”变成了“系统架构师”

过去写架构方案是一种“意志力消耗战”。文字、图、结构、细节，每一部分都要从头攀登。

现在的写法更像是“协同工程”：我提出核心框架，AI 做结构延伸；我填入实际业务脉络，AI 补充逻辑链路；我设想风险点，AI 提供替代路径。

一篇原本需要至少三天的文档，现在可能一晚上就能成型。而且质量还更高——因为我可以把更多精力用在概念的打磨，而不是在字句上埋头苦抠。

这种转变的紧迫性，在 Tim 的视频里有一个更残酷的注脚：他们团队曾为了制作《银河列车》的一个特效镜头，花费了整整一年时间。如果按传统流程计算，这需要 5 个专业特效师，干上大半年（约 500 小时）。然而到了 2025 年，AI 模型 Veo3 生成同样的列车穿梭画面，只需要 2 分钟。甚至连音效都给你配好了。

这被称为“努力的悖论”：当我们越努力花时间在纯粹的执行层面，越大规模地投入人力，我们做的事情可能越没有意义，因为 AI 进化的速度远超我们磨练手艺的速度。我们过去挑灯夜读学习的各种软件操作、技巧，在 AI 面前可能瞬间贬值。

简单来说：AI 把我从“执行者”提升成了“结构工程师”。不再只是完成任务，而是在设计体系。

AI 把我的“个人能力”扩展成一支小型团队

如果把人的能力想象成一块主板，那么 AI 就像是随时可挂载的扩展卡。

当我写代码，它变成 Pair Programmer；当我写系统方案，它变成架构师；当我做内容，它变成编辑、脚本师、素材库和灵感源；当我要和财经顾问沟通，它瞬间切换为金融分析师。

这种“随时换职业”的能力，最初带给我的是震惊，后来是依赖，现在则是一种平静——就像我习惯了身边有一支 24 小时待命的“影子团队”。

更重要的是，它让我重新定义了一个词：边界。

以前我会想：“这个我不擅长，我可能做不了。”现在变成：“我先试一下，有 AI 垫着底，总不会差到哪儿去。”

于是我开始尝试以前不敢碰的东西：重构博客、做内容、理解宏观经济、给孩子准备学习路径……我开始在多个领域“通气”，不再害怕跨界。

这不是膨胀，而是一种被悄悄打开的世界。

AI 让我重新塑造了“工作的意义”

这也许是最深刻的改变。

过去很长一段时间，我对工作有一种强烈的异化感：琐碎、分散、被动，像是机器上的一个齿轮。

但是，当我开始使用 AI，我突然意识到：我在把自己从齿轮变成系统设计者。而这种转变，本身就是意义。

当我为公司设计未来两年的系统进化方案时，我其实是用 AI 把那些“想做但做不到”的事情逐步拉回到能力区间内。

当我为孩子设计学习路径时，我在用 AI 把一个父亲的焦虑转换成行动上的笃定。

当我持续写内容时，我在用 AI 把积累变成可复用的知识资产，而不是散落在生活里的临时技能。

换句话说，AI 让我第一次看到：工作和生活中的很多事，原来不是“我不行”，而是“我缺工具”。工具补齐之后，我对世界的参与度被重新激活。

但这种参与度的激活，不仅仅是为了效率，更是为了连接。Tim 在视频里讲述了乐队“深海呼吸”主唱 57 的故事，让我对“工作的意义”有了更深一层的理解。

57 患了重病，听力受损，面临一个成功率只有六七成的手术。他说了一句让我心碎的话：“我其实并不害怕生命提前结束，我害怕的是以后有一天我什么都听不到了。”为了帮他圆梦，团队在他进手术室前拼命赶制《银河列车》的 MV。

虽然手术结果并不完美——没有奇迹发生，他瘦了 30 斤，听力也没有显著改善——但在 MV 发布的那天，57 向爱人求婚成功了。那一刻，视频制作的效率、特效的精细度（那些 AI 能轻易超越的东西）都不重要了。重要的是这个项目承载的人与人之间的羁绊。

工作的意义，不仅在于设计系统、提升效率，更在于通过这些系统，我们能否传递爱与勇气。AI 可以生成完美的画面，但它无法理解 57 求婚时紧张的汗水，也无法复刻那间 60 块钱排练房里梦想的味道。

那么，我们还剩下什么？

如果 AI 真的能做一切，如果它比我们更快、更强、更聪明，我们还剩下什么？

Tim 的视频给了我一个直击灵魂的答案：“可能，只有经历了吧。经历塑造了我们每一个人独特的灵魂。”

当你看到妈妈的白发，你的思绪不会停在这里；当你走进曾经的校园，闻到教室的气味，你的记忆会被瞬间唤醒。这些瞬间的感受、这些独特的生命体验，是 AI 无法计算、无法模拟的。AI 看不透你，因为它没有“经历”过你的人生。

视频最后那个关于“火车”的隐喻非常动人：在 AI 的逻辑里，火车太慢、太笨重、太低效了，远不如光纤和火箭。它们也许无法理解人类为什么会对这种过时的交通工具产生情感。但火车有一点很特别：“即便上车意味着分别，但只要轨道还在，我们还记得彼此，总有一天，我们会再次相遇。”

我每次加班结束开车回家时，也总会喜欢选择鼓楼大街，虽然不如深夜的二环快，但是除了快慢，应该还有你在乎的别的东西。

这让我明白了 AI 革命的另一面：AI 可以是那个呼啸而过的火箭，带我们飞向更高的地方，去探索认知的边界；但我们依然是那个坐在火车窗边的人（开车的人），紧握着身边人的手，感受着心脏的跳动。

效率归 AI，经历归人类。

AI 的价值，从来不是替代，而是升级

它带来了效率，但更带来了方向感；它改变了工作，但更改变了心态；它加速了专业成长，但更重塑了自我认知。

未来怎么样我不知道，但至少此刻，我能清楚地感受到一件事：AI 不是科技潮流，它是一种个人革命。它逼迫我们交出低效的劳动，去换取更珍贵的“经历”与“连接”，而我恰巧正在这场革命的中心。

作者提示：个人观点，仅供参考

关税是什么？为什么川普又对中国加税？

Sun, 27 Apr 2025 09:11:11 GMT

最近和在美国做进出口贸易的朋友聊天，才发现他已经暂停了从中国的进口业务，改为通过转口或从其他国家进口。他的原因很直接：美国又加关税了，利润空间被严重压缩，生意根本做不下去。

受到这事影响，我也赶紧下单了台新 Mac —— 深怕再拖一拖，加税落地，价格上涨，吃亏的还是我们这些消费者。

这也激起了我的好奇心：关税到底是怎么回事？为什么美国总喜欢拿它说事？对我们普通人又有多大影响？

过去几周，我做了一些调研，整理出一篇入门科普，希望能帮大家看懂“关税”背后的逻辑。

一、关税是什么？从“过路费”到地缘武器

1. 什么是关税？

关税（Tariff），本质上是政府对跨境流动的商品征收的税。可以理解为一种现代版的“过路费”或“保护费”。

例如，你从国外买了一双运动鞋，商品进入中国海关时，国家会按照这双鞋的申报价格收一笔税，这就是关税。

2. 它有哪三种主要功能？

作用	说明
财政收入	早期国家重要收入来源，现在对发展中国家仍然重要
贸易保护	提高外国商品价格，保护本国企业和产业
政治博弈工具	加税威胁或制裁他国，比如特朗普时代的“贸易战”

在现代经济体系中，关税已不仅仅是“税”，而是一项综合性的国家政策工具，具有强烈的战略属性。

二、美国与关税：一段剪不断理还乱的历史

1. 关税是美国的“老朋友”

美国建国初期，联邦政府没有征个人所得税，几乎所有财政收入都靠关税。
南北战争的一大诱因，也是南方反对北方制定的高关税政策（保护北方工业，伤害南方农业）。
所以说，美国对关税的依赖，不是特朗普时代才有，而是“祖传的”。

2. 特朗普：用关税“治理国家”

自2018年起，特朗普政府对中国发起了四轮关税行动。
覆盖超过3,600亿美元中国出口商品。
美国对中国商品的平均关税从3.1%提升到21%（来源：Peterson Institute for International Economics, 2020）

3. 他为什么能“说加就加”？

美国的法律给总统提供了很多“单边加税”的武器：

法律条款	允许总统以……为理由加税
301条款	对贸易伙伴实施报复性关税
232条款	以“国家安全”为由加税（如钢铁、铝）
IEEPA法案	紧急情况下，加税、冻结资产、禁运（曾用于打击芬太尼）

三、新一轮关税风暴：只是“川普作秀”吗？

在 2024 年的竞选中，特朗普提出了更激进的加税计划：

对中国商品最高加征 125% 关税
对加拿大、墨西哥等邻国征收 25% 关税，理由是“毒品和非法移民”
提出 全球10%基准关税，只因“其他国家占了便宜”

这些言论固然有“竞选作秀”成分，但也反映出美国正在把“关税”作为国家政策常规工具使用。

四、美国为啥总要加关税？表面 vs 深层逻辑

表面理由（官方说法）

理由	举例
贸易逆差太大	中国对美出口远超美国对中出口
保护制造业就业	促进“制造业回流”
国家安全问题	涉及芯片、稀土、芬太尼等敏感领域

更深层次：美国的“三重困境”

1. 特里芬难题：美元霸权的副作用

美国作为“世界货币发行国”，必须持续输出美元（即从他国买买买），以满足全球美元需求。
这就导致了长期贸易逆差和制造业空心化。

维持美元霸权，必须牺牲制造业 —— 这就是“特里芬难题”。

2. 铁锈带选票与民粹需求

美国中部传统制造业地区长期失业率高、经济停滞。
特朗普的基本盘是这些“铁锈带”的工人阶层。
“对中国加税”能唤起他们的被剥夺感 + 民族主义情绪，是政治操作利器。

3. 财政赤字高企，需要“隐形加税”

美国国债已超34万亿美元（截至2024年末，来源：US Treasury）。
关税不仅是贸易政策，也是一种对国内消费者征税的手段，增加财政收入而不直接加所得税。

五、关税到底有用吗？争议很大

正面观点	反面观点
短期保护制造业	扭曲价格机制，降低资源配置效率
增加政府收入	加重企业和消费者负担
政策博弈工具	破坏全球产业链协作

根据2021年美国国会预算办公室（CBO）报告，上一轮贸易战中，93%的关税成本由美企和美国消费者承担，而非中国出口商。

六、谁在为关税买单？消费者和企业

尽管人民币贬值等因素在短期内可抵消部分关税影响，但长期来看：

美国消费者承担大部分成本，体现在商品价格上涨；
中美企业都要在利润、产能、供应链上做出牺牲；
全球贸易环境变得更不确定，供应链加速“去中国化”。

关税是一种“看起来打别人，实际上打自己和全球市场”的武器。

七、小结

美国不断挥舞关税大棒，表面上是打击对手，实质上是试图用强权手段应对其结构性难题：

美元霸权带来的副作用
产业空心化与民粹化
高赤字、高债务财政失衡

而在这个过程中，中国只是最方便出手的“假想敌”罢了。

未来无论是谁当总统，关税这个工具只会更常用、不会消失，这正是全球“去全球化”和地缘政治分裂的缩影。

附录 | 小白看懂关税、美元体系和美债逻辑

关税术语解释

术语	简单解释
关税	国家对进口商品征税
基准关税	默认适用的标准税率
对等关税	对等回应他国的关税政策

SWIFT 是什么？

全球银行之间安全转账用的“信息系统”。
本身不转钱，只发“指令”。
类比：银行界的“快递物流系统”。

布雷顿森林体系

1944年确立的全球货币制度，美元和黄金挂钩，其他货币跟美元挂钩。
奠定了“美元霸权”的基础。

特里芬难题

世界想用美元，美国就得不断输出美元（买买买）。
但美元太多，会削弱其信用。
是“美元全球化”与“美国自身利益”的矛盾。

美债的全球作用

吸收全球多余美元，是美元信用锚。
提供美国政府低成本融资。
和美元构成闭环：“美元 → 买美债 → 美国再花出去”

如你所见，关税远不是一个“经济问题”这么简单，而是政治、财政、货币、国际秩序交织的节点。

我的2024

Sat, 04 Jan 2025 09:18:33 GMT

今天是2025年第一个周六，在公司加班。白天一直在写团队2024总结，晚上终于有时间盘点下2024自己都做了啥。安静下来想想，现在的我会对2025年的自己说些什么？

此时此刻，脑子里突然想起一句罗曼罗兰著名的话：

世界上只有一种真正的英雄主义，那就是认清生活的真相后依然热爱生活。

这句话对人到中年的我来说，确实有一些不一样的意义：看似伟大，但实际平凡。首先什么是「生活」，每个人所经历和能经历的生活是截然不同。站在2025年初，我可能想对未来的自己说：提升自己可以选择「过什么样生活」的权利，大环境的问题下，更要拓宽自己的能力边界，给未来更多的可能性。

旅行

今年去了国内和国外的一些地方，体会了不同的风土人情。见了久违的在杭州的故友，促膝长谈了2天。

2月-旅行：福州 → 泉州 → 厦门

福州：赶在麦当当Close前，买了年夜饭，才不至于在年三十儿啃泡面

泉州：半城烟火半城仙，几百米一座庙，让你能感受到住在这里的安逸和祥和，没什么事情是这么多神仙无法解决的。。。

厦门：去了很多次的地方，非常典型的海边城市，这次著名的景点一个没去，就是随意逛逛

3月-异地见故友：杭州

飞去杭州见了很久没见面的朋友，聊了很多过去，也聊了很多现在。有个感受，异地的情况，想见一面基本需要进行年度规划

5月-旅行：宁波

东钱湖：景色很美，之前去过泸沽湖，各有千秋吧

宁波博物馆：主要是因为「三体」的取景地，打个卡

7月-旅行：格鲁吉亚

飞了好久好久：北京 → 乌鲁木齐 → 第比利斯（格鲁吉亚首都），十几个小时了

朴素的民风 + 欧洲的风格 + 亚洲的价格：格鲁吉亚的人很好，旅游业目前还不是特别发达，所以东西不贵，也没有宰客现象。我的导游是本地人，英语+中文+格鲁吉亚语+俄语，想怎么沟通都OK

推荐几个地方：第比利斯citywalk + 卡兹别克 + 巴统（黑海），各种教堂确实记不住…

9月-旅行：阿那亚金山岭

和朋友一家一起去的，路程不远（北京过去的话150公里）。全程宠物友好，整体社区确实很阿那亚。值得喜欢宠物的朋友，一起聚会的地方

11月-音乐剧：《我，堂吉诃德》

带孩子第一次看现场音乐剧。之前一直没系统看过《堂吉诃德》，但是也是知道故事主题脉络的，看了整个剧，还是挺感动的，重新理解了理想主义，以及如何追求理想主义追梦

工作

变化有限，我和团队都在努力搬着砖，完成各种交付。但是2025年，需要保持独立思考，聚焦一些重要目标。

输入和输出

输入

今年调整了一些信息输入的工具，目前工具如下

Follow

碾压之前的一切RSS工具，现在唯一的RSS + Newsletter工具

Cubox

一直以来的碎片整理，稍后读工具

小宇宙

全年听了138小时，主要2个播客是离不开的

虚实之间

听过最好的播客，没有之一，高质量、高认知，2023-10月开播以来，每集都必听。

小宇宙-虚实之间

全年69小时

声动早咖啡

每个工作日早上通勤15分钟，可以了解世界的科技商业新闻，与时俱进。

小宇宙-声动早咖啡

全年47小时

微信读书 + 纸质书

《张居正》

历史小说。张居正是个牛人，他在万历年间推行了一系列改革，比如整顿税收、削减冗官，但过程特别艰难。书里还写了他如何在复杂的政治斗争中周旋。看完你会感叹：历史里的“改革者”有多难当。

《小王子》

每一段旅程都像是一面镜子，让人反思友情、爱和成长。表面是童话，实则讲的是人生哲理。

《重来-跳出疯狂的忙碌》

37signals 的创始人撰写，提出了一种反主流的工作和创业理念，强调减少忙碌、关注核心目标以及更高效地完成工作。一定要独立思考。

《我与地坛》

散文。这个地方成了史铁生思考人生的一个舞台。他写自己对死亡、母爱和生命意义的感悟，文字朴实却很触动人心。里面很多地坛的景色描写，我觉得孩子可以好好积累下，作文素材。

《撒哈拉的故事》

三毛和她丈夫荷西住在撒哈拉沙漠，虽然生活条件很艰苦，但他们过得特别浪漫。书里记录了她遇到的趣事、奇人以及对生命的热爱，读起来很轻松，但又有深意。后面我还特意去小红书搜了搜故居的样子，看了后更加代入。

《芯片简史》

AIGC大发展之年。我偶然读到这本。读的过程中想起了自己大学时代各种课程和课程设计。这本书从最初的晶体管，到如今的芯片如何影响全球科技发展，作者写得特别清晰，看完你会对科技背后的故事刮目相看。

《置身事内》

如果你对经济感兴趣，但总觉得太复杂，这本书超适合你。它用很接地气的语言解释中国经济是怎么运行的，告诉你“体制内”和“体制外”的那些事儿。读完，你会更懂咱们国家的经济逻辑。

《智人之上》

赫拉利的新作。这本书探讨了未来人工智能、生物科技的发展会如何改变人类。作者还反思了技术进步带来的挑战：我们是变得更幸福了，还是失去了什么重要的东西？

得到

学习两门历史课程，分别是：施展老师的「中国史纲」，以及李筠老师的「西方史纲」。个人兴趣，非常喜欢“大历史”，这2门课讲的非常好，适合喜欢“大历史”，以及历史贯通感的同学，推荐。

多邻国

一直坚持学习英语，又是365天，但是为了之后能有其他的选择，英语的学习打算在2025年加大力度。目标是：达到可以去英语国家工作和生活的标准（其实差距很大还是，总得有个目标）。

加油！给自己，也给家庭一些不一样的生活的可能性（卷孩子不如卷自己，卷孩子现在确实没啥性价比）

输出

Notion

主力日常输出工具是，负责整理想法，日常的工作和个人学习管理。

Blog

今年年底，因为黑五，薅到了便宜的VPS（https://cloudcone.com/）。冲动消费后，VPS不能闲着啊，于是把Blog从Vercel的静态Blog迁移到了VPS上的WordPress的动态Blog。

Blog今年才写了6篇，平均2个月1篇，明年加油。

适合工程师的免费画图工具

Thu, 19 Dec 2024 09:21:51 GMT

最近接近年底，又到了一年一度系统性规划的时间。这时候确实少不了画图工具，所谓一图胜千言。从设计架构到制作流程图，甚至是在会议中唬人，总得需要几张「神图」撑场面。但是，谁说画图一定要花钱呢？能白嫖的肯定不花钱啊！今天推荐几款我常用的免费画图工具。

Excalidraw – 手绘感满满的创意之选

http://excalidraw.com

如果你觉得那些一本正经的图表太死板，那就来试试Excalidraw吧！它的手绘风格一上来就能给你一种「我是艺术家」的错觉，就像是让毕加索来画你的系统架构图一样！

特点

支持协同编辑
提供了素材库（按需添加）
端到端加密，完全不存储用户数据

Mermaid – 码农福音，语法驱动

https://mermaid.js.org

厌倦了拖拖拽拽？Mermaid让你用写代码的方式来画图！这简直就是程序员的终极浪漫。当你用代码画出一个漂亮的流程图时，那种成就感简直比修复一个bug还爽！

特点

用代码生成图表，极客范十足（有了AIGC简直是提效神器）
类型丰富，从流程图到甘特图，甚至时序图，应有尽有
可以集成到各种markdown编辑器

Drawio – 全能

https://www.drawio.com

如果说Excalidraw是可爱的邻家小妹，Mermaid是极客码农，那Drawio就是学霸了，几乎能胜任你能想到的所有画图需求，功能强大，以免费和丰富的功能著称。

特点

具备接近商业软件的功能，且完全免费
提供桌面版和在线版
支持多种存储方式（Google Drive、OneDrive）
丰富的模板库，还可以自定义自己的库

Frame0 – 手绘风格的原型设计工具

https://frame0.app

一款非常适合程序员快速验证想法的原型设计工具，轻松描绘应用程序创意，项目从2024-09开始创建，陆续更新了7个版本，目前版本还是beta，适合喜欢新鲜感和尝鲜的同学。

特点

跨平台，支持macOS、Windows、Linux
流畅的操作体验
适合制作精美的展示图表
支持实时协作

如何通过云计算为客户提供服务

Sun, 24 Nov 2024 09:52:09 GMT

最近在给公司的市场部同学提供一些系统的技术类描述的输出。我在选题的时候也考虑了再三，突然想到了「AI」「云计算」此类词汇的走红，但是应该大部分人对所谓的技术网红词都一知半解，反正不提好像就是OUT了。因为我们是一个SaaS服务商，所以从云计算的角度去写一写，做一些云计算的科普好像是一个不错的输出方向。

定义

云计算是一种通过互联网提供计算资源（如服务器、存储、数据库、网络、软件等）的技术，它允许用户按需访问和使用这些资源，而无需在本地购买和维护硬件和软件。云计算的核心理念是将计算资源集中起来，通过网络将这些资源以服务的形式提供给用户。

服务模式

云计算包含了3种服务模式，由底层到上层依次为IaaS → PaaS → SaaS

部署方式

云计算常见的部署方式有3种，分别是：公有云、私有云、混合云

[我们目前的部署方式] 公有云（Public Cloud）

云服务商提供（例如：阿里云、华为云、AWS、Microsoft Azure）

优点：具备成本效益、可扩展性、灵活性、良好的高可用性，以及良好的安全性（网络安全和数据安全）
缺点：比较依赖第三方的云服务商；对于某些敏感信息（如：涉及国家安全信息等）可能不是最佳选择

私有云（Private Cloud）

为单个组织专门构建的云环境，可以在组织内部或第三方数据中心中托管，提供更高的安全性（当企业和产品发展到一定阶段后，通常使用此类部署方式的是对安全要求较高的KA客户）

优点：数据安全性和隐私保护得到了加强
缺点：一定程度上牺牲了公有云的扩展性和灵活性；成本（服务器成本和运维人员成本）高昂

混合云（Hybrid Cloud）

如果希望利用公有云的扩缩能力和安全性，同时将数据保留在本地以遵守数据驻留法律的规定，或支持更接近客户的计算需求，则混合云方式会比较适合。

优点：结合了公有云和私有云的大部分优点，可以在需要时轻松扩展计算资源和存储空间，同时仍可以在本地访问数据和应用
缺点：管理复杂、需要专门的VPN或专线连接公有云和私有云、网络传输速度和稳定性都要求很高

IaaS层

主要利用阿里云的提供的网络、存储相关基础设施，构建我们的SaaS基础

PaaS层

非应用类

主要利用阿里云提供的开发平台和环境，构建和部署我们的应用服务，比如：容器服务、无服务器计算等

应用类

视频会议能力
文档协作能力
直播能力
AIGC
……

SaaS层

通过SaaS层为我们的用户提供服务

SaaS的好处

成本效益：用户无需购买昂贵的硬件或软件许可，只需按需付费
快速部署：用户只需注册账户即可开始使用，减少了传统软件安装和配置所需的时间
易于扩展：用户可以根据需求增加或减少使用的功能模块
自动更新和维护：SaaS提供商负责软件的更新和维护，用户始终使用最新版本，无需担心升级和安全补丁
访问便利：用户可以通过任何连接互联网的设备访问SaaS服务，支持远程工作和移动办公，提高了工作灵活性
安全性：SaaS提供商非常重视安全措施，包括数据加密、备份和灾难恢复，通常比中小型企业自行管理的安全措施更为可靠

消费降级，我的订阅服务瘦身

Sun, 01 Sep 2024 10:01:31 GMT

随着各种软件、服务的使用增多，也发现了我每个月会收到很多订阅缴费的Email。最近一段时间梳理了一下自己现在的互联网软件的订阅服务，发现了很多可以「省钱」的地方。

腾讯视频

分类	周期及成本	需要程度
视频内容	168元/年	看内容，选任意平台即可

之前唯一订阅的视频服务，主要是因为在追动漫（来源于少年时代看网络小说，现在动漫都是网络小说改编的居多），腾讯视频的动漫IP确实比大部分平台要多一些。主要在追的如下

斗罗大陆
斗破苍穹
吞噬星空
诛仙
神印王座

小米影视会员 + 赠送的爱奇艺会员

分类	周期及成本	需要程度
视频内容	392元/年	有了更好

主要是因为家里的小米电视，孩子有看的需求。

Apple Music

分类	周期及成本	需要程度
音乐	11元/月	有了更好

疫情期间买新设备赠送的3个月免费，那会开始续订的，主要原因我是苹果全家桶，体验比较顺畅。我一般是在开车通勤的路上，在公司coding的过程中，会听一听怀旧歌曲。

帆书（原樊登读书）

分类	周期及成本	需要程度
知识付费	365元/年	不需要/不续订

听了4年了，前2年大量地听，因为平台内很多书没有听过，经过2年，几乎听完了平台内大部分书，暂时不打算续订了，目前更多的信息输入是纸质书和电子书。

声动胡同

分类	周期及成本	需要程度
知识付费	365元/年	不需要/不续订

我每天早上会固定收听「声动早咖啡」，15分钟左右的时间，可以了解国内外科技相关信息。而且非常喜欢这个团队输出的内容质量，年轻、有活力、专业。所以，加以粉丝心态，加入了声动胡同。目前加入会员后，有几档收费播客可以收听（不止金钱、跳进兔子洞），但是就ROI来讲，还是性价比不高的。希望当我要续订下一年的时候，这个团队能给我更多的「理由」续费。就目前来讲，不是很推荐和需要。

微信读书

分类	周期及成本	需要程度
知识付费	19元/月	需要/续订

今年使用了「微信读书」代替了我之前的Apple Books + ZLibaray的白嫖方案。

主要原因有2个

笔记可以统一管理，也可以导出，比较方便
听书功能体验很好，在开车通勤的路上，使用起来很方便

AgentNEO（科学上网）

分类	周期及成本	需要程度
网络服务	240元/年	需要/续订

刚需，懂得都懂。

Blog维护费用

分类	周期及成本	需要程度
域名	156元/年	需要/续订

目前我的Blog花费只是在域名购买上（Godaddy），其余的都是Free。

类别	服务	花费
代码托管	Github（Hugo框架）	Free
部署托管	Vercel（Git Commit自动触发）	Free
图床	https://sm.ms	Free（5GB）
CDN加速	Cloudflare	Free
域名购买	Godaddy	156元/年

多邻国（家庭套餐）

分类	周期及成本	需要程度
学习	0元/年	需要/续订

学语言的利器，白嫖了朋友的家庭套餐。。。，不过也可以从小红书等渠道去找拼团，也比较实惠，千万不要自己一个人购买，太贵了。

Cubox-Pro

分类	周期及成本	需要程度
碎片信息收集	98元/年	需要/续订

我的信息输入流，一般来自于3类

书籍（纸质或电子）
订阅的RSS
关注的公众号
其他社交APP等

对于上面除了书籍外，有很多信息当时看了一遍，觉得不错，或者可以继续深入阅读，或者收藏，我会加入到我的Cubox里面，在写Blog、写规划、思考某类问题时，会进行相关标签的搜索，进行信息的二次加工，所以Cubox对我来讲，还是必须品。

iCloud

分类	周期及成本	需要程度
云存储	21元/月（200G）	不需要/不续订

iCloud确实在多设备照片和文件同步很方便，但是当我的iCloud大小超过了200G的时候，这个选项就没有性价比了。200G是每月21元，下一个档位是2TB，每月68元，一年800+，着实有点肉疼。经过一番调研，最终选择了NAS方案，彻底解决设备文件同步和备份的问题，从此省取了每年800+的费用。当然，对NAS的首次投资肯定是大于800的，还是需要看长期成本递减。NAS当时在极空间和绿联之间二选一，最终选择了绿联DX4600+，配了8TB硬盘。买了2个月后，绿联新款NAS开始出现软件质量问题，被用户声讨，索性的是老版的软件比较稳定，至今体验还不错。

Todoist

分类	周期及成本	需要程度
效率工具	30元/月	不需要/不续订

不是深度任务使用者，在订阅了6个月左右后，觉得性价比对我来讲不高。最终用Notion的ToDo List模板，替换掉了Todoist。

图图记账

分类	周期及成本	需要程度
效率工具	8元/月	不需要/不续订

我是一个有着洁癖的程序猿，所以无论是Coding还是写文档，或者是生活中的信息流等等，都希望可以数据化，通过可视化分析，找到一些所谓的「成就感」。图图记账是在「少数派」的推荐下开始使用的，基本使用了6个月后，发现一个很麻烦的问题，记账不及时，而且有一个很大的问题是，有些财务的隐私信息，不是很敢在互联网产品内记录，所以，基于及时性和隐私性，最终弃用。

使用了开源解决方案beancount替换，记账周期基本是按照季度进行。原始流水从微信和支付导出Excel，然后通过Python脚本简单处理下，自动生成beancount的格式文本，经过微调就可以了，最终效果如下。

Sam Club 卓越会员

分类	周期及成本	需要程度
购物	680元/年	需要/续订

人到中年，发现可以把逛超市当做是娱乐活动之一，我和老婆都很喜欢逛山姆。山姆的品质确实是一流的，再加上山姆目前在北京有1小时极速达，非常爽，家里缺什么下了单，不到1小时就送到了。卓越会员是消费返利的，返利是在下个月的消费可以使用的，所以其实加上返利的钱，总体是不亏的，和200+的普通会员没啥差距。

[播客] 声动早咖啡

[播客] 虚实之间

[AIGC] 302.ai

[RSS] RSS订阅Blog的Feed是我获取高质量信息的一个非常主要的渠道，有需要的可以加我联系方式，我发你啊

优化完后，从每年3200下到每年2100（依然很贵），后面考虑把家里的NAS的功能充分发挥出来，没准可以替换掉更多的收费订阅服务。

AIGC应用探索分享

Sun, 21 Jan 2024 10:19:36 GMT

生成式人工智能（Artificial Intelligence Generated Content）

定义

百度百科

生成式人工智能AIGC（Artificial Intelligence Generated Content）是人工智能1.0时代进入2.0时代的重要标志。

GAN、CLIP、Transformer、Diffusion、预训练模型、多模态技术、生成算法等技术的累积融合，催生了AIGC的爆发。算法不断迭代创新、预训练模型引发AIGC技术能力质变，多模态推动AIGC内容多边形，使得AIGC具有更通用和更强的基础能力。

AIGC对于人类社会、人工智能的意义是里程碑式的。短期来看AIGC改变了基础的生产力工具，中期来看会改变社会的生产关系，长期来看促使整个社会生产力发生质的突破，在这样的生产力工具、生产关系、生产力变革中，生产要素——数据价值被极度放大。

基础的生成算法模型不断突破创新。
预训练模型引发了AIGC技术能力的质变。
多模态技术推动了AIGC的内容多样性，让AIGC具有了更通用的能力。

生产力、生产关系、生产资料的变化

生态体系

基础模型

国外主要的AIGC预训练模型

场景和应用

Tool AI
AI工具箱
AI导航

国外AIGC应用

国内AIGC应用

通用类场景应用示例

ChatGPT

ChatPDF

ChatPDF可以将200页以内的pdf文档拖入，ChatPDF马上就自己“读懂”了整个文章的内容。首先它能够生成一个摘要大致总结文档的要点，然后用户可以在对话框进一步追问更多问题，ChatPDF能根据文档内容进行回答。

我周末在帮我儿子复习，把总结的数学错题PDF输入给了ChatPDF，右侧是他的回答，准确率还不错。

腾讯混元助手

可以在微信小程序搜索「腾讯混元助手」

集成了聊天 / 绘画 / 编程等多场景

通义听语

可以在微信小程序搜索「通义听语」

音频转写类，可以实时记录语音，同步实时翻译，智能总结等等

文心一言

在APP「文心一言」

集成了聊天 / 绘画 / 编程等多场景

Runway

https://runwayml.com

hotoke.ai

hotoke.ai是一个日本开发者开发的基于ChatGPT 的佛祖平台，已为百万人排忧解难。

我问了大家经常会在迷茫的时候思考的问题：「人生的意义是什么」

学习场景应用示例

多邻国

一个流行的免费语言学习应用，通过游戏化的方式帮助用户学习新的语言。（我本人一直使用，体验非常好）

美国版本新增了GPT-4功能：Max。

主要提供了基于GPT-4模型的2大功能：Explain My Answer 和 Roleplay。

Explain My Answer

这个功能的主要目的是让学生在练习时不仅能了解他们答案的正确性或错误性，而且还能够深入了解他们的答案背后的原因。无论答案是正确还是错误的，学生都可以与虚拟助手交流，获得关于为什么他们的答案是对还是错的简要解释，并询问示例或进一步的澄清。这有助于学生更好地理解并纠正他们的错误，从而提升学习效果。

Roleplay

该功能允许学生在应用程序中与虚拟角色进行真实世界对话技能的练习。学生可以通过点击角色来访问，完成挑战可以获得经验值（XP）。在这些挑战中，学生将与虚拟角色进行不同情景下的对话练习。应用程序会引导学生探讨不同的情境，比如与角色Lin讨论未来的度假计划，或者在巴黎的咖啡馆点咖啡，或者与角色Eddy一起购买家具，或者邀请朋友一起去远足。这些练习有助于学生在不同情景下练习语言交流能力，从而提高他们的语言技能水平。

网易有道（AI口语老师）

和多邻国提供的roleplay场景类似，模拟各种对话场景，但是体验很一般。

API技术文档

可以进行小程序体验

Grammarly

写作辅助工具，可以提升作文写作能力

Khanmigo

Khanmigo基于GPT-4等模型开发了个性化学习工具，比如“辅导我”模式和针对不同科目的测验模块。对于K12主题的问题回答最准确，但对于小众主题则不太准确。

Quizlet（Q-Chat）

ChatGPT的AI家教Q-Chat。它是一个在线学习平台，提供各种互动学习工具，帮助孩子们理解和记忆知识。Q-Chat，作为其最新的功能，就像一个个性化的AI导师，根据每个学生的学习风格和进度，提供帮助。Q-Chat能通过提出问题和孩子进行有深度的对话，无论他们正在学习什么。它使用基于问题的苏格拉底式教学法，激发孩子的主动学习欲望，帮助他们深入理解知识。

Youtube介绍视频：https://www.youtube.com/watch?v=VLUGMzbJ3_M

MathGPT（未发布）

MathGPT以讲题、解题、算法等为核心，既能随机生成数学题，也能系统自动给出答案，其支持中英文，并可在移动端和PC端体验。

就目前数据而言，MathGPT能够覆盖高中、初中、小学等数学内容，代数题、应用题、计算题等，相关数学题目都可通过MathGPT来找到相应的答案，解题思路与逻辑也更加清晰明了。

适应变化，拥抱AIGC，学会使用AIGC工具，结合自己的工作和生活，让AIGC帮助我们变得更好

聊天对话类的助手：可以帮忙高效查资料、总结归纳（有条件的用国外ChatGPT，没有条件的可以用腾讯、百度、阿里的）
图片、视频类助手：可以通过Midjourney、Runway等工具，加速海报、对外文案的输出
编程助手：通过Github Copilot、Bito等助手，加速编码

我的2023

Sun, 07 Jan 2024 01:44:56 GMT

年底有点忙，忙着产品大版本上线发布，忙着给孩子做期末复习等等。到了7号才整理了自己的2023。从生活、工作、阅读和写作3个方面整理。

生活

2023年生活上最大的变化就是，家里多了一个新成员，一只可爱的狗狗（小儿子），叫咖啡豆的泰迪熊。于是我的家庭组成变成了：我、老婆、大儿子（娃）、小儿子（咖啡豆）。每次回家开门，娃和狗子，一起扑向你的快乐（有时候还挂在你身上），是我每天最期待的时刻，给我的工作和生活做了减压的催化剂。

另外，2023还过了有史以来最贵的十一黄金周（十一医院深度游）。儿子在9月底确诊了支原体肺炎，快速发展到重度的情况，经历了紧张的找医院住院的过程，最终住进了「新世纪儿童医院」，经过12天的治疗（2次洗肺），顺利出院。最大的感受就是：

看病好贵
医疗资源紧缺
传染病在新冠后怎么TMD这么厉害
必须上高端医疗险（11月立马补了友邦的）

2023的旅行不多，先后去了三亚、广西、长白山、延吉。都说读万卷书，不如行万里路。在这个看似不太好的时代，不要过度卷工作和学习，抽些时间出去看看世界，从另外一个角度去学习和认知这个世界，旅行确实可以让自己内心更加平静、缓解焦虑。

2023在习惯上，一共写了5篇，平均2个多月一篇。到了年底，实在为自己的懒惰而羞愧。写的少主要还是，对工作和技术积累的总结和整理偏少，所以，可以分享的内容不多，明年加油，争取每月1篇。

写给自己

回顾自己的生活，不是坐在屏幕前写代码、写方案，就是在陪娃、遛狗，偶尔看看世界，中年人的生活状态好像一览无余，全部命中。虽然好像缺少了热情和梦想，但是总体来讲，我不是特别焦虑（有时候会有一点），物欲不高，没啥外债，做着自己选择并打拼了十几年的行业，公司氛围很好，老板很Nice，还有时间陪家人，还是挺好的。

希望2024自己可以继续多多读书，多出去走走，好好陪家人，在人生的道路上继续修行，活的真实，遵从内心，顺其自然，随遇而安。

AI编码助手

Fri, 21 Jul 2023 01:44:56 GMT

为什么需要使用AI编码助手

提高编码效率，适应新时代的编程方式

大模型时代，正在催生“超级个体”。这些超级个体效率极高，熟练使用各种工具，快速交付业务价值。
工具使用前提，都需要「科学上网」，这个是没有办法的
使用过程中，请注意信息安全，密钥、重要代码，不要进行复制询问

工具使用介绍

Bito（官网：Bito）

个人版（免费）

介绍

Bito AI是一个通用AI助手，开发者可以向它提出任何技术问题，它可以从自然语言提示中生成代码，也可以对现有代码提供反馈，主要功能如下：

生成代码：用户可以用自然语言向Bito提出需求，Bito可以自动生成不同语言的代码实现（如Java）。
命令语法：用户可以询问任何技术命令的语法和用法（如git）。
测试用例：Bito可以为给定的代码自动生成测试用例。
解释代码：Bito可以解释选中的代码片段的作用和实现原理。
注释方法：Bito可以为函数或方法自动生成注释，补充到用户的代码中。
改进性能：用户可以询问如何优化给定代码的性能。
检查安全：检查代码是否存在已知的安全问题。
学习技术概念：用户可以问Bito任何技术概念的相关问题（如B+树），Bito可以解释清楚。

安装

使用

Youtube视频
- https://www.youtube.com/@bitoai/featured
- https://www.youtube.com/watch?v=q42hqwT-jsg
文档介绍
- https://docs.bito.ai/getting-started/bito-ai-examples

Github Copilot（官网：Copilot）

个人版（$10 / Month），可以有传送门（私信我）

介绍

GitHub Copilot为开发者提供了非常有价值的代码自动完成与生成功能。它可以根据代码中生成代码行或整个函数。通过智能代码自动完成和生成，GitHub Copilot可以提升开发效率，降低开发难度。它的出现将进一步推动AI在软件开发中的应用，使开发者从代码编写的繁琐工作中解放出来,，更专注于设计与算法。

安装

IDEA插件
VS Code插件
- Copilot
- Copilot Labs（对话助手）

使用

https://docs.github.com/zh/copilot/quickstart

Codeium（官网：Codeium）

个人版（免费），VS Code体验较好，IDEA差一些

介绍

Codeium是一个利用AI进行代码自动生成的平台，主要功能包括：

代码生成：用户可以通过自然语言描述需求，Codeium可以自动生成对应的代码实现。支持多种编程语言，如Java、Python、JavaScript等。
代码搜索：用户可以通过关键词搜索代码段，Codeium可以从海量代码库中找到相关的代码示例。
代码解释：用户可以选择一段代码，Codeium可以用自然语言对其进行解释，帮助用户更好地理解代码逻辑。
代码优化：用户可以让Codeium分析已有代码，给出代码质量优化、算法优化等方面的建议。
代码编辑：Codeium内置智能代码编辑器，可以提供代码自动完成、语法检查、格式化等功能。

安装

使用

https://codeium.com/chat

建议方案

个人使用感受

Bito

非常强大助手类工具。默认模板功能很好用，可以方便在对话中插入代码。然后询问针对代码的问题。IDEA和VS Code的插件使用体验都不错。

Github Copilot

理解代码上下文很厉害（用的越多，越理解你），可以快速补全代码。常规的工具和算法的方法，可以依赖直接生成的代码进行开发。

Codeium

代码补全能力一般，在IDEA下插件体验不是很好，在VS Code下，体验还不错，功能其实和Bito有些类似

使用IDEA

Bito + Github Copilot（如果有预算）

使用VS Code

Bito + Codeium（如果有预算，可以换成Github Copilot）

如何处理「线上问题」

Fri, 28 Apr 2023 01:44:56 GMT

什么是「线上问题」

从产品开发周期上来讲，「线上问题」发生在产品发布后。

「线上问题」指提供给用户的服务全部或部分不可用、服务性能低、用户吓验不好等。在产品前期阶段，为了抢占市场先机，产品新功能的发布速度追求往往优先于其质量，埋下了很多技术债务，部分技术债务的爆发会引起「线上问题」，造成客户满意度下降，甚至是直接经济损失。

「线上问题」流程概览

发现 -> 处理 -> 总结 -> 反馈

严重程度

严重程度	描述	处理方式
致命	最高级别，系统或服务完全停止或无法使用	立即采取紧急措施进行解决
严重	次高级别，系统或服务部分停止或使用受限	尽快地采取措施进行解决
一般	一般级别，系统或服务的使用没有明显的影响	但需要在合理的时间内进行处理，以防发展成更高级别的故障
轻微	最低级别，不影响系统或服务使用的小问题或异常	日常维护过程中逐步处理

处理流程

用户反馈 & 监控告警

值班策略

每周轮换：每周一上午10点，会在钉群推送本周值班的人员，如下图

错误分析报告

每天会进行日志分析，向钉钉服务告警群推送 日志错误分类报告

值班RD每天下班前，针对报告进行分析，如果判断为线上问题，报告给QA进行登记

复盘报告

故障复盘报告（致命）

双周复盘报告（整体）

如何理解「用户故事」

Sun, 05 Mar 2023 01:44:56 GMT

什么是用户故事

用户故事是一个简短而简单的功能描述，它为用户或客户带来价值，并且团队可以在迭代中交付这些功能。

用户故事应该回答三个问题:

我们为谁实现它?——期望<用户>的类型
我们实现的是什么功能?——我希望<功能>
我们为什么要实现它?——<价值，和好处>

所以，用户故事的典型格式是:

作为一个<某种类型用户>，我想要<功能或场景>，以便<得到价值或好处>。

As a , I want to , so that .

例如：作为注册用户，我希望能够将我的照片下载到我的个人资料中，以便其他用户可以看到我的样子。

如何编写用户故事

层级结构

准则

根据INVEST准则，用户故事应为：

独立 Independent
- 不依赖其他故事（这条其实，在现实中，很难实现，因为的确有一些故事依赖前置故事）。
可协商 Negotiable
- 并非一成不变，可以进行讨论。
有价值 Valuable
- 用户故事必须对业务具有明确且可量化的价值。这意味着重构、代码清理、架构设计等这类技术实践不是故事。同时这也意味着故事是一个垂直切片，它不可能是一个单独的前端或后端的任务。
可估计的 Estimable
- 足够清晰，交付团队可以很好地知道它有多大。
足够小 Small
- 用户故事应该不大于一到两个开发人员在一个迭代中实现的工作量。
可测试 Testing
- 用户故事必须对业务具有明确且可量化的价值。这意味着重构、代码清理、架构设计等这类技术实践不是故事。
有价值 Testing

我们使用的用户故事模板

故事编写FAQ

Q1:故事是否可以针对不同的端，进行拆分？

A1:如果故事本身涉及到了2个端（即移动端和PC端），如果2个端的故事点较大，且FE为不同的人，可以针对不同的端，进行故事的拆分。

Q1:故事点如果特别大，是否进行拆分？

A1:故事是否拆分的标准是，是否可以交付「用户可见的价值」，和故事点本身无直接关系。

如何进行故事点估算

什么是故事点

故事点是对一个故事的难度和工作量的估计，说白了就是一件工作的工作量的度量。故事点的估计值不是承诺，跟实际完成时间没有直接关系。

故事点的「通货膨胀」

代码质量、开发人员水平、对业务熟悉程度，都会影响交付速度，但是当不同的开发人员，进行故事点估算时，如果以完成时间为标准，就会完成每个人的故事点估算是完全不一样的，这就引起了「通货膨胀」。

计划扑克估算

参考：计划扑克

计划扑克

Thu, 02 Mar 2023 01:44:56 GMT

什么是计划扑克

一种基于共识的估算方式（游戏），主要用于估算Scrum迭代中的开发任务的工作量问题，通过团队的共同的评估方式，使得偏差变得相对较小。

实施步骤

角色说明

参与角色	说明
Scrum Master（QA）	主持整体估算流程
PM	对故事进行解释和描述
RD / FE	进行估算的开发人员
RD TL / FE TL	故事点合理性裁判

Round 1

1.「PM」进行Story的描述和讲解
2.「RD / FE」通过面朝下的方式打出编号卡，Scrum Master宣布翻牌，同时翻开牌面（斐波那契值：1，2，3，5，8，13，20，40）
3.解释估算偏差，并讨论
4.估算共识达成

Round 2

1.针对不一样的故事点，「RD / FE」解释估算偏差，并达成共识
2.Scrum Master把最终故事点写到故事列表中
3.全体参与优先级的排序，并填写到故事列表中

斐波纳契序列和计划扑克

计划扑克使用Fibonacci序列作为Story Point。Fibonacci序列是13世纪引入的数学系列数字，用于解释自然的某些形成方面，例如树的分支。通过将前两个数字相加来生成序列，以获得序列中的下一个值：0、1/2、1、2、3、5、8、13、20等。出于敏捷估计的目的，一些数字已经改变，导致以下系列：1、2、3、5、8、13、20、40、100，如下图所示：

点数约定：1 Story Point 约等于理想情况下 1人/天（按照团队研发人员的平均水平估算）

牌	解释
0	不需要工作量
?	无法估计
其他	按照字面意思理解点数

作为研发Leader，如何做迭代管理

Tue, 07 Feb 2023 01:44:56 GMT

写在前面

「迭代流程管理」在每个公司的情况都不一样，随着产品发展阶段、团队规模、资源情况等变化，会进行各种实践和优化。我的团队一般会以半年为单位，进行迭代管理流程的Review，进行相关的流程调整和优化。

以下是我的团队在2023年初，刚刚优化过的迭代流程。

迭代管理在解决什么问题

上图中，共分为3个阶段，其中「产品开发」这个阶段，是下文中描述的「迭代流程」部分。

开发过程方法论

原则和框架

说明：在整体迭代阶段上，我们采用类似「瀑布」方式进行了大阶段的拆分；

在需求的理解、交付上，我们采用「敏捷」方式，以故事的粒度进行交付和验收。

遵循的原则

以「人的主观能动性」为核心，高效、高质量交付更有价值的产品，让团队成员成为更好的自己

使用的框架

Scrum + Kanban

敏捷（Agile）的目标是为了：帮助我们尽早了解我们到底有多糟糕，尽早管理这种局面。

流程概览

角色说明

角色	职责
Scrum Master	敏捷教练，推动迭代的进行，目前QA兼任
PM	产品经理，进行PRD的输出和讲解
RD	服务端工程师，负责后端代码实现
FE	前端工程师，负责前端代码实现
QA	测试工程师，负责迭代质量
UI	UI设计师，负责交互和界面设计

详细说明

需求阶段

启动会 Kick Off Meeting

会议目标： 顾名思义，开球。主要是传达产品价值，以及为什么要做，和本次迭代的目标，不会深入产品细节和原型细节等。

参加人员： 全体

相关动作

「PM」→ 输出PRD中的产品价值
「Master」→ 在 项目管理平台 创建迭代版本
「Master」→ 在 沟通工具 创建沟通群

需求影响分析会 Impact Analysis Meeting

会议目标： 熟悉系统现有功能，分析本次迭代变动的影响

参加人员： RD、FE、QA

相关动作

「RD 或 FE」→ 讲解系统现有功能，分析影响

需求评审会 PRD Review Meeting

会议目标： 讨论需求、实现逻辑和规则细节，达成整体团队对于本次需求理解的共识（会议次数原则上不应不超过2次）。

参加人员： 全体

相关动作

「PM」→ 输出 Final PRD

UI评审会 UI Review Meeting

会议目标： 讨论页面和交互的实现，达成团队对于本次页面和交互设计的理解共识（会议次数原则上不应不超过2次）。

参加人员： 全体

相关动作

「UI」→ 输出页面和交互设计

设计及评估阶段

计划会 Plan Meeting

会议目标： 进行本次迭代内容的确认，可能包含：业务部分、技术部分、遗留问题或Bug等。

参加人员： 全体

相关动作

「Master」→ 组织计划会，确定本次迭代的范围（Review 项目管理平台 内的遗留问题和Bug）

设计评审会 Design Review Meeting

会议目标： 讨论设计、规范、实现、数据迁移、历史技术债务、上线发布等多方面。

参加人员： RD 或 FE、QA

相关动作

（按需）「RD」→ 输出设计文档，并评审（关于设计文档编写，请参考 如何编写「设计文档」TODO）
- 第1次，RD内部进行设计评审
- 第2次，RD + FE进行API设计评审
（按需）「FE」 → 输出设计文档，并评审

工作量评估会 Estimate Meeting

会议目标： 根据计划会的确认的开发范围，进行工作量估算，并分配任务优先级和具体开发人员。

参加人员： RD、FE、QA

相关动作

「Master」→ 组织工作量评估会，确定本次迭代的工作量（评估方式：计划扑克 TODO）

「研发周期」计划发布 Plan Deploy

相关动作

「QA」→ 发布本次迭代的「研发周期」计划

「Master」→ 把各类迭代信息，更新到 项目管理平台，正式进入编码

测试用例评审会 Test Case Review Meeting

会议目标： 评审测试用例的完整性和合理性。

参加人员： RD、FE、QA

相关动作

「QA」→ 组织评审（测试用例维护在 测试用例管理平台）

开发阶段

每日站会 Stand Up Meeting

会议目标： 参考如何进行「每日站会」TODO

参加人员： 全体

相关动作

「Master」→ 组织会议，主要沟通依赖、Block、风险等

故事验收 & 测试 Desk Check & Story Testing

相关动作

「RD & FE」→ 发起故事验收（如何进行故事验收 TODO），通过后，部署FAT环境进行测试，「QA」记录结果
「QA」→ 针对故事进行测试，当故事没有功能相关问题时，结束此故事测试

中期检查 Mid-term Check

会议目标： 沟通问题，预知风险

相关动作

「Master」→ 在迭代进行到中段，组织研发人员进行工作进度的Review，预知Delay风险

测试 & 验收阶段

系统测试 System Testing

相关动作

「RD & FE」→ 整理部署文档，提交部署工单
「QA」→ 在FAT
- 验证部署文档
- 冒烟测试
- 用例测试（黑盒、白盒）
- 回归测试（黑盒、白盒）

验收 Acceptance

相关动作

「QA」→ 在UAT
- 验证部署文档
「PM」→ 进行产品验收
「UI」→ 进行UI验收
「QA」→ 在UAT
- 回归测试（黑盒、白盒）

发布阶段

发布 Release

相关动作

「QA」→ 提交部署工单进行审核，通过后进行发布动作
「QA」→ 填写本次发布说明（对内）

迭代回顾阶段

迭代回顾会 Review Meeting

会议目标： 总结迭代流程和质量问题，进行复盘，优化迭代流程、代码质量、协作方式等。

参加人员： 全体

相关动作

「Master」→ 汇总迭代数据，进行报告和总结的编写
「Master」→ 组织迭代全部人员进行迭代数据的Review和问题的讨论

使用的相关工具或平台

	工具或平台
项目管理平台	https://www.teambition.com/
沟通工具	钉钉
测试用例管理平台	https://metersphere.io

我的2022

Sat, 31 Dec 2022 01:44:56 GMT

小小的感慨

2022一路走来，体会到了马尔克斯《百年孤独》中的南美洲的魔幻现实主义的循环，经历了人生第一次「转运集中隔离」，当我以为2022年会在疫情管控的反复循环中结束的时候，12月突然的放开，让我们又在全网的悼念中结束，对于任何人都是非常不容易的一年。

BBC 2022全球总结的第一句话就是：2022这是一段漫长的旅程。俄乌战争开始，到世界杯梅西夺冠结束，算是给这个漫长而又艰难的一年画上了一个相对圆满的句号。

回想了这一年的经历和变化，会让我感慨，作为时代的一粒沙，确实只能在历史的进程中「随波逐流」。作为普通人，我们无法改变什么，能做的只能是改变自己，努力生活。下面回顾下我这一年的一些小小的收获。

回顾

阅读与写作

纸质书

共 11 本

小说（6本）
- 人世间
- 三体
- 悉达多
- 人生海海
- 活着
- 百年孤独
社科（4本）
- 乡土中国
- 人类简史
- 以色列一个民族的重生
- 枪炮病菌钢铁
历史（1本）
- 万古江河

听书

樊登: 9247分钟（约154小时），131本次

Blog

发布技术类文章：3篇
微信公众号关注人数变化：85 → 156
阅读量：接近5000

健康与锻炼

户外运动：2次爬山运动（少的可怜）

减肥：很遗憾，没啥变化

新的一年的计划

2022年，听书量还可以，但是阅读纸质书籍的量偏少，需要加强更多的摄入。发布技术类文章的数量也没达到预期，这个需要克服自己的「拖延症」。健康方面，虽然身体还好，但是锻炼着实是少的可怜，2023年必须加强，未来是要拼免疫力的啊。

给自己的2023年确定一些小目标

健康与锻炼
- 户外运动：15次
- 每天晚上11点30分前睡觉
- 体重下降5公斤
加强建设自己的个人品牌
- 发布技术类文章：10篇
- 微信公众号关注人数增长100%
- 独立Blog访问量破1w
加强阅读
- 纸质书：18本
- 听书：破10000分钟
- 开始尝试写读书笔记（5篇）
提升英语听说能力
- 坚持多邻国打卡
- 坚持看英文原文TED
- 关注一些提升听力博主，进行系统性学习

写给2023的自己

麦加在《人生海海》里面提到了一句话（最近世界杯的央视解说天花板贺炜也说过）

世上只有一种英雄主义，就是在认清了生活真相后依然热爱生活。 — 罗曼罗兰

2023希望家人和朋友健康，虽然世界依然乱七八糟，但是还是要相信和热爱生活，相信努力就会变好。

基于「结构化思考」的研发管理实践

Fri, 28 Oct 2022 03:45:38 GMT

为什么想到要「结构化」

人

前几年，有幸读过一本书《高效能人士的七个习惯》（想了解的同学，自己豆瓣搜下），其中讲到做人非常重要的一个逻辑 「以终为始」 。

主要是告诉我们，做人需要以原则为中心，不要被事件、表象所左右，需要有做人的原则，这个原则应该是稳定的，指引我们人生的。

团队

其实，管理团队也是一样的。作为Leader，需要甄别关键任务，带领团队在正确的方向上持续前进。所以，也需要 「以终为始」 ，找到适合研发团队的稳定的原则。然后，以一个稳定的结构化方式进行输出，围绕原则进行产品能力、团队能力的提升，持续进步。

指北针

团队工作的「指北针」，指导团队的工作决策。

我们应该遵循「以终为始」的原则，为工作中的各种「选择」、「决策」，提供稳定的结构化的思考框架和工作框架。

「指北针」核心存在的意义就在于此。

组成

研发效能指标

目的：「持续快速交付价值的能力」是效能改进的核心目标。

指标项	指标子项	说明
交付吞吐量	单位时间交付的版本数量	1个月或1个季度内，交付的各个版本的数量（统计意义上看趋势）
需求响应时间	交付周期	需求启动到发布上线的平均时长
	研发周期	编码开始到发布上线的平均时长
交付质量	单位故事点 / 功能点Bug数量	针对不同类型迭代计算方式不一样
	单位时间修复的线上问题数量	1个月或1个季度内，修复的线上问题数量
持续发布能力	发布频率	1个月或1个季度内，发布次数
	发布时间	从合并代码完成，到发布到线上的平均时长

系统可用性指标

目的：全面体现系统的健康程度，构建SLI、SLO，给用户提供极高的稳定性和可用性。

依据谷歌SRE理论，通过SLI、SLO、SLA，进行系统健康程度的观测

工作逻辑

我们团队负责的是一个SaaS产品，所以针对我们团队的工作逻辑，进行了下面的结构化抽象。

研发能力分层

目前等级：Poor（不好）、Fair（凑合）、Average（中等）、Good（不错）

收获

目前，我们这个抽象的结构化工作逻辑，已经持续了一段时间，产生了一些效果，比如

在规划方面，我们有了稳定的结构，可以持续改进某个方面的能力
在目标上，团队清楚未来2个季度的整体规划
在决策上，我们会依据「结构化」「原则」进行关键任务的甄别

作为研发Leader，如何做规划

Mon, 01 Aug 2022 03:49:59 GMT

现实中的规划

刚刚过去的Q2，团队内部做了迭代和OKR的复盘，然后马上需要去做Q3的OKR拆分。在这个过程中，我找了团队中的几个伙伴沟通了下，发现大家对于规划的理解，更多的是，把问题罗列，然后针对具体问题，形成一些目标，然后去做。这样做，目标的准确性和逻辑性，以及目标是否真的是目标，都存在很大的不确定性。

规划的方法

做规划的方式，其实体现了每个人在遇到问题时的思考方式。这里我们需要先了解了，2个最基本的逻辑分析方法「演绎法」和「归纳法」。

演绎法

人们以一定反应客观规律的理论认识为依据，从服从该事物的已知部分，推理得到事物的未知部分的思维方法。

例子

哲学先贤，亚里士多德提出过的经典的三段论，其实就是演绎法的体现

大前提：所有人都会死；小前提：苏格拉底是人；结论：苏格拉底会死。

大前提、小前提正确，结论也是正确的。

归纳法

人们以一系列经验事物或知识素材为依据，寻找出其服从的基本规律或共同规律，并假设同类事物中的其他事物也服从这些规律。

例子

前提：大姑做P2P赚了钱，小姑做P2P赚了钱，同事A做P2P赚了钱；结论：我做P2P也一定可以赚钱。

这是一个典型的归纳推理，前提是我们观察到很多人做P2P都赚了钱，所以，得出我自己也能赚钱的结论，对未来做出了预测。

我们要采取什么方法

从例子可以看出，很显然，归纳法存在一定的风险，把事物的过去的表现当做了事物本身的属性，所以事物的未来发展趋势也是一样的。

我们知道演绎法，只要保证前提是正确的，其结论一定是正确的，所以在使用演绎法的时候，我们需要注意，我们的大前提和小前提的是否真的是正确的。

这里我所采取的方法是：演绎法

规划的价值

识别「关键任务」

规划的首要价值就是，从复杂的现实问题中，找到对于团队或组织最重要的部分，集中资源执行。

从全局思考问题

不谋万世者不足谋一时不谋全局者不足谋一域。 —— 陈澹然[清]

规划的另一个价值就是，让自己从全局思考、从事物的原理思考，尽可能保证我们规划的内容是符合逻辑的，是反应客观规律的，找到正确的「前提」。

就像演绎法的定义一样：

人们以一定反应客观规律的理论认识为依据，从服从该事物的已知部分，推理得到事物的未知部分的思维方法。

让目标成为大家的目标

规划好后，需要给团队详细输出我们对于规划的分析思路和Why。只有每个人充分理解了规划的内容，才能更好进行目标的执行。

研发Leader一个非常重要的工作就是「识别关键任务」，找到团队和技术架构问题，进行系统性的规划，指导团队解决问题

一个SaaS产品的半年规划Demo

作为研发Leader，如何数据化评价「迭代质量」

Wed, 16 Feb 2022 04:01:57 GMT

为什么要数据化

用事实说话

通过数据的客观事实反应团队的协同效果和成果的产出质量，是从另外一个客观视角去挖掘问题的一种方式。尽量不要用「我觉得」、「我认为」这些主观臆断方式，进行复杂问题的评价。

角色多样、配合复杂

一个迭代，往往涉及到很多角色。所以，这些角色的行为和成果，对于「迭代质量」都会产生各种变化，这些变化往往是复杂的。所以，也需要从数据的层面，收集各个维度的客观事实，综合地评价「迭代质量」。

迭代也要迭代

产品的优化、迭代，是不断持续完善的。企业和产品的不同阶段，针对质量的要求其实也是完全不一样的。著名的项目管理三角形，其实就是权衡的过程，时间、成本、范围，最终都会影响质量的高低，只不过看某些阶段，我们更看重什么。在企业、产品不断的发展过程中，我们需要从各个方面收集数据，从不同维度持续分析「迭代质量」，以便于帮助我们在当前环境下，进行取舍，从而达到我们的产品目标。

如何数据化

在我们团队内部，采用了一个标准来评价迭代的质量，即「迭代质量评价标准」，其组成如下

迭代质量评价标准组成

4个维度 + 1个分值

4个维度
- PM改动需求（30%）
- User Story交付延期情况（10%）
- User Story冒烟测试情况（20%）
- Bug（40%）
1个分值
- 迭代质量分值

满分10分，合格6分	维度	占比
PM改动需求（PRD定稿后）	30%	3
User Story交付测试延期	10%	1
User Story冒烟测试通过情况	20%	2
Bug（n = Bug总数 / 总故事点）	40%	4

举个栗子

上面是我的团队，近期的一组迭代数据，背景交代

故事点：1个故事点 = 1人天
迭代流程：按故事开发和测试 → 整体回顾测试 → PM&UI验收 → 发布 → 复盘

迭代数据化能带给团队什么

团队为迭代负责
- 通过数据化呈现迭代质量，让团队以一种理性的方式，审视迭代问题，从而找到解决方案，伙伴的目标是一致的：让迭代更好
让「问题」透明化
为改进团队迭代效能提供了坚实的数据基础（任何改变都能从数据层面找到体现）

想做还没做的事情

通过打通我们使用的各个敏捷工具，自动化收集迭代数据，产生「迭代质量分值」，并可以针对历史数据进行各自维度对比，从而更好的提高效率。

作为研发Leader，如何做总结

Fri, 04 Feb 2022 03:58:33 GMT

为什么要总结

行有不得，反求诸己。 —— 出自《孟子》

学会从自身寻找原因，可以帮助我们成为更好的人。

其实，无论是个人还是团队，在年底进行一些有针对性的总结（建议是数据化呈现），对于找到自身问题，提高和改进，还是有挺大帮助的。

切忌，不是为了总结而总结。应该学会从客观的事实（数据化是个不错的手段），寻找问题的发生原因，从而尝试做改变，去改善问题。

准备工作

思考的框架优于思考的内容

避免流水账

作为研发Leader，在做总结时，我会首先避免流水账，不要先思考这1年来，我们做了什么，这样很容易陷入到细节中。

思考：我们需要什么样子的团队

小时候，经常被问到，你想成为什么样的人。其实，管理团队也是一样的逻辑，先思考「我们需要什么样的团队」。在2021年初，我们团队定下的指导思想是「成为专业的团队」，所以，在接下来的1年时间里，我们都在遵循这个指导思想。

建设团队的指导思想

抽象团队的工作分类

我的思路

做了什么

建议按照工作分类进行重点事项的陈述

做到了什么，没做到什么

从做的事情，客观的数据反馈，和年初的目标，进行综合对比，进行分析，找到问题原因，为来年提供改善思路

分享自己或团队其他人的做事心得（方法）

意在提高团队认知，授人以鱼不如授人以渔

我的2021总结（部分）

做了什么

Iteration 迭代

Arch 架构
- Backend
  - 涉及内容较敏感
- Frontend
  - 涉及内容较敏感
Assets 技术资产
- 工具
- 服务器和环境
- 代码规划&设计
  - 涉及内容较敏感
团队
- 架构
  - 涉及内容较敏感
- 激励
  - 涉及内容较敏感
- 活动
  - 涉及内容较敏感

做到了什么，没做到什么

涉及内容较敏感

分享自己或团队其他人的做事心得（方法）

小团队敏捷实践2.0

Wed, 18 Aug 2021 05:47:18 GMT

1.0阶段

1.0

一切从需求开始

在「1.0」阶段实施和使用过程中，我们发现了很多实际问题，所以整体对敏捷流程进行了一些改进和升级，以适应团队迭代的变化。

需求源分类

由于提出需求渠道比较多，为了便于管理，我们对需求源进行了分类，具体分类如下：

需求代号	描述	迭代版本代号
Feature	基于产品价值的自主产品迭代	feature/sprintXX，如：feature/sprint40
CS	客户成功经理反馈的用户侧需求	cs/yyyyMMdd，如：cs/20210713
Tech	研发内部发起的技术改进或重构类需求	tech/模块或重构名，如：tech/mtms、tech/res
Hotfix	故障流程触发的线上问题修复需求	hotfix/yyyyMMdd，如：hotfix/20210713

目前，我们团队开启Sprint的需求类型为：feature，其余类型不触发Sprint。

迭代流程

整体迭代分为6个阶段，分别是

PRD Review：产品需求评审、用户故事评审
Estimate：概要设计、工作量估算（扑克牌）
Sprint Start：Jira创建Sprint、版本号、登记用户故事、创建甘特图
Sprint In Progress：迭代进行中，每天10点站会同步进度
Deploy：PM、UI验收、版本发布
Sprint Review：迭代复盘

1.PRD Review

PRD Review流程

参与者

推动：PM
参与：RD FE QA UI

输入信息

本次迭代的PRD。（路径「PM团队」→「产品需求」→「2021产品需求」→「产品自主迭代」→「某次迭代的PRD页面」）

输出信息

蓝湖中本次迭代原型讨论终稿
用户故事讨论终稿（路径「钉钉云盘」→「3-研发部」→「用户故事拆解」→「SprintXX」→「文件夹下的用户故事文件」）

PRD

钉钉中的用户故事

2.Estimate

估算方式采用的是「规划扑克估算法」。一种基于共识的估算方式（游戏），主要用于估算Scrum迭代中的开发任务的工作量问题，通过团队的共同的评估方式，使得偏差变得相对较小。

什么是规划扑克

规划扑克使用Fibonacci序列作为Story Point。Fibonacci序列是13世纪引入的数学系列数字，用于解释自然的某些形成方面，例如树的分支。通过将前两个数字相加来生成序列，以获得序列中的下一个值：0,1/2,1,2,3,5,8,13,20等。出于敏捷估计的目的，一些数字已经改变，导致以下系列：1，2，3，5，8，13，20，40，100

扑克说明（点数约定：1 Story Point = 1 人/天）

牌	解释
0	不需要工作量
无穷	任务量大
?	无法估计
一杯咖啡	不足0.5
其他	按照字面意思理解点数

估算流程

参与者

推动：PM
参与：RD FE QA

输入信息

用户故事

输出信息

用户故事的估算和优先级

操作步骤（一般2轮估算基本可以达成共识）

PM进行用户故事描述

RD / FE 的团队成员，通过面朝下的方式打出编号卡（斐波那契值：1，2，3，5，8，13，20，40）

卡片同时亮出

解释估算偏差，并讨论

估算共识达成

估算记录表

估算完成后，我们把估算的结果填写到钉盘中的故事列表中，并确定故事优先级

3.Sprint Start

Sprint创建&开启流程

参与者

推动：Scrum Master（QA）
参与：RD FE QA

输入信息

用户故事 & 估算结果

输出信息

Sprint & Gantt

创建Epic

创建Story

Sprint面板

Gantt

4.Sprint In Progress

日常流程

参与者

推动：Scrum Master（QA）
参与：RD FE QA

输入信息

站会同步

输出信息

用户故事更新

5.Deploy

验收&发布流程

参与者

推动：Scrum Master（QA）
参与：PM UI RD FE

输入信息

UAT环境

输出信息

迭代发布
Sprint Done

6.Sprint Review

Review流程

参与者

推动：QA
参与：PM UI RD FE

输入信息

测试报告

输出信息

复盘结果

测试报告

总结

以上就是目前研发团队的2.0版本的敏捷迭代流程，后面需要重点改进的还是，如何引入CI、自动化测试等等手段，进一步提升测试的效率，从而更快的反馈出问题。

Code Review Practice

Sun, 01 Aug 2021 05:52:08 GMT

什么是Code Review

Google Code Review的描述

The biggest thing that makes Google’s code so good is simple: code review. At Google, no code, for any product, for any project, gets checked in until it gets a positive review.

让谷歌的代码如此优秀的原因很简单：代码审查。在谷歌，任何产品、任何项目的代码都不会在没有审查的情况下进入代码库。

是一种文化，不是制度

为什么需要

工作中的痛点

每个人代码风格不统一
接口、类各种命名不统一
深层逻辑问题，测试不容易发现
吐槽「这TMD谁设计的，各种坑（可能是几个月前的自己）」

可以带给我们什么

提升代码质量
团队知识共享
团队统一规范
形成好的代码文化共识

Review什么

Google Review的原则

What to look for in a code review

Design: Is the code well-designed and appropriate for your system?
Functionality: Does the code behave as the author likely intended? Is the way the code behaves good for its users?
Complexity: Could the code be made simpler? Would another developer be able to easily understand and use this code when they come across it in the future?
Tests: Does the code have correct and well-designed automated tests?
Naming: Did the developer choose clear names for variables, classes, methods, etc.?
Comments: Are the comments clear and useful?
Style: Does the code follow our style guides?
Documentation: Did the developer also update relevant documentation?

我们的Review原则

架构和设计

S.O.L.I.D
- 单一职责原则（SRP）
- 开放封闭原则（OCP)
- 里氏替换原则（LSP）
- 接口隔离原则（ISP）
- 依赖倒置原则（DIP）
行为是否统一
- 缓存是否统一，错误处理是否统一，错误提示是否统一等等
- 同一逻辑 / 同一行为有没有走同一Code Path。低质量程序的另一个特征是，同一行为 / 同一逻辑，因为出现在不同的地方或者被不同的方式触发，没有走同一Code Path 或者各处有一份copy的实现，导致非常难以维护
DRY原则（Don’t repeat your self）
面向接口编程，而不是面向实现编程
健壮性
- 对Corner case有没有考虑完整，逻辑是否健壮？有没有潜在的bug？
- 有没有内存泄漏？有没有循环依赖?（针对特定语言，比如Objective-C) ？有没有野指针？
- 有没有考虑线程安全性，数据访问的一致性
错误处理
- 有没有很好的Error Handling？比如网络出错，IO出错
效率 / 性能
- 对频繁消息和较大数据等耗时操作是否处理得当
- 关键算法的时间复杂度多少？有没有可能有潜在的性能瓶颈

Style

工程规范（工程结构，分层方式及命名等等）
Apollo配置规范
命名规范（接口、类、方法名、变量名等）
代码风格（括号、空格、换行、缩进等）
注释规范（规定必要的注释）
日志规范（合理的记录必要的日志）
DB SQL规范
URL规范

如何进行Code Review

团队前置准备

Git Branch Model
Git Message（能说明提交内容的）

何时触发

使用工具

Gitlab
Sonarqube

参考

Git Branch Guidelines

Fri, 25 Dec 2020 06:11:02 GMT

我们日常开发面临的问题

紧急修复线上BUG，应该如何拉取代码进行改动，直接在develop或master改吗？
现在团队有好几个并行开发任务，每个上线时间点不一样，而且是不同的小组负责开发，怎么管理并行任务，如何推送正确代码是一个大问题。
每个人对于分支命名不一样，对于命名的理解也千差万别，上线前在发现，分支合并错了。

分支管理的目标

代码提交在应该提交的分支
随时可以切换到线上稳定版本代码
多个版本的开发工作同时进行
明确每个分支的功用，做到对应的分支执行对应的操作
使用 Git 管理版本迭代、紧急线上 bug fix、功能开发等任务

有一份前辈的参考资料

A successful Git branching model
By Vincent Driessen on Tuesday, January 05, 2010

A successful Git branching model

首先这个不是Git或Github的官方资料，只是这位前辈的个人总结，也仅仅是适用当时这位前辈所在的Team的工作模式，并不适用与目前团队的工作模式。所以，在参考Git Flow的资料后，我们制定了自己的团队规范。

我们的规范

feature/sprintXX

作用：新功能迭代开发
部署环境：开发环境 DEV
创建：基于develop分支
是否删除：功能发布后删除
限制：无

test/sprintXX

作用：新功能迭代测试
部署环境：测试环境（FAT）
创建：基于feature分支（每次提测前，feature merge develop代码，feature再合并到test）
是否删除：功能发布后删除
限制：No Push / 开发人员Merge

hotfix/yyyyMMdd

作用：线上问题修复
部署环境：测试环境（FAT）
创建：master分支（修复上线后，合并回master和develop）
是否删除：修复发布后删除
限制：无

develop

作用：包含最新的功能代码，新建feature/sprintXX 分支的基础
限制：No Push / 开发人员Merge

master

作用：稳定代码
部署环境：生产环境（PROD）
限制：No Push / 少部分有权限的可Merge

分支操作规范

feature/sprintXX分支下使用rebase

解决提交路线图清晰问题，git pull默认是merge操作，可以使用如下命令进行rebase

git pull --rebase

#也可以做全局配置
git config --global pull.rebase true
git config --global branch.autoSetupRebase always

分支合并使用 no-ff

解决fast-forward 合并的路线图问题，这种 merge 的结果就是一条直线，无法明确看到切出一个新的 feature 分支，但是使用 no-ff就可以明显看出新feature分支的合并路线图

# 合并sprint01 到 develop 分支
git merge --no-ff feature/sprint01

Git Commit Guidelines

Mon, 21 Dec 2020 06:14:55 GMT

为什么需要

降低Review成本，可以明确知道本次提交的改变和影响
规范整个Team的提交习惯，对技术素养的养成有益
可以通过统一工具，抽取规范的message自动形成change log

GitHub Angular Demo

目前Github的Angular项目，就是完全采用规范的Git Message来进行日常的提交管理和发布管理的，下面是这个项目的Commit记录，和自动根据commit生成的change log

遵循什么规范

目前，使用较多的是AngularJS规范

angular/angular.js

# 包括三个部分：Header，Body 和 Footer

<type>(<scope>): <subject>
// 空一行
<body>
// 空一行
<footer>

包括三个字段：type（必需）、scope（可选）和subject（必需）

任何一行都不能超过100个字符

type

用于说明 commit 的类别，类型包含如下几种

feat: A new feature
fix: A bug fix
docs: Documentation only changes
style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
refactor: A code change that neither fixes a bug nor adds a feature
perf: A code change that improves performance
test: Adding missing or correcting existing tests
chore: Changes to the build process or auxiliary tools and libraries such as documentation generation
revert: Reverts a previous commit
build: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
ci: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)

如果type为feat和fix，则该 commit 将肯定出现在 Change log 之中。其他情况由你决定，要不要放入 Change log。

scope

用于说明 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同

subject

subject是 commit 目的的简短描述

Body

Body 部分是对本次 commit 的详细描述，可以分成多行

Footer 部分只用于两种情况

不兼容变动

如果当前代码与上一个版本不兼容，则 Footer 部分以BREAKING CHANGE开头，后面是对变动的描述、以及变动理由和迁移方法

关闭问题

如果当前 commit 针对某个issue，那么可以在 Footer 部分关闭这个 issue。

如：Closes #123, #245, #992

工具约束

我们的目标还是要通过工具生成和约束

Commitizen

commitizen/cz-cli 代替git commit

我们需要借助它提供的 git cz 命令替代我们的 git commit 命令, 帮助我们生成符合规范的 commit message

# 如何安装，在安装之前请先安装npm
# 全局安装 commitizen
npm install commitizen -g

除此之外, 我们还需要为 commitizen 指定一个 Adapter 比如: cz-conventional-changelog (一个符合 Angular团队规范的 preset). 使得 commitizen 按照我们指定的规范帮助我们生成 commit message

# 进入到我们项目的根目录

cd your_repo_root_path
# 初始化package.json
npm init --yes
# 为commitizen指定适配器
commitizen init cz-conventional-changelog --save-dev --save-exact

现在我们就可以用git cz去进行提交了

但是问题来了，如果我们此时还用git commit -m “” 去提交，也是允许的，但是这肯定不是我们想要的，因为我们需要对message进行格式限制，所以，我们需要下面的检验插件commitlint + Husky

Commitlint + Husky

commitlint可以帮助我们检查校验提交的message

如果我们提交的不符合指向的规范, 直接拒绝提交

校验 commit message 的最佳方式是结合 git hook, 所以需要配合Husky

# 在我们的项目根目录
npm install --save-dev @commitlint/{config-conventional,cli}
npm install husky --save-dev

# 在package.json尾部加入如下结构
"husky": {
    "hooks": {
      "commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
    } 
}

# 在项目根目录新增文件commitlint.config.js
module.exports = {
  extends: ['@commitlint/config-conventional'],
  rules: {
  'type-enum': [2, 'always', [
     "feat", "fix", "docs", "style", "refactor", "perf", "test", "build", "ci", "chore", "revert"
   ]],
  'scope-empty': [2, 'never'],
  'subject-full-stop': [0, 'never'],
  'subject-case': [0, 'never']
  }
};

现在，我们可以在试试git commit -m “test”看看是否可以正常提交，应该会得到下面的拦截记录

Standard Version

通过以上工具的帮助, 我们的工程 commit message 应该是符合Angular团队那套，这样也便于我们借助standard-version这样的工具, 自动生成 CHANGELOG, 甚至是语义化的版本号(Semantic Version)

# 在项目根目录
npm install --save-dev standard-version
# 在scripts结构体中加入执行脚本
{
  "scripts": {
    "release": "standard-version"
  }
}
# 生成changelog
# 第一次生成
npm run release -- --first-release
# 后续生成
npm run release

会在我们项目根目录生成一个CHANGELOG.md文件，如下所示

项目中如何使用

如果我们已经完成了上述操作，会发现我们最终会得到一个package.json，我们只需要把package.json / commitlint.config.js提交版本库即可

把node_modules 和 package-lock.json都加入git忽略文件

下次再新clone项目后，直接在项目根目录运行npm install即可完成上述所有步骤

PS：NPM有时候国外镜像不稳定，可以切换淘宝镜像

npm config set registry https://registry.npm.taobao.org

作为研发Leader，如何组织技术分享

Wed, 02 Dec 2020 05:53:26 GMT

目的

首先，我们需要明确为什么要做这件事情。这件事情能给大家带来什么，预期结果又是什么，这里的“大家”主要有3个主体：公司、团队、个人，每个主体对于技术学习与分享这件事件，都有不同的预期结果，下面总结了几点目的：

学习新技术，提升自我，形成技术知识体系
提升专业知识领域的经验
提升沟通和表达能力
学习和分析内容，可以帮助产品技术框架、性能、工具的推进
技术资料的沉淀，形成公司技术价值

如何开始

了解了目的，我们需要想想如何做，才能达成目的。成人的学习、培训是比较难顺利推进，繁重的开发任务和人的惰性，Leader和管理层是否真正关注和帮助大家，这些都是历来公司内部推进技术学习与分享的各种困难，最后很多公司和团队都是不了了之。那么我们怎么做才能避免一些坑呢：

管理层统一思想，技术学习和分享是长期工作，其效果体现需要长期来看和评估
内容的质量，内容不能过浅
明确的分享周期和分享团队，明确分享人和听众的责任
选择内容不能随意，需要针对“听众”的情况，选择感兴趣的内容

如何做

1.分享成员

降低责任分母，如果12人团队，责任分母是12，会因为各种原因，某个人觉得不是我一个人的事情，很难主动分享；把分享做成小组，责任分母变小，可能是2或者3，这样小组内推进，比每个人的自驱动力推进来的靠谱。

我们目前的研发团队组成有3类

RD：4人
FE：5人
QA：3人

以3个小组为单位，进行技术学习和分享活动，按照顺序轮流执行，小组内，可以一次多人分享，也可以一次一人分享。

2.周期确定

周期规则必须明确，这样分享人和听众，都有时间去准备。

分享时间规则

频次：每2周1次（几组轮流）
时间：周四晚上19点15分
时长：60分钟内

分享人准备

发出大纲：提前1周，即分享前一周的周四前发出

听众准备

阅读资料：分享会前1周内，需要把分享资料进行阅读，有分析显示，如果不提前看开会内容，在会议上可能听懂的内容也就20%，为了不浪费自己的生命，也应该分享前去阅读资料

3.内容选择

学习和分享的目的，是为了提高大家的技术水平，扩展大家认知的领域，所以内容选择建议分成2类：技术专题分享、自由主题分享。

如何选择内容

内容的选择，应该因团队情况和产品技术架构情况而异，每个季度进行一次规划，从团队中了解管理、技术弱点、希望提高的方面、产品下一步的技术和框架的要求，针对规划出来的内容，进行内容的选择（也包含培训课程平台的选择，目前选择的是拉勾教育）。

技术专题分享

有针对性提升团队在某一个技术领域的专业技能
可以快速的，有针对性的使用在现有架构和产品中
往往需要由浅入深，进行循序渐进的分享

自由主题分享

拓展认知
内容可以更广，甚至可以邀请相关非技术同学参加
更加要求分享者的表达的逻辑思维，怎么把大家不熟悉的内容，讲明白

针对分享类型，可以有针对性的进行技术专题分享和自由主题分享的交替

Reject Simple

想要分享的内容和形式NB，你就得变的NB在内容上，我们拒绝特别简单的技术内容，不要分享安装什么什么环境、什么什么入门之类的

4.团队氛围

通过技术学习和分享，提升团队的技术氛围，加强大家的了解，提高凝聚力。

分享会提供一些饮料、好吃的，在一个轻松的氛围下，免费学习知识，肯定有更多的人愿意来参与进来，主动性会增强很多。

总结

除了学习和分享，也希望大家学会感恩

感谢公司可以提供平台给大家进行分享的机会；感谢分享人利用自己时间，准备PPT；感谢听众认真聆听，踊跃提问；

怀着一颗感恩的心，你会看到更美好的东西，站在别人的角度思考，会让你走向另一个高度！

小团队如何落地敏捷开发

Wed, 11 Nov 2020 06:29:01 GMT

You can’t manage what you don’t measure. – Peter Drucker
你如果无法度量它，就无法管理它。

这是现代管理学之父，彼得·德鲁克的一句名言。项目管理、敏捷开发的前提，还是需要把数据串起来，进行可视化、数据化，这样才能看到它，管理它。

本文将以公司SaaS产品为例，介绍下“小团队”是如何进行敏捷研发的落地的。

为什么要实施

需求的进展不透明，不知道现在到哪里了
需求延期发布成为了家常便饭，不知道什么时候会发布上线
需求发布上线后，心里总是忐忑不安，不知道什么时候会出现问题和故障
团队沟通成本太高，经常性出现RD、FE、QA、PM信息不一致
需求插入随意、频繁，不计成本
\

不清楚，研发团队的工作量，是正常、超负荷、还是有人不饱和

\

在互联网初创公司里，需求和有限的资源，永远是矛盾命题，如何在矛盾中寻找平衡，把有限的资源专注于符合公司战略的需求，保持团队的节奏和良好的情绪，就是要实施敏捷管理的痛点，也是我们为什么要实施，敏捷管理也可以很好的回答上面出现的各种问题，给出答案。

使用的工具

The tools you use shape the way you work.

Atlassian Confluence
Atlassian Jira

如何做好这件事情

「需求评审 ➡️ 设计评审 ➡️ 研发实现 ➡️ 测试 ➡️ 验收 ➡️ 发布 ➡️ 后评估」

为了让产品和研发过程可视化，更加可控，信息互通，我们采用4个看板模型进行敏捷管理实践，看板名称和功能如下：

公开需求看板（Kanban Board）

通过「看板」建立一个公开需求池，向跨部门成员广泛收集需求，一切市场反馈及时传递到位。看板类型为Kanban Board。

需求看板（Kanban Board）

为需求生命周期搭建流程，按「Backlog – 评审 – 排期 – 设计 – 开发 – 发布」设立多个阶段，需求流转可视化。

任务效能看板（Scrum Board）

为需求预设好发版时间，所有人都可以及时预知逾期风险；产品、开发和需求提出者随时发起沟通，及时同步需求变化或者开发进展。

BUG看板（Kanban Board）

通过看板查询，迭代中的各种类型的BUG数量情况，清楚明了。

公开需求管理（公开需求看板）

公司属于教育类SaaS，其公开需求主要来源有下面几类：

重要客户（学校）
用户日常使用反馈（教师、学生、家长）
销售渠道

甄别和过滤伪需求和次要或者不符合战略的需求，在这里进行，但是“业务方”提出的众多的需求如何管理，也是一件头疼的事情，主要的公开需求来源一般由以下几种：

销售
市场
内部（基于产品规划 / 其他）
用户使用体验

客户成功同学、销售同学或者其他干系人，都可以在这个看板内，提交公开需求，产品同学会过滤、调研，转化为产品需求，到产品需求池内，下面是公开需求看板，卡片的内容主要包含了：需求描述、公开需求来源、报告人、经办人

判断价值很低或者肯定不会做的需求，直接拖到已完成
判断有一定价值或需要在分析的需求，拖到调研讨论，最终确定后，再拖到已完成

产品研发需求管理（需求看板）

需求分类

产品研发内部，我们把需求分成2类：

产品需求：PM提出的迭代、紧急、日常类需求
技术需求：研发内部为了稳定性、扩展性、维护性而进行的技术重构类需求

需求等级

古语云：师出有名，需求的提出也是如此，为了让研发同学知道需求的重要和紧急程度，需求等级划分是特别需要的一件事情。

产品需求等级划分
- P0：紧急任务，必须穷尽所能，最短时间完成；可以调人支援，可以停止其他项目，需要加班
- P1：非常重要任务，有Deadline，并且不可以Delay；如遇到P0，那么就需要加班保证P1的Deadline
- P2：重要、有影响力的任务，有Deadline，如遇到P0和P1，可以顺延（应该是大部分任务）
- P3：锦上添花的正常任务，优先级最低
技术需求等级划分
- T0：重大性能和漏洞，需要加班加点进行修复
- T1：扩展性和性能风险问题，一般是单独任务进行修复
- T2：设计或者一般性能缺陷，一般是随着迭代进行相关改进

产品需求管理（需求看板）

PM和研发同学，通过PRD的方式进行沟通和交流，研发同学最终也是通过PRD进行开发、测试工作，所以第一步是需要创建PRD，PRD的管理方式采用相对灵活的方式，PM写PRD的工具有的是蓝湖，有的墨刀，我们这里为了统一归档，在Confluence做了归档的统一管理（PRD的详细链接可以是任何工具的链接），在Confluence创建时选择模板创建，见下图：

主要包含了

背景描述
业务目标的描述
需求链接和功能列表（即Story）\

需求看板的泳道有P0、P1、P1以下、技术需求的4个泳道，为了便于搜索，在快捷搜索列加入了常用的搜索关键词，卡片主要包含：需求等级、到期日、需求负责人

技术需求管理（需求看板）

类似数据结构的变更、技术架构的改进，比如：更换配置中心为Apollo，这类需要简称技术需求，其数据显示和看板功能，和产品需求基本一致，也显示在需求看板内，看板如下：

技术任务管理（任务效能看板）

这个阶段，主要是从需求阶段进入到了研发阶段，这个阶段主要包含如下类型的任务：

开发任务：RD、FE
开发自测：RD、FE
测试用例编写：QA
测试用例执行：QA

技术任务类型的问题，主要来源于2个方面

产品需求
技术需求

对于此类任务管理，我们使用的看板是任务效能看板。在开始之前，我们需要在Backlog内，拖动需要进行迭代的技术需求或产品需求，如下图：

然后，以产品需求和技术需求为父任务，在需求看板内，创建子任务，界面如下：

创建好后，可以查看父子任务详情，并有工作量体现

点击开始Sprint，并设置好时间，如下图：

RD & QA & FE，在每天下班前，填写其任务的工作量即可达到任务工作量跟踪的效果，如下图：

测试BUG管理（BUG看板）

在Sprint中产生的BUG都会显示在BUG看板中，工作流主要是打开 ➡️ 处理中 ➡️ 已解决 ➡️ 已关闭，如下图：

我们所采用的BUG类的问题类型有以下几种：

功能错误
界面优化
功能优化
性能问题
安全相关

在这个迭代结束后，测试人员，会根据BUG的统计报告数据，分析得出本次迭代的测试报告，测试报告，我们在Confluence创建了统一模板，主要内容如下：

小结

需求和效能的生命周期管理，这里仅仅是按照目前产品和团队的需求和阶段，规定了一些适合我们的方法，这个周期管理，还是需要随着人员和阶段的不同而进行不断的改造和演进的，下面是我们在JIRA和Confluence使用的一些核心流程和方法：

4个看板
- 公开需求看板：处理市场、销售前端部门提出的“大客户需求”和“用户使用体验问题”
- 需求看板：主要是管理技术需求和产品需求
- 任务效能看板：主要是管理开发阶段，RD & FE & QA的任务和工作量，跟踪其任务合理性
- BUG看板：主要是管理迭代内产生的5类BUG问题，功能优化 & 功能错误 & 界面优化 & 性能问题 & 安全相关
2个模板
- 产品需求模板：产品需求的管理
- 测试报告模块：迭代后，针对BUG和其他问题，进行的测试相关的总结

目前，敏捷相关的管理，这个阶段也仅仅是做了一小部分，还有很多实践方法，在后续的变化中，会加入和实施

敏捷管理是为了快速、稳定的交付产品而服务的，切忌不要为了追求敏捷工具的使用而耽误了实际要达成的目标。