用途：帮助团队在项目中应用一致的命名、结构与代码模式，使代码更易读、易维护。
适用时机：启动新项目或模块、按团队约定重构、配置或更新 lint/格式/类型检查规则、评审代码一致性、新人上手时记录或套用规范、强制命名与结构统一。
核心原则：可读性优先；KISS（用能工作的最简方案，避免过度设计与过早优化）；DRY（抽取公共逻辑，避免复制粘贴）；YAGNI（不为臆测的未来需求提前增加复杂度）；不可变性（优先 const，避免修改参数或共享状态，必要时用展开/复制）；错误需带上下文处理与传播；边界处显式类型，避免不必要的 any。
工作流程：先扫描现有代码发现项目约定（命名、文件布局、导入风格、测试模式，以及 CONTRIBUTING、.eslintrc、.prettierrc、editorconfig）；再将新增或改动代码与约定和规则对比找出违规；然后给出具体修改建议（重命名、抽取函数、加类型、修格式，一次一个逻辑改动）；最后记录例外情况，不要脱离上下文强行“修复”。
命名约定：变量与函数使用描述性名称，函数用动词-名词（如 marketSearchQuery、isUserAuthenticated、fetchMarketData）；真常量用 UPPER_SNAKE（如 MAX_RETRIES、API_BASE_URL）或遵循项目约定；类型与接口用 PascalCase（User、OrderItem、ApiResponse<T>），可按角色加后缀（CreateUserRequest）；文件方面组件用 PascalCase（Button.tsx），工具与 hooks 用 camelCase（formatDate.ts、useAuth.ts），类型文件按项目习惯（market.types.ts）。
其他要点：通过展开创建新引用而非直接改对象/数组；异步独立请求用 Promise.all 并行；用显式类型替代 any；注释解释“为什么”而非“做了什么”，公共 API 用 JSDoc；不保留注释掉的代码；文件与项目结构沿用现有布局；导入按 stdlib→第三方→本地分组。常见坏味道包括函数过长、深层嵌套、魔法数字、参数过多、重复逻辑，应拆分、提前返回、抽取常量、改用选项对象或共享函数。集成时优先对齐已有风格指南与 lint/格式配置，除非用户明确要求覆盖；建议给出具体编辑而非只列规则。具体价格与平台限制资料未提供。