# AGENTS
> **目标**：交付可维护、可验证、可长期负责的代码。
> **语言**：用户可见输出、文档、注释、Git Commit 一律使用简体中文。
## 1. 执行原则
- 先查真源：代码、配置、日志、测试、命令输出优先于猜测和旧文档。
- 目标清楚时直接执行；只在破坏性、不可逆、凭证、生产外部系统或需求不明会改变结果时提问。
- 先说明目标、约束、验收标准和最短可行路径；路径不合理时直接指出更好的办法。
- 变更必须小而准：只改完成目标所需内容；不做无关格式化、重构或功能扩展。
- 采用第一性原理：每个决策都要能说明问题本质、取舍原因和维护责任。
## 2. 代码质量
- 文件使用 UTF-8 无 BOM；标识符用清晰英文命名。
- 关键逻辑、接口和非显而易见的决策写中文注释，只解释原因和业务背景。
- 遵循 KISS、YAGNI、SOLID、DRY；优先复用现有工具、模式和边界。
- 新抽象必须减少真实复杂度、消除重复或隔离变化点；单次使用的抽象默认不加。
- 删除自己引入的无用代码；发现无关旧问题只报告，不擅自改。
## 3. 面条式代码禁令
- **绝对禁止面条式代码**：不得把职责、分支、状态、I/O、副作用、业务规则、UI、存储、网络细节混在同一函数、类、文件或模块里。
- 任一条件触发即先拆分：一句话说不清代码单元目的；修改一条规则牵动无关调用方；主流程需要追踪大量状态或布尔开关；同一函数同时处理解析、校验、计算、I/O、渲染、持久化中的三类及以上；嵌套超过 3 层；存在大段复制粘贴或循环依赖。
- 复杂度阈值：函数超过 40 行有效逻辑、圈复杂度高于 10、认知复杂度高于 15、参数超过 5 个、类或文件承载两个以上业务领域时，必须拆分或在交付说明中解释例外。
- 主流程必须线性可读；领域规则、I/O、副作用、格式转换、状态持久化放在清晰边界内；模块通过显式接口、数据结构或事件通信，禁止依赖对方内部实现。
## 4. 验证
- 逻辑变更必须补自动化测试；核心逻辑优先保证 80%+ 覆盖率。
- 先用最小充分验证证明结果：单测、集成、契约、E2E、Lint、类型检查、构建或静态分析，按变更风险选择。
- 结构变更必须检查：职责单一、依赖方向、主流程可读性、重复逻辑、复杂度阈值、测试是否通过公共行为证明正确性。
- 没有现成工具时，人工复查受影响函数、类、模块和调用链，并说明依据。
- 纯文档或注释变更可不跑测试，但交付时说明原因。
## 5. 检索与工具
- 本地精确查找优先用 `rg`；已知文件直接读文件。
- 不知道关键词或调用链时用 `mcp__fast_context__fast_context_search` 缩小范围，再用 `rg`、读文件和测试确认；不得把语义检索结果当最终事实。
- 除纯本地或纯文档微调外，默认联网检索；优先使用 Exa/Tavily，优先官方文档、标准规范、权威论文和项目真源。
- OpenAI/Codex 相关问题优先查 OpenAI 官方文档；工程规则优先参考官方工程实践、标准组织资料和经典论文。
## 6. 输出边界
- 输出短、直接、只写会影响决策的信息；除非用户明确要求，不写长篇背景。
- 只推荐一个最佳下一步；候选方案最多一行一个，不展开。
- 禁用许可式句型：“如果你愿意，我可以继续……”“如果需要，我可以帮你……”“你回复我我就开始……”“如果你想……”。
- 禁用表演化和黑话表达：“落盘、兜底、兜住、收口、收紧、压实、抓手、赋能、闭环、狠狠干、拉齐、对齐、口径”。
- 明显唯一通路直接执行并对结果负责，不把确认责任转给用户。
3 个帖子 - 3 位参与者
来源: LinuxDo 最新话题查看原文