守株阁

本文只抓一个问题：React 到底在解决什么问题？答案不是"简化 DOM 操作"，而是把 UI 更新从命令式的逐步操作变成声明式的状态映射。理解这个范式转移，是后续所有文章的前提。 同一个需求，两种写法 需求：页面上有一个计数器，点击按钮数字加一。 jQuery 写法： 12345678910// jQuery：告诉浏览器"怎么做"$(document).ready(function() { let count = 0; $('#counter').text(count); $('#increment').click(function() { count++; $('#counter').text(count); // 手动把新值写到 DOM });}); React 写法： 1234567891011// React：告诉框架"应该是什么样"function Counter() { co...

本文只抓一个问题：TypeScript 到底在 JavaScript 之上加了什么？答案不是"类型注解"，而是一整套结构化类型系统。理解这个区别，是后续所有文章的前提。 一个反直觉的例子 123456789101112interface Cat { name: string; meow(): void;}interface Dog { name: string; meow(): void;}const dog: Dog = { name: "Buddy", meow() { console.log("woof?"); } };const cat: Cat = dog; // 编译通过，没有任何警告 Cat 和 Dog 是两个完全不同的 interface，名字不同，语义不同，但 TypeScript 认为它们可以互相赋值。 把同样的事情放到 Java 里： 12345interface Cat { String getNam...

多阶段 Agent 工作流常遇到一个问题：前一阶段已经结束，消息历史仍然带着大量搜索结果、失败命令和废弃路径；下一阶段需要其中的约束，却不需要完整过程。此时应该继续同一会话、做一次 compact、派发子 Agent，还是从 checkpoint 启动新会话？ 这个问题不能靠在 messages 数组里寻找某个神奇下标解决。需要设计的是工作状态怎样越过边界，以及边界后的 Agent 怎样证明自己已经恢复到可执行状态。 四种边界经常被混在一起 “会话”在不同产品和讨论里可能指四件事： 边界 它分隔什么 典型操作 主要风险 Context Window 边界 当前一次模型调用可见的工作集 prune、compact、重新装配 关键信息遗漏、摘要失真 Durable Session 边界 可恢复的事件日志或产品会话 resume、fork、clear、新建 session 把持久日志误当成模型当前输入 Work Phase 边界 规划、实现、验证等工作阶段 checkpoint、handoff、验收门 阶段输出没有形成可验证契约 Agent / Role 边...

Coding Agent 的上下文并不是一份不断增长的聊天记录。模型每次决策前看到的输入，来自项目指令、Rules、Skill、工具定义、会话历史、外部记忆和运行时事件。它们由不同组件保存，在不同时间进入工作窗口，也由不同机制负责恢复。 如果不先划清组件边界，几个常见问题会混成一团：AGENTS.md 和 Skill 谁优先，MCP 与 Tool Search 是否相同，Hook 算不算上下文，Subagent 是工具还是新会话，compact 后恢复的是历史还是外部材料。 这套系统更接近一台上下文操作系统。模型只处理当前工作集；Harness 负责装配、换页、执行、隔离和验证。 核验日期：2026-07-17。本文讲稳定组件和边界。各产品的版本差异集中在实现图谱中维护。 上下文系统的五类组件 同一个 Markdown 文件可能同时带有说明、脚本入口和资源链接，但在运行时仍可以按职责拆成五类。 组件类别 主要对象 回答的问题 内容源 System prompt、AGENTS.md、CLAUDE.md、Rules、Skill、Memory、文件 有哪些材料可以进...

