追风笔记

PageFly

Mon, 01 Jan 0001 00:00:00 +0000

PageFly 是一个面向 AI 工作流的轻量页面托管方案：写好 HTML/Markdown 后直接发布，适合把分析页、工具页或实验性内容快速上线。

状态：已上线
地址：https://fly.882680.xyz
技术栈：Cloudflare Pages + Functions + KV（免费层）
用途：个人工作流落地页、轻量产品原型、AI 输出展示

个人简介

Mon, 01 Jan 0001 00:00:00 +0000

我是谁

王鹏，数学学士 + 计算机硕士，现就职于某银行总部（北京），担任后端架构师。

日常工作围绕客户信息系统（ECIF）、核心系统与分布式系统展开，熟悉：

分库分表、RocketMQ 动账通知；
账户 / 卡 / 支付结算 / 计息 / 限额；
数据治理与安全加密；
支付系统（二代支付、银联 / 网联）；
反洗钱 / KYC / CRS。

我在做什么

目标：从银行技术专家走向 CIO；
同时经营个人品牌第二曲线——公众号「金融科技百分百」，写银行系统、金融科技、支付、分布式与 IT 架构；
这个站点（追风笔记）是我沉淀技术专栏、博客与文档的地方。

投资顾问系统

Mon, 01 Jan 0001 00:00:00 +0000

一个偏向个人投资研究的原型系统：用 AKShare 获取 A 股/基金数据，Supabase 做后端存储，All-Weather 策略做资产配置参考。

状态：进行中
技术栈：Python / AKShare / Supabase / All-Weather
目标：把「数据获取 → 策略回测 → 组合跟踪」串成可复用的工作流
适用：个人投资研究，非投资建议

写作与专栏

Mon, 01 Jan 0001 00:00:00 +0000

我在这个站点上主要写三类专栏，对应我在银行工作中的不同关注点：

架构专栏：客户信息系统、核心系统、分布式架构与 DDD；
银行业务专栏：支付清算、计息与限额、账户 / 卡、反洗钱（AML）/ KYC / CRS；
数据专栏：数据治理、加密与安全、分库分表、消息与流处理。

此外，我也在运营公众号「金融科技百分百」，分享银行系统、金融科技、支付、分布式与 IT 架构相关的实战与思考。

联系方式

Mon, 01 Jan 0001 00:00:00 +0000

公众号：金融科技百分百
邮箱：（待补充）

认知匹配 / AI 认知画像

Mon, 01 Jan 0001 00:00:00 +0000

一个轻资产创业方向的探索：通过 AI 认知画像，把人的知识结构、偏好与能力结构化，再与机会（项目、人、内容）做匹配。

状态：规划中
形态：React + Claude API 的轻量原型
投入：每周约 18–27 小时，优先免费/低成本方案
核心问题：如何把「认知相似性」变成可计算、可解释的匹配信号

中文 AI 人味化 skill

Mon, 01 Jan 0001 00:00:00 +0000

一个 WorkBuddy skill（v3.0.0-zh），用于把 AI 生成的中文内容去「AI 味」，覆盖 18 类常见痕迹：夸张象征、宣传腔、-ing 分析、模糊归因、破折号滥用、三段式、AI 词汇等。

版本：v3.0.0-zh
形态：WorkBuddy skill
用途：公众号、技术文档、邮件、报告等需要「像人写的」中文场景
思路：先检测痕迹模式，再按类别做针对性改写

银行业本体论

Mon, 01 Jan 0001 00:00:00 +0000

把银行科技中反复出现的概念（组织、产品、账户、交易、客户、渠道、风险、监管报送等）结构化成本体，形成可复用的知识框架。

状态：研究中
输出：PPT、概念图、领域词汇表
目标：让业务→技术→数据的映射有统一语言
关联方向：ECIF、MDM、监管报送、数据资产

开博第一篇：为什么写「追风笔记」

Sat, 15 Aug 2026 00:00:00 +0000

做银行系统架构这些年，踩过的坑、想明白的事，大多散落在笔记本和聊天记录里。开这个站点，是想把它们系统地沉淀下来。

我会写什么

架构专栏：客户信息系统（ECIF）、核心系统、分布式架构，以及领域驱动设计（DDD）在银行场景下的落地。
银行业务专栏：支付清算、计息与限额、账户/卡、反洗钱（AML）/KYC/CRS 等核心业务梳理。
数据专栏：数据治理、加密与安全、分库分表、消息与流处理。

写给谁

同行、想转行做金融科技的工程师，以及任何对「银行系统为什么这么设计」感到好奇的人。

这个站点是示例内容，框架搭好后，真实文章会逐步替换进来。

在银行客户信息系统（ECIF）里落地 DDD 聚合

Wed, 12 Aug 2026 00:00:00 +0000

ECIF 里「客户」的概念极其庞大：个人、对公、同业，各自的属性、关系、生命周期都不同。如果用一个巨大的 Customer 实体硬扛，代码会迅速腐化。

用界限上下文切分

把客户拆成几个界限上下文：

客户主数据（Party）：统一的自然人/机构标识与基础属性。
客户画像（Profile）：风险偏好、营销标签，读写频率高、变化快。
客户关系（Relationship）：持股、担保、集团关系。

聚合根怎么定

每个上下文内部再定聚合根。例如 Party 上下文里，Party 是聚合根，Address、Contact 是其值对象，保证一致性边界内不跨聚合调用。

经验：聚合的边界应以「事务一致性」而非「业务概念大小」来划。ECIF 里最容易犯的错，就是把所有客户信息塞进一个聚合。

这样设计后，主数据服务稳定，画像服务可以独立迭代，互不影响。

一文理清 ECIF：客户信息为什么要「集中」

Mon, 10 Aug 2026 00:00:00 +0000

在没有 ECIF 的年代，网点、网银、信用卡中心各自维护一份客户信息。同一个客户，在不同系统里姓名、证件、联系方式都不一样，营销和风控都无从谈起。

ECIF 解决什么

ECIF（企业客户信息整合）把分散在各业务系统的客户主数据收敛到一处，对外提供唯一客户视图。

唯一标识：用客户号（Party ID）统一自然人/机构，而非证件号。
主次关系：支持一人多户、一户多卡，但主数据唯一。
服务化：其他系统通过接口查询，不再各自落库。

技术上的关键取舍

读写分离：主数据写入强一致，查询可走缓存/只读副本。
变更可溯源：客户信息变更需要留痕，满足监管审计。

ECIF 不是「又一个数据库」，而是银行数字化的最底层地基。

银行数据治理：先治「元数据」再治「质量」

Sat, 08 Aug 2026 00:00:00 +0000

很多银行的数据治理项目最后沦为「补元数据、填责任表」。要见效，得把治理内建到数据生产的流水线里。

两件事优先做

元数据与血缘：字段从哪个系统来、被哪些任务加工、流向哪里，必须可自动追踪。
质量规则内建：非空、唯一、口径一致等校验，在 ETL/湖仓任务里当「门禁」，不过不入库。

安全与加密

静态加密：落盘即对敏感字段加密（如证件号、卡号）。
动态脱敏：查询侧按角色脱敏，开发环境拿不到明文。

治理的目标不是「漂亮的报告」，而是让 downstream 系统敢用这份数据。