文章 · Hugox

缓慢工作的形状：在持续变化的世界里保留注意力

Wed, 22 Jul 2026 17:10:00 +0800

我们很容易把速度理解成一种单一能力：更快地回复消息，更快地完成任务，更快地把想法变成可见的结果。然而，真正决定一项工作能否长期存在的，往往不是最初完成得有多快，而是在变化不断发生之后，它是否仍然清楚、可靠，并且允许后来的人继续前进。

缓慢工作并不意味着拖延，也不意味着拒绝效率。它是一种对注意力的主动安排：在需要判断的地方停下来，在可以复用的地方建立结构，在结果尚不确定的时候保留修正的空间。它关心的不只是今天完成了什么，也关心明天是否还能理解今天的决定。

速度并不是时间的反义词

一件事情看起来完成了，不代表它真正结束了。仓促写下的代码可能在上线后变成长期维护成本；没有说明背景的文档可能在半年后制造新的误解；为了赶进度而跳过的验证，往往只是在把检查工作推迟到更昂贵的阶段。

因此，衡量速度不能只看交付时刻，还要看一个结果从产生到稳定所经历的完整周期。如果一项工作需要反复返工、解释和补救，那么最初节省的时间通常只是暂时借来的。

真正的快，不是比别人更早离开起点，而是更少走进那些必须原路返回的岔路。

这并不要求每个决定都经过漫长讨论。恰恰相反，好的节奏来自对决定类型的区分：容易撤销的决定可以迅速行动，难以撤销的决定则需要更多证据。

决定类型	撤销成本	合适的做法
修改局部文案	很低	直接尝试并观察
调整页面布局	较低	用真实内容验证
改变数据结构	较高	设计迁移与回滚
发布公共接口	很高	明确约束并记录原因

当注意力与风险匹配时，团队既不会在小事上无限争论，也不会在重要边界上草率行事。

注意力是一种有限资源

一天中的时间看似均匀，注意力却不是。连续两个小时的完整思考，与被消息切成十二段的两个小时，并不具有相同价值。很多复杂问题需要我们先在头脑中建立一个模型，然后才能判断某个局部变化会带来什么影响。每一次打断，都可能让这个模型部分坍塌。

这也是为什么“随时在线”并不等于高效协作。即时沟通适合处理真正紧急、需要快速同步的信息，但如果所有问题都进入同一条即时通道，重要工作就会被迫与每一个提示音竞争。

给不同工作分配不同容器

一种简单的做法，是根据工作所需的认知状态来安排环境：

深度工作需要连续时间、明确目标和尽量少的入口。
协作讨论需要共享上下文，以及可以被追踪的结论。
日常处理适合集中完成，避免它们不断侵入主要任务。
探索性工作需要允许失败，不应过早承诺确定结果。

容器不是严格的时间表，而是一种边界。它告诉我们当前正在做什么，也提醒其他事情暂时不进入这里。

上午：完成需要连续推理的核心工作
中午：处理邮件、评论和短任务
下午：协作、评审与验证
结束前：记录进展和下一步入口

这样的安排看起来并不激进，却能减少每天重新寻找状态的次数。

清晰比聪明更容易延续

我们常常欣赏精巧的解决方案，因为它们展示了作者的能力。但一套需要反复解释才能使用的方案，很难在时间中保持稳定。真正耐久的系统通常没有那么戏剧化：命名与行为一致，边界可以被识别，失败发生时能够找到原因。

清晰不是把所有复杂性抹平。有些领域本身就复杂，例如支付状态、权限继承、分布式一致性。好的设计会让这些必要的复杂性显露出来，同时尽量减少与问题无关的意外复杂性。

下面是一段普通的配置。它没有追求技巧，但每项设置都表达了明确意图：

[pagination]
pagerSize = 8

[params]
description = "记录技术、阅读与日常观察。"
dateFormat = "2006 年 1 月 2 日"

[taxonomies]
tag = "tags"

