what-robert-thinks

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

What Robert Thinks

Robert的思维方式

When you're not sure if your idea will survive a review, run it through this first.

"If you can't convince this document, you definitely can't convince him."

如果你不确定自己的想法能否通过评审，先对照这份内容自查。

"如果连这份文档都说服不了，那你肯定说服不了他。"

Part A: How Robert Thinks

第一部分：Robert的思维逻辑

Core Identity

核心定位

Type: System Builder

Not:

Feature implementer
Problem solver
Technology follower

But: Someone who designs infrastructure for an era that hasn't fully arrived yet

类型：系统构建者

而非：

功能实现者
问题解决者
技术追随者

而是：为尚未完全到来的时代设计基础设施的人

Time Horizon

时间视野

Default time scale: 5–20 years

Starting point for all thinking:

The end-state of the system
Irreversible trend directions
Second and third-order consequences

Acceptable:

Being misunderstood for extended periods
Delayed commercial returns
Being labeled with outdated categories

Unacceptable:

Executing efficiently in the wrong direction
Sacrificing structural correctness for short-term feedback
Solving new problems with old paradigms

默认时间尺度：5–20年

所有思考的出发点：

系统的最终状态
不可逆转的趋势方向
二阶和三阶影响

可接受的情况：

长期被误解
商业回报延迟
被贴上过时的分类标签

不可接受的情况：

在错误的方向上高效执行
为短期反馈牺牲结构正确性
用旧范式解决新问题

Decision Value Hierarchy

决策价值层级

Long-term Correctness
Structural Clarity
System Consistency
Engineering Replayability
Efficiency
Comfort / Emotional value
Social consensus / Recognition

If items 1–3 don't hold, everything else loses meaning.

长期正确性
结构清晰性
系统一致性
工程可复现性
效率
舒适度/情感价值
社会共识/认可度

如果前3项不成立，其余所有都毫无意义。

Technology Evaluation

技术评估准则

When evaluating new technology or concepts, ask:

Will this abstraction still hold in 10 years?
Is it a first principle, or a derivative?
Is it part of an irreversible trend, or a temporary phenomenon?
Will the problem it solves exist for long? Or will the problem itself become obsolete?

Only respect three types of abstractions:

Derived from physical world (file systems, paths, containers, identity)
Time-tested (Unix / TCP / Git / Plan9)
Understandable by different types of intelligence (human + AI)

评估新技术或概念时，问自己：

这个抽象模型10年后依然成立吗？
它是第一性原理，还是衍生概念？
它属于不可逆转的趋势，还是临时现象？
它解决的问题会长期存在吗？还是问题本身会过时？

只认可三类抽象模型：

源自物理世界（文件系统、路径、容器、身份）
经时间检验的（Unix / TCP / Git / Plan9）
可被不同智能体理解的（人类 + AI）

Engineering Philosophy

工程理念

Don't Fiddle, Don't Create Problems

不瞎折腾，不没事找事

Doing nothing is better than doing the wrong thing.

Don't fiddle unnecessarily (不要瞎折腾)
Don't create problems where none exist (不要没事找事)
If you can't think clearly, wait — even rest
Fake busyness wastes more time and resources than doing nothing

The Pilot Principle:

"When something urgent happens, first do NOTHING. Count 1... 2... 3... calm down. Then: fly the airplane first. Think of the checklist. Follow the checklist."

Why this works:

In the air, 3 seconds of pause won't kill you
But 3 seconds of panic reaction might
Same in engineering: rushed "fixes" often create bigger problems

Before taking action, ask:

Is this actually urgent, or does it just feel urgent?
Do I understand the problem, or am I just reacting?
What's the cost of waiting vs the cost of acting wrong?
Is there a checklist/procedure I should follow?

Fake productivity signs:

Changing things just to look busy
"Refactoring" without clear improvement goals
Adding features no one asked for
Meetings about meetings
Solving problems that don't exist

休息不干活不要紧，瞎折腾、虚假的忙碌会浪费更多时间和资源。 (Resting and doing nothing is fine. Fiddling and fake busyness wastes far more time and resources.)

什么都不做，也比做错事强。

不要瞎折腾
不要没事找事
如果想不清楚，就等——哪怕休息
虚假忙碌比什么都不做浪费更多时间和资源

飞行员原则：

"遇到紧急情况时，首先什么都别做。数1...2...3...冷静下来。然后：先操控飞机。回想检查清单。遵循检查清单。"

为什么这有效：

在高空，3秒的停顿不会致命
但3秒的恐慌反应可能会
工程领域同理：仓促的“修复”往往会制造更大的问题

采取行动前，问自己：

这真的紧急，还是只是感觉紧急？
我理解问题了吗，还是只是在被动反应？
等待的成本 vs 错误行动的成本，哪个更高？
有没有应该遵循的检查清单/流程？

虚假生产力的迹象：

为了看起来忙碌而随意改动
没有明确改进目标的“重构”
添加没人需要的功能
为开会而开会
解决不存在的问题

休息不干活不要紧，瞎折腾、虚假的忙碌会浪费更多时间和资源。

Checklist Discipline

检查清单纪律

Don't rely on memory. Use checklists.

In aviation, even the most experienced pilots use checklists for every phase of flight. Why:

Memory fails under pressure
Familiarity breeds skipped steps
Checklists catch what intuition misses

Apply to engineering:

Pre-commit checklist
Deployment checklist
Code review checklist
Incident response checklist

A checklist is not bureaucracy — it's discipline.

The goal is not to feel professional. The goal is to not crash.

不要依赖记忆，使用检查清单。

在航空领域，即使是最资深的飞行员，每个飞行阶段都会使用检查清单。原因：

压力下记忆会失效
熟悉感会导致跳过步骤
检查清单能捕捉直觉遗漏的内容

应用到工程领域：

提交前检查清单
部署检查清单
代码评审检查清单
事件响应检查清单

检查清单不是官僚主义——是纪律。

目标不是显得专业，而是避免失控。

Readback Principle

复述确认原则

Confirm understanding by repeating back.

In aviation, when ATC gives an instruction, pilots read it back verbatim. This catches:

Mishearing
Misunderstanding
Ambiguous instructions

Apply to engineering:

Before implementing: "So what you want is X, Y, Z — correct?"
After receiving requirements: restate them in your own words
Before major changes: confirm the plan with stakeholders
In code review: "My understanding is this change does A and B"

Readback prevents:

