Merge branch 'master' of https://gitee.com/zzzisfunnyboy/obsidian-notes
# Conflicts: # .obsidian/appearance.json
This commit is contained in:
Zane
12
.gitignore
vendored
Normal file
12
.gitignore
vendored
Normal 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
|
||||
2
.obsidian/appearance.json
vendored
2
.obsidian/appearance.json
vendored
@@ -2,7 +2,7 @@
|
||||
"accentColor": "",
|
||||
"theme": "obsidian",
|
||||
"cssTheme": "Zen",
|
||||
"textFontFamily": "Microsoft YaHei",
|
||||
"textFontFamily": "霞鹜文楷,Microsoft YaHei",
|
||||
"interfaceFontFamily": "Microsoft YaHei UI",
|
||||
"baseFontSize": 17
|
||||
}
|
||||
136
.obsidian/workspace.json
vendored
136
.obsidian/workspace.json
vendored
@@ -4,16 +4,16 @@
|
||||
"type": "split",
|
||||
"children": [
|
||||
{
|
||||
"id": "1538f6ad5b15def5",
|
||||
"id": "4463cbe9dee439a2",
|
||||
"type": "tabs",
|
||||
"children": [
|
||||
{
|
||||
"id": "afc535d48add9e90",
|
||||
"id": "bf4a47cd3f5340ef",
|
||||
"type": "leaf",
|
||||
"state": {
|
||||
"type": "markdown",
|
||||
"state": {
|
||||
"file": "2Areas/游戏开发/pcei速度预估.md",
|
||||
"file": "1Project/大富翁Demo/关于AI/离全自动发起PR有多远.md",
|
||||
"mode": "source",
|
||||
"source": false,
|
||||
"backlinks": true,
|
||||
@@ -28,7 +28,7 @@
|
||||
}
|
||||
},
|
||||
"icon": "lucide-file",
|
||||
"title": "pcei速度预估"
|
||||
"title": "离全自动发起PR有多远"
|
||||
}
|
||||
}
|
||||
]
|
||||
@@ -101,23 +101,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 +127,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 +160,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": "bf4a47cd3f5340ef",
|
||||
"lastOpenFiles": [
|
||||
"2Areas/游戏开发/索引.md",
|
||||
"skills/obsidian-markdown/SKILL.md",
|
||||
"skills/obsidian-bases/SKILL.md",
|
||||
"skills/json-canvas/SKILL.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/大富翁Demo/关于AI/护栏与AI.md",
|
||||
"1Project/大富翁Demo/关于AI/离全自动发起PR有多远.md",
|
||||
"笔记数据库.base",
|
||||
"1Project/大富翁Demo/关于AI",
|
||||
"1Project/大富翁Demo",
|
||||
"未命名 1.base",
|
||||
"未命名.base",
|
||||
"卡片数据库.base",
|
||||
"卡片盒skill.md",
|
||||
"查询数据skill.md",
|
||||
"00-Home.md",
|
||||
"copilot-custom-prompts/Remove URLs.md",
|
||||
"copilot-custom-prompts/Make shorter.md",
|
||||
"copilot-custom-prompts/Explain like I am 5.md",
|
||||
"copilot-custom-prompts/Emojify.md",
|
||||
"1Project/GPU地形/地形优化.md",
|
||||
"1Project/理财.md",
|
||||
"1Project/GPU地形/Houdini PCG.md",
|
||||
"1Project/GPU地形/GPU地形-目录.md",
|
||||
"1Project/GPU地形/GPU Driven Terrain 跟学与实现.md",
|
||||
"渲染/软渲染/图片/9702b7cbafa93d6e3d0cd59e7cf37e31.png",
|
||||
"渲染/软渲染/图片/86aa46af36c4c3b1f1efef2a1ccc6310.png",
|
||||
"渲染/软渲染/图片/62ad22d3e981954fc083018fb850413a.png",
|
||||
"渲染/软渲染/图片/23d61a2b7376ea3149d74d6bd4ea9430.png",
|
||||
"2Areas/年度复盘/2025.md",
|
||||
"1Project/ZYGame/州府前端流程.md",
|
||||
"1Project/GPU地形/ComputeShader生成无限世界地形.md",
|
||||
"1Project/海量渲染战斗/批量渲染gpu动画.md",
|
||||
"1Project/外包/Project_城堡/_城堡.md",
|
||||
"1Project/海量渲染战斗/基于GPU蒙皮动画的Spine实现.md",
|
||||
"1Project/海量渲染战斗/基于GPU动画和ComputeShader的大批量动画渲染Demo（一）之GPU顶点动画.md",
|
||||
"1Project/海量渲染战斗/海量渲染战斗-目录.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地形",
|
||||
"1Project/海量渲染战斗/GPU动画工程/GPU蒙皮动画.md",
|
||||
"1Project/海量渲染战斗/GPU动画工程/GPU顶点动画.md",
|
||||
"skills/obsidian-markdown",
|
||||
"skills/obsidian-bases",
|
||||
"skills/json-canvas",
|
||||
"skills",
|
||||
"渲染/软渲染/图片/9702b7cbafa93d6e3d0cd59e7cf37e31.png",
|
||||
"渲染/软渲染/图片/86aa46af36c4c3b1f1efef2a1ccc6310.png",
|
||||
"渲染/软渲染/图片/62ad22d3e981954fc083018fb850413a.png",
|
||||
"渲染/软渲染/图片/23d61a2b7376ea3149d74d6bd4ea9430.png",
|
||||
"wallhaven-rq75r7.jpg",
|
||||
"1Project/构建新框架/管道模式/未命名.canvas",
|
||||
"2Areas/如何记录笔记/P.A.R.A/Pasted image 20250614192838.png",
|
||||
|
||||
11
00-Home.md
11
00-Home.md
@@ -1,11 +0,0 @@
|
||||
# Home
|
||||
|
||||
## 入口
|
||||
- [[InBox/InBox-目录]]
|
||||
- [[1Project/项目-目录]]
|
||||
- [[2Areas/领域-目录]]
|
||||
- [[3Resources/资源-目录]]
|
||||
- [[4Archives/归档-目录]]
|
||||
|
||||
## 常用目录
|
||||
- [[3Resources/游戏开发/性能优化/性能优化-目录]]
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- 带宽
|
||||
- 优化
|
||||
---
|
||||
|
||||
|
||||
### 优化带宽(减少储存数据量
|
||||
- 一块地形为128个三角形，每个三角形包含三个位置
|
||||
- 每个位置包含位置Vec3,法线Vec3,UV Vec2
|
||||
|
||||
@@ -1,5 +0,0 @@
|
||||
- 参考表的内容
|
||||
- 地图格子该长什么样，需要什么图标显示吗
|
||||
- 世界事件对应的实现需要策划案
|
||||
- 政务系统
|
||||
- 人力怎么来，需要怎么做
|
||||
@@ -1,13 +0,0 @@
|
||||
### 养成界面
|
||||
- 需要重写SlotViewModel，这中间处理建筑的各种状态（升级中，普通，空闲无建筑）
|
||||
- 区域选择界面
|
||||
- 建筑背包
|
||||
- 生产详情
|
||||
- 建筑详情页面
|
||||
- 背包
|
||||
- 英雄
|
||||
- 兵种
|
||||
|
||||
### 地图
|
||||
- 程序自动拼接不同区域
|
||||
- 区域中不同节点
|
||||
@@ -1 +0,0 @@
|
||||
- 每个兵种允许装备最多一种武器和两种通用饰品
|
||||
@@ -1,36 +0,0 @@
|
||||
|
||||
|
||||
# 地图性质说明
|
||||
- 鏖战：
|
||||
- 通常是战场性质的地图。战场重视的是人力、装备资源、战略地区，主要的交互方式是创建军队参与战斗。战斗本身有一定收益，但随着次数增加收益降低，如果支持的军队获胜，还会得到更高收益
|
||||
- 幻影：
|
||||
- 幻境地图。游戏内的地块被区分为多种多样的区域，不同的区域有不同类型的怪物，也会获得不同类型的收益
|
||||
- 天灾：
|
||||
- 世界上会不定期生成天灾军，击败后得到一定数值的天灾点。天灾军越强荣誉点越强。可以在地图中央使用天灾点购买道具
|
||||
- 轻灵：
|
||||
- 地图分为自由、神秘、宝藏3个区域。自由区每隔一段时间回血。神秘区有额外战利品加成。宝藏区可以得到神器碎片和神级角色信物
|
||||
- 秩序：
|
||||
- 地图内有一个完整的秩序，有商人区、魔物区和平民区，可以实现招募、打金、交易等一系列行为
|
||||
- 神庙：
|
||||
- 地图核心位置有一个宗教神庙，包含一个信仰的神明。可以选择信奉神明驱逐异端，也可以选择信奉恶魔驱逐信徒
|
||||
- 瘟疫：
|
||||
- 开始是正常的，后来会有瘟疫恶鬼不断出现，可以携带特定装备大幅降低恶鬼生命，或者清理一片区域的恶鬼。灵魂和圣女在这个世界有额外加成
|
||||
|
||||
# 需要的功能
|
||||
- A\*寻路
|
||||
- 格子地图
|
||||
- 编辑器：地图大小，地图图片，事件自定义，CommandBuffer定义格子，点击生成方块
|
||||
- 模式：自动战斗，回合制
|
||||
- 进入地图需要迷雾系统
|
||||
- 鼠标悬停地图点位需要提示
|
||||
- 怪物说明
|
||||
- 战斗次数
|
||||
- 点位奖励等级
|
||||
- 奖励类型
|
||||
|
||||
# 事件
|
||||
- [[战斗系统]]
|
||||
- 暗雷战斗和地块战斗的战斗时间，概率分别为5%和10%。
|
||||
- 选择奖励
|
||||
- 仪式：献祭物品可以进入独立的小地图
|
||||
- 拜访：拜访一位未解锁的随机名人
|
||||
@@ -1,20 +0,0 @@
|
||||
---
|
||||
tags:
|
||||
- 城堡
|
||||
- 外包
|
||||
- 目录
|
||||
- MOC
|
||||
---
|
||||
|
||||
- [[_城堡]]
|
||||
- [[QA]]
|
||||
- [[事件系统]]
|
||||
- [[兵种系统]]
|
||||
- [[地图系统]]
|
||||
- [[城堡政务系统]]
|
||||
- [[家园界面]]
|
||||
- [[属性系统]]
|
||||
- [[战斗系统]]
|
||||
- [[抽卡系统]]
|
||||
- [[背包系统]]
|
||||
|
||||
@@ -1,25 +0,0 @@
|
||||
# 建筑工厂
|
||||
- 仅仅作为功能的开放
|
||||
- 有条件限制，需要条件系统
|
||||
- 解锁后，部分建筑需要消耗资源才可以建造
|
||||
- 未解锁，仅仅显示名称，并被解锁条件遮盖
|
||||
- 初始拥有农场
|
||||
|
||||
|
||||
# 工厂经营
|
||||
- 食物消耗
|
||||
- 规则
|
||||
- 任何建筑开始工作时(农场除外)，每个人力 消耗每秒0.1单位粮食
|
||||
- 城堡随着时间消耗粮食,每位居民，每隔60s需要消耗1单位粮食
|
||||
- 当粮食为0时，出现部分居民无法获得粮食，这部分居民拒绝交税。
|
||||
- 粮食每消耗少消耗1单位，居民缴纳的金币-1
|
||||
- 居民每消耗1单位粮食，缴纳1金币
|
||||
|
||||
# 事件
|
||||
- 当玩家在城堡界面中 && “政务处理” 开启时
|
||||
- 按照一定的速率生成随机事件
|
||||
- 事件
|
||||
- 随机
|
||||
- 只要城堡满足该数据
|
||||
- 条件
|
||||
- 需要特定条件满足后触发，且仅触发一次
|
||||
@@ -1,4 +0,0 @@
|
||||
- 区分区域，不同的区域都有市中心
|
||||
- 建筑背包
|
||||
- 建筑空地
|
||||
- 建造
|
||||
@@ -1,8 +0,0 @@
|
||||
- 兵种属性/装备属性：
|
||||
- 力量
|
||||
- 防御
|
||||
- 生命
|
||||
- 运气
|
||||
- 技能
|
||||
- 神性
|
||||
- 信念
|
||||
@@ -1,3 +0,0 @@
|
||||
- 回合制
|
||||
- 规则
|
||||
- 按照速度排序出手顺序
|
||||
@@ -1,3 +0,0 @@
|
||||
- 概率和内容需要配置
|
||||
- 内容
|
||||
- 材料
|
||||
@@ -1,23 +0,0 @@
|
||||
# 道具类型
|
||||
- 材料
|
||||
- 食物
|
||||
- 消耗品
|
||||
- 装备
|
||||
- 灵珠
|
||||
- 特殊道具
|
||||
|
||||
**需要一批材料、食物、消耗品的预设**
|
||||
|
||||
# 字段
|
||||
- Id
|
||||
- uId
|
||||
- ItemType
|
||||
- 材料
|
||||
- 食物
|
||||
- 消耗品
|
||||
- userType
|
||||
- 装备
|
||||
- [[属性系统]]
|
||||
- 灵珠
|
||||
- 特殊道具
|
||||
|
||||
24
1Project/大富翁Demo/关于AI/护栏与AI.md
Normal file
24
1Project/大富翁Demo/关于AI/护栏与AI.md
Normal file
@@ -0,0 +1,24 @@
|
||||
---
|
||||
tags:
|
||||
- AI
|
||||
---
|
||||
## 理想的AI编码流程
|
||||
- 策划发起需求
|
||||
- AI理解需求
|
||||
- harness工程执行
|
||||
- AI Review
|
||||
- 是否与需求对齐
|
||||
- 六大基本原则
|
||||
- hook发起PR
|
||||
- 经过CI
|
||||
- 编译门禁
|
||||
- 核心流程门禁
|
||||
- AirTest跑最主要的流程
|
||||
- 模块单例测试门禁
|
||||
- 异步与状态门禁
|
||||
|
||||
### 可验证是AI提高代码正确率的关键
|
||||
- AirTest编写最主要的几条流程作为验证
|
||||
- 是否可以正确投掷
|
||||
- 进行一轮跑测
|
||||
- error日志
|
||||
7
1Project/大富翁Demo/关于AI/离全自动发起PR有多远.md
Normal file
7
1Project/大富翁Demo/关于AI/离全自动发起PR有多远.md
Normal file
@@ -0,0 +1,7 @@
|
||||
|
||||
###
|
||||
根据[[护栏与AI]]的流程，我还需要做
|
||||
- 云端部署harness
|
||||
- 围栏的搭建
|
||||
- AirTest的案例编写
|
||||
|
||||
@@ -1,9 +0,0 @@
|
||||
---
|
||||
tags:
|
||||
- MVVM
|
||||
- 目录
|
||||
- MOC
|
||||
---
|
||||
|
||||
- [[欠缺内容]]
|
||||
|
||||
@@ -1,34 +0,0 @@
|
||||
|
||||
---
|
||||
- [ ] <span style="color:rgb(202, 104, 118)">扩展嵌套列表</span>
|
||||
- [x] 列表优化添加 移除
|
||||
- [ ] 自定义嵌套列表的事件
|
||||
- [x] 绑定View-ViewModel的报错
|
||||
- 优化V和VM的绑定
|
||||
---
|
||||
- [x] M和VM的事件通知
|
||||
- ~~在用的时候可以用别的事件系统，接入Event~~
|
||||
---
|
||||
- [x] 设置Active标签
|
||||
---
|
||||
- [x] bool值回调除了toggle另外的组件怎么处理
|
||||
- ~~通过特性ValueChanged解决~~
|
||||
- ~~需要将现有组件重新封装一次~~
|
||||
- ~~bool值回调就可以根据IValueChanged接口来实现了~~
|
||||
- ~~~~~IValueChanged\<string\>~~~~~
|
||||
- ~~Text : IValueChanged\<string\>~~
|
||||
- ~~IValueChanged\<bool\>~~
|
||||
---
|
||||
- [ ] Inject添加ScopeId的参数
|
||||
---
|
||||
- 池子接入应该更方便一点，
|
||||
- 现在的情况每种泛型都需要Register
|
||||
---
|
||||
- OnValueChanged太过麻烦
|
||||
- ToggleGroup选择改变的时候View没有对应的监听，想要监听必须new一个组件出来，或者直接绑定ViewModel的PropertyChanged的方法
|
||||
---
|
||||
- ~~toggle监听的方式为interface = bool，选中之后不可取消~~
|
||||
---
|
||||
- 缺少Panel SubPanel 普通View的分类
|
||||
- subPanel需要有Activatable的回调
|
||||
- 提前挂载在场景上的View无法触发OnShow
|
||||
@@ -1,5 +1,9 @@
|
||||
---
|
||||
原文发布链接: https://zhuanlan.zhihu.com/p/18503608013
|
||||
tags:
|
||||
- GPU动画
|
||||
- ComputeShader
|
||||
- 顶点动画
|
||||
---
|
||||
- GPU蒙皮动画 https://zhuanlan.zhihu.com/p/574550709
|
||||
- Unity实现GPU动画 https://zhuanlan.zhihu.com/p/690695496
|
||||
@@ -1 +1,8 @@
|
||||
[[基于GPU动画和ComputeShader的大批量动画渲染Demo（一）之GPU顶点动画]]
|
||||
---
|
||||
tags:
|
||||
- GPU蒙皮动画
|
||||
- Spine
|
||||
原文发布链接: "[[基于GPU动画和ComputeShader的大批量动画渲染Demo（一）之GPU顶点动画]]"
|
||||
---
|
||||
|
||||
|
||||
|
||||
@@ -1,3 +1,9 @@
|
||||
---
|
||||
tags:
|
||||
- gpu动画
|
||||
---
|
||||
|
||||
|
||||
- 通过[[GPU动画]]，将Clip（每个顶点每帧的位置）烘焙到一张图片上去。
|
||||
- 用shader做顶点偏移，片元着色还是原来物体上的
|
||||
|
||||
|
||||
@@ -1,4 +1,9 @@
|
||||
# AABB
|
||||
## SAP算法
|
||||
这是一种先用扫描线扫描单条轴有无碰撞的快筛算法
|
||||
- 假设一个2D项目
|
||||
- 如果xa(min,max)与xb(min,max)在x轴没有交集，那么y就无再扫描，直接排除
|
||||
- y轴也是同理
|
||||
|
||||
# SAT 分离轴定理
|
||||
|
||||
|
||||
81
InBox/AGENTS.md_待看.md
Normal file
81
InBox/AGENTS.md_待看.md
Normal file
@@ -0,0 +1,81 @@
|
||||
# 在实际工作流中验证了四个月并可跨 project 复用的 AGENTS.md
|
||||
|
||||
**来源**: [知乎](https://zhuanlan.zhihu.com/p/2009629370684306095)
|
||||
**收录时间**: 2026-04-09
|
||||
**标签**: #Agent #代码规范 #项目管理
|
||||
|
||||
---
|
||||
|
||||
## 文档写作原则：Self-Contained（自解释）
|
||||
|
||||
所有文档（PROGRESS.md、STATES.md、EXPERIMENTS.md、TODO.md）必须做到**只读文档就能完全理解**，不依赖对话上下文或任何脑内默认知识。
|
||||
|
||||
### 核心要求
|
||||
|
||||
1. **每个方法首次出现时必须解释它是什么、怎么做的**。不能只写"方法 A 效果好"，必须写"方法 A（用因果卷积在 MLP 打分前丰富 token 特征，让 gate 感知邻居信息）效果好"
|
||||
|
||||
2. **不要假设读者知道任何缩写**。首次使用缩写时必须给出全称和一句话解释。例如不要写"STE"，要写"STE（Straight-Through Estimator，前向用 hard 0/1 掩码，反向用 sigmoid 梯度近似）"
|
||||
|
||||
3. **实验结论必须包含足够上下文**。不要写"差距缩小到 0.001"，要写"TopK 自适应选择与 Fixed 周期掩码的质量差距从 0.005 缩小到 0.001（提高 gate 学习率从 0.001 到 0.1）"
|
||||
|
||||
4. **数字必须有参照物**。不要写"val_bpb=0.8605"，要写"val_bpb=0.8605（对比：无加速 baseline=0.840，Fixed 周期掩码=0.8605）"
|
||||
|
||||
5. **因果链要完整**。不要只记录结论，要记录**为什么**。"TopK 不如 Fixed"不够，要写"TopK 不如 Fixed，因为 TopK 的 think token 48% 紧挨着聚集（间距=1），导致部分 skip token 的信息供给不足（信息瓶颈），而 Fixed 均匀间隔保证每个 think token 只需支撑 2 个 skip token"
|
||||
|
||||
6. **docs/STATES.md 顶部维护一个术语表**，所有关键术语集中定义。其他文档开头引用该术语表即可
|
||||
|
||||
### 反面例子（禁止）
|
||||
- "V11 实验效果不错" → 什么是 V11？做了什么？效果不错是多少？
|
||||
- "提高了 gate LR" → 从多少到多少？为什么要提高？效果改善了多少？
|
||||
- "信息瓶颈是核心问题" → 什么信息？什么瓶颈？为什么是核心？
|
||||
|
||||
### 正面例子（要求）
|
||||
- "TopKConvGate 实验（在 MLP 打分前用 768 通道因果深度卷积让每个 token 看到前 7 个邻居的特征，帮助 gate 感知局部上下文以减少 think token 聚集）：E4T4D4 架构下 5k 步 val_bpb=0.8610，仍略差于 Fixed 周期掩码(0.8605)，差距 0.0005"
|
||||
|
||||
---
|
||||
|
||||
## 项目管理工作流
|
||||
|
||||
### 文档维护规范
|
||||
|
||||
**docs/PROGRESS.md**: 只记录"已经完成"的工作/实验/结论（附关键脚本/日志/ckpt 路径），不要写待办计划。
|
||||
|
||||
**docs/TODO.md**: 只记录"未完成/进行中/下一步"的待办与计划（尽量可一键复现）；完成后从 docs/TODO.md 移除对应项，并把结果写入 docs/PROGRESS.md（避免重复记录）。
|
||||
|
||||
**docs/STATES.md**: 只维护已经完成的成果，录入真正长期有用的东西而非临时的噪音。
|
||||
|
||||
**docs/EXPERIMENTS.md**: 实验相关内容的特殊STATE，专注于处理实验和数据。
|
||||
|
||||
### 关键原则
|
||||
|
||||
- 能用小数据集/短实验快速 debug 就不要用大数据集/长实验；优先最快迭代
|
||||
- 每次准备做实验前必须先高层质疑与方向审视确认当前未知/最小实验/失败后下一步
|
||||
- 两个文档都必须按时间升序记录（越早在前、越晚在后），新增内容只能追加到文件末尾
|
||||
- 训练评测时只要是正式实验，一定要在正规文件里弄好脚本然后一键几乎无传参地跑
|
||||
- 跑训练或评测必须在 tmux 里启动，避免中途断开导致任务退出
|
||||
- 时刻注意删掉没用的 checkpoint 等大文件，维护空间不爆炸
|
||||
- 有多个相同功能文件的时候，请把错误的冗余的全部都扔进 archive，只保留一个
|
||||
|
||||
### Git 提交规范
|
||||
|
||||
当完成一个完整功能或要进行破坏性改动时：
|
||||
```bash
|
||||
git add .
|
||||
git commit -m "描述"
|
||||
```
|
||||
|
||||
- 发现任何文档或代码有错误时，更新不要保留任何错误痕迹
|
||||
- 写了一个新版本的正确文件，请删掉错误版本的文件
|
||||
- 兼容性不要搞得那么好，不要 fallback
|
||||
- 同样的功能禁止有错误实现，并且只能有一个位置正确实现，禁止冗余
|
||||
|
||||
---
|
||||
|
||||
## 其他要点
|
||||
|
||||
- 跟我沟通请使用中文。任何的临时测试都请在 tmp 文件夹
|
||||
- 我们现在是在一个Docker环境里边，使用公共服务器的电脑。千万不要跟别的程序抢占GPU，这是绝对禁令
|
||||
- 想用 GPU 的时候用 nvidia-smi 查看空闲 GPU 然后精确加载空闲的
|
||||
- 你只要遇到问题就处理，遇到问题就处理，直到没有问题。不要问我顺序什么的
|
||||
- 有不清楚的先记下来跳过，所有探究实现路径全部卡住了再都通知我
|
||||
- 没用的东西放 archive/
|
||||
115
InBox/Agent上下文管理策略_待看.md
Normal file
115
InBox/Agent上下文管理策略_待看.md
Normal file
@@ -0,0 +1,115 @@
|
||||
# 万字长文解析Agent框架中的上下文管理策略
|
||||
|
||||
**来源**: [知乎](https://zhuanlan.zhihu.com/p/2012088406826562496)
|
||||
**收录时间**: 2026-04-09
|
||||
**标签**: #Agent #上下文管理 #LLM #ClaudeCode
|
||||
|
||||
---
|
||||
|
||||
## 0x00. 写在前面
|
||||
|
||||
今年春节前后，至少9家国内的厂商密集地发布了他们旗舰版本的模型（比如GLM5、MiniMaxM2.5、Qwen3.5），可以发现大模型领域的竞争焦点从通用能力转向了Agent落地、编程能力这两大方向。
|
||||
|
||||
随着Claude Code、OpenClaw等Agent Scaffold的爆火，各大厂商也纷纷将自己的定位锁定在Agentic Engineering上，从"chatbots that respond" 转向 "agents that act"。
|
||||
|
||||
---
|
||||
|
||||
## 0x01. 背景
|
||||
|
||||
### （1）什么叫上下文工程（Context Engineering）？
|
||||
|
||||
"上下文工程"简单来说，就是在一些LLM的约束下（如上下文窗口大小、注意力长度的限制），优化上下文token的效用，从而持续获得理想输出的工程实践。
|
||||
|
||||
一个好的context engineering追求用最少的、信号最强的token集合，最大化期望输出的概率。
|
||||
|
||||
如果说之前早期的"Prompt Engineering"适用于单轮文本生成任务；那么"Context Engineering"就适用于需要多轮推理、长时间运行的智能体，需管理不断演变的上下文状态。
|
||||
|
||||
### （2）为什么Context Engineering对构建一个强大智能体来说至关重要？
|
||||
|
||||
Agent 每调用一次工具，就会返回一个工具的Observation，这个结果会被追加到聊天记录中。生产环境中的 Agent 可能会进行长达数百轮的对话，因此随着时间的推移，历史记录message会越来越长。
|
||||
|
||||
**上下文腐败（context rot）**：虽然现在的LLM能够接受越来越长的序列了，但它们和人类一样，会随着上下文增长而出现注意力涣散的现象，模型准确回忆信息的能力会下降，而且推理也会变慢。
|
||||
|
||||
导致这种现象的原因包括：
|
||||
- **注意力分散**：每个token都关注上下文中的所有其他token，形成了 n^2 级别的两两关系
|
||||
- **训练数据偏差**：模型在训练时接触的长序列远少于短序列
|
||||
- **位置编码插值**：可以让模型适应更长的序列，但通常会牺牲一定的精度
|
||||
|
||||
---
|
||||
|
||||
## 0x02. 上下文工程
|
||||
|
||||
### （1）上下文卸载与检索（Context Offload & Retrieval）
|
||||
|
||||
#### (a) 将上下文卸载到文件系统（紧凑化, Compaction）
|
||||
|
||||
Manus提出了一个核心理念：**将文件系统视为终极上下文**。这是因为文件系统天然具有无限容量、持久化、可随机访问的特性。
|
||||
|
||||
这种"可逆压缩"确保上下文长度缩减的同时，信息并未真正丢失——它们只是被卸载到文件系统中了，随时可以重新加载进来。
|
||||
|
||||
#### (b) 检索：推理前检索 vs "Just-in-time"检索
|
||||
|
||||
**RAG（Retrieval-Augmented Generation）**：预先对知识库的文本进行向量化，然后在推理前预先检索相关片段。
|
||||
|
||||
**Just-in-time检索**：让 LLM 自己生成搜索命令，像人类一样主动探索大文件或者代码库。
|
||||
|
||||
Claude Code 在处理大型的数据时，会生成一些复杂的 Bash 命令进行查询（如ripgrep、jq、find等），利用自己对代码的深刻理解，使用精细而复杂的正则表达式定位相关代码块。
|
||||
|
||||
### （2）上下文摘要(Context Summarization)
|
||||
|
||||
当上下文窗口即将被填满，且没有办法进一步做紧凑化的时候，我们不得不采用另一种手段：摘要化。这是一种有损压缩，它会将对话历史浓缩成一段摘要，从而释放空间。
|
||||
|
||||
**Claude Code的压缩流程**：
|
||||
- 自动触发：监控当前上下文的 token 使用量，接近上限时自动触发
|
||||
- 手动触发：用户可通过/compact命令主动执行压缩
|
||||
|
||||
摘要包含：主要请求和意图、关键技术概念、文件和代码段、错误和修复、问题解决、用户所有消息、待办任务、当前工作、可选下一步
|
||||
|
||||
### （3）上下文隔离（多智能体架构）
|
||||
|
||||
面对一个复杂的任务，我们可以将任务分解，然后由主智能体协调多个专门化的子智能体（sub-agents）来处理具体任务。
|
||||
|
||||
**多智能体架构的好处**：
|
||||
- **节省主Agent的上下文**：subagent的上下文和主agent是隔离的
|
||||
- **权限控制**：限制 subagent 可用的工具
|
||||
- **特定领域专业化**：为特定领域编写专门的系统提示
|
||||
- **节约调用成本**：可以把某些简单的任务路由到更快、更便宜的模型
|
||||
|
||||
**Claude Code的subagent分类**：
|
||||
- **Explore**：只读 agent，专门用于搜索和分析代码库（使用 Haiku）
|
||||
- **Plan**：负责理解代码库并进行规划（使用 Sonnet/Opus）
|
||||
- **General-Purpose**：全能型 agent（使用 Sonnet/Opus）
|
||||
|
||||
**运行模式**：
|
||||
- **前台运行模式**：subagent 运行时阻塞主对话，用户实时决定要不要accept操作
|
||||
- **后台运行模式**：subagent 在后台运行，启动前收集权限，运行中自动拒绝未批准的操作
|
||||
|
||||
**调用关系**：
|
||||
- **并行调用**：多个 subagent 同时独立运行
|
||||
- **链式调用**：多个 subagent 顺序执行，后一个依赖于前一个的输出
|
||||
|
||||
### （4）上下文缓存
|
||||
|
||||
**KV Cache（KV缓存）**：Transformer 模型在生成每个 token 时，需要计算所有之前 token 的Key和Value向量，用于注意力机制的计算，这些 KV 向量就构成了上下文的状态。KV Cache就是将这些中间计算结果保存下来，当后续请求包含相同的前缀时，可以直接复用。
|
||||
|
||||
**Prefill（预填充）**：只在生成第一个输出 token 之前，模型对所有输入 token 进行并行处理的阶段。
|
||||
|
||||
**为什么缓存对 agent 来说至关重要？**
|
||||
- Agent 的工作流程是多轮工具调用的重复
|
||||
- 平均Agent的输入输出 token 比高达 100:1
|
||||
- 以 Claude Sonnet 为例，缓存的输入 token 价格为 0.30 美元/百万 token，而未缓存的则高达 3 美元/百万 token，相差 10 倍！
|
||||
|
||||
**Claude Code的缓存策略**：
|
||||
- **核心原则**：上下文只追加，不修改
|
||||
- **自动缓存**：在请求顶层添加cache_control字段，系统自动将最后一个可缓存的内容块作为缓存断点
|
||||
- **手动缓存**：对稳定性极高的内容（如system prompt、工具定义）使用显式断点
|
||||
- 最多4个缓存断点（包括显式和自动缓存）
|
||||
|
||||
---
|
||||
|
||||
## 参考链接
|
||||
|
||||
- https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
|
||||
- https://minusx.ai/blog/decoding-claude-code/#21-use-claudemd-for-collaborating-on-user-context-and-preferences
|
||||
- https://manus.im/en/blog/Context-Engineering-for-AI-Agents-Lessons-from-Buliding-Manus
|
||||
- https://platform.claude.com/docs/
|
||||
215
InBox/AutoHarness-论文解读.md
Normal file
215
InBox/AutoHarness-论文解读.md
Normal 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. 反馈：把错误信息喂给 LLM（Critic 模块整理错误）
|
||||
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 次就搞定了
|
||||
- 最难学的游戏：GermanWhist（43次）、Chess（64次）、Othello（62次）
|
||||
|
||||
直觉理解：简单游戏（如猜数字、骰子）规则简单，几次就能写对检查器；复杂游戏（如国际象棋）规则多样（王车易位、吃过路兵等），需要更多轮迭代。
|
||||
|
||||
最终结果：**全部 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
29
InBox/CLIProxyAPI.md
Normal 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
|
||||
36
InBox/v2ex_1196441_大模型变笨讨论.md
Normal file
36
InBox/v2ex_1196441_大模型变笨讨论.md
Normal 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
|
||||
20
InBox/测试笔记_共享转移_20250320.md
Normal file
20
InBox/测试笔记_共享转移_20250320.md
Normal file
@@ -0,0 +1,20 @@
|
||||
---
|
||||
title: 测试笔记 - 共享目录转移
|
||||
date: 2026-03-20
|
||||
tags: [测试, 共享目录]
|
||||
---
|
||||
|
||||
# 测试笔记
|
||||
|
||||
这是一篇测试笔记，用于验证共享目录转移流程。
|
||||
|
||||
## 创建信息
|
||||
- 创建时间: 2026-03-20 03:01
|
||||
- 来源: Mac mini 共享目录
|
||||
- 目标: zanepc Obsidian InBox
|
||||
|
||||
## 测试内容
|
||||
如果这篇笔记能成功转移到 zanepc 的 Obsidian 中，说明流程配置正确。
|
||||
|
||||
---
|
||||
*自动创建用于测试共享目录转移*
|
||||
@@ -1,15 +0,0 @@
|
||||
---
|
||||
copilot-command-context-menu-enabled: true
|
||||
copilot-command-slash-enabled: false
|
||||
copilot-command-context-menu-order: 40
|
||||
copilot-command-model-key: ""
|
||||
copilot-command-last-used: 0
|
||||
---
|
||||
<instruction>Add relevant emojis to enhance the text below. Follow these rules:
|
||||
1. Insert emojis at natural breaks in the text
|
||||
2. Never place two emojis next to each other
|
||||
3. Keep all original text unchanged
|
||||
4. Choose emojis that match the context and tone
|
||||
Return only the emojified text.</instruction>
|
||||
|
||||
<text>{copilot-selection}</text>
|
||||
@@ -1,14 +0,0 @@
|
||||
---
|
||||
copilot-command-context-menu-enabled: false
|
||||
copilot-command-slash-enabled: false
|
||||
copilot-command-context-menu-order: 120
|
||||
copilot-command-model-key: ""
|
||||
copilot-command-last-used: 0
|
||||
---
|
||||
<instruction>Explain the text below in simple terms that a 5-year-old would understand:
|
||||
1. Use basic vocabulary
|
||||
2. Include simple analogies
|
||||
3. Break down complex concepts
|
||||
Return only the simplified explanation.</instruction>
|
||||
|
||||
<text>{copilot-selection}</text>
|
||||
@@ -1,10 +0,0 @@
|
||||
---
|
||||
copilot-command-context-menu-enabled: true
|
||||
copilot-command-slash-enabled: false
|
||||
copilot-command-context-menu-order: 0
|
||||
copilot-command-model-key: ""
|
||||
copilot-command-last-used: 0
|
||||
---
|
||||
<instruction>Fix the grammar and spelling of the text below. Preserve all formatting, line breaks, and special characters. Do not add or remove any content. Return only the corrected text.</instruction>
|
||||
|
||||
<text>{copilot-selection}</text>
|
||||
@@ -1,10 +0,0 @@
|
||||
---
|
||||
copilot-command-context-menu-enabled: false
|
||||
copilot-command-slash-enabled: false
|
||||
copilot-command-context-menu-order: 80
|
||||
copilot-command-model-key: ""
|
||||
copilot-command-last-used: 0
|
||||
---
|
||||
<instruction>Create a glossary of important terms, concepts, and phrases from the text below. Format each entry as "Term: Definition". Sort entries alphabetically. Return only the glossary.</instruction>
|
||||
|
||||
<text>{copilot-selection}</text>
|
||||
@@ -1,10 +0,0 @@
|
||||
---
|
||||
copilot-command-context-menu-enabled: false
|
||||
copilot-command-slash-enabled: false
|
||||
copilot-command-context-menu-order: 70
|
||||
copilot-command-model-key: ""
|
||||
copilot-command-last-used: 0
|
||||
---
|
||||
<instruction>Generate a hierarchical table of contents for the text below. Use appropriate heading levels (H1, H2, H3, etc.). Include page numbers if present. Return only the table of contents.</instruction>
|
||||
|
||||
<text>{copilot-selection}</text>
|
||||
@@ -1,14 +0,0 @@
|
||||
---
|
||||
copilot-command-context-menu-enabled: true
|
||||
copilot-command-slash-enabled: false
|
||||
copilot-command-context-menu-order: 60
|
||||
copilot-command-model-key: ""
|
||||
copilot-command-last-used: 0
|
||||
---
|
||||
<instruction>Expand the text below to twice its length by:
|
||||
1. Adding relevant details and examples
|
||||
2. Elaborating on key points
|
||||
3. Maintaining the original tone and style
|
||||
Return only the expanded text.</instruction>
|
||||
|
||||
<text>{copilot-selection}</text>
|
||||
@@ -1,14 +0,0 @@
|
||||
---
|
||||
copilot-command-context-menu-enabled: true
|
||||
copilot-command-slash-enabled: false
|
||||
copilot-command-context-menu-order: 50
|
||||
copilot-command-model-key: ""
|
||||
copilot-command-last-used: 0
|
||||
---
|
||||
<instruction>Reduce the text below to half its length while preserving these elements:
|
||||
1. Main ideas and key points
|
||||
2. Essential details
|
||||
3. Original tone and style
|
||||
Return only the shortened text.</instruction>
|
||||
|
||||
<text>{copilot-selection}</text>
|
||||
@@ -1,10 +0,0 @@
|
||||
---
|
||||
copilot-command-context-menu-enabled: false
|
||||
copilot-command-slash-enabled: false
|
||||
copilot-command-context-menu-order: 90
|
||||
copilot-command-model-key: ""
|
||||
copilot-command-last-used: 0
|
||||
---
|
||||
<instruction>Remove all URLs from the text below. Preserve all other content and formatting. URLs may be in various formats (http, https, www). Return only the text with URLs removed.</instruction>
|
||||
|
||||
<text>{copilot-selection}</text>
|
||||
@@ -1,14 +0,0 @@
|
||||
---
|
||||
copilot-command-context-menu-enabled: false
|
||||
copilot-command-slash-enabled: false
|
||||
copilot-command-context-menu-order: 130
|
||||
copilot-command-model-key: ""
|
||||
copilot-command-last-used: 0
|
||||
---
|
||||
<instruction>Transform the text below into a professional press release:
|
||||
1. Use formal, journalistic style
|
||||
2. Include headline and dateline
|
||||
3. Follow inverted pyramid structure
|
||||
Return only the press release format.</instruction>
|
||||
|
||||
<text>{copilot-selection}</text>
|
||||
@@ -1,20 +0,0 @@
|
||||
---
|
||||
copilot-command-context-menu-enabled: false
|
||||
copilot-command-slash-enabled: false
|
||||
copilot-command-context-menu-order: 110
|
||||
copilot-command-model-key: ""
|
||||
copilot-command-last-used: 0
|
||||
---
|
||||
<instruction>Convert the text below into a Twitter thread following these rules:
|
||||
1. Each tweet must be under 240 characters
|
||||
2. Start with "THREAD START" on its own line
|
||||
3. Separate tweets with "
|
||||
|
||||
---
|
||||
|
||||
"
|
||||
4. End with "THREAD END" on its own line
|
||||
5. Make content engaging and clear
|
||||
Return only the formatted thread.</instruction>
|
||||
|
||||
<text>{copilot-selection}</text>
|
||||
@@ -1,14 +0,0 @@
|
||||
---
|
||||
copilot-command-context-menu-enabled: false
|
||||
copilot-command-slash-enabled: false
|
||||
copilot-command-context-menu-order: 100
|
||||
copilot-command-model-key: ""
|
||||
copilot-command-last-used: 0
|
||||
---
|
||||
<instruction>Rewrite the text below as a single tweet with these requirements:
|
||||
1. Maximum 280 characters
|
||||
2. Use concise, impactful language
|
||||
3. Maintain the core message
|
||||
Return only the tweet text.</instruction>
|
||||
|
||||
<text>{copilot-selection}</text>
|
||||
@@ -1,10 +0,0 @@
|
||||
---
|
||||
copilot-command-context-menu-enabled: true
|
||||
copilot-command-slash-enabled: false
|
||||
copilot-command-context-menu-order: 30
|
||||
copilot-command-model-key: ""
|
||||
copilot-command-last-used: 0
|
||||
---
|
||||
<instruction>Simplify the text below to a 6th-grade reading level (ages 11-12). Use simple sentences, common words, and clear explanations. Maintain the original key concepts. Return only the simplified text.</instruction>
|
||||
|
||||
<text>{copilot-selection}</text>
|
||||
@@ -1,10 +0,0 @@
|
||||
---
|
||||
copilot-command-context-menu-enabled: true
|
||||
copilot-command-slash-enabled: false
|
||||
copilot-command-context-menu-order: 20
|
||||
copilot-command-model-key: ""
|
||||
copilot-command-last-used: 0
|
||||
---
|
||||
<instruction>Create a bullet-point summary of the text below. Each bullet point should capture a key point. Return only the bullet-point summary.</instruction>
|
||||
|
||||
<text>{copilot-selection}</text>
|
||||
@@ -1,14 +0,0 @@
|
||||
---
|
||||
copilot-command-context-menu-enabled: true
|
||||
copilot-command-slash-enabled: false
|
||||
copilot-command-context-menu-order: 10
|
||||
copilot-command-model-key: ""
|
||||
copilot-command-last-used: 0
|
||||
---
|
||||
<instruction>Translate the text below into Chinese:
|
||||
1. Preserve the meaning and tone
|
||||
2. Maintain appropriate cultural context
|
||||
3. Keep formatting and structure
|
||||
Return only the translated text.</instruction>
|
||||
|
||||
<text>{copilot-selection}</text>
|
||||
19
卡片数据库.base
19
卡片数据库.base
@@ -1,19 +0,0 @@
|
||||
views:
|
||||
- type: table
|
||||
name: 表格
|
||||
filters:
|
||||
and:
|
||||
- file.hasTag("性能优化")
|
||||
order:
|
||||
- file.name
|
||||
sort:
|
||||
- property: file.name
|
||||
direction: DESC
|
||||
- type: cards
|
||||
name: 视图
|
||||
filters:
|
||||
and:
|
||||
- file.hasTag("性能优化")
|
||||
cardSize: 150
|
||||
image: note.tags
|
||||
imageAspectRatio: 1.25
|
||||
Reference in New Issue
Block a user