diagnose-verify-fix

スター10

フォーク4

更新日2026年6月1日 02:09

用于 Quantia 仓库的"验证优先"诊断与修复工作流——当用户报告 bug、异常、生产日志报错、或要求"检查/审查当前修改是否引入新问题"时使用。强制：先证实问题真实存在并定位根因 → 评估多方案择优 → 修复 → 回归自检 → 本地/接口验证，最后才声明完成。覆盖生产日志（阿里云 115.29.213.22）根因定位、phase/文档一致性核对。纯新功能开发、纯查询/解释、用户已明确"直接改"时可跳过严格证实步骤。

インストール

Codex または Claude でインストールこの Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。

ソース

posbright

posbright/Quantia

GitHub リポジトリを開く Creator のリポジトリを見る

ダウンロード

诊断 → 验证 → 根因 → 择优 → 修复 → 回归（Quantia 验证优先工作流）

这是本仓库用户的签名工作流。几乎每次"修 bug / 检查改动 / 看日志"的请求都隐含这套要求，即使用户没逐条写出来，也要按此执行。

触发场景

"请帮我检查并验证…是否包含 bug / 引入了新问题"
"为啥…会失败 / 为啥结果是降级版"（贴图、贴日志）
"帮我修复服务器运行时的错误"（贴 *.log）
"当前修改是否合理 / 有没有不符合预期的行为"
"综合评估这几个方案…选最优" / "是否有更优解决方案"
进入下一个 phase 前的"再次审查确认无遗漏"

五步硬流程（不可跳步）

1. 证实问题真实存在（先别动手改）

复现：写最小复现（脚本 / 单测 / Invoke-RestMethod 黑盒调接口），或在代码里定位触发路径。
区分"用户以为的问题"与"真实问题"：用户常给现象（"结果是降级版""收益为 0"），根因可能在别处。
若无法复现 → 明确告知"当前无法复现"，列出已验证的点，再问用户补信息；不要猜测性地乱改。

2. 定位根因（root cause，不是症状）

顺数据流回溯：Fetch → MySQL/cache → Analysis job → Handler → 前端（见 AGENTS.md 规则 1 的管道边界）。
生产日志诊断（阿里云 115.29.213.22，库 instockdb）：
- 常看：quantia/log/stock_fetch.log / stock_error.log / refresh_ai_kb.log / kline_cache 相关。
- 读 Traceback 顶层异常 + 触发函数，再对应到本地源码；注意"数据源降级""OHLC 异常过滤""未找到命令"等高频根因。
- 日志是 Compute/Fetch 侧产物——分析时仍遵守管道分离，不在 handler 里加网络请求来"修日志"。
一句话写清根因（"X 因为 Y，触发于 Z"），让用户能确认。

3. 列方案 + 择优（用户偏好显式对比）

