知识 Wiki。

真正的问题在于：我们把两个统计口径不同的指标，当成了同一个“内存占用”。这也是我想单独写清 RSS 的原因。

更准确的说法是：Profile 没有唯一的技术含义。它表示某个对象在一组维度上的完整描述。对象不同，中文意思也不同。

技术文档如果只写一个裸的 Profile，通常不是读者不懂，而是作者省略了最重要的前缀。

它适合观察同一口径下的趋势和拆解 Browser、Renderer、GPU、Utility 等进程角色，但在 Chromium 多进程架构里，把各进程 RSS 直接相加可能重复计算共享页，所以它不等于应用独占的真实物理内存，更不能单凭一次上涨就判定内存泄漏。

问题在于，不同进程可以映射同一份共享库、共享内存或 file-backed page。对单个进程看，这些页面确实属于它的 resident set；但如果把多个进程的 RSS 直接相加，同一批物理页就可能在多个进程名下重复出现。

footprint 在接收多个进程时，会把多重映射的对象去重，并把共享部分单独记账。因此，RSS 汇总和 Physical Footprint 出现明显差异，本身并不是异常。

RSS 不是“假数据”，Physical Footprint 也不是 RSS 的修正版。它们是从不同层面观察内存的两把尺子。

这也解释了为什么这份 baseline 没有拿历史报告中的 1.53–1.67 GB RSS 直接宣称“大幅下降”：历史数据的进程树、页面负载和采样口径并不完全一致。当前这组数据首先是一条可复现的基线，只有后续版本在同机、同 workload、同范围、同窗口下复测，才形成有效比较。

我现在会把 RSS 对比当成一个有前置条件的实验，而不是把两个数字直接相减。

内存泄漏会推高 RSS，但 RSS 上涨还有很多正常原因：

Profile 由 Distribution 编写，表达“我想交付什么”；lock 由工具根据 Profile 和实际解析结果生成，记录“这次精确使用了什么”。前者是声明，后者是可复现证据。

Distribution Profile 产品与发行工程团队 开发、构建或发版时 否 Build Profile 构建工程团队 执行某种构建时 否 Browser User Profile 浏览器用户 日常使用中 是 User Settings 应用用户 日常使用中 通常是

Build Kit 读取这份 Profile，再结合 lock、已经安装的 package、Chromium checkout 和目标平台 toolchain，完成后续构建与打包。

Lean Profile 也不是第四种全新的 Profile。在当前 FlyOS contract 里，lean 是 Distribution Profile 中可选的一组交付约束，例如只保留指定的 Chromium locale，或者明确排除某类 Runtime payload。

只有后续版本在同机、同 workload、同范围、同窗口下复测，才形成有效比较。

修改 Profile 后需要重新解析和刷新 lock，而不是手工把两份文件改到“看起来一致”。

simple 的主要作用是取消英文停用词和 stemming，不会自动把： text 工作区修订是不可变资产集合快照 切成： text 工作区 / 修订 / 不可变 / 资产 / 集合 / 快照

这个结果说明它不是“完全不支持中文”。索引里恰好存在的完整中文词可以命中，英文领域词也很稳定；真正不可靠的是中文自然问句。

它们不理解抽象语义，却非常擅长精确对象：函数名、错误码、配置项、订单号、API 名称和领域术语。

但语义相似不等于业务上正确。Vector Search 可能把相似概念混在一起，也可能让精确的类名和错误码沉到后面。它增加了一种召回能力，没有取代关键词检索。

别名不应该每次调用 LLM 临时生成，而应该来自项目的 CONTEXT.md 和受治理 Glossary，这样结果可解释、可重复。

第一阶段不必立刻引入昂贵的 LLM Query Planner，可以先从受治理的 Glossary 生成确定性映射

当复杂 Query 占比上升，再增加 Multi-query、Subquery Planning 和 Source Routing。只有任务复杂度值得支付规划成本时，才进入 Agentic Retrieval。

第一阶段：Query Rewrite 这是成本最低、应该最先做的一步。

先检索全部内容、再在答案阶段隐藏结果，是危险设计。

Planner 可以决定怎么搜，不能决定自己有权看什么。

一个全局 Brain 如果没有绑定 Workspace 和 Source，再高的召回率也可能意味着更严重的跨项目污染。

不要在没有 Workspace / Source Scope 的情况下把多个项目全部塞进默认 Brain。

知识库缺少证据时，系统应该返回 no_evidence，而不是用模型常识补一段看似合理的答案。

Reranker 只能重排已有候选。正确文档没有进入 Top 50，后面的模型再强也救不回来。

至少观察下面几个指标： 指标 关注的问题 --- --- Recall@5 正确文档是否进入前 5 MRR@5 正确文档排得是否足够靠前 Zero-hit Rate 中文问句是否仍频繁零召回 Citation Precision 引用是否真的支撑回答 P95 Latency Hybrid Search 增加了多少延迟 Scope Leakage 是否检索到其他 Workspace 的知识

Retrieval Eval：正确 Evidence 是否进入候选集？ Ranking Eval：正确 Evidence 是否排到足够靠前？ Generation Eval：回答是否被 Evidence 支撑？ Agent Eval：行动是否遵守 Scope、Permission 与事实？

如果后续评测证明 Embedding 仍不能满足精确中文术语检索，再给应用侧增加中文 Side Index： text GBrain Vector Search + GBrain Keyword Search + 本地 Tantivy 中文 BM25 → RRF Fusion

另一条路线是在云端 PostgreSQL 使用 pg_jieba 或 zhparser，但它增加了数据库扩展和部署运维复杂度，不适合当前以本地 PGLite 为主的 MVP。

中文检索应通过真实 Query Eval 判断是先做 Rewrite、Multilingual Embedding，还是增加中文 BM25 Side Index。

当前官方文档的规则是：仍然存在的 DOM 元素可以在后续快照和同一文档更新中保留引用；页面或 iframe 导航、元素替换会影响引用有效性。没有对应 DOM 节点的虚拟无障碍节点，其引用只适用于当前快照。

- Page、Tab、Window 的稳定身份； - 导航前后元素引用何时失效； - Frame 和弹窗如何归属； - Screenshot、DOM Snapshot 与当前页面是否来自同一时刻；

getFullAXTree() 的 full 也不等于自动解决所有跨进程 iframe，跨 frame 支持仍需由具体执行器单独验证。

引用省去了为每一步重新编写 selector 的工作，但它不是商品 ID、订单号，也不是跨页面永久有效的地址。

snapshot -i 偏向可引用的操作目标，“有货”这样的普通结果文字可能被排除；某些标题和表格单元格能够留下，也不保证所需字段完整。找动作目标时可以压缩观察，检查业务结果时则需要保留相关正文、状态或表格内容，不能把“交互快照里没出现”理解为“页面没有”。

结果可验证 参数与业务结果能否通过 AX 再次确认？ 保留受阻或未验证状态，不以调用成功替代业务结果

这里存在一个重要边界：BrowserOS 源码能证明这些组件和调用关系存在，但不能仅凭静态源码证明每个网站、每个模型、每个任务都能可靠完成。任务成功率仍然需要基于真实任务集、Provider 和环境做运行时评测。

列表重排或复用节点 核对该控件所属的业务记录，不能只看引用是否仍可解析

那么 Extension + Local Server 通常是成本更低的选择。先验证用户是否真的需要 Agent 完成这些任务，再决定是否接管浏览器底座。

代价也很明显：一旦 fork Chromium，就要长期维护 Patch Stack、解决上游冲突、承担跨平台编译和安全更新压力。fork 不是“更高级”的默认答案，它只是用更高的维护成本换取更深的产品控制权。

若流程长期固定、定位条件清晰、主要目标是回归测试，也可以继续使用现有自动化测试工具，不必为了引入 Agent 而改写成熟流程。

缺少必要语义时，可以明确转入混合观察，也可以保持 AX-only 并报告受阻；两者都需要如实记录实验条件。

本站只用 Accessibility Tree，浏览器 Agent 能走多远？核验的是 @mastra/agent-browser 0.4.1 与 agent-browser 0.19.0 的组合，那条路径通过 Playwright ariaSnapshot() 生成工具快照。本文核验的上游 0.41.1 Chrome 原生路径直接读取 CDP AX Tree。工具名和命令相似，不能代替对依赖版本及真实调用链的检查。

本文以 BrowserOS 仓库的 5ddb0f2d0 commit 为源码快照。BrowserOS 后续会继续变化，固定 commit 能让文中的目录、代码和发布流程保持可复查。

本文讨论通用机制和设计判断；示意不对应任何具体产品的已交付状态。源码阅读坐标沿用原稿，本次整理不构成新的运行时验收。

本文按 2026 年 11 月 1 日核验的上游 0.41.1 版本与官方文档解释，默认讨论 Chrome / CDP 路径。已有系统若固定在旧版本，需要分别核对实现，不能把新版原理直接套到旧适配器上。

缺少必要语义时，可以明确转入混合观察，也可以保持 AX-only 并报告受阻；两者都需要如实记录实验条件。

若它只是一块没有名称的图形，单靠这份语义观察可能无法确定用途，需要补充截图、上下文或其他受控读取。

截图能帮助判断图标、布局和视觉遮挡；是否将它作为模型输入、怎样结合语义结果，仍由调用方决定。

- Screenshot、DOM Snapshot 与当前页面是否来自同一时刻；

当 AI 把实现和生成的成本迅速压低，真正稀缺的能力开始转向问题选择、方案取舍、边界判断与结果验收。

我现在用五类选择理解 Taste： 判断 要回答的问题 --- --- 问题选择 这是一个真实问题，还是一个热闹概念？ 目标与层级 用户第一眼应该看见什么，完成什么？ 取舍 哪些能力、装饰和表达应该被删除？ 边界 稳定性、性能、可访问性和业务约束在哪里？ 完成标准 什么证据足以证明它可以交付，什么仍然只是 Demo？

这段过程让我确认了一件事：设计风格首先是一套删减规则。 如果一套风格只告诉 Agent“可以用什么”，它很快就会把所有特征同时用上。真正能提高输出稳定性的，是同时写清楚“最多用多少”“只能用在哪里”“什么情况下不要用”。

AI 很擅长生成看起来完成度很高的界面，但如果提示词只有“高级、简洁、科技感”，结果通常会收敛到几种熟悉套路：高饱和蓝紫渐变、纯黑科技背景、玻璃卡片层层嵌套、发光描边和胶囊按钮。

青山湖设计风格的核心，不是把界面染成绿色，而是把青山湖的自然层次翻译成数字产品的职责分工：雾白负责空间与材质，湖水青负责操作，水杉绿负责状态，青山灰蓝负责信息层级，晨光金只负责极少量高光。

经过几轮实战后，青山湖不再是一组零散的 hex，而是逐渐形成了 Seed → Map → Semantic → Alias 的 token 架构。

最后采用的是纯 SwiftUI 内部绘制： - 大面积雾白柔焦带； - 左上角雾白 soft blur； - 右下角很淡的湖水青 blur； - 所有效果裁剪在卡片内部； - 不使用 NSVisualEffectView； - 不使用 .behindWindow 或 .underWindowBackground。

这也是 Taste：知道哪个体验必须保留，哪个实现可以妥协，并让审美服从稳定性、性能和可读性。

只在一个产品里成立的规则，还只能叫项目风格。 后来我把这套语言迁移到“小界”的 Web 工作台。平台从 SwiftUI 变成 React、Umi、styled-components 和 Tailwind，产品形态也从 macOS menu bar 工具变成 AI 控制台，但核心映射依然成立

迁移过程中，设计体系又吸收了 Web 产品的新约束：正文默认 14px、工具栏控件 32–36px、桌面优先但窄屏不溢出、动效支持 prefers-reduced-motion，以及资源统一使用 WebP。

把两边都染成青绿色没有迁移价值。跨端复用的是同一套判断：低噪声画布、清晰的信息层级、克制的状态色、不过度装饰的 glass surface，以及让内容始终压过背景的优先级。

这次抽取没有把同一套界面复制到六个平台。共享的是一套 semantic vocabulary：canvas、surface、text、primary action、focus、success、warning、error，以及明确的 anti-pattern；各平台仍然遵守自己的交互模型和验收方式

值得上：AI 控制台、桌面效率工具、settings、数据 dashboard、menu bar 与 floating panel。这些场景需要稳定、清透、低噪声，又不能完全失去品牌辨识度。 可以再等：强营销 landing page、娱乐化社区、需要极强情绪刺激的消费产品。

重点关注：不要让 Agent 把设计系统退化成 palette。每次迁移至少检查四层：语义 token、信息密度、组件形态和 anti-pattern。只换颜色，不算迁移完成。

它的反模式同样明确： - 不是贴一张青山湖照片； - 不是把所有组件改成青绿色； - 不是处处 glassmorphism； - 不是用大面积留白制造“高级感”； - 不是遇到层级问题就再套一张卡片； - 不是牺牲稳定性去追求系统材质效果。

不能替代： 涉及安全、合规、数据正确性和复杂系统边界时，Taste 不能替代专业知识、工程验证和责任机制。好判断必须建立在真实约束上。

当这些规则被写进 DESIGN.md 和项目级 AGENTS.md，审美才从一次性的聊天上下文，变成可以在下一次会话继续生效的工程资产。

Remember：记住拒绝过什么 只保存“最终用了什么”还不够。很多一致性来自对失败经验的记忆：为什么不再用大面积金色，为什么不恢复高风险系统材质，为什么数据页面不铺云雾，为什么不做纯黑科技风。

比如本文封面先由图片模型生成无文字的青山湖氛围底图，再用 HTML/CSS 确定性排版标题，最后转成 WebP 并记录生成 metadata。模型负责打开视觉可能性，工程流程负责保证文字、尺寸和交付结果没有靠运气。

这三层刚好对应 Taste 的三个动作：先扩大看过的世界，再把选择写成约束，最后把约束变成稳定产物。

我的判断框架 青山湖风格值得继续用，但不是所有产品都应该用。

AI 能不能帮助人提升 Taste？ 可以，但不要把最终选择也外包给模型。

它不证明 Taste 可以被 AI 自动拥有；它证明的是另一件更务实的事：人的判断可以被外化成 Agent 能读取、实现和验收的约束。

同一条事实对不同 Claim 的证明力完全不同。Evidence 的证明力始终相对于 Claim而存在。

Trace: Agent 调用了 deploy()，接口返回 accepted Claim: 新版本已经在生产环境生效 前者不能直接证明后者。

“任务已完成”只是一条 Claim，不是事实。 真正的验证应该回到权威系统重新读取状态。

这使“完成”从自然语言变成可执行的 Acceptance Contract。

Artifact 存在，只能证明有交付物；它不能自动证明交付物正确。

Evidence 是事实材料，Evaluation 是依据规则作出的判断。

聊天记录可以参与恢复，但它不是完整 State；Trace 可以帮助调查，但它不自动构成 Evidence；Evidence 能证明一次交付，却不能替代跨版本的 Eval。

Evidence 是从 Trace、Artifact 和权威状态中挑出的、足以支撑 Claim 的最小集合。

大多数生产系统应该先做到 L3，不必一开始追求 L4。

读取 Checkpoint ↓ 校验 Contract Version 与 Workspace Revision ↓ 检查上一个 Side Effect 是否已经生效 ↓ 用 Idempotency Key 决定复用结果还是重试

内部 runId 是事实主键，Provider Session ID 只是 ExternalRunRef。

重试只能作用于已声明幂等的边界。否则“失败后自动重试”可能变成重复扣款、重复发信或重复发布。

- Evidence 本身有效，但与 Claim 无关； - 两条有效 Evidence 相互冲突； - Evidence 支持 Claim，但覆盖范围不足；

8. 出现冲突、过期或撤销后，旧结论能否重新计算？

换句话说，Checkpoint 不只是保存 JSON，还要知道它由哪一版代码解释。

OS、CPU 和 ABI 决定“能不能跑”，package format 决定“怎么装”，channel 决定“拿哪条版本线”。

因此，磁盘 offset 变化不一定是错误；非资源 section 的 RVA、大小或内容变化，则必须高度警惕。

这也解释了为什么 Chromium 文档里会出现“Chromium Updater 轮询 Omaha Server”这种句子：前者是本机执行者，后者是云端决策者。

这里有一个很重要的责任边界：浏览器启动参数只能调整 Chromium 接受的那部分 Runtime 行为。

这次实现采用 fail-closed 策略。只有同时满足以下条件，兼容路径才会启用： 1. PE 中存在资源 section。 2. .rsrc 之后除了 .reloc，只多出一个 .bun。 3. 写入新资源后，整个 image 的虚拟大小不变。 4. 所有非资源 section 的名称、RVA、virtual size、raw size、attributes 和二进制内容不变。 5. 重新解析输出文件后，所有目标 VERSIONINFO 字段与预期值一致。

这里刻意没有把 PointerToRawData 设为不变量。.rsrc 增长时，后续 section 在磁盘文件中的位置可以移动；只要 PE Header 正确反映新位置，Loader 仍能读取它。兼容层需要锁住的是虚拟布局与 payload 内容。

原始 resedit 解析这份文件时会抛出错误： text After Resource section, sections except for relocation are not supported

如果目标 executable 需要 Authenticode，顺序也必须固定： 签名后的 PE 再被修改，原签名就不再对应当前文件内容。

不过，“同属 AArch64”仍不等于二进制可以跨 OS 直接运行。一个 macOS arm64 Mach-O executable 不能因为 CPU 相同，就直接当作 Linux arm64 ELF executable 使用。OS API、object format、ABI 与 system library 仍然不同。

所以“架构兼容”只是必要条件，不是充分条件。发行工程真正要验证的是整条 artifact：可执行文件、动态库、native addon、插件、安装器和更新器都必须对齐。

这条异常来自 resedit 底层 PE library 的保守假设：资源 section 之后只接受 relocation，并不表示 Bun executable 已损坏。

这个处理范围很窄：放行的是已经识别并验证过的 Bun 布局，不是把任意 PE 都交给宽松解析器。

服务端不会把安装包塞进 Update Check 的 JSON response。它先回答 noupdate 或 ok；当有新版本时，再提供 nextversion 与一组按优先级排列的 pipeline。

下载成功只能证明一串 bytes 到了本地；Chromium Updater 还要校验大小与 hash，处理 CRX3，执行 installer，并根据 user/system scope 处理权限、进程和安装状态。

本地模型显存不足、Native Host 内存泄漏、Extension 事件丢失，不能靠给所有 Renderer 加大堆上限来统一“治疗”。

它不会在启动时立刻分配 4 GB，也不会自动降低 RSS，更不会修复对象长期存活、跨进程重复缓存或 Native Runtime 泄漏。

从 Chrome 136 开始，--remote-debugging-port 和 --remote-debugging-pipe 在默认 Chrome User Data Directory 上不再生效，必须同时指定非默认目录。

- 不把 Remote Debugging 接到用户日常 Profile； - 每个并行 Run 使用唯一目录，不共享同一个 C:\Temp\profile； - Harness 优先使用 Pipe；必须用 Port 时，让 Runner 分配和回收，不固定写死 9222；

- [ ] Start Menu、Desktop、Taskbar shortcut 的 Arguments 都为空； - [ ] 首次启动和重启后没有 unsupported command-line flag 警告； - [ ] chrome://version 中 Browser Process 没有 --no-sandbox、--disable-gpu、Remote Debugging 或证书绕过参数；

子进程会带 Chromium 自己生成的 --type= 等参数，因此只筛选没有 --type= 的主进程

真实 artifact 验证完成后，仍不能把 macOS 上的结构检查描述成 Windows 原生验收。正式发布还需要在 Windows 上启动 executable、回读 File Properties 或 PowerShell VersionInfo，并在 metadata 修改之后完成 Authenticode 签名。

截至 2026 年 8 月 25 日，这份公开文档仍标注为 draft；真正实现时应固定到所使用的 Chromium commit，而不是假设 main 永远不变。

CUP public key 必须在构建期进入客户端 trust root，服务端必须正确保管对应 private key，还要为旧客户端设计 key rotation 与历史 key 兼容。

- [ ] 每次 Chromium baseline 升级后重新跑 GPU、Sandbox、Profile、Automation 与 Memory Regression。

这轮改动之后，我更确定一件事：本地 Agent 工具的性能优化，重点不是把某一次 query 跑快，而是把刷新语义、数据计算和 UI 发布拆开管理。

FlyOS 性能治理真正需要的，不是寻找一个万能数字，而是把进程结构、系统压力、运行时分配和用户体验连成一条证据链。

这件事看起来是视觉微调，实际很像前端工程里的控制问题：动画有了不代表体验变好了。

这相当于一个 trailing-edge coalescer。它允许短时间内的事件合并，又保证「刷新期间发生的最后一次变化」不会消失。对本地日志同步来说，这比无限取消的 debounce 更符合数据正确性。

此前这些 UI surface 共用一份 analytics reload，打开菜单栏也可能触发全套 dashboard 查询。优化后把 snapshot 分成两类：

当用户点开菜单栏时，先从已经落到本地 SQLite 的数据快速加载 surface snapshot，再在后台走 adapter 增量同步。用户看到的是立刻可用的旧但可信数据；同步完成后再应用新结果。

这一步很朴素，但它把“数据库读到一个结果”与“UI 需要看到一次新状态”明确区分开了。

检测到活跃 Agent：每 3 秒检查并按需同步 没有活跃 Agent：30 秒才做一次兜底刷新 文件观察事件：立即合并到下一次刷新

这里有一个容易犯的错：没有 trace 就先宣布“快了 X%”。这次我没有编造一个漂亮数字，而是把验证拆成三个层次：

最后我把层级选择暴露到了设置里：默认用最稳的普通窗口，用户可以自己切到浮动或桌面组件风格。这个决策不够“产品洁癖”，但足够工程务实。

这就是为什么透明 panel 要同时处理两层： 层 要处理什么 ------ SwiftUI view clipShape、背景、边框、视觉层次 AppKit hosting/container clear background、cornerRadius、continuous corner、masksToBounds

原因很简单：灵动卡本身已经是一个透明 NSPanel，再叠系统 material 和特殊 window level，变量太多。为了排查和发布稳定性，先减少系统合成路径。

灵动卡需要接近 macOS 桌面小组件的玻璃质感。最直接的实现是 NSVisualEffectView、系统 material 和 behind-window sampling，但这条路径曾经触发打开即崩。为了稳定性，我们一度把它降级成普通的浅色 panel，结果功能稳定了，气质也一起消失了。

但从事故恢复看，持久化会放大问题：如果“打开灵动卡”本身会崩，那么应用每次启动自动恢复灵动卡，就会变成“打开应用即崩”，用户连进设置关闭它的机会都没有。

最后我选择恢复持久化和默认打开，但把默认 window level 降到普通窗口，并把高层级选择放到设置里。这不是绝对安全，但比“默认走最高风险路径”合理得多。

所以这类 bug 不能只问“为什么我不复现”。更有效的问题是：哪些系统路径只有对方会走到？哪些设置会让用户每次启动都自动进入危险路径？

这相当于一个 trailing-edge coalescer。它允许短时间内的事件合并，又保证「刷新期间发生的最后一次变化」不会消失。对本地日志同步来说，这比无限取消的 debounce 更符合数据正确性。

此前这些 UI surface 共用一份 analytics reload，打开菜单栏也可能触发全套 dashboard 查询。优化后把 snapshot 分成两类：

这一步很朴素，但它把“数据库读到一个结果”与“UI 需要看到一次新状态”明确区分开了。特别是 3 秒一次的活动探测中，绝大多数轮次的活跃会话并没有变化；这时只要不写回 activeSession，就不会无端唤醒整棵视图树。

检测到活跃 Agent：每 3 秒检查并按需同步 没有活跃 Agent：30 秒才做一次兜底刷新 文件观察事件：立即合并到下一次刷新

最后我判断：在这个产品场景里，彩带收益不够高。Argos 是一个 macOS 工具，不是游戏结算页。彩带一旦做不好，负收益很明显。所以最终删掉。 这个决策很重要：粒子系统不是越复杂越高级，删掉不稳定元素也是工程能力。

也就是说，random 只是 variation，不是 composition。

这也是为什么 FlyOS 同时采集两条线： bash 拆解进程角色，并得到每个进程的 RSS ps -axo pid=,ppid=,rss=,%cpu=,command= 对同一组 PID 做 macOS Physical Footprint 统计 footprint -j result.json -f bytes --noCategories footprint 在接收多个进程时，会把多重映射的对象去重，并把共享部分单独记账。因此，RSS 汇总和 Physical Footprint 出现明显差异，本身并不是异常。

因此，“跑一次后 RSS 比之前高”最多是一个调查信号，不是泄漏结论。更可靠的链路应该是：先固定 workload 和进程范围复现趋势，再用 heap snapshot、allocation profile、对象数量、GC 后基线和进程生命周期去定位原因。

如果你确实要做桌面小组件式 surface，可以上玻璃质感，但默认路径要克制。我的建议是：默认普通层级 + 安全 blur + 可选高级层级。等收集到足够多真实设备反馈后，再决定要不要把更像系统小组件的层级设为默认。

最后采用的是纯 SwiftUI 内部绘制： - 大面积雾白柔焦带； - 左上角雾白 soft blur； - 右下角很淡的湖水青 blur； - 所有效果裁剪在卡片内部； - 不使用 NSVisualEffectView； - 不使用 .behindWindow 或 .underWindowBackground。

我会怎样验证这类优化 这里有一个容易犯的错：没有 trace 就先宣布“快了 X%”。这次我没有编造一个漂亮数字，而是把验证拆成三个层次： 1. 行为正确性：并发事件不会丢最后一次更新；手动刷新与自动刷新不会并发重入。 2. 数据正确性：没有 delta 时不改 analytics；有 delta 时会重新读取对应 scope。 3. 运行时证据：用 Instruments 观察主线程占用、SwiftUI update 原因，以及菜单栏打开和仪表盘切换时的 SQLite 查询量。

GitHub Apps 可以被直接安装到组织或者用户账号上，并且可以赋予它们访问指定仓库的权限。它们带有内置的 webhook 和狭窄的特定权限。

按“DNS 解析 → 本机代理 → 网络出口 → Git 配置”的顺序排查。hosts 只应作为明确、临时且可回滚的诊断手段，不是长期方案。

NPM Token 是不能被别人看到的，为了达到这个目的，首先项目需要设置为私有的，然后将 Token 放到 .env 中，通过 process.env.NPM_AUTH_TOKEN 获取。另外谨记不要在日志中打印环境变量。

如果把 GitHub App 发布为 public 的，那么任何仓库都可以安装该应用，这不是我们想要的结果。解决办法有两个，一是将应用注册为 private 类型的，二是在监听回调中判断是否是允许的组织或者用户。我选择的是第二种方案

避免采用：从第三方网站抄 IP 后长期写 hosts。它可能短暂恢复访问，却会在下一次基础设施变更时再次失效。

公司网络下应优先使用合规的网络出口或咨询网络管理员，不要把公共 IP 固化进 hosts。

lerna 管理版本由于是一次可能发布多个仓库，所以无法使用上面提到的发布流程。

如果浏览器能打开而 Git 失败，重点检查 Git 的代理配置；如果两者都失败，则更可能是 DNS、代理客户端或网络出口的问题。

HTTPS 网络策略不稳定、且账户已配置 SSH key 时，可以将远程地址切到 SSH

ssh -T git@github.com 这不会绕过网络限制，但能避免 HTTPS 凭据与代理配置的额外变量。

