1这份文档写给谁
本文档面向对本系统的技术实现方式感兴趣的读者：考虑引入类似自动化工具的企业、进行技术交流的同行、以及需要了解我们如何构建这类系统的合作方。
2系统概要
What to buy Today 是 PPAP株式会社 自研自运营的财务分析工具：每天自动收集外币计价基金的官方基准价额与主要市场行情，计算技术指标并排出榜单，同时为用户提供多币种持仓的损益核算与 AI 辅助记账。
| 项目 | 内容 |
|---|---|
| 形态 | Web 应用（浏览器直接访问，无需安装） |
| 跟踪对象 | 外币计价基金 20 只（美元计价 10 只 / 日元计价 10 只）、股指与汇率等十一项宏观行情、用户自选个股最多 12 只（中国 A 股 / 香港 / 美国 / 日本） |
| 自动化节奏 | 每天 1 轮 + 工作日 2 轮，共三轮定时管线，各自产出看板更新与邮件 |
| 用户模型 | 账户发放制 + 邮箱验证码自助注册；未登录亦可浏览公开内容 |
| 运行环境 | 共享主机（Apache + PHP）＋ 运营方本地的自动化调度 |
| 开发运营 | PPAP株式会社 自社内制（企画・実装・運用を一貫） |
3架构概览
系统刻意保持了极简的运行时结构：面向用户的部分只有静态页面与少量 PHP 端点，所有"重活"都在离线的自动化管线里完成。
4技术栈与选型思路
| 层面 | 采用 | 选型思路 |
|---|---|---|
| 前端 | 原生 HTML / CSS / JavaScript，单页单文件，数据内嵌 | 不引入框架与打包器。目标是十年后仍能打开修改——这类长期自运营的工具，最大的风险不是功能不足，而是工具链腐化导致无人能维护 |
| 图表 | 手写内联 SVG | 不依赖图表库，避免版本升级与体积负担；样式与品牌完全可控 |
| 服务端 | PHP（共享主机原生环境） | 零部署成本、零运维负担。服务端只承担必须实时的职责，逻辑量刻意压到最小 |
| 数据存储 | 文件存储（每用户一份加密文件），不使用数据库 | 天然隔离、易备份、删除账户即删除一个文件，契合个人数据的可删除要求；在当前用户规模下性能充裕 |
| 调度 | 运营方侧的自动化管线（非服务器 cron） | 管线中包含"需要判断"的环节（宏观叙述整理、榜单点评），这类工作交给具备检索与写作能力的 AI 代理执行，而非固定脚本 |
| AI | Anthropic Claude（结构化输出） | 用于把非结构化的对账单文本、截图、PDF 转成结构化交易记录；输出走 JSON Schema 约束，保证字段可直接进入前端确认表 |
| 发布 | 脚本化上传 + 白名单清单 + 上传后校验 | 用清单式白名单而非排除式黑名单，凭证类文件在脚本层面被硬性排除，不依赖人的记性 |
5数据管线
数据全部来自公开渠道，管线的工程重点在多源冗余与失效可恢复。
| 数据类别 | 来源性质 | 工程处理 |
|---|---|---|
| 基金基准价额 | 基金方公开的官方值（当日值 + 全历史日线） | 每轮全量抓取后写回页面内嵌数据块，并保留一份外部副本供长历史查询 |
| 股指与汇率 | 多家公开行情源并用 | 按"标的 × 期间粒度"分别路由到最合适的源；每个标的配置降级链，主源失效自动改走兜底源 |
| 宏观叙述 | 公开信息的检索与整理 | 由管线在每轮生成当日判断，并保留历史综合，避免只有一个时点的孤立结论 |
6核心算法
| 算法 | 说明 |
|---|---|
| 技术指标 | 基于日线序列计算：相对高点的回撤幅度、RSI、区间百分位、相对中期均线的偏离、年化波动率。全部为公开可复现的标准算法 |
| 综合评级 | 把上述指标按固定权重合成为「入手吸引力」，用于榜单排序与每日提示。规则固定、不含机器学习，因此结果可解释、可回溯 |
| 持仓成本 | 移动平均法。卖出时按卖出时点的平均成本结算已实现损益，并从持有量中扣减；卖出量超过持有量时按持有量截断并显式提示 |
| 计价口径处理 | 日本国内投信的基准价额按「每 1 万口」公表。系统在入账与显示两处分别处理该换算，使用户填入与看到的数值都与官方口径一致，避免手工换算引入错误 |
| 多币种汇总 | 按「货币 × 投资类型」二维分组小计，各行折算日元；折算值明确标注为概算，不参与任何对账用途 |
| 录入校验（防呆） | 两道：① 基金录入单价与该日期官方基准价额偏差超过阈值即告警（可捕获日期误记与标的误选）② 与既有记录或同批内其他行的标的·类型·数量·单价完全一致时提示疑似重复。两者均为提示而非阻断，并在用户修改字段后实时重新判定 |
评级与提示刻意不采用黑箱模型：一是可解释性对金融类工具是刚需，二是规则化的结果便于事后复盘"当初为什么这么排"。
7AI 的使用方式
系统中 AI 承担两类工作，界限划得很清：
| 场景 | AI 做什么 | 为什么这样限定 |
|---|---|---|
| AI 辅助记账 | 把用户提供的对账单文本、截图或 PDF 提取成结构化交易记录，以 JSON Schema 约束输出字段 | 提取结果不直接入账，必须经用户在确认表中逐项核对。AI 承担"读"，人承担"认"——记账数据一旦错误，后续全部损益都会失真 |
| 自动化管线的判断环节 | 检索并整理当日宏观信息、生成叙述性判断、撰写邮件内容 | 这类工作无法用固定脚本表达，但产物是叙述而非数值；所有数值仍来自确定性的抓取与计算，不由 AI 生成 |
AI 不参与任何数值计算，也不产生投资结论。榜单、指标、损益全部由确定性规则计算得出。
8安全与隐私设计
| 设计点 | 做法 |
|---|---|
| 最小化收集 | 只收集邮箱、称呼、密码（不以明文保存）与用户自行录入的内容。不索取任何金融机构的账号、密码或卡号，系统也没有任何需要它们的功能 |
| 静态加密 | 每位用户的数据保存为独立的 AES-256-GCM 密文文件，置于 Web 不可直接访问的目录。目的是降低文件被单独取得时的泄露风险（不主张运营方在技术上完全无法访问） |
| 写入完整性 | 存储层对写入结果做回读校验，校验失败即报错而非静默成功——曾实测到静默写入失败会造成数据孤儿，此护栏为此而加 |
| 会话 | 登录签发有期限的令牌，服务端只保存其散列值，且仅保留最近若干个，超出即自动失效 |
| 环境隔离 | 验证环境与生产环境的账户数据完全分离，避免测试污染真实数据 |
| 代理防滥用 | 行情代理对符号与期间做白名单校验，不接受任意目标地址，避免成为开放代理 |
| AI 端点防滥用 | 需登录、按用户设每日调用上限、限制请求体大小 |
| 凭证隔离 | 全部凭证仅存在于运营方本地配置与服务器的非公开目录；发布脚本以白名单方式上传，凭证类文件在脚本层面硬性排除，且不写入任何文档 |
| 用户自主权 | 用户可自行修改邮箱与密码、关闭邮件、删除账户 |
9工程实践
| 实践 | 内容 |
|---|---|
| 两段式发布 | 功能改动先发到验证环境供确认，再由每日管线推向生产；纯数据更新走豁免路径直推。会改变行为的与只更新数字的，走不同的路 |
| 发布后校验 | 上传完成后取回线上文件比对字节数与关键标记，不一致即视为发布失败，而非以"上传命令成功"为准 |
| 幂等设计 | 每日管线的各阶段均带幂等标记，重复触发不会产生重复产物（如同日新闻不会二次生成并覆盖） |
| 可解释的数据来源 | 页面上每个数值都标注来源与基准日期；数据未更新时显式呈现，不隐藏 |
| 失效史留档 | 外部数据源的每一次失效都记录现象、根因与处置，形成可查的运维知识库——这类工具的主要维护成本就在外部源的变动上 |
| 文档化 | 技术、运维、用户三类文档独立成篇并统一样式；内部运维文档置于门禁区，对外文档公开 |
10设计取舍与适用边界
本系统是为特定场景做的取舍，坦率列出它不适合什么，比夸大适用范围更有意义。
| 取舍 | 换来了什么 | 付出了什么 |
|---|---|---|
| 不用框架、单文件前端 | 极低的维护腐化风险；任何环境可直接打开 | 不便多人并行开发；文件体积较大 |
| 数据内嵌、无后端渲染 | 首屏即有数据；服务器故障面极小 | 数据更新需重新发布页面 |
| 文件存储、无数据库 | 隔离与删除彻底、备份简单 | 不适合跨用户统计与大规模检索 |
| 调度在离线侧 | 能把"需要判断"的工作纳入自动化 | 依赖运营方侧环境处于运行状态 |
| 规则化评级、不用黑箱模型 | 结果可解释、可复盘 | 不追求预测精度，也不宣称有预测能力 |
| 多源冗余而非采购付费行情 | 零数据成本 | 受公开源变动影响，存在延迟且需持续维护 |
本系统是信息整理与可视化工具，不是金融商品取引业者，一切输出不构成投资建议或劝诱。技术层面的可靠性设计，不构成对数据正确性或投资结果的保证。详见免責事項・利用規約。
对本系统的技术实现有进一步兴趣，或希望探讨类似自动化工具的引入，欢迎通过 PPAP株式会社 お問い合わせ窓口 与我们联系。