yuqei/ai-exchange
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
main
ai-exchange/docs/AI_ICT_全自动开发执行流程_v1.md
T
Codex d7a4330d30 Add ICT book mainline governance docs
2026-05-21 08:27:12 +08:00

23 KiB
Raw Permalink Blame History

AI ICT 全自动开发执行流程 v1

0. 硬性主线约束

任何自动化流程在选择切片前，必须先读取并服从：

  • docs/ICT交易全书_出版终校版.md
  • docs/AI_ICT_硬性主线约束_必须遵循ICT交易全书_2026-05-21_v1.md

若自动化流程、旧阶段计划、历史 backlog 或临时 prompt 与《ICT交易全书》主线冲突，必须停止该切片进入交易员主界面，并改为回到书本主线。

自动化只允许推进能映射到以下链路的交易分析工作：

Range / Draw / Location
-> Liquidity / Sweep / Inducement / Path
-> Displacement / MSS / FVG / Retest / Session
-> backtest evidence
-> pre-market plan
-> intraday unique focus or no-trade reason
-> journal / study-notes feedback

1. 目标

本流程用于约束后续 ai-exchange 项目的默认推进方式。

从本文件更新后开始，项目默认采用：

文档锚点驱动 + 连续自动推进 + 分阶段闭环验证 + 状态自动回写

这里的“全自动”不是指跳过验证、跳过风控、跳过状态记录，而是指：

  • 不等待每个子阶段的用户确认
  • 不在完成一小部分后停住
  • 不把本可自行继续的工作交还给用户
  • 除非遇到真实外部阻塞，否则自动进入下一可执行步骤

本流程已经根据以下文档统一调整：

  • docs/AI_ICT_实盘交易分析决策助手下一阶段开发方案_v1.md

后续该项目默认以本流程作为自动推进协议。

2. 适用范围

本流程适用于当前仓库两条连续主线：

2.1 主线 A：AI_ICT 当前主系统收尾与稳态推进

包括但不限于：

  • 当前 N4 visual-watch 相关收尾
  • runtime env 恢复
  • market stream / broker read / readiness 验证恢复
  • 当前 Real-time Assisted Trading V1 未完成收尾项

2.2 主线 B：AI_ICT + TradingAgents 融合实施

按最终版方案顺序推进：

  1. P0 影子接入，不影响现有决策
  2. P1 受控进入决策包与运行时
  3. P2 经验回流、评估闭环、研究竞技场
  4. P3 长期优化循环闭环与状态化运行
  5. P4 优化治理与 operator 可见性闭环
  6. P5 confirmed swing replay 证据闭环
  7. P6 governance tick 自动巡检闭环

3. 自动化推进总顺序

默认顺序不是“哪里有想法先做哪里”，而是：

先稳住当前 AI_ICT 主骨架
-> 再推进 Research Council P0
-> P0 稳定后推进 P1
-> P1 证明对 operator 真有帮助后再推进 P2
-> P2 进入长期运行态后推进 P3 优化循环闭环
-> P3 cycle 稳定后推进 P4 优化治理与可见性
-> P4 review 指出 bounded replay 缺口后推进 P5 证据闭环
-> P5 review 恢复 healthy 后推进 P6 governance tick 自动巡检
-> P6 tick 为 no_op_healthy 后冻结 P0-P6
-> 进入自动化执行层开发阶段

更具体地说：

  1. 先完成当前主系统可执行收尾
  2. 清理外部环境与 runtime 验证阻塞
  3. 再进入融合主线
  4. 融合主线必须遵守影子运行 -> 受控影响 -> 经验回流的顺序

如果当前出现主系统 bug、readiness 回退、runtime 烟雾失败，则：

优先修主系统，再继续融合

4. 文档锚点与唯一真源

每一轮自动推进，必须先读取并以如下锚点为准：

4.1 必读锚点

  • docs/AI_ICT_实盘交易分析决策助手下一阶段开发方案_v1.md
  • SESSION.md
  • TASKS.md

4.2 辅助锚点

