跳到主要内容

关于FEEI.CN

FEEI.CN 是吴飞飞的个人知识与生活记录站，围绕健康、事业、财务、人生体验四个方向持续积累。这里同时保存按时间留下的生活记录，以及随认识更新的专题内容。新的想法优先融入已有专题，让零散的经历和思考逐步形成可以反复使用的认识。

为什么建立这个系统​

我希望这个系统能帮我做好三件事：记住生活、改善选择、积累认识。

记住生活。 留下发生的事情、遇到的人，以及当时的感受与判断。几年后重新读到，仍能想起那段日子是怎么过的。这是日记的价值，不要求每一天都有进步，也不要求每一件事都总结出道理。

改善选择。 把日常经历与一段时间的数据放在一起，发现反复出现的问题，判断哪些做法有效，决定下一步调整什么。这是复盘的价值。记录不只是为了回头看，也为了让下一次选择多一些依据。

积累认识。 将已经想清楚、值得反复使用的方法，融入健康、事业、财务和人生体验的专题中。新的经历带来新的认识，旧的判断也可以被修正。这是知识积累的价值：经历没有停留在过去，而是成为以后遇到问题时可以调用的经验。

日记保留“当时的我怎么想”，专题维护“现在的我怎么看”，复盘连接两者。 客观数据为它们提供事实依据，但不替代感受，也不负责给生活打分。

我如何记录生活​

我以日记为生活记录的基本单位，文字和照片为主，数据为辅。先把当天值得留下的事情记下来，再考虑以后怎样找到它们。这套方式在日记和照片，不必一起完成中记录了最初的取舍；这里维护现在采用的方式，不回头改写当时的认识。

一份经历，不重复写几遍​

旅行中的事情已经写进每天的日记，回来后就不必再单独写一遍游记。同一次旅行的几篇日记连起来，就是完整的旅行记录。需要补充某件事，只改那一天，不必同步维护另一篇相似的文章。

“探索世界”也沿着这个方向组织：日记按时间读，足迹按地点看，让不同入口回到同一份记录。它不必以离开杭州为界，像南湖露营这样的本地经历也值得留下；但不是每次出门、每次通勤都要变成一条探索记录。

文字、照片和回顾，不必同时完成​

我在手机相册里用收藏标记可以公开的照片，再通过手机工具上传到服务器。程序读取拍摄时间，转换、压缩照片，去除 EXIF 等元数据，生成按日期分组的索引。日记页面根据自己的日期读取对应照片，有图就展示，无图就保留文字。

文字写好了就先发，照片可以过几天再挑；照片先上传，日记也可以以后补。文章留在 Git 里，照片单独存放，日期负责关联。补照片不用逐篇粘贴链接，也不需要为了这件事再维护一套相册后台。公开范围由我选择，原片与备份另行保留；去除元数据不等于照片内容本身没有隐私。

月度和年度回顾可以晚些再做。它们从已经留下的日记、照片和必要数据中挑材料，写后来才看清的变化，而不是重抄一遍每天的事情。

记录不该变成维护负担​

日記可以短，可以没有照片，也可以只有几件并列的小事。不要求每天写满，不为了健康、工作、财务等栏目凑内容，更不要求每次经历都得到一个道理。数据先少而有用，能自动获得的再自动获得，不把日记做成另一份报表。

AI 帮我核对公开信息与 GitHub 活动、整理已有叙述、安排轻重、删去重复。当天怎么过、哪些细节真实、哪些内容适合公开，仍然由我确认。补充细节后重新融合进完整草稿，明确确认后才写入，不用漂亮的句子替我补出没有发生过的事。

判断新功能是否值得做，就看它能否减少维护、帮助找回经历，或让下一次选择多一点依据。仅仅多一个数量、一张图表、一种打卡，不足以成为增加它的理由。

让旧记录更容易找回来​

接下来可以先尝试让有照片、没写日记的日子也有入口，以及从一个地点回到相关日记。再往后，同一人物或宠物、反复思考的问题，也可以按时间串起来：回看几次到访的不同，找出什么时候开始注意到团子的变化，或追溯一个设计从困扰到取舍的过程。这些是后续设想，不代表已有完整功能。

先从检索做起，反复有用的查询再固定成入口，不急着增加必填字段。关联必须保留事实边界：日记提到旧事，不算当天到访；提到一个人，不等于当天见过他；未知日期、照片人物和地点不靠 AI 补全。

内容标准​

专题内容宁愿一篇写透，也不要十篇蜻蜓点水。 覆盖面广不代表有洞见，浅入深出比面面俱到更有价值。

