docs(agents): 完善 AGENTS.md 中的工作准则和规范细节
补充精准变更原则的约束条件,更新测试要求为更严格的核心逻辑验证策略, 细化依赖升级的分级策略,新增 Git Scope 推导规则和示例, 重构模块组织章节并提供完整目录结构示例,新增文档方案规范章节
This commit is contained in:
@@ -31,6 +31,8 @@
|
|||||||
### 3. 精准变更 (Surgical Changes)
|
### 3. 精准变更 (Surgical Changes)
|
||||||
**只改动必须改的。只清理你自己造成的混乱。**
|
**只改动必须改的。只清理你自己造成的混乱。**
|
||||||
|
|
||||||
|
- 未明确要求时不修改已有文件
|
||||||
|
- 先确认意图再动手
|
||||||
- 不要"优化"相邻的代码、注释或格式。
|
- 不要"优化"相邻的代码、注释或格式。
|
||||||
- 不要重构没有问题的代码。
|
- 不要重构没有问题的代码。
|
||||||
- 遵循已有风格,即使你自己的写法不同。
|
- 遵循已有风格,即使你自己的写法不同。
|
||||||
@@ -64,9 +66,9 @@
|
|||||||
- 变量/函数命名:`snake_case`
|
- 变量/函数命名:`snake_case`
|
||||||
|
|
||||||
**测试要求**
|
**测试要求**
|
||||||
- 新功能建议附测试;修复 bug 建议附回归测试(不主动编写测试)
|
- 核心业务逻辑需测试(关键算法、边界条件、错误处理)
|
||||||
- 简单明确的逻辑不需要创建测试(如枚举字面值、Getter、无分支的简单转换)
|
- 简单逻辑不需要测试(枚举字面值、Getter、无分支的简单转换)
|
||||||
- 测试结构:AAA 模式 (Arrange-Act-Assert),优先测试边界条件和错误场景
|
- 不主动补测试(除非用户明确要求)
|
||||||
|
|
||||||
**错误处理**
|
**错误处理**
|
||||||
- 优先使用 `Result` 处理错误,避免 `unwrap()`
|
- 优先使用 `Result` 处理错误,避免 `unwrap()`
|
||||||
@@ -76,7 +78,11 @@
|
|||||||
**安全规范**
|
**安全规范**
|
||||||
- 不硬编码密钥,使用环境变量
|
- 不硬编码密钥,使用环境变量
|
||||||
- 用户输入必须验证
|
- 用户输入必须验证
|
||||||
- 依赖包保持更新
|
- 依赖升级策略:
|
||||||
|
- **安全补丁**:立即升级(修复已知漏洞)
|
||||||
|
- **次要版本**:评估后升级(新功能、向后兼容)
|
||||||
|
- **主要版本**:谨慎升级(可能破坏兼容性,需全面测试)
|
||||||
|
- **验证**:升级后运行完整测试套件确保无回归
|
||||||
|
|
||||||
**Git Commit 规范**
|
**Git Commit 规范**
|
||||||
- 使用 Conventional Commits 格式:`<type>(<scope>): <description>`
|
- 使用 Conventional Commits 格式:`<type>(<scope>): <description>`
|
||||||
@@ -91,6 +97,17 @@
|
|||||||
- `test` - 测试相关
|
- `test` - 测试相关
|
||||||
- `chore` - 构建/工具/配置
|
- `chore` - 构建/工具/配置
|
||||||
- 描述使用祈使句、现在时态、句尾无句号
|
- 描述使用祈使句、现在时态、句尾无句号
|
||||||
|
- **Scope 推导规则**:
|
||||||
|
- 从被提交的文件路径中推导出一个最相关的 scope
|
||||||
|
- 一个 commit 只写一个主要 scope,不要罗列多个
|
||||||
|
- 如果改动涉及多个模块,选择影响范围最大的那个或使用更上层抽象名称
|
||||||
|
- 如果改动是全局的,可以省略 scope 或使用 `core`/`global`
|
||||||
|
- **示例**:
|
||||||
|
- `feat(llm): 添加流式响应支持`(修改 `src/llm/stream.rs`)
|
||||||
|
- `fix(memory): 修复向量检索边界条件`(修改 `src/memory/vector_store.rs`)
|
||||||
|
- `refactor(core): 统一错误类型定义`(修改多个模块的错误处理)
|
||||||
|
- `docs: 更新 API 文档`(全局文档更新)
|
||||||
|
- `chore(deps): 升级 tokio 到 1.40`(依赖更新)
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
@@ -106,7 +123,47 @@
|
|||||||
|
|
||||||
**模块组织**
|
**模块组织**
|
||||||
- 按功能领域组织模块(一个模块一个职责)
|
- 按功能领域组织模块(一个模块一个职责)
|
||||||
- 使用 Rust 新风格模块结构:`foo.rs` 作为模块根,子模块在 `foo/bar.rs`
|
- **2018+ 版风格**:使用 `foo.rs` 作为模块根,子模块放在 `foo/` 目录下
|
||||||
|
- **扁平优先**:如果模块没有子模块,直接用单个 `foo.rs` 文件
|
||||||
|
- **需要子模块时才用目录**:只有当模块需要组织多个子模块时才创建 `foo/` 目录
|
||||||
|
- **避免 `mod.rs`**:不使用 `foo/mod.rs` 风格,统一使用 `foo.rs` 作为模块根
|
||||||
|
- **公共 API 重导出**:在模块根中使用 `pub use` 重新导出子模块的公共类型,提供清晰的 API 边界
|
||||||
|
|
||||||
|
**示例结构图**:
|
||||||
|
```
|
||||||
|
src/
|
||||||
|
├── lib.rs # crate 根,声明顶层模块
|
||||||
|
├── llm.rs # LLM 模块(无子模块,扁平文件)
|
||||||
|
├── memory.rs # 记忆模块根(有子模块)
|
||||||
|
├── memory/
|
||||||
|
│ ├── conversation.rs # ✓ 子模块
|
||||||
|
│ └── vector_store.rs # ✓ 子模块
|
||||||
|
├── prompt.rs # 提示词模块根(有子模块)
|
||||||
|
├── prompt/
|
||||||
|
│ ├── template.rs # ✓ 子模块
|
||||||
|
│ └── optimizer.rs # ✓ 子模块
|
||||||
|
├── tool.rs # 工具模块根(有子模块)
|
||||||
|
├── tool/
|
||||||
|
│ ├── mcp.rs # ✓ 子模块
|
||||||
|
│ └── registry.rs # ✓ 子模块
|
||||||
|
└── agent.rs # Agent 模块根(有子模块)
|
||||||
|
└── agent/
|
||||||
|
├── runtime.rs # ✓ 子模块
|
||||||
|
└── planner.rs # ✓ 子模块
|
||||||
|
|
||||||
|
# ❌ 避免的风格
|
||||||
|
src/
|
||||||
|
└── memory/
|
||||||
|
└── mod.rs # ❌ 不使用 mod.rs 风格
|
||||||
|
|
||||||
|
# ✅ memory.rs 示例:声明子模块并重导出公共 API
|
||||||
|
pub mod conversation;
|
||||||
|
pub mod vector_store;
|
||||||
|
|
||||||
|
// 重导出常用类型,提供简洁的公共 API
|
||||||
|
pub use conversation::ConversationMemory;
|
||||||
|
pub use vector_store::VectorStore;
|
||||||
|
```
|
||||||
|
|
||||||
**测试文件**: 内联测试(`#[cfg(test)] mod tests {}`)或 `tests/` 目录
|
**测试文件**: 内联测试(`#[cfg(test)] mod tests {}`)或 `tests/` 目录
|
||||||
|
|
||||||
@@ -114,6 +171,22 @@
|
|||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
## 文档规范
|
||||||
|
|
||||||
|
### 方案规范 (docs/)
|
||||||
|
|
||||||
|
**编号规则**:创建新方案前必须先通过 shell 命令确认当前实际最大编号(Unix: `ls docs/` / Windows: `dir docs\`),禁止使用上下文中缓存的编号,如遇冲突自动递增
|
||||||
|
|
||||||
|
**方案文档结构**(6 项):
|
||||||
|
1. **背景与目标** - 问题描述、预期目标
|
||||||
|
2. **需求分析** - 功能需求、非功能需求
|
||||||
|
3. **方案设计** - 架构设计、模块划分、接口定义
|
||||||
|
4. **实现计划** - 任务拆解、优先级、时间估算
|
||||||
|
5. **风险评估** - 潜在风险、缓解措施
|
||||||
|
6. **验收标准** - 可验证的完成条件
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
## 项目特定规则
|
## 项目特定规则
|
||||||
|
|
||||||
### 项目结构
|
### 项目结构
|
||||||
|
|||||||
Reference in New Issue
Block a user