读者不需要猜测分页大小从哪里来，也不需要寻找隐藏在模板中的日期规则。透明的配置减少了理解系统时必须记住的例外。

注释应当解释原因

如果一段注释只是把代码换一种语言重复，它很快就会变成噪音。更有价值的注释会保存无法从当前实现中直接推导出来的背景，例如为什么不能采用看似更简单的方案，或者某项约束来自哪个外部系统。

// 使用 UTC 保存发布时间，避免部署地区变化后文章顺序发生漂移。
publishedAt := time.Now().UTC()

这里重要的不是“调用了 UTC”，代码已经表达了这一点。重要的是顺序稳定这一约束，它会帮助后来的人避免无意中恢复旧问题。

维护不是创造的对立面

“新功能”容易被看见，“维护”则经常被描述成不得不做的后续工作。但对使用者来说，两者并没有清晰边界。页面是否快速、升级是否安全、数据能否保留、错误是否能够恢复，这些都构成产品本身。

维护工作的价值常常体现在没有发生的事情上：

一次迁移没有造成停机；
一个错误在影响用户前被监控发现；
一段旧代码被删除后，后续修改不再需要考虑双重路径；
构建时间缩短，让修复能够更快抵达生产环境；
文档保存了关键决定，使团队不必重复同一场讨论。

因为这些结果缺少戏剧性，我们需要用更具体的语言描述它们。与其说“重构存储层”，不如说“让数据库迁移可以在不中断写入的情况下完成”。后者指出了用户和系统真正得到的能力。

写作是整理判断的工具

写作不只是传播已经形成的观点。很多时候，观点是在写作过程中才真正形成的。一个模糊想法留在脑海里时，可以依靠直觉连接许多未说明的部分；一旦写到纸面上，缺失的前提、跳跃的推论和含混的词语就会暴露出来。

因此，写作也是一种低成本的设计验证。它迫使我们回答：

我试图解决的究竟是什么问题？
哪些事实是已知的，哪些只是推测？
这个方案依赖哪些条件？
如果结果不符合预期，如何撤销或修正？
谁会受到这个决定的影响？

这些问题适用于文章，也适用于软件、流程和产品决策。

文档应该保存决定，而不是复制现状

现状可以从代码、配置和运行结果中读取，决定背后的理由却很容易消失。一份耐久的文档不必很长，但应当让未来的读者知道某个边界为何存在。

决定：RSS 输出完整文章正文。

原因：读者应当能够在订阅器中完成阅读，不必跳转网页。

影响：订阅文件体积会增加，图片和代码块需要保持有效的 HTML 表达。

当约束发生变化时，这段记录也提供了重新评估的起点，而不是把旧选择变成无法质疑的传统。

删除是一种重要的设计能力

增加功能会扩大系统能够做的事情，删除则减少系统必须同时解释的状态。每移除一条无用分支，测试、部署、文档和维护者就少考虑一种可能性。

然而，安全删除比简单增加更需要证据。一个看似无人使用的入口，可能仍被外部脚本调用；一项已经关闭的功能，可能仍留下持久化数据；一个旧配置项，可能被用户当作稳定契约。

删除前可以做一份简短检查：

搜索仓库中的直接和间接引用；
检查生产环境是否仍有真实使用；
确认旧数据是否需要迁移；
告知外部使用者变化范围；
同时删除过期测试和文档；
部署后观察关键指标。

删除不是清理冲动，而是对系统边界的重新确认。

性能需要明确预算

如果没有具体标准，“足够快”会变成不断变化的主观判断。性能预算的作用，是把偏好变成可验证的约束。它不一定适用于所有项目，但应该与产品场景相匹配。

对于一个以阅读为主的静态站点，可以采用这样的预算：

指标	建议预算
初始 HTML	压缩后小于 30 KB
关键 CSS	压缩后小于 20 KB
JavaScript	非必要时保持 0 KB
首屏最大图片	小于 250 KB
500 篇文章构建时间	小于 2 秒