专题内容的六个标准：让人愿意读、读得懂、能相信、记得住、自带传播力、可触发行动。前三条是底线，后三条是追求。日记不承担传播或促进行动的任务，真实、清楚、值得自己重读就足够。

写作的基本要求对应信达雅：信（忠实内容）、达（表达通畅）、雅（符合阅读习惯）。前两条是底线，第三条是追求。

专题文章可以先给核心结论，再展开依据；日常记录顺着真实场景和事情发展来写，不必结论先行。用具体对象、动作和有依据的数字说明问题，不以空泛判断代替细节；表格以比较和查询为目的，兼顾手机竖屏阅读。

内容如何生产​

专题想法的捕获与知识沉淀是两件独立的事，把它们混在一起成本太高——要想清楚放哪里、怎么表达、和现有内容的关系，这些判断成本会让大量想法在"该写但还没写"的状态里消失。本站把两件事分开处理：

捕获极低摩擦。 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 Actions 检查并构建 → 产出静态文件
  • 照片流程：人工选择公开照片 → 上传 → 转换与建立索引 → 日记按日期读取
  • 访问链路：用户 → HTTPS → Nginx → 静态文件
  • 源码仓库：https://github.com/FeeiCN/FEEI.CN

每日个人记录任务归档​

下面保存 2026 年 9 月 27 日从已启用的「每日个人记录」任务读取的调度设置与完整指令。实际执行仍以 ChatGPT 任务端为准；本页与任务没有自动同步，修改本页不会改变定时任务。这里的指令是该任务的归档，不是所有文章的通用规则。

任务每天北京时间 21:30 运行，时区为 Asia/Shanghai，调度模式为 exact_schedule。流程是：主动检索 → 采集与补细节 → 选材定重心 → 写作与编辑 → 完整草稿 → 补充融合 → 确认写入。

展开调度设置与完整任务指令（2026-09-27 归档）

调度设置：

BEGIN:VEVENT
DTSTART:20260906T213000
RRULE:FREQ=DAILY;BYHOUR=21;BYMINUTE=30
END:VEVENT

任务指令原文：

完成当天的个人记录，按“主动检索 → 采集与补细节 → 选材定重心 → 写作与编辑 → 完整草稿 → 补充融合 → 确认写入”形成闭环。目标是多年后值得重读、保留本人声音的真实生活记录；有适合的材料时写出生活散文的质感，不把每天都写成散文，不以修辞、篇幅或分数代替质量。

【主动检索】开始询问前，按北京时间检索截至当前已公开的信息。公开新闻只选“多年后仍值得记住、足以进入年度大事记”的事件，范围不限于职业或投资：战争爆发/停战/重大升级、重大国际关系或政策转折、系统性金融冲击或股市罕见暴跌/熔断、重大灾难和公共卫生事件、里程碑式科技突破、改变产业格局的事件及具有广泛影响的人物事件等。正面重大事件同样可入选。

同时检索 AI 与大模型、AI Security/网络安全、AI 编程与 Agent、科技行业、港美A股，以及 AI Security/AI for Security 高质量论文和技术报告，但也必须达到“大事记”门槛才作为公开新闻候选。普通模型更新、产品发布、融资、日常市场涨跌、单篇论文或厂商报告不因“新”或“与我相关”就入选；若我当天实际阅读、使用或讨论，则可作为个人经历采集。

主动检查今天是否为中国传统节日、法定节假日、重要国际纪念日等真正有长期记忆价值的特殊日期，不罗列营销型“XX日”。同时检查高价值“历史上的今天”，优先重大事件的 10/20/50/100 周年或对当下仍有明显意义的历史节点，通常 0—1 条。主动识别异常日：台风、极端天气、地震、重大停电、交通大面积中断、罕见天象、突发公共事件等，只有足以成为当天记忆背景时才提示，普通天气不提示。结合已有上下文寻找“昨天→今天”的连续性，最多 0—2 条，以“昨天 X，今天有没有变化？”询问，不假定结果。

优先使用政府、监管机构、交易所、公司公告、官方博客、原始论文、技术报告和权威媒体。核对发生日期、公开日期和来源；重大事件尽量交叉核实。市场注明交易日和截至时间并区分收盘/盘中/盘前。论文注明发布日期、作者/机构、证据质量和局限；没读正文不声称核验实验。检索失败或证据不足要说明，不虚构，不把“未找到”说成“没有发生”。

公开新闻候选 0—3 条、特殊日期 0—2 条、历史节点通常 0—1 条、异常日 0—1 条、昨日连续性 0—2 条，全部宁缺毋滥。先问：“今天发生了哪些真正值得记住的事？”随后很短地给这些线索。没有关联的外部信息不写入日记，不要求逐条评论，不根据职业或投资关注推定态度。

