lean-mode 是什么
lean-mode 是一份面向编码 Agent 的 SKILL.md。它不以“代码越少越好”为目标，而是给 Agent 提供明确判据，帮助它回答两个工程问题：
- 一段看似安全的代码是否值得写，例如校验、
try/catch、抽象层、兜底逻辑或额外的安全子系统。 - 当前构建和测试为什么很慢，以及怎样把低效验证循环缩短到合理范围。
技能文件位于 skills/lean-mode/SKILL.md，采用标准 frontmatter，也就是 name、description 加 Markdown 正文。它不依赖特定宿主，凡是支持 SKILL.md 约定的 Agent 都可以使用。
它要解决的核心问题
长时间编码会话中，模型容易出现两类系统性倾向：过度防御性编程和低效验证循环。
过度防御性编程
常见表现包括在内部可信数据上重复做空值校验、用异常捕获隐藏根因、为单一实现提前创建抽象，以及在没有确认问题来源时不断添加兜底。代码表面上更“安全”，实际上可能增加维护成本，并把清晰的失败变成难以追踪的错误值。
低效验证循环
常见表现包括频繁执行完整构建、反复使用 clean、禁用常驻进程、每次都跑全部测试，以及让明显卡住的命令长时间等待。lean-mode 用进程复用、增量执行、范围控制、执行顺序、调用频率和超时管理六类规则约束这些行为。
README 中的量化数据来自一份约 20k 行 Java 与 Gradle 工程的单次长会话，只用于说明问题真实存在，不应被视为跨模型或跨项目的行业基准。
主要能力
- 只在信任边界校验一次：要求先回答“这个 null 从哪里来”，避免可信数据进入系统后仍被层层重复检查。
- 避免吞掉根因：警惕
catch后返回null、false、空集合或零值，因为它们可能将明确异常转换成更难定位的错误。 - 约束提前抽象：只有一个实现、仅为未来可能替换而创建的抽象，不一定形成真正稳定的扩展边界。
- 优先修复根因：添加兜底意味着根因尚未完全解决。确实需要兜底时，应说明问题归属、删除条件和经过核实的依据。
- 让改动量匹配行为变化：新增代码超过 50 行时，先报告总行数、校验与兜底所占行数，以及不写这些代码的实际代价。
- 写安全代码前先回答三问：问题真的会发生吗，发生后用户会怎样，不写的代价是什么。任何一问无法回答时，先不要添加代码。
- 缩短验证回路：覆盖 Gradle、Maven、Go、Node 与 TypeScript、Rust、Python、.NET 七类构建系统的最小验证思路。
- 允许得出“不用改”的结论：目标是解决问题，而不是强行产出代码，也不应在用户没有要求的区域顺手加固。
- 提供存量代码审计流程：先量化密度，再检查最严重的文件，逐条判断删除、上移或保留，并在修改前先向用户提交结果表。
针对防御性代码，技能提供 Java、Go、TypeScript 和 Python 四种语言的反例，帮助 Agent 识别不同语法背后的同类问题。
安装 lean-mode
方式一：从 URL 拉取
如果宿主支持从 URL 导入技能，例如 Vantaloom 的技能页，可以直接粘贴仓库地址。宿主会在 skills/lean-mode/ 下找到技能文件。
https://github.com/Timefiles404/lean-mode-skill方式二：复制到工作区
先克隆仓库，再把技能目录复制到宿主约定的位置。使用 Vantaloom 工作区约定时执行：
git clone https://github.com/Timefiles404/lean-mode-skill.git
cp -r lean-mode-skill/skills/lean-mode <你的工作区>/.vantaloom/skills/如果宿主使用 Claude 风格的技能目录，则复制到 .claude/skills/：
cp -r lean-mode-skill/skills/lean-mode <你的工作区>/.claude/skills/方式三：手动创建技能
在宿主中创建一个新技能，然后将仓库内 skills/lean-mode/SKILL.md 的完整内容粘贴进去。不要遗漏顶部 frontmatter，因为宿主会根据其中的 description 判断何时加载技能。
基本使用流程
安装后，lean-mode 主要依赖技能描述按需进入上下文。当 Agent 准备添加校验、异常捕获、抽象层、兜底或额外安全子系统，或者一轮中已经执行多次构建测试时，它应被触发。
场景一：判断是否需要新增校验
- 先定位数据来源，确认它是否来自外部输入、接口边界或其他不可信来源。
- 检查相同约束是否已经在信任边界验证过。
- 回答问题是否真实可发生、用户会受到什么影响，以及不写校验的代价。
- 如果数据进入内部后已经可信，不再层层重复添加同类运行时校验。
例如，Agent 想在多个内部方法中重复加入 Objects.requireNonNull 时，不应只因为参数“理论上可能为 null”就添加，而应先追踪 null 的实际来源，并判断边界处是否已经完成验证。
场景二：处理异常
当 Agent 准备捕获异常并返回默认值时，应先确认这种处理是否会隐藏根因。以下模式属于需要重点审查的类型：
catch (...) {
return false;
}重点不是禁止所有异常捕获，而是避免把一次可定位的失败转换成缺少上下文的 false、null、空结果或零值。若业务确实需要降级，仍应根据技能中的例外条件评估。
场景三：评估抽象层
如果一个接口目前只有一个实现，创建它的唯一理由又是“未来可能替换”，Agent 应暂停并检查真正的变化边界。lean-mode 不否定抽象，而是反对在缺乏当前需求和稳定边界时提前制造间接层。
场景四：缩短构建和测试
- 优先复用已有构建进程，避免无必要地反复冷启动。
- 保留增量产物，不要习惯性运行
clean。 - 先执行只编译、只检查相关模块或只运行一个测试的最小命令。
- 最小验证通过后，再逐步扩大到模块测试或完整测试。
- 控制重复调用频率，避免没有代码变化时反复执行相同命令。
- 为可能卡住的命令设置合理超时，并在失败后先分析首个根因。
README 中的完整技能正文针对七种构建系统给出了“只跑这一个”的最小验证回路。实际使用时，应优先把这些示例替换成项目里可以直接执行的真实命令。
审计已经过度防御的代码
lean-mode 附带一套“先量再删”的审计流程，适合处理已经积累大量校验、兜底或异常吞噬逻辑的项目。
- 搜索并量化：按语言使用附录中的搜索模式，统计相关模式的数量和密度。
- 缩小检查范围：只查看问题最集中的 5 个文件，避免一开始审计整个仓库。
- 逐条分类：将每处逻辑标记为“删”“上移”或“留”。“上移”通常表示将校验集中到真正的信任边界。
- 先报告再修改：先把审计表交给用户选择，不要未经确认就进行大规模删除。
- 分批验证：修改后采用最小构建和测试范围验证，再根据结果扩大范围。
这种流程强调可观察、可选择和可回退，而不是把“减少防御代码”变成另一次不受控制的大重构。
定制 SKILL.md
SKILL.md 本身就是 Markdown，可以直接编辑。以下三类定制最有价值。
替换项目验证命令
把第七节中的通用命令改成当前工程真实可执行的“只编译”和“只跑一个测试”命令。一条可以直接复制执行的命令，通常比抽象原则更能约束 Agent 的行为。
调整搜索模式
根据项目代码风格修改附录的搜索规则。例如 Java 工程可能使用 Guava Preconditions，也可能主要使用 Objects.requireNonNull。搜索模式应与真实代码一致。
调整参考密度
技能将每 200 至 500 行出现一条校验作为经验参考，但这不是统一标准。解析器、协议边界和业务 CRUD 的合理校验密度不同，应根据领域风险和数据来源调整。
高级使用建议
- 把例外也保留在上下文中：技能中的判据是启发式规则，不是定理。不要只保留“不要校验”或“不要 catch”之类的简化口号。
- 要求 Agent 报告改动构成：当新增超过 50 行时，让它明确说明总行数、校验兜底行数及不实现这些逻辑的代价。
- 让验证范围逐级扩大：从相关文件、单个测试或模块开始，再进入更大的测试范围，避免每次修改都触发完整构建。
- 用证据说明兜底：必须保留兜底时，记录具体问题来源、核实结果和未来删除条件，不要使用无法验证的“某些环境可能出错”。
- 把“不修改”当作有效结果：如果问题已被现有逻辑解决，或新增代码没有清晰收益，应允许 Agent直接说明无需改动。
能力边界与可选配套
lean-mode 改变的是模型倾向，而不是模型能力。它不能强制模型停止编写某种代码，只能在合适时机把判据放进上下文，因此有效但不构成保证。
它也不是静态分析器，不会自动读取或扫描代码。附录中的审计需要 Agent 自行运行对应搜索命令，并根据结果判断。
可选的 Vantaloom 同名插件会把压缩后的守则持续放到每轮动态上下文中，并提供工具结果尾注和 lean_review 工具。插件负责持续提醒，技能负责提供完整判据。即使不安装插件，这份技能仍可独立使用。
项目仓库可在 GitHub 上的 lean-mode-skill 查看，采用 MIT 许可。
结语
lean-mode 的价值不在于机械地减少代码，而在于让每项校验、异常处理、抽象、兜底和验证命令都能说明理由。安装后再结合项目实际命令、搜索模式和风险密度进行定制，可以帮助编码 Agent 更聚焦根因，并建立更短、更可靠的工程反馈循环。