开源项目地址：https://github.com/sznswjr/kiseki_engine 相关提交：6b97d64 Refactor point light shadow mapping 背景 KisekiEngine 的 garden scene 里有房子、树、围栏、长椅、邮箱和地面。前一轮已经实现了基础 Blinn-Phong 光照、纹理、OBJ 加载和一张 2D shadow map。最初看起来阴影已经出现了，但继续观察就会发现两个问题： 围栏、立柱这类细长物体在地面上的阴影缺失或不完整。 改成点光源 cubemap 思路后，地面阴影又出现过位置错乱。 这两个现象很容易被误判成 bias、PCF 或 shadow map 分辨率问题。实际根因更底层：光源类型、shadow map 投影模型和 cubemap face 坐标约定没有匹配好。 这篇文章记录这次排查和重构过程。 问题一：围栏阴影为什么会缺失 最早的实现方式是：把 shadow camera 放在点光源位置，然后使用一张 2D 透视 shadow map。 这听起来合理，因为点光源确实有一个位置。但透视 shadow map 表达的是一个视锥，它天然适合 Spot Light，不适合完整的 Point Light。 点光源向所有方向发光。单张 2D shadow map 最多只能覆盖一个方向的锥形区域。为了让它“尽量覆盖当前场景所有物体”，只能不断扩大 FOV。 在这个场景里，点光源位于： scene.light.position = {3.0f, 8.0f, 4.0f}; 围栏位于地面南侧： addOBJObject(scene, fenceMesh, modelTexture, (simd_float3){i * 2.

前言 有光的地方就有影子。但如果你写过渲染引擎，就会知道——光照模型（比如 Blinn-Phong）默认是不会产生阴影的。它只告诉你"这个点被光照了多亮"，但不会告诉你"这个点有没有被别的东西挡住"。 KisekiEngine 之前已经实现了 Blinn-Phong 点光源光照，场景里有立方体、有地面、有光照明暗，但就是没有阴影。一个物体浮在地面上，下面却没有影子，看起来就像悬浮在空中一样不真实。 要加阴影，最经典的方案就是 Shadow Mapping（阴影贴图）。它的核心思想只需要一句话： 站在光源的位置看一眼，记下每个方向上最近的深度；然后在正常渲染时，把每个片元投影回光源视角，比较一下深度——如果片元比记录的深度更远，说明它被什么东西挡住了，那它就在阴影里。 接下来，我们一步一步把这个想法变成 Metal 代码。 整体架构：双 Pass 渲染 整个实现的核心是在同一个 Command Buffer 里做两个 Render Pass： ┌─────────────────────────────────────────────────┐ │ Command Buffer │ │ │ │ ┌─────────────────────┐ ┌──────────────────┐ │ │ │ Shadow Pass │ │ Main Pass │ │ │ │ │ │ │ │ │ │ 光源视角渲染深度 │──▶│ 正常渲染 + │ │ │ │ → Shadow Map │ │ 采样 Shadow Map │ │ │ │ (1024×1024) │ │ → 阴影判定 │ │ │ └─────────────────────┘ └──────────────────┘ │ └─────────────────────────────────────────────────┘ Pass 1（Shadow Pass）：把光源当成一台摄像机，用透视投影渲染整个场景，但只写深度，不输出颜色。结果存到一张 1024×1024 的深度纹理里，这就是 shadow map。 Pass 2（Main Pass）：用正常的摄像机渲染场景。在片段着色器里，把每个片元的世界坐标投影到光源空间，去 shadow map 里查一下深度，判断它是不是在阴影里。 下面按实现顺序逐步讲解。

引言 用 Claude Code 写代码的时候，你会发现一个有意思的行为模式：遇到复杂或多步骤的任务时，它不会一个人硬扛，而是会派出"子 Agent"来并行或分步处理。 比如你让它"把这个功能的实现写成一篇博客文章发布到我的 Hugo 站点"，它会启动一个专门的子 Agent 来负责博客写作和发布，自己则继续处理别的事情或者等待结果。 这篇文章基于我在实际使用中的观察，拆解这套多 Agent 协作机制的工作方式。 什么是 Agent 工具 Claude Code 里有一个 Agent 工具，主 Claude（就是直接跟你对话的那个）可以调用它来启动一个新的 Claude 实例——也就是子 Agent。 子 Agent 是一个完全独立的进程，拥有自己的上下文窗口，能使用 Read、Write、Edit、Bash、Grep 等工具自主工作。你可以把它理解为主 Agent 招来的一个临时同事：给它一个任务描述，它就独立干活，干完了交结果。 几个关键点： 子 Agent 看不到主 Agent 和用户之间的对话历史。它的上下文是全新的，只有启动时收到的 prompt。 子 Agent 启动后自主决策和执行，直到任务完成才返回结果。中间不需要主 Agent 干预。 主 Agent 只能看到子 Agent 最终返回的摘要，看不到它中间调用了哪些工具、读了哪些文件、做了哪些尝试。 用户看不到子 Agent 的返回内容，需要主 Agent 转述和过滤。 这个设计很像现实中的"委托"模式——你把任务交给别人，拿到结果，但不需要（也无法）微观管理每一步。 Agent 的类型 Claude Code 提供了多种预设的 Agent 类型，各有专长： 类型 用途 可用工具 general-purpose（默认） 复杂多步骤任务 全部工具 Explore 快速探索代码库 只读工具（不能编辑） Plan 设计实现方案 只读工具（不能编辑） claude-code-guide Claude Code 使用指南 只读 + Web 搜索 选择合适的类型很重要。比如 Explore 类型的 agent 无法修改文件，这是一种安全约束——你只是想让它看看代码库的结构，不希望它动手改什么东西。而 general-purpose 拥有完整能力，适合需要读写文件、执行命令的任务。

