① 工程：搭 AI agent 系统时，别一上来就设计十个 agent 的编排框架——先让单个 agent 端到端跑通一个真实任务，再加第二个。先有可运转，再谈复杂。② 家庭：想给家里建一套"完美日程系统"？先用一张共享清单跑两周，跑通了再加自动化。③ 反模式预警：当你发现自己在精心设计"将来才用得上"的复杂结构时——它大概率连第一步都跑不起来。可运转性是唯一不能赊账的东西。
English Summary
Gall's Law — a complex system that works is invariably found to have evolved from a simple system that worked. The converse bites harder: a complex system designed from scratch never works and can't be patched into working — you must restart from a simple, working system and let it grow. Complexity is grown, not built; every intermediate step must preserve the "it runs" invariant (isomorphic to evolution — every transitional eye had to be useful). Corollary: big-bang rewrites almost always fail. Practical test: does the system still run after this step? If not, you're violating Gall's Law.
AI Prompts
中文提示词
我打算构建/重写 [系统/产品/流程]，当前方案是 [描述]。请用高尔定律审视我：
① 我是不是在试图一次性搭一个从未运转过的复杂系统？
② 能端到端跑通的"最小可运转版本"是什么——剥掉哪些部分它仍然能跑？
③ 设计一条 3-4 步的生长路径，每一步都保持系统可运转，并标出每步新增的唯一复杂度。
English Prompt
I'm about to build/rewrite [system/product/process]. Current plan: [describe]. Apply Gall's Law:
1. Am I trying to stand up a complex system that has never worked, all at once?
2. What is the minimal version that runs end-to-end — which parts can I strip while it still works?
3. Design a 3–4 step growth path where every step keeps the system running, naming the single new complexity added at each step.
健壮性原则 · Postel's Robustness Principle
"Be conservative in what you send, be liberal in what you accept." — Jon Postel, RFC 760, 1980
早期浏览器对畸形 HTML 的宽容解析（quirks mode）让网页爆炸式普及——任何人手写的烂标签都能显示出来。代价是几十年的渲染不一致，以及 HTML5 不得不花大力气把"容错解析"反过来重新精确标准化。宽容点燃了生态，也留下了规范的烂账。
场景 · BigCat
① 与 LLM 交互的接口：入口要宽容（用户的自然语言千奇百怪，尽量都接住并归一化），但你交给下游系统的输出 schema 必须严格（JSON 字段固定、类型固定），否则下游全乱。② 沟通：对他人的表达方式宽容（别为措辞挑刺），但自己对外的承诺要精确——这是工程原则在协作上的同构。③ 警惕暗面：你越是"什么都能接"，对方越不会自我修正，最终你被迫永远兼容所有人的坏习惯。
English Summary
Postel's Robustness Principle — be conservative in what you send, be liberal in what you accept. Liberal acceptance let the early Internet stitch heterogeneous implementations into one interoperable whole. But its blessing is its curse: liberal acceptance erodes the spec — every implementation accepts slightly different input until nobody knows the "correct" format and bugs become de-facto standards (the seedbed of Hyrum's Law). Modern protocols (HTTP/2, QUIC) often swing strict instead. Discipline: accept liberally at the boundary, normalize dirty input into a clean internal representation, but emit strictly — downstream depends on your output. Tolerance interoperates but corrodes; the balance depends on whether the system is an open ecosystem or a closed, evolvable core.
AI Prompts
中文提示词
我在设计 [接口/API/协作流程]。请用健壮性原则帮我分两侧审视：
① 入口处，我应该宽容地接住哪些"脏但合理"的真实输入？给出归一化策略。
② 出口处，我的输出是否足够严格规范，下游能否稳定依赖？
③ 找出 1 个"过度宽容"的风险点——我现在的容忍，将来会把哪个 bug 沉淀成没人敢改的事实标准？
English Prompt
I'm designing [interface/API/collaboration process]. Apply the Robustness Principle on both sides:
1. At the inbound edge, which "dirty but reasonable" real-world inputs should I accept liberally? Give a normalization strategy.
2. At the outbound edge, is my output strict enough for downstream to depend on stably?
3. Identify one over-tolerance risk — which bug will my current leniency eventually cement into an unchangeable de-facto standard?
海勒姆定律 · Hyrum's Law
"With a sufficient number of users of an API, all observable behaviors of your system will be depended on by somebody." — Hyrum Wright
Linux 内核的铁律"绝不破坏用户空间"——因为任何系统调用行为都被某个程序依赖，哪怕那原本是个 bug。Windows 为兼容老软件而长期保留已知缺陷，也是同理。这条定律正是 Google 工程团队从无数次"改了个没承诺的细节、却弄垮下游"的事故里提炼出来的。
场景 · BigCat
① 平台/库：你的内部库被几十个团队用过之后，连日志格式、报错文案都不敢动——每一处都可能是某人的解析依据；想保留演进空间，必须在用户还少时就立规矩。② AI prompt 工程：一个被很多下游流程依赖的 prompt 模板，改一个词、调一下输出顺序，都可能让某条 pipeline 静默崩溃——LLM 输出的"可观测行为"全是隐式契约。③ 育儿：你无意中建立的隐式承诺（每晚必讲故事、周末必去公园）会被孩子当成不可违背的契约——可观测的规律就是承诺，哪怕你从没说出口。
English Summary
Hyrum's Law — with enough users of an API, it doesn't matter what you promised in the contract: all observable behaviors of your system will be depended on by somebody. Error-message wording, hash iteration order, a 10 ms latency — anything observable becomes an implicit interface in someone's code. This is the death of the encapsulation myth: with enough observers, no abstraction is truly leak-proof, and your implementation freedom shrinks inversely with your user count (an observer-effect isomorphism). The implicit contract — emergent from thousands of dependents — is larger than your docs and can't be recalled. To preserve freedom: hide behavior actively (inject randomness/jitter so nobody depends on it), or lock semantics early while users are few.
AI Prompts
中文提示词
我维护的 [接口/库/prompt 模板/系统] 即将变更：[描述改动]。请用海勒姆定律帮我排雷：
① 列出 5 个"我从未承诺、但可被观测、可能已被依赖"的行为（输出顺序、错误文案、时序、默认值等）。
② 我的这次改动会踩中其中哪几个？下游会以什么方式静默崩溃？
③ 给出策略：哪些行为应趁早注入随机性以阻止依赖，哪些应正式纳入契约、稳定下来。
English Prompt
I maintain [interface/library/prompt template/system] and plan to change it: [describe change]. Use Hyrum's Law to find landmines:
1. List 5 behaviors I never promised but that are observable and may already be depended on (output ordering, error text, timing, defaults).
2. Which of these does my change touch, and how would downstream break silently?
3. Recommend a strategy: which behaviors to actively randomize now to prevent dependence, and which to formally promote into the contract and stabilize.
沃斯定律 · Wirth's Law
"Software is getting slower more rapidly than hardware is becoming faster." — Niklaus Wirth, 1995
实践：给关键路径设"性能预算"（如冷启动 < X 秒、首屏 < Y 毫秒），并把它当成会失败的测试持续守护——预算就是抵抗熵增所注入的那股逆向能量。每加一层抽象或一个依赖，先问：它吃掉的硬件红利，换回的开发便利值不值。
硬件红利不断扩大，软件体验却追不上——中间张开的缺口就是被消耗掉的性能
经典例子
今天启动一个基于 Electron 的聊天或编辑器应用，占用的内存和启动时间，足以让 90 年代的整台机器跑完一个完整操作系统还有富余。网页平均体积逐年膨胀，硬件再快也追不回首屏那几秒等待——算力涨了几个数量级，体验却几乎原地踏步。
场景 · BigCat
① AI 时代的新沃斯定律：更强模型带来的算力红利，正被越来越长的 agent 调用链、层层 RAG 检索、冗余的 re-prompt 吃掉——模型快了一个数量级，端到端体验却没快多少。② 个人工作流：工具越强，反而堆出越臃肿的流程（十个插件、五层自动化），净效率的提升被流程本身的开销抵消。③ 逆向纪律：给自己的 AI 工作流也立"延迟/步骤预算"，每加一环都要证明它换回的价值大于它吃掉的速度。速度不会自己回来，只能主动夺回。
English Summary
Wirth's Law — software is getting slower more rapidly than hardware is becoming faster. Moore's dividend doesn't become faster experiences; it's eaten by abstraction layers, bloated dependencies, and "the machine is fast enough" complacency ("Andy giveth, Bill taketh away"). At root it's an incentive problem, not a technical one: developers spend the hardware dividend on development speed, not user speed. Performance is actively consumed, never auto-improved — isomorphic to entropy (software trends toward bloat unless you inject counter-energy) and echoing Parkinson's Law (work expands to fill available resources). The fix is institutionalized performance discipline: set performance budgets on critical paths and guard them like tests that can fail.
AI Prompts
中文提示词
我的 [应用/服务/AI 工作流] 性能在退化/臃肿：[描述现状与症状]。请用沃斯定律分析：
① 列出吃掉性能红利的前 3 个来源（抽象层、依赖、冗余调用、复杂度膨胀等），按代价排序。
② 为关键路径提出 1 套可量化的"性能预算"（具体指标 + 阈值），能当作持续守护的测试。
③ 给出 2 个"逆熵"动作：删掉或合并哪些环节能立即换回最多速度，且不牺牲核心价值。
English Prompt
My [app/service/AI workflow] is degrading/bloating: [describe current state and symptoms]. Apply Wirth's Law:
1. List the top 3 sources eating the performance dividend (abstraction layers, dependencies, redundant calls, complexity creep), ranked by cost.
2. Propose a quantifiable performance budget for the critical path (concrete metrics + thresholds) that can be guarded as a failing test.
3. Give 2 anti-entropy moves: which steps to cut/merge for the biggest immediate speed-back without sacrificing core value.