当需要判断当前历史阶段、上下文或旧计划映射时，补充读取：

  • docs/archive/AI_ICT_下一阶段开发计划_v1.md
  • docs/archive/AI_ICT_下一阶段开发任务清单_v1.md
  • docs/archive/AI_ICT_TradingAgents_P0自动任务清单_v1.md
  • docs/AI_ICT_TradingAgents_P1自动任务清单_v1.md
  • docs/AI_ICT_TradingAgents_P2自动任务清单_v1.md
  • docs/AI_ICT_TradingAgents_P3自动任务清单_v1.md
  • docs/AI_ICT_TradingAgents_P4自动任务清单_v1.md
  • docs/AI_ICT_TradingAgents_P5自动任务清单_v1.md
  • docs/AI_ICT_TradingAgents_P6自动任务清单_v1.md
  • docs/archive/AI_ICT_TradingAgents_P0-P6合理性审查与优化结论_v1.md
  • docs/archive/AI_ICT_research_council脚手架与数据表草案_v1.md

4.3 真源原则

需要统一裁决时，优先级如下：

最新可执行状态
-> SESSION.md / TASKS.md
-> 当前正式方案文档
-> 较早的旧计划文档

也就是说：

  • 不依赖聊天记忆
  • 不依赖“上次大概做到哪”
  • 不依赖旧文档里已经被新方案覆盖的内容

5. 默认执行原则

  1. 阶段顺序固定

    • 不跳阶段
    • 不把 P0 和 P1 混做
    • 不在主骨架未稳时提前把研究层接入执行路径

  2. 实现优先于讨论

    • 只要锚点已经足够明确，就直接实现
    • 有小歧义时采用合理默认值并在状态中记录假设

  3. 每一轮必须闭环

    • 代码 / 文档实现
    • focused validation
    • 相关质量门
    • 必要时 API / browser / runtime smoke
    • 必要时远端 deploy 与 smoke
    • SESSION.md / TASKS.md / docs 回写

  4. 先小闭环，再自动进入下一小闭环

    • 每次推进一个可验证切片
    • 完成后立即判断下一个切片，不停顿

  5. 不制造第二套真相

    • AI_ICT 继续做事实层、规则层、执行边界层
    • Research Council 只做研究推理增强层
    • 不允许平行状态机、平行 readiness、平行 trust

  6. 不让研究层越权

    • 不允许委员会结果直接改写 risk_result
    • 不允许直接改写 execution_allowed
    • 不允许直接替代 DecisionPacketService 主裁决

  7. 文档与状态必须同步

    • 新能力落地后，相关 docs 必须同步
    • SESSION.md 和 TASKS.md 必须反映最新可执行现实

6. 单轮自动执行标准流程

每一轮自动推进，按以下顺序执行。

Step 0：验证自动化前置条件

必须先检查：

  1. 当前仓库路径正确
  2. 基础工具可用
  3. GSTACK_OK 规则是否满足（如当前工作依赖该规则）
  4. 当前 .venv 或等价运行环境可用

如果这些前置条件缺失且可自动修复，则先修复再继续。

Step 1：读取当前锚点

必须读取：

  • docs/AI_ICT_实盘交易分析决策助手下一阶段开发方案_v1.md
  • SESSION.md
  • TASKS.md

确认：

  • 当前活跃主线
  • 当前活跃阶段
  • 当前真实阻塞项
  • 当前验收口径
  • 当前下一默认入口

Step 2：确定“本轮最小可执行切片”

自动从当前锚点中选出最小可闭环切片。

优先级规则：

  1. 先处理主系统 blocker
  2. 再处理当前活跃阶段的最小闭环
  3. 再处理增强解释层
  4. 最后才处理扩展和优化

切片应满足：

  • 能在一轮内形成可验证结果
  • 能落在现有模块边界内
  • 不需要等待用户做新的产品决策

不允许把一个阶段拆成大量无验证的长链未完工改动。

Step 3：实现当前切片

实现时必须遵守：

  1. 优先复用现有服务、仓储、API、脚本、前端结构
  2. 不新增平行状态机
  3. 不把研究层反向写成主事实层
  4. Research Council 相关改动统一落到：
src/services/research_council/
  1. 优先接入现有主链：
    • decision_packet
    • review_packet
    • runtime
    • workbench
    • visual_watch