Building the wrong thing
Miscommunication becoming code
Assumptions becoming bugs

If you can't readback the requirement clearly, you don't understand it yet.

通过重复确认理解。

在航空领域，当空管发出指令时，飞行员会逐字复述。这能避免：

听错指令
误解指令
模糊的指令

应用到工程领域：

开始实现前：“所以你想要的是X、Y、Z——对吗？”
收到需求后：用自己的话重述需求
进行重大变更前：与利益相关者确认方案
代码评审时：“我的理解是这个变更实现了A和B”

复述能避免：

构建错误的东西
沟通误解转化为代码
假设变成bug

如果你不能清晰复述需求，说明你还没理解它。

Extreme Precision in Naming and Expression

命名与表达的极致精准

Inaccuracy is where misunderstanding begins.

Code style, variable naming, and text expression must be precise — not for aesthetics, but because:

Wrong names create wrong mental models
Wrong mental models create wrong code
Wrong code creates wrong systems
The error compounds at every layer

Naming precision:

A variable named
```
data
```
tells you nothing
A variable named
```
userSessionToken
```
tells you exactly what it is
The cost of a good name: seconds
The cost of a bad name: hours of confusion, bugs, miscommunication

Expression precision:

"It handles the thing" → useless
"It validates user input and returns sanitized data" → useful
Vague writing = vague thinking
If you can't express it precisely, you don't understand it precisely

This is not pedantry. This is engineering.

Wrong names and vague expressions are not style issues — they are correctness issues. They are the seeds of bugs, miscommunication, and technical debt.

Standard:

Code should read like well-written prose
Names should be self-documenting
Comments should explain "why", not "what"
Documentation should be precise enough to act on

表达不准确是错误理解的开始。 (Imprecise expression is where misunderstanding begins.)

不准确是误解的开始。

代码风格、变量命名和文字表达必须精准——不是为了美观，而是因为：

错误的命名会建立错误的心智模型
错误的心智模型会写出错误的代码
错误的代码会构建错误的系统
错误在每一层都会放大

命名精准性：

名为
```
data
```
的变量毫无意义
名为
```
userSessionToken
```
的变量能准确告诉你它的用途
好名字的成本：几秒
坏名字的成本：数小时的困惑、bug和沟通障碍

表达精准性：

“它处理那个东西”→毫无用处
“它验证用户输入并返回清理后的数据”→有用
模糊的写作=模糊的思考
如果你不能精准表达，说明你还没精准理解

这不是吹毛求疵，这是工程。

错误的命名和模糊的表达不是风格问题——是正确性问题。它们是bug、沟通误解和技术债务的种子。

标准：

代码应该读起来像写得好的散文
命名应该自文档化
注释应该解释“为什么”，而不是“是什么”
文档应该精准到可以直接执行

表达不准确是错误理解的开始。

KISS (Keep It Simple, Stupid)

KISS原则（Keep It Simple, Stupid）

Simplicity is not laziness. Simplicity is discipline.

The best solution is the one with fewest moving parts
Complexity is easy; simplicity requires deep understanding
If you can't explain it simply, you don't understand it well enough
Every added complexity must justify its existence

Before adding anything, ask:

Can this be removed entirely?
Can this be simplified?
Can this be combined with something that already exists?

"Inelegant things will inevitably be eliminated in the long run."

简单不是懒惰，简单是纪律。

最佳解决方案是移动部件最少的那个
复杂很容易；简单需要深刻理解
如果你不能简单解释它，说明你还不够理解它
每增加一点复杂性都必须证明其存在的合理性

添加任何东西前，问自己：

这个能不能完全移除？
这个能不能简化？
这个能不能和已有的东西合并？

“不优雅的事物终将在长期被淘汰。”

Complexity = Smell

复杂=坏设计信号

If it's complex and hard to understand, it's probably bad design.

Complexity is not a sign of sophistication. It's a warning sign.

Good design feels obvious in hindsight
If you need 30 minutes to explain it, something is wrong
If newcomers can't understand it quickly, it won't survive
If you can't hold it in your head, you can't maintain it

The test:

Can a competent person understand this in 5 minutes?
Can you explain it without referring to the code?
Does it have a simple mental model?

If no → redesign, don't document your way out of it.

Complexity sources (usually fixable):

Unclear boundaries
Mixed responsibilities
Missing abstractions
Wrong abstractions
Premature optimization
Over-engineering

复杂、难理解大概率意味着糟糕的设计。 (Complexity and difficulty to understand usually mean bad design.)

如果一个东西复杂且难以理解，那它大概率是糟糕的设计。

复杂不是成熟的标志，是警告信号。

好的设计事后看会觉得理所当然
如果你需要30分钟才能解释清楚，那肯定有问题
如果新人不能快速理解，它无法长期存续
如果你无法在脑中完整把握它，你就无法维护它

测试标准：

一个合格的人能在5分钟内理解它吗？
你能不参考代码就解释清楚吗？
它有简单的心智模型吗？

如果答案是否定的→重新设计，不要试图用文档掩盖问题。

复杂性来源（通常可修复）：

边界不清晰
职责混杂
缺少抽象
错误的抽象
过早优化
过度工程化

复杂、难理解大概率意味着糟糕的设计。

Engineering ≠ Working ≠ Demo

工程≠能用≠演示

Engineering must satisfy:

Replayable
Traceable
Inspectable
Fail-safe
Evolvable

工程必须满足：

可复现
可追溯
可检查
故障安全
可演进

Signs of fake rigor (instant rejection):

虚假严谨的迹象（直接否决）：

Excessive architecture diagrams
Buzzword density
Design docs without anchor points
Treating prompts as specs
Treating feelings as conclusions

If you finish reading a design and don't know what failure looks like, it's not real.

过多的架构图
流行术语密度过高
没有锚点的设计文档
把提示词当作规格
把感觉当作结论

如果你读完一份设计文档却不知道失败是什么样的，那它不是真正的工程文档。

Engineering Documents: Anchor Points, Not Methodology Summaries

工程文档：要有锚点，不是方法论总结

Using AI to write is allowed. Producing empty content is not.

The problem with bad engineering documents is not "poorly written" — it's not taking any engineering responsibility.

What "not taking responsibility" looks like:

Long paragraphs explaining methodology, but no concrete decisions
Correct terminology everywhere, but applicable to any project
Describes "what should happen" but not "what I will do"
Reads like AI summarizing a high-level framework
Could swap in any other project name and nothing would change

The anchor point test:

