This commit is contained in:
zzzisfunnyboy
2026-04-01 00:58:24 +08:00
parent f03d4f72fc
commit 81a97f87c0
21 changed files with 390 additions and 230 deletions

12
.gitignore vendored Normal file
View File

@@ -0,0 +1,12 @@
### Windows
# Windows thumbnail cache files
Thumbs.db
# Folder config file
[Dd]esktop.ini
# Recycle Bin used on file shares
$RECYCLE.BIN/
# Windows shortcuts
*.lnk

View File

@@ -1,8 +1,8 @@
{
"accentColor": "",
"theme": "obsidian",
"cssTheme": "Border",
"textFontFamily": "Microsoft YaHei",
"cssTheme": "Zen",
"textFontFamily": "霞鹜文楷,Microsoft YaHei",
"interfaceFontFamily": "Microsoft YaHei UI",
"baseFontSize": 17
}

View File

@@ -4,31 +4,17 @@
"type": "split",
"children": [
{
"id": "1538f6ad5b15def5",
"id": "3e4f6277b6c6f87f",
"type": "tabs",
"children": [
{
"id": "afc535d48add9e90",
"id": "a240fec474278e11",
"type": "leaf",
"state": {
"type": "markdown",
"state": {
"file": "2Areas/游戏开发/pcei速度预估.md",
"mode": "source",
"source": false,
"backlinks": true,
"backlinkOpts": {
"collapseAll": false,
"extraContext": false,
"sortOrder": "alphabetical",
"showSearch": false,
"searchQuery": "",
"backlinkCollapsed": false,
"unlinkedCollapsed": true
}
},
"type": "empty",
"state": {},
"icon": "lucide-file",
"title": "pcei速度预估"
"title": "新标签页"
}
}
]
@@ -101,23 +87,23 @@
}
],
"direction": "horizontal",
"width": 338.5
"width": 401.5
},
"right": {
"id": "d809b577c235ae94",
"type": "split",
"children": [
{
"id": "7cbbb049622f8875",
"id": "c6a04719e9395783",
"type": "tabs",
"children": [
{
"id": "fc04db1c3d5f37f2",
"id": "a0097fbc2c860370",
"type": "leaf",
"state": {
"type": "backlink",
"state": {
"file": "地图编辑器/RoadMap.md",
"file": "4Archives/归档-目录.md",
"collapseAll": false,
"extraContext": false,
"sortOrder": "alphabetical",
@@ -127,35 +113,25 @@
"unlinkedCollapsed": true
},
"icon": "links-coming-in",
"title": "RoadMap 的反向链接列表"
"title": "归档-目录 的反向链接列表"
}
},
{
"id": "02bb49a0e123a922",
"type": "leaf",
"state": {
"type": "calendar",
"state": {},
"icon": "lucide-ghost",
"title": "calendar"
}
},
{
"id": "9132b294d54e83ca",
"id": "d6423d1f79769c25",
"type": "leaf",
"state": {
"type": "outgoing-link",
"state": {
"file": "地图编辑器/RoadMap.md",
"file": "4Archives/归档-目录.md",
"linksCollapsed": false,
"unlinkedCollapsed": true
},
"icon": "links-going-out",
"title": "RoadMap 的出链列表"
"title": "归档-目录 的出链列表"
}
},
{
"id": "a94ba3bbe0f00555",
"id": "009d8bcaab15bbb9",
"type": "leaf",
"state": {
"type": "tag",
@@ -170,90 +146,90 @@
}
},
{
"id": "e28ebb851b5264ee",
"id": "11a36b370174df61",
"type": "leaf",
"state": {
"type": "outline",
"state": {
"file": "性能优化/关于Unity加载优化你可能遇到这些问题 - 知乎.md",
"file": "4Archives/归档-目录.md",
"followCursor": false,
"showSearch": false,
"searchQuery": ""
},
"icon": "lucide-list",
"title": "关于Unity加载优化你可能遇到这些问题 - 知乎 的大纲"
"title": "归档-目录 的大纲"
}
},
{
"id": "d08a5ba04eeae6cf",
"id": "4a0e6c346bdcec3c",
"type": "leaf",
"state": {
"type": "copilot-chat-view",
"type": "calendar",
"state": {},
"icon": "message-square",
"title": "Copilot"
"icon": "calendar-with-checkmark",
"title": "Calendar"
}
}
],
"currentTab": 5
]
}
],
"direction": "horizontal",
"width": 200
"width": 408.5,
"collapsed": true
},
"left-ribbon": {
"hiddenItems": {
"bases:创建新数据库": false,
"templates:插入模板": false,
"canvas:新建白板": false,
"switcher:打开快速切换": true,
"bases:新数据库": false,
"switcher:打开快速切换": false,
"graph:查看关系图谱": false,
"command-palette:打开命令面板": true,
"canvas:新建白板": false,
"templates:插入模板": false,
"command-palette:打开命令面板": false,
"copilot:Open Copilot Chat": false
}
},
"active": "f2ac97a7addb8678",
"active": "a240fec474278e11",
"lastOpenFiles": [
"2Areas/游戏开发/索引.md",
"卡片数据库.base",
"InBox/v2ex_1196441_大模型变笨讨论.md",
"InBox/unity-csharp-patch.md",
"InBox/CLIProxyAPI.md",
"InBox/AutoHarness-论文解读.md",
"InBox/未看的帖子.md",
"InBox/测试笔记_共享转移_20250320.md",
"InBox/20260211-180200-VContainer-Unity-DI-文档笔记.md",
"InBox/介绍状态同步战斗玩法的设计和实现.md",
"2Areas/游戏开发/物理碰撞/物理碰撞算法.md",
"笔记数据库.base",
"InBox/网页总结_曹鑫博客_20250320.md",
"InBox/InBox-目录.md",
"2Areas/学习.md",
"2Areas/领域-目录.md",
"InBox/未命名.md",
"4Archives/归档-目录.md",
"4Archives/动态图集/动态图集-目录.md",
"4Archives/动态图集/动态图集.md",
"3Resources/游戏开发/性能优化/性能优化-面试.md",
"3Resources/游戏开发/性能优化/性能优化-方向.md",
"3Resources/游戏开发/性能优化/批量渲染 数字UI.md",
"3Resources/游戏开发/性能优化/黑马 SLG 游戏《三国:谋定天下》怎么用 Unity 技术实现高效地形渲染?.md",
"3Resources/游戏开发/性能优化/韩国Unity团队研发的demo分享—ProjectKaya.md",
"3Resources/游戏开发/性能优化/关于Unity加载优化你可能遇到这些问题 - 知乎.md",
"skills/obsidian-markdown/SKILL.md",
"skills/obsidian-bases/SKILL.md",
"skills/json-canvas/SKILL.md",
"00-Home.md",
"skills/obsidian-markdown",
"skills/obsidian-bases",
"skills/json-canvas",
"skills",
"未命名.md",
"2Areas/游戏开发/pcei速度预估.md",
"2Areas/游戏开发/物理碰撞/物理碰撞算法.md",
"1Project/海量渲染战斗/GPU动画工程/GPU蒙皮动画.md",
"2Areas/游戏开发/物理碰撞",
"1Project/海量渲染战斗/GPU动画工程/GPU顶点动画.md",
"1Project/海量渲染战斗/GPU动画工程/bindpose.md",
"1Project/GPU地形/Houdini PCG.md",
"1Project/GPU地形/GPU Driven Terrain 跟学与实现.md",
"渲染/软渲染/图片/9702b7cbafa93d6e3d0cd59e7cf37e31.png",
"渲染/软渲染/图片/86aa46af36c4c3b1f1efef2a1ccc6310.png",
"渲染/软渲染/图片/62ad22d3e981954fc083018fb850413a.png",
"渲染/软渲染/图片/23d61a2b7376ea3149d74d6bd4ea9430.png",
"2Areas/年度复盘/2025.md",
"1Project/ZYGame/州府前端流程.md",
"1Project/海量渲染战斗/GPU动画工程/TODO转为Job组织数据.md",
"1Project/海量渲染战斗/GPU动画工程/TODO将Time存进buffer中做成不同的实例可以使用不同的动画时间.md",
"1Project/海量渲染战斗/GPU动画工程/TODO不同动作存进Buffer中.md",
"1Project/海量渲染战斗/GPU动画工程/TODO 不同动作间的混合.md",
"1Project/海量渲染战斗/GPU动画.md",
"1Project/海量渲染战斗/GPU动画工程",
"1Project/海量渲染战斗/批量渲染gpu动画.md",
"1Project/海量渲染战斗/基于GPU蒙皮动画的Spine实现.md",
"1Project/海量渲染战斗/基于GPU动画和ComputeShader的大批量动画渲染Demo之GPU顶点动画.md",
"1Project/ZYGame",
"1Project/GPU地形/ComputeShader生成无限世界地形.md",
"2Areas/游戏开发/fgui&ugui合批记录.md",
"1Project/图文合批/字体字形图片申请.md",
"1Project/图文合批/图文使用不同的Tex2DArr.md",
"1Project/UE",
"1Project/海量渲染战斗",
"1Project/GPU地形",
"wallhaven-rq75r7.jpg",
"1Project/构建新框架/管道模式/未命名.canvas",
"2Areas/如何记录笔记/P.A.R.A/Pasted image 20250614192838.png",

View File

@@ -1,5 +0,0 @@
- 参考表的内容
- 地图格子该长什么样,需要什么图标显示吗
- 世界事件对应的实现需要策划案
- 政务系统
- 人力怎么来,需要怎么做

View File

@@ -1,13 +1,16 @@
### 养成界面
- 需要重写SlotViewModel这中间处理建筑的各种状态升级中普通空闲无建筑
- 区域选择界面
- 建筑背包
- 生产详情
- 建筑详情页面
- 背包
- 英雄
- 兵种
- 地图地板
### 地图
- 程序自动拼接不同区域
- 区域中不同节点
- 建筑
- 升级
- 缺少表现
- 消耗变化
- 建造
- 只有入口
- 招募兵种
- 军事区的新面板
- 资源背包
- 新面板
- 总览
- 背包
- 产出总览

View File

@@ -1 +0,0 @@
- 每个兵种允许装备最多一种武器和两种通用饰品

View File

@@ -1,36 +0,0 @@
# 地图性质说明
- 鏖战:
- 通常是战场性质的地图。战场重视的是人力、装备资源、战略地区,主要的交互方式是创建军队参与战斗。战斗本身有一定收益,但随着次数增加收益降低,如果支持的军队获胜,还会得到更高收益
- 幻影:
- 幻境地图。游戏内的地块被区分为多种多样的区域,不同的区域有不同类型的怪物,也会获得不同类型的收益
- 天灾:
- 世界上会不定期生成天灾军,击败后得到一定数值的天灾点。天灾军越强荣誉点越强。可以在地图中央使用天灾点购买道具
- 轻灵:
- 地图分为自由、神秘、宝藏3个区域。自由区每隔一段时间回血。神秘区有额外战利品加成。宝藏区可以得到神器碎片和神级角色信物
- 秩序:
- 地图内有一个完整的秩序,有商人区、魔物区和平民区,可以实现招募、打金、交易等一系列行为
- 神庙:
- 地图核心位置有一个宗教神庙,包含一个信仰的神明。可以选择信奉神明驱逐异端,也可以选择信奉恶魔驱逐信徒
- 瘟疫:
- 开始是正常的,后来会有瘟疫恶鬼不断出现,可以携带特定装备大幅降低恶鬼生命,或者清理一片区域的恶鬼。灵魂和圣女在这个世界有额外加成
# 需要的功能
- A\*寻路
- 格子地图
- 编辑器地图大小地图图片事件自定义CommandBuffer定义格子点击生成方块
- 模式:自动战斗,回合制
- 进入地图需要迷雾系统
- 鼠标悬停地图点位需要提示
- 怪物说明
- 战斗次数
- 点位奖励等级
- 奖励类型
# 事件
- [[战斗系统]]
- 暗雷战斗和地块战斗的战斗时间概率分别为5%和10%。
- 选择奖励
- 仪式:献祭物品可以进入独立的小地图
- 拜访:拜访一位未解锁的随机名人

View File

@@ -1,20 +0,0 @@
---
tags:
- 城堡
- 外包
- 目录
- MOC
---
- [[_城堡]]
- [[QA]]
- [[事件系统]]
- [[兵种系统]]
- [[地图系统]]
- [[城堡政务系统]]
- [[家园界面]]
- [[属性系统]]
- [[战斗系统]]
- [[抽卡系统]]
- [[背包系统]]

View File

@@ -1,25 +0,0 @@
# 建筑工厂
- 仅仅作为功能的开放
- 有条件限制,需要条件系统
- 解锁后,部分建筑需要消耗资源才可以建造
- 未解锁,仅仅显示名称,并被解锁条件遮盖
- 初始拥有农场
# 工厂经营
- 食物消耗
- 规则
- 任何建筑开始工作时(农场除外),每个人力 消耗每秒0.1单位粮食
- 城堡随着时间消耗粮食,每位居民每隔60s需要消耗1单位粮食
- 当粮食为0时出现部分居民无法获得粮食这部分居民拒绝交税。
- 粮食每消耗少消耗1单位居民缴纳的金币-1
- 居民每消耗1单位粮食缴纳1金币
# 事件
- 当玩家在城堡界面中 && “政务处理” 开启时
- 按照一定的速率生成随机事件
- 事件
- 随机
- 只要城堡满足该数据
- 条件
- 需要特定条件满足后触发,且仅触发一次

View File

@@ -1,4 +0,0 @@
- 区分区域,不同的区域都有市中心
- 建筑背包
- 建筑空地
- 建造

View File

@@ -1,8 +0,0 @@
- 兵种属性/装备属性:
- 力量
- 防御
- 生命
- 运气
- 技能
- 神性
- 信念

View File

@@ -1,3 +0,0 @@
- 回合制
- 规则
- 按照速度排序出手顺序

View File

@@ -1,3 +0,0 @@
- 概率和内容需要配置
- 内容
- 材料

View File

@@ -1,23 +0,0 @@
# 道具类型
- 材料
- 食物
- 消耗品
- 装备
- 灵珠
- 特殊道具
**需要一批材料、食物、消耗品的预设**
# 字段
- Id
- uId
- ItemType
- 材料
- 食物
- 消耗品
- userType
- 装备
- [[属性系统]]
- 灵珠
- 特殊道具

View File

@@ -1,4 +1,9 @@
# AABB
## SAP算法
这是一种先用扫描线扫描单条轴有无碰撞的快筛算法
- 假设一个2D项目
- 如果xa(min,max)与xb(min,max)在x轴没有交集那么y就无再扫描直接排除
- y轴也是同理
# SAT 分离轴定理

View File

@@ -0,0 +1,215 @@
# AutoHarness 深度解读
> 来源https://zhuanlan.zhihu.com/p/2016839356833341880
> 收藏时间2026-03-25
## 一句话总结
用小模型Gemini-2.5-Flash自动写一段"规则检查代码"包裹在 LLM 外面,让它不再犯"非法操作"的低级错误,结果小模型+代码 > 大模型裸跑。
---
## 这篇论文到底在解决什么问题?
### LLM 做 Agent 时的尴尬现实
你可能已经知道,现在很多人在用 LLM 做 agent——让模型去完成一些需要"行动"的任务,而不是简单地回答问题。比如让 LLM 下棋、玩游戏、操控机器人等。
**问题来了LLM 经常做出"非法操作"。**
论文举了一个非常生动的例子:在 Kaggle GameArena 的国际象棋比赛中Gemini-2.5-Flash 78% 的失败不是因为下棋策略差,而是因为走了不符合规则的棋。比如让马走直线、让兵倒着走之类的。
这就好比你请了一个非常聪明的人来帮你下棋,他对棋局分析得头头是道,但就是经常把棋子摆到不合法的位置上。
### 为什么会这样?
LLM 本质上是一个文本生成模型。它"知道"国际象棋的规则(因为训练数据里有大量棋谱),但它没有一个硬编码的规则引擎来确保输出的每一步都合法。它的"知道"是概率性的、模糊的,不是精确的。
### 现有解决方案及其问题
| 方案 | 怎么做 | 问题 |
|------|--------|------|
| Fine-tuning | 用大量合法游戏轨迹去微调模型 | 成本极高;可能降低模型在其他任务上的能力 |
| 手写 Harness | 人工为每个游戏写一个规则检查器 | 费时费力,每换一个游戏就要重写 |
**这篇论文的创新点是:让 LLM 自己写这个规则检查器。**
---
## 核心概念:什么是 "Harness"
### Harness 的直觉理解
"Harness" 这个词在英文里是"挽具/马具"的意思用来控制和约束马的行为方向。在这篇论文里Harness 就是包裹在 LLM 外面的一层"安全壳",确保 LLM 输出的动作是合法的。
用工程的话说,这就是一个 wrapper / middleware / interceptor
```
传统做法:
用户请求 → LLM → 输出动作(可能非法)→ 环境报错
加了 Harness 之后:
用户请求 → LLM → Harness检查 → 合法? → 执行
↓ 不合法
告诉LLM"这步不行" → LLM重新生成 → 再检查...
```
### 三种 Harness 变体
论文提出了三种不同"约束力度"的 harness
#### ① Harness-as-Action-Verifier动作验证器— 论文主要聚焦的方案
```python
while True:
action = LLM.generate(observation) # LLM 提出一个动作
if code_harness.is_legal_action(obs, action): # 代码检查是否合法
break # 合法就执行
else:
# 不合法,告诉 LLM 这步不行,让它重新想
observation += f"\n警告:{action} 是非法操作,请重新选择"
return action
```
类比:就像你写代码时 IDE 的实时语法检查——你写了不合法的代码,红线提示你改。
#### ② Harness-as-Action-Filter动作过滤器
```python
legal_actions = code_harness.propose_action(obs) # 代码先列出所有合法动作
best_action = LLM.rank(legal_actions) # LLM 从中选最好的
return best_action
```
类比:就像下拉菜单——用户只能从合法选项中选,不可能输入非法值。
#### ③ Harness-as-Policy代码即策略— 最激进的方案
```python
action = code_harness.propose_action(obs) # 完全由代码决定动作
return action # 根本不需要 LLM
```
类比:你直接写了一个规则引擎/算法来玩游戏LLM 只在"开发阶段"用来写这个算法。运行时零 LLM 调用,零成本。
---
## 核心方法:怎么让 LLM 自动写出 Harness
这是论文最核心的技术贡献。如果你熟悉 GRPO你可以把这个过程理解为用环境反馈来优化代码而不是优化模型权重。
### 整体流程
```
1. 初始化LLM 写一版 harness 代码propose_action + is_legal_action
2. 测试:用这个代码在游戏环境里跑 rollout
3. 评估:记录哪些动作被判为非法,收集错误信息
4. 反馈:把错误信息喂给 LLMCritic 模块整理错误)
5. 优化LLM 基于错误反馈生成改进版代码Refiner 模块)
6. 重复 2-5直到合法率达到 100% 或超时
```
### 和 GRPO 的对比
| 维度 | GRPO | AutoHarness |
|------|------|-------------|
| 优化的对象 | 模型权重 θ | 代码文本(程序) |
| 搜索空间 | 参数空间(连续) | 程序空间(离散) |
| 反馈信号 | reward标量 | 执行反馈(错误日志+reward |
| 优化方法 | 梯度下降 | LLM 当"突变算子"改代码 |
| 探索策略 | 采样多个 response 对比 | Thompson sampling 做 tree search |
| 类比 | 调参让模型更好 | 让 AI 写更好的代码 |
**关键区别**GRPO 改的是模型内部的权重AutoHarness 改的是模型外部的代码。一个改"大脑",一个改"工具"。
### Tree Search + Thompson Sampling
#### 为什么要用 Tree Search
简单的迭代优化(写代码 → 测试 → 改代码 → 测试…)有个问题:容易陷入局部最优。比如 LLM 沿着一个思路改了 5 版代码,发现这个方向走不通了,但已经回不去了。
Tree search 的思路是:同时维护多个版本的代码,像一棵树一样分叉发展。
```
初始代码 v0
/ \
v1a v1b ← 两个不同的改进方向
/ \ |
v2a v2b v2c ← 继续分叉
|
v3a ← 这个方向成功了合法率100%
```
#### Thompson Sampling 是什么?
你面对这棵树上的多个节点,每次迭代应该选哪个节点来继续优化?这就是经典的 exploration-exploitation探索-利用)问题:
- **利用Exploitation**:选当前表现最好的代码版本继续改进
- **探索Exploration**:试试那些还没被充分优化的代码版本,也许潜力更大
Thompson sampling 是一种概率性的选择策略:
```
对每个节点:
1. 根据它历史的"合法率"数据建一个概率分布Beta 分布)
2. 从这个分布中随机采样一个值
3. 选采样值最高的节点来优化
效果:表现好的节点被选中的概率更高(利用),
但表现差的节点也有机会被选中(探索)
```
工程类比:这和你做 A/B testing 时的 Multi-Armed Bandit 问题几乎一模一样。Thompson sampling 就是一种 bandit 算法。
### Critic 和 Refiner 的分工
**Critic批评者**
- 输入rollout 中失败的步骤(最多 5 个)
- 工作:整理和归纳各种错误类型
- 输出:结构化的错误摘要
- 类比Code Review 时给你提 bug 的同事
**Refiner优化者**
- 输入:当前代码 + Critic 的错误摘要
- 工作:基于反馈生成改进版代码
- 输出:新版本的 harness 代码
- 类比:你根据 code review 意见改代码
一个关键细节:如果 `is_legal_action()` 返回 True 但环境说动作非法(漏判),则两个函数都要改;如果 `is_legal_action()` 返回 False 且动作确实非法(检查器工作正常,只是 `propose_action` 提出了错误动作),则只改 `propose_action()`。这个区分很重要,避免了"改了不该改的代码"。
---
## 实验结果解读
### 训练效率:多快能学会?
- 平均 **14.5 次迭代**就能学会(即 LLM 改代码 14.5 次)
- **19/32 个游戏**不到 10 次就搞定了
- 最难学的游戏GermanWhist43次、Chess64次、Othello62次
直觉理解:简单游戏(如猜数字、骰子)规则简单,几次就能写对检查器;复杂游戏(如国际象棋)规则多样(王车易位、吃过路兵等),需要更多轮迭代。
最终结果:**全部 145 个游戏都达到了 100% 合法动作率。**
### 双人游戏:小模型+Harness vs 大模型
| 对阵 | 我们的方法胜率 | 对手胜率 |
|------|--------------|----------|
| Flash+Harness vs Gemini-2.5-Pro | **56.3%** | 38.2% |
| Flash+Harness vs Flash原始 | **64.8%** | — |
这意味着什么?**一个小模型Flash配上自动生成的规则检查代码可以打败一个大几倍的模型Pro。**
---
## 核心启示
1. **"代码即策略"可能是 LLM Agent 的终局形态** — 让 LLM 写代码,然后运行时零 LLM 调用
2. **小模型+好代码 > 大模型裸跑** — 这打破了"模型越大越好"的迷信
3. **Program Synthesis + RL 的结合** — 这可能是下一代 AI 系统的核心范式
---
## 标签
#论文解读 #AutoHarness #LLM #Agent #ProgramSynthesis #GRPO #强化学习

29
InBox/CLIProxyAPI.md Normal file
View File

@@ -0,0 +1,29 @@
# CLIProxyAPI
**GitHub**: https://github.com/router-for-me/CLIProxyAPI
**添加时间**: 2026-03-24
**提醒时间**: 2026-03-25 10:00
**标签**: #代理 #CLI #工具
---
## 项目简介
(待补充 - 明天落实时填写)
## 主要功能
(待补充)
## 安装使用
(待补充)
## 备注
- 用户要求:无风险的情况下落实
- 提醒已设置明天3月25日10:00
---
**原始链接**: https://github.com/router-for-me/CLIProxyAPI

View File

@@ -0,0 +1,36 @@
# 大家有没有感觉最近大模型变笨了
**来源**: https://www.v2ex.com/t/1196441#reply25
**保存时间**: 2026-03-24
**标签**: #AI #大模型 #讨论
---
## 帖子摘要
楼主提问:大家有没有感觉最近大模型变笨了?
主要讨论点:
- 用户感觉 GPT-4、Claude 等大模型最近回复质量下降
- 有人认为是心理作用或期望值提高
- 也有人提到可能是模型更新导致的风格变化
- 讨论涉及多个主流大模型GPT-4、Claude、Gemini 等
---
## 关键回复观点
1. **心理作用论**: 用多了之后对模型能力边界更清楚,所以感觉"变笨"
2. **模型更新论**: OpenAI 等厂商确实会调整模型,可能影响某些任务的表现
3. **任务复杂度**: 随着使用深入,提出的问题更难,模型显得力不从心
4. **对比效应**: 新模型出来后,旧模型相对显得弱了
---
## 个人思考
(待补充)
---
**原始链接**: https://www.v2ex.com/t/1196441#reply25

View File

@@ -1,8 +0,0 @@
- 需要验证Editor preview
- 需要验证战斗
- 需要验证地图
- 需要验证行军线
- 前端表现
- android
- 性能分析

View File

@@ -0,0 +1,20 @@
---
title: 测试笔记 - 共享目录转移
date: 2026-03-20
tags: [测试, 共享目录]
---
# 测试笔记
这是一篇测试笔记,用于验证共享目录转移流程。
## 创建信息
- 创建时间: 2026-03-20 03:01
- 来源: Mac mini 共享目录
- 目标: zanepc Obsidian InBox
## 测试内容
如果这篇笔记能成功转移到 zanepc 的 Obsidian 中,说明流程配置正确。
---
*自动创建用于测试共享目录转移*