≥2 个可行方案时，列优缺点对比（正确性 / 副作用 / 性能 / 维护成本 / 与文档一致性）。
主动问一句"是否有更优解"再下结论——用户多次要求"再深入分析是否有更优方案"。
选最优且最合理的，不是最省事的。说明为什么不选其它。
与 document/*.md（特别是当前 phase 的开发计划）核对，确保方案不偏离需求。

4. 修复（最小、不外溢）

只改根因相关代码；不顺手重构、不加无关"改进"（见 AGENTS.md 实施纪律）。
改动若涉及后端常驻进程 → 走 restart-and-deploy skill 重启 + 黑盒接口验证（commit ≠ 生效）。

5. 回归自检 + 验证（声明完成前必做）

回归扫描：本次改动是否引入新 bug / 破坏既有行为？显式回答，别默认"应该没事"。
跑相关单测：python -m pytest tests/test_<相关>.py -q；改了多模块就跑相关多文件。
黑盒验证被改接口：Invoke-RestMethod 确认 200 + 预期字段（区间用 2026-03~05，2025 在生产 DB 为空）。
自定义策略相关改动：内置 vs custom_<id> 两条路径都验证（见 AGENTS.md Custom-strategy parity）。
只有 1-5 全过，才向用户报告"已修复/已验证"，并附验证证据（测试通过数 / 接口返回片段）。

完成后

通过自检 → 按 commit-and-push skill 询问是否提交推送（用户高频要求"验证后提交推送"）。

反模式（请避免）

反模式	正确做法
没复现就按用户描述直接改	先证实问题真实存在 + 根因
修了症状没修根因（如 fillna 掩盖 NaN 源头）	顺数据流回溯到根因再修
只给一个方案就动手	多方案对比 + 择优，必要时问"是否有更优解"
改完不做回归扫描就说"完成"	显式回答"是否引入新 bug"+ 跑测试 + 黑盒验证
后端改完只 commit 不重启 → 说生效了	重启 web_service + 黑盒接口确认
自定义策略只测内置一侧	内置 + custom 两条路径都验证

このリポジトリの他の Skills

同じリポジトリ

ai-agent-debug

posbright/Quantia

Use when debugging AI agent issues: empty reports, tool call failures, LLM hallucinated columns, SSE streaming errors, max_rounds exhaustion, or provider connectivity. Covers diagnostic steps, common root causes, and fix patterns for the stock_analyst/market_summarizer/strategy_coder agents.

2026-05-2710

composite-indicator

posbright/Quantia

Use when adding, editing, debugging, or reviewing custom composite indicators (Phase 9 自定义综合指标) under quantia/core/composite/, including normalizers (n_lin/n_wr/n_rank/n_supertrend/n_pctb/n_cci), hard-rule AST sandbox expressions, risk simulator stop/target/max-hold + fundamentals exit, dynamic universe filters, and the cn_stock_custom_indicator handler. Use when writing builtins or wiring the customIndicatorHandler / refresh_composite_universe cron.

2026-05-1510

restart-and-deploy

posbright/Quantia

Use after editing Quantia backend Python (quantia/web/**, quantia/core/**, quantia/job/**) or frontend (quantia/fontWeb/src/**) to restart the long-running Tornado web service, sync template changes, and copy the Vite dist into quantia/web/static for production. Use when changes appear to take no effect in the browser or when frontend strategy templates show stale code.

2026-05-1510

name

diagnose-verify-fix

description

诊断 → 验证 → 根因 → 择优 → 修复 → 回归（Quantia 验证优先工作流）

这是本仓库用户的签名工作流。几乎每次"修 bug / 检查改动 / 看日志"的请求都隐含这套要求，即使用户没逐条写出来，也要按此执行。

触发场景

"请帮我检查并验证…是否包含 bug / 引入了新问题"
"为啥…会失败 / 为啥结果是降级版"（贴图、贴日志）
"帮我修复服务器运行时的错误"（贴 *.log）
"当前修改是否合理 / 有没有不符合预期的行为"
"综合评估这几个方案…选最优" / "是否有更优解决方案"
进入下一个 phase 前的"再次审查确认无遗漏"

五步硬流程（不可跳步）

1. 证实问题真实存在（先别动手改）

复现：写最小复现（脚本 / 单测 / Invoke-RestMethod 黑盒调接口），或在代码里定位触发路径。
区分"用户以为的问题"与"真实问题"：用户常给现象（"结果是降级版""收益为 0"），根因可能在别处。
若无法复现 → 明确告知"当前无法复现"，列出已验证的点，再问用户补信息；不要猜测性地乱改。

2. 定位根因（root cause，不是症状）

顺数据流回溯：Fetch → MySQL/cache → Analysis job → Handler → 前端（见 AGENTS.md 规则 1 的管道边界）。
生产日志诊断（阿里云 115.29.213.22，库 instockdb）：
- 常看：quantia/log/stock_fetch.log / stock_error.log / refresh_ai_kb.log / kline_cache 相关。
- 读 Traceback 顶层异常 + 触发函数，再对应到本地源码；注意"数据源降级""OHLC 异常过滤""未找到命令"等高频根因。
- 日志是 Compute/Fetch 侧产物——分析时仍遵守管道分离，不在 handler 里加网络请求来"修日志"。
一句话写清根因（"X 因为 Y，触发于 Z"），让用户能确认。

3. 列方案 + 择优（用户偏好显式对比）

≥2 个可行方案时，列优缺点对比（正确性 / 副作用 / 性能 / 维护成本 / 与文档一致性）。
主动问一句"是否有更优解"再下结论——用户多次要求"再深入分析是否有更优方案"。
选最优且最合理的，不是最省事的。说明为什么不选其它。
与 document/*.md（特别是当前 phase 的开发计划）核对，确保方案不偏离需求。

4. 修复（最小、不外溢）

只改根因相关代码；不顺手重构、不加无关"改进"（见 AGENTS.md 实施纪律）。
改动若涉及后端常驻进程 → 走 restart-and-deploy skill 重启 + 黑盒接口验证（commit ≠ 生效）。

5. 回归自检 + 验证（声明完成前必做）

回归扫描：本次改动是否引入新 bug / 破坏既有行为？显式回答，别默认"应该没事"。
跑相关单测：python -m pytest tests/test_<相关>.py -q；改了多模块就跑相关多文件。
黑盒验证被改接口：Invoke-RestMethod 确认 200 + 预期字段（区间用 2026-03~05，2025 在生产 DB 为空）。
自定义策略相关改动：内置 vs custom_<id> 两条路径都验证（见 AGENTS.md Custom-strategy parity）。
只有 1-5 全过，才向用户报告"已修复/已验证"，并附验证证据（测试通过数 / 接口返回片段）。

完成后

通过自检 → 按 commit-and-push skill 询问是否提交推送（用户高频要求"验证后提交推送"）。

反模式（请避免）

反模式	正确做法
没复现就按用户描述直接改	先证实问题真实存在 + 根因
修了症状没修根因（如 fillna 掩盖 NaN 源头）	顺数据流回溯到根因再修
只给一个方案就动手	多方案对比 + 择优，必要时问"是否有更优解"
改完不做回归扫描就说"完成"	显式回答"是否引入新 bug"+ 跑测试 + 黑盒验证
后端改完只 commit 不重启 → 说生效了	重启 web_service + 黑盒接口确认
自定义策略只测内置一侧	内置 + custom 两条路径都验证