Step 4：补足 focused tests / checks

要求：

  1. 先补 touched modules 的 focused tests
  2. 再补相关脚本 smoke
  3. 再补相关 API smoke
  4. 再决定是否需要更大范围回归

对于不同改动类型，要求不同：

A. 文档-only

  • 检查文档结构、标题、路径、锚点引用

B. 纯后端逻辑

  • focused unit tests
  • 相关脚本 smoke
  • 相关 API smoke

C. runtime / API / workbench / DB

  • focused tests
  • 相关脚本 smoke
  • API smoke
  • browser smoke
  • 必要时 deploy smoke

Step 5：执行本地质量门

默认本地验证顺序为：

  1. touched modules focused tests
  2. tests/unit
  3. scripts/run_offline_checks.py
  4. 若涉及前端或静态资源，再执行：
npm run lint
npm run build
npm run visual:snapshots
  1. 若需要本地 API / browser 验证：
    • 启动本地 API server
    • 执行 API smoke
    • 执行 browser smoke

原则：

  • 不因为“只是小改动”跳过应有验证
  • 也不因为“只是文档改动”强行做无意义部署

Step 6：决定是否需要远端部署验证

不是每轮都必须远端部署，但以下情况必须部署并做远端 smoke：

  1. 改动涉及 runtime
  2. 改动涉及 API
  3. 改动涉及 DB schema / migration
  4. 改动涉及 workbench / operator 真实可见行为
  5. 改动涉及 alert / broker / readiness / decision packet / review packet 主链

以下情况可不部署远端：

  1. 文档-only
  2. 纯本地测试支撑代码
  3. 尚未进入运行链路的孤立脚手架

如果不部署远端，必须在状态里明确说明原因。

Step 7：执行远端 deploy 与 smoke

需要远端验证时，默认流程为：

  1. 部署当前 HEAD
  2. 执行 migration
  3. 等待容器 healthy
  4. 验证关键 API
  5. 验证关键 runtime 状态
  6. 验证 browser / operator 关键可见结果

至少应覆盖：

  • /health
  • 当前阶段新增或影响的核心 API
  • 当前阶段关键状态输出

涉及主系统时，还要特别验证：

  • launch-readiness
  • runtime-status
  • decision-packet
  • trust-score
  • review-packet

涉及 Research Council 时，还要验证：

  • research-council 手动触发入口
  • packet / review 中的研究增强字段
  • 失败降级行为

Step 8：写回状态锚点与方案文档

每轮结束必须更新：

  • SESSION.md
  • TASKS.md

必要时同步更新：

  • docs/archive/AI_ICT_TradingAgents融合实施方案_最终版.md
  • 当前阶段相关任务清单 / 技术设计文档

必须写回的内容：

  • 当前完成了什么
  • 当前切片是否闭环
  • 当前未完成但仍可继续的下一入口
  • 新出现的 blocker / warning / noisy incident
  • 是否已 deploy / smoke
  • 若未 deploy，为何未 deploy

原则：

状态锚点必须反映“现在真实能继续做什么”，而不是只写“做过什么”。

Step 9：自动决定下一轮入口

若本轮已经满足：

  • 当前切片代码/文档完成
  • 相应验证完成
  • 必要时 deploy / smoke 完成
  • 状态锚点已回写

则：

直接进入下一可执行切片，不等待用户确认

下一入口优先级：

  1. 同一阶段剩余闭环切片
  2. 当前阶段收尾
  3. 下一阶段最小切片

但当当前阶段为 Research Council P6 且 governance tick 返回 no_op_healthy 时，不进入下一阶段，也不自动创建 P7。此时应停止 Research Council 阶段扩展，并进入自动化执行层开发准备。

Step 10：阶段晋级判定

当同一阶段的切片已经基本闭环时，不能只因为“本轮跑完了”就默认跳到下一阶段，必须执行阶段晋级判定。

统一规则如下：

A. P0 晋级到 P1

只有同时满足以下条件，才允许自动进入 P1：

  1. research_council 手动 API / script 能稳定跑通
  2. 没有委员会结果时，原系统行为不回归
  3. 有委员会结果时，review packet 能稳定展示委员会摘要
  4. council 失败时，runtime 自动降级但不中断主链
  5. 连续多次 focused smoke 无新增主链 blocker

