关于FEEI.CN
FEEI.CN 是吴飞飞的个人知识站，围绕健康、事业、财务、人生体验四个方向持续积累。不是博客——博客是发布时间点的快照，这里的每篇文档会随认知更新反复修改。不是笔记——笔记解决了捕获问题，但不解决整合问题；这里每一条新想法都要融入现有结构，而不是追加堆砌。
内容标准
这个站点的内容标准：宁愿一篇写透，也不要十篇蜻蜓点水。 覆盖面广不代表有洞见，浅入深出比面面俱到更有价值。
好内容的六个标准：让人愿意读、读得懂、能相信、记得住、自带传播力、可触发行动。前三条是底线，后三条是追求。
写作的基本要求对应信达雅：信（忠实内容）、达（表达通畅）、雅（符合阅读习惯）。前两条是底线，第三条是追求。
具体到行文：核心结论先说，再往下展开细节；直接陈述正面结论，不用"不是……而是……"绕圈子；不引用具体数字作为论据，用逻辑关系和因果机制表达观点；表格优先设计为纵向滚动，兼容手机竖屏阅读。
内容如何生产
想法捕获与知识沉淀是两件独立的事，把它们混在一起成本太高——要想清楚放哪里、怎么表达、和现有内容的关系，这些判断成本会让大量想法在"该写但还没写"的状态里消失。本站把两件事分开处理：
捕获极低摩擦。 GitHub Issue 是随时可以扔东西进去的收件箱——标题、几行文字、一张截图、一个链接，都行。不需要想结构，不需要想措辞，不需要想放哪里。
整合由 LLM 完成。 判断归属、提炼观点、找到现有文档的接入点、写成连贯的表达——这些认知成本交给 LLM。LLM 同时能看到全部待处理 issue 和全部现有内容，做的是真正的融合，不是简单追加。每一条想法都有最终去处（关闭），不会积压。
输入源分两类：
思维与认知——书摘划线、浏览器稍后阅读、视频文稿、突然的灵感、洗澡时的想法、对话中触发的认知……来源不固定，共同点是捕获窗口极短。比如微信读书 skill 可以直接把划线抓出来，创建成 GitHub Issue，先进入收件箱，再交给 LLM 处理。记下来是第一优先级，结构和措辞之后由 LLM 处理。LLM 的工作是逐条判断增量价值（重复或已覆盖则跳过），找到现有文档的接入点，融入而不追加——划线不是为了存档，而是为了让认知真正进入可被调用的结构中。
客观数据——投资持仓、iOS 健康数据、运动记录、睡眠数据……这类输入有明确的数据源和固定结构，用脚本自动同步比手动 Issue 更合适。以投资数据为例：脚本每天自动拉取证券账号持仓与历史资产，写入 static/data/account-assets/ 下的 JSON 文件，MDX 页面通过 ECharts 渲染资产走势、持仓分布、盈亏明细。健康数据也是同一类流程：sync-health 先同步仓库，再调用 export-health-year 通过 health-auto-export MCP 读取 Apple Health 年度数据，写入 static/data/health/<year>/<month>.json，随后更新 FEEI.CN 运行状态页，提交健康数据和状态页并推送。页面本身只负责读取结构化 JSON 并渲染图表，数据全程不需要手动维护，变动会在下一次脚本运行后自动反映在站点中。
这套模式和"用 LLM 写 Wiki"的本质区别在于：LLM-Wiki 是让 LLM 生成内容，每次独立工作，不知道已有什么、该放哪里，久了知识库发散成积压库。这里的 LLM 是编辑——每次介入都读全量现有内容，判断新想法归属哪个文档的哪个位置，融入而不产生新页面。知识库的密度在增长，页面数几乎不变。结构由人定，内容由 LLM 填充，主权在人。
技术架构
本站是基于 Docusaurus 的静态站点，没有管理后台、数据库和服务端动态语言。 所有内容以 Markdown 形式存放在 Git 仓库，构建后产出纯静态文件对外提供。
选择这套架构的核心原因是 AI 友好。 内容是纯文本 Markdown，AI 可以直接读取、撰写和重构，无需穿过编辑器、数据库或后台接口；各类信息都能以统一的 Markdown 沉淀下来，让 AI 参与整理与持续完善的成本极低。Git 与 Pull Request 的流程又让每次由 AI 产生的改动都可审阅、可回滚。
- 内容流程：编辑 Markdown / 源码 → 提交 Pull Request → GitHub Action 执行构建 → 产出静态文件
- 访问链路：用户 → HTTPS → Nginx → 静态文件
- 源码仓库：https://github.com/FeeiCN/wufeifei.com