这是一个基于 React + Vite 的最小示例，演示如何实现一个简单量化投资 Agent：
- 使用内置价格序列（
src/data/mockPrices.js） - 使用双均线策略生成信号（
BUY / SELL / HOLD） - 执行极简回测并输出收益率、胜率与交易日志
npm install
npm run dev默认打开地址：
http://localhost:5173
npm run build- 接入真实行情 API（如日线数据）
- 支持手续费、滑点、仓位管理
- 增加更多策略（动量、均值回归、多因子）
- 结果可视化（收益曲线、回撤曲线）
GitHub 分支协作操作手册。
本手册用于说明以下开发流程：
- 从 GitHub 上拉取最新
main分支 - 基于
main创建新的开发分支new_change - 在
new_change上修改代码并提交 - 将
new_change推送到 GitHub - 审核者对
new_change进行审核 - 审核通过后将
new_change合并到main
团队开发时，不要直接在 main 分支上修改代码。
- 先同步最新
main - 从
main创建自己的开发分支 - 在开发分支上完成修改
- 推送到远端
- 发起 Pull Request
- 审核通过后再合并到
main
如果本地还没有仓库，先执行：
git clone 仓库地址
cd 仓库名例如：
git clone https://github.com/xxx/your-project.git
cd your-project如果本地已经有仓库，则跳过这一步。
git checkout main
git pull origin main说明：
使用 git status 可以查看当前分支状态，确认自己在 main 分支上。
git checkout main：切换到主分支git pull origin main：从 GitHub 拉取最新的main
这样可以保证你创建新分支时，基于的是最新版本。
git checkout -b new_change说明：
-b表示创建新分支- 创建后会自动切换到这个分支
可以用下面命令检查当前分支：
git branch如果看到：
* new_change
main说明当前已经在 new_change 分支上。
在 new_change 分支上进行正常开发和修改即可。
修改完成后，先查看变动：
git status如果希望把当前所有修改都加入提交：
git add .如果只想提交某个文件：
git add 文件名例如：
git add src/App.jsxgit commit -m "完成某某功能修改"例如：
git commit -m "新增登录页面样式优化"提交信息建议写清楚本次改动内容，不要只写 update、test 这种过于模糊的内容。
git push -u origin new_change说明：
origin表示远端仓库new_change表示推送到远端同名分支-u表示建立本地与远端分支的跟踪关系
第一次推送后，后续再推送只需要：
git push代码推送成功后，进入 GitHub 仓库页面。
通常 GitHub 会出现提示：
Compare & pull request
点击后创建一个 Pull Request。
需要确认：
- base 分支：
main - compare 分支：
new_change
也就是表示：
把 new_change 的改动合并到 main
然后填写：
- 标题：本次修改的主要内容
- 描述：改了什么、为什么改、是否有注意事项
最后点击：
Create pull request
这样审核者就能看到你的代码改动。
审核者收到 Pull Request 后，进入 GitHub 的 PR 页面进行审核。
主要检查内容包括：
- 修改的文件是否正确
- 代码逻辑是否合理
- 是否有明显 bug
- 命名、格式是否规范
- 是否影响现有功能
审核者可以：
- 直接评论某一行代码
- 提出修改建议
- 同意通过审核
- 要求继续修改
如果审核者提出了修改意见，开发者继续在本地 new_change 分支上修改代码。
修改完成后再次执行：
git add .
git commit -m "根据审核意见修改代码"
git push因为之前已经建立了跟踪关系，所以这次直接 git push 就行。
推送后，Pull Request 会自动更新，审核者可以继续查看最新代码。
审核通过后，由有权限的人在 Pull Request 页面点击合并。
常见按钮是：
Merge pull request
然后确认合并。
合并完成后，new_change 分支中的内容就进入 main 分支了。
远端 main 更新后，开发者需要更新本地 main：
git checkout main
git pull origin main这样本地主分支就和 GitHub 上保持一致。
如果 new_change 已经完成任务，不再使用，可以删除。
git branch -d new_changegit push origin --delete new_change说明：
- 本地删除只是删除自己电脑上的分支
- 远端删除才是删除 GitHub 上的分支
下面是一套从开发到审核再到合并的完整示例。
git checkout main
git pull origin main
git checkout -b new_change
# 修改代码后
git add .
git commit -m "新增用户信息展示模块"
git push -u origin new_change然后去 GitHub 发起 new_change -> main 的 Pull Request。
- 打开 Pull Request
- 查看代码差异
- 发表评论或提出修改意见
- 审核通过后点击合并
git checkout main
git pull origin main
git branch -d new_change如果还要删除远端分支：
git push origin --delete new_change因为 main 是主分支，通常代表稳定版本。
如果大家都直接修改 main，很容易出现：
- 代码冲突
- bug 直接进入正式版本
- 审核流程失效
所以应该先在功能分支开发，再合并回 main。
可能会导致你的分支不是基于最新主线。 最好重新先执行：
git checkout main
git pull origin main然后再新建分支。
可以把最新 main 合并到自己的分支：
git checkout main
git pull origin main
git checkout new_change
git merge main如果有冲突，解决后再提交。
它表示建立“跟踪关系”。 设置以后，你在这个分支上后续直接执行：
git push就可以了，不用每次都写完整分支名。
Pull Request，简称 PR，意思是：
“我已经在自己分支改好了代码，请你审核，并把这些修改合并到目标分支。”
它是 GitHub 上最常用的团队协作方式。
建议团队统一遵守以下规则：
-
不直接提交到
main -
每个功能或修改新建独立分支
-
分支命名清晰，例如：
feature/login-pagefix/navbar-bugnew_change
-
commit 信息要明确
-
所有代码通过 PR 审核后再合并
-
合并完成后及时同步本地
main
标准流程就是：
先拉 main → 新建分支 → 在新分支修改 → push 到远端 → 发起 PR → 审核通过 → 合并到 main