让积累产生复利：我为什么做 Fgeo
太长不读：
最近整理博客，我发现最难处理的不是没东西写。
是东西太多：项目、笔记、AI 对话、半成品。
它们没有变成判断，只变成了：“以后再处理。”
上一篇文章里，我把这个状态比作认知过载。这里说的“病”，不是医学诊断，而是积累没有代谢。
我的解法不是再建一个更大的知识库，而是给积累装一条回路：
Action × Feedback × Adaptation
行动 × 反馈 × 调整
Fgeo，就是我正在做的这条回路。
AI 把东西做出来以后，反馈不能继续靠截图硬扛：我为什么做 Floop
太长不读：
AI 让我们更快地做出页面、原型和演示稿。
但做出来不等于被看懂，更不等于经得起真实用户和利益相关者的反馈。
问题不在于反馈太少，而在于反馈散在截图、聊天记录和会议纪要里，脱离了版本、页面和具体元素。
所以我做了 Floop：把交付物的版本、分享、评论和修复重新连成一个可追溯的反馈回路。
肥胖是一种病，认知过载也是
太长不读：
肥胖不只是吃多了。
认知过载也不只是信息太多。
真正的问题是：输入长期大于代谢，系统没有稳定的输出和反馈，于是身体会堆积脂肪，大脑会堆积焦虑。
知识库、书签、项目经验、RSS、AI 对话，都可能从资产变成负债。
解法不是停止输入，而是建立最低代谢：每天一点判断，每周一个作品，每次输出都进入真实反馈。
别再让 AI 把前端做成一次性原型：我为什么做 Fdesign
太长不读：
AI 写前端很快，但它经常把你的设计系统写散。
第一版像魔法，第五版像事故现场。
所以我做了 Fdesign：一个开源、local-first 的设计工程工具，让 AI 在生成 UI 前先理解 token 和组件，在生成后接受规则校验。
AI 把开发变快以后，测试不能继续靠 Excel 硬扛
太长不读：
AI 正在把开发速度拉高，但很多团队的测试管理还停在 Excel、会议纪要和口头确认。
结果就是：开发越来越快，测试越来越像最后一道人工防线，QA 背锅，Tech Lead 心里没底，老板只听到一句“应该测过了”。
testboat 想解决的不是“让 AI 多写几条测试用例”，而是让测试策略、用例、执行、缺陷、报告和版本进入同一套可追溯的工程系统。
别让旧时代的 ORM 拖累你的 AI 编程助手
太长不读：代码助手越来越懂你，但在写数据库操作时却总翻车。不是 AI 变笨了，是 Hibernate 的 N+1 陷阱和 MyBatis 的 XML 强耦合，让 AI 很难在一次上下文中写出零副作用的安全代码。在这篇《Jimmer in Action》前传里，我们聊聊为什么 AI 编程时代，你需要一个像 Jimmer 这样强类型的现代 ORM。
我的 AI 又双叒失忆了，所以我花两周做了个工具治它
太长不读：
凌晨两点跟 AI 聊出了完美方案，第二天它翻脸不认人。
我受不了了，花两周做了个开源工具 fcontext。
结果做完以后，治好的不是 AI 的失忆，是我自己的工作方式。