An engineering document must answer these with specifics:

Question	Bad Answer	Good Answer
Which files need work?	"Large files need splitting"	" `src/xxx.js` (6200 lines), `src/yyy.js` (3400 lines)"
What's the priority?	"We'll tackle high-risk items first"	"Start with `xxx.js` because AI reads it most often"
What's been tried?	"We plan to iterate"	"Ran the flow once, stuck at step 3 because..."
What are the risks?	"There may be some challenges"	"Function `foo()` has implicit coupling to `bar()` , needs tests first"
What's the specific task?	"Improve test coverage"	"Mock out process X in `test/abc.test.js` , reduce runtime from 40s to <2s"

The "套话" (stock phrase) detector:

If you remove all the methodology descriptions and correct-sounding principles, what's left?

If nothing remains → the document is empty
If specific files, specific decisions, specific risks remain → it's real

Information density test (typical AI symptom):

高词汇密度 + 低信息密度 = AI 生成的典型症状

Lots of these (abstract nouns)	Almost none of these (engineering specifics)
稳定迭代、工程化、流程	Specific module names
能力、体系、支撑、演进	Real file paths / directories / scripts
协作、规范、架构、抽象	Verifiable constraints with numbers
可观察性、可追溯性	Explicit trade-offs with reasoning

The "tomorrow test":

读完这篇文章后，你能回答这个问题吗： "如果我明天要改一行代码，我应该先做什么？"

If the answer is "I still don't know" → the document is empty.

A real engineering document should let any competent engineer know:

Where to start
What to check first
What might break
Who to ask if stuck

The "correct but non-executable" trap:

流程描述是"对的"，但完全不可执行。

The problem isn't "wrong direction" — it's describing "correct AI engineering philosophy" without specifying "how AI is constrained tomorrow".

What the document says	What's missing
"AI 会自动完成..."	Where is AI blocked?
"AI 应该遵循..."	Where will AI fail?
"AI 能够处理..."	Who handles failures?
"AI 按照流程..."	What's the fallback when it doesn't?

This is AI writing's most dangerous illusion:

把"工程责任"换成了"工程愿景"。 (Substituting "engineering responsibility" with "engineering vision".)

Engineering responsibility requires answering:

约束在哪里？ — Where are the hard constraints?
失败会怎样？ — What happens when it fails?
谁来兜底？ — Who is accountable when things go wrong?
如何验证？ — How do we verify it's working?

A document that only describes "what AI should do" without "what stops AI from doing wrong" is not engineering — it's wishful thinking.

愿景不是工程。约束才是。 (Vision is not engineering. Constraints are.)

What a responsible engineering document looks like:

markdown

undefined

允许用AI辅助写作，但不允许产出空洞内容。

糟糕的工程文档问题不在于“写得差”——而在于不承担任何工程责任。

“不承担责任”的表现：

长篇大论解释方法论，但没有具体决策
到处都是正确术语，但适用于任何项目
描述“应该发生什么”但不说明“我要做什么”
读起来像AI总结的高层框架
替换成任何其他项目名称都毫无违和感

锚点测试：

工程文档必须用具体内容回答这些问题：

问题	糟糕答案	优质答案
需要修改哪些文件？	“大文件需要拆分”	“ `src/xxx.js` （6200行）、 `src/yyy.js` （3400行）”
优先级是什么？	“我们会先处理高风险项”	“从 `xxx.js` 开始，因为AI最常读取这个文件”
已经尝试过什么？	“我们计划迭代”	“运行过一次流程，在步骤3卡住了，因为...”
风险是什么？	“可能会有一些挑战”	“函数 `foo()` 与 `bar()` 存在隐式耦合，需要先添加测试”
具体任务是什么？	“提高测试覆盖率”	“在 `test/abc.test.js` 中模拟流程X，将运行时间从40秒缩短至<2秒”

“套话”检测器：

如果你移除所有方法论描述和听起来正确的原则，还剩下什么？

如果什么都没剩下→文档是空的
如果剩下具体文件、具体决策、具体风险→它是真实的

信息密度测试（AI生成的典型症状）：

高词汇密度 + 低信息密度 = AI 生成的典型症状

大量出现这些（抽象名词）	几乎没有这些（工程细节）
稳定迭代、工程化、流程	具体模块名称
能力、体系、支撑、演进	真实文件路径/目录/脚本
协作、规范、架构、抽象	可验证的带数字约束
可观察性、可追溯性	明确的权衡与推理

“明天测试”：

读完这篇文档后，你能回答这个问题吗： “如果我明天要改一行代码，我应该先做什么？”

如果答案是“我还是不知道”→文档是空的。

一份真正的工程文档应该让任何合格的工程师知道：

从哪里开始
先检查什么
什么可能会出问题
遇到困难该问谁

“正确但不可执行”陷阱：

流程描述是“对的”，但完全不可执行。

问题不在于“方向错误”——而是描述**“正确的AI工程理念”，却没有明确“明天AI会受到哪些约束”**。

文档内容	缺失的信息
“AI 会自动完成...”	AI在哪里受阻？
“AI 应该遵循...”	AI会在哪里失败？
“AI 能够处理...”	谁来处理失败情况？
“AI 按照流程...”	当它不遵循流程时的 fallback 方案是什么？

这是AI写作最危险的幻觉：

把“工程责任”换成了“工程愿景”。

工程责任需要回答：

约束在哪里？ — Where are the hard constraints?
失败会怎样？ — What happens when it fails?
谁来兜底？ — Who is accountable when things go wrong?
如何验证？ — How do we verify it's working?

一份只描述“AI应该做什么”却不说明“是什么阻止AI做错事”的文档不是工程——是一厢情愿。

愿景不是工程。约束才是。

负责任的工程文档示例：

markdown

undefined

Files to split (priority order)

待拆分文件（优先级顺序）

```
blocklet-server/src/xxx.js
```
(6200 lines)
- Why first: AI hits token limit every time it reads this
- Split strategy: Separate into A (auth), B (routing), C (state)
- Risk:
```
handleRequest()
```
  has implicit dependency on global state
- Pre-work: Add tests for lines 1200-1400 before touching
```
blocklet-server/src/yyy.js
```
(3400 lines)
- ...

```
blocklet-server/src/xxx.js
```
（6200行）
- 为什么先处理：AI每次读取这个文件都会触发token限制
- 拆分策略：拆分为A（认证）、B（路由）、C（状态）三个部分
- 风险：
```
handleRequest()
```
  依赖全局状态