预算并不意味着超过一字节就失败。它提供的是讨论基础：如果一个新能力需要额外成本，我们可以判断它是否值得，而不是在上线后才偶然发现代价。

留出可以回来的入口

长时间工作最困难的部分，往往不是继续，而是重新开始。昨天结束时没有留下线索，今天就需要再次阅读大量上下文，才能找回当时正在形成的判断。

一个好的结束动作非常简单：记录已经确认的事实、当前未解决的问题，以及下一步最小可执行动作。例如：

## 当前状态

- 已确认数据读取没有错误
- 问题只出现在移动端布局
- 可能与 42rem 断点有关

## 下一步

在 375px 宽度下检查文章列表的日期布局。

这份记录不是正式报告，而是留给未来自己的路标。它减少了重新进入工作所需的启动成本，也让协作者能够接续而不是从头猜测。

长期主义是一系列短期动作

长期主义听起来像一种宏大立场，但它真正存在于日常细节里：是否为重要决定写下一句原因，是否在功能稳定后删除临时开关，是否愿意在上线前完成最后一次验证，是否给后来的人留下可以理解的命名。

这些动作单独看都很小。它们不会立刻制造巨大的差异，却会持续改变系统未来的可修改性。一年之后，项目是变得越来越沉重，还是仍然允许人们从容地做出改变，往往取决于这些不显眼的选择。

我们不需要预测所有未来，也不可能一次设计出永远正确的结构。更实际的目标，是让错误能够被发现，让决定能够被解释，让变化能够被撤销，让注意力能够回到真正重要的问题上。

缓慢工作的价值最终不在于慢，而在于它保留了判断。它让速度不必以混乱为代价，让创造与维护不再彼此对立，也让我们完成的东西在离开当下之后，仍然拥有继续生长的可能。

The Quiet Work of Building Software That Lasts

Wed, 22 Jul 2026 16:40:00 +0800

Most software does not fail because its authors lacked intelligence. It fails because the system gradually became harder to understand than the organization could afford. A shortcut became a convention, a temporary exception became a permanent interface, and a useful abstraction accumulated responsibilities until nobody could explain where its boundaries ended.

The difficult part of building software is therefore not invention alone. It is preserving clarity while requirements, teams, and operating conditions continue to change. This work is quiet. It rarely produces dramatic screenshots, but it determines whether a project remains useful after the excitement of its first release has passed.

Clarity is an operational feature

We often discuss clarity as if it were a preference for elegant code. In practice, clarity affects response time, reliability, and cost. When an incident occurs, the team must form an accurate model of the system before it can act safely. Every ambiguous name, hidden dependency, and surprising side effect increases the time required to build that model.

A clear system does not need to be simple in every dimension. Some domains are genuinely complicated. The goal is to make essential complexity visible and accidental complexity removable. A payment system may need careful state transitions, but it should not also require its operators to remember that a function named refresh silently writes to three databases.

Good maintenance begins when the code says what it does, the documentation says why it exists, and the production system behaves like both.

This standard changes how we review code. Instead of asking only whether a patch works, we can ask a more durable set of questions:

Can a reader identify the inputs, outputs, and side effects?
Does the change introduce a new concept that the existing model cannot express?
Is failure visible at the boundary where it can be handled?
Will the next person know which behavior is intentional?

These questions do not eliminate defects. They reduce the amount of interpretation required when defects inevitably appear.

Small changes are easier to trust

Large rewrites are attractive because they promise a clean boundary between the frustrating present and an orderly future. That boundary rarely exists. The old system contains years of discovered behavior, including behavior that was never documented but still matters to someone. A rewrite starts with less visible complexity, not necessarily less actual complexity.

Small changes provide a different advantage: they preserve feedback. A narrow patch can be reviewed against a narrow claim. It can be deployed independently, observed in production, and reverted without disturbing unrelated work. If the result is wrong, the lesson arrives before the team has built five more decisions on top of it.

Consider a function that has begun to mix validation, persistence, and notification:

