博客七周年：AI 一天完成整体重构
博客从 2019 年国庆用 Xiuno BBS 搭建，到 2026 年国庆整整七年。868 篇文章、53 条评论、6060 个代码块，这次与 AI Agent 结对，一天完成从 PHP 论坛到 Next.js 的整体重构与无损迁移。
309
AI笔记本
资深 Android 开发工程师，丰富系统级应用经验，覆盖亿级用户设备，专注 AI Agent 工程化落地。白天在搞 AI 智能体，晚上回来折腾这个博客。以前的文章是从刚毕业一个字一个字敲的，现在嘛——我跟 AI 说一句话，它就写好发出来了。不信？看看最新的文章 🚀
文章列表
上下文工程（18）：总结与决策框架
《上下文工程》系列写到第 18 篇，收官。前 17 篇按"懂账 → 技术 → 评测"的顺序层层推进，每篇解决一个专门问题；但真到线上排障时，没有人按系列顺序翻文章——你手里只有一个症状：窗口爆了、账单翻倍、Agent 开…
18
上下文工程（17）：给 Agent 系列的 RAG Agent 做上下文优化
《上下文工程》系列前 16 篇各自开各的药方：预算、压缩、缓存、工具结果治理、注入纪律、评测口径。这一篇把病人请进来——优化对象是《AI Agent 开发》系列第 17 篇搭起来的 Agentic RAG（Retriev…
16
上下文工程（16）：注入攻击面与内容过滤
上下文工程讨论到现在，一直在回答"往窗口里放什么"：检索结果要标注来源，工具结果要裁剪，记忆要分层注入。这一篇换个问法——放进来的每一段内容，是否可能是别人递进来的刀？《AI Agent 开发》系列第 28 篇讲过 Ag…
18
上下文工程（15）：怎么知道注入的内容有用
《上下文工程》系列的前 14 篇都在做同一件事：设计上下文——预算怎么分配、历史怎么压缩、检索结果怎么注入、工具输出怎么治理。每篇结尾其实都悬着同一个问题：改完之后，怎么知道真的有效？多数团队的答案是"看模型回答好不好"…
18
上下文工程（14）：命中率的经济学
第 6 篇把缓存与压缩的取舍算成了一笔战术账：命中读取只要 0.1 倍输入价，而压缩改写历史会把这笔折扣亲手作废。那篇的视角是单次决策——这一轮压还是不压。这一篇把镜头拉远：当一个系统每天跑几万轮 Agent 调用，命中…
13
上下文工程（13）：100 万 token 不是免费午餐
系列前 12 篇都在教同一件事：把窗口当稀缺资源省着用——预算、压缩、缓存、子代理、检索注入，招招都是"少装"。但 2026 年的价目表很容易让人动摇：GPT6 Astra 窗口 1.05M，Gemini 3 Pro 与…
13
上下文工程（12）：Claude Code 的实践
让 Agent 修一个函数，它能径直扎进你五年没敢动的祖传模块；让它排查一个偶发 bug，它 grep 两下就锁定病灶。这类体验的背后是同一个问题：百万行代码库里，这一轮该让模型看到哪几百行？代码是上下文工程最苛刻的场景…
18
上下文工程（11）：短期、长期与工作记忆
给 Agent 补记忆的零件，这个系列已经攒了不少：第 5 篇的 compaction 教会它压缩历史，第 7 篇的文件笔记教会它记本子，《AI Agent 开发》系列第 23 篇的 Store 教会它建长期画像。但零件…
15
上下文工程（10）：RAG 信息的注入策略
RAG（RetrievalAugmented Generation，检索增强生成）链路里最容易被高估的一环是检索，最容易被低估的一环是注入。Agent 系列第 14～18 篇用五篇篇幅讲怎么把资料捞回来——切块、嵌入、混…
14
上下文工程（09）：子代理架构与上下文隔离
主 Agent 回答"这个接口的超时重试在哪实现"要付出什么代价？grep 三个关键词命中 800 行，顺着命中读了 20 个文件，再 grep 一轮确认调用方——最终答案是 200 token 的一句话，过程却烧掉近 …
11
上下文工程（08）：输出裁剪与清理策略
《上下文工程》系列前几篇反复点名同一个嫌疑人：工具结果。第 2 篇的实测账本里，24 条日志 JSON 组成的工具结果吃掉了 73% 的窗口；第 4 篇的预算拆账又把它确认为单轮成本中两三倍的大头。它的膨胀方式也特殊：用…
19
上下文工程（07）：结构化笔记（Note-Taking）模式
跑过长任务的 Agent 都经历过"失忆三连"：追问三小时前定下的口径，它翻不出来；压缩刚过，再问某个关键路径，它一脸茫然；会话重启，一切归零从头再来。对话历史看起来是记忆，其实是块易失介质——会被压缩、会腐烂、会随会话…
21
上下文工程（06）：Prompt Caching 的成本反直觉
第 5 篇讲 compaction 时，所有算式都建立在一个隐含前提上：token 越少越省钱。这个前提在 2026 年要打折扣——主流 API 的 Prompt Caching（提示词缓存）把"重复发送的相同前缀"降到…
13
上下文工程（05）：上下文压缩（Compaction）实战
跑过长会话 Agent 的人都见过状态栏上那行 "Context left until autocompact: 32%"。一个排查了 40 分钟的 bug，历史消息里堆满了文件内容、命令输出和试错的工具调用，上下文窗口…
11
上下文工程（04）：给上下文做财务规划
上下文工程系列前三篇讲的都是"往上下文里放什么"：窗口的物理极限、token 的计量方式、系统提示的信息架构。这一篇换一个视角——不先问放什么，先问放得起多少。Agent 的每一轮请求都是一张账单：system 提示、工…
14
上下文工程（03）：系统提示的信息架构设计
上篇解剖上下文窗口时留了一个尾巴：窗口里这么多内容，到底哪一块对模型行为的塑造力最强？答案朴素得近乎无聊——系统提示（system prompt）。用户消息一轮一换，工具结果用完即弃，检索片段随问题变化，只有系统提示从第…
15
上下文工程（02）：token、注意力与上下文腐烂
上一篇《上下文工程全景》把结论立在了范式层：上下文工程的核心，是把模型的上下文窗口当作稀缺资源来经营。但"经营"的前提是先懂账——窗口里装的到底是什么、按什么单位计价、为什么塞得越多效果反而越差。这一篇从范式下钻到物理层…
15
上下文工程（01）：从 Prompt 到 Context 的范式转移
《AI Agent 开发》系列 30 篇讲的是"怎么把 Agent 搭起来"：工具调用、RAG、记忆、规划，零件一一到位。但真把 Agent 放进生产环境跑长任务，问题就来了——跑着跑着开始"失忆"，重复犯过的错，忽略早…
15
FigmaToCode：私有化的 Figma 转代码插件.
设计稿转代码这件事，如今满屏都是"AI 一键生成"，但早在 AI 之前就有人把这条路走通了——bernaferrari/FigmaToCode 从 2020 年做到现在：不调 AI 模型、不连外部服务、不上传设计稿，纯确定性规则在 Figma 插件沙箱内把选中图层转成 HTML、Tailwind、Flutter、SwiftUI 等多种代码。约 5.2k Star、GPL-3.0 协议，官网口号"F…
22