study-tool
585a7a28dd
- settings: study.mode fast|normal and study.parallel 1-5 - normal mode: one headless browser per video, visibility keep-alive, auto-degrade when the platform enforces order - report study/log/detail/save before isComplete; drop lastProgressTime on completion - complete periodType 10/13 container nodes and recompute counters via PUT calFinalScore - capture mode: POST /api/capture records all XHR/fetch including new tabs - UI: study mode in settings, capture / stop-capture menu items
38 lines
2.6 KiB
Markdown
38 lines
2.6 KiB
Markdown
# AGENTS.md
|
|
|
|
本文档用于约束本项目中的 AI / 自动化开发行为。开发时优先遵循本文件，其次遵循用户当前消息。
|
|
|
|
## 基本原则
|
|
|
|
- 先读现有代码，再动手修改，优先沿用项目已有结构和写法。
|
|
- 写代码保持最少行数，能简单实现就不要引入复杂抽象。
|
|
- 标准格式、协议、解析、压缩、加密、日期等通用能力优先使用成熟稳定的库，不要手写底层实现，除非用户明确要求或项目已有实现必须沿用。
|
|
- 不要为了“兼容更多场景”写大量分支，只实现当前明确需要的功能。
|
|
- 项目尚未上线，不需要兼容旧数据；表结构或字段调整时直接按新设计修改，不写旧字段兼容、数据迁移兜底或删除旧表的清理逻辑，除非用户明确要求。
|
|
- 每次写完代码，不需要检查语法，不需要执行构建，用户会自己做。
|
|
- 不要改无关文件，不要顺手重构。
|
|
- 任何文件编辑、改动、删除或格式化前，必须先询问用户是否允许；只有得到明确同意后才能修改。
|
|
- 如果工作区已有用户改动，不要回滚，不要覆盖；只在必要范围内追加修改。
|
|
|
|
## 反复提醒沉淀
|
|
|
|
- 如果开发过程中总是遇到某个问题，或者用户反复提醒同一个注意事项，需要把该注意事项补充到本文件。
|
|
- 补充时写成明确、可执行的规则，避免只写模糊描述。
|
|
- 新规则应放到最相关的章节；找不到合适章节时放到“项目注意事项”。
|
|
|
|
## 文档规范
|
|
|
|
- README 保持简洁，只放项目介绍、核心功能、快速开始和文档入口。
|
|
- 后续待办写到 `docs/progress/todo.md`。
|
|
- 已实现但还需要用户测试确认的事项写到 `OPTIMIZATION.md`。
|
|
- 每次任务完成前，都要根据实际变更检查并更新 `OPTIMIZATION.md` 和 `OPTIMIZATION.md`；如果功能或待办没有变化，也要确认无需修改。
|
|
- 文档不要写过期日期；除非用户明确要求记录具体时间。
|
|
|
|
## 发版本流程
|
|
|
|
- 发版本时，先把 `CHANGELOG.md` 的 `Unreleased` 变更整理成新的版本记录，并保留空的 `Unreleased` 标题。
|
|
- 每次提交必须将当前版本号进行提升，更新 `metadata.yaml`里面的`version`中的版本号。
|
|
- 将当前未提交的代码全部提交到 Git。
|
|
- 提交完成后，给当前提交打最新版本号对应的 tag，例如 `v0.0.5`。
|
|
- 发版本流程中不要执行编译、测试或构建，除非用户明确要求。
|
|
- 如果触发重要的决策，你需要将代码提交到`git`中，并且将本次已经修改的内容进行总结 |