2026年6月27日星期六2026 年 6 月 27 日
- 重新阅读了 26 日编写的 docs/roadmaps/2026-06-26-source-to-ast-input-flow.md，判断整篇文档的一致性不足
- 最初编写的 27 日文档包含大量对象说明和结构说明，实际追踪输入流向困难
- 根据后续 PR 反馈重新确定文档方向
- 将
# <相对路径> 展开的输入中，具体写明哪个文件的哪一行进入 AST Parser
- 如
player.gd 的 E020‑E034，依据实际行范围整理出该段正文如何通过 Retriever 检索并由 LLM 判断的流程
- 文件路径仅用于追踪，Retriever 检索时仅使用代码/正文片段的
chunkText，此规则重新固定
docs_chunks、api_mapping、label_prototypes 不作特殊处理，采用相同方式检索，由 LLM 再次验证搜索候选- 今日工作旨在在实际实现前，先通过文档固定输入与输出在何处以及如何衔接，防止 AI 任意更改范围或使用抽象结构说明
- 为验证文档中的流程，实现了
Source Flow Debugger Web 工具
- 在本地通过
http://127.0.0.1:8010/ 运行，直接查看 Godot 项目输入
- 将
# <相对路径> 展开的项目输入按文件拆分，.gd 视为 AST 类型的 chunk，.godot 与 .tscn 视为 direct chunk
- 在一个小型 Godot 项目中确认拆分为
5 files、14 chunks、AST 9、Direct 5
- 将类似 README.md 的文档文件排除在 source‑analysis 模式外，并在界面上显示排除的事实与原因
- 为每个 chunk 添加调试 UI
- 在每个 chunk 下方放置
docs_chunks 搜索、api_mapping 搜索、label_prototypes 搜索、Validate JSONL 按钮
- 采用在当前 chunk 直接下方执行表格搜索的方式，而非全局表格复选框
- Retriever 输入仅显示
{ "chunkText": "..." }，去除文件路径、行号、提示等信息
- Qwen 验证仅在
prompt + chunkText + retrieved JSONL 步骤中使用
- 在实际使用 Web 调试器时发现的问题并修复
- 移除页面加载时自动插入示例 Godot 代码的问题
- 即使同一文件/文件夹再次上传，仍通过在点击上传输入时清空其值，使浏览器
change 事件重新触发
- 为防止旧 JS 残留，在静态文件响应中加入
cache-control: no-store
- 在 PostgreSQL 搜索路径出现 client 创建/连接失败时，确保通过防御性调用
client.end() 使 cleanup 安全执行
- 将实现结果以截图形式另存为文档
- 以当前进度来看，已基本成功完成 chunk 级别的拆分，接下来重点是实际执行 DB 检索的方式
- 需要仅凭
chunkText 确认 docs_chunks、api_mapping、label_prototypes 中返回的 JSONL 候选
- 在 Qwen 验证阶段判断检索到的 JSONL 是否与当前 chunk 相关，并决定是否舍弃
- 在接入 DB 检索前，使用 GPT 生成了与 Godot chunk 相关/无关的示例 JSONL，实验匹配提示词
- 最初提问 “这条 JSONL 是否包含源码对应的内容，请仅回答 是/否”，结果相关和无关的 JSONL 都返回 “是”
- 随后限定只有
source_api、source_pattern、match_terms、required_when_seen_in_code、before_code 中的任意一项与实际 SOURCE_CODE 字符串/API 调用完全匹配时才返回 “是”
- 不再依赖宽泛的词义相似或 LLM 对 Godot 的先验知识，只看 JSONL 中的字符串依据：相关 JSONL 为 “是”，无关 JSONL 为 “否”
- 通过此实验得到的结论是，DB 检索后的 Qwen 验证阶段应先判断 “检索到的 JSONL 中是否存在直接匹配当前 chunk 的字符串依据”，而非仅凭“似是而非的语义相似度”
- 观察日志: 基于 JSONL 收集现状的测试仓库选择观察日志
- 观察日志: JSONL 依据匹配提示词观察
- 回顾: docs/retrospectives/2026-06-27.md
- 明日计划制作多个与 Godot chunk 相关/无关的 JSONL 示例集，反复测试 Qwen 基于何种依据给出 “是”/“否” 的判断