否则：

继续停留在 P0
-> 自动补同阶段剩余缺口
-> 不提前切到 P1

B. P1 晋级到 P2

只有同时满足以下条件，才允许自动进入 P2：

  1. decision_packet 已稳定吸收委员会解释字段
  2. runtime 已受控接入 research_council
  3. workbench 已稳定展示支持 / 反对 / 分歧 / follow-up checks
  4. visual_watch 已能消费委员会建议
  5. 未对 execution gate / live readiness / operator confirmation protocol 造成回归

否则继续停留在 P1 收尾。

C. P2 阶段出口

P2 不是一次性结束点，而是进入持续运行与评估优化模式。

当以下条件成立时，自动切换为“长期运行态”：

  1. lesson backfill 机制稳定
  2. checkpoint / resume 机制稳定
  3. 评估脚本能持续比较 council 与非 council 效果
  4. 内部研究竞技场已能服务后续迭代

进入长期运行态后，默认动作变为：

持续评估
-> 识别问题
-> 回到 P2 内部优化
-> 必要时回流修正 P1 或 P0

D. 阶段判定失败时的统一状态写法

如果阶段执行完成但晋级门未通过，状态锚点应明确写成以下之一：

  • P0 部分完成
  • P0 待收尾
  • P0 环境阻塞
  • P1 部分完成
  • P1 待收尾
  • P1 环境阻塞
  • P2 进入长期运行态

不允许写成模糊的“基本完成”后直接跳段。

E. P3-P6 状态化出口

P3-P6 不再使用传统“晋级门”语义，而使用状态化出口：

  1. P3 完成后进入 P4，前提是 optimization cycle 可持久化、可查询、可通过 CLI / API 消费。
  2. P4 完成后根据 review 结果分流：
    • 若返回 add_replay_fixture_with_confirmed_swings，进入 P5。
    • 若 review 已是 healthy 且无 bounded action，直接进入 P6。
    • 若返回其他 needs_attention，只打开最小 bounded slice，不自动扩新阶段。
  3. P5 完成后必须回到 P4/P6 review，确认原 bounded action 已关闭。
  4. P6 是 Research Council 当前主线的终端治理入口：
    • no_op_healthy：停止，不写代码，不扩 P7。
    • cycle_required：只有策略允许时补跑 cycle。
    • bounded_slice_required：打开最小 bounded slice，完成后回到 P6。

P6 之后如需继续扩大阶段，必须是用户明确提出的新产品阶段规划，而不是自动化默认行为。

7. 针对当前融合主线的自动化阶段策略

7.1 阶段 A：先稳住当前 AI_ICT 主骨架

默认优先处理：

  • 当前 N4 visual-watch 相关收尾
  • runtime env 恢复
  • market stream / broker credentials / proxy 恢复
  • readiness / runtime / broker smoke 回归

这一阶段不应被新的 Research Council 扩展打断。

7.2 阶段 B：Research Council P0

目标：

  • 影子接入
  • 不影响现有决策
  • 只读消费 AI_ICT 事实
  • 结果先进入 review packet，再逐步扩展

默认切片顺序：

  1. research_council 目录脚手架
  2. council_context_builder
  3. structure_analyst
  4. risk_analyst
  5. bull_researcher / bear_researcher
  6. research_manager
  7. 手动 API / script 触发
  8. review packet 只读展示

本阶段禁止：

  • 改写 action_recommendation
  • 改写 risk_result
  • 改写 execution_allowed

完成本阶段后，必须执行 Step 10 的 P0 晋级判定，判定通过才可切入 P1。

7.3 阶段 C：Research Council P1

目标：

  • 受控进入 decision_packet
  • 受控进入 runtime
  • 增强 operator / workbench 的解释质量

默认切片顺序：

  1. runtime 任务接入
  2. packet 字段扩展
  3. news_event_analyst
  4. visual_analyst
  5. disagreement / follow-up checks
  6. visual watch 建议联动
  7. workbench 展示增强

本阶段仍禁止：

  • 改写执行闸门
  • 改写 live readiness
  • 绕过 operator confirmation protocol