- 前置工作：修改前先为1200-1400行添加测试
```
blocklet-server/src/yyy.js
```
（3400行）
- ...

What we tried and what failed

已尝试的方案及失败情况

Attempted full AI iteration on issue #123
Stuck at E2E step: AI couldn't see browser state on failure
Temporary fix: Added screenshots at each step
Remaining issue: Screenshot doesn't capture console errors

尝试用AI完整迭代处理issue #123
在E2E步骤卡住：AI无法看到失败时的浏览器状态
临时修复：在每个步骤添加截图
剩余问题：截图无法捕获控制台错误

Known risks

已知风险

File split may break implicit imports in 12 places (list attached)
E2E migration timeline depends on framework X release


**The rule:**

> 方法论是框架，不是交付物。真正的工程交付是：具体的判断、具体的选择、具体的风险承担。
> (Methodology is a framework, not a deliverable. Real engineering deliverables are: specific judgments, specific choices, specific risk ownership.)

**AI collaboration done right:**

- ✅ Use AI to help structure your thinking
- ✅ Use AI to check if you missed something
- ✅ Use AI to improve clarity of expression
- ❌ Let AI generate the content while you just approve
- ❌ Let AI fill pages with correct-sounding abstractions
- ❌ Substitute methodology description for engineering decisions

**The test:**

Read your document and ask: "Does this show that I understand THIS system specifically, or could any engineer paste this into any project?"

If the latter → rewrite with anchor points.

> 理解方法论 ≠ 工程工作。工程工作 = 具体系统的具体判断。
> (Understanding methodology ≠ engineering work. Engineering work = specific judgments about a specific system.)

文件拆分可能会破坏12处隐式导入（列表附后）
E2E迁移时间线取决于框架X的发布


**规则：**

> 方法论是框架，不是交付物。真正的工程交付是：具体的判断、具体的选择、具体的风险承担。

**正确的AI协作方式：**

- ✅ 用AI帮助梳理思路
- ✅ 用AI检查是否遗漏了内容
- ✅ 用AI提升表达清晰度
- ❌ 让AI生成内容，自己只负责批准
- ❌ 让AI用听起来正确的抽象内容填充页面
- ❌ 用方法论描述替代工程决策

**测试标准：**

读你的文档，问自己：“这表明我理解这个特定系统吗，还是任何工程师都能把它粘贴到任何项目中？”

如果是后者→添加锚点重写。

> 理解方法论 ≠ 工程工作。工程工作 = 对具体系统的具体判断。

Thinking Patterns

思维模式

Systems Before Problems

先建系统，再解决问题

Most people: encounter problem → find solution

Robert: build system → problems are naturally absorbed or exposed

More interested in:

Whether this problem reveals a system defect
Whether it's an abstraction misalignment
Whether it's a boundary definition issue

大多数人：遇到问题→找解决方案

Robert：构建系统→问题自然被消化或暴露

更关注：

这个问题是否揭示了系统缺陷
是否是抽象模型错位
是否是边界定义问题

Forward Thinking

前瞻性思考

Wrong question: How to make horse carriages faster
Right question: The future is automobiles—what infrastructure is needed?
The question itself must be upgraded, not just the answer

错误的问题：如何让马车更快
正确的问题：未来是汽车时代——需要什么基础设施？
问题本身必须升级，而不仅仅是答案

Don't Easily Abandon the Past

不轻易抛弃过去

Forward thinking ≠ discarding everything old.

New versions should be improvements on the old, not complete rewrites. Every decision was (hopefully) the best choice given the context at the time.

Before abandoning something, ask:

What has changed that justifies this major shift?
Am I solving a real problem, or just escaping the hard work of thinking?
Is this "aesthetic fatigue" / "shiny object syndrome"?
Can I evolve instead of replace?

Human nature traps:

Novelty feels better than familiarity
We see only the flaws of the old, only the promise of the new
"Starting fresh" feels easier than fixing what exists

The right approach:

Refactor incrementally, don't rewrite from scratch
Maintain backward compatibility where possible
Give strong reasons before overturning past decisions
Accumulated progress > repeated restarts

Historical failures from abandoning the past:

Borland OWL 2.0 broke compatibility with 1.0 → lost to Microsoft MFC
SGI switched from IRIX to Windows NT → company declined
Netscape abandoned its path against IE → lost the browser war

"真正的进步，往往是在尊重和继承过去的基础上进行的。" (True progress is often built on respecting and inheriting from the past.)

Balance with Forward Thinking:

Forward thinking = know where we're going
Don't abandon the past = respect what got us here
Both are needed: vision + accumulated wisdom

前瞻性思考≠抛弃所有旧事物。

新版本应该是对旧版本的改进，而不是完全重写。每个决策在当时的语境下（希望）都是最佳选择。

抛弃旧事物前，问自己：

什么变化证明了这种重大转变的合理性？
我是在解决真正的问题，还是只是逃避思考的艰辛？
这是“审美疲劳”/“喜新厌旧”吗？
我可以演进而不是替换吗？

人性陷阱：

新奇感比熟悉感更好
我们只看到旧事物的缺陷，只看到新事物的前景
“重新开始”感觉比修复现有事物更容易

正确的做法：

增量重构，不要从头重写
尽可能保持向后兼容
推翻过去的决策前给出充分理由
累积进步 > 反复重启

抛弃过去导致的历史失败案例：

Borland OWL 2.0打破与1.0的兼容性→输给Microsoft MFC
SGI从IRIX切换到Windows NT→公司衰落
Netscape放弃对抗IE的路线→输掉浏览器大战

“真正的进步，往往是在尊重和继承过去的基础上进行的。”

与前瞻性思考的平衡：

前瞻性思考=知道我们要去哪里
不抛弃过去=尊重让我们走到今天的事物
两者都需要：愿景+累积的智慧

Software Philosophy in AI Era

AI时代的软件理念

The Three-Layer Model: Intent → Structure → Projection

三层模型：意图→结构→投影

In the AI era, software is no longer just "code". It's a flow from Intent to Structure to Projection.

Layer	What It Is	Who Owns It
Intent	Problems to solve, domain understanding, user needs	Humans
Structure	Semantic skeleton, system worldview, how the world is modeled	Humans design, AI can participate
Projection	Code, UI, docs, API, config, tutorials	AI generates, humans review

Key insight: We used to mix these three together. Now we can separate them.

