Levels of Abstraction — abstraction isn't "hiding details," it's picking the set of invariants sufficient for the current problem and encapsulating the rest one layer down. Good abstraction: upper layer reasons correctly using only the interface. Bad abstraction: upper layer must know lower-layer details to use it (leaky abstraction). Each layer compresses information; whatever gets compressed away eventually returns as a bug. Test: can you debug the upper layer without opening the lower one? If every debug session requires diving through 3 layers, the boundary is wrong.
AI Prompts
中文提示词
我正在设计 [系统/模块]。当前抽象边界是 [描述]。请：
① 找出 2-3 个最可能"抽象泄露"的地方——上层必须知道下层细节才能用对的接口；
② 评估是否抽象层太少（上层重复劳动）还是太多（穿透太多层 debug）；
③ 给出 1 个具体的重画边界方案，说明它解决了哪个信息压缩反扑。
English Prompt
I'm designing [system/module]. Current abstraction boundaries: [describe]. Please:
1. Identify 2–3 likely leaky abstractions — interfaces where the upper layer must know lower-layer details to use them correctly.
2. Diagnose whether there are too few layers (upper-layer duplication) or too many (debug requires piercing many layers).
3. Propose one concrete re-drawing of boundaries, naming which compression-rebound it resolves.
康威定律 · Conway's Law
"Organizations design systems that mirror their communication structure." — Melvin Conway, 1967
中文详解
系统架构 = 组织沟通结构的同构投影。两个 team 之间沟通成本高 → 它们负责的模块之间一定会演化出"防御性接口"，无论你最初画的架构图多漂亮。这不是 bug 是社会-技术系统的物理定律。
① 在公司：分布式系统里两个模块总在边界打架？看人——这俩 team 之间是不是"开会才说话"？拉近 daily 沟通比重构代码更治本。② 在家：把孩子的"练琴模块"和"作业模块"塞给同一个家长 → 边界自动模糊；分给不同家长 + 通过共享日历同步 → 自动涌现出"接口契约"。康威定律不分公司还是家。③ AI 时代：你 + 一组 agents 是一个新的"组织"——你和 agent 的对话带宽决定了产出代码/产物的耦合度。沟通带宽窄 = agent 输出会变碎片化。
English Summary
Conway's Law — system architecture is an isomorphic projection of the organization's communication structure. High-friction team boundaries become defensive API boundaries in code, regardless of the original architecture diagram. The Inverse Conway Maneuver: to get the architecture you want, first reshape the org. Architecture isn't designed — it emerges under communication-bandwidth constraints. The architect's lever is boundary conditions (team splits, reporting lines, who shares meetings), not the box diagram. Map team-communication structure before drawing UML — it predicts the code 6 months out more accurately than any design doc.
AI Prompts
中文提示词
我们团队当前组织结构是 [描述]，想要的目标架构是 [描述]。请：
① 用康威定律预测：在当前组织下，6 个月后实际会涌现出什么样的架构？
② 找出 2 个最可能演化为"防御性接口"的团队边界；
③ 给出 1 个最小化的"逆康威"动作（重组哪条沟通线、谁开始同会），它能让目标架构变得可行。
English Prompt
Our team org structure: [describe]. Target architecture: [describe]. Please:
1. Apply Conway's Law: under the current org, what architecture will actually emerge in 6 months?
2. Identify 2 team boundaries most likely to harden into defensive APIs.
3. Propose one minimal Inverse-Conway move (which communication line to redraw, who joins which meeting) that makes the target architecture feasible.
Twitter 早期 Rails monolith——快速验证 PMF 的正确债务选择。但 2010 年 World Cup 期间反复宕机时，债务利率已变成"每多一个用户就指数上升"。他们用 3 年时间重写为 Scala/JVM 微服务（"Fail Whale"时代）。教训：早期借得对（让 Twitter 活下来），中期没及时还（拖到危机才动）。
场景 · BigCat
① 个人知识系统的债：随手记笔记不归类 = 借了"分类决策"债，3 个月内利率低（笔记少时随便搜），1 年后变高利率（笔记爆炸时找不到东西）。② 育儿的"技术债"也成立——为了赶时间替孩子做决定 = 借"她的自主性"债，利率会在青春期一次性兑现。③ AI 工作流：prompt 复制粘贴 = 借"prompt 系统化"债。最初提速，半年后所有 prompt 都不能复用、版本不可追溯 = 你在为一年前的偷懒付高利息。关键不在不借，而在记账。
English Summary
Technical Debt — Cunningham's original metaphor is widely misused. It's not "hacky code." It's: ship with incomplete understanding, then refactor in what you learned post-release — that's the borrow. Interest = every new feature built on a flawed model compounds future refactor cost. Distinguish conscious debt (strategy) from unconscious debt (ignorance) — the latter is dangerous because you don't know you're indebted. Interest rates vary wildly: some debt sits 5 years (dead code), others kill velocity in 6 months (wrong data model, wrong core abstraction). Pay down high-rate debt first, not the ugliest debt. Zero debt = zero output; healthy teams track what they borrowed, the rate, and when they plan to pay.
AI Prompts
中文提示词
我们的项目/系统是 [描述]。请帮我做技术债审计：
① 列出 5 项当前存在的债，按"利率估计 × 当前余额"排序；
② 标记每项是"有意识借的"还是"无意识欠的"——后者优先；
③ 给出未来 1 个季度的"还款计划"：还哪 2 项、为什么是这两项、能换回多少未来 velocity。
English Prompt
My project/system: [describe]. Run a technical-debt audit:
1. List 5 current debts, ranked by estimated interest rate × current balance.
2. Tag each as "consciously borrowed" or "unconsciously incurred" — prioritize the latter.
3. Propose a 1-quarter repayment plan: which 2 to pay down, why these two, how much future velocity it buys back.
YAGNI 与过早抽象 · YAGNI & Premature Abstraction
"You Ain't Gonna Need It" — XP 原则 / "Duplication is far cheaper than the wrong abstraction." — Sandi Metz
非平凡点：① "看起来重复" ≠ "本质重复"——两段长得一样的代码可能是同一概念的 2 个 instance（应该 DRY），也可能是两个不同概念恰好暂时长得一样（不应 DRY）。提前 DRY = 把两个概念锁进一个 abstraction，未来它们各自演化时你要痛苦地把它们撕开。② Sandi Metz 名言："duplication is far cheaper than the wrong abstraction"——错抽象的成本远高于复制代码。原因：复制代码是线性问题（多改几个地方），错抽象是耦合问题（每个新需求都被错框架污染）。③ 反方向陷阱（"YAGNI 过头"）：核心数据模型选错也叫"我不预测未来"——错了。架构层面的决策（数据模型、部署拓扑、核心 API 契约）必须预测，因为它们一旦错了，技术债利率最高（见 Card 3）。YAGNI 适用于实现层，不适用于架构层。④ "等三次再抽象"是 Martin Fowler 的 Rule of Three 启发法——前两次容许重复，第三次再抽象，此时样本充足。
YAGNI & Premature Abstraction — XP's "You Ain't Gonna Need It." Deep version: abstraction needs data — you must see 3–5 real variants before the right boundary is visible. Abstracting at variant #1 or #2 = fitting on insufficient samples; you'll overfit and the abstraction collapses when variant #3 arrives. Sandi Metz: "duplication is far cheaper than the wrong abstraction." Reverse trap: don't push YAGNI into architecture-level decisions (data model, core APIs, deployment topology) — those have the highest interest rate when wrong. YAGNI applies to implementation layer, not architecture layer. Fowler's Rule of Three: tolerate duplication twice; abstract on the third occurrence when samples are sufficient.
AI Prompts
中文提示词
我正在考虑给 [代码/系统/流程] 加一层抽象/通用框架。请压力测试：
① 我目前手上有几个真实出现过的变体？少于 3 个 → YAGNI 触发，请说服我先复制；
② 如果硬抽象，最可能 overfit 到哪个特性，将来第 3 个变体出现时如何 break？
③ 区分这个决策属于"实现层"还是"架构层"——若是架构层，给出必须现在决定的最小决策集。
English Prompt
I'm about to add an abstraction / generic framework to [code/system/process]. Stress-test me:
1. How many real observed variants do I have? If < 3 → YAGNI trigger; argue me into duplicating first.
2. If I abstract now, which feature am I most likely overfitting to, and how does it break when variant #3 arrives?
3. Classify the decision as implementation-layer vs architecture-layer. If architecture-layer, name the minimal set of decisions that must be made now.