完成本阶段后，必须执行 Step 10 的 P1 晋级判定，判定通过才可切入 P2。

7.4 阶段 D：Research Council P2

目标：

  • 经验回流
  • checkpoint / reflection / lessons
  • 内部评估闭环

默认切片顺序：

  1. research_council_lessons
  2. replay / journal / weekly-review lesson backfill
  3. council checkpoint / resume
  4. 评估脚本
  5. 内部研究竞技场

本阶段仍然不是平台化阶段。

本阶段完成后，不是直接“项目结束”，而是执行 Step 10 的 P2 阶段出口判定，进入长期运行与评估优化模式。

7.5 阶段 E：Research Council P3

目标：

  • 把 P2 的长期运行态固化为可重复执行的 optimization cycle
  • 持久化 lesson / replay / eval / arena summary
  • 给下一轮 bounded optimization 输出明确动作

默认切片顺序：

  1. research_council_optimization_cycles
  2. CouncilOptimizationService
  3. run_research_council_optimization_loop.py
  4. optimization cycle API
  5. focused unit tests / script smoke / API smoke
  6. SESSION.md 与 TASKS.md 状态回写

本阶段完成后，进入 Research Council P3 long-running optimization loop。该循环只产生 operator follow-up 与下一轮研究优化建议，不扩大 execution gate / live readiness / trust bucket 权限。

7.6 阶段 F：Research Council P4

目标：

  • 将最近 P3 optimization cycles 转成治理判断
  • 暴露 stale / needs_more_samples / needs_attention / healthy 状态
  • 接入 CLI / API / review packet / workbench

默认切片顺序：

  1. CouncilOptimizationReviewService
  2. run_research_council_optimization_review.py
  3. optimization review API
  4. review packet 与 workbench 可见性
  5. focused unit tests / script smoke / API smoke
  6. remote deploy / smoke
  7. SESSION.md 与 TASKS.md 状态回写

本阶段完成后，进入 Research Council P4 Optimization Review Governance。该阶段只产生 operator follow-up 和下一轮 bounded optimization 建议，不自动改变模型、trust bucket、execution gate 或 live readiness。

7.7 阶段 G：Research Council P5

目标：

  • 将 P4 的 add_replay_fixture_with_confirmed_swings 建议落成可部署 replay evidence
  • 用 confirmed swing high / low 样本重跑 optimization loop
  • 确认 latest review 不再把 replay fixture 作为待办缺口

默认切片顺序：

  1. data/replay/research_council_confirmed_swings_v1.jsonl
  2. replay quality gate 与 focused tests
  3. optimization replay summary evidence
  4. optimization loop rerun
  5. optimization review / review packet / workbench smoke
  6. remote deploy / remote API cycle / remote review smoke
  7. SESSION.md 与 TASKS.md 状态回写

本阶段完成后，进入 Research Council P5 Confirmed Swing Replay Evidence。该阶段只关闭 replay evidence 缺口，不自动改变模型、trust bucket、execution gate 或 live readiness。

7.8 阶段 H：Research Council P6

目标：

  • 将 healthy optimization review 转成可调度 no-op tick
  • 将 stale/missing/needs_attention 转成明确自动化状态
  • 避免健康状态下重复打开无意义开发切片

默认切片顺序：

  1. CouncilGovernanceTickService
  2. run_research_council_governance_tick.py
  3. governance tick API
  4. focused unit tests / script smoke / API smoke
  5. remote deploy / remote API smoke
  6. SESSION.md 与 TASKS.md 状态回写

本阶段完成后，进入 Research Council P6 Governance Tick。该阶段只做周期治理判断，不自动改变模型、trust bucket、execution gate 或 live readiness。

7.9 P0-P6 审查与阶段冻结

目标：

  • 审查 P0-P6 是否合理
  • 修正自动化流程中可能导致无限扩阶段的地方
  • 明确下一步进入自动化执行层开发

审查结论：

P0-P6 合理
P0-P6 阶段冻结
P6 为默认治理入口
no_op_healthy 时停止
不自动创建 P7

