daily_stock_analysis 自建部署：先选运行路径

按维护方式选择，但都应先完成一次最小配置和手动验证。

使用受控的 Secrets 或环境变量，避免写入代码、截图与公开记录。

先检查日志、密钥、股票列表、时区、上游数据服务和通知配置。

本页解释第三方项目的自建准备项。无论选择 GitHub Actions、Docker 或本地运行，模型服务、股票列表、数据来源、调度、日志与故障处理都由部署者负责；它不是 EasyClaw 的内置定时日报功能。

更新于 2026-08-02 第三方项目核对版本：f4d9956 页面定位：自建维护说明

三种运行方式，三个维护重点

先选你能持续维护的方式，再谈自动化。第一次目标应该是用最少配置跑出一次可追溯的结果，而不是立刻接入所有数据源和通知渠道。

方式	适合的情况	你负责的内容	首次验证
GitHub Actions	希望按计划运行，但不维护自己的常驻服务器。	自己的代码副本、Secrets、工作流、时区、运行日志和失败重跑。	先手动触发一次任务，再查看日志、输出和数据时间。
Docker	希望固定依赖环境，并在本机或服务器运行。	镜像、环境变量、网络、目录挂载、容器生命周期和定时执行。	在容器中完成一次最小分析，并保留故障日志。
本地运行	需要调试、了解代码或自己控制启动过程。	运行时、依赖、配置文件、进程、计划任务和机器安全。	仅配置必要输入并运行一次，再逐步增加通知与数据源。

配置越多，排障越困难。先验证最小路径，再按研究需求逐层增加；每增加一层，都记录数据来源、密钥保管方式和失败时的回退动作。

至少确认可用模型服务、股票列表和基础运行环境。密钥不要写进代码仓库，也不要出现在截图、日志导出或聊天记录中。

行情、财务、公告、新闻和不同市场可能依赖不同服务。请分别确认账户权限、更新节奏、字段口径和限流规则，而不是假定一个服务覆盖全部需求。

定时运行、通知渠道和失败重试属于部署者的维护范围。先把本地或手动运行的输出核验清楚，再启用定时任务与外部推送。

保存必要日志，记录运行时间、任务版本和数据异常。遇到失败先分辨是密钥、网络、上游服务、股票代码还是时区问题。

来源说明：本页根据固定版本项目文档整理运行责任。项目依赖、服务接口和默认设置可能改变，部署前请回看对应版本的原始文档。

只配置一次运行真正需要的模型服务和股票列表。确认市场代码、时间范围和数据服务可访问，再增加其他选项。

出现空结果或失败时，按日志检查密钥、网络、配额、数据服务和代码格式。不要通过公开粘贴完整配置或凭据来排障。

检查报告生成时间、数据时间、来源、报告期、单位和缺失项。自动输出是待核验材料，不是交易结论。

使用提示：第三方项目的文档、依赖和上游数据服务可能变化。自建运行成功不保证数据完整性、研究质量或投资结果，本页不构成投资建议。

每次部署或升级后，至少记录项目版本、运行方式、执行时间、股票列表、数据服务状态和一次输出核验结果。这样在数据异常、任务延迟或结果变化时，才能追溯是环境、配置、上游服务还是研究输入发生了变化。

固定代码版本和依赖范围，升级前保留可回退版本；不要把临时修改当成未经验证的长期配置。

记录足以定位问题的时间、错误类型和服务状态，避免把完整密钥、个人信息或敏感配置写进日志。

为密钥失效、数据延迟、网络故障和任务超时准备明确的人工检查与重跑步骤。

daily_stock_analysis 自建部署应先选择 GitHub Actions 还是 Docker？

按你能否维护运行环境和任务选择；无论哪种方式，都先完成一次最小配置和手动验证。

daily_stock_analysis 自建时如何保存模型服务密钥？

使用受控的 Secrets 或环境变量，避免写入代码、截图、日志导出和公开记录。

daily_stock_analysis 定时运行失败先检查什么？

先检查日志、密钥、股票列表、时区、上游数据服务、网络条件和通知配置。