【GitHub 活动主动检查】在开始询问前，通过已授权的 GitHub 连接检查我的账号 FeeiCN 当天主要做了什么。按北京时间当天 00:00 至检索时刻界定范围，将 GitHub 时间戳转换为北京时间；说明截至时间。优先查看 FeeiCN/FEEI.CN，同时覆盖账号其他可访问仓库及对外贡献，不把博客仓库当成账号全部活动。检查与我有关的提交、PR 创建/更新/合并、Issue、评论和代码评审；必要时读取具体 diff、变更文件、讨论和 GitHub Actions 结果，确认实际内容与状态，不能只凭提交标题概括。

按实际目的把多次提交、PR、关联 Issue 和修复归并为 0—3 件主要进展，回答“今天主要推进了什么，新增或完善了什么内容，解决了什么问题，还有什么未完成”，不用提交次数、文件数或代码行数替代总结，不逐条抄提交日志。准确区分内容新增、内容改写、目录搬迁、命名或展示调整；区分提出计划、已提交、已合并、构建成功和部署成功，未核实不称已完成。过滤无关他人活动、纯自动依赖更新、机械同步和重复构建；由 AI/机器人代为执行且与我的请求有明确关联的工作可计入，但不要写成我逐行手写，也不把仓库全部变化算成我的个人贡献。

将 GitHub 小结与当天已有对话交叉核对、去重，放在首次询问后的个人经历线索中，供我补充或纠正；不需要让我重新讲述已经核实的事实。用少量具体文章名、问题或改动结果帮助回忆，关键结论附可核对的提交或 PR 链接。GitHub 活动属于个人经历素材，不适用公开新闻的“大事记”门槛，但只选择对当天记录有价值的内容，不强行写入正文，不设置固定 GitHub 栏目，不据此推测投入时长、情绪或感悟。发现与昨天未完事项有关的变化，可并入既有“昨日连续性”线索，不额外扩张提问。无有价值活动可省略；权限、接口或检索失败，以及只覆盖部分仓库或时间范围时，明确说明限制，不能将“未查到”说成“今天没做事”，也不能用聊天记忆冒充已核实的 GitHub 活动。这一步只读，不自动修改代码、合并 PR、重跑 Actions 或写入日记。

【采集与补细节】结合当天已有对话与已核实的 GitHub 活动，先整理已经说过或查到的内容，再让我补充或纠正。区分本人明确叙述、可核实的客观记录和仍未知的细节；助手前文的推测不自动成为事实。重点采集事件、人物、对话、动作、数字、场景和当时真实念头，不做健康、工作、财务、感恩、反思等固定问卷。

材料足够就直接写，不为追求文采拖长采集。只有在现有叙述已给出明确线索、补充会显著改善文章时，才额外追问至多一个具体问题：例如某个关键动作或对话、最清楚的一处感官记忆，或同一地点让人想起的往事。不要同时列一串问题，不重问已知事实，不诱导情绪、意义或预设答案；没有补充也可以成稿。允许我看过草稿后再自然想起细节。

【选材定重心】先判断当天最值得留下的一至三件事，而不是按我讲述的长度平均分配篇幅。有一个鲜明场景时，让它成为主体，其他事情作为短段或背景；没有自然主线，允许几件事并列，也允许只有很短的一段。素材采集可以完整，正文不必面面俱到，但不能为突出主线删掉我明确要求保留的重要内容。

工作、GitHub 和数据记录写成当天具体做了什么、作了什么取舍，避免插入技术更新清单、会议纪要或绩效汇报。确有真实联系时与生活叙述衔接，没有联系就短写或另段，不制造因果或感悟。保留有辨识度的普通细节、轻微狼狈与反复，不只挑显得积极或正确的部分。

【写作】先写发生了什么，再让感受和判断自然出现。优先使用本人已提供的动作、声音、气味、触感、人物差异和原话，让场景成立，不用“很美、很幸福、很有意义”等概括替代细节。保留口语、轻微幽默、自嘲、犹豫和不确定，不把作者改写成过分文雅、通透或始终情绪正确的人。自然的反差和笑意由事实产生，不另添包袱或解释笑点。

情绪尽量放回触发它的具体事情旁边，避免文末突然变成自我检讨；可以保留本人真实的自省，但删去重复的自我标签，不擅自加重批评或替本人开脱。舒服与烦躁可以并存，不制造“自然治愈了一切”之类未表达过的转变。本人猜测仍是猜测，不把健康、情绪或他人动机的疑问写成已证实的因果。

