codinglisted

# Coding and AI Development Standards ## Coding Standards - 实现前必须读 ADR-000（技术栈 SSOT，`CLAUDE.md ## Tech Stack` 为其摘要）确认技术选型；未经 tech-lead 确认，不引入 ADR-000 未列出的包或框架 - 前端 TypeScript，后端 Python（技术栈详见 ADR-000） - 使用 ESLint + Prettier 统一代码风格 - Git commit message 使用 Conventional Commits 格式 - 变量/函数命名使用 camelCase，类型/接口使用 PascalCase - 不添加不必要的注释，只注释 WHY 而非 WHAT - 优先编辑现有文件而非创建新文件 ### Verify before assert（基线引用纪律） 引用项目已有基线（架构 / 鉴权 / DB schema / API 契约 / hook / CLI 参数 / etc）做新决策或写新文档时，**必须先 grep 实际代码 verify**，即使来源是： - 上一份 ADR / spec / review 报告 - 团队 lead（含 tech-lead / product-lead）的口头描述或 SendMessage - CLAUDE.md Tech Stack 摘要（描述可能滞后于实现，技术选型以 ADR-000 为准） - 任务派工模板里的固定句式 **违规典型**：基于二手描述写新文档，不实证验证。一个真实发生过的链路：review 报告对鉴权契约的描述凭印象写错（未 grep 实际 client/router 代码）→ ��续 ADR 引用 review 继承误述 → spec 起草人引用 ADR 接着错 → 错误一路传到实现阶段才被发现，多份文档都得回头 patch。**链条上每个引用方都没 verify，任何一处 grep 就能斩断**。 **最小成本 verify 模板**（10 秒事）： ```bash grep -nE "<keyword>" <file_or_dir> # 关键字定位 git log --oneline --grep="<feature>" | head # commit 历史 ``` **适用范围**：所有 agent，**tech-lead 自身也不豁免**——上面那次违规链条的起点恰恰是 tech-lead。 ## AI Development Guidelines - 接入 LLM SDK 时优先启用 prompt caching（若厂商 SDK 支持） - Prompt 使用 XML 标签结构化（`<context>`, `<rules>`, `<output_format>`） - Agent 工具定义要有清晰无歧义的 description 和参数 schema - 实现 guardrail 防止 Agent 行为失控 - 记录 LLM 输入/输出用于调试和评估 ## LLM 行为铁律（全团队适用） > 本节是给执行层（含 lead）共用的日常工作纪律——不是项目级规则，而是"如何写代码 / 如何动 diff"的行为约束。结构借鉴 Karpathy 的 LLM coding guidelines（2026），按本团队已有规范裁剪后只保留增量条款；与 brainstorming / verify-before-assert