Back to Details

principle-encode-lessons-in-structure

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Encode Lessons in Structure

将经验教训编码到结构中

Encode recurring fixes in mechanisms (tools, code, metadata, automation) instead of textual instructions. Every error, human correction, and unexpected outcome is a learning signal. Capture it, route it, and close the loop.
Why: Textual instructions are easy to miss. They require the reader to notice, remember, and comply. Structural mechanisms (lint rules, metadata flags, runtime checks, automation scripts) enforce the rule without cooperation.
Pattern: When you catch yourself writing the same instruction a second time:
  1. Ask: can this be a lint rule, a metadata flag, a runtime check, or a script?
  2. If yes, encode it. Delete the instruction
  3. If no (genuinely requires judgment), make the instruction more prominent and add an example of the failure mode
Corollary: Don't paper over symptoms. If the fix is structural, ONLY use the structural fix. The instruction IS the symptom.
Feedback loop:
  • Capture every correction. When the human intervenes or tests fail, decide if it's a one-off or a pattern.
  • Route to the right layer. One-off -> brain note. Recurring fix -> skill or lint rule. Systemic issue -> principle.
  • Close the loop. Don't just record. Apply now or create a concrete todo.
Anti-patterns:
  • Acknowledging without recording ("I'll keep that in mind" does not persist)
  • Recording without routing (a brain note about a lint rule that should exist is wasted unless the lint rule gets implemented)
  • Fixing without generalizing (fixing one instance while leaving the recurring pattern intact)
将重复出现的修复措施编码到机制（工具、代码、元数据、自动化）中，而非使用文本指令。每一个错误、人工修正和意外结果都是一个学习信号。捕获它、传递它并形成闭环。
原因： 文本指令容易被忽略。它们要求读者注意、记住并遵守。而结构化机制（lint规则、元数据标记、运行时检查、自动化脚本）无需配合就能强制执行规则。
模式： 当你发现自己第二次写下相同的指令时：
  1. 思考：这能否转化为lint规则、元数据标记、运行时检查或脚本？
  2. 如果可以，将其编码实现。删除原有的文本指令。
  3. 如果不行（确实需要人为判断），则让指令更醒目，并添加失败场景的示例。
推论： 不要掩盖问题症状。如果修复方案是结构化的，就只使用结构化修复。文本指令本身就是问题的症状。
反馈闭环：
  • 捕获每一次修正。 当人工介入或测试失败时，判断这是一次性问题还是重复出现的模式。
  • 分配到合适的层级。 一次性问题 -> 记在脑中。重复修复 -> 技能或lint规则。系统性问题 -> 原则。
  • 形成闭环。 不要只记录下来。立即应用或创建具体的待办事项。
反模式：
  • 只确认不记录（“我会记住的”无法持久留存）
  • 只记录不分配（脑中想着应该存在某个lint规则，但不实际去实现，就是浪费）
  • 只修复不推广（修复单个实例，却放任重复出现的模式存在）