Super Code

Super Code Skill

概述

产出短小、正确、惯用且可维护的代码——按此优先级排序。 本技能解决两种必须独立修复的低效问题：

1. 代码 token 低效 — 产出物本身臃肿（多余的行、样板代码、过度抽象）
2. 生成 token 低效 — 智能体在会话中的操作方式（全文件重写、未经请求的文件、代码变更前后的冗余说明）

两者都很重要。只修其中一个是不够的。

何时使用本技能

• 在 IDE 中的每个编码任务上自动应用本技能。
• 当用户要求用任何语言编写、编辑、重构、生成或审查代码时使用。
• 这是常驻编程风格规范，而非按需启用——始终应用。

优先级顺序（不得违反此排序）

正确性 → 可读性 → 必要的健壮性 → 简洁性 → 微性能

简洁性绝不优先于正确性或可读性。如果某次压缩会丢弃实际可能发生的错误处理，或产出让人类六个月后无法阅读的代码，就撤销该压缩。短而错误的代码比长而正确的代码更糟。

工作流——应用于每个编码任务

步骤 1：在动手之前确定最小正确形态

在接触文件之前，先决定：

• 正确解决此问题的最小表面积是什么？
• 调用方实际需要从这个函数/类/模块获得什么？
• 是否已有标准库/框架原生功能做到了这一点？

在脑中记下（不要以文字块形式输出给用户）。这就是目标形态。

步骤 2：使用语言惯用模式编写

阅读所用语言的相关参考文件：

• Bash/Shell → bash/SKILL.md
• C → c/SKILL.md
• C++ → cpp/SKILL.md
• C# → csharp/SKILL.md
• Dart/Flutter → dart/SKILL.md
• Elixir/Erlang → elixir/SKILL.md
• Go → go/SKILL.md
• Java → java/SKILL.md
• Kotlin/Compose → kotlin/SKILL.md
• PHP → php/SKILL.md
• Python → python/SKILL.md
• Ruby → ruby/SKILL.md
• Rust → rust/SKILL.md
• Scala → scala/SKILL.md
• Swift → swift/SKILL.md
• TypeScript/JavaScript → typescript/SKILL.md

应用该文件中的惯用模式。它们用正确、紧凑且仍可读的等价写法替代冗长的命令式代码。

步骤 3：对自己的草稿做压缩检查

在展示任何代码之前，扫描以下内容：

步骤 4：护栏检查——展示前运行此检查

自问（静默地）：

• 我是否移除了对实际可能发生的情况的处理？
• 我是否让人类六个月后更难阅读？
• 我是否为了省行数而牺牲了正确性或安全性？

如果任一项为是：撤销该特定压缩，保留其余。

步骤 5：展示输出——生成 token 规则

始终：

• 通过针对性补丁/差异编辑文件，而非全文件重写，除非文件是新的或变更涉及 >70% 的行
• 只展示被请求的内容

绝不：

• 生成未经请求的文件（测试、README、配置、类型），除非用户要求
• 在代码前后添加文字块解释你即将做什么或刚做了什么——直接做
• 向用户重述其自身需求后再编写
• 在展示差异后用段落复述变更了什么——差异本身已不言自明

通用反模式清单

以下适用于每种语言。语言特定文件会扩展此列表。

注释

• ❌ // Loop through the list and add each item → ❌ 删除
• ✅ // Order matters: process refunds before charges → ✅ 保留（说明了为什么）
• 规则：如果注释可以通过阅读代码机械地生成，它就不增加价值

防御性编码

• 只处理在调用点实际可能发生的错误情况
• 如果调用方保证非空，函数内就不要做空值检查
• 如果 catch 块只能日志记录并重新抛出，考虑移除 try/catch

抽象

• 不要为仅在一处使用一次的逻辑提取函数
• 不要为仅使用一次的原始类型创建包装类
• 阈值：抽象在被使用 2 次以上时，或拥有真正阐明领域逻辑的有意义名称时，才算物有所值

脚手架

• 除非用户要求搭建骨架，否则不留占位 TODO
• 不写 // TODO: add error handling——要么加上，要么不加
• 不留"以防万一"的空 catch 块
• 不加当前调用方不使用的参数

生成 Token 规则（智能体 IDE 特定）

这些规定你在会话内的操作方式，不只是产出物：

文件编辑

• 优先精准补丁：只展示变更行 + 最少上下文
• 全文件重写仅适用于：新文件、少于 ~30 行的文件、或变更涉及 >70% 行的文件
• 永远不要为了"展示完整上下文"而重复文件的未变更部分

未经请求的产出物

• 不要创建测试文件、README 更新、类型定义文件、配置文件或 CI 脚本，除非明确请求
• 如果你认为测试文件有价值，在主要输出后用一句话提议——不要未经请求就生成

文字开销

• 不要"这是我即将做的："前导语
• 不要"我做了以下变更："后缀语（差异已经展示了）
• 不要"如果你需要我……"收尾语
• 如果需求确实有歧义，一行澄清是可以接受的；否则，做出合理选择并在代码内以注释标注假设（如果重要的话）

语言参考文件

在步骤 2 中阅读相关文件。如果语言未列出，应用上述通用清单并使用该语言自身的惯用写法处理循环、错误处理和数据转换。

示例

示例 1：重构冗长的循环

// Anti-pattern
List<String> names = new ArrayList<>();
for (User u : users) {
    if (u.isActive()) {
        names.add(u.getName());
    }
}
// Super-code idiomatic (Java)
List<String> names = users.stream().filter(User::isActive).map(User::getName).toList();

故障排除

问题：代码过于紧凑难以阅读

症状： 审查者抱怨或逻辑不可读。 解决方案： 回退过度压缩的部分。可读性和正确性始终优先于简洁性。

相关技能

• @karpathy-guidelines - 关于精准变更和简洁性的行为准则。

局限性

• 语言支持： 语言特定惯用写法需要参考文件。
• 可读性权衡： 极端压缩如果不注意，有时会损害可读性。