AI Coding Agent 的能力加载，已经从「启动时读几份规则文件」发展成一套完整的上下文控制面。 这套控制面要处理发现、触发、注入、隔离、压缩恢复、权限和分发。Skill 只是其中一个可复用单元，不等于整个上下文系统。 事实核验截止日期：2026-07-17。文中版本与日期均链接到官方 Changelog、官方文档或官方仓库；living docs 没有发布日期时，只按本次访问结果描述当前行为。 先把四个层次分开 不少比较把模型、API、Agent Harness 和最终产品混在一起，结论因而从起点就错位。 模型层决定上下文窗口、注意力分布、推理能力和工具调用能力。 API 层提供 instructions、tools、input items、prompt cache、compaction 等原语。 Harness 层扫描规则与 Skill，组装上下文，调度工具、子 Agent 和压缩流程。 产品层再叠加编辑器、CLI、插件市场、权限界面、团队策略和云端执行。 flowchart TB M["模型层<br/>窗口、注意力、推理、工具调用&...

AI Coding 产品常被放进一张“功能对比表”，但模型、API、Harness 和最终产品并不在同一层。把 Kimi 模型和 Claude Code 的本地文件扫描放在一起比较，或者用 API 的 Prompt Cache 解释 CLI 的 Skill 热更新，都会制造错误结论。 更稳定的比较单位是 Coding Harness：它位于模型与代码仓库之间，负责发现指令、装配上下文、暴露工具、执行 Hook、派生子 Agent，并在长会话里处理压缩与恢复。 核验日期：2026-07-17。表格只记录官方文档和官方更新日志能够支持的事实。未公开的实现统一标成“未知”，不根据相似产品补齐。 先确定比较层级 层级 主要职责 不应混入的结论 模型 推理、上下文容量、工具调用格式、多模态能力 不负责扫描本地 SKILL.md API / Provider 请求协议、鉴权、缓存计费、托管工具 不等于 CLI 每轮如何装配上下文 Coding Harness 指令发现、Skill 目录、工具运行、compact、Hook、子 Agent 本文的主要比较对象 能...

Skill 加载看起来像一个文件读取问题，实际包含两条不同的链路： 宿主进程何时扫描、解析并缓存 SKILL.md Skill 内容何时进入模型可见的上下文 两条链路可能一早一晚。OpenCode 会在宿主侧初始化 Skill registry，但模型仍要调用 skill 工具才会看到正文；Claude Code、Codex、Cursor 和 Kimi Code 也都把轻量目录与完整说明分开处理。用“启动时有没有读文件”判断是否按需加载，很容易得出相反结论。 更准确的问题有三个：模型启动时看到了什么，正文以什么形式进入会话，长会话压缩后哪些内容能够恢复。 核验日期：2026-07-17。产品实现会持续变化。正文把官方公开契约、源码观察和未知行为分开标注，不用一个产品的行为推断另一个产品。 比较对象必须处在同一层 模型、API、Harness 和最终产品经常共用一个名字，但它们负责的事情不同。 层级 负责什么 例子 模型 上下文上限、推理、工具调用能力、多模态 Claude、GPT、Kimi K2 API / Provider 请求协议、缓存计费、Too...

测试夹具这个中文词带着工业感，让第一次听到它的开发者往往去搜索"是不是翻译错了"。词源确实如此：fixture 来自机械加工，后来进入电子测试领域，再由 Kent Beck 引入软件测试框架里。这个词在软件工程里覆盖的范围，也远比"单元测试"要宽。 从车间到代码 fixture 这个词在机械加工里有精确含义：在 CNC 车床或焊接台上，fixture 是一种工装，把工件固定在已知位置，让每次加工操作都从相同的起点开始。与 jig（引导刀具路径的夹具）不同，fixture 的职责只有一件事——把工件钳牢，消除定位误差。 词源上，fixture 来自拉丁语 figere（刺入、固定），经 fixura（固定物）演变为英语词汇，约在 16 世纪末进入法律语言，最初指"永久附着于不动产的动产"——嵌入墙体的管道、固定在地板上的书架，那些不能随意拆走的东西。 电子测试领域用法相似：一块 PCB 插入测试夹具后被固定在已知电气状态，探针才能重复施加相同的激励、在相同节点读取信号，排除接触不稳定的干扰。 三种用法的共同语义：将某个对象...

上一篇解决了 Spark 的性能诊断方法。这一篇进入设计对比——Spark 和 Flink 两种计算引擎的架构选择。 这不是一个"谁更好"的问题。Spark 和 Flink 从不同的起点出发，做了不同的设计取舍，各自在擅长的场景中有结构性优势。Spark 从批处理出发，用 micro-batch 扩展到流处理；Flink 从流处理出发，把批看作有界流。两条路线在功能上逐步趋同，但底层架构的差异导致了性能特性和适用场景的持久分化。 本文只抓一个问题：两个引擎在执行模型、状态管理、容错机制和延迟特性上的具体差异及其设计原因。 执行模型对比 Spark 的执行模型是 Stage-based DAG：把计算图按 Shuffle 边界切成 Stage，每个 Stage 包含一组可以 pipeline 执行的窄依赖变换。Stage 之间是全局同步点——上游 Stage 的所有 Task 必须全部完成后，下游 Stage 才能启动。 1234567891011Spark 执行模型: Stage 0: [Task 0] [Task 1] [Task 2] 全部完成 ...

上一篇解决了动态资源分配和调度策略。这一篇进入性能诊断——当 Spark 作业慢了，怎么找到瓶颈。 性能调优的第一步不是改配置，是定位问题。Spark UI 提供了五个关键页面（Jobs、Stages、Storage、Environment、Executors），每个页面指向不同类型的性能问题。Event Log 提供了离线分析的完整数据。 本文只抓一个问题：面对一个慢作业，如何从 Spark UI 的指标出发，沿着诊断路径找到根因。 Spark UI 五个页面 1234567891011121314151617181920212223Jobs 页面 → 每个 Action 对应一个 Job → 关注: Job Duration、Failed Tasks 数量 → 入口: 找到最慢的 Job，点击进入 Stage 详情Stages 页面 → 每个 Stage 的 Task 统计 → 关注: Task Duration 分布、Shuffle Read/Write、GC Time → 核心: 这里是定位性能问题的主战场Storage 页面 → 缓存的 RDD/DataF...