func Publish(ctx context.Context, post Post) error {
	if err := post.Validate(); err != nil {
		return fmt.Errorf("validate post: %w", err)
	}

	if err := repository.Save(ctx, post); err != nil {
		return fmt.Errorf("save post: %w", err)
	}

	return notifier.Send(ctx, post)
}

It may eventually need a queue, retries, idempotency, and an audit log. Adding all of those at once would make the transition difficult to reason about. A smaller first step might only make the notification boundary explicit and record failures. That change creates evidence for the next decision instead of predicting every future requirement.

The value of reversible decisions

Not every decision deserves the same ceremony. A local variable name is easy to change. A public URL, persisted schema, or external protocol is expensive to change. Good teams spend their attention according to reversibility.

Decision	Cost to reverse	Useful response
Internal helper name	Low	Choose clearly and continue
Page layout detail	Low to medium	Test with real content
Database representation	High	Model migration and rollback
Public API contract	Very high	Document invariants and versioning

This approach avoids two common failures. The first is endless debate over details that can be corrected in minutes. The second is casual treatment of interfaces that will constrain the project for years.

Maintenance is product development

Maintenance is often described as the work that happens after product development. That distinction is misleading. Users experience the complete behavior of a system: its speed, consistency, recovery, compatibility, and ability to preserve their data. Improving those properties is product work, even when the release notes contain no new feature names.

A maintenance task has product value when it removes friction or reduces risk. Examples include:

replacing an unreliable background job with an observable queue;
deleting a configuration option that no longer changes behavior;
improving an error message so a user can recover without support;
reducing build time so fixes reach production sooner;
documenting a data-retention rule before it becomes an incident.

The challenge is that preventive work competes poorly in planning meetings. A visible feature can be demonstrated immediately, while the value of a safer migration appears as an incident that never happens. Teams need a vocabulary for this value. Instead of saying “clean up the database layer,” describe the concrete operational result: “allow schema changes without stopping writes.”

Documentation should preserve decisions

Documentation decays when it merely repeats code. A list of function parameters can often be generated, and generated facts should be generated. Human-written documentation is most valuable when it records context that cannot be reconstructed from the current implementation.

Useful documentation answers questions such as:

What problem made this component necessary?
Which alternatives were considered and rejected?
What must remain true during a migration?
Which failure modes are acceptable?
Who depends on this behavior outside the repository?

An architectural decision can be short and still be durable:

Decision: store publication timestamps in UTC.

Reason: authors and readers may be in different time zones, while ordering
must remain stable across deployments.

Consequence: convert to local time only at presentation boundaries.

The important detail is not the format. It is the preservation of intent. Without the reason, a future developer may “simplify” the code by storing local timestamps and unknowingly restore the original bug.

Observability begins with questions

Collecting more telemetry does not automatically make a system observable. A dashboard with hundreds of charts can still leave operators unable to answer a basic question: are users completing the action they came to perform?

Start with questions, then collect the evidence needed to answer them:

Is the service accepting work?
Is accepted work completing successfully?
Where is time being spent?
Which users or inputs are affected by failure?
Did the latest deployment change any of these answers?

This sequence usually produces a small set of service-level metrics, structured events, and traces around important boundaries. It also reveals where logging is merely decorative. A message like operation failed consumes storage but carries no diagnostic value unless it identifies the operation, relevant state, and underlying cause.

Design errors for recovery

Errors are part of an interface. Internally, they should preserve enough context for diagnosis. Externally, they should tell the caller what can happen next. These needs are related but not identical.

For example, a storage timeout may need a request identifier and dependency name in the logs. The user may only need to know that their draft remains safe and that retrying is appropriate. Exposing internal detail to the user is not transparency; it is transferring diagnostic work to someone without the tools to perform it.

Performance work needs a budget

Performance improvements are easiest to evaluate when the project defines an explicit budget. Without one, “fast” becomes a moving adjective and optimization becomes a collection of local opinions.

A small content site might choose budgets like these:

