# v6.3.15 AI 精确楼层回复 + 提示词相关性优化

## 现场问题 1：识别到了“好看”，但软件发成新的一级评论
截图已经证明：
- 原帖定位正常；
- 成员评论正文“好看”识别正常；
- DeepSeek可以生成文本；
- 发送结果却出现在帖子评论列表中作为频道主自己的一级评论，而不是回复“好看”这条评论。

根因是上一版的“双通道兜底”：
`do-reply` 失败或 comment_id 链不足时，会自动执行 `do-comment`。

这个策略保证了“能发出去”，但语义是错的。

## 本版修改：评论/回复绝不降级为一级评论

### 评论 / 回复 / 评论内@
以下情况只允许：
`feed do-reply`

包括：
- type 4 收到评论；
- type 5 收到回复；
- type 6 @发生在评论/回复楼层；
- 通知中已存在 comment_id / reply_id。

如果楼层链仍不完整：
- 不执行 do-comment；
- 本条保持 failed，可后续重试；
- 写 ai_reply_diagnostics.log；
- 界面明确提示“已阻止发布一级评论”。

### 只有直接@帖子
当 type 6 确认为直接发生在帖子本身、没有评论/回复链时，
才允许使用：
`feed do-comment`

这符合腾讯官方 feed-reference：
- do-comment = 评论帖子 / 回复帖子；
- do-reply = 回复已有评论或回复，必须有 comment_id。

## do-reply 参数改为运行时完整链

旧版为了规避 createTime 问题，把 do-reply 缩减成：
- feed_id
- feed_create_time
- comment_id
- reply_type
- content

某些 CLI/OIDB 版本需要更多上下文时会失败。

本版先完整补齐：
- guild_id
- channel_id
- feed_id
- feed_author_id
- feed_create_time
- comment_id
- comment_author_id
- comment_create_time
- target_reply_id
- target_user_id
- reply_type=1
- content

如果当前互动本身是楼中楼回复：
- incoming reply_id → target_reply_id
- incoming reply author_id → target_user_id

随后通过当前机器实时：
`tencent-channel-cli schema feed.do-reply`
过滤掉此CLI不支持的字段。

因为这是复杂链式操作，本版 do-reply 使用 stdin JSON，
避免 CLI flag 模式把没有对应 flag 的链式字段丢掉。

## 精确楼层验证
发送前必须：
- 找到 comment_id；
- get-feed-comments / get-next-page-replies 能验证该评论/回复链；
- `reply_target_verified=1`。

验证失败宁可不发，也不会再发错楼层。

## 现场问题 2：“好看”被回复成万能客服话术

旧提示词只有：
“自然、友好、简洁地回复”。

对模型约束太弱，所以 DeepSeek可能把任何互动生成成：
“我在呢！看到你的消息啦，有什么想聊的……”

## 内置不可覆盖提示词
现在运行时始终增加一层固定 system prompt：
1. 第一优先级回应成员刚刚说的原话；
2. 原帖只作上下文，不能替代成员原话；
3. “好看/不错/喜欢/666/支持”等短评必须短回复；
4. 禁止“我在呢/看到你的消息/有什么想聊的/需要帮忙吗”等客服万能开场；
5. 具体问题直接回答；
6. 短互动通常10~50字；
7. 不自我介绍、不说AI、不编造。

例：
成员：“好看”
合理输出：
“谢谢喜欢～这次展示能让你觉得好看就很开心啦！”

运营者在界面里填写的系统提示词现在只控制语气和风格，
不能覆盖“必须紧扣成员原话”的固定规则。

DeepSeek仍通过官方 Chat Completions system + user messages调用。

## 热更新
- VERSION继续 v6.3.15。
- app/updater.py / make_update_package.py / bootstrap.py /
  licensing / license_public_key / 构建脚本保持指定 v6.3.12 原文件字节级不变。
