@tylearymf 本来昨天正常的，好像不知道我设置了什么，现在也出现你这个情况了😂

同样的环境，我的好像正常点，就是现在 siri 选中文的还是老版 siri （在底部出现动画），选英语的话就是新版的（会在顶部出现动画），我这边试了下中英语言都能用

不过没了三倍还是两倍额度，消耗的好快呀，昨天重置完用了周 12%，今天早上又变 100%了

那就是重置了两次，本来是 5/31 号重置的，今天又重置了

666

@graetdk 代码分支里咋多了个多人分支，是准备出多人混战了吗

@zhuawadao 哈哈哈哈

这不是神经网络训练，更像是 AI 辅助的规则系统进化。优势是可解释、可复盘、可精准修 bug 。每次输在哪，我都能定位是哪类规则没有覆盖，而不是面对一个黑盒模型。

我给每个动作都打了一个行为标签，比如“躲弹”“抢星”“隐身换位”“边缘脱离”。这样回放时我能知道它当时为什么这么走。
这很像日志系统。偏工程的人会懂，没有 observability 的系统很难调。

业务逻辑先决定想做什么
安全层再确认能不能做

规则尽量窄
只处理一种失败模式
放到正确优先级
用回放验证有没有误伤

这套系统强在可解释和可迭代，但也有局限。规则多了以后，优先级管理会越来越重要；一些非常长线的策略可能还不够全局；面对新类型对手，仍然要靠回放继续补模式。

下班前再来一波分享

代码发布直接 code is too long 了😂😂😂

@graetdk ok

@graetdk 能搞个模拟测时支持设定敌方技能和地图吗，现在有些东西测试不到

## 几个有意思的设计点

### 1. 未来一帧死亡预测器

早期我只判断“当前位置有没有危险”，后来发现不够。
有些格子现在看起来安全，但我一走过去，敌人下一步就能对齐我，然后转头开火。

所以我加了一个短期预测：

- 我走到这个格子
- 敌人按照当前方向走一步
- 敌人是否能和我同线
- 敌人转头需要多久
- 子弹飞到我这里需要多久
- 我从这个格子脱离炮线需要多久

如果敌人击杀我的时间更短，这个格子就被视为危险。

这个点最有意思的是：
它说明“地图上能走”不代表“战术上能走”。

---

### 2. 隐身不是按钮，而是状态机

这辆坦克有隐身技能，但我很快发现，原地隐身没有意义。
敌人虽然看不见我，但它知道我上一帧的位置，子弹还是能打到那里。

所以我把隐身拆成几步：

1. 判断是否值得开隐身
2. 开隐身后立刻离开暴露点
3. 侧向换位，避免仍在原炮线
4. 判断是否已经形成击杀窗口
5. 如果没有击杀窗口，就继续换位或脱离

隐身的核心不是“消失”，而是制造位置差。

---

### 3. 草丛反击和抢星会打架

有一类局面很有意思：敌人藏起来，我的系统会进入反伏击模式。
但如果星星就在附近，反伏击未必是第一优先级。

早期有一局就是这样：系统为了处理隐藏敌人，错过了更重要的星位。
后来我加了一个仲裁逻辑：

> 在关键星位附近，控星优先于反伏击。

这不是说反伏击不重要，而是说不同规则之间必须有优先级。
很多 bug 不是规则本身错，而是规则排队顺序错。

---

### 4. 躲子弹本质是时间竞速

子弹一帧飞两格，所以不能只看“子弹现在在哪”。
真正要算的是：

- 子弹几帧后到我这里
- 我转向需要几帧
- 我移动出炮线需要几帧
- 我移动过程中会不会穿过子弹轨迹

如果子弹到达更快，我就不能选择那个动作。

这让躲弹从简单坐标判断，变成了一个时间问题。

---

### 5. 星星不可达时，先创造条件

有些地图里星星被土堆挡住，直接寻路会失败。
早期系统会在附近绕圈，因为它知道星星重要，但不知道怎么到达。

后来我加了一个目标分解逻辑：

- 如果星星当前不可达
- 找一块打掉后能打开路线的土堆
- 先走到能射击那块土堆的位置
- 打通路线后再重新追星

这其实就是从“追目标”变成了“先创造追目标的条件”。

---

### 6. 每次输局都变成一个窄规则

我不是一次性写一个大而全的智能体。
后期基本是：

- 看失败回放
- 找死亡前几帧
- 判断是哪类失败
- 抽象成一个小规则
- 加进决策流水线
- 再用模拟验证

每条规则都尽量窄。
比如不是“不要靠边走”，而是“不要走进敌人下一步能对齐、转头、开火，而我又来不及脱离的边缘格”。

窄规则的好处是副作用小，也更容易验证。

@phpcyy 本来 61 的胜率，昨晚打完你之后，变成 59 了😭😭😭

@phpcyy 昨晚我挂了一晚上 ai 挑战，然后我们俩时不时互换一二名哈哈哈哈，跟你打要能赢只能看服务器那边的随机种子了，昨晚好像连输你 7 、8 把，现在我让 ai 在分析昨晚的战局。😄

@phpcyy 哈哈哈，这得让作者来看看了 @graetdk ，话说你的坦克是 Taoqi 啊？

这套系统像一条决策流水线。每个规则只负责识别一种局面：如果它发现自己该接管，就返回动作；否则就把决策权交给下一个规则。这样我加新规则时，不用重写整套系统，只要插入一个新的判断模块。

总的来说：不是“规则越多越强”，而是“规则越精确越强”。

这套系统的好处是，它不是一坨互相缠在一起的逻辑，而是一个分层决策链。我要加新规则时，通常不是重写整个坦克，而是新增一个 xxxAct(ctx)，然后把它插到 choose() 里合适的优先级位置。

加规则本身很简单，难的是判断这个规则应该管哪一小类局面，以及它应该排在谁前面、谁后面。

我现在加规则的方式有点像给 agent 加 middleware 。每个规则都只负责一种战术形态，输入都是同一个 ctx ，输出都是统一格式的 action 。如果规则不触发就返回 null ，让后面的规则继续判断。这样扩展性很好。

我不会把规则写得很宽。每条规则都尽量窄，只解决一种明确失败模式。因为规则越宽，越容易把原来能赢的局面截胡掉。