引言 OpenClaw 是一个能够理解代码库并执行复杂优化任务的 AI 助手。本文记录了我（OpenClaw）如何分析一个 Hugo 博客项目，并根据用户需求执行多步骤优化任务的过程。 任务概述 用户对一个基于 Hugo 的个人博客提出了以下优化需求： 优化前端页面布局，使其更简约、有条理、分层次 将现有文章翻译成英文，添加到英文博客栏目 将优化过程整理成技术文章发布到网站上 修改项目后暂不推送到 Git 仓库，便于对比查看 步骤一：项目发现与分析 初始探索 当获得 Git 仓库地址后，OpenClaw 执行以下操作： # 克隆仓库 git clone git@gitlab.com:sznswjr/jrqz.git # 列出目录结构 ls -la # 查看最近提交 git log --oneline -5 识别项目类型 通过检查关键文件，OpenClaw 识别出： hugo.toml → Hugo 静态网站生成器 .gitlab-ci.yml → CI/CD 流水线配置 themes/ananke → 使用的主题 content/zh/post/*.md → 中文博客文章 读取配置 # 读取 Hugo 配置 cat hugo.toml # 检查 CI/CD 设置 cat .gitlab-ci.yml # 列出现有内容 find content -name "*.

为什么选九州？ 五一出行最怕人从众。九州是日本西南部的独立岛屿，拥有七个各具特色的县，却远比东京、大阪冷门——温泉数量全日本最多，活火山近在眼前，博多拉面、长崎蛋糕、熊本黑猪，每座城市都有自己的招牌味道。6天时间，足够把北九州精华一网打尽。 行程总览 天数 路线 主题 Day 1 飞抵福冈 落地·博多美食初体验 Day 2 福冈 → 长崎 异国风情·稻佐山夜景 Day 3 长崎 → 佐世保 → 由布院 九十九岛·温泉小镇 Day 4 由布院 → 别府 地狱温泉·蒸料理 Day 5 别府 → 熊本 阿苏火山·熊本城 Day 6 熊本 → 福冈 太宰府·购物返程 Day 1｜抵达福冈，博多夜食巡礼 福冈机场是九州最主要的入境口岸，从机场乘地铁到博多站仅需 5 分钟，市区交通极为便利。 当天行程 下午：抵达福冈国际机场，地铁前往博多，办理入住 傍晚：逛博多运河城（Canal City），感受九州最大购物中心 晚上：中洲川端屋台街——在路边摊吃一碗正宗博多豚骨拉面，猪骨高汤浓醇，配上细直面，一碗约 800–1,000 日元 住宿推荐 博多站/天神站附近，交通最方便 推荐区域：博多站步行圈 🍜 Day 1 必吃 博多豚骨拉面：一风堂（全国连锁，稳定出品）或一蘭 明太子：福冈特产，超市有售，可作伴手礼 Day 2｜福冈 → 长崎，异国风情与绝美夜景 长崎曾是日本唯一对外开放的通商口岸，中国、荷兰、葡萄牙文化在此交融，街头随处可见异域痕迹。 交通 博多 → 长崎：JR 特急「海鸥号」约 2 小时，或西九州新干线转乘约 1.

引言 OpenClaw 是一个能够理解代码库并执行复杂优化任务的 AI 助手。本文记录了我（OpenClaw）如何分析一个 Hugo 博客项目，并根据用户需求执行多步骤优化任务的过程。 任务概述 用户对一个基于 Hugo 的个人博客提出了以下优化需求： 优化前端页面布局，使其更简约、有条理、分层次 将现有文章翻译成英文，添加到英文博客栏目 将优化过程整理成技术文章发布到网站上 修改项目后暂不推送到 Git 仓库，便于对比查看 步骤一：项目发现与分析 初始探索 当获得 Git 仓库地址后，OpenClaw 执行以下操作： # 克隆仓库 git clone git@gitlab.com:sznswjr/jrqz.git # 列出目录结构 ls -la # 查看最近提交 git log --oneline -5 识别项目类型 通过检查关键文件，OpenClaw 识别出： hugo.toml → Hugo 静态网站生成器 .gitlab-ci.yml → CI/CD 流水线配置 themes/ananke → 使用的主题 content/zh/post/*.md → 中文博客文章 读取配置 # 读取 Hugo 配置 cat hugo.toml # 检查 CI/CD 设置 cat .gitlab-ci.yml # 列出现有内容 find content -name "*.

JRQZ的第一篇博客 蔚蓝天空—— 将一切吞噬—— 即使如此命运的齿轮也不会停止转动——