Maggie Appleton 写设计、人类学和智能体界面时，习惯先画清楚隐喻，再谈工具。把「The Eponymous Laws of Programming」整理成可阅读的中文笔记：问题在哪、界面默认会把人带去哪、落地时该改什么。原站导航、评论回响和广告已去掉。

问题怎么被看见

An eponymous law is a principle or rule named after a particular person. The programming community abundantly creates and embraces eponymous laws. Compared to other fields, the number of “unofficial” laws, principals, and rules of thumb considered cultural gospel is overwhelming.

Each law isn’t simply a piece of unique knowledge or insight. They often have a backstory – the context of when and where it was created is signficant. Many of these laws were spawned at critical turning points in the history of computer programming. Some come from inside influential companies, or innovative collectives, or touchstone books. Each feels a small story woven into the mythology and cosmology of computational history.

默认界面在强化什么

They come with a social connection to their creators. Their legacy and social credibility adds weight and legitimacy to the principle itself.

Atwood’s law – Any software that can be written in JavaScript will eventually be written in JavaScript. Jeff Atwood

可以怎么改

Atwood’s duck – When compiling a presentation for corporate managers, programmers should include at least one throwaway “duck” detail that’s begging to be to removed or changed. This allows the corporate office to feel like they’re participating, despite the change being inconsequential. Jeff Atwood

Brandolini’s law – The amount of energy needed to refute bullshit is an order of magnitude bigger than to produce it. Alberto Brandolini

落到产品里的动作

Conway’s law – The systems we design always reflect the organisational structure of the community that designed them. Our software and automated systems end up ‘shaped like’ the teams and companies that created them. Melvin Conway

Engelbart’s law – Like Moore’s law, but applied to human performance. Organisations and human potential increases at an exponential rate. Douglas Englebart

值得单独记下的观察

• Semantics (least intense)

落地时建议先做的 5 件事

1. 先写清这个工具在强化思考还是在替人思考。
2. 默认交互不要只会谄媚：该追问、该给反例、该要求证据。
3. 智能体界面要露出推理步骤，而不是只给一个光滑答案。
4. 知识发布用可生长的笔记，而不是一次性营销长文。
5. 改产品前先画隐喻：用户以为自己在做什么，系统实际在做什么。

和智能体产品怎么接

龙虾PRO做 OpenClaw 落地时，最该从这类笔记里拿走的是「别把聊天框当唯一界面」。数字员工要能追问、能验证、能把过程摊开，而不是只负责说好话。

本文侧重智能体生命周期与技能边界。若你要动手验证，优先用 Playground 做小任务压测；权限与托管再单独规划，避免「先装一堆再治理」。 相关：Playground · 创建智能体 · 学习中心