第 49 周
清晨计划
-
tech Q4 版本投产复盘; -
tech 项目方案书；
夜晚总结
清晨计划
-
tech 反思业务架构和技术架构的谜团； 251212
夜晚总结
-
life 《灰烬与星辰的拾荒者》
清晨计划
-
pm 25 年遗留督办项：国产化自主可控路线的规划方案（过技术规划委员会） -
pm 25 年遗留督办项：网安委方案（报总办会） -
code 整理 C / C++ 笔试题；
夜晚总结
-
tech 针对某国股行，配合业务架构，梳理技术架构； -
tech 当我们在谈行情时，我们在谈些什么？数据？服务？接口？平台？界面？讨论会上，语言的不统一、概念的混淆和视角的发散，令人难受。这也是企业级系统开发中的核心痛点之一。如果没有统一的架构语言和明确的分层治理，就会出现功能界面、系统平台、服务单元等全部混为一谈的 “大杂烩 “。缺乏清晰业务架构指导而直接推演技术架构，都将导致整体系统架构偏离真实业务需求。这也是中型技术团队在架构治理上最常见的问题。 rca 1.（架构认知层面）对业务/应用/技术架构的职责不清，讨论时缺乏统一语言，仅停留在个人关注的视角上。 sta 1）业务架构先行：讨论任何技术方案前，先统一业务语言，明确不同团队的业务目标、用户角色和核心业务流程；2）应用架构规划系统内部（构成）和系统之间（调用）的关系；3）技术架构负责设计可共享的核心服务和可复用的公共组件，以支撑业务需求。 rca 2.（技术实现层面）缺乏企业级的统一设计语言、组件规范和规划，导致各系统界面风格、交互、数据展示各不一致，重复造 “粗糙 “的轮子 sta 解决重复建设的核心在于 “分” 与 “合” 的架构设计艺术。“分” 是对业务差异进行垂直拆分（极致性能/深度数据/高并发/面向流程/面向报表）；“合” 是寻找和整合可复用的部分：1）对都需要的核心功能做 “模块通用化”；2）使用 “平台化思路”，将界面渲染/交互/配置规则等，封装为低代码界面框架或 SDK，业务团队无需关心底层实现，只需通过配置或少量代码即可 “组装” 出符合自身需求的界面。 rca 3.（组织管理层面）传统交付模式惯性，各团队独立建设，追求局部最优，而非全局最优；瀑布式开发流程场景单一，复用率不高. sta 组织保障技术变革，抽调核心人员共同负责平台化、组件化的建设，将平台能力复用、跨团队贡献纳入绩效考核（参考平安证券）。基于 1-2 个试点项目，共同设计（可结合外部资源）并初步建设行情平台组件库和统一数据服务接口。 road 可行的推进路径：1）统一架构语言（在同一语境下讨论）；2）梳理核心领域服务（基于共性需求，明确边界、标准和协议）；3）推动界面组件化（作为产品的一部分来规划和建设）。 eg1 以行情数据为例，通过统一的数据服务总线，汇总各业务方订阅和发布的数据，并将各业务方需要的核心功能（如基础实时行情数据接收、协议解析）下沉为统一的行情服务总线或核心领域服务，作为单一可信数据源。 eg2 实现高内聚和低耦合的、更广义的” 公共组件 “，1）基础组件库：封装高性能表格、图标等基础元素；2）业务组件库：基于基础组件封装行情展示，如报价板、K 线图等；3）低代码平台级组件：让开发 / 业务人员能基于平台组件（行情组件）快速配置和定义界面功能（自定义筛选、过滤条件）。
清晨计划
-
tech 确定 Q4 技术培训计划，聚焦代码 / SQL 规范；
夜晚总结
-
tech Q4 评估会，暴露了团队内部信息同步机制存在的延迟、遗漏和不透明性。作为生产环境前的最后一道重要关卡，在模拟环境中发现的问题，不仅没有及时收集到准确的信息，反而是借由其他部门提出。这也意味着信息在传递过程中出现了阻滞，缺乏一个强制性的确认环节，导致内部未能及时知晓并评估对自身工作的影响。后续应建立更健壮的信息同步与确认机制，尤其在大版本上线前，引入强制确认点。
清晨计划
-
tech 整理 O 库安全下线及 K 库版本投产重点关注事项；
夜晚总结
清晨计划
夜晚总结
清晨计划
夜晚总结
第 48 周
清晨计划
夜晚总结
清晨计划
夜晚总结
清晨计划
夜晚总结
清晨计划
夜晚总结
清晨计划
夜晚总结
清晨计划
夜晚总结
清晨计划
夜晚总结
第 47 周
清晨计划
-
pm 数据库遗留问题日报（新增 10 个问题，部分问题 12 月以 patch 形式提供，但涉及年结，需产研团队评估）； -
pm 2025 年度经营及财务情况的报告（含 2026 年工作计划）；
夜晚总结
清晨计划
-
pm 2025 年下半年应急演练总结报告和演练记录，评审后修正以下几点：1）简化不同阶段，总体应该有恢复时间的重要程度标准；2）故障的模拟因能合理解释总体恢复时间，若不能，则模糊故障原因； -
arch 了解并梳理某大行新一代系统架构；
夜晚总结
-
pm 学习《网络安全管理办法》评审意见；
清晨计划
-
code 优化微信读书月度报表；
夜晚总结
-
pm 内部评审《网络安全管理办法》； -
ai AI 技术路线图整体规划； -
tech 梳理单元化建设思路和方案，形成初版，需进一步明确单元的定义、划分维度、技术实现（服务网格、自动化、容器化）、跨单元调用规范、数据同步等； -
tech 11 月技术规划委员会对《第三方软件管理规范》进行了评审，领导评审会变成了一次生动的现场教学，为我树立了一个极高的专业标杆。编写规范性文件是一项对专业素养要求极高的工作，这不仅仅是文字功夫，更是系统思维、风险预判、组织协调和细节把控能力的综合体现。从 “完成任务” 的 “写手”，转变为 “为公司建立规则、防范风险” 的 “架构师”，沿着这个方向努力，培养出受益终身的严谨、系统和风险意识。 bug 1. 对细节的把控不够细致 rca 写作习惯和标准意识：往往更关注 “写了什么”（内容），而忽略了 “怎么写的”（形式）。但在一份规范中，形式和结构本身就是内容的一部分，它直接影响着规定的严谨性和可执行性。 sta 建立个人规范性文件检查清单，并包含：术语一致性、指代明确、标点与格式、强制性用语（“应”、“必须”、“不得”、“宜”、“可”、“建议” 等）、“朗读” 检查法。 bug 2. 视野不够全面，往往引入合规风险 rca “就事论事” 地编写规范，没有将其置于公司更大的合规体系、法律法规和业务场景中去考量。 sta 1）建立 “合规地图”，动笔前先画出每份规范需要对接的 “上”（上位法、行业监管要求）、“下”（公司已有的其他管理办法）、“左”（其他部门的相关要求）、“右”（实际场景中的特殊情况和潜在漏洞）；2）主动扮演 “挑刺者”，合规审查时会从哪个条款入手？该规定在极端情况下是否仍然适用？ bug 3. 组织内部职责梳理不清，导致规范不准确、不合理、甚至有冲突 rca 事前未与相关部门充分沟通，仅凭个人理解或想象去定义权责，这是规范类文件的大忌。 sta 提前梳理 RACI 职责矩阵，保证 “最终会签” 的有效性、准确性、可执行性。 bug 4. 重复造了 “粗糙” 的轮子 rca 对公司现有的制度体系不熟悉，一味追求 “大而全”，希望在一个文件里解决所有问题，反而降低了专业性。 sta 1）对公司现有相关规章制度建立个人知识库；2）精通 “引用” 的艺术，学会使用 “其他未尽事宜，参照《XXX 管理办法》执行”、“本规范所述的安全要求，不低于《XXX 要求》中的标准” 等表述；3）明确文档的边界，清晰定义核心目标和适用范围，与之无关的内容，应坚决引用或剔除，保持文档的聚焦和精炼。
我能排除哪些不安的根源？
也许最大的不安来自
真正的安宁，是意识到：大多数惊涛骇浪，都只在你内心的杯子里翻腾。当把注意力从纷扰的外界收回到可控的当下，许多杂音自然会静止。
清晨计划
-
code 实现微信读书月度报表数据的解析处理、自动化生成、可视化结果输出（复刻微信读书 App 端效果）； -
code 完成想法页面的历史内容同步； -
pm 梳理 Oracle 数据库下线方案； -
pm 梳理采购流程已知痛点和不合理的地方；
夜晚总结
-
tech 信创中间件选型会议纪要； -
code 构建阅读页面，支持展示微信读书月度统计报告； -
code 私有化部署视频课程网站可行性分析； -
pm 2025 年应急演练总结报告； -
code 2025 全球 C++ 及系统软件技术大会；
我还在用什么琐碎的比较来烦扰自己呢？
他人的成就像一面高墙，衬出自己步伐的迟缓；社交媒体上零碎的光鲜，幻化成一柄标尺，悄悄丈量着自己生活的褶皱。其实，用来烦扰自己的 “琐碎比较”，其根源或许并非事情本身，而是一种对自身坐标的焦虑。无论是他人的职位、财富还是看似完美的生活 —— 都成了最现成的参照系。
琐碎吗？也未必。烦扰吗？或许可以转换成动力。本质也许是对自我价值确认的渴望，通过 “胜过” 某个比较对象，获得短暂的安全感和价值感。但不管怎样，生命是展开而非竞赛。当停止用别人的地图寻找自己的路，转而信赖内心的罗盘时，那些琐碎的比较可能才会如潮水般退去，显露出真正需要专注的、属于自己的航道。
清晨计划
-
code 内部评审 11 月技术规划委员会 7 个议题材料； -
code 实现部分微信读书统计接口的调用和可视化输出； 251127 -
code 构建想法页面；
夜晚总结
-
tech 人脉是可以改变 “游戏规则” 的（有感于网站关键词排名）； -
code 通过 Stream手动抓包获取skey，并完成拉取月度读书统计数据； -
work 组织内部因为生产事故出现扯皮甩锅现象，放平心态，聚焦职责，做好分内事，不推诿责任，也不无谓背锅； -
life 下属遭遇情感危机，团队及时干预关心，自己又何尝不是一个渴望像他一样被关怀的个体；
更多的钱真的会让事情变得更好吗？
在基本需求未得到满足时，金钱的效用是巨大的。它能将人们从生存焦虑中解放出来。此时，金钱直接等同于安全感、健康与尊严，它无疑是让事情 “更好” 的决定性因素。而一旦跨越了基本的生活舒适线，金钱的 “幸福回报率” 便会急剧下降。它无法直接购买内心的平静、真挚的关系、生命的意义感或持续的幸福。许多困扰，如情感孤独、价值虚无或精神空虚，是财富无法解决的，甚至有时会带来新的烦恼。
因此，所谓的 “更好” 存在一个
清晨计划
-
code 日报的结构设计想了一夜没想出结果，不如先写，完成比完美更重要。 -
sec 完成《网络安全应急预案》和《开源软件管理规范》的整理。
夜晚总结
-
arch 学习某大行微服务治理体系，虽古老（使用 XML通信），但长期稳定可靠（控制到业务字段级）；251128 -
ai 除了用于文本生成和多模态理解的基础推理 API，其他类型 API 还包括：微调 API、训练 API、管理类 API 等（尽管暂时未涉及）； -
ai 推理表现不低于行业主流水准，可以从生成速度和响应延迟方面进行量化，如：生成速度每秒 20 个 token 以上，首个 token 时间小于 500 毫秒，对于 token 输出长度在 256 以内的文本生成任务，其 P95 延迟（即 95% 的请求的延迟）应低于 2 秒，输出长度在 256 以上的，其 P95 延迟应低于 5 秒； -
sec 整理完成《网络安全突发事件应急预案》、《网络安全应急演练计划》、《网络安全应急演练实施方案》、《网络安全应急演练工作确认单》； -
sec 整理完成《第三方软件和开源软件管理规范》以及对应软件台账； -
code 完成微信读书统计数据的接口逆向；