04b5836b39
后端： 1. 新增课表图片识别接口，支持上传截图后返回“可编辑草稿”（success / partial / reject），并补齐大图、空图、格式不支持、识别能力未配置等错误分支。 2. 课表识别服务接入多模态 Responses 链路，完善图片请求归一化与安全校验（大小、MIME、内容探测），并对识别结果做结构化清洗、强/弱约束校验、告警去重与默认文案兜底。 3. 新增 Ark Responses 统一客户端抽象，支持文本+图片输入、JSON对象输出、usage统计透传与不完整输出识别；同时补齐模型返回 finish_reason 透传，便于定位截断问题。 4. 启动阶段增加课表识图模型与参数注入（模型名、最大图片字节、最大输出token），并将配置示例收敛为“仅保留当前代码实际读取项”。 前端： 5. 课表中心新增“导入课表”完整闭环：上传图片识别、草稿编辑校对、正式导入落库；并新增对应 API 与类型定义。 6. 导入弹窗支持识别中止、全局告警与行级告警展示、低置信度提示、行内编辑、手动新增、删除、拖拽排序、本地校验与提交前二次确认。 7. 正式导入前将草稿按“课程名+地点+是否允许嵌入”聚合为导入结构，并统一携带幂等键请求头，降低重复提交风险。 8. 周课表画板修复跨节次事件遮挡导致的网格错位问题，改进“完全遮挡/部分遮挡”渲染判定与 grid 行定位。 9. 助手流式区域优化“思考中”指示逻辑与样式，避免已有正文时仍展示回答中占位；同时补充全局组件视觉统一（弹窗/按钮）样式。 仓库： 10. 新增课表图片识别前端对接说明文档，补充主动优化能力 PRD 讨论稿，并在协作规范中新增“实现 Eino 新能力前需先查官方文档”的约束。
51 lines
4.0 KiB
Markdown
51 lines
4.0 KiB
Markdown
# AGENTS.md
|
||
|
||
## 协作偏好（逐条追加）
|
||
|
||
1. 默认语言规则：所有注释、接口文案、说明、评审反馈均使用中文。
|
||
2. 请勤加注释，尤其是复杂逻辑部分，确保代码易于理解和维护。
|
||
3. 每次在本地执行测试命令（如 `go test`）后，必须清理项目根目录下的 `.gocache` 目录，避免缓存文件长期堆积。
|
||
4. 文件编码统一使用 UTF-8（无 BOM），禁止使用 GBK、GB2312 等其他编码，避免中文内容出现乱码。
|
||
5. 进行结构重构时，优先采用“并行迁移”策略：允许新旧目录并存，先迁移、再切流、再验证、最后删除旧实现，禁止一步到位式重命名大改。
|
||
6. 遇到公共能力（如模型调用、JSON 解析、阶段推送、深拷贝、缓存快照读写）时，若在第二处出现重复实现，必须优先评估是否抽公共层，禁止无脑复制第三份。
|
||
7. 迁移期每一轮只允许处理一个能力域或一类公共件，禁止同一轮同时改多个 skill 的结构与逻辑，避免回归问题无法定位。
|
||
8. 新增代码时，必须优先复用已有公共能力；如果暂时无法复用，必须在注释或文档中写明“为什么这次不能抽公共层”，禁止默认复制粘贴旧实现。
|
||
9. 对于明显过大的文件（尤其是同时承载编排、业务、模型交互、工具分发的文件），后续重构时必须拆分职责，禁止继续向单文件堆砌新逻辑。
|
||
10. Prompt、State、模型交互、Graph 连线应尽量分目录/分文件管理，禁止把大段 prompt、节点逻辑、模型 helper 长期混写在同一文件中。
|
||
11. 若本轮任务包含“结构迁移”，最终答复中必须明确说明：本轮迁了什么、哪些旧实现仍保留、当前切流点在哪里、下一轮建议迁什么。
|
||
12. 若后续在 `backend/agent` 中新增、下沉、替换任何“通用能力”，必须同步更新 `backend/agent/通用能力接入文档.md`，否则视为重构信息不完整。
|
||
13. 写完代码后，如果输入输出格式明确、逻辑可验证（如数据转换函数、解析函数、工具层操作），必须编写单元测试验证正确性。跑完之后删除测试文件（`*_test.go`），禁止把测试文件长期留在项目中。
|
||
14. 当 Claude Code 帮助操作 git 提交时，commit message 中禁止出现与 Claude 协同相关的描述（如 Co-Authored-By 等），只保留项目本身的内容。
|
||
15. 实现任何 Eino 新功能之前，必须先阅读 Eino 官方文档并确认对应能力的推荐接入方式与参数语义，禁止在未查文档的情况下直接编码。
|
||
|
||
## 注释规范（强制）
|
||
|
||
1. 默认使用中文注释，禁止英文注释（专业术语除外）。
|
||
2. 复杂逻辑必须写“步骤化注释”，用 `1. / 2. / 2.1` 这种编号，说明：
|
||
- 这一步要做什么
|
||
- 为什么要这样做
|
||
- 失败时怎么处理
|
||
- 兜底/回退策略是什么
|
||
3. 函数注释至少说明“职责边界”：
|
||
- 这个函数负责什么
|
||
- 不负责什么
|
||
- 输入输出语义（尤其是 bool、error、状态字段）
|
||
4. 涉及分支、重试、事务、幂等、并发、状态机的代码，必须写清楚判断依据与流转条件。
|
||
5. 跨文件调用前必须写“调用目的注释”，让读者不跳转文件也能理解当前代码意图。
|
||
6. 注释禁止空话（如“设置变量”“调用方法”）；必须写业务意图与约束。
|
||
7. 改动代码时，如修改了复杂逻辑，必须同步更新注释；注释过期视为不合格提交。
|
||
8. 不要求每行都注释；简单直白代码可省略，重点保证关键路径可读性。
|
||
|
||
## 注释风格示例
|
||
|
||
推荐：
|
||
- `// 1. 先查缓存，命中则避免回源 DB，降低接口延迟。`
|
||
- `// 2. 缓存未命中再查库；若查库失败直接返回，避免写入不完整状态。`
|
||
- `// 3. 写库成功后再更新缓存，保证“先真后快”，避免脏缓存。`
|
||
|
||
不推荐：
|
||
- `// 查询缓存`
|
||
- `// 调用 DAO`
|
||
- `// 返回结果`
|
||
|