Measure	Budget
Initial HTML	Under 30 KB compressed
Critical CSS	Under 20 KB compressed
JavaScript	0 KB unless interaction requires it
Largest image	Under 250 KB
Server build	Under 2 seconds for 500 posts

Budgets are not universal laws. They are constraints chosen for a particular product. Their value is that they turn a vague preference into a testable decision. When a feature exceeds the budget, the team can discuss whether its value justifies the cost instead of discovering the cost accidentally after launch.

Deletion is a design skill

Removing code is one of the highest-leverage forms of maintenance. Every deleted branch eliminates a state that tests, operators, and future developers no longer need to consider. Yet deletion requires more care than addition because old behavior may have invisible consumers.

Safe deletion starts with evidence:

search for internal references;
inspect production usage where possible;
identify persisted data using the old representation;
announce changes to external consumers;
remove the behavior and its tests together;
observe the system after deployment.

Feature flags deserve particular attention. A temporary flag creates at least two versions of the product. Once a rollout is complete, leaving the flag in place preserves both versions in the code even if only one is used. The cleanup task is part of the feature, not optional work for a quieter quarter.

A sustainable pace is technical infrastructure

Software quality depends on attention, and attention is finite. Teams working under constant urgency make narrower observations, rely more heavily on familiar solutions, and postpone verification. Over time, the system reflects those conditions through duplicated logic, incomplete migrations, and alerts that everyone learns to ignore.

A sustainable pace does not mean avoiding deadlines or difficult periods. It means allowing recovery and protecting enough uninterrupted time for careful work. Review quality, incident response, and architectural judgment all decline when every task arrives as an emergency.

This is not separate from engineering practice. It is part of the environment in which engineering decisions are made. A team cannot compensate indefinitely for an unstable process by asking individuals to be more disciplined.

What lasting software feels like

Software that lasts is not frozen. It changes without losing its shape. New contributors can locate important behavior. Operators can understand failures before guessing at remedies. Users can trust that an upgrade will preserve their work. Old features can be removed without archaeology becoming the dominant engineering activity.

None of this requires perfect foresight. It requires habits that keep correction affordable:

Prefer explicit boundaries over clever shortcuts.
Make the smallest change that can produce useful evidence.
Record why expensive decisions were made.
Treat maintenance outcomes as user-facing value.
Delete obsolete paths once their replacement is proven.
Protect the attention needed to verify important work.

The result may look modest from the outside. That is often the point. Reliable systems make difficult work appear ordinary. Their strongest qualities emerge not in a launch demonstration, but months later, when a new requirement arrives and the team can meet it without first untangling everything that came before.

从一张白纸开始写作

Wed, 22 Jul 2026 10:30:00 +0800

极简不是把所有东西删掉，而是让留下来的部分各自承担明确的工作。这个主题没有 JavaScript，页面只由 HTML、CSS 和一套中文阅读字体构成。

阅读是一种节奏

中文正文需要比拉丁文字更舒展的行距。标题负责停顿，段落负责向前，元信息则安静地退到视线之外。主题将正文宽度控制在适合持续阅读的范围，同时让手机屏幕保持自然的边距。

好的排版不会抢走文字的声音，它只是让声音抵达得更清楚。

文章可以使用常见的 Markdown 元素：

无序列表用来并列记录
有序列表用来表达步骤
行内代码 用来标明命令或变量
链接可以指向 Hugo 官方文档

构建时完成代码高亮

Hugo 内置 Chroma。高亮结果直接写入静态 HTML，不需要浏览器下载脚本。

package main

import "fmt"

func main() {
	fmt.Println("纸短，路长。")
}

表格与长内容

较窄的屏幕会让表格自然横向滚动，不会撑破正文布局。

原则	实现方式	运行时依赖
内容优先	语义化模板与克制排版	无
自动深色	`prefers-color-scheme`	无
代码高亮	Hugo Chroma	无

图片

这篇文章可以在填入真实内容后删除。创建下一篇文章时，运行：

hugo new content posts/my-note.md