正式进入自动化执行层开发的条件：

  1. docs/archive/AI_ICT_TradingAgents_P0-P6合理性审查与优化结论_v1.md 已存在
  2. SESSION.md / TASKS.md 已写明 automation_flow_p0_p6_review_closed
  3. P6 governance tick 最近一次结果为 no_op_healthy
  4. 文档一致性测试通过

7.10 自动化执行层 P7：监控成熟度与晋级路由

用户明确要求从 P7 开始设计自动化时，P7 只代表自动化执行层的新阶段，不代表 Research Council P7。

P7 的目标是打破以下健康巡检循环：

continue_periodic_analysis_decision_monitoring
-> monitor passed
-> quality gate passed
-> continue_periodic_analysis_decision_monitoring

新的稳定窗口出口为：

analysis_decision_monitor_quality_gate=passed
stable_monitoring_window=true
latest blockers=[]
latest warnings=[]
P6 governance tick=no_op_healthy
-> automation_execution_layer_p7_monitor_maturity_rollup

P7 默认不扩大交易能力，只做：

  1. 监控成熟度摘要
  2. 本地/远端状态漂移检查
  3. alert 与 decision-support 输出质量审查
  4. 唯一下一个 bounded automation slice 选择
  5. SESSION.md / TASKS.md / .claude 状态回写

P7 必须继续遵守：

  • 不修改 execution_allowed
  • 不修改 real_live_ready
  • 不绕过 risk governor
  • 不升级或降级 trust bucket
  • 不绕过 operator confirmation protocol
  • 不把 OKX fills 为 0 当作当前 analysis/decision-only 阶段 blocker
  • 不创建 Research Council P7

P7 任务清单以以下文档为准：

docs/archive/AI_ICT_自动化执行层_P7监控成熟度与晋级路由_v1.md

P14 之后的自动化执行层连续开发，以以下有限清单为准：

docs/AI_ICT_自动化执行层_P15-PXX闭环任务清单_v1.md

该清单把 P15-PXX 收敛为已知范围，不允许在 PXX closure gate 之后自动发明新阶段；新的真实交易闭环、真实外部媒体通道或新产品能力，必须由用户明确打开新的产品阶段。

8. 阻塞处理规则

只有以下情况允许停下来请求用户：

  1. 密钥 / 凭据缺失，且无法从现有环境推断
  2. 外部账号权限不足
  3. 需要不可逆破坏性操作
  4. 产品决策确实无法合理默认
  5. 上游网络 / 供应商 / 远端环境阻塞导致无法继续验证

除上述情况外：

  • 默认自行排查
  • 默认自行修复
  • 默认继续推进当前阶段的非阻塞部分

如果 blocker 只影响远端验证而不影响本地实现，则：

先完成本地闭环 -> 记录阻塞 -> 转入下一本地可执行切片

9. 边界守卫规则

以下守卫是硬规则：

  1. 不默认开启真实自动下单
  2. 不让 LLM 绕过风控
  3. 不让 Research Council 重写主事实层
  4. 不让 Research Council 直接替代 trust / readiness / execution gate
  5. 不在远端 smoke 未完成时把 runtime / API / workbench 主链改动宣告完成
  6. 不把环境问题伪装成代码完成
  7. 不因为“自动化”省略状态回写

10. 单轮完成定义

一个自动化切片只有满足以下条件，才算真正完成：

  • 锚点目标已实现
  • 对应 focused validation 已完成
  • 需要时本地质量门已通过
  • 需要时 deploy / remote smoke 已通过
  • SESSION.md / TASKS.md / docs 已回写

否则只能算：

部分完成 / 待收尾 / 被环境阻塞 / 仅本地完成

11. 当前默认工作模式

从本文件生效起，后续该项目默认工作模式为：

自动读取锚点
-> 自动判定当前主线与最小可执行切片
-> 自动实现
-> 自动 focused validation
-> 自动执行必要质量门
-> 自动决定是否 deploy / smoke
-> 自动写回 SESSION / TASKS / docs
-> 自动进入下一切片

换句话说：

以后该项目默认全程采用自动化流程推进，除非遇到真实外部阻塞或必须用户拍板的产品决策。

Reference in New Issue View Git Blame Copy Permalink