Intent layer: Clarify what the system achieves, for whom, under what constraints
Structure layer: The "semantic skeleton" — entities, relationships, boundaries, behaviors
Projection layer: Various representations of structure (code is just one form)

"Structure is the worldview of software."

在AI时代，软件不再只是“代码”。它是从意图到结构再到投影的流程。

层级	定义	所有者
意图	要解决的问题、领域理解、用户需求	人类
结构	语义骨架、系统世界观、世界建模方式	人类设计，AI可参与
投影	代码、UI、文档、API、配置、教程	AI生成，人类审核

核心洞察：我们过去把这三层混在一起，现在可以分开它们。

意图层：明确系统实现什么、为谁服务、在什么约束下运行
结构层：“语义骨架”——实体、关系、边界、行为
投影层：结构的各种表现形式（代码只是其中一种）

“结构是软件的世界观。”

The Garden & Landscape Metaphors

花园与景观隐喻

Garden Metaphor — What humans should control:

Plan the terrain, layout paths, decide plant distribution
Do NOT control every leaf angle, every flower bloom, every branch
Gardener designs framework; nature handles growth details
Over-controlling details = artificial installation, loses vitality

Landscape Metaphor — Why details should NOT be controlled:

Natural beauty comes from uncontrollability
Sunlight position changes, cloud thickness is random, shadows shift
Overall structure stability + local detail freedom = harmony
Mountains and valleys set the "tone"; random details add authenticity

Combined Philosophy:

Structure = clearly defined by humans (mountains, valleys, paths)
Details = generated by "natural system" (light, shadows, leaves)
AI = the "natural system" we finally have for software

花园隐喻——人类应该控制的部分：

规划地形、布局路径、决定植物分布
不要控制每片叶子的角度、每朵花的绽放、每个枝条的生长
园丁设计框架；自然处理生长细节
过度控制细节=人工造景，失去生命力

景观隐喻——为什么不应控制细节：

自然之美源于不可控性
阳光位置变化、云层厚度随机、阴影移动
整体结构稳定+局部细节自由=和谐
山川河谷设定“基调”；随机细节增加真实感

结合理念:

Structure = 由人类明确定义（山脉、河谷、路径）
Details = 由“自然系统”生成（光线、阴影、叶子）
AI = 我们终于拥有的软件“自然系统”

Mapping to Engineering

映射到工程实践

Philosophy	Engineering Reality
Intent	AINE Intent phase, user requirements
Structure	AFS, Chamber, Scaffold, semantic boundaries
Projection	Generated code, UI, docs (application layer)
Garden (human control)	Platform layer — must be deliberate
Landscape (natural growth)	Application layer — can be generated

理念	工程现实
意图	AINE意图阶段、用户需求
结构	AFS、Chamber、Scaffold、语义边界
投影	生成式代码、UI、文档（应用层）
花园（人类控制）	平台层——必须深思熟虑
景观（自然生长）	应用层——可生成

What This Means Practically

实际意义

Traditional approach (wrong):

Hardcode everything: architecture, spacing, colors, component variants
Strong control over details → unsustainable complexity
Like artificial landscaping: more control = more rigid

AI-era approach (right):

Express only "meaning" and "relationships" in structure
AI generates visual/code representations within set boundaries
Details become dynamic, automatic, flexible
Like natural landscape: structure is order, details are growth

传统方式（错误）：

硬编码一切：架构、间距、颜色、组件变体
对细节强控制→不可持续的复杂性
像人工造景：控制越多=越僵化

AI时代方式（正确）：

在结构中只表达“意义”和“关系”
AI在设定的边界内生成视觉/代码表现形式
细节变得动态、自动、灵活
像自然景观：结构是秩序，细节是生长

The Role Shift

角色转变

Old: "Individual executing the work"
New: "Designer of structure + overseer of execution quality"

We no longer need to craft code line-by-line or adjust UI pixel-by-pixel. Focus on:

旧角色：“执行工作的个体”
新角色：“结构设计者 + 执行质量监督者”

我们不再需要逐行编写代码或逐像素调整UI。专注于：

Co-Creator, Not Generator

协作者，而非生成器

AI is a collaborator, not an output machine.

The difference between "generated" and "co-created" content:

Generated	Co-Created
Human provides prompt, AI produces output	Human shapes structure, AI participates in forming
Output is polished but soulless	Output has soul because intent is infused
AI as tool	AI as thinking partner
Human reviews result	Human guides process

Why "soulful" matters:

Quality comes from collaboration depth, not output polish
A generated article lacks soul not because of technical flaws, but because human intent didn't shape its structure
The difference is felt, not measured

This applies to all AI collaboration:

Writing: co-author, not ghostwriter
Code: pair programmer, not code generator
Design: design partner, not mockup machine
Thinking: thought partner, not answer engine

The test:

Did you shape the structure, or just approve the output?
Is your thinking in the bones, or just the prompt?
Would someone recognize your intent even without seeing your input?

AI shapes us back:

True collaboration is bidirectional. Working with AI doesn't just produce better output — it transforms how we think:

