更多的是我在反思，让kimi看看它跟我的理念的差异，造成了一些不顺畅以及技术债务。

节选一下：

## 对 AI 的提示

在后续开发中，当遇到以下信号时，应主动质疑而不是默认实现：

1. 某个功能不在 `ROADMAP.md`、设计文档或用户明确指令中

2. 功能的加入理由是 “xxx 软件也有”

3. 修复一个边缘 bug 需要引入复杂的条件分支

4. 功能在复杂架构下语义不清

5. 正在解决的问题与之前已解决的问题高度相似

6. 同一个模块/功能反复出现相似 bug

此时应优先向用户确认：

> “这个功能不在当前设计范围内，且边界较复杂。建议是 A) 简化实现 B) 直接删除 C) 排期设计。您的偏好是？”

当遇到实现困难时，应优先执行以下检查清单：

1. **搜索当前代码库**：是否有同一模块中已解决的相似问题？

2. **搜索历史修改记录**：CHANGELOG / git history 中是否有相关修复？

3. **查看原始参考**：`xxxxxx/` 原始 C++ 代码中是否有对应逻辑？

4. **检查可复用组件**：是否有公共函数、工具类、或已有模式可以直接套用？

5. 只有在上述四步都没有找到答案时，才允许从零实现。

**注意**：第 1-4 步的参考价值**高于**第 5 步中你可能想到的”通用最佳实践”。参考代码包含了本项目的具体约束和验证过的边界条件。

当脑海中浮现”我知道一个更好的方案”时，应问自己：

1. 这个”更好的方案”是**当前项目真正需要的**，还是**我知识库中恰好有的**？

2. 如果用一个简单方案实现 80% 的价值，**剩下 20% 是否值得引入额外的复杂度**？

3. 这个方案如果被证明过度设计，**是否容易拆除**？

4. 手头的参考代码（第三方源码或项目内已有实现）是否已经给出了**更适合当前约束的答案**？