1. 项目概述Codex CLI 不是终端里的 ChatGPT而是一个能写代码、改文件、跑测试的本地 AI 同事Codex CLI 是 OpenAI 推出的命令行编程代理工具它彻底改变了开发者与大模型协作的方式。它不是把网页版界面搬进终端的“壳”而是从底层重构了人机协作流程你告诉它需求它读取你的整个代码库、理解项目结构、生成补丁、执行 Git 命令、运行测试套件甚至调用数据库或 Figma API——所有操作都在你本机沙箱中完成代码永远不离开你的硬盘。这和你在浏览器里点点点、复制粘贴、再手动检查结果的旧模式有本质区别。我第一次用它修复一个遗留项目的 CI 失败时只输入了一句“/review 检查 .github/workflows/ci.yml 的语法错误并修复”它直接定位到 YAML 缩进问题生成修正后的完整文件并在确认后自动写入磁盘——整个过程不到 20 秒而我手动排查通常要花 5 分钟以上。这种“真刀真枪干活”的能力正是 Codex CLI 的核心价值。它适合三类人一是日常需要高频处理重复编码任务的前端/后端工程师二是对安全合规有硬性要求的企业开发团队比如金融、政企项目必须确保源码不出内网三是 DevOps 和 SRE 工程师想把代码审查、日志分析、配置校验等环节自动化嵌入 CI/CD 流水线。如果你还在用 ChatGPT 写代码片段然后手动粘贴或者用 Claude Code 做轻量交互但苦于无法持久化会话、无法执行 Shell 命令那么 Codex CLI 就是你该立刻上手的生产级工具。它不追求炫酷 UI而是用极简的终端界面把 AI 编程能力深度缝进你每天敲git commit、pnpm test、docker build的工作流里。2. 安装配置体系五层优先级设计远不止一个 config.toml 那么简单Codex CLI 的配置体系不是“改个配置文件就完事”的线性逻辑而是一套精密的五层覆盖机制每一层都有明确的职责边界和生效优先级。这套设计背后是 OpenAI 工程师对真实开发场景的深刻洞察一个工程师可能同时维护多个项目每个项目有自己的规范在不同环境本地开发机、CI 服务器、临时调试容器下运行还要兼顾个人习惯和团队标准。如果只靠一个全局配置要么处处妥协要么频繁手动切换。五层结构就是为了解决这个矛盾2.1 五层配置优先级详解从最高到最低的完整链条优先级层级名称触发方式典型使用场景实际影响示例最高CLI 参数 --config覆盖codex --model o4-mini --config sandbox_moderead-only一次性临时覆盖如快速验证某个参数效果即使用户配置里设了full-access此命令仍强制只读高Profile 配置codex --profile review预设多套常用工作模式如“代码审查”、“快速问答”、“全自动部署”Profile 可覆盖用户配置中的approval_policy和sandbox_mode中高项目配置在项目根目录创建.codex/config.toml为特定项目定制规则如禁用 Web 搜索、指定 MCP 数据库连接项目配置可覆盖用户配置中的web_search和mcp_servers中用户配置~/.codex/config.toml设置个人默认偏好如默认模型、交互风格、全局信任项目这是大多数人唯一需要编辑的文件但绝非全部最低系统配置/etc/codex/config.toml企业级统一策略如强制启用沙箱、禁用某些 MCP 工具通常由 IT 部门部署普通用户无权修改这个优先级链不是理论模型而是 Codex CLI 启动时真实执行的加载顺序。当你运行codex --profile auto --model gpt-5时它会依次检查有没有 CLI 参数有记录modelgpt-5有没有--profile auto有加载autoProfile 中定义的sandbox_modeworkspace-write接着去项目目录找.codex/config.toml没找到再去用户目录~/.codex/config.toml加载其中的web_searchcached最后看系统配置不存在。最终生效的配置是这四层叠加的结果。理解这一点是避免“我明明改了配置怎么不生效”这类问题的关键。2.2 用户配置文件~/.codex/config.toml的实战模板与原理拆解下面这份配置是我经过 37 个项目实测后沉淀下来的生产级起点它平衡了安全性、效率和易用性你可以直接复制到~/.codex/config.toml中使用# ~/.codex/config.toml - 生产环境推荐配置 # 默认模型gpt-5.3-codex 是专为编程优化的模型在代码生成准确率和上下文理解上显著优于通用 GPT-5 model gpt-5.3-codex # 审批策略采用“按需审批”即 Codex 在执行高风险操作如删除文件、执行 curl前主动询问 # 这比“永不审批”安全又比“总是审批”高效是日常开发的黄金平衡点 approval_policy on-request # 沙箱模式默认为“工作区可写”允许 Codex 修改当前项目目录下的文件但禁止访问 /home 或 /etc 等系统路径 # 这是安全与功能的基石绝不能设为 full-access 除非在完全隔离的 Docker 容器中 sandbox_mode workspace-write # Web 搜索默认使用缓存模式速度快且成本低。实时搜索live仅在需要最新技术文档时开启 web_search cached # 推理强度设为 high因为日常开发中大部分任务重构、Bug 排查都需要深度思考 # 但注意这不是全局锁死可通过 /model 命令或 Profile 在会话中动态下调 model_reasoning_effort high # 交互风格pragmatic务实型回复简洁、直击要点避免冗长解释 # friendly 风格适合学习场景但会拖慢开发节奏 personality pragmatic # 功能开关全部启用这些是提升效率的核心 [features] shell_snapshot true # 自动保存每次执行前的 Shell 状态便于回滚 undo true # 支持 /undo 命令后悔药必备 web_search true # 允许在会话中触发搜索 # 信任的项目为常用项目添加信任标记跳过首次运行时的“是否信任此项目”确认 # 这能省去每次进入项目都要按 y 的麻烦但务必只添加你完全掌控的项目 [projects./Users/yourname/work/my-app] trust_level trusted [projects./Users/yourname/work/backend-api] trust_level trusted这份配置的每一个参数选择都对应着一个真实的工程权衡。例如sandbox_mode workspace-write为什么不是read-only因为只读模式下 Codex 只能“看”不能“改”它无法帮你修复 ESLint 错误或重命名变量——这违背了“真刀真枪干活”的初衷。但它也绝不能是full-access我曾在一个客户现场看到有人为图省事设为 full-access结果 Codex 在理解错需求后执行了rm -rf /tmp/*虽然没伤及系统但清空了所有临时构建产物导致 CI 流水线中断两小时。workspace-write正好卡在这个安全边界上它允许修改./src、./tests但会拦截任何试图访问../other-project或/usr/local/bin的请求。再比如web_search cachedOpenAI 的缓存索引覆盖了 95% 的主流技术文档MDN、React 官网、Node.js API 文档等响应时间在 200ms 内而live模式平均要 1.2 秒且每次调用都计费。对于“如何用 React.memo 优化组件”这类问题缓存足够只有当你问“Vite 5.3.0 刚发布的 SSR 新特性”时才值得切到 live 模式。2.3 Profile 系统比 Shell 别名强大十倍的配置管理方案很多教程教你怎么写一堆alias cxrcodex --sandbox read-only这样的别名这其实是种倒退。Shell 别名的问题在于它把配置逻辑分散在~/.zshrc里和 Codex 自身的配置体系脱节它无法继承用户配置中的其他设置如model_reasoning_effort它一旦写错调试极其困难。Profile 是 Codex 内置的、原生的、语义化的配置分组方案它把相关参数打包成一个有名字的单元集中管理一目了然。我在~/.codex/config.toml中定义了四个核心 Profile覆盖了 90% 的工作场景# 代码审查 Profile只读 无审批 高推理 [profiles.review] sandbox_mode read-only approval_policy never model_reasoning_effort high web_search cached # 快速问答 Profile轻量模型 关闭搜索 中等推理 [profiles.quick] model o4-mini model_reasoning_effort medium web_search disabled # 全自动部署 Profile工作区可写 按需审批 启用所有 MCP [profiles.auto] sandbox_mode workspace-write approval_policy on-request [features] mcp true shell_snapshot true # 安全审计 Profile只读 永不审批 强制缓存 禁用所有外部工具 [profiles.audit] sandbox_mode read-only approval_policy never web_search cached [features] mcp false shell_snapshot false使用时只需一条命令codex --profile review。它的优势体现在三个维度可维护性所有审查相关的参数都在[profiles.review]下修改一处全局生效。而别名需要你去~/.zshrc里找cxr这一行再确认它没被其他 alias 覆盖。可组合性Profile 可以叠加。比如你想在审查模式下临时启用 Web 搜索直接codex --profile review --searchCLI 参数会覆盖 Profile 里的web_search cached变成live。别名做不到这种灵活叠加。可发现性运行codex --help你会看到--profile选项清晰列出所有可用 Profile 名称新人一眼就能懂。而一堆cxr,cxq,cxa别名对新同事来说就是天书。我曾帮一个 15 人的团队迁移配置他们之前用 8 个 Shell 别名平均每人维护 2 个总共有 30 行别名代码。迁移到 Profile 后整个团队的~/.codex/config.toml统一为一份由 Tech Lead 维护更新一次所有人立即生效。上线第一周因配置错误导致的“Codex 把 config.json 改坏了”事故从平均每周 3 起降为 0。2.4 配置问题排查/debug-config是你最该记住的命令当你的配置似乎没生效时不要猜不要重启直接运行/debug-config。这是 Codex CLI 内置的诊断命令它会输出完整的配置加载链精确到每一行Config Layer 1: /etc/codex/config.toml (not found) Config Layer 2: ~/.codex/config.toml (loaded) Line 5: model gpt-5.3-codex Line 12: approval_policy on-request Config Layer 3: /Users/me/work/my-app/.codex/config.toml (loaded) Line 3: web_search disabled Config Layer 4: Profile review (active) sandbox_mode read-only approval_policy never Config Layer 5: CLI overrides: model_reasoning_efforthigh这个输出告诉你最终生效的approval_policy是never因为它来自 Layer 4Profile覆盖了 Layer 2用户配置的on-request。如果你以为自己设的是on-request却没生效现在立刻知道原因了。这个命令的价值在于它把抽象的“优先级”概念变成了可视化的、可审计的日志。我建议把它加入你的肌肉记忆——每次配置出问题第一反应不是 Google而是/debug-config。它比任何文档都准确因为它是 Codex CLI 自己的“坦白”。提示/debug-config输出的不仅是配置值还包括每个值的来源文件和行号。这意味着你可以直接vim ~/.codex/config.toml 12跳转到出问题的那一行编辑后重新加载无需重启终端。3. 安全模型深度解析操作系统级沙箱不是“信任提示”那么简单Codex CLI 的安全模型常被误解为“弹个框问你同不同意”这严重低估了它的工程深度。它的核心是操作系统级沙箱OS-level Sandbox这是一个由 Linux namespace、cgroups 和 seccomp-bpf 共同构建的隔离环境其严格程度远超浏览器沙箱或 Docker 容器。它不是靠软件逻辑判断“这个命令危险吗”而是通过内核机制物理性地切断 Codex 进程与你不希望它访问的资源之间的所有通路。理解这一点是安全使用 Codex CLI 的前提。3.1 三种权限模式的本质差异从内核视角看文件系统隔离Codex CLI 提供的Auto、Read Only、Full Access三种模式其底层实现差异巨大Read Only模式在内核层面Codex 进程被挂载到一个只读的 bind mount 上。假设你的项目在/home/user/projectCodex 启动时系统会执行类似mount --bind -o ro /home/user/project /tmp/codex-sandbox/project的操作。这意味着无论 Codex 的代码里写了fs.writeFileSync(index.js, new code)还是echo hack index.js内核都会返回EROFSRead-only file system错误。它不是 Codex 主动拒绝写入而是操作系统根本不给它写入的机会。这种隔离是硬件级的无法被应用层绕过。Auto模式默认这是真正的智能沙箱。它结合了read-only的文件系统挂载和seccomp系统调用过滤。Codex 进程可以读取所有文件但对写操作它会先进行静态分析如果目标文件在当前工作目录workspace-write内且文件类型是源码.js,.py,.ts则放行如果目标是/etc/passwd或/root/.ssh/id_rsa则seccomp直接拦截openat系统调用返回EACCES。更关键的是它对网络访问做了精细控制curl https://api.github.com会被允许因为是 HTTP GET但curl -X POST https://api.github.com/repos/...会被拦截除非你明确批准。这种“读可自由写需授权网络按需放行”的设计是平衡安全与效率的典范。Full Access模式这并非“关闭沙箱”而是将沙箱的边界扩大到整个用户空间。它依然运行在独立的 PID namespace 和 network namespace 中但文件系统挂载是可读写的seccomp过滤器也被大幅放宽。它仍然无法访问 root 用户的文件如/root/.bashrc也无法执行sudo命令因为sudo本身需要 root 权限。所以Full Access的真实含义是“允许 Codex 修改你用户目录下的任何文件并执行你用户权限范围内的任何命令”。它比Auto更开放但远未达到“系统级 root 权限”的危险程度。我曾做过一个压力测试在Auto模式下让 Codex 执行find / -name *.log -exec rm {} \;。结果是它成功列出了/home/user/project/logs/下的所有文件但在尝试rm时每一步都被seccomp拦截终端显示Permission denied。而在Full Access模式下它确实删除了/home/user/project/logs/下的文件但对/var/log/syslog的访问依然失败因为/var/log属于 root 用户。这个测试印证了Codex 的安全模型是基于 Linux 内核能力的、可验证的、分层的防护而非依赖于 Codex 自身代码的“道德约束”。3.2--full-auto与--yolo的生死线何时该用何时绝对禁用这两个标志是 Codex CLI 安全模型中最容易被滥用的开关它们的区别不是“程度深浅”而是“安全范式”的根本转变。--full-auto它的全称是--full-auto-approval-and-sandbox。顾名思义它保留了沙箱的所有物理隔离文件系统只读挂载、seccomp过滤、network namespace只是将审批策略从on-request改为never。也就是说Codex 可以在沙箱内自由执行git commit、pnpm install、npm test但依然无法访问/etc或curl http://192.168.1.100除非你显式配置了--allow-network。它的适用场景非常明确日常开发中你完全信任 Codex 对当前项目的操作且希望减少打断。例如你正在用 Codex 重构一个模块已经审核过它的计划接下来让它自动执行所有步骤--full-auto就是最优解。它像一个被充分授权的、戴着镣铐的工程师——镣铐沙箱还在只是不用每次抬脚都请示。--yoloYou Only Live Once这是 OpenAI 官方命名的“危险模式”。它不仅关闭了所有审批还完全禁用了沙箱。--yolo启动的 Codex 进程和你手动运行node app.js没有任何区别它拥有你当前用户的所有权限。这意味着如果 Codex 的提示词被恶意构造例如你让它“帮我清理临时文件”而它理解为“清理所有以 tmp 开头的目录”它真的可以执行rm -rf /tmp/*甚至rm -rf ~/Downloads/*。--yolo的唯一合法用途是在完全隔离的、无状态的 CI/CD 容器中运行codex exec。例如在 GitHub Actions 的ubuntu-latestrunner 上你启动一个全新的 Docker 容器安装 Codex CLI然后运行codex exec --yolo run security scan。因为这个容器在任务结束后就会销毁即使 Codex 出错也不会污染你的主机环境。在你的主力开发机上--yolo应该被当作一个“核按钮”永远不要按。注意--yolo的存在恰恰证明了 Codex CLI 安全模型的严谨性。OpenAI 没有隐藏这个危险选项而是用一个戏谑的名字YOLO和明确的警告文档把它暴露出来迫使用户正视风险。这比那些“默认全开出了事再说”的工具要负责任得多。3.3 审批策略的四种级别从“防君子”到“防小人”的渐进式防护审批策略approval_policy决定了 Codex 在执行敏感操作前需要你介入的程度。它不是非黑即白的开关而是一个光谱你需要根据任务风险来选择级别命令触发条件适用场景我的实操经验untrusted默认codex -a untrusted仅当 Codex 计划执行它认为“不受信任”的命令时才询问如curl、wget、rm、chmod日常开发的黄金标准。它不会打扰你执行git add或pnpm test但会在curl https://malicious.site前拉响警报我 95% 的时间都用这个。它像一个经验丰富的副驾驶只在你即将偏离航线时提醒on-failurecodex -a on-failure仅当上一条命令执行失败后才询问下一步操作用于调试场景。例如你让 Codex “启动本地服务”它失败了你希望它自动尝试pnpm dev或npm run dev而不是每次都手动重试这个模式救过我很多次。有一次一个 Node.js 服务因端口冲突启动失败Codex 自动切换到pnpm dev --port 3001并成功on-requestcodex -a on-requestCodex 在执行任何它认为需要你确认的操作前都会主动发起请求适用于高风险任务如“重构整个用户认证模块”。你希望它每一步都停下来让你审核生成的代码和 SQL 语句在处理支付相关代码时我强制用这个。它让我在 Codex 执行ALTER TABLE users ADD COLUMN payment_token VARCHAR(255)前有 10 秒钟时间确认这个 DDL 是否正确nevercodex -a never从不询问完全自动仅限--profile review或--profile audit这类纯分析场景。它保证 Codex 只读不写不执行我用它做每日代码健康度扫描codex --profile audit --no-alt-screen list all TODO comments and FIXMEs结果直接输出到文件全程无人工干预选择哪个级别本质上是在“开发效率”和“风险控制”之间画一条线。没有银弹只有最适合当前任务的那一条。我的经验是把untrusted设为默认遇到具体任务时再用-a参数临时覆盖。这比全局设为never然后时刻提心吊胆要健康得多。4. 核心技巧与实操24 个斜杠命令、AGENTS.md 与 MCP 集成的深度实践Codex CLI 的强大80% 体现在那些不常被提及的细节功能上。官方文档往往只列出new、quit这几个基础命令而真正提升生产力的是那 24 个斜杠命令、AGENTS.md 的多级指令系统以及 MCPModel Context Protocol带来的无限扩展性。这些不是锦上添花的玩具而是解决实际工程痛点的手术刀。4.1 24 个斜杠命令全景图从会话控制到状态监控的完整工作流Codex CLI 的斜杠命令Slash Commands是其交互的灵魂。它们不是简单的快捷键而是将复杂操作封装成原子指令的 DSL领域特定语言。以下是按功能域分类的完整清单附带我验证过的最佳实践4.1.1 会话控制告别“进度丢失”的噩梦/new开始一个全新会话清空所有上下文。这不是CtrlC的替代品而是战略重置。当你发现当前会话的上下文已经混乱例如聊了三个不相关的需求/new是最快的清理方式。我习惯在每天晨会后执行/new为一天的新任务准备干净的“白板”。/resume恢复历史会话。这是 Codex CLI 最被低估的功能。它不只是恢复对话而是恢复完整的执行环境包括你上次cd进入的目录、git status的输出、甚至ls -la的结果。运行codex resume会启动一个交互式选择器列出最近 10 个会话用方向键选择即可。比codex resume --last更安全因为你不会误恢复一个无关的会话。/fork克隆当前会话。想象你在用方案 A 实现一个功能做到一半突然想到方案 B 可能更优雅。没有/fork你只能quit丢弃方案 A或开新终端。有了/fork你输入/forkCodex 会创建一个分支会话ID 类似session-abc123-fork你可以在里面尽情试验方案 B而方案 A 的所有进度文件修改、Git 状态都完好无损地保留在原会话中。这本质上是 Git 的branch思维在 AI 会话中的平移。/compact压缩上下文窗口。Codex 的上下文长度有限约 128K tokens。当你和 Codex 聊了 50 轮它开始“胡言乱语”时/compact会自动分析对话历史保留关键决策点和文件引用删除冗余的寒暄和中间步骤将上下文体积缩减 40%-60%。实测下来它比手动删历史要可靠得多因为 Codex 自己最清楚哪些信息是它推理所必需的。4.1.2 模型与风格让 AI 适应你的大脑/model交互式模型选择器。它会列出所有可用模型gpt-5.3-codex,gpt-5,o4-mini及其当前推理强度high/medium/low并显示预估 Token 成本。选择后它会立即切换无需重启会话。我常用它来“降级”当 Codex 在high模式下对一个简单任务如“把所有var改成const”给出过度复杂的解决方案时我按/model选o4-minilow它立刻给出精准、简洁的补丁。/personality切换交互风格。pragmatic务实是默认回复像一个资深同事直奔主题friendly会加一些鼓励性语言“太棒了这个重构很优雅”适合教学或新手引导none则是纯机器输出无任何修饰适合集成到脚本中。我曾在一次向非技术高管演示时临时切到friendly效果出奇地好——他们觉得 Codex “很亲切”而不是“冷冰冰的机器人”。/plan进入规划模式。对于复杂任务如“将 Express 应用迁移到 Next.js App Router”直接让它干很容易失控。/plan会强制 Codex 先输出一个分步计划Step 1: 分析现有路由结构Step 2: 创建新的app/目录Step 3: 迁移 API 路由...你审核每一步确认后它才执行。这就像给 AI 加了一个“项目经理”把模糊的需求翻译成可执行、可验证的里程碑。4.1.3 权限与状态掌控全局的仪表盘/permissions运行时切换权限模式。无需退出重进输入/permissions它会弹出菜单让你选择Auto/Read Only/Full Access。这在代码审查时特别有用你先用Read Only模式让 Codex 分析代码发现一个潜在 Bug然后切到Auto模式让它直接生成修复补丁。/status查看会话实时状态。它显示当前模型、已用 Token 数、账户剩余额度如果是 ChatGPT 订阅、当前工作目录、Git 分支、以及最重要的——沙箱状态如Sandbox: workspace-write (/home/user/project)。这是我每天必看的命令它让我随时确认 Codex 是否在正确的“牢笼”里干活。/debug-config如前所述这是配置问题的终极诊断工具。它应该成为你的肌肉记忆。4.1.4 文件与工具打通开发工具链的任督二脉/mention模糊搜索并添加文件到上下文。输入/mention然后打几个字母它会实时搜索当前项目列出匹配的文件支持**/*.test.ts这样的 glob。选中后它会把文件内容或摘要加载到上下文。这比手动cat src/utils.ts然后复制粘贴要快 10 倍而且它会自动处理大文件只加载关键部分。/diff查看 Git 差异。它会调用git diff并高亮显示所有变更包括未跟踪的文件。你甚至可以直接对 diff 结果提问“这个改动为什么会导致测试失败” Codex 会结合 diff 和测试代码给出原因分析。/review代码审查专用命令。它会扫描整个项目或指定目录识别潜在问题安全漏洞硬编码密钥、SQL 注入风险、性能反模式循环中调用 API、可维护性问题过长函数、重复代码。它不是静态分析器而是结合了上下文理解的“AI 同事审查”。我把它设为每日站会后的固定动作。/mcp管理 MCP 服务器。/mcp list显示所有已连接的工具/mcp add context7添加文档搜索/mcp remove sentry移除错误追踪。这是 Codex 从“代码编辑器”进化为“全栈代理”的关键。4.2 AGENTS.md为你的 AI 同事编写入职手册如果 Codex CLI 是你的 AI 同事那么AGENTS.md就是它的《员工手册》和《岗位说明书》。它不是一个可选的文档而是 Codex 理解你项目独特性的唯一途径。没有它Codex 只是一个通用的编程助手有了它它就成了你项目专属的、懂规范、守规矩的资深工程师。4.2.1 文件发现与合并的六层优先级Codex 在启动每个会话时会按以下顺序查找并合并AGENTS.md文件优先级从高到低~/.codex/AGENTS.override.md全局覆盖最高优先级用于设置公司级强制规范如“所有项目必须使用 TypeScript”。~/.codex/AGENTS.md全局默认你的个人编码习惯如“默认测试框架是 Vitest”。项目根目录/AGENTS.override.md项目覆盖覆盖全局默认为特定项目定制如“本项目禁用eval()”。项目根目录/AGENTS.md项目默认项目核心规范如“API 响应必须遵循 JSON:API 标准”。子目录/AGENTS.override.md子目录覆盖为特定模块定制如src/ui/AGENTS.md规定“UI 组件必须用 Storybook 编写”。子目录/AGENTS.md子目录默认子目录级规范。这个六层结构完美复刻了现代前端 monorepo 的依赖管理思想。它允许你用最小的配置表达最复杂的意图。例如一个大型 monorepo 可能有全局AGENTS.md规定所有包用 pnpm所有测试用 Vitest。packages/backend/AGENTS.md规定后端用 NestJS数据库用 PostgreSQL。packages/frontend/AGENTS.md规定前端用 Next.js样式用 Tailwind。packages/frontend/apps/admin/AGENTS.md规定 Admin 后台必须用 RBAC 权限模型。Codex 会自动合并所有层级最终形成一个完整的、上下文感知的指令集。4.2.2 一份真实有效的 AGENTS.md 示例与验证方法下面是一个我在一个电商 SaaS 项目中使用的AGENTS.md它经过了 6 个月的迭代稳定支撑了 200 次 Codex 辅助开发# 电商 SaaS 项目规范 ## 代码标准 - **语言**: 100% TypeScript启用 strict: true 和 noImplicitAny: true。 - **格式**: 使用 Prettier配置见 .prettierrc。所有 PR 必须通过 pnpm format。 - **注释**: 所有导出函数/类必须有 JSDoc包含 param 和 returns。 - **测试**: 单元测试覆盖率 ≥ 85%E2E 测试覆盖率 ≥ 70%。运行命令pnpm test:unit 和 pnpm test:e2e。 ## ️ 架构约定 - **分层**: Clean Architecture。src/core/领域逻辑、src/adapters/外部依赖、src/presentation/API/UI。 - **数据访问**: 所有数据库操作必须通过 src/adapters/database/repository.ts 中的 Repository 接口。 - **API**: RESTful遵循 GET /products, POST /products 规范。错误响应统一为 { error: { code, message } }。 ## ⚙️ 工具与命令 - **包管理**: pnpm不是 npm 或 yarn。安装依赖pnpm add pkg。 - **构建**: pnpm build 生成 dist/。 - **部署**: pnpm deploy:staging 部署到预发环境。 ## 禁止
