Back to Details

karpathy-guardrails

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Karpathy Guardrails

Karpathy 约束准则

Four rules. Load them into context at the start of every task. The reviewer enforces them as a Pass-1 filter before it looks at code quality.
四项规则。在每项任务开始时将其加载到上下文环境中。审核者会在检查代码质量前，将这些规则作为第一轮筛选条件强制执行。

1. Think Before Coding

1. 编码前思考

Before the first edit, write down:
  • What am I actually building? One sentence. If you cannot state it, stop.
  • What am I assuming? List every assumption. If any is load-bearing and unverified, flag 
    NEEDS_CONTEXT
    and ask — do not guess.
  • What does success look like? Map each acceptance criterion to a concrete test, check, or observable behaviour. If a criterion is not verifiable, propose a sharpening via the 
    revision
    skill (automated-trace subsection), not a vague attempt.
Refusing to produce code is allowed. A task with unknown scope is a spec bug, not a coding task.
在首次编辑之前，请写下：
  • 我实际要构建什么？ 用一句话概括。如果无法明确说明，请停止操作。
  • 我做出了哪些假设？ 列出所有假设。如果任何关键假设未经验证，请标记
    NEEDS_CONTEXT
    并询问——不要猜测。
  • 成功的标准是什么？ 将每个验收标准映射到具体的测试、检查或可观察行为。如果某个标准无法验证，请通过
    revision
    技能（自动跟踪小节）提出明确化建议，而非进行模糊尝试。
允许拒绝编写代码。范围不明确的任务属于规格缺陷，而非编码任务。

2. Simplicity First

2. 简洁优先

The correct amount of code is the minimum that meets the acceptance criteria.
  • No speculative features. No abstraction layer "in case we need it."
  • No new dependencies unless the task requires one and no existing dep fits.
  • No "while I'm in here" refactors. Surface them as separate kits.
  • Duplication is not always wrong. Three similar lines usually beat a premature abstraction with two configuration knobs.
If the diff is larger than the acceptance criteria seem to demand, explain why in the commit body. If you cannot, trim the diff.
合适的代码量是满足验收标准的最小代码量。
  • 不添加推测性功能。不提前构建“以防万一需要”的抽象层。
  • 不引入新依赖，除非任务明确要求且现有依赖无法满足需求。
  • 不进行“顺便重构”操作。将此类重构作为独立任务提出。
  • 代码重复并非总是错误的。三行相似代码通常优于带有两个配置项的过早抽象。
如果代码变更量超出验收标准的合理范围，请在提交说明中解释原因。若无法解释，请精简变更内容。

3. Surgical Changes

3. 精准修改

Every line in the diff must trace back to an acceptance criterion. Touching code outside the task's owned files is justified only when a requirement forces it. Examples of violations:
  • Fixing a formatter warning in an unrelated file.
  • Renaming a helper "to match new convention."
  • Reordering imports, docstrings, whitespace.
  • Tightening a type signature the task did not ask about.
If you see a real bug in adjacent code, log it to 
.cavekit/history/backprop-log.md
as a candidate kit item and keep it out of this task's diff.
代码变更中的每一行都必须对应某一项验收标准。仅当需求强制要求时，才可修改任务所属文件之外的代码。违规示例：
  • 在无关文件中修复格式化警告。
  • 为“符合新规范”重命名辅助函数。
  • 调整导入顺序、文档字符串或空白字符。
  • 收紧任务未提及的类型签名。
如果在相邻代码中发现真实漏洞，请将其记录到
.cavekit/history/backprop-log.md
中作为候选任务项，不要包含在当前任务的变更中。

4. Goal-Driven Execution

4. 目标驱动执行

Transform vague tasks into verifiable success criteria before execution.
  • A task that cannot be verified is not a task — escalate it.
  • The verification plan must be concrete: exact commands, exact assertions, exact files to inspect. "Make sure it works" is not a plan.
  • After implementation, run the verification plan. Report the output.
在执行前将模糊任务转化为可验证的成功标准。
  • 无法验证的任务不能算作任务——请升级处理。
  • 验证计划必须具体：精确的命令、精确的断言、精确的检查文件。“确保能运行”不能算作计划。
  • 实现完成后，执行验证计划并报告结果。

Role-specific enforcement

角色专属执行要求

  • task-builder — must produce, alongside code, a Verification Report listing each AC, the verification step, and the observed result.
  • reviewer — must refuse to advance to Pass 2 (code quality) if Pass 1 finds any of: undeclared assumptions, diff lines unjustified by an AC, out-of-scope edits, or unreachable verification steps.
  • planner — must reject kits that contain un-testable ACs. They are spec bugs and block planning.
  • inspector — must flag completed tasks whose verification logs are missing or hand-waved.
  • 任务构建者——必须在提交代码的同时生成一份验证报告，列出每个验收标准（AC）、验证步骤及观察结果。
  • 审核者——如果第一轮检查发现以下任何情况，必须拒绝进入第二轮（代码质量检查）：未声明的假设、无验收标准支撑的变更行、超出范围的修改，或无法执行的验证步骤。
  • 规划者——必须拒绝包含不可测试验收标准的任务包。这些属于规格缺陷，会阻碍规划进程。
  • 检查者——必须标记验证日志缺失或描述模糊的已完成任务。

When you are tempted to break a rule

当你想要违反规则时

You are probably over-confident about a shortcut that will cost more than the delay of asking. Stop and note the tension in the commit body or in the build log so the reviewer can judge.
你可能对某个捷径过于自信，而这个捷径带来的代价会超过询问所花费的时间。请停止操作，并在提交说明或构建日志中记录这种矛盾情况，以便审核者判断。