One email per milestone 每个里程碑,一封邮件
3 Aug 20262026年8月3日
Say you want "an HMI" for your machine — and that's the whole spec. No forty-page document, no ticket board. That's not an edge case; it's what real work looks like when you hire someone to own the problem rather than execute a document. Here's the mechanism I use to keep that kind of work from spiralling — and what it looks like from your side of the table. 假设你想给你的机器配一个"HMI"——而这就是全部需求。没有四十页的规格书,没有工单看板。这不是极端个例;当你雇一个人是为了"把问题整个交给他",而不是"照文档执行"时,真实的活儿就长这样。下面是我用来防止这类工作失控的机制——以及坐在你那一侧看,它是什么样子。
The one email那一封邮件
I split the work into milestones so it can't spiral. At the start of each milestone I send one email — one — containing: 我把工作拆成里程碑,让它没有失控的空间。每个里程碑开始时,我发一封邮件——就一封——里面写清:
- Everything I might need this phase.这个阶段我可能需要的所有东西。
- The risks I already see.我已经看到的风险。
- What I will build.我将构建什么。
- How it's accepted.怎么算验收通过。
- The hard criteria for moving to the next stage.进入下一阶段的硬性标准。
Then I tell you: none of this blocks me — but here's what I need from you, and by when. 然后我告诉你:这些都不会卡住我——但这是我需要你提供的,和需要的时间点。
What you experience你经历的是什么
One big risk becomes small stages. I drive the work, not the other way around. You watch the nodes complete and the problems surface and get closed, one by one. Nothing to chase, nothing to manage — just a drumbeat of stages completing on schedule. 一个大风险,变成一段段小阶段。是我在驱动工作,而不是工作驱动我。你看着节点一个个完成,问题一个个浮出、又一个个关闭。不用追问,不用管理——只有一个个阶段按节奏完成的鼓点。
Why I work like this: attention economics为什么这样干:注意力经济学
I'm a full-time independent. My scarcest resource is attention. Whoever saves my attention, I pay real money for — and I repay clients the same way: lowest communication overhead, highest information density. That's why async plus email is my main mode. Proactivity on top of agreed outcomes is the mode I enjoy — and it's genuinely fast. 我是全职独立工程师,最稀缺的资源是注意力。谁替我省注意力,我愿意为谁付真金白银——而我也用同样的方式回馈客户:最低的沟通开销,最高的信息密度。这就是为什么"异步 + 邮件"是我的主模式。在约定结果之上主动推进,是我享受的工作方式——而且它真的快。
A spec is one way to de-risk a project. A drumbeat of kept promises is another — and it works when no spec exists yet. 规格书是给项目降险的一种方式。一串兑现了的承诺是另一种——而且在规格书还不存在时,它就已经生效了。
This is how I actually run contracts — written from practice, not theory. No specific client, machine or project is described. 这就是我真实运转合同的方式——写自实践,不是理论。不描述任何具体的客户、机器或项目。
Companion note, same vein: Why I lead with a runnable demo. 同系笔记:为什么我先给你一个能跑的 demo。
If a machine you build needs an interface, a device connection, or data that has to land somewhere else — tell me what it's costing you now. You'll get an honest read on whether it's solvable, and usually something running to look at. Start here →如果你造的机器需要一套界面、一个设备连接,或者数据必须落到别处去——告诉我它现在正让你付出什么代价。你会得到一个诚实的判断:能不能解;通常还会收到一个能跑的东西。从这里开始 →