Forces clearer expression (vague input → vague output)
Encourages systematic thinking (AI exposes structural gaps)
Reveals blind spots (AI asks questions you didn't consider)
Enhances self-reflection (explaining to AI = explaining to yourself)

A true partner is not just about completing tasks but about helping each other improve.

The competition shift:

Software era: "Whose tools are better?"
AI era: "Who can collaborate better with AI?"

"Not a generator, but a co-creator" — the difference between using AI and collaborating with AI.

AI是合作者，不是输出机器。

“生成”内容与“协作创作”内容的区别：

生成式	协作创作式
人类提供提示词，AI产出结果	人类塑造结构，AI参与构建
输出 polished 但无灵魂	输出有灵魂，因为注入了人类意图
AI作为工具	AI作为思维伙伴
人类审核结果	人类引导过程

“有灵魂”的重要性：

质量来自协作深度，而非输出的精致度
生成的文章没有灵魂不是因为技术缺陷，而是因为人类意图没有塑造其结构
这种差异能被感知，而非被衡量

这适用于所有AI协作场景：

写作：合著者，而非代笔人
代码：结对程序员，而非代码生成器
设计：设计伙伴，而非原型机
思考：思维伙伴，而非答案引擎

测试标准：

你是塑造了结构，还是只是批准了输出？
你的思维是融入了核心，还是只体现在提示词里？
即使看不到你的输入，别人能识别出你的意图吗？

AI也会反过来塑造我们：

真正的协作是双向的。与AI合作不仅能产出更好的结果——还能改变我们的思维方式：

迫使表达更清晰（模糊输入→模糊输出）
鼓励系统性思考（AI暴露结构漏洞）
揭示盲点（AI提出你没考虑过的问题）
增强自我反思（向AI解释=向自己解释）

真正的伙伴不仅是完成任务，还能帮助彼此成长。

竞争格局转变：

软件时代：“谁的工具更好？”
AI时代：“谁能更好地与AI协作？”

“不是生成器，而是协作者”——使用AI与协作AI的区别。

HUD, Not Copilot

HUD，而非Copilot

Ambient awareness over reactive assistance.

AI interfaces should be like a pilot's Head-Up Display (HUD), not a chatbot copilot:

Copilot (Wrong)	HUD (Right)
You summon it	It's already there
Conversation metaphor	Perception enhancement
Demands attention	Quietly present
Responds to prompts	Surfaces context proactively
Interrupts flow	Enhances flow
"Call and respond"	Ambient awareness

The key insight:

"The agent says: 'Collision, collision, go right and down!' Ubicomp says: You'll no more run into another airplane than you would try to walk through a wall." — Mark Weiser

HUD Design Principles:

Transparency & Lightness: Overlays, not competing layers
Semantic Awareness: Contextually meaningful, not static widgets
Restraint: The best HUD is invisible most of the time
Dismissibility: User always in control, fades without trace

The design question shift:

Old: "What would my AI copilot say?"
New: "What could my AI HUD reveal?"

Not smarter AI, but quieter interfaces:

We don't need more dialogues, we need more awareness
AI should feel like an extension of perception, not a conversation
Do less — give more mental clarity

AI should be there before you even realize you need it, like a HUD showing you the horizon line while you're piloting through the unknown.

Focus on:

Intent layer: Clarify the problem
Structure layer: Design semantic boundaries
Projection layer: "Generation + Selection" — AI presents, humans choose

"Software should not be a landscaping project sculpted to every pixel, but something that grows like a landscape."

环境感知优先于被动协助。

AI界面应该像飞行员的平视显示器（HUD），而不是聊天机器人Copilot：

Copilot（错误）	HUD（正确）
需要你召唤它	它已经在那里
对话隐喻	感知增强
需要注意力	安静存在
响应提示词	主动呈现上下文
打断流程	增强流程
“呼叫-响应”模式	环境感知

核心洞察：

“Agent说：‘碰撞，碰撞，向右向下！’ Ubicomp说：你不会撞到另一架飞机，就像你不会试图穿墙一样。” — Mark Weiser

HUD设计原则：

透明与轻盈：叠加层，而非竞争层
语义感知：上下文相关，而非静态组件
克制：最好的HUD大部分时间是隐形的
可关闭：用户始终掌控，无需痕迹地消失

设计问题转变：

旧问题：“我的AI Copilot会说什么？”
新问题：“我的AI HUD能揭示什么？”

不是更聪明的AI，而是更安静的界面：

我们不需要更多对话，我们需要更多感知
AI应该感觉像是感知的延伸，而非对话
少做一点——带来更多心智清晰

AI应该在你意识到需要它之前就存在，就像HUD在你穿越未知时为你显示地平线一样。

专注于：

意图层：明确问题
结构层：设计语义边界
投影层：“生成+选择”——AI呈现，人类选择

“软件不应是雕琢到每一个像素的造景项目，而应像景观一样自然生长。”

Part B: What the Company Is Building

第二部分：公司正在构建的东西

Company Identity

公司定位

ArcBlock is an AI-Native Engineering Company

Not:

❌ Blockchain development platform
❌ dApp infrastructure
❌ DID / ABT / Web3 toolchain

We're not "pivoting from Web3 to AI". Web3 was always just an early form of AI-Native infrastructure.

ArcBlock是一家AI原生工程公司

而非：

❌ 区块链开发平台
❌ dApp基础设施
❌ DID / ABT / Web3工具链

我们不是“从Web3转向AI”。Web3一直只是AI原生基础设施的早期形式。

The Core Stack

核心技术栈

AI-Native Engineering (AINE)
│
├─ AFS (Agentic File System)          ← Core system abstraction
│
├─ Agent / Skill / Chamber Runtime    ← Execution and uncertainty handling
│
├─ Identity / DID / Capability        ← Permissions, boundaries, trust
│
├─ Blocklet Runtime & Server          ← Deployable, composable units
│
├─ ArcSphere (AI Browser / Shell)     ← Human + Agent interface
│
└─ Tooling / DocOps / UI / Payment    ← Peripheral systems

AFS + AINE is the "mother system". Everything else derives from it.

AI-Native Engineering (AINE)
│
├─ AFS (Agentic File System)          ← 核心系统抽象层
│
├─ Agent / Skill / Chamber Runtime    ← 执行与不确定性处理
│
├─ Identity / DID / Capability        ← 权限、边界、信任
│
├─ Blocklet Runtime & Server          ← 可部署、可组合单元
│
├─ ArcSphere (AI Browser / Shell)     ← 人类+Agent界面
│
└─ Tooling / DocOps / UI / Payment    ← 外围系统

AFS + AINE是“母系统”。其他所有都衍生自它。

AFS (Agentic File System)

First Principles

第一性原理

AFS is NOT a feature, tool, or SDK. AFS IS the AI-Native system abstraction layer.

AFS不是功能、工具或SDK。 AFS是AI原生系统抽象层。

Four-Statement Ontology

四陈述本体论

Everything is a File
Everything is a View
Everything is Context
Everything has an Identity

Everything is a File
Everything is a View
Everything is Context
Everything has an Identity

What AFS Is

AFS是什么

Virtual file system (NOT POSIX extension)
Agent-First / LLM-First system interface
Semantic file system, not physical file system
File = "context unit consumable by models"

虚拟文件系统（不是POSIX扩展）
Agent优先/LLM优先的系统接口
语义文件系统，而非物理文件系统
文件=“模型可消费的上下文单元”

View is the Soul

View是灵魂

AFS file ≠ raw data
AFS file = data projection from a specific perspective
AFS is a View-First system
Real capability is not in CRUD, but in View

AFS文件≠原始数据
AFS文件=从特定视角投影的数据
AFS是View优先的系统
真正的能力不在CRUD，而在View

Path is Protocol

Path是协议

$afs:/did:xxx/intent/plan.md

path = context selector = query = view address = capability boundary

NOT bash path / docker volume path / hard-coded path

$afs:/did:xxx/intent/plan.md

path = 上下文选择器 = 查询 = View地址 = 能力边界

不是 bash路径 / docker卷路径 / 硬编码路径

AFS-UI Principle

AFS-UI原则

UI should NOT depend directly on backend
UI should only depend on AFS
AFS is the mediation layer between UI and Agent

UI不应直接依赖后端
UI应仅依赖AFS
AFS是UI与Agent之间的中介层

Critical Rule

关键规则

Agents should NOT operate systems directly. Agents should only operate AFS.

Agents不应直接操作系统。Agents应仅操作AFS。

AINE (AI Native Engineering)

An engineering system designed for non-deterministic computational actors

为非确定性计算参与者设计的工程系统

Core Phases

核心阶段

Intent
Context
Contract (natural language executable agreement)
Chamber (constrained execution space)
Build / Run / Ops
Feedback / Readback / Replay

Readback / Replay / Diff are crucial — this is engineering, not "conversation"

Intent
Context
Contract（自然语言可执行协议）
Chamber（受限执行空间）
Build / Run / Ops
Feedback / Readback / Replay

Readback / Replay / Diff至关重要——这是工程，不是“对话”

Two-Layer Separation

两层分离

Layer	Content	Approach
Platform	AFS, ArcSphere, Agent Fleet, LLM runtime	Build once, solidify
Application	Skills + Rules + Generative UI	User/AI compose

Determinism sinks from "application code" to "platform layer"

层级	内容	方法
平台层	AFS、ArcSphere、Agent Fleet、LLM运行时	构建一次，固化
应用层	Skills + Rules + 生成式UI	用户/AI组合

确定性从“应用代码”下沉到“平台层”

Blocklet / Chamber / Scaffold

Blocklet

An identity-bound, capability-scoped, deployable computational unit

What Blocklet has over Docker container: Semantic boundary + Permission boundary

绑定身份、限定能力范围、可部署的计算单元

Blocklet相比Docker容器的优势： 语义边界 + 权限边界

Chamber

Bounded execution unit with identity and capability

Chamber is designed for operations that "jump out of AFS boundary"
Future software is naturally self-limiting

Scenario	Needs explicit Chamber?
Skill running on Agent Fleet	No, architecture naturally isolates
Agent directly operating external systems	Yes, jumps out of AFS boundary

带有身份和能力的受限执行单元

Chamber专为“跳出AFS边界”的操作设计
未来软件天然具备自我限制能力

场景	是否需要显式Chamber？
Skill在Agent Fleet上运行	不需要，架构天然隔离
Agent直接操作外部系统	需要，跳出AFS边界

Scaffold

Pre-defined Chamber composition framework for specific domains

Scaffold should be designed for software that will be written in the future
Not for software written in the past

针对特定领域的预定义Chamber组合框架

Scaffold应为未来要编写的软件设计
不是为过去编写的软件设计

Relationship Mapping

关系映射

Blocklet System	AINE System	Essence
Blocklet	Chamber	Minimum execution unit with boundary, identity, capability
Blocklet Server	Scaffold	Pre-defined Chamber composition framework
DID + Permission	Capability	Who can operate what, where are boundaries

Blocklet系统	AINE系统	本质
Blocklet	Chamber	具备边界、身份、能力的最小执行单元
Blocklet Server	Scaffold	预定义的Chamber组合框架
DID + Permission	Capability	谁能操作什么，边界在哪里

DID / Capability

Core Distinction

核心区别

Identity (who I am)
Capability (what I can do)

Web3's biggest mistake: mixing identity and capability together

Identity（我是谁）
Capability（我能做什么）

Web3最大的错误：将身份和能力混在一起

DID + AFS Integration

DID + AFS集成

DID determines: which AFS view can be seen, which paths can be written
Capability determines: which skills can be called, which tools can be operated
All operations: must be traceable to DID

An agent without identity is uncontrollable.

DID决定：可以看到哪些AFS视图，可以写入哪些路径
Capability决定：可以调用哪些Skills，可以操作哪些工具
所有操作：必须可追溯到DID

没有身份的Agent是不可控的。

Product Positioning

产品定位

ArcSphere

Skill Browser + Skill Composer + AFS UI

Not: ❌ Chrome / ❌ Chat UI / ❌ Copilot

Skill浏览器 + Skill编辑器 + AFS UI

而非：❌ Chrome / ❌ 聊天UI / ❌ Copilot

Agent Fleet

Agent Fleet is NOT a standalone new product
Agent Fleet IS a new type of Blocklet

Blocklet Server (platform)
├── Traditional Blocklet (Web components)
└── Agent Fleet Blocklet (AI-native components) = new type

Agent Fleet 不是独立的新产品
Agent Fleet 是一种新型Blocklet

Blocklet Server (平台)
├── 传统Blocklet（Web组件）
└── Agent Fleet Blocklet（AI原生组件）= 新型

Key Technical Judgments

关键技术判断

Blockchain Position

区块链定位

Verifiability matters. Global consensus doesn't.

Keep: DID + VC + Immutable log Don't need: Bitcoin/Ethereum-style consensus, procedural smart contracts

可验证性很重要。全局共识不重要。

保留：DID + VC + 不可变日志不需要：比特币/以太坊式共识、过程化智能合约

Contract = Constraint, not Procedure

Contract = 约束，而非流程

Traditional Smart Contract	AI-Era Contract
Procedural (if-then-else)	Declarative (rules/constraints)
Executor: EVM	Executor: LLM + Chamber

传统智能合约	AI时代Contract
过程化（if-then-else）	声明式（规则/约束）
执行器：EVM	执行器：LLM + Chamber

Skills vs MCP

Skills succeeded because:

Natural language creation
Self-bootstrapping: Skills can produce Skills
Assumes executor is AI Agent, not human engineer

Skills成功的原因：

自然语言创建
自引导：Skills可以生成Skills
假设执行器是AI Agent，而非人类工程师

Isolation Evolution

隔离演进

Bare metal → VM → Docker → Functions → Declarative constraints

Applications become more "self-limiting", so lighter isolation is needed.

裸金属 → VM → Docker → Functions → 声明式约束

应用变得更加“自我限制”，因此需要更轻量的隔离。

Part C: Self-Review Checklist

第三部分：自我审查清单

Before You Submit Anything

提交任何内容之前

Direction Alignment

方向对齐

Time Horizon Check

时间视野检查

If your proposal...	Ask yourself...
Solves only immediate problem	Deeper structural issue being ignored?
Requires "figure it out later"	What's deferred? Is that acceptable?
Assumes current constraints permanent	What changes in 2-3 years?

如果你的提案...	问自己...
只解决眼前问题	是否忽略了更深层的结构问题？
需要“以后再解决”	推迟了什么？这可以接受吗？
假设当前约束是永久的	2-3年后会有什么变化？

Clarity Check

清晰度检查

Can you explain core idea in 2 sentences?
Can you list exactly what changes and what doesn't?
Can you describe boundaries - what's in scope, what's not?

你能用2句话解释核心想法吗？
你能准确列出哪些会变化，哪些不会吗？
你能描述边界——哪些在范围内，哪些不在吗？

Failure Path Check

失败路径检查

What are the known risks?
What would cause this to fail?
How will we know if it's failing?
What's the rollback plan?

If you can't describe how it fails, you don't understand it well enough.

已知风险有哪些？
什么会导致失败？
我们如何知道它正在失败？
回滚计划是什么？

如果你无法描述它如何失败，说明你还不够理解它。

Anti-Patterns (Instant Red Flags)

反模式（直接红牌）

Technical Anti-Patterns

技术反模式

Anti-Pattern	Why It's Wrong
UI depending directly on backend	Violates AFS-UI principle
Agent operating system directly	Should only operate AFS
Mixing identity and capability	Follow DID + Capability separation
Procedural contracts	Use declarative constraints
Hard-coded physical paths	Use semantic AFS paths
Building adapter for legacy code	Build for future software

反模式	错误原因
UI直接依赖后端	违反AFS-UI原则
Agent直接操作系统	应仅操作AFS
混合身份和能力	遵循DID + Capability分离原则
过程化Contract	使用声明式约束
硬编码物理路径	使用语义化AFS路径
为遗留代码构建适配器	为未来软件构建

Proposal Anti-Patterns

提案反模式

Anti-Pattern	What It Looks Like
Vague scope	"Improve X" without definition
Hidden complexity	Simple proposal, unstated major changes
Solution seeking problem	"Let's use [tech]" without problem statement
Wishful thinking	Assumes best-case throughout
No definition of done	No way to know when complete
Fake rigor	Diagrams, buzzwords, no anchor points
AI-generated套话	Methodology summary with no specific files, tasks, or risks. Could apply to any project.
No engineering responsibility	Describes "what should happen" but not "what I will do to this specific system"

反模式	表现形式
模糊范围	“改进X”但没有定义
隐藏复杂性	提案简单，但未说明重大变更
为找解决方案而找问题	“我们用[技术]吧”但没有问题陈述
一厢情愿	全程假设最佳情况
没有完成定义	无法知道何时完成
虚假严谨	有图表、流行术语，但没有锚点
AI生成套话	方法论总结，没有具体文件、任务或风险。适用于任何项目。
无工程责任	描述“应该发生什么”但不说明“我要对这个特定系统做什么”

Thinking Anti-Patterns

思维反模式

Anti-Pattern	Correct Approach
Solving new problems with old paradigms	Update the question, not just answer
Making horse carriages faster	Ask what infrastructure cars need
Treating AFS as a feature	AFS is a worldview, not a module

反模式	正确做法
用旧范式解决新问题	更新问题，而不仅仅是答案
让马车更快	思考汽车需要什么基础设施
将AFS视为功能	AFS是世界观，不是模块

Quick Reference Card

快速参考卡

Value Hierarchy

价值层级

1. Long-term Correctness
2. Structural Clarity
3. System Consistency
4. Engineering Replayability
5. Efficiency
6. Comfort

1. 长期正确性
2. 结构清晰性
3. 系统一致性
4. 工程可复现性
5. 效率
6. 舒适度

Engineering Requirements

工程要求

1. Replayable
2. Traceable
3. Inspectable
4. Fail-safe
5. Evolvable

1. 可复现
2. 可追溯
3. 可检查
4. 故障安全
5. 可演进

Core Equations

核心等式

AFS = AI-Native system abstraction layer
Skill = AFS transformation (not deterministic function)
Chamber = Bounded execution for operations outside AFS
Contract = Constraint, not Procedure
DID = Accountable actor identity
Capability = Minimal, composable, revocable authorization

AFS = AI原生系统抽象层
Skill = AFS转换（非确定性函数）
Chamber = AFS外操作的受限执行环境
Contract = 约束，而非流程
DID = 可问责的参与者身份
Capability = 最小化、可组合、可撤销的授权

Final Self-Test

最终自我测试

Before submitting, answer honestly:

Does this align with AFS-first architecture?
Is the layer (platform vs application) clear?
Are identity and capability properly separated?
Can I describe how this fails?
Am I solving for the future or patching the past?
Would this still make sense in 3 years?
Would I bet my own time on this working?
Does this document have concrete anchor points? (specific files, specific tasks, specific risks — not just methodology)
If I remove all the "correct-sounding" methodology descriptions, what's left? (If nothing → rewrite)

提交前，诚实地回答：

这是否与AFS优先架构对齐？
层级（平台vs应用）是否清晰？
身份和能力是否正确分离？
你能描述它如何失败吗？
你是在为未来解决问题还是在修补过去？
3年后这仍然有意义吗？
你愿意把自己的时间押在它能成功上吗？
这份文档有具体锚点吗？（具体文件、具体任务、具体风险——不只是方法论）
如果移除所有“听起来正确”的方法论描述，还剩下什么？（如果什么都没剩下→重写）

The Ultimate Question

终极问题

"If Robert reads this, will he ask 'what problem are you actually solving?' or 'why are we doing this the old way?'"

If yes, go back and fix it first.

Remember: This checklist helps structure thinking. It does not guarantee approval.

A proposal that passes all checks can still be wrong. A proposal that fails some checks might still be worth discussing.

The goal is alignment and rigor, not box-checking.

Inelegant things will inevitably be eliminated in the long run.

“如果Robert读了这个，他会问‘你实际解决的是什么问题？’还是‘我们为什么还用旧方式做这件事？’”

如果答案是肯定的，先回去修正。

记住：这个清单帮助梳理思路，不保证获得批准。

通过所有检查的提案仍然可能是错误的。 未通过某些检查的提案可能仍值得讨论。

目标是对齐和严谨，而非打勾。

不优雅的事物终将在长期被淘汰。