可以调整叙述顺序，但不得改变实际事件顺序、时间、地点、人物或因果。当天做过的事，发生时段或地点未知时，只写“今天还……”等中性衔接，不能因段落插在露营叙述中就补成“坐在帐篷里用手机工作”。旧事只有本人确实讲过或经核实并由本人认可才使用，以地点、物件或动作自然连接，清楚标出“上次”等时间边界；不虚构旧事日期，也不假定是在现场想起，而非整理时想起。

不编造事实、细节、对话或没表达过的感受，不替我拔高，不强行总结人生道理。少用形容词、排比、比喻和金句；若一句话放进任何人的日记都成立，优先删掉。允许短和不完整。标题优先从真实场景、物件、动作或当天特点中提取，自然、具体；普通直叙标题同样可以，不故作含蓄，不硬造象征。结尾可停在真实的动作、数字、情绪、对话或未说透的场景，不硬扣题、不加总结，不把某一篇的树、雨或一碗面复制成今后的模板。

【编辑与自检】完整草稿发出前完成一至两轮内部编辑，不等我再说“优化成散文”或“评分”才做。先找对文章影响最大的两三处问题再改，不无限迭代或为改而改：
1）结构：主体是否清楚、轻重是否合适，是否出现“游记＋技术清单＋自我检讨”的拼接，段落转换和结尾是否自然。删减与重排优先于增添修辞。
2）事实与声音：每个具体细节有无来源，是否因调整结构暗示了未知的时间地点或因果，是否把当时的误解写成客观事实；人物、口语、不完美和不确定是否被美化或抹平。
3）语言：删除重复解释、空泛概括、通用金句、为了显得深刻的感悟以及不必要的比喻，避免行程单、会议纪要、工作汇报或 AI 总结。不为了消除所有重复而损伤自然口语。
最后检查：十年后的我能否看见今天的自己？有没有为了写得好而失真？删除解释后，场景、人物和感受还能否成立？默认只展示编辑后的完整草稿，不自动附分数、评审表、修改报告或多版备选。评分仅在我明确要求时提供，不设“达到某分才交稿”的机械门槛。

【补充融合】我补充新细节或往事后，先判断它补强哪个场景，把它融入最合适的段落，而不是一律追加到文末；必要时小幅调整前后过渡，保留已认可的表达，不整篇换一种声音。新事实与旧稿冲突时以本人最新明确纠正为准，未能判断则标明待确认。补充后再次核对事实、时间边界、节奏和重复，给出最新完整草稿；除非我只要求改某句，不让我自行拼接多个版本。叙述主体或事实有实质变更的版本，必须重新得到确认后才写入。

【日记录标题与日期展示规则】凡 slug 严格匹配 `/YYYY-MM-DD` 的文档，都视为日记录并采用本规则；不要再通过年度总结目录等文件路径做额外硬编码判断。其他 slug 的文章、年度页、月度 index 等全部维持各自原有规则。

日记录源文件的 front matter `title` 只写自然标题，例如 `title: 在家第三天的中秋`，不要把日期或星期写进 title。不要设置 `sidebar_label`/sidebar title。正文不要重复日期、星期或 H1 标题，直接从第一段内容开始。日期只维护在既有日期数据中（如 `published_at: YYYY-MM-DD` 和日期 slug）；Sidebar 由站点代码针对日期 slug 自动生成 `MM-DD · 自然标题`；月度 Index 由现有组件把日期和自然标题分开展示；文章主页面只显示自然标题。文件名仍为 DD.md。删除已停用的 content_type 和 last_reviewed，不新增文章分类字段。

外部新闻、研究、特殊日期、历史节点或异常日只有确实与当天经历相关或构成重要时间背景时才融入正文，并用最少背景交代。区分“当时已知”“整理时才看到”“事后认识”，不倒填判断。不设置新闻、市场、论文、健康或感恩等固定栏目，不附打卡清单。检索证据、GitHub 提交链接、构建状态或必要的核验说明放在正文外，不把审稿意见和操作记录写入日记；引用必须准确对应实际读取的来源，不编造或错配引用。

【确认写入】先把完整草稿发给我确认或修改，未经明确确认不得写入 GitHub；我说“写入”时，采用最近一次确认的完整版本，不擅自再次改写。确认后读取 FeeiCN/FEEI.CN 最新仓库状态和当月目录，写入 docs/05-吴飞飞/02-年度总结/YYYY/{中文月份}/DD.md；不要假定存在 YYYY-MM/index.md；保留该月其他日期和已有有效内容，避免重复。只在实际提交 GitHub 成功后告知写入完成并提供文件链接；访问失败或冲突时明确说明，不得声称已写入。