行为不变的代码简化inbox-zero Code Simplifier 技能实战指南【免费下载链接】inbox-zeroThe worlds best AI personal assistant for email. Open source app to help you reach inbox zero fast.项目地址: https://gitcode.com/GitHub_Trending/in/inbox-zero导读本文以 .claude/skills/code-simplifier/SKILL.md 为骨架系统讲解 inbox-zero 开源仓库中面向 AI 编码助手的Code Simplifier代码简化技能如何在提交评审或开启 PR 之前对当前会话或当前分支中刚改动的代码做行为不变的轻量打磨——提升可读性、一致性与可维护性却绝不改变任何功能语义。读完本文你将掌握该技能的适用范围、四条核心规则与五步工作流并理解它如何与仓库的 AGENTS.md 工程规范、Biome/ultracite 格式化体系以及 review 技能协同运作。一、技能定位它解决什么问题Code Simplifier 是仓库中面向 AI Agent 的一套编码规范型技能。从其 frontmatter 可以看出它的设计意图name: code-simplifier description: Simplify and refine recently modified code for clarity, consistency, and maintainability while preserving exact behavior. Use when asked to simplify, polish, refactor lightly, or clean up current-session changes before review or PR.它的核心信条在文档开篇就明确给出Refine recently modified code without changing what it does. Prioritize readable, explicit code over overly compact solutions.翻译过来即简化代码的表达方式而不是改变代码的行为宁可多几行直白代码也不要追求极致的紧凑。这与仓库整体Change Philosophy一脉相承——AGENTS.md 中同样强调Prefer the simplest, most readable change。从定位上看该技能与仓库中其他 Agent 技能如 review、create-pr形成了流水线关系改代码 → 简化打磨 → 评审 → 提交 PR。它被设计为在review 或 PR 之前使用。二、Scope 边界只碰最近改动的代码技能对工作范围做了严格限制避免 AI 在打磨时顺手做大改造聚焦范围只处理当前会话或当前分支 diff 中触及的代码除非用户明确要求更广范围的清理禁止事项不得引入大范围重构broad refactors、格式化扰动formatting churn、依赖变更dependency changes或无关修改unrelated edits。这一边界与 create-pr 中do not expand the requested scope for optional refactors的原则相互印证简化技能服务于把当前改动收拾干净而不是借机重构整个模块。三、四条核心规则详解规则一精确保持功能Preserve functionality exactly这是整个技能的安全红线任何简化都必须守住保持功能、输出、副作用、数据契约、权限、错误行为完全不变只改变代码的表达方式how code is expressed不改变代码做了什么what it does。在 inbox-zero 这种涉及邮件数据处理、支付、权限的多租户应用中这条规则尤其重要——一次看似无害的简化可能悄悄改变某个 server action 的校验行为或错误返回结构。这也是为什么技能要求简化后必须做focused validation见第五节。规则二应用项目标准Apply project standards简化不是自由发挥而是向仓库既有规范对齐。技能明确要求参考 AGENTS.md 与更具体的本地指令。结合 AGENTS.md 的实际内容可归纳出以下可直接执行的检查清单规范项要求仓库佐证TypeScript开启 strict null checksAGENTS.md TypeScript with strict null checksimport 位置全部置于文件顶部禁止文件中途动态 importAGENTS.md All imports at the top of files, no mid-file dynamic imports导入方式直接从原始来源导入禁止 barrel 文件与 re-export 模式AGENTS.md No barrel files. Import directly from source files.类型推导用z.infertypeof schema从 Zod schema 推导类型不重复手写 interfaceapps/web/utils/actions/admin.validation.ts 中大量export type XxxBody z.infertypeof xxxBody辅助函数放在文件底部而非顶部AGENTS.md Helper functions go at the bottom of files注释只写为什么不写是什么AGENTS.md Only add comments for why, not what约定跟随触及 React、API 路由、server action、日志、测试时遵循仓库既有约定.claude/skills/fullstack-workflow/SKILL.md以类型推导为例仓库的真实做法在 apps/web/utils/actions/admin.validation.ts 中随处可见import { z } from zod; export const hashEmailBody z.object({ // ...字段定义 }); export type HashEmailBody z.infertypeof hashEmailBody;这样 schema 是类型的唯一事实来源简化时删除重复的 interface、改为z.infer推导正是技能规则二鼓励的低风险改动。规则三提升清晰度Enhance clarity这是简化的正面动作技能给出的手段包括降低不必要的复杂性与嵌套层级删除冗余代码与弱抽象weak abstractions当意图更清晰时改善命名仅在确实提升可维护性时合并相关逻辑避免嵌套三元表达式nested ternaries优先使用直白的控制流、小辅助函数、switch 或查表lookup table。最后一条在仓库层面有双重印证技能文件要求避免嵌套三元而 biome.json 中虽将noNestedTernary关闭说明仓库允许 lint 层面的宽容但 AGENTS.md 仍明确写着 Avoid large/nested ternaries. Prefer straightforward control flow, a small helper, or a lookup table when it improves readability——即风格红线由文档约定而非强制 lint 规则承载。一个典型的嵌套三元 → 查表简化示意符合技能规则的改造方向// 简化前嵌套三元意图模糊 const statusLabel rule.isActive ? rule.failedCount 0 ? Degraded : Active : Paused; // 简化后查表/直白控制流行为完全一致 function getStatusLabel(rule: Rule): string { if (!rule.isActive) return Paused; return rule.failedCount 0 ? Degraded : Active; }规则四保持平衡Maintain balance技能特意提醒简化不能走向另一个极端不要为了更少的行数牺牲可读性不要写出聪明而密集的单行代码clever dense one-liners不要在一个函数/组件里塞进过多职责不要删除那些让代码更易理解、更易扩展的有价值的抽象。这与 AGENTS.md 中避免过早抽象、但正确性敏感的重复代码应尽早抽取/集中的辩证关系一致也与 review 技能中的审查问题Can this be simpler?和Is it DRY without premature abstraction?形成闭环——简化与评审共享同一套审美标准。四、五步工作流从 diff 到报告技能定义了可重复执行的五步流程适合 AI Agent 按序操作检查当前 diff定位最近修改的代码段寻找低风险的简化点——只挑那些能改善清晰度或一致性、且显然不改变行为的改动仅应用保持行为的改动对触及的文件运行聚焦验证focused validation汇报重要改动与所做的验证。其中第 4 步验证是行为不变承诺的落地手段。结合仓库 package.json 与 .claude/skills/testing/SKILL.md可用的聚焦验证命令包括pnpm test path/to/file.test.ts # 运行单个单元测试文件 pnpm test-integration # 集成测试emulator 驱动 pnpm check # ultracite 格式/lint 检查 pnpm fix # ultracite 自动修复其中pnpm check/pnpm fix经由 ultracite 驱动package.json 中check: ultracite check、fix: ultracite fix而lint-staged也会在提交时对*.{js,jsx,ts,tsx,json,jsonc,css,scss,md,mdx}自动执行ultracite fix因此简化后的代码天然会被仓库的提交钩子再次校验格式。五、与评审、提交流程的协同Code Simplifier 不是孤立的它在 create-pr 定义的检查与评审 → 分支提交 → 开 PR → 交给 pr-watch 监控流水线中位于最前端的打磨阶段。其输出质量直接决定 review 技能后续审查的工作量——review 技能明确把Can this be simpler?Can we remove any code?列为每次评审必问的问题而这些问题正是 code-simplifier 在编码阶段就应该已经回答过的。此外AGENTS.md 中Runpnpm installbefore running tests or build if not already done等环境约束同样适用于简化后的验证步骤若修改触及 LLM 相关代码AGENTS.md 还提示应避免为抓取模型当前措辞而添加关键词黑名单这类脆弱规则简化时不应引入此类守卫逻辑。六、实战要点小结判断时机被要求simplify / polish / refactor lightly / clean up时启用只处理当前会话或当前分支 diff 内的代码安全第一功能、输出、副作用、数据契约、权限、错误行为六要素一个都不能变对齐规范以 AGENTS.md 为最终裁判重点是 strict null checks、顶部 import、禁 barrel 文件、z.infer推导类型、辅助函数置底、注释只写 why、避免嵌套三元克制平衡可读性优先于行数不追求单行炫技不删除有价值的抽象验证兜底改动后运行聚焦的单元测试或pnpm check/pnpm fix并在最终汇报中说明改了什么、验证了什么。这套方法论的价值在于它把一个容易失控的重构冲动收敛为一套有边界、有规则、有流程、有验证的轻量打磨体系让 AI 助手在大型 monorepoNext.js App Router TypeScript Zod Biome中既能交付更干净的代码又不会因过度发挥而引入回归——这正是 inbox-zero 仓库为 AI 协作编码沉淀的一条可复用的工程实践。【免费下载链接】inbox-zeroThe worlds best AI personal assistant for email. Open source app to help you reach inbox zero fast.项目地址: https://gitcode.com/GitHub_Trending/in/inbox-zero创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考