method

redo 是一种工程反推框架。

它从成熟系统的结果倒推到当时的约束和选择,解释为什么一个看起来不完美的方案在当时是理性的,以及它后来留下了什么债。

not this

  • 不是教程。
  • 不是功能巡礼。
  • 不是 release timeline。
  • 不是源码导读。
  • 不是泛泛的 AI 摘要。

core loop

一条选择链

每个案例都必须保留选择前的压力、没有选择的方案、选择后的代价,以及后续如何修复或隔离。

  1. 01

    constraint

  2. 02

    options

  3. 03

    chosen path

  4. 04

    trade-off

  5. 05

    debt

  6. 06

    mitigation

  7. 07

    unresolved pain

  8. 08

    transferable pattern

  9. 09

    boundary

evidence discipline

证据不是装饰

事实、推理和有争议判断必须分开。论文、设计文档、提案和标准是一等资料。

事实要有来源

核心事实必须能追到 source evidence,不能只靠二手复述。

推理要标注

动机、权衡和因果链如果不是来源直接陈述,就必须绑定 basis claim。

判断要有边界

有争议的评价必须保留反例、相反选择和适用边界。

弱资料不能撑核心结论

SEO 教程和泛文章只能做背景,不能支撑历史主张。

how to read

读的时候盯住债务流动

不要只看最后选了什么。更重要的是,某个债在什么时候被引入、什么时候被缓解、为什么仍然留在今天。

用 redo 读自己的系统时,先列出当前痛点,再倒推这些痛点最早在哪个约束下被合理化。然后问:当时的候选方案有哪些,今天是否有新的边界条件让旧选择不再成立。

提交一个系统