if (result.type === 'none') { app.log.error( You can't publish duplicate version ${result.package}@${result.version}, ); }

await execSh( cd ${cloneTempDir} && npm install && npm run build && ./node_modules/.bin/lerna publish from-git --yes --no-verify-access, );

这不会绕过网络限制，但能避免 HTTPS 凭据与代理配置的额外变量。

TaleFrame 的服务端采用一个 Next.js 项目。管理员页面与 API 放在一起，共享输入校验、内容模型和发布逻辑。部署时也只有一个服务端项目需要处理。

Neon 是独立的数据库服务。即使通过 Vercel 的集成入口创建或连接数据库，数据管理仍由 Neon 承担。Vercel 的存储文档也区分了 Blob 等产品与外部数据库集成。

服务端通过环境变量取得连接信息，在处理请求时访问 Neon；数据库凭证和 Blob 写入凭证不会下发给 Android。

这样的组合保留了客户端选择权。App 通过 HTTPS 读取目录、正文与图片，服务端使用 Next.js 不会把 Android 变成跨端应用。将来增加其他客户端，可以复用内容接口；各端交互仍然需要分别实现。

发布逻辑读取该书已保存的章节，计算每章正文的 SHA-256。新的正文版本写入 chapter_versions；同一章节、相同哈希已经存在时，不重复插入。 随后创建发布快照，把书目信息与章节引用保存到 releases，更新 books.published_release，并递增目录版本。相关更新在同一数据库事务中提交。

正文版本按“章节 ID 与内容哈希”去重。只修改一章时，其余章节可以复用已有正文版本；发布快照保存引用，无需每次复制整本正文。当前保留最近五次发布，回退通过切换已发布快照完成，也不会覆盖编辑中的草稿。

目录接口使用 ETag。App 带着上一次的标记请求，如果目录未变，服务端返回 304；如果发生变化，客户端先解析和校验新目录，再替换本地文件。解析失败或网络中断时，保留上一份可用目录。

正文下载后会核对 SHA-256，通过后才进入缓存。缓存键包含正文版本，同一章节被修订后不会误读旧文件。当前缓存上限为 100 MB，按最近读取情况淘汰旧内容；这个数值是本项目的选择，不是阅读 App 的通用标准。

当前目录包含所有已发布小说及其章节引用，不是仅含书名的轻量首页，也没有目录分页和增量补丁接口。这降低了首版实现复杂度，但书库继续扩大时，需要测量目录响应体与解析耗时，不能只关心正文占用。

重点关注的变化，是全量目录变大、数据库回源压力、真实地区网络可用性，以及付费内容或视频进入产品。这些变化会影响现有边界：目录可能需要拆分，正文分发可能需要调整，漫剧则需要重新测量视频存储与播放成本。

这仍然是单管理员后台。读者账号、会员权限、支付、跨设备阅读进度尚未实现。需要这些能力时，应重新设计身份与授权模型，不能把管理员密码机制直接扩展成面向所有读者的账号系统。

这也是 TaleFrame 暂时保留 Coming Soon 的原因。漫剧会增加视频存储、转码、播放与分发问题，小说正文的成本测量无法替视频业务作判断。

好看的关键不是“粒子越多越好”，而是让粒子的出生位置、生命周期、运动方向、密度分布、视觉层级服务同一个动势。

Emitter 是粒子系统里的发射器。它决定粒子从哪里出生。

所以云雾层需要满足四个约束： 约束 实现选择 --- --- 不影响交互 pointer-events: none 不挤压内容布局 position: absolute，不放进正常 flow 永远在内容下方 雾层 z-index: 0，内容容器 z-index: 1 动画成本可控 只动 transform 和 opacity

这里我刻意只用了 transform 和 opacity。它们通常可以由 compositor 处理，不会每一帧触发布局计算。

Streamers / 彩带 否 方向、曲线、交叉都很难调，容易显脏 Burst / 爆点 否 在这个场景里太像烟花，不符合 macOS 工具气质 Heavy bloom / 大光晕 否 容易污染画面，让文字和桌面背景变糊

最后我判断：在这个产品场景里，彩带收益不够高。Argos 是一个 macOS 工具，不是游戏结算页。彩带一旦做不好，负收益很明显。所以最终删掉。

/ 调整后：云团收进安全区，边缘交给页面底色 / inset: 5%; opacity: 0.82;

这也是我这次最有价值的判断：背景动画的优化，大多数时候不是“做得更多”，而是“让它少出现一点”。

这次最终我同时做了两件事： 1. 提高粒子数量：彩纸、亮片、星芒都增加。 2. 扩大覆盖区域：横向更接近全屏，纵向从中下区域扩到中上/中下区域。 这才让画面变“满”。如果只加 count，不改 distribution，只会更乱。

random 只是 variation，不是 composition。

真正起作用的不是某一个色值，而是三层关系： 1. 形状不规则：每个 gradient 的大小和位置不同，避免出现一眼可识别的圆形光斑。 2. 透明边界足够长：色彩在 76% 到 82% 之间才消失，云团会更像在空气里扩散。 3. 两层方向相反：一层从左下缓慢移动到右上，另一层反向移动，页面才有轻微的深度感。

调参时优先收束可见范围和对比度，而不是继续增加颜色或动画。

适合用的场景： 1. 用户完成一个阶段性目标。 2. 系统需要表达奖励。 3. 状态变化低频且重要。 4. 动画不会打断用户工作流。 不适合用的场景： 1. 高频反馈。 2. 错误提示。 3. 信息密集页面。 4. 用户正在专注输入或阅读。

- 值得上：空状态、Agent 对话页、工作台欢迎页这类内容稀疏但需要建立产品情绪的界面。用低对比、慢节奏的环境层补足空间。 - 可以再等：数据密集的列表、表格和监控台。那里信息密度已经够高，背景动画多半只会制造噪声。

此外，生产页面还应该补一条 prefers-reduced-motion，让用户可以在系统层面关闭或静止这类环境动画。审美不能覆盖可访问性偏好。

粒子系统本质上是每帧根据时间计算位置，然后画出来。Canvas 更贴近这个模型。

elapsed 是整个系统的时钟。每个粒子根据 elapsed - delay 算自己的局部时间，再算 position、rotation、opacity。

1. 停在任意时刻都成立：截取动画中的任意一帧，内容层级都清楚，不能依赖某个刚好干净的瞬间。 2. 连续看 10 秒不烦：如果能明确察觉云团在左右移动，节奏已经太强；正确的感觉应该是视线离开后才意识到页面在呼吸。 3. 性能面板没有持续压力：确认动画只涉及合成友好的属性，并在低性能设备上观察掉帧和 GPU 占用。

无缝循环的坑：GIF 要循环不跳帧，durationInFrames 必须是「一个完整动画周期」的整数倍，也就是 framesPerSprite 5 的倍数。

当速度随帧动态变化时，Math.floor(frame / framesPerSprite) 里的 framesPerSprite 每帧都在变，除法结果不再单调递增，sprite 会跳帧。严格正确的做法是对速度做相位累积（把每帧的换帧增量累加起来），而不是简单除法。

做匀速 demo 可以偷懒用除法，做严肃动态动画就得老实累积。

你要的是一个常驻 macOS 菜单栏、读真实 CPU 的原生小猫——那 Remotion 不是答案，老老实实用 Swift（RunCat 本体）或 Tauri/Electron。Remotion 造的是动画资产，不是系统进程。

脚手架层（省时间）：起项目、配 Composition、连 public/ 资源、写渲染脚本，这些样板活它一把梭。

翻译层（省脑子）：把 RunCat 那句 Swift 的命令式 index++ 翻译成 Remotion 的声明式取模，这种「换范式重写」是 AI 的强项——你给它源码逻辑，它给你目标框架的地道实现。

但「取模换帧」的原理、「相位累积」的坑、无缝循环的数学——这些判断你得心里有数，否则 AI 给的代码你既 review 不了也调不动。这也印证了我一直的观点：AI 拉满执行力，判断框架还得是自己的。

新公司入职有两个月了，独立负责了两个不大的中台项目，技术栈是基于 umijs 的

后期我也会继续输出跨平台相关的技术分享。

作为一个从前端转 Agent 开发的人，我一直好奇：这种逐帧 sprite 动画，能不能用现代 React 工具链声明式地复刻出来？

"main": "dist/cjs/index.js", "module": "dist/es/index.js", "browser": "dist/umd/index.js", "types": "dist/es/index.d.ts"

export default [ // browser-friendly UMD build { input: "./src/index.ts", // 输出 output: { file: pkg.browser, // 文件 format: 'umd', // 格式 name: 'refined-components', // 生成包名称，代表你的 iife/umd 包 }, },

我们实现的具体逻辑是，当 Probot app 监听到 release.released 事件时，处理发布前的操作。重要的是我们需要根据 package.json 中的 version 字段匹配出 tag

const downloadDefaultBranch = ${repo.full_name}${context.payload.release.tag_name};

组件库比较大时，我们可能需要让我们的库支持 tree-shaking。那么你就不能将所有的文件都打入到一个文件中。rollup-plugin-multi-input 便是一个将打包产物输出到各自的文件中的插件。

注意：因为产物是多文件，所以需要用 dir 属性指定文件夹。

// 如果用了 rollup-plugin-node-resolve， 则必须将它放在 typescript 插件前面

globals: { 'react': 'React', 'react-native': 'reactNative' },

NPM Token 是不能被别人看到的，为了达到这个目的，首先项目需要设置为私有的，然后将 Token 放到 .env 中，通过 process.env.NPM_AUTH_TOKEN 获取。另外谨记不要在日志中打印环境变量。

如果把 GitHub App 发布为 public 的，那么任何仓库都可以安装该应用，这不是我们想要的结果。解决办法有两个，一是将应用注册为 private 类型的，二是在监听回调中判断是否是允许的组织或者用户。我选择的是第二种方案

1. 判断 push 分支是否是主分支且提交信息包含 chore(release): publish 2. 因为是 lerna publish，所以需要使用 simple-git 这个库 clone 项目。 3. 由于 lerna publish 不支持 token，我们采用将 //registry.npmjs.org/:_authToken=${process.env.NPM_AUTH_TOKEN} 写入 .npmrc 的方式完成带 token 的发布。

await execSh( cd ${cloneTempDir} && npm install && npm run build && ./node_modules/.bin/lerna publish from-git --yes --no-verify-access, );

output: [ { dir: './src', format: 'cjs', exports: 'auto' }, { dir: './src', format: 'es' } ],

src - A.ts - B.ts - index.ts - dist - A.js - B.js - index.js

context.payload.head_commit.message.indexOf('chore(release): publish') === 0

const isTuya = context = { const { full_name } = context.payload.repository; return full_name.startsWith('youngjuning') full_name.startsWith('tuya'); };

其实答案显而易见，yarn.lock 文件属于 VS Code 标准文档模型，我们选用最简单的自定义文本编辑器即可。

而 vscode.CustomTextEditorProvider 这个接口只有一个方法 resolveCustomTexEditor。所以原理上我们只需要实现 resolveCustomTexEditor 这个方法即可。

"viewType": "yarn-lock-preview.yarnLock", "displayName": "Preview yarn.lock", "selector": [ { "filenamePattern": "yarn.lock" } ], "priority": "option"

This extension consists of 1060 files, out of which 1049 are JavaScript files. For performance reasons, you should bundle your extension

加载 100 个小文件要比加载一个大文件慢得多。这就是我们推荐捆绑的原因。

在 从零开发一款基于 webview 的 vscode 扩展 中我们讲述了使用 esbuild 打包可以减小打包产物的体积以及加快调试速度。

虽然本文的例子是基于 umijs 开发 webview 的内容，但是其他技术原理是一样的，紫升在后续也会提供多个技术的 vscode webview 开发脚手架。

本着重复的工作都可以用脚本代替的原则，我 vscode 插件开发的最佳实践沉淀为了一个脚手架，执行 yarn create @luozhu/vscode-extension 即可快速开始开发 vscode 扩展。

我现在用五类选择理解 Taste： 判断 要回答的问题 --- --- 问题选择 这是一个真实问题，还是一个热闹概念？ 目标与层级 用户第一眼应该看见什么，完成什么？ 取舍 哪些能力、装饰和表达应该被删除？ 边界 稳定性、性能、可访问性和业务约束在哪里？ 完成标准 什么证据足以证明它可以交付，什么仍然只是 Demo？

这段过程让我确认了一件事：设计风格首先是一套删减规则。 如果一套风格只告诉 Agent“可以用什么”，它很快就会把所有特征同时用上。真正能提高输出稳定性的，是同时写清楚“最多用多少”“只能用在哪里”“什么情况下不要用”。

这段过程让我确认：设计风格首先是一套删减规则。 如果只告诉 AI“可以用什么”，它会很积极地把所有特征一起用上。输出真正开始稳定，是因为规则同时写清了“最多用多少”“只能用在哪里”“什么情况下不要用”。

最后采用的是纯 SwiftUI 内部绘制： - 大面积雾白柔焦带； - 左上角雾白 soft blur； - 右下角很淡的湖水青 blur； - 所有效果裁剪在卡片内部； - 不使用 NSVisualEffectView； - 不使用 .behindWindow 或 .underWindowBackground。

这也是我现在判断视觉方案的一个原则：设计语言不能绕过工程约束，好的设计 token 应该能在安全实现与理想效果之间找到可迁移的中间层。

后来为了让灵动卡接近系统组件的玻璃质感，我们尝试过 macOS material 和窗口采样，特定组合会带来稳定性风险。最后我没有放弃“雾”，也没有为了视觉效果继续赌系统边界，而是改用纯 SwiftUI 绘制柔焦层：保留雾白的视觉职责，换掉高风险实现。

迁移过程中，设计体系又吸收了 Web 产品的新约束：正文默认 14px、工具栏控件 32–36px、桌面优先但窄屏不溢出、动效支持 prefers-reduced-motion，以及资源统一使用 WebP。

这次抽取没有把同一套界面复制到六个平台。共享的是一套 semantic vocabulary：canvas、surface、text、primary action、focus、success、warning、error，以及明确的 anti-pattern；各平台仍然遵守自己的交互模型和验收方式：

重点关注：不要让 Agent 把设计系统退化成 palette。每次迁移至少检查四层：语义 token、信息密度、组件形态和 anti-pattern。只换颜色，不算迁移完成。

值得上：AI 控制台、桌面效率工具、settings、数据 dashboard、menu bar 与 floating panel。这些场景需要稳定、清透、低噪声，又不能完全失去品牌辨识度。 可以再等：强营销 landing page、娱乐化社区、需要极强情绪刺激的消费产品。青山湖的优势是克制，不适合强行承担所有视觉目标。

不能替代： 涉及安全、合规、数据正确性和复杂系统边界时，Taste 不能替代专业知识、工程验证和责任机制。好判断必须建立在真实约束上。

它不证明 Taste 可以被 AI 自动拥有；它证明的是另一件更务实的事：人的判断可以被外化成 Agent 能读取、实现和验收的约束。

当这些规则被写进 DESIGN.md 和项目级 AGENTS.md，审美才从一次性的聊天上下文，变成可以在下一次会话继续生效的工程资产。

我准备明确区分两类职责：执行策略可以由模型调整；权限、预算、审批和审计由独立于模型决策的治理机制约束。“独立”首先是信任与职责边界，可以先在现有运行时里实现，不意味着新建一套控制平台。

把 E2E Eval、Trace、Replay、故障恢复和权限治理作为工程基础设施，而不是上线前的附加检查。一个任务即使完成了，如果过程中执行了未经授权的敏感操作，也不应被评价为成功。

- 安全与约束：输入过滤、输出审查、权限控制、沙箱隔离。Agent 的自主性越高，安全风险越大。

- 可靠性：Agent 的自主性意味着错误可能被放大，需要有完善的熔断、降级机制。

- Agent Runtime：Agent 的执行引擎。需要了解 LangChain、Mastra、AutoGen 等框架的 Runtime 设计。

- Checkpoint / Durable Execution：执行状态持久化，支持故障恢复。Temporal、Durable Objects 等技术。

从一类有代表性的任务开始，沿用现有工具、运行时和存储，补齐四项能力：结构化执行提案、动作发生前的授权检查、预算与终止条件、可供回放和评估的执行轨迹。

浏览器或某一移动端可以先落地，但不能把单端成功等同于跨环境完成。

对于规则明确、重复性高或需要严格保证顺序的任务，确定性 Workflow 仍然有价值；选择依据应当是成功率、风险、延迟和成本的对照结果。

如果动态规划没有带来收益，就保留固定流程；如果新增治理机制只增加确认次数而没有改善控制效果，就缩小范围、修正规则。

- 工作流 / 状态机：用状态机或 DAG 编排 Agent 的执行流程。如 LangGraph、Temporal 等。

- Planning：Agent 如何拆解任务、制定计划。关键概念包括 Task Decomposition（任务分解）、Hierarchical Planning（层次规划）、ReAct（推理+行动循环）。

技术深度决定能实现什么，产品判断决定什么值得实现。它们结合起来，才构成我想长期积累的职业壁垒。

以任务完成率、重复使用、审批等待、无必要打断和风险漏拦评估体验。

- 产品理解：理解 Agent 产品的用户场景和价值主张。

- 业务落地：从 POC 到生产环境，推动 Agent 在真实业务中产生价值。

固定流程、模型动态规划和混合方案使用同一任务与口径比较。没有统计基线之前，不承诺“耗时从 90 秒降到 40 秒”之类的结果；有数据后才设阶段目标，并同时注明样本、环境和风险指标。

评测中的越权用例必须阻断；有限测试零漏拦不等于实际环境绝对安全。

10 学习 Eval 体系：成功率、任务完成率、轨迹质量 为自己的 Agent 设计 10-20 个测试用例，建立自动化评估 Eval 数据集 + 评估脚本

工作中的经验可以帮助形成判断，但内部代码、运行数据和客户案例不能自动变成公开作品；无法获得公开授权的部分，用独立实现与合成场景表达，并注明验证范围。

将一款 AI Work 产品定位于客户体验治理办公场景，产品形态参考 ACCIO Work。

2026-10-31 本人明确的产品定位，本文为脱敏归纳。2026-11-01 本人确认项目主导身份。项目起始日期、具体执行职责、实施进度和成果尚未说明；类比仅表达产品定位。

项目起始日期、具体执行职责、实施进度和成果尚未说明；类比仅表达产品定位。

在团队降本提效的基建中，紫升开发了一款 vscode 插件，第一版我使用的是 vscode 内置 UI，虽说也能用，但是用户体验欠佳。由于 vscode 内置 UI 不够灵活，一番调研后我决定使用 webview 重构。

激活事件是在 package.json 中的 activationEvents 字段声明的一个 JSON 数组对象。为了注册 helloWorld 这个命令，第一步就是注册激活事件，激活事件类型有很多，注册命令的激活事件是 onCommand:

// 入口命令已经在 package.json 文件中定义好了，现在调用 registerCommand 方法 // registerCommand 中的参数必须与 package.json 中的 command 保持一致

vscode 默认的打包方式就是简单的编译拷贝，通过忽略文件减小体积也是杯水车薪。而且 vscode 扩展的规模往往增长很快。它们是在多个源文件中编写的，并依赖于 npm 的模块。分解和重用是开发的最佳实践，但在安装和运行扩展时，它们是有代价的。加载 100 个小文件要比加载一个大文件慢得多。这就是我们推荐捆绑的原因。

我们使用 esbuild 打包后会将使用到的代码都打包进 out/extension.js，但是 vsce 的打包机制是不管你有没有用到都会把 dependencies 中的包打进安装包中，所以我们需要将 _node_modules_ 忽略掉。

由于我们封装了 getUmiContent 方法，umi build 生成的 index.html 就没有用了，我们可以使用 HTML=none umi build 命令在打包的时候不生成 index.html 文件。

由于我们的项目是 vscode 扩展和 web 项目混合的项目。为了方便管理脚本和依赖，我们引入了 yarn workspace 来管理项目。

webview 反向传递信息给插件的原理也是一样的，只不过由于 webview 的上下文限制，我们只能通过 acquireVsCodeApi 函数获取阉割版的 VS Code API 对象，这个阉割的对象上有一个 postMessage 函数可以供我们发送事件用。注意 acquireVsCodeApi 个会话中只能调用一次，重复调用会报错。

在 VSCode WebView插件（扩展）开发实战 一文中我终于知道了 vscode webview 内部是不允许发送 ajax 请求，所有 ajax 请求都是跨域的，因为 webview 本身是没有 host 的。

webview 的脚本能做到任何普通网页脚本能做到的事情，但是 webview 运行在自己的上下文中，脚本是不能访问 VS Code API 的。我们需要借助 postMessage 这种事件的方式传递信息。

基于 Lerna 的多包管理架构的优点在于： - 组件级别解耦，独立版本控制，每个组件都有版本记录可追溯 - 组件单独发布，支持灰度、版本回滚以及平滑升降级 - 按需引用，用户安装具体某个组件包，无需配置即可实现按需加载的效果。

使用 ttf 字体有一个弊端，就是每次更新图标，都要相应的更新 ttf 文件，然后再次打包发布 APP。而且 ttf 不支持多种色彩的图标，导致所有图标都是单色。

这里紫升没有自己写脚本，而是使用了一款叫 react-native-iconfont-cli 的工具，fwh1990 大佬针对以上痛点用纯 Javascript 实现 iconfont 到 React 组件的转换操作，不需要依赖 ttf 字体文件，不需要手动下载图标到本地。

约定式提交我使用的是渐进式脚手架 @luozhu/create-commitlint，在项目中执行 npx @luozhu/create-commitlint 即可使项目符合规范化提交的配置。

注意：husky 高版本用法不向后兼容，我在这个 commit 中用尤大的 yorkie 代替了 husky。

当配置 conventionalCommits 为 true 后，lerna 版本将使用 Conventional Commits Specification 来确定版本升级并 生成 CHANGELOG.md 文件。

还有可以优化的地方吗？机智的你可能又发现我只是通过函数导出了一个配置而已，并不是真正的插件，所以未来我会定制一个 vant-react-native 自己的按需加载 babel 插件。

另外目前 umijs 的 mfsu 不支持 writeToDisk 方法，如果后续支持了可以使用 mfsu 优化调试速度。

初始化左右指针 left=0 和 right=arr.length-1。 2. 循环计算中间索引值 mid=left + Math.floor((right - left) / 2) 3. 比较中间元素与目标值： - 相等 → 返回 mid。 - 中间值较小 → 目标在右半区，更新 left = mid + 1。 - 中间值较大 → 目标在左半区，更新 right = mid - 1。

前提条件 - 数组必须有序：升序或降序排列（默认为升序）。 - 时间复杂度：O(log n)，每次排除一半元素，效率远超线性查找（O(n)）。

测试原则： - 覆盖所有分支：存在、不存在、边界、异常输入。 - 使用有序数组：确保输入的数组已排序。

nSum 系列问题的核心思路就是排序+双指针。 先给数组从小到大排序，然后双指针 left 和 right 分别在数组开头和结尾，这样就可以控制 nums[left] 和 nums[right] 这个两数之和的大小： 如果你想让它俩的和大一些，就让 left++，如果你想让它俩的和小一些，就让 right--。

如果 nums[i] 大于 0，则三数之和必然无法等于 0，结束循环 - 如果 nums[i] == nums[i - 1]，则说明该数字重复，会导致结果重复，所以应该跳过。

当 sum == 0 时，nums[left] == nums[left + 1] 则会导致结果重复，应该跳过，left++ - 当 sum == 0 时，nums[right] == nums[right - 1] 则会导致结果重复，应该跳过，right-- - 时间负责度：O(n^2)，n 为数组长度

有实现、边界变体和测试示例；修正说明中的中点括号及术语错误后保留。

有完整思路、去重规则、示例和可运行代码，保留原解法署名。

它们分别描述的是检索方式、数据结构、工程系统和知识治理方法，不能简单排成一条替代关系。

编译式 RAG，是把不可直接高效消费的 Raw Sources，在构建阶段加工成面向后续任务的、可检查、可版本化、可增量更新的知识中间表示；查询时优先读取这些编译产物，必要时回到原文核验。

LLM Wiki 可以理解为“知识治理层”，GBrain 可以作为它的知识运行时。

编译式 RAG 的核心不是提前写摘要，而是让知识产物进入版本、校验和重建闭环；查询时对关键 Claim 仍需回查原文。

BM25 不理解“意思”，但它对代码和技术术语非常实用。搜索 Workspace Revision 时，BM25 往往比纯向量相似度更可靠，因为向量模型可能把一些语义相近但并不包含这个精确标识符的文本排得很前。

第一版建议从 FTS/BM25 开始，因为它快、便宜、结果可解释。

先并行扩大 Recall，再用 Reranker 提升 Precision。不要直接拿两个分数相加，BM25 Score 与 Vector Similarity 往往不在同一标度上。

Hybrid Search 团队文档、代码说明、中文问答 数据量极小且 BM25 已达标 两套索引与 Fusion 调参

GraphRAG 解决的是“沿什么关系找到答案”，不是“图里的结论天然可信”。每一跳仍要锚定带版本的 Source Span。

Understand Anything 的输出也不应该被理解为第二份代码事实源。代码仍然以 Git Revision 为准，Graph 是可重建 Projection。

没有真实的关系查询，就不该为了架构图好看而上 GraphRAG。

如果团队不能维护这些约束，GraphRAG 会把“检索偶尔漏片段”变成“图谱稳定地提供错误关系”。

这里最容易犯的错误是把“索引”当成事实源。索引只是派生数据，应该可以从已验证的原始输入重新构建；真正的事实源应该保留自己的版本和摘要。

先检索全部内容、再在答案阶段隐藏结果，是危险设计。

知识库缺少证据时，系统应该返回 no_evidence，而不是用模型常识补一段看似合理的答案。

否则一次错误推理或偶发现象写进团队 Wiki，之后所有 Agent 都会把它当成事实。

先建立一个稳定知识底座，再用真实任务证明是否需要实时搜索器和代码图谱；不要为了“看起来完整”一次性维护三套基础设施。

只有经过验证和审核的稳定结论，才进入 GBrain 的正式页面。

当团队反复综合同一批稳定知识，并希望结果能够积累、审阅和复用时，增加编译层：把原始资料加工成结构化 Wiki、Procedure、Decision 和 Conflict 页面，但原始 Source 仍然是事实源。

GBrain、Sirchmunk、Understand Anything 可以各自擅长不同问题，但不应该让 Codex 或 Qoder 自己决定调用哪一个。应该由 Host 做意图路由

结构检查可以自动执行；涉及业务语义的冲突，应该进入人工审核，而不是让模型自行决定哪一方是真相。

增量更新：一条政策发布新版本后，哪些社区摘要和关系要重算？

这两个数字服务于当前项目，不是行业标准。

青山湖设计风格的核心，不是把界面染成绿色，而是把青山湖的自然层次翻译成数字产品的职责分工：雾白负责空间与材质，湖水青负责操作，水杉绿负责状态，青山灰蓝负责信息层级，晨光金只负责极少量高光。

这里最重要的动作是“蒸馏”，不是“复刻”。 我不需要在每个页面放一张水上森林背景，也不想把产品做成旅游宣传页。我需要的是把自然景观里的层次关系，映射成界面里的语义关系。

湖面变成主操作的湖水青，水杉变成成功和运行状态，远山承担次级信息，雾白负责空间和层次，晨光金只留在极少量高光里。母题也同时定义了禁区：不做赛博霓虹，不让金色主导 surface，不用重阴影堆层级，不为了“可爱”牺牲信息效率。

如果一套风格只告诉 Agent“可以用什么”，它很快就会把所有特征同时用上。真正能提高输出稳定性的，是同时写清楚“最多用多少”“只能用在哪里”“什么情况下不要用”。

这段过程让我确认：设计风格首先是一套删减规则。 如果只告诉 AI“可以用什么”，它会很积极地把所有特征一起用上。输出真正开始稳定，是因为规则同时写清了“最多用多少”“只能用在哪里”“什么情况下不要用”。

因此后来规范里出现了很多带比例和边界的表达：浮萍绿控制在 5% 以内，晨光金只做边缘光，常规圆角控制在 6–12px，动效只服务状态变化，卡片不能继续嵌套卡片。

最后采用的是纯 SwiftUI 内部绘制： - 大面积雾白柔焦带； - 左上角雾白 soft blur； - 右下角很淡的湖水青 blur； - 所有效果裁剪在卡片内部； - 不使用 NSVisualEffectView； - 不使用 .behindWindow 或 .underWindowBackground。

后来为了让灵动卡接近系统组件的玻璃质感，我们尝试过 macOS material 和窗口采样，特定组合会带来稳定性风险。最后我没有放弃“雾”，也没有为了视觉效果继续赌系统边界，而是改用纯 SwiftUI 绘制柔焦层：保留雾白的视觉职责，换掉高风险实现。

这也是我现在判断视觉方案的一个原则：设计语言不能绕过工程约束，好的设计 token 应该能在安全实现与理想效果之间找到可迁移的中间层。

后来我把这套语言迁移到“小界”的 Web 工作台。平台从 SwiftUI 变成 React、Umi、styled-components 和 Tailwind，产品形态也从 macOS menu bar 工具变成 AI 控制台，但核心映射依然成立

迁移过程中，设计体系又吸收了 Web 产品的新约束：正文默认 14px、工具栏控件 32–36px、桌面优先但窄屏不溢出、动效支持 prefers-reduced-motion，以及资源统一使用 WebP。

这次抽取没有把同一套界面复制到六个平台。共享的是一套 semantic vocabulary：canvas、surface、text、primary action、focus、success、warning、error，以及明确的 anti-pattern；各平台仍然遵守自己的交互模型和验收方式

把两边都染成青绿色没有迁移价值。跨端复用的是同一套判断：低噪声画布、清晰的信息层级、克制的状态色、不过度装饰的 glass surface，以及让内容始终压过背景的优先级。

值得上：AI 控制台、桌面效率工具、settings、数据 dashboard、menu bar 与 floating panel。这些场景需要稳定、清透、低噪声，又不能完全失去品牌辨识度。 可以再等：强营销 landing page、娱乐化社区、需要极强情绪刺激的消费产品。青山湖的优势是克制，不适合强行承担所有视觉目标。

重点关注：不要让 Agent 把设计系统退化成 palette。每次迁移至少检查四层：语义 token、信息密度、组件形态和 anti-pattern。只换颜色，不算迁移完成。

到了这个工作台，这套判断必须适应专业产品的密度。聊天入口可以有缓慢移动的云雾，进入任务和报告后，装饰必须后退。正文、筛选器、状态、日志和结果证据要更紧凑；loading、empty、error 和 success 继续使用同一套自然语义，但不能因为“青山湖”降低扫描效率。

每次迁移至少检查四层：语义 token、信息密度、组件形态和 anti-pattern。只换颜色，不算迁移完成。

共享的是一套 semantic vocabulary：canvas、surface、text、primary action、focus、success、warning、error，以及明确的 anti-pattern；各平台仍然遵守自己的交互模型和验收方式

这篇文章是一次阶段性自我校准。我会明确区分三个容易混淆的东西：职业身份是我想成为谁，技术判断是我选择研究什么，实践成果是我用什么证明判断与能力。三者相关，但不能互相替代。

Staff 是未来希望承担的问题范围，而不是今天已经拥有的头衔。我更倾向于 Individual Contributor（IC）的专家路径：可以影响技术战略、协调复杂工作，却不以正式带团队和人员管理作为身份的必要条件。

这不是已经被证实的行业结论，而是值得持续验证的 Technology Thesis（技术战略判断）。

我准备明确区分两类职责：执行策略可以由模型调整；权限、预算、审批和审计由独立于模型决策的治理机制约束。“独立”首先是信任与职责边界，可以先在现有运行时里实现，不意味着新建一套控制平台。

模型不能修改自己的权限，也不能在调用被拒后换工具、拆金额或委派给另一个 Agent 绕过同一限制。

审批不应机械地插入每一步。已有权限范围内、非敏感的只读分析可以自动进行；写生产、动钱、对外发送和访问敏感数据，应根据影响范围、可逆性、数据等级与既有授权判断是否升级。只读查询也可能导出敏感信息，不能直接等同于低风险。

这是说明边界的假设示例，不是本人已经实施的业务机制。

若拿不到真实生产授权，就用隔离试点验证，并明确它不能证明生产验收。

能力覆盖 Browser、Android、iPhone、Computer 四类环境的边界设计，实测从当前有设备与授权的一端开始；一个端通过不代表跨端能力完成。

安装依赖时看到 incompatible engine，不代表项目一定跑不起来；它表示某个包声明了经过验证的 Node.js 版本范围，而当前运行时不在这个范围内。它可能只是历史包写得过窄，也可能是在提醒你 API、ABI 或构建链已不兼容。

Yarn Classic 可以单次忽略： bash yarn install --ignore-engines 或写入本机配置： bash yarn config set ignore-engines true npm 的 engine-strict 为 false 时通常只警告；pnpm 则同样受 engine-strict 配置影响。

涉及 native addon、Node API、OpenSSL、ESM/CJS 加载方式或构建工具时，版本不匹配经常会在安装后才爆炸。此时 --ignore-engines 只会延后问题，不能解决问题。

必须修复：CI、线上或含原生模块的项目出现 engine 冲突。运行时版本应是可复现的工程约束。

error:0308010C:digital envelope routines::unsupported 常出现在把旧前端项目切到 Node.js 17 或更高版本之后。它看起来像业务代码报错，实际是构建工具请求了 OpenSSL 3 默认不再支持的旧算法。

如果堆栈里包含 webpack/lib/util/createHash、ERR_OSSL_EVP_UNSUPPORTED，且故障发生在 dev 或 build 初期，基本就是这个问题。常见组合是旧版 Webpack 4 与 Node.js 17+。

如果错误发生在运行时的加密、签名或 TLS 逻辑中，而不是构建阶段，不能简单套用 legacy provider。应先确认算法、证书或上游 SDK 是否需要迁移，否则可能降低安全性。

--openssl-legacy-provider 只能救急。长期方案是升级 Webpack/相关 loader，或把项目固定在兼容的 Node LTS；不要把这个环境变量当作永久配置。

静态导出 + egg-static 托管 Next.js 支持 output: 'export'，构建后输出纯静态文件

也就是说，GET / 返回文档站首页，GET /api/skills 走 Midway 控制器——静态文件和 API 共用同一个端口，完全无感。

边车提供了第三条路：原生 Core 保留控制权，Node Agent Host 只承载 Node 生态中不可替代的部分。

3. Core 给任务生成受限 capability profile，再通过版本化 IPC 发给 Sidecar。 4. Sidecar 调用 Provider SDK，并把 token、tool call、progress 和 error 作为有序事件流返回。

值得用： - 必须复用另一种语言或运行时的成熟 SDK。 - 任务容易崩溃、泄漏内存或需要单独限流。 - 能力涉及 Shell、网络、第三方插件等较高风险边界。 - 希望 Agent Runtime 可单独重启，而不影响 UI 和核心数据。

最后一种尤其常见：付出了多进程复杂度，却没有获得真实边界。

Tauri capability 主要约束 Webview → 原生 Core，不会自动沙箱已经启动的原生插件或 Node Sidecar。把平台 ACL 当成完整安全方案，是一个危险的边界误判。

因此我会把原生 Core 设计为 Permission Broker： - Frontend 不能直接启动 Sidecar，只能提交声明式 Intent。 - Sidecar 只接收完成当前任务所需的最小输入，不接收完整配置和全部 Secret。

这也是 Bearer Token 最重要的工程边界：它很好用，但安全性高度依赖 HTTPS、短有效期、最小权限、安全存储和严格验证。

Bearer Token 可以是 JWT，也可以是一段不可读的随机字符串。后者通常称为 Opaque Token，Resource Server 需要通过 Token Introspection 或内部查询确认它的状态。

JWKS 地址必须来自配置或可信的 Issuer Metadata，不能读取 Token Header 里的任意 jku 后直接请求。Token Header 属于攻击者可控输入。

只执行 Base64 Decode 没有任何安全意义。Decode 只能读取 Claims，不能证明 Claims 没被修改。

Fumadocs 各包的 peer dependency 比较严格，截至写作时

fumadocs-mdx 对 Next.js 16 有 optional peer dep，安装时加 --legacy-peer-deps 即可，不影响 Next.js 15 运行。

主应用需要回答：握手失败怎么办？任务执行中 Sidecar 崩溃是否重试？取消后怎样确保子进程和工具进程都被清理？升级时协议不兼容如何阻止启动？连续崩溃是否进入熔断？

一句话总结 Chat Composer 不能把所有 Enter 都视为提交。发送前至少要同时检查 KeyboardEvent.isComposing、IME 的兼容值 keyCode === 229，并处理部分 WebKit 环境中 compositionend 早于提交用 keydown 到达的时序差异。

React 组件性能优化的核心是减少渲染真实 DOM 节点的频率，减少 VirtualDOM 比对的频率。

但 WebKit 在 macOS 上长期存在另一种时序： text compositionend keydown Enter (isComposing: false) keyup Enter 对业务代码来说，收到 keydown 时 composition 已经结束，isComposing 自然变成 false。

因此，IME guard 中使用 keyCode === 229 不是把所有键盘逻辑退回旧 API，而是把它作为一个窄范围的兼容信号

这里的 80ms 不是协议常量，而是一个很窄的事件时序缓冲。它只保护 composition 刚结束后紧随而来的 Enter，不会改变用户完成输入后再次按 Enter 发送的习惯。

优化法则 - 法则一：动静分离，将变的部分与不变的部分分离。 - 法则二：缓存，复杂计算和有昂贵消耗的组件 memo 化，比如 React 的 useMemo、useCallback，Redux 的 useSelector。

我们可以看到这里边除了 Count 是因为 count 更新之外，其他组件的更新都是被无辜牵连的。根据法则一，我们可以尝试将 Count 组件和它依赖的状态封装起来。

要触发 bailout 函数，需要同时满足以下条件： 1. oldProps === newProps 并且 Context 没有改变 2. !includesSomeLane(renderLanes, updateLanes) 当前 fiber 上是否存在更新，如果存在那么更新的优先级是否和本次整棵 Fiber 树调度的优先级一致？

关键是把处理放在 Composer 输入边界，而不是 sendMessage() 里事后猜测

→ suggestion / mention / command popover → editor-local behavior → product shortcut → global shortcut 越靠前的输入状态，越应该先消费事件。

bailout 函数逻辑大致是：尽量复用 fiber，不进行 render。fiber 复用，判断 fiber 的子树是否有 work。有，返回 child，继续遍历子树。无，返回 null，跳过子树。

这个 Bug 的验收重点是事件语义，而不是文字最终有没有出现在 textarea。

自动化测试可以构造 compositionStart、keyDown、compositionEnd 序列，但不要只相信 JSDOM。IME 与 WebView 的差异发生在浏览器事件层，至少还需要一轮 macOS Safari / WKWebView、Chrome，以及 Windows 中文输入法的真机测试。

这类 headless primitive 通常已经包含基础的 isComposing 判断，但宿主应用仍可能需要为特定桌面 WebView、输入法和系统版本补充 guard。

该案例中我们引入了 Context，当 context 的 value 改变时，

这里最容易犯的错误是把“索引”当成事实源。索引只是派生数据，应该可以从已验证的原始输入重新构建；真正的事实源应该保留自己的版本和摘要。

如果把“进入索引”直接理解成“成为资产”，GBrain 数据库就会悄悄变成第二事实源。

GBrain database、FTS index、Vector index 都应该是可重建的派生实现。跨云端和本地同步时，同步版本化 Knowledge Asset，不要粗暴复制数据库文件。

GBrain 负责“知识怎么被找到和组织”，应用侧负责“谁能使用这些知识、作用于哪个 Workspace、最终执行是否成功”。两者不能混成一个边界。

一篇语雀文档被同步进 GBrain 后，可以被搜索、切块、建立向量和关系，但它依然可能过期、互相冲突、没有明确 Owner，甚至只是一场会议里的临时观点。它是 Raw Knowledge，不是已经发布的 Knowledge Asset。

GBrain 是知识引擎，不应该自动成为业务系统的权限和发布中心。

一句话定义 Workspace Revision 是面向 Workspace 发布的不可变资产集合快照。

simple 的主要作用是取消英文停用词和 stemming，不会自动把： text 工作区修订是不可变资产集合快照 切成： text 工作区 / 修订 / 不可变 / 资产 / 集合 / 快照

这个结果说明它不是“完全不支持中文”。索引里恰好存在的完整中文词可以命中，英文领域词也很稳定；真正不可靠的是中文自然问句。

它们不真正理解语义，所以中文自然语言问题可能需要更好的分词、Query Rewrite 或 Vector Search。

Keyword Search 守住精确术语，Vector Search 补足中文和同义表达，再通过 RRF 合并两个排序列表。

Sirchmunk 的价值不在于又实现了一套 Vector RAG，而是它选择了另一条路径：直接面对 Raw Data 做 Indexless Agentic Search。

它使用 Tree-sitter 和多 Agent Pipeline 提取 File、Function、Class、Dependency 等节点与关系，生成可交互 Knowledge Graph，并提供 Architecture Layer、Domain Flow、Diff Impact、Guided Tour 等视图。

Agent 不需要知道三套引擎的数据库、进程和权限模型，只需要调用宿主系统暴露的 knowledge.search、workspace.search 和 code.graph_query。

GBrain、Sirchmunk、Understand Anything 可以各自擅长不同问题，但不应该让 Codex 或 Qoder 自己决定调用哪一个。应该由 Host 做意图路由

- 每个 Agent Turn 开始前最多检索 5 条知识。 - 结果通过只读上下文注入 Codex 或 Qoder。 - 检索超时约 8 秒时自动降级。 - 每条结果生成 gbrain:// Citation。

这是一个很重要的工程原则：GBrain 增强 Agent，但不应该成为 Agent 执行的单点故障。

最危险的状态是“没有命中，但模型假装命中了”。因此 Prompt 和 Adapter 都应该要求：没有 Citation 的关键结论不得伪装成团队事实。

这时最容易出问题的不是模型能力，而是工作目录。切分支会覆盖未提交改动；为了并行而多 clone 几份，又会把依赖、构建产物和仓库状态弄得难以辨认。

真正起作用的，是把正确的信息送到正确的阶段，尽量不让无关的文件、文档、日志和历史决策进入当前上下文。

如果继续扩充静态 Reference，Skill 会逐渐变成一个难以维护的资料压缩包。知识更新需要修改 Skill，Skill 发布又和知识变更绑定；资料越多，Agent 每次加载的 Context 越大，真正需要的内容反而更难命中。

它们仍共享同一个仓库的 Git 对象库，不能把它当成权限隔离。

新 Session 的价值，就是把上下文重置成一个更干净的工作面。代码和 Git 工作区不会因为换 Session 消失，但对话里的决策不会自动继承，所以需要一份短 handoff。

Wiki 是可重建的知识产物。删除 Wiki 后，系统应该能够从 Raw Sources 重新编译；删除 Raw Sources 后，只剩 Wiki 就失去了可信根基。

端口、全局缓存、Docker 容器、数据库和远端环境依然可能冲突。

值得上：你同时处理发布、修复、审查或多个 Agent 任务；你不想为了切分支 stash 半成品；你需要从一个干净 commit 产出可追溯制品。

值得上 - 中大型代码库，文件和调用关系比较复杂。 - 经常需要查 React、Umi、Midway 等版本敏感的文档。 - 任务经常经历探索、实现、验证多个阶段。 - 长 Session 里经常出现重复解释和日志污染。

值得上：同一类任务反复发生，知识分散且持续变化，错误口径会直接影响设计或生产代码。 - 可以再等：资料规模小、规则稳定、任务复用率低，几份静态 Reference 已经能够清楚覆盖。

如果一个任务只需要改一个 CSS 属性，同时打开多个文档和代码 MCP，成本可能比收益更高。

不要把 worktree 当成“多开几个目录”就结束了。给每个目录一个任务边界、一个分支和一份验证证据，才是它在 AI 时代真正放大交付能力的方式。

不要把 LLM Wiki 当成更复杂的 RAG，也不要把它当成新的万能知识平台。

结构检查可以自动执行；涉及业务语义的冲突，应该进入人工审核，而不是让模型自行决定哪一方是真相。

合理拆 Session 是手动做的。判断标准不是“聊了多少轮”，而是当前上下文是否还服务同一个目标。

Agent 完成后报告 commit、验证命令和残留风险，而不是只说“改好了”。

Citation 是 Claim 指向 Source 或 Evidence 的定位关系。它解决“去哪里看”，不自动解决“这段内容是否真的支撑结论”。

Trace、日志、截图和测试输出只能算 Evidence Candidate。只有当它被绑定到具体 Claim，并说明来源、范围和验证方式后，才成为可以用于验收的 Evidence。

Citation 是 Evidence 的可回溯地址。

当出现下面任意几种需求时，Evidence 应升级为一级领域对象： - 同一条 Evidence 会被多个 Claim、Run 或 Evaluator 引用； - Evidence 需要独立权限与脱敏； - Evidence 会过期、撤销、被替代或重新验证；

1. 它是否拥有稳定 ID，能被 API、权限和审计记录独立引用？ 2. 它是否有独立生命周期，而不是伴随一次函数调用即消失？ 3. 它是否承载业务规则或状态转换？ 4. 它是否会被多个模块共同使用，而不属于某个框架的内部实现？ 5. 更换 Model、Runtime 或 Agent Framework 后，它是否仍然存在？

简单聊天机器人可以把 Citation 和 Evidence Span 放在 Message Metadata 中，不必一开始建设复杂平台。

不要把原始搜索结果直接拼接给模型。建议统一成： json { "content": "Overlay 不修改基础 Revision……", "source": "example-workspace-spec", "citation": "gbrain://default/example-workspace-spec", "revision": "workspace-revision-digest", "score": 0.99, "retrievedAt": "2026-07-22T12:00:00Z" }

应用侧不允许拿旧 Revision 的索引结果冒充当前 Workspace 的知识。知识检索必须和当前 Session Pin、Workspace 和 Permission Scope 对齐。

最危险的状态是“没有命中，但模型假装命中了”。因此 Prompt 和 Adapter 都应该要求：没有 Citation 的关键结论不得伪装成团队事实。

让 Agent 自己证明自己 Agent 输出“工具调用成功”只能算自述。高风险 Claim 应由独立 Verifier 从权威系统重新读取状态。

正确的闭环是： text Execution Evidence → Knowledge Draft → Citation / Conflict Check → Review Gate → Published Knowledge

这也意味着，十二个对象是一套用于架构决策的参考模型，不是对任何单一 SDK 或协议的重新命名。

AI 没有让工程能力失去价值，它改变了瓶颈的位置：生成候选越来越便宜，定义问题、比较方案、拒绝噪声、验证结果和沉淀标准变得更重要；我把这组带责任的判断称为 Taste。

当 AI 把实现和生成的成本迅速压低，真正稀缺的能力开始转向问题选择、方案取舍、边界判断与结果验收。

这张图的核心路径是：LLM 理解 → Agent 核心 → Runtime / Infra → Grounding & Execution → Evolution → 战略影响力。七个层级层层递进，每个层级下面都有具体的能力点。

作为全栈开发者，最大的优势是工程基础扎实、理解系统全貌。最大的挑战是从"确定性编程"转向"概率性系统"的思维转变。

最后我没有放弃“雾”，也没有为了视觉效果继续赌系统边界，而是改用纯 SwiftUI 绘制柔焦层：保留雾白的视觉职责，换掉高风险实现。

青山湖于是从一句审美偏好，变成一套可执行约束：颜色有 semantic roles，圆角有范围，间距有节奏，动效有性能与可访问性边界，组件有 anti-pattern。

这也是 Taste：知道哪个体验必须保留，哪个实现可以妥协，并让审美服从稳定性、性能和可读性。

与其写“保持高级感”，不如写“湖水青是唯一主操作色；浮萍绿控制在极小面积；不要卡片嵌套卡片”。

它不证明 Taste 可以被 AI 自动拥有；它证明的是另一件更务实的事：人的判断可以被外化成 Agent 能读取、实现和验收的约束。

这次抽取没有把同一套界面复制到六个平台。共享的是一套 semantic vocabulary：canvas、surface、text、primary action、focus、success、warning、error，以及明确的 anti-pattern；各平台仍然遵守自己的交互模型和验收方式

- Skill Library：Agent 学习的技能库，可复用的工具组合和策略模板。

- 反馈闭环：将执行结果反馈给 Agent，形成学习循环。成功/失败案例的积累。

第一阶段（1-3 个月）：夯实基础 重点：L2 + L3

产出物：一个具备 Planning + Memory + Tool Use 的 Agent 原型

理论学习 40 min 读文档、课程章节或论文，理解概念并记关键笔记 动手实践 60 min 写代码、跑示例、调 Prompt，必须产出可运行的代码 复盘整理 20 min 写学习日志、整理代码片段、画思维导图，沉淀为可复用知识

1. 先跑起来再完美：第一周就写出能运行的代码，不要花两周只读理论

- 值得投入： 当 AI 已经能快速产出候选，而产品仍然缺少方向、辨识度或稳定完成标准时，优先补 Reference、选择规则、anti-pattern 和验收方式。

- 不能替代： 涉及安全、合规、数据正确性和复杂系统边界时，Taste 不能替代专业知识、工程验证和责任机制。好判断必须建立在真实约束上。

- 重点关注： 不要只记录最终选择。把删掉什么、为什么删、什么证据会推翻当前决定一起沉淀，下一次协作才不会从零开始。

这里不存在一个严格的因果公式：使用 AI 不会自动让所有人拥有相同执行力，生成速度提高也不必然导致产品同质化。

Qingshan Lake Design Skill 里除了 token，还有布局顺序、材质策略、状态合同、Reduced Motion、对比度检查和禁区。

- Skill Library：Agent 学习的技能库，可复用的工具组合和策略模板。

按这个节奏，12 个月后你会有一条清晰的成长轨迹：从"能写 Agent"到"能设计 Agent 系统"再到"能带团队做 Agent 落地"。每天 2 小时，关键是不中断。

分析对象为 macOS 上的 ChatGPT 26.1023.51421，build 22530，检查日期为 2026 年 10 月 31 日。这是一轮安装包静态分析，没有执行真实网页任务，也不代表其他平台或历史版本采用相同实现。

漫画中的书店、库存和命令输出均为教学示意，不是实际业务执行记录。

本文以两张真实截图为界面依据，配合教学示例解释操作；没有对截图中的仓库执行暂存、提交或寄存。

Frameworks 下存在 Codex Framework.framework，其中的版本目录为 156.0.8078.48；应用 Info.plist 中的 ChromiumBaseVersion 与它一致。

{ sandbox: true, nodeIntegration: false, contextIsolation: true, webSecurity: true }

Browser Use 后端经过会话路由，找到页面的 WebContents，再使用 Electron 的 debugger 接口发送 CDP 命令。

这些证据支持“运行时带有定制扩展，并暴露了页面接管与转移接口”的判断。 但铭牌和接口没有交出完整施工图。

工具通过 Accessibility.getFullAXTree 取得节点信息，再组织角色、名称、状态和层级。

引用省去了为每一步重新编写 selector 的工作，但它不是商品 ID、订单号，也不是跨页面永久有效的地址。

snapshot -i 偏向可引用的操作目标，“有货”这样的普通结果文字可能被排除；某些标题和表格单元格能够留下，也不保证所需字段完整。找动作目标时可以压缩观察，检查业务结果时则需要保留相关正文、状态或表格内容，不能把“交互快照里没出现”理解为“页面没有”。

Rust CLI 解析命令并与 Rust daemon 通信，daemon 直接使用 CDP 驱动默认 Chrome 路径。

Stage 记下当时的版本 A，之后继续编辑成 B，暂存区仍保存 A。

同一文件名可能同时出现在两组，所以不能把两组数量简单相加，当作不同文件的总数。

未提交的工作区修改、仅暂存的内容、stash 条目，都不会随普通 Push 自动同步。

因此，Unstage All 之后直接点 Commit Tracked，并不能排除刚才取消的文件：Zed 又会自动暂存 tracked 改动后提交。

普通 git stash push 默认不收未跟踪文件，-u 把它们一并收纳，忽略文件仍默认留着。

两边有各自的工作区、index 和 HEAD，共享仓库对象与多数引用；原目录的未提交修改不会自动出现在新目录里。

功能分支已推送、代码已合入主线、应用已发布，是三个不同状态。

restore 的默认来源取决于目标是否含 --staged，不要把“取消暂存”和“丢弃编辑”当成同一操作

具体修改了哪些 Chromium/Electron 源码、对应哪个上游 Electron 版本、迁移时有哪些限制，仍不能从这次检查中确定。

会话仍在运行、浏览器关闭后能恢复状态、两个账号完全隔离，是三个不同要求。

本文没有进行这样的性能对照，不据此给出降本或提速比例。

截图未显示安装版本号，具体菜单以当前版本为准。

实际问题：document.body.scrollHeight 包含正文下方的"YOU MIGHT ALSO LIKE"推荐区。这块区域通常占页面高度的 15-25%。

我的站点用 Next.js output: 'export' 静态导出，全站 HTML/CSS/JS 推 CDN，没有运行中的 Node.js 服务。CAPI 需要从服务端调用 Meta Graph API 回传事件，这意味着： - 方案 A：改用 Vercel 部署（支持 Next.js Route Handler），在 app/api/fb-event/route.ts 里回传 - 方案 B：单独部署 Cloudflare Worker 或 Vercel Function 作为中转 - 方案 C：Meta 官方 CAPI Gateway（零后端成本，但灵活性差）

另外 CAPI 和 Browser Pixel 同时上报同一事件时，需要用 event_id 去重——前端生成 UUID 写 Cookie，服务端从 Cookie 读同一个 ID 再回传，这套打通有额外工程量。

当前阶段流量不大、日耗不高，浏览器 Pixel 足够，CAPI 等 Events Manager 出现"信号丢失"警告再评估。

单次访问价值 = 平均阅读页数 页面 RPM / 1000 利润 = 单次访问价值 - CPC 这意味着 Facebook 端的 CPC 只是上半场。真正决定能不能套利的，还有两个站内指标

如果站内阅读深度和 RPM 还没稳定，盲目追求低到不现实的 CPC，会让投放策略变形。比如为了便宜点击去投低质量受众，短期 CPC 降了，但用户进站 3 秒就走，最后广告收入更差。

在原始数据里还有一个信号：覆盖人数只有 939，展示 1019。这个量级太小了。 如果一个广告组一天只覆盖不到 1000 人，就算单次成本看起来不差，也不能直接判断它有放量能力。

我的最终判断是：当前任务不是把 0.33 元硬压到 0.05 元，而是验证 0.33 元能否在更大受众池里稳定复现。 复现成功，再用预算换量；复现失败，再回头修素材、落地页和读者质量。

原因：Meta 在 2023 年左右悄悄把这套机制改名了，现在叫「广告组转化事件」，UI 路径在广告管理工具 → 广告组 → 广告组转化事件（不在事件管理工具里）。 原来的 8 槽限制也放开了，现在可以正常选任意自定义转化事件作为优化目标，不再有数量硬上限。

然后用 IntersectionObserver 监听这个元素进入视口： js const sentinel = document.getElementById('chapter-content-end')

真正可交付的自动更新远不止一个 UI：旧客户端要发现正确版本，下载最终制品，验证更新签名，启动 updater，通过 macOS 的代码签名与 Gatekeeper 检查，替换旧 App，重启后还要保持用户数据和应用身份不变。

它适合已有安装器、希望自己掌握发布节奏的桌面应用；但它不会替你构建安装包、保管签名私钥，或证明一台旧 Windows 客户端真的升级成功。

多渠道设计真正完成，要分别验证源码、制品、服务端和旧客户端。下面这些状态不能合并成一句“已经发布”

它回答的是“下载到的字节是否由持有 private key 的发布方签出”，不是“macOS 是否允许其中的代码运行”。

Windows Authenticode 则证明 PE 发布者身份，供 Windows 安装信任链检查。两者解决不同问题，发行流程应同时验证，不把一个成功当作另一个成功。

签名主体不一定要按渠道拆分。Stable 与 Preview 可以继续使用同一家公司的 Developer ID 或 Authenticode 证书，因为它们表达“谁发布了这个二进制”；CUP、CRX3、Sparkle feed key 等更新信任则可以按渠道隔离，因为它们约束“哪条更新链有权推进这个应用”。

appcast 是发布开关。若先更新 feed，客户端可能立刻看到一个尚未上传、未完成 CDN 刷新或字节不一致的制品。artifact URL 应版本化且尽量 immutable；不要在相同 URL 上静默覆盖不同字节。

Sparkle 默认安装更高内部版本。已经升级到 101 的客户端不会因为 appcast 重新指向 100 就自动降级。

示例中的长度和签名只是占位值。发布时必须从最终签名后的安装包字节计算真实长度和 EdDSA 签名。

它改变同一安装后续接收的版本；如果目标渠道版本更低，默认不会立刻降级，可能要等待目标渠道追上，或显式启用 rollback。

本文讨论通用机制和设计判断；示意不对应任何具体产品的已交付状态。源码阅读坐标沿用原稿，本次整理不构成新的运行时验收。

每个故障都要保留客户端日志、feed 快照、制品哈希和 Windows 原生安装结果。macOS 上的源码检查不能代替 Windows 安装和旧客户端升级证据。

最终验收至少要覆盖：两个应用同时出现在系统中；分别打开各自的 About 页面；进程、安装目录和 User Data Directory 不相同；Preview 更新不会改变 Stable 版本；卸载 Preview 后 Stable 仍能启动和更新。

CLAUDE.md 是常驻规则。 它每次都进上下文，所以只放最高优先级、最稳定的东西：比如"博客每篇至少 3 张插图""性能规则不能回退""发布流程怎么走"。它贵，所以要克制——不该把操作细节全塞进来。

skill 是按需加载的操作手册。 它平时不占上下文，只有当任务命中触发词（"做 mac 应用图标"、".icns"）才被拉进来。这意味着 skill 可以写得很详细、很长，因为它不是常驻成本。

博客是给人也给 AI 的深度页。 它存的是"为什么这么做"的判断，而不只是"怎么做"的步骤。

- 只存结果不存判断 = 不可迁移。 "这次用了方案 A"没价值；"因为 X 约束所以选 A、代价是 Y"才能迁移到下一个场景。这也是为什么博客这层不可替代——它存的是判断框架。

效果：每次插图生成任务（A2.5）比之前少加载 27KB。这是结构性节省，不是内容压缩——文件总量没变，但每次调用用到的更少了。

内容压缩是锦上添花，结构分离才是关键。 文件从 162KB 压缩到 117KB，感觉很好。但真正节省大的是"A2.5 不再加载 genre playbook"那 27KB——它每次插图任务都生效，是乘法效应。

- Skill 被高频调用（每次写章节、每次生图都触发） - 单个 reference 文件超过 50KB - 同一个文件被不同 phase 消费，但 phase 之间需要的内容有明显差异

不值得做： - 为了"显得更整洁"而拆分（增加维护成本，收益低） - 把所有内容压到极限（模型需要足够的示例才能理解方法论，过度压缩反而降质量）

- 别用错工具：你要的是一个常驻 macOS 菜单栏、读真实 CPU 的原生小猫——那 Remotion 不是答案，老老实实用 Swift（RunCat 本体）或 Tauri/Electron。Remotion 造的是动画资产，不是系统进程。

关键就那一行 Math.floor(frame / framesPerSprite) % CAT_FRAMES.length： - frame / framesPerSprite：当前帧对应到「第几个 sprite 周期」 - Math.floor(...)：取整，同一张图在多个视频帧里保持不变 - % 5：跑完 5 张回到第 0 张——和 RunCat 那句 % frames.count 是同一个灵魂

这件事让我明确了一条分工：需要理解系统边界和做取舍的，找 Claude Code；需要快速验证一个想法的，找 Codex。

整个过程中，AI 没有替我做任何一个真正重要的决定。 - 要不要做这个项目？我决定。 - 功能优先级怎么排？我决定。 - 命名 Owlet？我决定。 - 青山湖配色方向？我决定。 - 性能规则里哪些不能回退？我决定。

今天我在提交一个 skill 改动时，中间的工具输出显示"已提交、已推送"，我就信了、往下走了。后来用 git rev-parse HEAD 和 git show 一核对——根本没提交成功，那几步是我基于未经核验的中间状态脑补出来的。

我后来把这条也固化了：涉及提交推送，一律以 git rev-parse、git status、git show 的真实输出为准，绝不用中间回显下结论。这就是一条为 AI 写的"自我校验规则"。

这个细节 Claude Code 不一定主动帮你算，得自己盯一下。

但「取模换帧」的原理、「相位累积」的坑、无缝循环的数学——这些判断你得心里有数，否则 AI 给的代码你既 review 不了也调不动。

- Skill 调用频率低（每月几次） - 所有 reference 文件都在 20KB 以下 - 文件内容高度内聚，没有明显的 phase 分离机会

这些规则都被写进了 CLAUDE.md 和 AGENTS.md，成为后续所有改动的底线。

- 写太细放错层 = 变负担。 把一次性的操作细节塞进 CLAUDE.md，每次会话都要为它付上下文成本。分层很重要：常驻的极简、按需的详尽。

它们分别描述的是检索方式、数据结构、工程系统和知识治理方法，不能简单排成一条替代关系。

向量 RAG、GraphRAG 和编译式 RAG 并不是一条从低级到高级的升级路线。

LLM Wiki 可以理解为“知识治理层”，GBrain 可以作为它的知识运行时。

LLM Wiki 的三层架构 Andrej Karpathy 提出的 LLM Wiki pattern 把知识系统分成 Raw Sources、Wiki 和 Schema 三层。

当前阶段 FTS/BM25 + Evidence 先解决本地、可解释、低依赖的知识接入

第一版建议从 FTS/BM25 开始，因为它快、便宜、结果可解释。

默认先做 Hybrid RAG：Keyword / BM25 保精确词，Vector Search 处理自然语言表达，再加 Metadata Filter 与 Rerank。

当前的 GBrain MVP 先使用 FTS，原因很务实：本地部署简单、依赖少、可解释，而且对项目里的英文领域术语已经有效。

当用户问的是“几个对象之间有什么关系”“这条结论依赖哪些事实”“修改某个事实会影响什么”时，图结构就更有价值。

关系变化比查询还快时，GraphRAG 的增量维护成本会吞掉收益。

如果继续扩充静态 Reference，Skill 会逐渐变成一个难以维护的资料压缩包。

同一批资料只问一次，直接 RAG 通常更便宜；团队每周都要重新综合同一套规则，提前编译才开始划算。

这里最容易犯的错误是把“索引”当成事实源。索引只是派生数据，应该可以从已验证的原始输入重新构建；真正的事实源应该保留自己的版本和摘要。

Wiki 是可重建的知识产物。删除 Wiki 后，系统应该能够从 Raw Sources 重新编译；删除 Raw Sources 后，只剩 Wiki 就失去了可信根基。

1. Raw Sources 不可被编译器改写。 2. 每个 Claim 都能追到 Source Span 与 Source Revision。 3. 编译产物可以全部删除并重建。 4. 高风险 Procedure 在进入 reviewed 前不能驱动自动执行。

知识编译不能绕过原始权限。Source、Wiki 页面和查询结果都要继承 Scope 与 Permission，过滤应该发生在召回和生成之前。

→ 补 Evidence 和 Citation → 再加入 Vector Search → 关系稳定后再建 Graph → 最后补权限、Revision、冲突和审核

第一阶段：FTS/BM25，确保精确术语能找到 第二阶段：Embedding，提升中文和语义召回 第三阶段：Hybrid Search，结合关键词与向量 第四阶段：对稳定实体建立关系图 第五阶段：补齐 Revision、权限、冲突和审核

Phase 0：先建评测集 从 30–50 个真实问题开始，标注必要 Evidence、允许版本、禁止答案和拒答条件。

验证效果时，不要只看“回答听起来不错”。至少要测四件事：命中率、证据准确率、引用覆盖率、额外延迟。

这一步很重要：如果不在真实的大字体环境复现，给某个组件加 allowFontScaling={false} 往往只是碰巧掩盖了布局问题。

按“DNS 解析 → 本机代理 → 网络出口 → Git 配置”的顺序排查。hosts 只应作为明确、临时且可回滚的诊断手段，不是长期方案。

如果堆栈里包含 webpack/lib/util/createHash、ERR_OSSL_EVP_UNSUPPORTED，且故障发生在 dev 或 build 初期，基本就是这个问题。

遇到 package.json 的 engines 与本地 Node.js 版本不匹配时，先区分 warning 与 hard failure。

它只适合明确以固定字号为产品要求的封闭场景，例如内部大屏、受控硬件终端。普通 App 应把它视为最后手段，并在设计评审中确认无障碍取舍。

团队项目不建议把忽略选项提交到仓库，因为它会掩盖其他开发机和 CI 的真实问题。

maxFontSizeMultiplier 适合导航标题、列表副标题等空间受限区域；正文、表单说明和错误提示通常不应设置得过小。

用 nvm, fnm 或 Volta 切到项目声明的 Node LTS，重新安装依赖。

如果浏览器能打开而 Git 失败，重点检查 Git 的代理配置；如果两者都失败，则更可能是 DNS、代理客户端或网络出口的问题。

如果错误发生在运行时的加密、签名或 TLS 逻辑中，而不是构建阶段，不能简单套用 legacy provider。应先确认算法、证书或上游 SDK 是否需要迁移，否则可能降低安全性。

避免采用：从第三方网站抄 IP 后长期写 hosts。它可能短暂恢复访问，却会在下一次基础设施变更时再次失效。

也可以仅给某个 script 设置该变量；重点是把它视为短期兼容层，并记录清理期限。

值得上：组件级 maxFontSizeMultiplier、弹性布局与真机大字号回归测试。

核心方法是把 reference 文件按"谁在哪个 phase 用"拆分，把同一个合规说明的三份副本压缩成一份，把 21 个 costume 模板压缩为 5 个 exemplar。结果：最重的单个 reference 文件从 162KB 降到 117KB，每次插图生成额外省 27KB 上下文。

内容压缩是锦上添花，结构分离才是关键。 文件从 162KB 压缩到 117KB，感觉很好。但真正节省大的是"A2.5 不再加载 genre playbook"那 27KB——它每次插图任务都生效，是乘法效应。

第一，发行版只消费 registry 中已发布的精确 package。禁止 file:、link:、workspace:、本地 tarball、sibling lookup 或跨仓 symlink。这样能强迫每次采用都经过版本、锁文件和干净安装。

测试通过、package 已发布、产品已构建、签名完成、CDN 可读、更新通道已激活、旧客户端成功升级，分别是不同事实。

一篇语雀文档被同步进 GBrain 后，可以被搜索、切块、建立向量和关系，但它依然可能过期、互相冲突、没有明确 Owner，甚至只是一场会议里的临时观点。它是 Raw Knowledge，不是已经发布的 Knowledge Asset。

如果把“进入索引”直接理解成“成为资产”，GBrain 数据库就会悄悄变成第二事实源。

中文检索则需要 Query Rewrite、Multilingual Embedding 与关键词检索协作，单纯把 PostgreSQL FTS 从 english 改成 simple 并不会获得中文分词能力。

这里最容易犯的错误是把“索引”当成事实源。索引只是派生数据，应该可以从已验证的原始输入重新构建；真正的事实源应该保留自己的版本和摘要。

如果一个组件只负责 while 循环、调用模型和分发 Tool，它更接近 Agent Runtime。 - 如果它还拥有 Run ID、权限、审批、恢复、证据和评测，它已经是 Harness。 - 如果它只提供 Linux、Node.js、Python 和网络，那只是运行环境，不是 Agent Runtime。

这也是为什么部署了一个 Agent SDK，并不等于拥有了生产级 Runtime。SDK 解决的是“怎样调用”，Harness 解决的是“这次调用在业务上是否受控、可信、可持续演进”。

把 Node 放进独立进程，只解决了部分故障隔离：Sidecar 崩溃后可以单独拉起，内存泄漏不会直接污染原生 Core。但如果它继承了完整环境变量、用户目录和网络权限，它仍然能够读取不该读取的文件，或者绕过审批直接访问外部服务。

Tauri capability 主要约束 Webview → 原生 Core，不会自动沙箱已经启动的原生插件或 Node Sidecar。把平台 ACL 当成完整安全方案，是一个危险的边界误判。

Evidence 是带有来源、定位、时间、范围和完整性信息，并明确支持或反驳某个 Claim 的可验证事实记录。

这条定义的锚点是“某个 Claim”。单独存在的事实，还没有获得证明方向。 没有 Claim 的 Evidence，只是 Source、Record 或 Observation。

它也不属于 Observability。Trace 和 Log 记录过程，Evidence 从过程记录、交付物或权威系统中挑出与 Claim 有关的最小事实集合。

Evidence 不等于 Agent 的自述，也不等于一段没有来源的摘要。它应该能定位回原始文档、文件、行号或 Chunk。

它同时提供两种有吸引力的部署形态： 场景 引擎 ------ 个人、本地、零服务部署 PGLite 团队共享、大规模、多机器 Postgres + pgvector

官方提供 FAST、DEEP 和 FILENAME_ONLY 等模式，也提供 MCP，适合直接挂到 Agent 上。

1. 正式知识优先查询 GBrain； 2. 问题涉及当前未提交内容时，查询 Sirchmunk； 3. 问题涉及调用链和 Diff Impact 时，查询 Understand Anything； 4. 多个结果由宿主系统合并，并保留各自 Citation； 5. 只有经过验证和审核的稳定结论，才进入 GBrain 的正式页面。

真正的问题不在业务逻辑，而在 AppKit window level、透明 panel、系统材质和启动持久化策略叠加后的边界行为。

UI 里的庆祝特效，本质是一个小型 particle system。好看的关键不是“粒子越多越好”，而是让粒子的出生位置、生命周期、运动方向、密度分布、视觉层级服务同一个动势。

最后我把层级选择暴露到了设置里：默认用最稳的普通窗口，用户可以自己切到浮动或桌面组件风格。这个决策不够“产品洁癖”，但足够工程务实。

这就是为什么透明 panel 要同时处理两层： 层 要处理什么 ------ SwiftUI view clipShape、背景、边框、视觉层次 AppKit hosting/container clear background、cornerRadius、continuous corner、masksToBounds

原因很简单：灵动卡本身已经是一个透明 NSPanel，再叠系统 material 和特殊 window level，变量太多。为了排查和发布稳定性，先减少系统合成路径。

最后我选择恢复持久化和默认打开，但把默认 window level 降到普通窗口，并把高层级选择放到设置里。这不是绝对安全，但比“默认走最高风险路径”合理得多。

这其实是一个很典型的 UI 粒子系统取舍：不是把所有效果都加上，而是删到只剩能稳定表达语义的元素。

最后我判断：在这个产品场景里，彩带收益不够高。Argos 是一个 macOS 工具，不是游戏结算页。彩带一旦做不好，负收益很明显。所以最终删掉。

段位晋级当然是好事，但它不是游戏胜利。Argos 的整体调性是克制的 macOS 工具，所以 burst 被删掉是合理的。

粒子系统本质上是每帧根据时间计算位置，然后画出来。Canvas 更贴近这个模型。

这个代码片段的重点不是 API 本身，而是思路：把“视觉偏好”从“稳定默认值”里拆出来。默认路径必须保守，高风险路径可以给高级用户选择。

持久化状态要配合故障恢复路径，否则一个开关就可能把用户锁死在崩溃循环里。

也就是说，random 只是 variation，不是 composition。

一个实用判断：如果你觉得画面“不够满”，先看热力图，不要先加粒子。

等收集到足够多真实设备反馈后，再决定要不要把更像系统小组件的层级设为默认。

适合用的场景： 1. 用户完成一个阶段性目标。 2. 系统需要表达奖励。 3. 状态变化低频且重要。 4. 动画不会打断用户工作流。

一句话：先定语义，再定动势，最后才调随机参数。

这也是我这次最有价值的判断：背景动画的优化，大多数时候不是“做得更多”，而是“让它少出现一点”。

这里有一个设计边界：背景和主 UI 需要低饱和，粒子可以高饱和。如果整个界面都高饱和，会廉价；但庆祝粒子高饱和，是语义需要。

值得上：空状态、Agent 对话页、工作台欢迎页这类内容稀疏但需要建立产品情绪的界面。用低对比、慢节奏的环境层补足空间。

Streamers / 彩带 否 方向、曲线、交叉都很难调，容易显脏 Burst / 爆点 否 在这个场景里太像烟花，不符合 macOS 工具气质 Heavy bloom / 大光晕 否 容易污染画面，让文字和桌面背景变糊

彩纸是离散粒子，单个粒子不好看也不会毁掉整体。彩带是连续曲线，一条不自然就非常显眼。

尤其在 macOS 上，全屏 overlay 下面是真实桌面和窗口。如果光晕太重，用户看到的是“脏”和“糊”，不是高级。

这个结构其实很朴素，但稳定。 很多 UI 特效最后不是赢在复杂，而是赢在“每个元素都知道自己负责什么”。

不影响交互 pointer-events: none 不挤压内容布局 position: absolute，不放进正常 flow 永远在内容下方 雾层 z-index: 0，内容容器 z-index: 1 动画成本可控 只动 transform 和 opacity

真正起作用的不是某一个色值，而是三层关系： 1. 形状不规则：每个 gradient 的大小和位置不同，避免出现一眼可识别的圆形光斑。 2. 透明边界足够长：色彩在 76% 到 82% 之间才消失，云团会更像在空气里扩散。 3. 两层方向相反：一层从左下缓慢移动到右上，另一层反向移动，页面才有轻微的深度感。

这里我刻意只用了 transform 和 opacity。它们通常可以由 compositor 处理，不会每一帧触发布局计算。

这里的 aria-hidden 也很重要。云雾没有语义，不应该被屏幕阅读器读到，更不该被当成一个可操作元素。

不像庆祝 emitter 方向、颜色亮度、confetti 形状 太乱 删除连续元素，降低 bloom，减少同步运动 不够满 distribution 先于 count 太快 lifetime、delay、fade out 不自然 motion field 先于 random 主信息不明显 toast 层级、粒子避让、颜色对比 廉价 少用爆点和大光晕，控制高饱和面积

也就是说，random 只是 variation，不是 composition。

粒子系统本质上是每帧根据时间计算位置，然后画出来。Canvas 更贴近这个模型。

elapsed 是整个系统的时钟。每个粒子根据 elapsed - delay 算自己的局部时间，再算 position、rotation、opacity。 这个模型比给每个粒子挂一堆 .animation 更可控。

1. 停在任意时刻都成立：截取动画中的任意一帧，内容层级都清楚，不能依赖某个刚好干净的瞬间。 2. 连续看 10 秒不烦：如果能明确察觉云团在左右移动，节奏已经太强；正确的感觉应该是视线离开后才意识到页面在呼吸。 3. 性能面板没有持续压力：确认动画只涉及合成友好的属性，并在低性能设备上观察掉帧和 GPU 占用。

此外，生产页面还应该补一条 prefers-reduced-motion，让用户可以在系统层面关闭或静止这类环境动画。审美不能覆盖可访问性偏好。

适合用的场景： 1. 用户完成一个阶段性目标。 2. 系统需要表达奖励。 3. 状态变化低频且重要。 4. 动画不会打断用户工作流。 不适合用的场景： 1. 高频反馈。 2. 错误提示。 3. 信息密集页面。 4. 用户正在专注输入或阅读。

每个 MCP 都可能增加： - 工具定义 - 工具调用 - 工具返回结果 - 额外的错误和重试信息

如果一个任务只需要改一个 CSS 属性，同时打开多个文档和代码 MCP，成本可能比收益更高。

如果直接把原始 CDP 暴露给模型，模型会面对大量方法、参数、Target、Frame、Node 和 Session 状态。它不仅浪费 Token，也很难稳定地完成“点击登录按钮”这种在人类看来很简单的任务。

browser-mcp 定义 Agent 看得懂的 Browser Tools，browser-core 则把 CDP 包装成有状态的 Browser Session。

// Agent 循环 while(!this.abortController.signal.aborted && !this.hasFinished) { // 当任务没有被取消或完成时执行 Agent 循环 const awareResult = await aware.run();

为什么要单独起一个本地 Server，而不是全部塞进 Extension Background？ 我的理解是，独立进程给 Agent Runtime 提供了更稳定的执行边界。它可以拥有自己的数据库、文件系统访问、长任务、模型 SDK、MCP Client 和生命周期，也能被 Extension、CLI、MCP Client 等多个入口复用。

这三轮不是固定模板。小改动可以一轮完成；当目标、证据和日志明显发生变化时，再切 Session。

You are a tool use expert. You should call the appropriate tools according to the aware status and environment information.

它回答的是“Agent 如何接入能力与资源”，不负责定义 Goal、Task、Run、Evidence 或 Evaluation。A2A 规范也把两者定位为互补协议：MCP 面向工具和资源连接，A2A 面向 Agent 之间的任务协作。

Capability：能做什么 Tool：通过什么接口做 Skill：按什么方法做 Model：由什么推理能力参与 Runtime：在哪个执行引擎里做

MCP 解决 Host、Client、Server 之间的上下文与能力交换，不等于完整 Agent 领域模型

这也意味着，十二个对象是一套用于架构决策的参考模型，不是对任何单一 SDK 或协议的重新命名。

优先做 Extension 如果产品主要是： - 总结、翻译和问答； - 读取当前 Tab 内容； - 在 Extension 权限范围内填表和导航； - 快速验证产品价值； - 可以接受跟随 Chrome 的产品入口和更新机制。

代价也很明显：一旦 fork Chromium，就要长期维护 Patch Stack、解决上游冲突、承担跨平台编译和安全更新压力。fork 不是“更高级”的默认答案，它只是用更高的维护成本换取更深的产品控制权。

本文以 BrowserOS 仓库的 5ddb0f2d0 commit 为源码快照。BrowserOS 后续会继续变化，固定 commit 能让文中的目录、代码和发布流程保持可复查。

这套组合值得用，但应该把它当成上下文管理方案，而不是工具收藏。

如果目标是让不同 Agent 稳定使用真实浏览环境，那么最值得先建设的，是独立于模型和 UI 的 Browser Runtime。

这里存在一个重要边界：BrowserOS 源码能证明这些组件和调用关系存在，但不能仅凭静态源码证明每个网站、每个模型、每个任务都能可靠完成。任务成功率仍然需要基于真实任务集、Provider 和环境做运行时评测。

useAgentFow hook 接收用户输入后，创建一个 AgentFlow 实例，并调用 agentFlow.run() 触发 Agent 执行

🔍 1. 盲听抓主旨 现阶段没办法做到记录主题、观点 - 我确定听到的词：computer science、What's an algorithm、instruction、step-by-step - 我猜他在说：算法

✍️ 2. 逐句听写 1、What's an algorithm. In computer science, an algorithm is a set of instructions for solving some problem, step-by-step. - 弱读： - for：[fɔ:r] - [fər] - an：[æn] - [ən] - 连读： - What's an algorithm - [wɑ:tsənælgrɪðəm] - is a set of - [ɪzəsetəv]

📚 3. 重点语言积累 - algorithm [ˈælɡərɪðəm]：n. 算法，运算法则 - instruction [ɪnˈstrʌkʃn]：n. 指令

🗣️ 4. 跟读任务 - 跟读第 1 句话 30 遍

This is because the declaration gets hoisted above the console.log, but the initialization stays below that line. So it doesn't know anything about the value 27 at the time of execution.

Variables declared with the keyword let are not hoisted. Let's have a look at the same example we just looked at. But we'll replace the keyword var for let. As you can see, we get an error saying that x cannot be accessed before initialization.

According to the rules of block scope, variables that are declared inside of a block or a pair of braces can only be accessed inside of that block and nowhere outside of it.

To understand why that happens, we also need to understand the difference between var and let when you use var. In a for loop, that variable actually gets hoisted up into the parent scope, which in this case would be the global scope.

输出顺序：1 → 4 → 3 → 2 解释： 1. 同步任务输出 1 和 4。 2. 当前宏任务（主线程）结束后，执行微任务队列中的 Promise.then，输出 3。 3. 最后执行宏任务队列中的 setTimeout，输出 2。

以下以浏览器为范围；Node.js 的事件循环阶段和 nextTick 队列不直接套用此顺序。

So it would seem like it should log out 0, 1, 2, but if we log it out, it actually console logs 3 three times.

The reason it logs 3 three times is because the timeout doesn't run till 100 milliseconds later. Long after that, For Loop has completed and iterated up to 3.

前提条件 - 数组必须有序：升序或降序排列（默认为升序）。 - 时间复杂度：O(log n)，每次排除一半元素，效率远超线性查找（O(n)）。

变体：查找左右边界 左边界​（第一个匹配元素） js function lowerBound(arr, target) { let left = 0, right = arr.length; while (left < right) { const mid = left + Math.floor((right - left) / 2); arr[mid] < target ? (left = mid + 1) : (right = mid); } return arr[left] === target ? left : -1; }

nSum 系列问题的核心思路就是排序+双指针。 先给数组从小到大排序，然后双指针 left 和 right 分别在数组开头和结尾，这样就可以控制 nums[left] 和 nums[right] 这个两数之和的大小

- 当 sum == 0 时，nums[left] == nums[left + 1] 则会导致结果重复，应该跳过，left++ - 当 sum == 0 时，nums[right] == nums[right - 1] 则会导致结果重复，应该跳过，right--

提示方法 HotpotQA (问题回答，精确匹配， 6-shot ) FEVER （事实验证，精确度， 3-shot ） ALFWorld (基于文本的游戏，成功率， 2-shot ) WebShop (网页交互，成功率， 1-shot )

标准输入输出 28.7（准确率） 57.1 无法执行 无法执行 仅推理 基于思维链（Chain of Thought，CoT） 29.4 56.3 无法执行 无法执行 仅行动 25.7 58.9 45 30.1 最佳 ReAct 方法 35.1 64.6 71 40

总体来看，不同提示方法在各个任务上表现差异明显，监督/模仿学习这个当前最优技术在足够样本的情况下在多数任务中表现最佳，而最佳 ReAct 方法在无大量样本的情况下在多个任务中表现突出。

保留论文的原始实验语境、图表和原始项目链接，不冒充本人研究成果。

This makes hoisting a good topic for an interview question, as it can really test the candidates knowledge of the language.

Which will help in our next Javascript interview, let's begin.

To take a look at one of the most famous Javascript trick questions that will wreck you on an interview if you don't know closures.

CLAUDE.md 是常驻规则。 它每次都进上下文，所以只放最高优先级、最稳定的东西：比如"博客每篇至少 3 张插图""性能规则不能回退""发布流程怎么走"。它贵，所以要克制——不该把操作细节全塞进来。

skill 是按需加载的操作手册。 它平时不占上下文，只有当任务命中触发词（"做 mac 应用图标"、".icns"）才被拉进来。这意味着 skill 可以写得很详细、很长，因为它不是常驻成本。

写了没触发词 = 白写。 skill 描述里不写"mac 应用图标 / .icns"，下次问"帮我做个应用图标"时它根本不会被加载。触发词是 LLM wiki 的"索引"。

写太细放错层 = 变负担。 把一次性的操作细节塞进 CLAUDE.md，每次会话都要为它付上下文成本。分层很重要：常驻的极简、按需的详尽。

如果同一个 Skill 同时覆盖它们，Agent 很容易把“本地源码已经通过测试”说成“发行版已经采用”，或者让发行版直接依赖平台的 sibling checkout。前者缺少发布和安装证据，后者会让本地环境掩盖真实的 package 边界。

第一，发行版只消费 registry 中已发布的精确 package。禁止 file:、link:、workspace:、本地 tarball、sibling lookup 或跨仓 symlink。这样能强迫每次采用都经过版本、锁文件和干净安装。

第三，交付状态必须拆开记录。测试通过、package 已发布、产品已构建、签名完成、CDN 可读、更新通道已激活、旧客户端成功升级，分别是不同事实。

如果工作只发生在一个产品仓库，且没有跨仓发布或受控凭据边界，暂时不必为了形式拆 Skill。真正需要关注的是：Agent 是否会因为错误的上下文和依赖方向，做出无法被交付证据支撑的结论。

Evidence 是带有来源、定位、时间、范围和完整性信息，并明确支持或反驳某个 Claim 的可验证事实记录。

它也不属于 Observability。Trace 和 Log 记录过程，Evidence 从过程记录、交付物或权威系统中挑出与 Claim 有关的最小事实集合。

如果一个组件只负责 while 循环、调用模型和分发 Tool，它更接近 Agent Runtime。 - 如果它还拥有 Run ID、权限、审批、恢复、证据和评测，它已经是 Harness。 - 如果它只提供 Linux、Node.js、Python 和网络，那只是运行环境，不是 Agent Runtime。

这也是为什么部署了一个 Agent SDK，并不等于拥有了生产级 Runtime。SDK 解决的是“怎样调用”，Harness 解决的是“这次调用在业务上是否受控、可信、可持续演进”。

worktree 不是隔离环境的万能替代品。 - 它们仍共享同一个仓库的 Git 对象库，不能把它当成权限隔离。 - 端口、全局缓存、Docker 容器、数据库和远端环境依然可能冲突。 - 同一分支不能被两个 worktree 同时 checkout；这是 Git 用来避免同一分支出现两份独立未提交状态的保护。

真正的收益是，每个 Agent 的输入和输出都更明确：它只能在自己的目录里修改；构建日志、node_modules、生成文件和未提交 diff 都不会悄悄影响另一个任务。

Sidecar 是由主应用启动和监管、通过明确协议协作的独立辅助进程。它适合隔离异构运行时和高风险能力，但进程隔离不等于安全沙箱，权限仍然必须由主应用强制执行。

把所有能力塞进一个进程当然最快，但代价也很直接：UI、数据库、凭据、文件系统和 Agent Runtime 混成一团，一个 Provider SDK 崩溃或越权，就可能拖垮整个应用。

状态：未核实 已记录结果：未记录（不能据此推断项目没有成果或尚未完成）

场景：2026-07-10 的公开文章回顾个人工具的开发动机与分工；确切立项日期未知。这里保留当时的项目自述，不据此推定当前版本、用户规模或上线状态。

它叫 Owlet，是我用 Claude Code 和 Codex 一起 vibe 出来的 macOS 小工具：常驻菜单栏，实时显示 Claude Code 和 Codex 的 token 消耗，附带一个贴合刘海的灵动岛面板、一个桌面灵动卡、还有一个看历史用量和排名的 dashboard。

包含逐句听写、语音标记和明确的 TED-Ed 来源，属于具体学习材料。

📚 3. 重点语言积累 - algorithm [ˈælɡərɪðəm]：n. 算法，运算法则

长期积累的技术词汇、音标与应用例句，适合检索复习。

Javascript（JS）是一种具有函数优先特性的轻量级、解释型或者说即时编译型的编程语言。

- 弱读： - for：[fɔ:r] - [fər] - an：[æn] - [ən] - 连读： - What's an algorithm - [wɑ:tsənælgrɪðəm] - is a set of - [ɪzəsetəv]

- 连读： - would you：[wʊdju]（我的油）-(同化) [wʊʤu]（我竹） - in a：[ɪnə] -(辅元连读) [ɪnə] -(懒音) [ənə]

- 连读 - point at each：[pɔ-ɪn-tæ-ti:-ʧ] -(Silent T) [pɔɪ-nə-i:-ʧ] - your're：[jər]（叶er） - one at a time：wʌ-nə-nə-ˈtaɪm

🗣️ 4. 跟读任务 - 跟读第 1 句话 30 遍 - 跟读第 2 句话 30 遍 - 跟读第 3 句话 30 遍 - 跟读第 4 句话 30 遍 - 跟读第 5 句话 30 遍 - 跟读第 6 句话 30 遍 - 跟读第 7 句话 30 遍 - 跟读第 8 句话 30 遍

pnpm 的 shamefully-hoist 选项故意用此词命名，暗示开启它是一种「不光彩」的行为——它退回了 npm/yarn 的扁平化 node_modules 模式，破坏了 pnpm 严格依赖隔离的设计初衷。

通过虚拟 DOM 技术，React 优化了性能：仅在状态变化时计算差异并更新实际 DOM 的对应部分，而非直接操作整个 DOM 树。

它的核心概念是将应用的整个状态存储在一个单一的对象树中，这个状态树是只读的。当要修改状态时，只能通过发送一个被称为 action 的纯对象来描述发生了什么。

它的设计轻巧且易于使用，使得开发者能够处理复杂的与状态相关的操作，同时无需大量的样板代码。

让我们试着用更正式一点的伪代码来描述它——这是一种类似英语的语法，看起来像编程语言。

Javascript（JS）是一种具有函数优先特性的轻量级、解释型或者说即时编译型的编程语言。

Node.js 是一个免费、开源的跨平台 Javascript 运行时环境，让开发者创建服务器、Web 应用程序、命令行工具和脚本。

WebAssembly（缩写为 Wasm /'wɔzəm/）是一种基于堆栈的虚拟机的二进制指令格式。

🔍 1. 盲听抓主旨 现阶段没办法做到记录主题、观点

提示 - 来源：TED-Ed - 链接： - 时长：4:58 - 日期：2026-01-08 - 难度自评：️️ - 核心关键词：algorithm, step-by-step, problem-solving

长期积累的技术词汇、音标与应用例句，适合检索复习。

当前的 GBrain MVP 先使用 FTS，原因很务实：本地部署简单、依赖少、可解释，而且对项目里的英文领域术语已经有效。后续再加入 Embedding，解决中文自然语言和同义表达的召回问题。

Hybrid Search = FTS/BM25 + Vector Search + Metadata Filter

所谓“向量 RAG”在生产里通常不是只查向量：BM25 守住精确词，Vector Search 处理同义表达，Metadata Filter 先排除过期和越权内容。

没有这些 Metadata，检索器可能把旧版本、测试环境或无权限文档排在最前面。相似度高，不等于业务上可用。

GraphRAG 的优势是关系可追踪、路径可解释，适合架构依赖、权限关系、组织知识、实体关联和影响分析。代价是数据建模和维护成本更高，图谱抽取也可能引入错误关系。

如果团队不能维护这些约束，GraphRAG 会把“检索偶尔漏片段”变成“图谱稳定地提供错误关系”。

不从所有自然语言里自由抽取任意关系，而是先定义少量 Typed Edge

GraphRAG 解决的是“沿什么关系找到答案”，不是“图里的结论天然可信”。每一跳仍要锚定带版本的 Source Span。

编译式 RAG，是把不可直接高效消费的 Raw Sources，在构建阶段加工成面向后续任务的、可检查、可版本化、可增量更新的知识中间表示；查询时优先读取这些编译产物，必要时回到原文核验。

编译式 RAG 的核心不是提前写摘要，而是让知识产物进入版本、校验和重建闭环；查询时对关键 Claim 仍需回查原文。

如果一个 Wiki 页面引用另一个 Wiki 页面，最后却找不到原文，这会形成循环证据。页面之间可以互相导航，事实依据必须落回 Source。

一项 2026 年的小规模预注册比较发现，LLM-compiled Wiki 更擅长跨论文连接与 Claim 级引用对齐，但测试设置下每次查询使用的 Token 反而明显高于 RAG；分解式 RAG 又追回了大部分综合能力差距。

第一阶段：FTS/BM25，确保精确术语能找到 第二阶段：Embedding，提升中文和语义召回 第三阶段：Hybrid Search，结合关键词与向量 第四阶段：对稳定实体建立关系图 第五阶段：补齐 Revision、权限、冲突和审核

Phase 0：先建评测集 从 30–50 个真实问题开始，标注必要 Evidence、允许版本、禁止答案和拒答条件。没有这一步，后续只能靠“看起来更聪明”做选型。

编译的收益依赖复用。同一批资料只问一次，直接 RAG 通常更便宜；团队每周都要重新综合同一套规则，提前编译才开始划算。

编译能否回本，要用自己的 Query 分布、更新频率和 Review 成本测。

很多生图流程第一步就是选模型。我现在反过来：先问最终文件要被谁消费。

目前 better-imagegen 把常见任务拆成独立工作流： 类型 默认交付重点 ------ Portrait / Cover 构图、人物、情绪、WebP 压缩 Text Poster 生图负责视觉底板，HTML/CSS 负责准确文字 Logo / Icon 透明背景、alpha 边缘、缩小后的可读性 macOS App Icon squircle、安全区、iconset、.icns Static Wallpaper 4K、PNG、桌面图标可读区域 Dynamic Wallpaper 多状态帧、HEIC、系统元数据 Sprite Loop 精灵图、编号帧、GIF 预览、manifest Image Edit 参考图输入、身份保持、局部变化

我持续完善 better-imagegen，把视觉资产的类型选择、规格约束、后处理、失败处理和验收写成可复用流程。它服务封面、角色、图标和帧动画等不同交付，不把一张模型生成的图片视为全部工程产物。

做 AI 视觉资产时，我先确定文件由谁使用，再决定生成与后处理流程。需要准确文字时，用 HTML/CSS 排版；需要同一角色时，优先参考图编辑；图标和帧动画要检查透明通道、循环与实际运行尺寸，不能只验收大图预览。

一个可执行的 Prompt，不是堆“高级感、电影感、8K、杰作”这类形容词，而是写清一份资产合同。 我现在通常至少写这 6 类信息： text 1. Subject：画面里必须有什么 2. Composition：主体位置、留白、视线方向、帧网格 3. Style：摄影、插画、像素、产品渲染等视觉语言 4. Delivery context：博客、社交媒体、菜单栏、桌面、App Icon、头像 5. Hard constraints：人数、透明背景、尺寸、帧数、角色身份 6. Negative constraints：不要文字、不要 Logo、不要水印、不要额外肢体

例如做 Argos 菜单栏猫头鹰动画时，“可爱猫头鹰”远远不够。真正决定可用性的约束是：横向精灵图、固定 6 帧、每格等宽、透明背景、暖橙色轮廓、18px 仍能辨识、首尾动作连续。 模型生成的是像素，但 Prompt 描述的是运行时约束。

我最后采用的流程是： text AI 生成无文字视觉底板 ↓ HTML / CSS 叠加真实文本和品牌组件 ↓ 浏览器渲染并截图 ↓ WebP 压缩 + 尺寸检查

如果每次都从文本重新生成，脸型、发型、服装结构和整体年龄感都会漂。更可靠的方法是把现有角色图作为 reference，通过 image edit 只修改服装、姿态、表情或手持物。

并增加了 4 个验收条件： 1. 每个 cell 尺寸完全一致，不能靠肉眼切。 2. 首帧和末帧的姿态能自然衔接。 3. alpha 通道真实存在，不能用棋盘格“画透明”。 4. 必须在实际运行尺寸验收，而不是只看 512px 预览。

稳定流程至少包括： text 生成透明源图 → 检查 alpha 边缘 → 裁掉异常透明留白 → 设置视觉安全区 → 生成 macOS squircle 底板 → 输出 16 / 32 / 128 / 256 / 512 / 1024 尺寸 → 组成 .iconset → 转换为 .icns

better-imagegen 现在默认使用 GPT Image 2，失败后归一化 Prompt 重试一次，再回退到 Gemini，最后才考虑 Doubao。 但 fallback 不是无脑串行，因为不同模型的交付特性不同：

Doubao Seedream 普通视觉任务的兜底能力 水印和最小像素面积会影响透明图、精灵图 因此透明 Logo、Icon 和 sprite sheet 不应该回退到一个会破坏 alpha 或网格的模型。Fallback 的目标不是“总能出图”，而是“仍然能交付同一种资产”。

7 月 9 日 GPT → Gemini → Doubao 的回退链路、文字型竞赛封面流程

所以我给每个产物增加了同名 JSON 元数据： json { "file": "cover.webp", "model": "gpt-image-2-all", "requested_size": "1536x1024", "actual_resolution": "1280x720", "generation_time_seconds": 38.8, "output_format": "webp", "postprocess": "center-cropped to 16:9; WebP quality 78", "prompt": "..." }

我会把过程拆成 4 层： 1. 类型层：这是封面、图标、壁纸还是动画？ 2. Prompt 层：哪些构图和负向约束真正起作用？ 3. 后处理层：裁切、透明、压缩、拆帧、系统封装做了什么？ 4. 验收层：在真实博客、菜单栏、Dock、网页里效果如何？

场景：2026-07-15 的公开文章回顾近期实践；项目起始日期未详。这里保留维护方向，不推定当前支持模型或发布状态。

状态：未核实 已记录结果：未记录（不能据此推断项目没有成果或尚未完成）

这里保留维护方向，不推定当前支持模型或发布状态。

这就是我理解的 Agent skill：不是一段“万能指令”，而是把成功经验变成一套带条件分支、失败处理和交付标准的操作系统。

根因是纯 SPM 的 macOS app 手动组装成 .app 之后，Swift Package Manager 默认生成的 Bundle.module 资源定位逻辑找不到资源包，会直接 fatalError；而我在 8 处加载资源里，唯独一处漏用了自己写的兜底封装。

问题在于，它内置的候选路径是为 swift build/swift test 那套 .build/ 目录布局准备的。当你手动把可执行文件塞进 Owlet.app/Contents/MacOS/、把资源包塞进 Contents/Resources/ 时，布局对不上，Bundle(url:) 在它预设的候选路径里全部返回 nil，于是走到最后一行崩掉。

全项目一共 8 处加载资源，其中 7 处都规规矩矩用了 AppResourceBundle.module：hook 脚本、app 图标、菜单栏猫头鹰、Dashboard 图片、本地化 bundle……唯独排名图标这一处漏了网

如果我能把 Bundle.module 的可见性收窄、逼所有资源加载都必须走 AppResourceBundle，这个 bug 从一开始就写不出来。可惜 SwiftPM 合成的 Bundle.module 是 internal 可见的，没法轻易禁掉——退而求其次，至少可以加一条 lint / grep 规则，在 CI 里扫「除了 AppResourceBundle.swift 之外任何文件出现裸的 Bundle.module」直接 fail。

如果只给字典的每次下标访问加一把细粒度锁（读一次锁一次、写一次锁一次），会发生什么？ 线程 A 读到 offset=1000，线程 B 也读到 offset=1000。两个线程都从 1000 开始读文件、各自解析、各自把"新 offset"写回。其中一个的结果被覆盖，offset 错乱，同一段 Token 用量被重复计入。

这里的不变量是"cache 里的 offset 必须和已经解析进去的字节严格对应"。要维持它，整个 discoverSessions() pass 必须串行执行。所以正确的修法是一把粗粒度锁，锁住整趟

原因很本质：async 函数可能在任意 await 处挂起，挂起之后恢复执行的线程不一定是原来那个线程。而 NSLock 是要求"谁上锁谁解锁、同一线程"的。如果你在 lock() 和 unlock() 之间跨了一个 await，挂起前后换了线程，就会变成"A 线程上锁、B 线程解锁"，直接是未定义行为。

- 锁的粒度对齐不变量，不对齐单个操作。 遇到 read-modify-write，先问自己"这三步之间的中间状态能不能被别人看到"，不能就整段串行。

Swift Data 的 index 是绝对的。removeFirst(n) 之后，它的 startIndex 会前移到 n，而不是回到 0。

这不是偶发的并发时序问题，是个确定性 bug：只要有一个 Claude 会话在跑、它的 JSONL 被追加写入两次，就必崩。之所以之前一直没暴露，是因为上一个并发崩溃发生得更早，先把进程带走了；修掉前一个，这个就顶到了最前面。

- 切片类型的索引从 startIndex 起，别信字面量 0。 Data、ArraySlice、Substring 的 startIndex 随时可能不是 0，尤其在 removeFirst / 切片之后。遍历用原生 index，不用 Int 硬编码。

这种「开发机好好的，用户机必崩」的 bug，往往指向同一类问题：运行环境的资源布局，和你开发时不一样。

答案是：堆内存被写坏之后，整个进程都在雷区里跑。 Thread 4 把字典的底层存储写坏，破坏的是共享的堆。此后任何线程在任何位置做一次内存访问，都可能踩到那片被污染的区域，然后随机崩溃。

防它的关键不在于更聪明地写这一行，而在于让这一行根本没机会写错。

场景 首选 理由 --------- 新写的、可以 async 化的共享可变状态 actor 编译器强制隔离，从根上杜绝数据竞争，不用自己管锁

湖面变成主操作的湖水青，水杉变成成功和运行状态，远山承担次级信息，雾白负责空间和层次，晨光金只留在极少量高光里。母题也同时定义了禁区：不做赛博霓虹，不让金色主导 surface，不用重阴影堆层级，不为了“可爱”牺牲信息效率。

1. 文件监听用 Dispatch Source，而不是轮询。 之前有些实现会 sleep-loop 检查 active session，我全部砍掉了。 2. JSONL 增量读取。 50 MB 的会话日志不应该造成 50 MB 内存峰值。

这些规则都被写进了 CLAUDE.md 和 AGENTS.md，成为后续所有改动的底线。一个工具要是自己先变成电老虎，就没资格监控别人的 token 消耗。

后来为了让灵动卡接近系统组件的玻璃质感，我们尝试过 macOS material 和窗口采样，特定组合会带来稳定性风险。最后我没有放弃“雾”，也没有为了视觉效果继续赌系统边界，而是改用纯 SwiftUI 绘制柔焦层：保留雾白的视觉职责，换掉高风险实现。

退而求其次，至少可以加一条 lint / grep 规则，在 CI 里扫「除了 AppResourceBundle.swift 之外任何文件出现裸的 Bundle.module」直接 fail。

@unchecked Sendable 这类逃生舱不是不能用——actor 化整个 adapter 也要改协议、改一堆调用点，工程上未必划算。

它们分别描述的是检索方式、数据结构、工程系统和知识治理方法，不能简单排成一条替代关系。

这条链路里，Source 是事实，Index 是为了查询而生成的派生数据，Evidence 是本次回答实际采用的依据。三者不能混为一层。

它们解决的是不同层次的问题，今天仍然会同时出现在一套系统里。

Hybrid Search = FTS/BM25 + Vector Search + Metadata Filter

所谓“向量 RAG”在生产里通常不是只查向量：BM25 守住精确词，Vector Search 处理同义表达，Metadata Filter 先排除过期和越权内容。

Reranker 只能重排已有候选。正确文档没有进入 Top 50，后面的模型再强也救不回来。

GraphRAG 的优势是关系可追踪、路径可解释，适合架构依赖、权限关系、组织知识、实体关联和影响分析。代价是数据建模和维护成本更高，图谱抽取也可能引入错误关系。

GraphRAG 解决的是“沿什么关系找到答案”，不是“图里的结论天然可信”。每一跳仍要锚定带版本的 Source Span。

没有真实的关系查询，就不该为了架构图好看而上 GraphRAG。

在这个 Agent 应用里，我希望每一个关键回答都能回答三个问题： - 依据是哪条 Evidence？ - 来源是哪一个事实源？ - 如果事实发生 Revision，当前回答是否仍然有效？

先检索全部内容、再在答案阶段隐藏结果，是危险设计。

风险越高，越要加强： - Source Span 级 Citation； - 人工 Review； - Revision Pinning； - Permission / Approval； - Dry Run 与 Evidence； - 无证据拒绝执行。

我的当前门槛是：先用确定性 Query Rewrite；中文评测出现 Recall@5 5% 时，再把 Multilingual Embedding + Hybrid Search 提到下一阶段。这两个数字服务于当前项目，不是行业标准。

Vector RAG 和 GraphRAG 已经有相对明确的工程含义，“编译式 RAG”却还不是一个边界稳定的标准术语。

编译能否回本，要用自己的 Query 分布、更新频率和 Review 成本测。

FTS 会先把文档分词、建立索引，再快速查找包含查询词的文档或 chunk。

FTS 负责找候选结果，BM25 负责判断谁更相关。

GBrain 导入时会解析 Front Matter、生成稳定 Slug、计算 Content Hash、创建 Page、拆分 Chunk，然后建立 Keyword Index；配置 Embedding 后还会生成向量，并从文档链接或代码引用中提取 Edge。

这些步骤把内容变得容易搜索，但没有替代 Source 的所有权、版本和审核流程。Page、Chunk、Embedding 和 Edge 都应该可以从已知 Source 重新构建。

FTS 的特点是“看词”，不真正理解语义。因此“Revision 是什么”和“Revision 的定义”未必会得到同样好的结果，中文自然语言问题也可能因为分词和语言配置而召回不稳定。

Hybrid Search = FTS/BM25 + Vector Search + Metadata Filter

这个结果说明它不是“完全不支持中文”。索引里恰好存在的完整中文词可以命中，英文领域词也很稳定；真正不可靠的是中文自然问句。

simple 的主要作用是取消英文停用词和 stemming，不会自动把： text 工作区修订是不可变资产集合快照 切成： text 工作区 / 修订 / 不可变 / 资产 / 集合 / 快照

搜索 Workspace Revision 时，BM25 往往比纯向量相似度更可靠，因为向量模型可能把一些语义相近但并不包含这个精确标识符的文本排得很前。

Embedding 能把问题和文档映射到语义空间，适合处理： text Revision 是什么？ 工作区如何固定可信资产？ 一次执行怎样保证知识版本一致？

它擅长语义相似，不保证函数名、错误码、配置项、缩写和精确领域词一定排在最前面。

Keyword Search ─┐ ├→ RRF Fusion → Metadata / Permission Filter → Evidence Vector Search ──┘

因此，LLM Wiki 的关键问题不是“模型能不能回答”，而是： 这条回答依据的事实是什么？事实来自哪里？什么时候有效？谁能修改？

没有 Evidence，LLM 只是“说得像”；有 Evidence 和 Citation，回答才具备审计能力。

一篇语雀文档被同步进 GBrain 后，可以被搜索、切块、建立向量和关系，但它依然可能过期、互相冲突、没有明确 Owner，甚至只是一场会议里的临时观点。它是 Raw Knowledge，不是已经发布的 Knowledge Asset。

如果把“进入索引”直接理解成“成为资产”，GBrain 数据库就会悄悄变成第二事实源。

第一阶段：FTS/BM25，确保精确术语能找到 第二阶段：Embedding，提升中文和语义召回 第三阶段：Hybrid Search，结合关键词与向量 第四阶段：对稳定实体建立关系图 第五阶段：补齐 Revision、权限、冲突和审核

不建议一开始就上完整 GraphRAG。知识量还小、关系还没稳定时，先把事实源、分块、检索、引用和版本做好，收益更高。

第一阶段：Query Rewrite 这是成本最低、应该最先做的一步。

第三阶段：真正的本地中文 FTS 如果后续评测证明 Embedding 仍不能满足精确中文术语检索，再给应用侧增加中文 Side Index： text GBrain Vector Search + GBrain Keyword Search + 本地 Tantivy 中文 BM25 → RRF Fusion

验证效果时，不要只看“回答听起来不错”。至少要测四件事：命中率、证据准确率、引用覆盖率、额外延迟。尤其要做反向问题：知识库没有答案时，系统能不能明确说不知道，而不是编造一个答案。

至少观察下面几个指标： 指标 关注的问题 --- --- Recall@5 正确文档是否进入前 5 MRR@5 正确文档排得是否足够靠前 Zero-hit Rate 中文问句是否仍频繁零召回 Citation Precision 引用是否真的支撑回答 P95 Latency Hybrid Search 增加了多少延迟 Scope Leakage 是否检索到其他 Workspace 的知识

最后一项尤其重要。一个全局 Brain 如果没有绑定 Workspace 和 Source，再高的召回率也可能意味着更严重的跨项目污染。

Chromium 的原生 Accessibility 系统支持辅助技术发起默认动作、聚焦、改变值与滚动。CDP 的 Accessibility 域则主要提供查询和事件，并没有通用的 click、fill 接口。不能因为使用了 Accessibility.getFullAXTree()，就假定动作执行也已经解决。

执行 click @e2 时，后台解析此前保存的引用，优先尝试关联的缓存节点，再进入元素定位和可操作性处理。节点替换或文档导航会影响这项关联；角色与名称恢复存在歧义时应停止动作。

“不用截图”“只给模型语义快照”“完全通过原生 Accessibility API 操作”是三种不同的实验。

这个区分决定了实验结论的范围：模型没有观察 DOM，不代表系统内部完全不接触 DOM。本文允许后者，但不允许执行器把额外读到的页面内容悄悄补给模型。

读取 AX Tree 也不代表整套工具只使用 AX 信息：当前实现还包含 DOM 范围解析、可点击线索补充等处理，不能把这张漫画理解为纯 AX-only 约束。

当前官方文档的规则是：仍然存在的 DOM 元素可以在后续快照和同一文档更新中保留引用；页面或 iframe 导航、元素替换会影响引用有效性。没有对应 DOM 节点的虚拟无障碍节点，其引用只适用于当前快照。

因此，稳定的节点引用也不能独立证明业务对象没变。列表可能复用同一个 DOM 容器展示另一条记录；“购买”按钮可能仍然存在，但页面当前商品已经不同。

虚拟列表还需要额外关注观察范围。总行数、行索引不能代表未挂载行的内容；滚动、翻页或筛选后仍要重新观察。

目标可观察 必要控件和字段是否出现在语义表示中？ 修复页面语义，或明确采用其他观察方式 目标可区分 重名元素能否由行、区域、业务对象关联？ 扩展带范围的定位；当前不能消歧则停止 动作受支持 执行器是否能把 AX 目标转换成正确操作？ 补齐角色、动作和 frame 支持，再归因于页面 结果可验证 参数与业务结果能否通过 AX 再次确认？ 保留受阻或未验证状态，不以调用成功替代业务结果

snapshot -i 偏向可引用的操作目标，“有货”这样的普通结果文字可能被排除；某些标题和表格单元格能够留下，也不保证所需字段完整。找动作目标时可以压缩观察，检查业务结果时则需要保留相关正文、状态或表格内容，不能把“交互快照里没出现”理解为“页面没有”。

第二种写法可以向辅助技术声明“我是按钮”，但 role="button" 不会自动添加 Enter/Space 激活、事件处理或正确的禁用逻辑。可用原生 button 时，优先直接使用。否则 AX 中有 button，也可能遇到“按键没有反应”的实现缺口。

原生 disabled 在支持它的控件上具有实际禁用行为，通常也使其退出 Tab 顺序；单独 aria-disabled 只传达不可用状态，不自动阻止事件。

页面若把搜索按钮暴露成一个有明确名称的 button，Agent 就有直接证据。若它只是一块没有名称的图形，单靠这份语义观察可能无法确定用途，需要补充截图、上下文或其他受控读取。

getFullAXTree() 的 full 也不等于自动解决所有跨进程 iframe，跨 frame 支持仍需由具体执行器单独验证。

生成引用时，后台保留引用与节点、frame 和文档的关联；后续文本中出现的 @e1 因而能回到浏览器中的具体目标。

AX 是 Accessibility（无障碍）的常用缩写，AX Tree 即 Accessibility Tree，无障碍树。

本文这条路径更适合称为页面观察裁剪，具体包括语义投影、结构压缩和快照输出过滤。这些处理不会把网页里的 DOM 节点删除，也不会改变页面的业务状态。

关键变化包括后台运行时和浏览器控制层，不能简化成“旧版是 Node CLI，新版才有 Rust CLI”：0.19.0 的默认 CLI 就已经是 Rust；该版本还提供实验性、需选择启用的 --native Rust daemon。

旧版 Playwright 也能通过 connectOverCDP() 连接 Chrome

TaleFrame 的服务端采用一个 Next.js 项目。管理员页面与 API 放在一起，共享输入校验、内容模型和发布逻辑。

所以，“小说列表存在哪”的完整答案有两层：管理员维护的书目在 books，读者读取的列表由当前发布指针关联 releases 后生成。

“小说文本存在哪”同样需要区分草稿与发布态：编辑器读写 chapters.body，读者接口读取 chapter_versions.body。

这里的 Postgres 由 Neon 提供。Vercel 是后台与接口的运行平台，也提供 Blob；数据库和文件存储各自承担持久化职责。

这组数据支持的是一个有限判断：在当前书库规模下，正文并没有大到必须拆出另一套文本文件服务。

也可以将正文存成对象文件，数据库只保留索引。但这样需要额外处理上传成功而数据库更新失败、快照引用了不存在的对象、旧对象清理与回退发生冲突等情况。

封面则值得先处理。图片上传后统一解码、限制尺寸并转换成 WebP，比让几 MB 的图片直接进入小说列表更符合移动端需要。

封面采用另一条路径：后台验证图片，限制上传大小，缩放到最多 768 像素宽并转成 WebP，再上传 Blob。

在同一个数据库事务里切换当前发布版本，并递增全局目录版本。

当目录变了，App 校验数据结构、章节引用与地址格式，成功后原子替换本地目录。更新失败时保留之前可用的内容，而不是先清空书库。

这也意味着发布不是实时推送。读者需要发生刷新请求，目录还可能处于共享缓存有效期内。

下架也需要明确语义：服务端可以移除公开目录，并拒绝后续正文读取；已经到达 CDN 的响应可能在缓存期内继续可用，设备上已有的离线内容也无法靠下架动作远程抹除。

TaleFrame 采用目录版本检查与按章缓存。这里的“在线更新”指书目和正文更新，不包含 APK 升级、动态下发可执行代码或绕过应用商店更新。

客户端正文与封面共用约 100 MiB 的自动缓存预算，按文件最近访问时间淘汰。这个上限不是整台 App 的总存储上限：目录和阅读偏好另行保存。

已经打开的阅读页保留其书籍版本对象，目录刷新不会立即把正在阅读的章节切换到新版本。

在线版本的安装包不再携带整套历史小说资源，因此首次打开需要网络。之后能否离线阅读，取决于相应章节是否已经缓存。

本项目沿用了已有的 Vercel Pro 计划，数据库采用 Neon Free，没有新增付费订阅或部署席位。这描述的是本次新增资源的情况，不能据此得出从零开始也没有固定成本。

Vercel 的 On-Demand Budget 本身不会停止用量；只有启用相应暂停动作，达到阈值后才会暂停团队所有项目的生产部署。

备份里的封面是 URL，不包含 Blob 图片本体，因此数据库备份不能替代图片备份。恢复脚本拒绝向非空目标数据库覆盖写入；这些工具的存在，也不等于已经运行了定时备份服务。

TaleFrame 所在的团队还承载其他项目，这次没有为了一个新 App 修改全团队暂停策略。若要启用，必须先确认其他项目可以接受同时停服。

当前目录包含所有已发布小说及其章节引用，不是仅含书名的轻量首页，也没有目录分页和增量补丁接口。这降低了首版实现复杂度，但书库继续扩大时，需要测量目录响应体与解析耗时，不能只关心正文占用。

它不代表真实用户规模下的稳定性：目前没有实体手机或不同国家、运营商网络验收，本次联网验证使用了现有代理环境，App 也尚未上架应用商店。

需要这些能力时，应重新设计身份与授权模型，不能把管理员密码机制直接扩展成面向所有读者的账号系统。

服务端已经通过 Vercel CLI 部署，TaleFrame 源码当时仍在本地，尚未公开，也没有接通 Git 自动部署。

真正的问题不在业务逻辑，而在 AppKit window level、透明 panel、系统材质和启动持久化策略叠加后的边界行为。

好看的关键不是“粒子越多越好”，而是让粒子的出生位置、生命周期、运动方向、密度分布、视觉层级服务同一个动势。

把“任何事件都立即全量刷新”改成“合并请求、分层计算、变化才发布”。

最终我放弃彩带后，保留了更稳定的 area/edge 混合

彩带一旦做不好，负收益很明显。所以最终删掉。

工具型产品里的 bloom，要像盐，不能像汤底。

粒子系统本质上是每帧根据时间计算位置，然后画出来。Canvas 更贴近这个模型。

这相当于一个 trailing-edge coalescer。它允许短时间内的事件合并，又保证「刷新期间发生的最后一次变化」不会消失。

当用户点开菜单栏时，先从已经落到本地 SQLite 的数据快速加载 surface snapshot，再在后台走 adapter 增量同步。

这一步很朴素，但它把“数据库读到一个结果”与“UI 需要看到一次新状态”明确区分开了。

检测到活跃 Agent：每 3 秒检查并按需同步 没有活跃 Agent：30 秒才做一次兜底刷新

如果你只是做一个普通工具窗口，不建议一上来就追系统小组件质感。

适合用的场景： 1. 用户完成一个阶段性目标。 2. 系统需要表达奖励。 3. 状态变化低频且重要。

值得上：数据源有 burst 写入，且多个 UI surface 订阅同一份状态。优先做刷新合并和 scope 拆分。

可以再等：只有一个页面、一次刷新只读极少量数据。先保持简单，不要过早拆 Task。

等收集到足够多真实设备反馈后，再决定要不要把更像系统小组件的层级设为默认。

这次我没有编造一个漂亮数字，而是把验证拆成三个层次

工具型产品里的庆祝动画，不应该朝游戏化一路狂奔。

内部 runId 是事实主键，Provider Session ID 只是 ExternalRunRef。

重试只能作用于已声明幂等的边界。否则“失败后自动重试”可能变成重复扣款、重复发信或重复发布。

自有 Thin Harness + 一个 Agent Runtime / SDK + 持久化数据库 + 统一 Tool Gateway + OpenTelemetry / Provider Trace + 任务级 Eval Suite

如果当前目标是让 Agent 可靠执行，先做 React Flow 往往会把注意力带到节点拖拽、连线和表单配置上，最难的恢复与验收仍然没有答案。

“任务已完成”只是一条 Claim，不是事实。 真正的验证应该回到权威系统重新读取状态。

Evidence 是从 Trace、Artifact 和权威状态中挑出的、足以支撑 Claim 的最小集合。

验收器和工具授权由受控代码执行，模型自述“已经完成”只能是待核验证据。

评测中的越权用例必须阻断；有限测试零漏拦不等于实际环境绝对安全。

大多数生产系统应该先做到 L3，不必一开始追求 L4。

聊天记录可以参与恢复，但它不是完整 State；Trace 可以帮助调查，但它不自动构成 Evidence；Evidence 能证明一次交付，却不能替代跨版本的 Eval。

Agent Framework 负责模型循环和 Tool 选择，Temporal 负责 Durable Execution、Timer、Retry 与跨服务状态。

这次实现采用 fail-closed 策略。只有同时满足以下条件，兼容路径才会启用： 1. PE 中存在资源 section。 2. .rsrc 之后除了 .reloc，只多出一个 .bun。 3. 写入新资源后，整个 image 的虚拟大小不变。 4. 所有非资源 section 的名称、RVA、virtual size、raw size、attributes 和二进制内容不变。 5. 重新解析输出文件后，所有目标 VERSIONINFO 字段与预期值一致。

我的判断更严格：正式发布的浏览器快捷方式，默认应该只有可执行文件路径，不附加任何强制启动参数。 GPU、Remote Debugging、独立 Profile、日志和网络覆盖都有使用场景，但它们应该属于有生命周期、有隔离边界、可审计的诊断或自动化 Profile，而不是用户每天点击的入口。

如果决定接入，优先验收一条真实旧客户端链路：发现新版本、验证 CUP response、下载 CRX3、校验 payload、执行已签名 installer、重启后读到新版本，同时保留用户数据。只调通一份 JSON response，证明不了这条链路。

这里刻意没有把 PointerToRawData 设为不变量。.rsrc 增长时，后续 section 在磁盘文件中的位置可以移动；只要 PE Header 正确反映新位置，Loader 仍能读取它。兼容层需要锁住的是虚拟布局与 payload 内容。

不把 Remote Debugging 接到用户日常 Profile； - 每个并行 Run 使用唯一目录，不共享同一个 C:\Temp\profile； - Harness 优先使用 Pipe；必须用 Port 时，让 Runner 分配和回收，不固定写死 9222；

客户端收到 pipeline 后，才向 Download Server 或 CDN 发起 HTTP GET。下载成功只能证明一串 bytes 到了本地；Chromium Updater 还要校验大小与 hash，处理 CRX3，执行 installer，并根据 user/system scope 处理权限、进程和安装状态。

TLS HTTP 连接 传输加密和站点身份 不等于 payload 发布者签名 CUP Update Check 的 request/response 组合 响应完整性、新鲜度，以及对当次请求的绑定 不提供内容保密，不代替包签名 CRX3 publisher signature 更新 payload 包来自客户端信任的 publisher key 不代替 OS 对可执行文件的信任判断 Authenticode Windows 可执行文件 文件的签名者与签名后完整性 不代替 Omaha 渠道决策或 CUP

Chromium 的 Windows Sandbox 设计 使用 Restricted Token、Job Object、Desktop Object 和 Integrity Level 限制 Renderer 等不可信进程。它的目的不是消除漏洞，而是限制漏洞能触达的文件、Registry、进程和用户数据。 --no-sandbox 会直接拆掉这层边界。

证书则不要走捷径。--ignore-certificate-errors 会让测试越过你真正需要验证的 TLS 行为，既扩大攻击面，也可能把证书链、代理中间人和时间错误一起掩盖。更可靠的做法是在隔离测试机安装受控测试 CA，限定域名和环境，并让用例同时覆盖证书有效、过期、名称不匹配与撤销场景。

这次落地将 resedit 精确锁定在 3.1.0，作为 Build Kit 的 npm dependency。它参与构建，但不会被复制到 Runway payload，也不会作为一个孤立的 .exe 混入 Browser App。

品牌、更新通道、内置 Extension、Native Host、默认 Policy 和 Runtime 发现应由安装包与产品配置负责。不要用快捷方式参数替代正式配置面。

我的建议是，先画清这些责任边界，再决定服务端是自行实现、使用现成实现，还是采用另一套 updater。先选中一个开源项目，再反推产品 identity 和 key 如何放置，很容易留下无法平滑迁移的历史负担。

只要 PE 带有未知自定义 section、已经签名、资源增长可能改变虚拟布局，或者发行链没有原生 Windows 验收，就不应该把“生成成功”当成可发布。先建立结构快照、负向测试和重签名路径，再决定是否修改。

一个参数只有同时回答了“明确故障、最小作用域、回退条件、跨版本验收”四件事，才有资格进入受管配置。其余参数都应该留在实验记录里。

你只有一个用户规模很小的内部工具，手动下载新版本的成本可接受；或者你还没有稳定的 code signing、artifact storage 和 release process。这时先把“可重复构建 + 正确签名 + 不可变上传”做稳，比匆忙增加 Omaha Server 更有价值。

真实 artifact 验证完成后，仍不能把 macOS 上的结构检查描述成 Windows 原生验收。正式发布还需要在 Windows 上启动 executable、回读 File Properties 或 PowerShell VersionInfo，并在 metadata 修改之后完成 Authenticode 签名。

每次 Chromium baseline 升级后重新跑 GPU、Sandbox、Profile、Automation 与 Memory Regression。

基于 Lerna 的多包管理架构的优点在于： - 组件级别解耦，独立版本控制，每个组件都有版本记录可追溯 - 组件单独发布，支持灰度、版本回滚以及平滑升降级 - 按需引用，用户安装具体某个组件包，无需配置即可实现按需加载的效果。

使用 yarn workspaces 结合 Lerna useWorkspaces 可以实现 Lerna Hoisting。这并不是多此一举，这可以让你在统一的地方（根目录）管理依赖，这即节省时间又节省空间。

对与每个子包我们期望使用一样的配置，所以我们会先在整个项目的根目录新建 tsconfig. base.json，在子包继承即可。

几乎所有的组件库都会将色彩、布局这些以 css 变量的形式提供给使用者和开发者为，React Native 不同的是样式基于 CSS in JS，不过道理相通，参照 vant 的设计资源，我们抽出了一套 JavaScript 常量

主题功能是通用的，因此我将主题相关的能力都放在 @vant-react-native/theme 包中发布。

我们的组件为了适应主题化需求，样式不能是写死在组件里的，而是要通过上下文获取样式常量。我们思路是首先使用 useTheme 从上下文中获取主题，然后由于样式定义较多，我们为每个组件编写一个 useStyle hook 放在单独的 style.ts 文件中

默认尊重系统字体缩放；只有品牌字标、极小的辅助标识等无法随字号变化的元素，才做组件级限制。布局错位应优先通过弹性布局、换行和最小高度修复。

如果不在真实的大字体环境复现，给某个组件加 allowFontScaling={false} 往往只是碰巧掩盖了布局问题。

它只适合明确以固定字号为产品要求的封闭场景，例如内部大屏、受控硬件终端。普通 App 应把它视为最后手段，并在设计评审中确认无障碍取舍。

做这个 app 的动机很私人。今年我开始从前端往 Agent / AI Infra 方向转，每天大部分时间都在跟 Claude Code 和 Codex 泡在一起。泡着泡着就产生了一个很朴素的疑问：我每天到底烧了多少 token？钱花哪儿了？哪个项目最费钱？ 现有的工具都不直接回答这个问题，那我就自己做一个。

我为看清 Claude Code 与 Codex 的使用成本，开发了 macOS 工具 Owlet。它围绕菜单栏、浮动会话面板和历史用量视图组织信息；我负责产品方向、关键取舍和验收，AI 协助实现。

2026-07-10 的公开文章回顾个人工具的开发动机与分工；确切立项日期未知。这里保留当时的项目自述，不据此推定当前版本、用户规模或上线状态。

Claude Code 是我的主架构师。 它的长上下文能力太适合这种代码量不大但跨模块关联多的项目。

这件事让我明确了一条分工：需要理解系统边界和做取舍的，找 Claude Code；需要快速验证一个想法的，找 Codex。

在 Owlet 的开发中，我把系统边界和架构取舍、小范围实现与快速试验分开处理，并由自己决定方向、优先级和验收标准。这个分工是当时项目中的选择，不表示不同工具永远只能承担固定角色。

Surface 作用 难点 --------- Menu bar 常驻图标 + token 总数 图标动画不能太耗电 Floating island 刘海区实时会话面板 NSPanel 圆角、多屏、透明度 Dashboard 历史用量、排名、设置 SwiftUI 图表和数据库查询 Dynamic card 桌面小组件式面板 像系统 widget，但不能真用 WidgetKit

同样是 Apple Silicon、同样是 macOS 15，有的机器能打开，有的机器直接崩。最后定位到问题不在业务逻辑，而在 AppKit window level、NSPanel、系统材质和透明圆角叠加后的边界行为。

1. 文件监听用 Dispatch Source，而不是轮询。 之前有些实现会 sleep-loop 检查 active session，我全部砍掉了。 2. JSONL 增量读取。 50 MB 的会话日志不应该造成 50 MB 内存峰值。ClaudeCodeAdapter 用 (mtime, fileSize, byteOffset) 做缓存，文件增长时只读新增 bytes。

这些规则都被写进了 CLAUDE.md 和 AGENTS.md，成为后续所有改动的底线。一个工具要是自己先变成电老虎，就没资格监控别人的 token 消耗。

在 Owlet 的本地数据刷新中，我选择合并短时间内的更新，按菜单栏与仪表盘的实际需要分层计算，并在值发生变化时才发布 UI 状态。刷新期间的最后一次变化必须保留；没有运行时测量，就不宣称 CPU 或耗时改善了某个百分比。

已记录选项：以 Agent 状态与用量监控为产品核心 后续结果：未记录

场景：公开复盘讨论本地日志、SQLite 与多个 SwiftUI 界面共享数据时的重复刷新问题；原文没有给出可复验的性能提升百分比。

状态：未核实 已记录结果：未记录（不能据此推断项目没有成果或尚未完成）

GN 是一门面向构建图生成的声明式 DSL。它在 generation 阶段执行 .gn、BUILD.gn、.gni 和 args.gn 中的代码，得到 target、config、toolchain 及依赖关系，再生成 Ninja 文件；真正的编译、链接、复制和代码生成由 Ninja 在 build 阶段执行。

一个 .cc 文件存在于 checkout，只说明实现代码可被选择；它进入某个 target、经过特定 toolchain 编译并最终链接进 binary，才构成可验证的构建事实。

这张图里最容易被忽略的是箭头：git add、git commit、git push 推进的是三个不同边界。少执行一步，代码所处的交付状态就不同；多汇报一步，则会把本地事实说成远端或发布事实。

“测试通过”如果没有说明测试读取了哪一层，就可能比证据本身更强。

如果 B 的公开 header 引用了 C 的公开类型，B 应考虑把 C 放入 public_deps。如果 C 只是 B 的 .cc 内部实现，普通 deps 更准确。把所有依赖都改成 public_deps 可以暂时修掉 include error，却扩大了 API 面和重编译范围，也掩盖了 header 分层问题。

阅读顺序建议固定为：target 类型 → sources → deps/public_deps → configs 传播 → 平台条件 → visibility → outputs。这样比从文件名猜模块边界可靠得多。

Chromium 的默认 target configs 通常由 build config 注入，因此修改时常见的是 configs += [...]，而不是直接 configs = [...]。直接覆盖可能无意删除默认 warning、optimization、sanitizer 或 platform config。

每个 BUILD.gn 的父 scope 主要来自 build config，而不是另一个 BUILD.gn；跨目录共享变量应该通过 .gni 或 target/config contract 表达。

它更准确地表示：该路径在 index 中已有一个候选版本，而磁盘上的 working tree 又相对这个候选版本发生了变化。两列 M 分别属于两个比较方向。

git commit 创建的是 index 的快照，并让当前 branch 指向这个新 commit。没有进入 index 的修改会继续留在 working tree。

它会把整个 working tree 中可见的修改都纳入 index，包括其他会话、编辑器或开发者留下的文件。仓库干净、任务单一时它很方便；存在并发工作时，应先用 git status --short 确认所有权，再按路径或 hunk 暂存

index 不能替代真正的执行隔离。测试和构建读取 working tree；两个会话同时编辑同一文件时，仍可能发生覆盖或证据污染。

在默认 toolchain 中，current_ 通常与 target_ 一致；但 host tool、代码生成器或交叉编译依赖可能使用 secondary toolchain。此时只判断 target_os 可能把 target 配进错误的执行环境。

GN 的完整 label 包含 toolchain，因此同一个 target 可以在不同 toolchain context 下分别存在。

它是一套额外 checkout，拥有独立的文件目录、HEAD 和 index，但共享同一个 Git object database、refs 与 remotes。

它不是“更高级的暂存区”。每个 linked worktree 仍然有自己的 working tree 和 index，仍然遵循 edit、stage、commit、push 的顺序。

如果堆栈里包含 webpack/lib/util/createHash、ERR_OSSL_EVP_UNSUPPORTED，且故障发生在 dev 或 build 初期，基本就是这个问题。常见组合是旧版 Webpack 4 与 Node.js 17+。

--openssl-legacy-provider 只能救急。长期方案是升级 Webpack/相关 loader，或把项目固定在兼容的 Node LTS；不要把这个环境变量当作永久配置。

如果错误发生在运行时的加密、签名或 TLS 逻辑中，而不是构建阶段，不能简单套用 legacy provider。应先确认算法、证书或上游 SDK 是否需要迁移，否则可能降低安全性。

选择旧 LTS 是为了给升级争取窗口，不是长期停留在已停止维护的运行时。

“小说文本存在哪”同样需要区分草稿与发布态：编辑器读写 chapters.body，读者接口读取 chapter_versions.body。正文没有拆成 Blob 文本文件，也没有在当前网络版 APK 中打包整个书库。

所以，“小说列表存在哪”的完整答案有两层：管理员维护的书目在 books，读者读取的列表由当前发布指针关联 releases 后生成。 公开列表不会直接暴露编辑中的书目草稿。

这里的 Postgres 由 Neon 提供。Vercel 是后台与接口的运行平台，也提供 Blob；数据库和文件存储各自承担持久化职责。围绕 Vercel 组织交付，不意味着所有东西都属于同一个计费产品。

当前系统有三类持久化位置：Neon 数据库、Blob 对象存储、Android 应用私有存储。每一类都承担明确职责。

这组数据支持的是一个有限判断：在当前书库规模下，正文并没有大到必须拆出另一套文本文件服务。 直接使用 Postgres，可以在一处处理草稿、正文版本、发布引用和回退，减少数据库与外部文件之间的一致性协调。

也可以将正文存成对象文件，数据库只保留索引。但这样需要额外处理上传成功而数据库更新失败、快照引用了不存在的对象、旧对象清理与回退发生冲突等情况。它可能适合更大的内容库，当前还没有足够收益抵消这些工作。

封面则值得先处理。图片上传后统一解码、限制尺寸并转换成 WebP，比让几 MB 的图片直接进入小说列表更符合移动端需要。

封面采用另一条路径：后台验证图片，限制上传大小，缩放到最多 768 像素宽并转成 WebP，再上传 Blob。App 按公开 URL 读取图片。图片无需参与正文的数据库事务，独立放在对象存储中更直接。

正文版本按“章节 ID 与内容哈希”去重。只修改一章时，其余章节可以复用已有正文版本；发布快照保存引用，无需每次复制整本正文。当前保留最近五次发布，回退通过切换已发布快照完成，也不会覆盖编辑中的草稿。

随后创建发布快照，把书目信息与章节引用保存到 releases，更新 books.published_release，并递增目录版本。相关更新在同一数据库事务中提交。

正文下载后会核对 SHA-256，通过后才进入缓存。缓存键包含正文版本，同一章节被修订后不会误读旧文件。

这也意味着发布不是实时推送。读者需要发生刷新请求，目录还可能处于共享缓存有效期内。当前没有消息推送或长连接通知。

本项目沿用了已有的 Vercel Pro 计划，数据库采用 Neon Free，没有新增付费订阅或部署席位。这描述的是本次新增资源的情况，不能据此得出从零开始也没有固定成本。

Vercel 的 On-Demand Budget 本身不会停止用量；只有启用相应暂停动作，达到阈值后才会暂停团队所有项目的生产部署。检查存在几分钟延迟，暂停后存储费用仍可能继续产生。

目前的成本控制还包括按章下载、目录条件请求、封面压缩和历史正文清理。最终费用仍受数据库计算、函数执行、请求量、存储与分发流量影响；现有免费额度或套餐不能解释成永久零成本。

核查时，集成返回的套餐为 Free（free_v3），作用范围是集成安装。但同一响应中的费用数据属于 2025 年 5 月，不能用它判断当前账期是否产生费用。

当前目录包含所有已发布小说及其章节引用，不是仅含书名的轻量首页，也没有目录分页和增量补丁接口。这降低了首版实现复杂度，但书库继续扩大时，需要测量目录响应体与解析耗时，不能只关心正文占用。

它不代表真实用户规模下的稳定性：目前没有实体手机或不同国家、运营商网络验收，本次联网验证使用了现有代理环境，App 也尚未上架应用商店。

重点关注的变化，是全量目录变大、数据库回源压力、真实地区网络可用性，以及付费内容或视频进入产品。这些变化会影响现有边界：目录可能需要拆分，正文分发可能需要调整，漫剧则需要重新测量视频存储与播放成本。

缓存通常能减少重复工作，但命中率与最终账单仍要在实际流量下观察。

一个完整的 AI 浏览器，至少同时包含浏览器内核、产品级原生集成、交互界面、Agent Runtime、浏览器工具协议、模型与外部连接，以及支撑多平台构建、签名、发布和更新的工程系统。

普通 Chromium 浏览器已经是 Browser、Renderer、GPU、Network Service、Extension 等多进程系统。AI 浏览器通常还会增加 Extension Service Worker、Native Host、本地模型 Runtime 或 Automation Controller。它们可能共享一次用户任务，但不共享同一种资源模型。

浏览器启动参数只能调整 Chromium 接受的那部分 Runtime 行为。

如果直接把原始 CDP 暴露给模型，模型会面对大量方法、参数、Target、Frame、Node 和 Session 状态。它不仅浪费 Token，也很难稳定地完成“点击登录按钮”这种在人类看来很简单的任务。

所以，LLM 没有“点击页面”。它生成了一个点击意图，Browser Tool Plane 才负责把意图变成确定性的浏览器操作。

CDP 的全称是 Chrome DevTools Protocol，它能创建 Tab、导航、执行 JavaScript、读取 DOM、截屏和监听浏览器事件。MCP 解决的是另一件事：如何把 navigate、snapshot、act 这类工具，以 Agent 能发现和调用的标准接口暴露出去。

简单说：CDP 更靠近浏览器，MCP 更靠近 Agent。

优先做 Extension 如果产品主要是： - 总结、翻译和问答； - 读取当前 Tab 内容； - 在 Extension 权限范围内填表和导航； - 快速验证产品价值； - 可以接受跟随 Chrome 的产品入口和更新机制。

一旦 fork Chromium，就要长期维护 Patch Stack、解决上游冲突、承担跨平台编译和安全更新压力。fork 不是“更高级”的默认答案，它只是用更高的维护成本换取更深的产品控制权。

Chromium 的 switches 不是面向终端用户承诺稳定的产品配置 API。每次升级 Chromium baseline，都应该重新核对当前源码和真实二进制行为；不能因为某个参数在旧版本“能跑”，就把它永久固化。

Installer 升级、修复安装和卸载重装不会把诊断参数重新写回快捷方式；

我把它叫作 Engineering Delivery Control Plane，因为它不在一次 Agent 请求的调用链上，却贯穿 Browser、Server、Extension、CLI 和所有平台产物。

一个 Binary 在本地编译成功，只能证明 Build；上传到对象存储但没有切换 Feed，通常只是 Staged；客户端能从正式 Feed 发现并安装，才进入 Update 链路。

BrowserOS 先冻结 Candidate SHA，再让公共资源和各平台 Lane 都绑定这个 SHA、Browser Version、Component Version 和资源摘要。

每次 Chromium baseline 升级后重新跑 GPU、Sandbox、Profile、Automation 与 Memory Regression。

Codex 的 item/agentMessage/delta 和 Qoder 的 stream_event 都在 Adapter 内转换成 message.delta。上层不需要知道事件来自哪个 SDK。

边车提供了第三条路：原生 Core 保留控制权，Node Agent Host 只承载 Node 生态中不可替代的部分。

Agent Ops App 应该拥有 Session、权限、Workflow 和审计，Provider 只拥有原生执行上下文；新增 Provider 时，理想状态是只增加 Adapter 和 Projection，而不是修改整条业务链路。

对本地 Agent 来说，我倾向于采用“可信 Core + 受控 Sidecar”：Core 决定谁能做什么，Sidecar 负责把某一种运行时的能力做到最好。边车可以执行任务，但不能决定规则。

这里我刻意把 ProviderId 定义成 string，而不是： ts type ProviderId = 'codex' 'qoder'; 封闭 union 在小型应用里类型体验很好，但对可扩展 Provider 系统意味着每接入一个 Provider 都要修改公共契约。

因此 Agent Ops Session 是权威记录，Provider Session 只是外部引用。 创建 Session 时还应该固定 Provider 版本、Workspace Revision、权限配置和资产投影版本。

错误做法是用文本解析或业务分支伪造能力。正确做法是让 probe() 返回 Capability

不支持 resume 就明确返回不支持，不要偷偷重放 Prompt 并告诉上层“恢复成功”。能力差异应该由数据表达，不能靠语义造假。

把 Node 放进独立进程，只解决了部分故障隔离：Sidecar 崩溃后可以单独拉起，内存泄漏不会直接污染原生 Core。但如果它继承了完整环境变量、用户目录和网络权限，它仍然能够读取不该读取的文件，或者绕过审批直接访问外部服务。

因此我会把原生 Core 设计为 Permission Broker： - Frontend 不能直接启动 Sidecar，只能提交声明式 Intent。 - Sidecar 只接收完成当前任务所需的最小输入，不接收完整配置和全部 Secret。

Tauri capability 主要约束 Webview → 原生 Core，不会自动沙箱已经启动的原生插件或 Node Sidecar。把平台 ACL 当成完整安全方案，是一个危险的边界误判。

最后一种尤其常见：付出了多进程复杂度，却没有获得真实边界。

如果应用只调用一个稳定 API，且没有切换执行引擎的计划，直接封装一个 Client 往往足够，不必为了模式而模式。 但满足下面任意三项时，我会尽早建立 Provider 边界

不值得用： - 只是几个纯函数或轻量业务逻辑。 - 无法定义稳定协议，双方需要共享大量可变内存状态。 - 团队没有能力维护打包、签名、IPC、可观测性和崩溃恢复。 - 拆出去以后仍给 Sidecar 全部文件、网络、凭据和数据库权限。

四个问题都能给出明确答案，Sidecar 才是架构；否则它只是多启动了一个进程。

如果新增 Hermes 还需要修改以上模块，说明 Provider 私有语义已经穿透 Adapter 边界。

即使 Codex、Qoder 都有自己的 Permission Mode，Agent Ops App 仍然必须持有上层权限策略。Provider 原生审批只能进一步收紧，不能放宽组织策略已经拒绝的动作。

所有高风险工具调用经过 Core 审批与审计，Sidecar 不能自己给自己授权。

版本不能只在日志里打印一次，而要进入 Session Pin 和 Compatibility Manifest

主应用需要回答：握手失败怎么办？任务执行中 Sidecar 崩溃是否重试？取消后怎样确保子进程和工具进程都被清理？升级时协议不兼容如何阻止启动？连续崩溃是否进入熔断？

TaleFrame 的服务端采用一个 Next.js 项目。管理员页面与 API 放在一起，共享输入校验、内容模型和发布逻辑。部署时也只有一个服务端项目需要处理。

这里的 Postgres 由 Neon 提供。Vercel 是后台与接口的运行平台，也提供 Blob；数据库和文件存储各自承担持久化职责。围绕 Vercel 组织交付，不意味着所有东西都属于同一个计费产品。

“接上 Vercel”描述的是服务端部署方式，不会把 Kotlin 与 Jetpack Compose 客户端变成跨端应用。

Neon 是独立的数据库服务。即使通过 Vercel 的集成入口创建或连接数据库，数据管理仍由 Neon 承担。

这组结果支持一个很具体的选择：在当前规模下，把正文继续放在 Postgres，能够省去数据库与对象存储之间的额外一致性维护。

这组数据支持的是一个有限判断：在当前书库规模下，正文并没有大到必须拆出另一套文本文件服务。

不过，上表的变化描述的是当前封面资源的体积：历史原图仍保留在 Blob 中供旧版本回退，并没有因为换上新图就自动消失，不能把下载量节省写成存储量已经减少。

封面采用另一条路径：后台验证图片，限制上传大小，缩放到最多 768 像素宽并转成 WebP，再上传 Blob。

正文版本按“章节 ID 与内容哈希”去重。只修改一章时，其余章节可以复用已有正文版本；发布快照保存引用，无需每次复制整本正文。

随后创建发布快照，把书目信息与章节引用保存到 releases，更新 books.published_release，并递增目录版本。相关更新在同一数据库事务中提交。

TaleFrame 采用目录版本检查与按章缓存。这里的“在线更新”指书目和正文更新，不包含 APK 升级、动态下发可执行代码或绕过应用商店更新。

当目录变了，App 校验数据结构、章节引用与地址格式，成功后原子替换本地目录。更新失败时保留之前可用的内容，而不是先清空书库。

正文下载后会核对 SHA-256，通过后才进入缓存。缓存键包含正文版本，同一章节被修订后不会误读旧文件。当前缓存上限为 100 MB，按最近读取情况淘汰旧内容；这个数值是本项目的选择，不是阅读 App 的通用标准。

Vercel 对 s-maxage 的处理属于 CDN 缓存语义；代码中写了缓存头，只能证明配置意图，实际是否命中仍要查看响应与运行数据。

下架也需要明确语义：服务端可以移除公开目录，并拒绝后续正文读取；已经到达 CDN 的响应可能在缓存期内继续可用，设备上已有的离线内容也无法靠下架动作远程抹除。

客户端缓存改善体验，并不创造无限期的历史访问承诺。

本项目沿用了已有的 Vercel Pro 计划，数据库采用 Neon Free，没有新增付费订阅或部署席位。这描述的是本次新增资源的情况，不能据此得出从零开始也没有固定成本。

Vercel 的 On-Demand Budget 本身不会停止用量；只有启用相应暂停动作，达到阈值后才会暂停团队所有项目的生产部署。检查存在几分钟延迟，暂停后存储费用仍可能继续产生。

核查时，集成返回的套餐为 Free（free_v3），作用范围是集成安装。但同一响应中的费用数据属于 2025 年 5 月，不能用它判断当前账期是否产生费用。

使用托管服务后，可以少维护服务器和运行环境，但内容正确性、安全边界和恢复方式仍然由应用负责。

当前目录包含所有已发布小说及其章节引用，不是仅含书名的轻量首页，也没有目录分页和增量补丁接口。这降低了首版实现复杂度，但书库继续扩大时，需要测量目录响应体与解析耗时，不能只关心正文占用。

但服务端只保留有限历史，旧阅读页若之后再下载已清理的正文，仍可能遇到版本不可用，需要刷新书库。

它不代表真实用户规模下的稳定性：目前没有实体手机或不同国家、运营商网络验收，本次联网验证使用了现有代理环境，App 也尚未上架应用商店。

需要这些能力时，应重新设计身份与授权模型，不能把管理员密码机制直接扩展成面向所有读者的账号系统。

这次检查的价值，是把“内置浏览器”拆成可回查的四层：随应用分发的 Chromium，承载网页的 ，管理生命周期的主进程，以及连接 Agent 的 CDP 通道。

一个完整的 AI 浏览器，至少同时包含浏览器内核、产品级原生集成、交互界面、Agent Runtime、浏览器工具协议、模型与外部连接，以及支撑多平台构建、签名、发布和更新的工程系统。

所以，“用了 Electron”只是第一层答案。网页如何保存、何时挂载、怎样转移、权限由谁处理，都属于应用额外实现的管理逻辑。

简单说：CDP 更靠近浏览器，MCP 更靠近 Agent。

本次代码给出的路径是：Browser Use 后端经过会话路由，找到页面的 WebContents，再使用 Electron 的 debugger 接口发送 CDP 命令。

如果直接把原始 CDP 暴露给模型，模型会面对大量方法、参数、Target、Frame、Node 和 Session 状态。它不仅浪费 Token，也很难稳定地完成“点击登录按钮”这种在人类看来很简单的任务。

所以，LLM 没有“点击页面”。它生成了一个点击意图，Browser Tool Plane 才负责把意图变成确定性的浏览器操作。

主进程还包含 Target.attachToTarget、Target.getTargets、子 Session、控制权释放和超时处理。因此，这不是只有一个“执行浏览器命令”的按钮；它需要维护任务与页面的归属，并处理控制过程的生命周期。

问题在于，不同进程可以映射同一份共享库、共享内存或 file-backed page。对单个进程看，这些页面确实属于它的 resident set；但如果把多个进程的 RSS 直接相加，同一批物理页就可能在多个进程名下重复出现。

RSS 不是“假数据”，Physical Footprint 也不是 RSS 的修正版。它们是从不同层面观察内存的两把尺子。

这里有一个很重要的责任边界：浏览器启动参数只能调整 Chromium 接受的那部分 Runtime 行为。

本地模型显存不足、Native Host 内存泄漏、Extension 事件丢失，不能靠给所有 Renderer 加大堆上限来统一“治疗”。跨进程系统如果只剩一把 flags 锤子，最后通常会同时损失安全性、可观测性和问题定位能力。

我的判断更严格：正式发布的浏览器快捷方式，默认应该只有可执行文件路径，不附加任何强制启动参数。

参数的专业管理标准不在于“记住更多 flags”，而在于回答四个问题：谁添加、作用于哪些进程、何时移除、用什么证据证明它解决了问题。

Chromium 的 switches 不是面向终端用户承诺稳定的产品配置 API。每次升级 Chromium baseline，都应该重新核对当前源码和真实二进制行为；不能因为某个参数在旧版本“能跑”，就把它永久固化。

我的核心原则只有一句：先问指标在回答什么问题，再看数字大小。

那么 Extension + Local Server 通常是成本更低的选择。先验证用户是否真的需要 Agent 完成这些任务，再决定是否接管浏览器底座。

代价也很明显：一旦 fork Chromium，就要长期维护 Patch Stack、解决上游冲突、承担跨平台编译和安全更新压力。fork 不是“更高级”的默认答案，它只是用更高的维护成本换取更深的产品控制权。

因为模型会换、UI 会改、MCP Client 会增加，但 Page、Tab、Frame、Navigation、Snapshot、Input 和 Side Effect 的语义需要长期稳定。

如果只想验证一个页面助手，Extension 已经足够；如果要做浏览器级产品，就要接受 Chromium fork 带来的长期成本；如果目标是让不同 Agent 稳定使用真实浏览环境，那么最值得先建设的，是独立于模型和 UI 的 Browser Runtime。

但铭牌和接口没有交出完整施工图。具体修改了哪些 Chromium/Electron 源码、对应哪个上游 Electron 版本、迁移时有哪些限制，仍不能从这次检查中确定。

本次没有运行真实任务，因而不进一步宣称所有操作都成功、前后台表现一致，或全部浏览器工具都采用这条后端。

这里存在一个重要边界：BrowserOS 源码能证明这些组件和调用关系存在，但不能仅凭静态源码证明每个网站、每个模型、每个任务都能可靠完成。任务成功率仍然需要基于真实任务集、Provider 和环境做运行时评测。

随后接手的是主进程中的浏览器管理逻辑。名为 browser-sidebar-manager 的日志标识周围，可以找到标签页状态、页面挂载与转移、恢复、后台页面预算、下载和权限提示等代码。will-attach-webview 与 did-attach-webview 事件把界面的嵌入动作连接到主进程。

网页由 Electron 的 guest WebContents 承载，应用再把它与当前任务的展示位置关联起来。

export const ipcClient = createClient({ ipcInvoke: window.electron.ipcRenderer.invoke, });

export const ipcRoutes = t.router({ ...agentRoute, ...llmRoute, // 这里定义了 actionRoute ...actionRoute, ...browserRoute, ...fileSystemRoute, ...searchRoute,

{ sandbox: true, nodeIntegration: false, contextIsolation: true, webSecurity: true }

Preload 是应用与页面能力之间的桥接位置，可以接入批注等受控功能；它不意味着普通网页直接获得 Node.js 权限。这些配置是已见的隔离措施，不能替代完整安全审计。

- 部分 Node.js能力：默认不启用 Node.js 集成，但可通过 preload 脚本和 contentBridge 暴露有限 API（如 fs 模块的部分功能）。 - 沙箱环境：出于安全考虑，渲染进程默认隔离，无法直接访问系统资源或执行危险操作。

- 在渲染进程加载前注入，通过 contextBridge.exposeInMainWorld() 安全暴露主进程 API（如 sendMessageToMain）

while(!this.abortController.signal.aborted && !this.hasFinished) { // 当任务没有被取消或完成时执行 Agent 循环 const awareResult = await aware.run();

const toolCallList = (await executor.run(awareResult.status)).filter( Boolean, ); const mcpTools = await ipcClient.listMcpTools(); const customServerTools = await ipcClient.listCustomTools();

const awareResult = JSON.parse( result.tool_calls.filter(Boolean)[0].function.arguments, ) as AwareResult;

You are a tool use expert. You should call the appropriate tools according to the aware status and environment information.You should not output any response text and only return the JSON.

但铭牌和接口没有交出完整施工图。具体修改了哪些 Chromium/Electron 源码、对应哪个上游 Electron 版本、迁移时有哪些限制，仍不能从这次检查中确定。

这些证据支持“运行时带有定制扩展，并暴露了页面接管与转移接口”的判断。

EventManager 类主要是负责和 chat-ui 交互的，由于 chat-ui 没有开源，这块是黑盒的。后续开源之后详细讲解。

@vender/chat-ui 由于内部原因，暂未公开，可以关注 issues417。

很多生图流程第一步就是选模型。我现在反过来：先问最终文件要被谁消费。

目前 better-imagegen 把常见任务拆成独立工作流： 类型 默认交付重点 ------ Portrait / Cover 构图、人物、情绪、WebP 压缩 Text Poster 生图负责视觉底板，HTML/CSS 负责准确文字 Logo / Icon 透明背景、alpha 边缘、缩小后的可读性 macOS App Icon squircle、安全区、iconset、.icns Static Wallpaper 4K、PNG、桌面图标可读区域 Dynamic Wallpaper 多状态帧、HEIC、系统元数据 Sprite Loop 精灵图、编号帧、GIF 预览、manifest Image Edit 参考图输入、身份保持、局部变化

我持续完善 better-imagegen，把视觉资产的类型选择、规格约束、后处理、失败处理和验收写成可复用流程。它服务封面、角色、图标和帧动画等不同交付，不把一张模型生成的图片视为全部工程产物。

一个可执行的 Prompt，不是堆“高级感、电影感、8K、杰作”这类形容词，而是写清一份资产合同。

1. Subject：画面里必须有什么 2. Composition：主体位置、留白、视线方向、帧网格 3. Style：摄影、插画、像素、产品渲染等视觉语言 4. Delivery context：博客、社交媒体、菜单栏、桌面、App Icon、头像 5. Hard constraints：人数、透明背景、尺寸、帧数、角色身份 6. Negative constraints：不要文字、不要 Logo、不要水印、不要额外肢体

真正决定可用性的约束是：横向精灵图、固定 6 帧、每格等宽、透明背景、暖橙色轮廓、18px 仍能辨识、首尾动作连续。

模型生成的是像素，但 Prompt 描述的是运行时约束。

AI 生成无文字视觉底板 ↓ HTML / CSS 叠加真实文本和品牌组件 ↓ 浏览器渲染并截图 ↓ WebP 压缩 + 尺寸检查

用户必须认出“还是同一个角色”时，使用 image edit。 - 只需要同类风格、不要求身份连续时，才用 text-to-image。 - 角色进入帧动画时，先锁定标准立绘，再做动作变化。

1. 每个 cell 尺寸完全一致，不能靠肉眼切。 2. 首帧和末帧的姿态能自然衔接。 3. alpha 通道真实存在，不能用棋盘格“画透明”。 4. 必须在实际运行尺寸验收，而不是只看 512px 预览。

生成透明源图 → 检查 alpha 边缘 → 裁掉异常透明留白 → 设置视觉安全区 → 生成 macOS squircle 底板 → 输出 16 / 32 / 128 / 256 / 512 / 1024 尺寸 → 组成 .iconset → 转换为 .icns

better-imagegen 现在默认使用 GPT Image 2，失败后归一化 Prompt 重试一次，再回退到 Gemini，最后才考虑 Doubao。

因此透明 Logo、Icon 和 sprite sheet 不应该回退到一个会破坏 alpha 或网格的模型。Fallback 的目标不是“总能出图”，而是“仍然能交付同一种资产”。

所以我给每个产物增加了同名 JSON 元数据： json { "file": "cover.webp", "model": "gpt-image-2-all", "requested_size": "1536x1024", "actual_resolution": "1280x720", "generation_time_seconds": 38.8, "output_format": "webp", "postprocess": "center-cropped to 16:9; WebP quality 78", "prompt": "..." }

元数据看起来是小事，但它让视觉生成从“聊天记录里的偶然结果”变成了可审计的工程产物。

但它不是 Figma 的替代品，也不会自动解决所有品牌一致性问题。涉及精确排版、复杂 Design System、连续镜头或严格 3D 资产时，仍然需要专业工具和人工判断。

我的结论是：如果你每周都有两次以上视觉生成需求，值得把生图从 Prompt 升级成 skill。 判断是否值得工程化，我看 3 个问题： 问题 是 否 --------- 同类资产会重复出现吗？ 建立类型 reference 临时生成即可 输出要进入代码、客户端或内容系统吗？ 增加后处理和验收 保存图片即可 失败会影响交付节奏吗？ 增加模型回退和元数据 手动重试即可

场景：2026-07-15 的公开文章回顾近期实践；项目起始日期未详。这里保留维护方向，不推定当前支持模型或发布状态。

状态：未核实 已记录结果：未记录（不能据此推断项目没有成果或尚未完成）

Next.js 支持 output: 'export'，构建后输出纯静态文件

TaleFrame 的服务端采用一个 Next.js 项目。管理员页面与 API 放在一起，共享输入校验、内容模型和发布逻辑。

我的站点用 Next.js output: 'export' 静态导出，全站 HTML/CSS/JS 推 CDN，没有运行中的 Node.js 服务。

也就是说，GET / 返回文档站首页，GET /api/skills 走 Midway 控制器——静态文件和 API 共用同一个端口，完全无感。

本地开发时，Next.js 需要一个 dev server 做热更新，不能用静态文件。用 concurrently 解决

fumadocs-mdx ^15.0.0 注意不是 ^12，v15 才支持 core v16

fumadocs-openapi ^10.0.0 要求 core ^16.9、ui ^16.9

这组结果支持一个很具体的选择：在当前规模下，把正文继续放在 Postgres，能够省去数据库与对象存储之间的额外一致性维护。

历史原图仍保留在 Blob 中供旧版本回退，并没有因为换上新图就自动消失，不能把下载量节省写成存储量已经减少。

正文版本按“章节 ID 与内容哈希”去重。只修改一章时，其余章节可以复用已有正文版本；发布快照保存引用，无需每次复制整本正文。

缓存键包含正文版本，同一章节被修订后不会误读旧文件。当前缓存上限为 100 MB，按最近读取情况淘汰旧内容；这个数值是本项目的选择，不是阅读 App 的通用标准。

ChapterRead50 / ChapterCompleted / TimeOnPage30 是自定义事件，必须先包装。

document.body.scrollHeight 包含正文下方的"YOU MIGHT ALSO LIKE"推荐区。这块区域通常占页面高度的 15-25%。

CAPI 需要从服务端调用 Meta Graph API 回传事件，这意味着

核心判断：先把事件质量做好（正确触发、正确包装自定义转化），再考虑量的问题（CAPI）。顺序搞反了没意义。

Egg.js 内置 egg-static 插件，开启后可以托管静态目录

App 下次检查目录时获得新快照，阅读对应章节时请求新正文。

方案 A：改用 Vercel 部署（支持 Next.js Route Handler），在 app/api/fb-event/route.ts 里回传

先把小说的更新与阅读做好，等实际需要承载视频时，再为视频选择服务。

对 Next.js 包体积有严格限制（文档站打出来还是有一定体积的）

它可能适合更大的内容库，当前还没有足够收益抵消这些工作。

CAPI 和 Browser Pixel 同时上报同一事件时，需要用 event_id 去重

moment().tz is not a function 通常不是时区格式问题，而是 moment-timezone 没有被正确加载。本文给出可复现的导入方式、排查步骤和替代方案。

一句话总结 tz() 来自 moment-timezone，不是 moment 本体 API。直接从 moment-timezone 导入，最能避免 bundler、默认导入和重复依赖导致的实例不一致。

它依赖 moment-timezone 修改同一份 moment 实例。在 monorepo、alias 配置或 lockfile 出现多个 moment 副本时，副作用可能修改的是 A 实例，而业务代码拿到的是 B 实例，于是仍然报 tz is not a function。

1. 运行 pnpm why moment 或对应包管理器命令，确认没有意外安装多份 moment。 2. 检查 moment-timezone 是否在生产依赖中，而不是只在 devDependencies。 3. 检查 bundler alias 是否把 moment 指到不同路径。 4. 确认时区名是 IANA 格式，例如 Asia/Shanghai，而不是 GMT+8 这类展示字符串。

Moment 已进入维护模式。新项目如果只需时区转换，可以评估 date-fns-tz、Luxon 或原生 Intl.DateTimeFormat；但在已有 Moment 代码库里，局部替换的成本未必值得。先把导入链路修正确，再决定是否迁移。

我的判断框架 遗留项目：继续使用 moment-timezone 并统一入口导入，风险最低。 新项目：优先选择现代日期库或 Intl，避免新增 Moment 依赖。

This is a special type of scope which applies to variables that are declared using the let or the const keyword only. According to the rules of block scope, variables that are declared inside of a block or a pair of braces can only be accessed inside of that block and nowhere outside of it.

This is called the scope chain, it does this all the way up to the global scope. And if the variable is still not resolved, then we get the error that the variable is not defined.

So a closure is not just a function, it's a function combined with its outer state or lexical environment. As you might imagine, closures require more memory and processing power than a pure function.

the most important one being data encapsulation to prevent leaking or exposing data where it's not needed. We can create a closure by defining an outer function that contains the state, then an inner function that operates on it.

This is because the declaration gets hoisted above the console.log, but the initialization stays below that line. So it doesn't know anything about the value 27 at the time of execution.

Variables declared with the keyword let are not hoisted. Let's have a look at the same example we just looked at. But we'll replace the keyword var for let. As you can see, we get an error saying that x cannot be accessed before initialization.

Now, if we write a second property and use an arrow function, you'll notice this is now the global object or undefined in strict mode in an arrow function. This is based on the enclosing object's execution context, which in this example, would be global.

And lastly, I'll point out that you also have the apply method, which is identical to call. The only difference is that the second argument is an array of arguments. A good way to remember the difference is to think a for array or apply, or c for comma or call.

以下以浏览器为范围；Node.js 的事件循环阶段和 nextTick 队列不直接套用此顺序。

- ​新微任务继续排队：微任务执行过程中产生的新微任务会加入队尾，在本次微任务检查点继续处理，直到队列清空；不会打断当前正在执行的回调。

输出顺序：1 → 4 → 3 → 2 解释： 1. 同步任务输出 1 和 4。 2. 当前宏任务（主线程）结束后，执行微任务队列中的 Promise.then，输出 3。 3. 最后执行宏任务队列中的 setTimeout，输出 2。

2、​微任务阻塞渲染 长时间运行的微任务会延迟 UI 渲染，因为微任务队列必须在渲染前清空。

In Javascript, every object has a hidden link called or its prototype. If a property or method isn't found on the object, Javascript looks up these prototype. This lookup process continues up the prototype chain. It starts with your object, moves to its prototype and keeps going until it either finds the property or hits null.

Here, customObj inherits name from obj and toString from Object.prototype. That's the power of the prototype chain.

// Inherited from obj console.log(custom.name); // Found in Object.prototype console.info(custom.toString()); // custom's prototype is obj console.info(custom.__proto__) // custom's prototype is Object console.info(obj.__proto__) // Object's __proto__ is null

gnu 通常表示 GNU toolchain / glibc environment，musl 表示 musl libc environment。CPU 和 kernel 都对，libc 不匹配，程序仍可能在启动时报告 dynamic linker 不存在、symbol version 找不到，或者某个 native dependency 无法加载。

这也是 Linux 安装包经常比 macOS 多出一截后缀的原因：发布者需要把更多用户态兼容边界写进名字。

笔者使用的是 AliYun 服务器 ECS，镜像选择的是 Ubuntu，Ubuntu的详细版本信息是：Ubuntu 18.04.4 LTS (GNU/Linux 4.15.0-91-generic x86_64)

更新系统源 $ apt update 升级系统源 $ apt upgrade

第三，把检测对象说清楚。 你检测的是 physical machine、operating system，还是当前 process？在 Rosetta、WOW64、container 和 cross-compilation 环境里，这三个答案完全可能不同。

ldd --version 的输出通常能帮助判断当前环境属于 glibc 还是 musl，但不同 distribution 的实现与输出不完全一致。发布者若提供了专门的 gnu / musl artifact，应继续对照其支持矩阵，而不是只看 uname -m。

- uname -a：显示全部Linux系统信息 - cat /proc/version：显示Linux信息 - cat /etc/lsb-release：查看发行版信息 - echo $SHELL：当前的shell

Linux或Mac系统使用LF作为行结束符，因此你不想 Git 在签出文件时进行自动的转换；当一个以 CRLF 为行结束符的文件不小心被引入时你肯定想进行修正，把 core.autocrlf 设置成 input 来告诉 Git 在提交时把 CRLF 转换成 LF，签出时不转换

我们使用 n 模块来维护 Node 的版本： shell $ apt install nodejs npm build-essential $ sudo npm install -g npm n 安装最新版 $ sudo n latest

修改 ~/.zshrc 之后都需要执行 source ~/.zshrc 命令使之立即生效 echo $SHELL 可以查看当前 Shell

- 修改默认Shell：chsh -s /bin/zsh

- -ef：列出所有用户在所有终端的所有进程，可以配合管道方便查看 ps -ef less - -efH：按照乔木状列出进程 - -u：列出此用户运行的进程 - -aux：通过CPU和内存使用来过滤进程

& 符号：后台运行进程 - cp file.txt file-copy.txt & - find / -name "log" output_find 2&1 & nohup: 使进程与终端分离

m h dom mon dow command - 顺序口诀：分 时 日 月 周 - m：minute 的缩写，表示”分钟“（0~59）

实例 一定要换行，不换行不会生效的 重启 cron 服务：systemctl cron.service restart

- Linux 多看一层 libc 与最低版本。 CPU 匹配后，再核对 gnu/musl、distribution baseline 和 package format。

名称片段 描述对象 不能单独证明什么 --- --- --- linux-arm64 OS + CPU 不保证 libc 与最低系统版本兼容 gnu / musl libc / ABI environment 不表示 package manager

更新系统源 $ apt update 升级系统源 $ apt upgrade 必备环境及应用 Git shell 安装 git $ apt install git

Flutter 和 React Native 所适用的业务场景是不一样的，Flutter 更多地可以替代原生开发作为 App 开发的新模式，闲鱼目前的基础链路就在用 Flutter 做归一的架构。而 React Native 可以做动态化的事情，比如手淘的活动引导页这类需要高度动态化的场景。

技术存在即合理，站在宗心大佬的高度，一切技术的选型和架构一定是跟随业务场景走的。脱离业务去谈技术和架构，就是流氓行为，不负责任的，纯属制造焦虑的。

那么闲鱼是否会放弃 Flutter 呢？答案是否定的，宗心大佬描述了闲鱼基础链路架构的方向：Flutter 作为基础链路的核心，辅以原生、H5 等容器，最终做到基础链路的归一。

目前跨端处于比较混乱的局面，RN 容器、H5 容器、原生壳、各厂封闭生态的小程序以及 Flutter 共存于一个 App 的情况屡见不鲜。这带来的不只是管理成本，还有性能问题。此时急需一个能够统一基础链路的技术，闲鱼基于多年的经验选择了 Flutter。

其实，在涂鸦也有相应的小组在做同样的事情，在我们的沟通里叫一码多端。也是基于 Flutter 实现一套代码多端运行。

大佬将专家分为技术向专家和业务向专家。技术向专家比较少见，需要对某一个领域或某一个问题有很专精的研究，比如 Flutter 渲染引擎的优化、音视频方向的编码研究等等。而更常见的是业务向专家，这里的业务并不是具体的 ERP 或者电商。而是要有产品意识，需要在缺少产品的紧急情况下能顶上去的能力。

宗心大佬最后还是劝诫我不要只在意技术方面的进步，能走的更远需要的不只是你的技术能力，更多的是综合能力，甚至是平衡生活和家庭的能力。

我们要做的是学习大佬的习惯、学习方法、对于技术框架的架构以及技术的前瞻性。

本人找工作的base是郑州，一个互联网三线城市。刚开始主动打招呼的和海投回应的都很多，9成都是 Vue 开发，甚至需要维护 jquery 项目。我心想还是主动投投 React Native 岗位吧，现实再次打了我的脸，郑州这边 RN 岗位两个手数的过来，并且范围都是 8-10K，甚至 4-8K。

新公司入职有两个月了，独立负责了两个不大的中台项目，技术栈是基于 umijs 的，而 umijs 基于 dva、antd、react-router，而 dva 又基于 redux。两个项目下来，我的水平停留在了熟练基于 umijs 开发业务。

嗯，技术专家是紫升目前努力的方向，也制定了一系列的目标和计划。但是我并不知道这些目标和计划是否正确！

我从 18 年开始做 React Native 开发，积淀了很多业务开发知识和架构工程化方面的能力。一直在我心里过不去的坎是原生开发能力的欠缺。

紫升你思考一下你作为一个前端真的需要精通后端吗？你需要的不是精通那么多后端细枝末节，而是培养自己解决问题的通用能力。

我建议你去学一下 iOS 和 安卓开发，起 Demo 玩一玩知道怎么运行的，如何开发的。

但是宗心大佬还是告诫我一定要知道自己安身立命的东西是什么，不要忘记初心。不管是就业形势还是职业发展我更希望你能做一个懂客户端的大前端，而不是放弃前端往客户端突破。

虽然还是很不舍，但我不得不逼自己暂时放弃 Deno、Rust 的学习。之所以要坚持 Go 的学习是因为我需要一个编译语言来解 JS 的毒，而 Go 足够简单不会对我造成太大的负担。

其实，在涂鸦也有相应的小组在做同样的事情，在我们的沟通里叫一码多端。也是基于 Flutter 实现一套代码多端运行。这在跨端领域可以说是炙手可热的话题了。

嗯，技术专家是紫升目前努力的方向，也制定了一系列的目标和计划。但是我并不知道这些目标和计划是否正确！

一句话总结 Skill 应该按“谁拥有决策和证据”拆分，而不是按“这些命令能不能连着执行”拆分。平台开发与发行版开发之间，最重要的产物是已发布、精确版本锁定的 package，而不是共享一个工作目录。

平台 Skill 放在平台仓库的 .codex/skills/，含义是：它服务这个仓库的维护者，不应被产品安装、CI 或运行时依赖。发行版 Skill 则面向拥有产品配置和交付责任的工程。两者可以引用同一套平台契约，但不能共享“直接读取平台源码”这条捷径。

这一层的核心约束是：AI 可以读取，但不能把自己的总结反向覆盖原始事实。任何 Wiki 页面和 Agent 答案都应该能够回到具体 Source、版本和位置。

对 Agent Skill 来说，合理的边界也因此更清楚：稳定方法写进 Skill，稳定规则留在 Reference，变化中的事实进入知识库，执行中得到的经验经过审核后再反哺事实源。

如果工作只发生在一个产品仓库，且没有跨仓发布或受控凭据边界，暂时不必为了形式拆 Skill。真正需要关注的是：Agent 是否会因为错误的上下文和依赖方向，做出无法被交付证据支撑的结论。

四个答案相同，通常可以留在一个 Skill 里。只要其中一个答案分叉，特别是出现“平台已发布 package”与“产品已签名 artifact”两种证据时，就应该拆开。

如果继续扩充静态 Reference，Skill 会逐渐变成一个难以维护的资料压缩包。知识更新需要修改 Skill，Skill 发布又和知识变更绑定；资料越多，Agent 每次加载的 Context 越大，真正需要的内容反而更难命中。

可以再等：资料规模小、规则稳定、任务复用率低，几份静态 Reference 已经能够清楚覆盖。

第一，发行版只消费 registry 中已发布的精确 package。禁止 file:、link:、workspace:、本地 tarball、sibling lookup 或跨仓 symlink。这样能强迫每次采用都经过版本、锁文件和干净安装。

第三，交付状态必须拆开记录。测试通过、package 已发布、产品已构建、签名完成、CDN 可读、更新通道已激活、旧客户端成功升级，分别是不同事实。

Wiki 是可重建的知识产物。删除 Wiki 后，系统应该能够从 Raw Sources 重新编译；删除 Raw Sources 后，只剩 Wiki 就失去了可信根基。

知识编译不能绕过原始权限。Source、Wiki 页面和查询结果都要继承 Scope 与 Permission，过滤应该发生在召回和生成之前。

一次 Ingest 不应该只生成摘要。完整流程至少包括： text 读取新 Source → 提取事实、实体、关系与适用范围 → 查找已有相关页面 → 新增或更新 Wiki 页面 → 标记冲突与待确认项 → 更新 index.md 与 log.md → 保留 Source Citation 增量更新比全量重建更重要。

Query 的默认路径是先读取 Wiki，快速定位主题、实体和已有综合结论。遇到下面几类内容时，再回到 Raw Sources 核验： - 字段口径、时间范围、过滤条件等精确事实； - 可能已被新版本替代的结论； - 会影响代码生成或生产任务的关键规则； - Wiki 中明确标记为冲突或低置信度的内容。

结构检查可以自动执行；涉及业务语义的冲突，应该进入人工审核，而不是让模型自行决定哪一方是真相。

这里最重要的变化，是 Skill 从“知识容器”变成“知识消费者和执行编排器”。领域知识可以独立演进，Skill 只需要保持操作协议稳定。

这是一种有明确损失的信息投影：布局装饰通常被省略，纯颜色含义可能缺失，未挂载的数据不会自动出现。

Agent 可以从可靠语义知道目标及状态，但无法凭一条 role 或 aria-expanded 保证页面实现与声明一致。

网页上的某次点击成功，只能证明一个动作完成了，距离回答用户的问题还差一次结果核对。

重新观察的目的包括获取可用引用，也包括更新决策证据。即使 @e1 仍然有效，页面条件也可能已经不允许继续执行原计划。

生成引用时，后台保留引用与节点、frame 和文档的关联；后续文本中出现的 @e1 因而能回到浏览器中的具体目标。

页面或 iframe 导航、元素替换会影响引用有效性。没有对应 DOM 节点的虚拟无障碍节点，其引用只适用于当前快照。

稳定的节点引用也不能独立证明业务对象没变。列表可能复用同一个 DOM 容器展示另一条记录；“购买”按钮可能仍然存在，但页面当前商品已经不同。

引用省去了为每一步重新编写 selector 的工作，但它不是商品 ID、订单号，也不是跨页面永久有效的地址。

snapshot -i 偏向可引用的操作目标，“有货”这样的普通结果文字可能被排除；某些标题和表格单元格能够留下，也不保证所需字段完整。找动作目标时可以压缩观察，检查业务结果时则需要保留相关正文、状态或表格内容，不能把“交互快照里没出现”理解为“页面没有”。

虚拟列表还需要额外关注观察范围。总行数、行索引不能代表未挂载行的内容；滚动、翻页或筛选后仍要重新观察。

snapshot -i 偏向可引用的操作目标，适合先找输入框、链接和按钮；具体保留范围见后文的裁剪说明。

本站只用 Accessibility Tree，浏览器 Agent 能走多远？核验的是 @mastra/agent-browser 0.4.1 与 agent-browser 0.19.0 的组合，那条路径通过 Playwright ariaSnapshot() 生成工具快照。本文核验的上游 0.41.1 Chrome 原生路径直接读取 CDP AX Tree。

工具名和命令相似，不能代替对依赖版本及真实调用链的检查。

原生 AX-only 观察 CDP 返回的角色、名称、值、状态、父子关系 从语义引用重新定位、检查可操作性并执行 Demo 采用

Chromium 的原生 Accessibility 系统支持辅助技术发起默认动作、聚焦、改变值与滚动。CDP 的 Accessibility 域则主要提供查询和事件，并没有通用的 click、fill 接口。

面对第三方站点，应先检查真实任务中的关键控件，再决定是否坚持这条路线。缺少必要语义时，可以明确转入混合观察，也可以保持 AX-only 并报告受阻；两者都需要如实记录实验条件。

出现多个同名按钮 补充行、区域或业务字段以消歧；无法确认时停止操作

评估接入价值时，我会先看三项条件：页面语义是否足够表达目标，引用与页面状态能否持续对应，以及结果是否有可检查的完成标准。

过滤后即使标题和购买按钮都留下了，库存文字仍可能消失。按钮可以定位，只说明存在一个动作目标，不能据此回答“有货”。裁剪策略至少要保住当前任务需要的三类信息：

1. 动作目标与上下文：输入框、按钮、关联标签及所属区域，避免同名控件之间失去区分。

2. 业务对象身份：书名、版本、规格及结果行的对应关系，避免把其他对象的库存接到当前对象上。

3. 结果与约束证据：库存、价格、加载状态、禁用或选中状态、错误提示及失败原因。

agent-browser 的核心定位是面向 AI Agent 的浏览器自动化 CLI

0.41.1 也提供可选的 agent-browser chat：配置模型后，将自然语言转成命令并执行。

"husky": { "hooks": { "pre-commit": "tsc --noEmit && lint-staged" } }, "lint-staged": { "/.{js,jsx,ts,tsx}": [ "eslint --fix", "git add" ], "/.{md,json}": [ "prettier --write", "git add" ] }

作者自己团队的 ESLint 方案是基于 eslint-config-airbnb 扩展的，有兴趣可以体验一下 @sishuguojixuefu/eslint-config

"gitHooks": { "commit-msg": "commitlint -e -V", "pre-commit": "lint-staged" }

vant-react-native 暂时使用 @youngjuning/eslint-config、@youngjuning/prettier-config 约束项目代码规范。

standard-version 是一款遵循语义化版本（ semver）和 commit message 标准规范 的版本和 changlog 自动化工具。

"commitlint": { "extends": [ "@commitlint/config-conventional" ] }, "husky": { "hooks": { "commit-msg": "commitlint -E HUSKY_GIT_PARAMS" } }

当配置 conventionalCommits 为 true 后，lerna 版本将使用 Conventional Commits Specification 来确定版本升级并 生成 CHANGELOG.md 文件。

组件级别解耦，独立版本控制，每个组件都有版本记录可追溯

使用 yarn workspaces 结合 Lerna useWorkspaces 可以实现 Lerna Hoisting。这并不是多此一举，这可以让你在统一的地方（根目录）管理依赖，这即节省时间又节省空间。

由于子包之间有依赖关系，不要使用 --parallel 参数并行执行打包脚本。

"predev": "lerna run build --scope @vant-react-native/icons", "dev": "lerna run dev --parallel", "start": "react-native start", "debug": "run-p dev start",

组件单独发布，支持灰度、版本回滚以及平滑升降级

使用 ttf 字体有一个弊端，就是每次更新图标，都要相应的更新 ttf 文件，然后再次打包发布 APP。而且 ttf 不支持多种色彩的图标，导致所有图标都是单色。

fwh1990 大佬针对以上痛点用纯 Javascript 实现 iconfont 到 React 组件的转换操作，不需要依赖 ttf 字体文件，不需要手动下载图标到本地。

由于实际依赖的是 packages 下的包，我们必须先编译所有的包，否则部署的时候会报 This dependency was not found: 的错误。

Dumi 是支持 Lerna 仓库的，它默认会以 packages/[包名]/src 为基础路径搜寻所有子包的 Markdown 文档并生成路由。

@youngjuning/eslint-config 计划也用 lerna 管理，产出 @youngjuning/eslint-config-react、@youngjuning/eslint-config-react-native、@youngjuning/eslint-config-vue 让开发者无需过多配置开箱即用。

所以未来我会定制一个 vant-react-native 自己的按需加载 babel 插件。

@unchecked Sendable 是一个逃生舱：它告诉编译器"这个类型我人工审计过了，线程安全我自己保证，你不用检查"。

sessionEntryCache 是一个普通的 Dictionary，没有锁、没有串行队列、没有 actor，什么保护都没有。@unchecked Sendable 关掉了编译器的并发检查，于是这个隐患一路绿灯上了线。

Thread 4 把字典的底层存储写坏，破坏的是共享的堆。此后任何线程在任何位置做一次内存访问，都可能踩到那片被污染的区域，然后随机崩溃。

当两次刷新时间上挨得很近（比如启动时 bootstrap 和文件监听几乎同时发生），两个 detached task 就并发进入了同一个 adapter 实例的 discoverSessions()，一起写那个没有任何保护的字典。

细粒度锁保护了"每一次字典操作"的原子性，却没保护"读—改—写"这个序列整体的原子性。

这里的不变量是"cache 里的 offset 必须和已经解析进去的字节严格对应"。要维持它，整个 discoverSessions() pass 必须串行执行。

第二个调用等第一个做完之后拿到锁，此时 cache 已经是热的，绝大多数文件的 mtime / fileSize 都没变，直接命中缓存、零 I/O 秒回。

编译器无法证明你两者之间没有 await，于是干脆禁止在 async 上下文里裸用 lock()/unlock()。

Swift Data 的 index 是绝对的。removeFirst(n) 之后，它的 startIndex 会前移到 n，而不是回到 0。

这不是偶发的并发时序问题，是个确定性 bug：只要有一个 Claude 会话在跑、它的 JSONL 被追加写入两次，就必崩。

Data、ArraySlice、Substring 的 startIndex 随时可能不是 0，尤其在 removeFirst / 切片之后。遍历用原生 index，不用 Int 硬编码。

看到 @unchecked Sendable，就当成一个待验证的 TODO。 它旁边必须有一句注释说明"靠什么保证线程安全"（哪把锁、哪个串行队列、哪个 actor）。

注意最后一行：找不到资源包，它不给你 fallback，直接 fatalError。

当你手动把可执行文件塞进 Owlet.app/Contents/MacOS/、把资源包塞进 Contents/Resources/ 时，布局对不上，Bundle(url:) 在它预设的候选路径里全部返回 nil，于是走到最后一行崩掉。

全项目一共 8 处加载资源，其中 7 处都规规矩矩用了 AppResourceBundle.module：hook 脚本、app 图标、菜单栏猫头鹰、Dashboard 图片、本地化 bundle……唯独排名图标这一处漏了网

但崩溃发生在 Bundle.module 这个表达式被求值的瞬间，压根轮不到 .url(...) 返回 nil。

崩溃日志里"触发信号的那个线程"（triggered: true）才是凶手，其他线程往往只是受害者。

Bundle.module 和 AppResourceBundle.module 类型一样、API 一样、调用方式一样，编译期没有任何区别。

至少可以加一条 lint / grep 规则，在 CI 里扫「除了 AppResourceBundle.swift 之外任何文件出现裸的 Bundle.module」直接 fail。

凡是「开发机好好的、用户机崩」的 bug，第一反应就去查运行环境差异——资源布局、签名方式、路径假设、权限。

Claude Code 负责架构、长上下文和需要判断力的重构；Codex 负责快速试错和小范围实现；我负责拍板、验收和把家乡青山湖的颜色塞进 UI。

文件监听用 Dispatch Source，而不是轮询。

JSONL 增量读取。 50 MB 的会话日志不应该造成 50 MB 内存峰值。ClaudeCodeAdapter 用 (mtime, fileSize, byteOffset) 做缓存，文件增长时只读新增 bytes。

这些规则都被写进了 CLAUDE.md 和 AGENTS.md，成为后续所有改动的底线。

skill 是按需加载的操作手册。 它平时不占上下文，只有当任务命中触发词（"做 mac 应用图标"、".icns"）才被拉进来。

1. 可执行，不是描述。 别写"记得处理透明背景"，直接给能跑的脚本 + 参数 + 兜底分支。

涉及提交推送，一律以 git rev-parse、git status、git show 的真实输出为准，绝不用中间回显下结论。

"这次用了方案 A"没价值；"因为 X 约束所以选 A、代价是 Y"才能迁移到下一个场景。

文件监听用 Dispatch Source，而不是轮询。 之前有些实现会 sleep-loop 检查 active session，我全部砍掉了。

ClaudeCodeAdapter 用 (mtime, fileSize, byteOffset) 做缓存，文件增长时只读新增 bytes。

这些规则都被写进了 CLAUDE.md 和 AGENTS.md，成为后续所有改动的底线。

最后定位到问题不在业务逻辑，而在 AppKit window level、NSPanel、系统材质和透明圆角叠加后的边界行为。

写了没触发词 = 白写。 skill 描述里不写"mac 应用图标 / .icns"，下次问"帮我做个应用图标"时它根本不会被加载。

把一次性的操作细节塞进 CLAUDE.md，每次会话都要为它付上下文成本。

这些规则都被写进了 CLAUDE.md 和 AGENTS.md，成为后续所有改动的底线。

snapshot -i 偏向可引用的操作目标，“有货”这样的普通结果文字可能被排除；某些标题和表格单元格能够留下，也不保证所需字段完整。找动作目标时可以压缩观察，检查业务结果时则需要保留相关正文、状态或表格内容，不能把“交互快照里没出现”理解为“页面没有”。

若请求超时而动作效果未知，应先检查页面是否已经发生变化。尤其是提交、支付、删除等操作，不能仅凭未收到成功响应就重复执行。

目标可观察 必要控件和字段是否出现在语义表示中？ 修复页面语义，或明确采用其他观察方式

结果可验证 参数与业务结果能否通过 AX 再次确认？ 保留受阻或未验证状态，不以调用成功替代业务结果

role="button" 不会自动添加 Enter/Space 激活、事件处理或正确的禁用逻辑。可用原生 button 时，优先直接使用。否则 AX 中有 button，也可能遇到“按键没有反应”的实现缺口。

原生 disabled 在支持它的控件上具有实际禁用行为，通常也使其退出 Tab 顺序；单独 aria-disabled 只传达不可用状态，不自动阻止事件。

读取 AX Tree 也不代表整套工具只使用 AX 信息：当前实现还包含 DOM 范围解析、可点击线索补充等处理，不能把这张漫画理解为纯 AX-only 约束。

点击“更多筛选”时，脚本需同时更新内容是否显示和 aria-expanded。aria-controls 只表达控制关系，不会自动把按钮连成可工作的折叠组件。

本站只用 Accessibility Tree，浏览器 Agent 能走多远？核验的是 @mastra/agent-browser 0.4.1 与 agent-browser 0.19.0 的组合，那条路径通过 Playwright ariaSnapshot() 生成工具快照。本文核验的上游 0.41.1 Chrome 原生路径直接读取 CDP AX Tree。

工具名和命令相似，不能代替对依赖版本及真实调用链的检查。

ARIA snapshot-only 观察 工具生成的角色、名称、状态和引用 DOM 遍历、名称计算、Locator 用于解释现有工具

原生 AX-only 观察 CDP 返回的角色、名称、值、状态、父子关系 从语义引用重新定位、检查可操作性并执行 Demo 采用

语义完整、任务范围受控的后台表单，值得把 AX-only 观察作为可测量的基线。它能帮助判断一次失败发生在观察、候选构造、目标绑定还是结果验收，也会直接暴露页面语义质量问题。

缺少必要语义时，可以明确转入混合观察，也可以保持 AX-only 并报告受阻；两者都需要如实记录实验条件。

这是建议的验收方法，不是本次已经完成的测试结果。

后续若比较速度、token 或费用，还需要固定任务、页面状态和完成条件，并将失败与恢复过程计入；本文没有进行这样的性能对照，不据此给出降本或提速比例。

为了最大程度方便开发者（无需安装运行环境）我们们需要一个可以将 CLI 打包成二进制的方案。

使用 package.json 的 bin 项是用来指定各个内部命令对应的可执行文件的位置

我用的爬虫插件是 colly，选择提示插件是 promptui。

我选择了 tj 大神的 commander

GitHub CI 监听到有新的 git tag 被 push 到仓库，则将所有模板打包并发布一个草稿版的 release

我是使用 net/http 手撸了一个文件下载函数，然后使用 archiver 对压缩包解压到缓存目录，最后使用 copy 复制到当前目录。

利用 recursive-readdir 库递归读取项目所有文件

利用 handlebars 进行模板替换

Node 开发的 CLI 是需要通过 NPM 安装的，开发者需要在本地事先安装 Node 环境。

它由于将 Node 环境打包进安装程序造成安装包过大以及直接暴露源代码落选了

没有选择 Deno 的原因生态不够完善需要自己造的轮子有点多。

CGO_ENABLED=0 GOOS=windows GOARCH=amd64 go build -o ${name}.exe main.go

urfave 比较简单易上手，如果是小型的或者单命令的程序推荐选择，我选择的是 cobra。

自动为你的应用程序生成的 bash 自动完成

可选与 viper 紧密集成，可用于 12factor 应用程序

暂未和 viper 联动，后续有需求可以加上。

为了最大程度方便开发者（无需安装运行环境）我们们需要一个可以将 CLI 打包成二进制的方案。

在命令行输入 npm link 或 npm install -g 将当前项目安装到全局环境

暂未和 viper 联动，后续有需求可以加上。

一句话总结 git worktree 是同一个 Git 仓库的多个 checkout。每个 checkout 有自己的分支、文件和未提交改动，但共享提交历史与对象数据库。

它不是替代 branch。branch 仍然定义历史；worktree 只是让多条历史线同时拥有可工作的文件系统。

它们仍共享同一个仓库的 Git 对象库，不能把它当成权限隔离。

同一分支不能被两个 worktree 同时 checkout；这是 Git 用来避免同一分支出现两份独立未提交状态的保护。

普通 git stash push 默认不收未跟踪文件，-u 把它们一并收纳，忽略文件仍默认留着。Pop 成功应用后移除条目；发生冲突时保留条目，先解决冲突，再决定是否删除。

两边有各自的工作区、index 和 HEAD，共享仓库对象与多数引用；原目录的未提交修改不会自动出现在新目录里。

临时换任务时，按是否需要保留原现场，在 Stash 和 Worktree 之间选择。

取回后重新检查 Diff 和暂存状态，不能假设 Zed 的 Pop 会恢复原来的 Staged / Unstaged 划分。Stash 不会随普通 Push 同步，也不能代替远端备份。

执行 git push 或 git clone 时出现 Failed to connect to github.com port 443，表示连接还没到 GitHub 的认证阶段，就在 HTTPS 建连前失败了。

按“DNS 解析 → 本机代理 → 网络出口 → Git 配置”的顺序排查。hosts 只应作为明确、临时且可回滚的诊断手段，不是长期方案。

代理客户端退出、端口变化后，Git 仍会尝试连接旧地址。确认不需要代理时，清掉旧配置：

避免采用：从第三方网站抄 IP 后长期写 hosts。它可能短暂恢复访问，却会在下一次基础设施变更时再次失效。

值得上：你同时处理发布、修复、审查或多个 Agent 任务；你不想为了切分支 stash 半成品；你需要从一个干净 commit 产出可追溯制品。

可以再等：仓库很小、任务严格串行，而且你几乎没有未提交改动。

行为核对于 2026 年 10 月 29 日，参考 Zed 官方文档及固定版本源码；截图未显示安装版本号，具体菜单以当前版本为准。

上家公司是从 2018年3月干到2020年5月的，整整两年，写过小程序，负责过公众号、参与过基于element 和 vue 的后台程序开发、基于React Native开发过业务，搞过React Native 项目的架构。

那是 18 年的夏天，公司 6 月底去成都团建回郑州后，小弟、肖老师和当时绰号小萌的我（以下简称三剑客）开始了使用 React Native 开发 App 的工作。

跨端开发相较于传统的原生开发有其迭代周期快、可以在发布应用后热更新代码、甚至代码直接通过服务动态下发的优点，相较于 Codava、H5 打包这种解决了 60 帧问题，性能更好更接近原生。

我们不可能把所有的设备控制面板都写在 App 中，ios、android 的平台也不能动态下发代码，而 React Native 可以实现开发面板 - 打包 - 注册到云端 - 客户端根据从服务端动态加载相应的业务代码这个流程。

刚开始主动打招呼的和海投回应的都很多，9成都是 Vue 开发，甚至需要维护 jquery 项目。我心想还是主动投投 React Native 岗位吧，现实再次打了我的脸，郑州这边 RN 岗位两个手数的过来，并且范围都是 8-10K，甚至 4-8K。

有一说一，React Native 包括 Flutter 在内，岗位比 Web 前端开发是要少很多的，但是这并不意味着不值得投资。相较于 Web 开发，跨端开发需要掌握更多的技能，入门更难一些。但是一般掌握了它，对应的薪资待遇也是很诱人的。

万事开头难这句话用在 RN 和 Flutter 上尤其合适，跨端对于原生转和前端上手都是不太友好的，所以不要再问前端转合不合适，原生转不比你舒服到哪里去。

如果用 Android Studio 打开项目，不要跟着提示随便升级 gradle - RN 0.60 之后 ios 使用 cocoapod 管理项目依赖，这玩意如果网速不好，会卡住。

以我的经验来看，只要你有编程经验，快速从事 RN 业务开发难度并不大。写页面用到的无非是 React 语法、React Native 内置组件的使用和第三放组件、API 的使用。

但是如果是要掌控整个 App 的架构和开发，那要求会多一些。但也无非是 React 开发同样需要掌握的全局状态管理、路由管理、组件封装等能力。

你可能会问不会原生开发可以从事 RN 开发吗？答案是肯定的，跨端方案的出现对于前端开发者的一大利好便是可以使用前端技术开发移动应用。

当然你可能还有疑问，如果社区没有现成的，或者需要自定义原生的功能才能完成业务怎么办？这个就没那么简单了，但是别担心，现代工业社会是讲究协作和精细化分工的，在涂鸦，我们有专业的原生开发团队为我们提供底层 SDK 业务编写，但是我还建议大家 ios、android 的桥接代码还是要会写、原生的配置要懂，有助于提升个人能力和稀缺性。

工作需要，总结了React Native 开发经验并输出了React Native 项目架构面面观【持续更新】、react-navigation 5.x 最佳实践 等多篇相关博文，这几篇也成为了几十篇文章中阅读量和点赞最多的。

- umi-plugin-react-native：Show React Native Demo with dumi powered by react-native-web - react-native-quill-editor：React Native Quill Rich Text Editor Wrapper - react-native-form：私塾React Native动态表单项目，这个项目后来只在内部更新了，离职一年多了，大概率被同事重构了已经，我一直说要用 hooks 实现以下，也没得机会。

- react-native-screenshot：简单易用的 React Native 截屏、监听系统截屏事件组件（ios、android） - react-native-office-viewer：Office Preview Plugin for React Native（support png,pdf,doc,xls,txt...） - react-native-template-sishu：👾 Clean and minimalist React Native template for a quick start with TypeScript.

- 优雅地使用TypeScript开发React Native应用 - react-navigation 5.x 最佳实践 - React Native 项目架构面面观 - React Native 集成 CodePush 指南

抱着快要放弃的心态，再次缩小范围投递了几家 React 技术栈的公司，最终实现了试用期工资高于上家的目标。

郑州这边 RN 岗位两个手数的过来，并且范围都是 8-10K，甚至 4-8K。

React Native 包括 Flutter 在内，岗位比 Web 前端开发是要少很多的，但是这并不意味着不值得投资。

一句话总结 Skill 应该按“谁拥有决策和证据”拆分，而不是按“这些命令能不能连着执行”拆分。

真正的难点不是多写几个 SDK 调用，而是阻止 Provider 私有协议渗透业务层。

真正起作用的，是把正确的信息送到正确的阶段，尽量不让无关的文件、文档、日志和历史决策进入当前上下文。

第一，发行版只消费 registry 中已发布的精确 package。禁止 file:、link:、workspace:、本地 tarball、sibling lookup 或跨仓 symlink。

测试通过、package 已发布、产品已构建、签名完成、CDN 可读、更新通道已激活、旧客户端成功升级，分别是不同事实。

不应该修改： - Agent Chat 的事件渲染逻辑 - Workflow Run 状态机 - Approval 数据模型 - Audit Event 格式 - Asset 的事实源模型

如果新增 Hermes 还需要修改以上模块，说明 Provider 私有语义已经穿透 Adapter 边界。

判断标准不是“聊了多少轮”，而是当前上下文是否还服务同一个目标。

所以应该按职责选择，而不是把所有工具都打开： text 查外部文档 → Context7 理解代码结构 → Serena 查精确字符串 → rg 修改代码和跑测试 → Codex 原生工具

因此 Agent Ops Session 是权威记录，Provider Session 只是外部引用。

创建 Session 时还应该固定 Provider 版本、Workspace Revision、权限配置和资产投影版本。

如果工作只发生在一个产品仓库，且没有跨仓发布或受控凭据边界，暂时不必为了形式拆 Skill。

如果应用只调用一个稳定 API，且没有切换执行引擎的计划，直接封装一个 Client 往往足够，不必为了模式而模式。

但不要为了“省 token”把一个小任务拆成很多 Session。每次新建 Session 都有重新传递背景和重新建立上下文的成本。

需要理解系统边界和做取舍的，找 Claude Code；需要快速验证一个想法的，找 Codex。

整个过程中，AI 没有替我做任何一个真正重要的决定。

文件监听用 Dispatch Source，而不是轮询。

这些规则都被写进了 CLAUDE.md 和 AGENTS.md，成为后续所有改动的底线。

禁止 file:、link:、workspace:、本地 tarball、sibling lookup 或跨仓 symlink。

解析顺序是： text 显式环境变量覆盖 → App/SDK bundled runtime → 系统 CLI 开发兜底

探索完成后，我会把结论压缩成一份 handoff，再开始实现

上层根据数据决定是否展示“恢复”“Fork”或“审批”按钮，而不是判断 Provider 名称