Why I lead with a runnable demo 为什么我先给你一个能跑的 demo
When you're hiring someone you've never worked with, every proposal sounds confident and every one is a promise. A promise puts the risk on you: you pay, then you find out. So instead of telling you I can do the thing, I'd rather hand you a small version of it that runs — and let the running code carry the argument. 当你要雇一个从没合作过的人,每份提案都很自信,而每一份都是一个承诺。承诺把风险压在你身上:你先付钱,再发现结果。所以与其告诉你我能做这件事,我更愿意给你一个能跑的小版本——让运行的代码来替我说话。
A claim is cheap; a running thing isn't嘴上说很便宜;能跑的东西不便宜
Anyone can write "expert in X." The words cost nothing, and by the time you can tell whether they were true, you've already spent your budget and your weeks. A working demo collapses that gap: you see the behaviour before you commit, and if it doesn't hold up, you've lost a click instead of a contract. That asymmetry is the whole point — it moves the risk off you and onto me, where it belongs. 谁都能写"精通 X"。这话不花一分钱,而等你能判断它真假时,你的预算和几周时间已经花出去了。一个能跑的 demo 把这道缝合上:你在投入之前就看到行为,如果它撑不住,你损失的是一次点击,而不是一份合同。这种不对称正是重点——它把风险从你身上挪到我身上,那才是它该在的地方。
Mock-first: prove the logic before spending trustMock 先行:在消耗信任之前证明逻辑
Most integrations ask you to spend something just to find out if they work — an API key, a paid credit, write access to a live system. I build the demo the other way round: on stand-in data, so the whole pipeline runs and can be watched without a single real credential. You verify the behaviour on evidence first; the real keys come after, when there's nothing left to doubt. Where a value can't be trusted, the demo flags it for review rather than guessing — because "confidently wrong" is worse than "honestly unsure." 多数集成要求你先押上点什么,才知道它通不通——一把 API key、一笔付费额度、对线上系统的写权限。我把 demo 反过来做:跑在替身数据上,让整条流水线运行、被看见,却不需要一个真凭据。你先凭证据验证行为;真 key 之后再上,那时已无可怀疑。遇到一个不可信的值,demo 会把它标出来交人工复核,而不是猜——因为"自信地错"比"诚实地不确定"更糟。
It gives your reviewer something to read它给你的评审一份能读的东西
If you have a technical person who vets the work, a demo is the most useful thing I can put in front of them: real code, in your stack, that they can read and run — not a résumé to take on faith. It answers the question a track record can't fully settle: not "has this person done something," but "do I trust how they build?" 如果你有懂技术的人来把关,demo 是我能摆在他面前最有用的东西:你技术栈里的真实代码,他能读、能跑——而不是一份要靠信任的简历。它回答一个履历回答不了的问题:不是"这人做过没有",而是"我信不信他构建的方式"。
The honest limit诚实的边界
A demo runs on stand-in data, not yours, so I say that plainly and never dress a sample up as a shipped result — the point it proves is the method, and the method is what ports onto your problem. That honesty is deliberate: if I'll tell you exactly what a demo does and doesn't prove before you've paid me anything, that's the same care you'll get when something is genuinely uncertain mid-project. Proof before promises isn't a slogan; it's just the cheapest way for both of us to find out early whether we should work together. demo 跑在替身数据上,不是你的,所以我把这点直说,绝不把一个样例打扮成已交付的成果——它证明的是方法,而方法才是能迁到你问题上的东西。这种诚实是刻意的:如果在你还没付我一分钱时,我就会明确告诉你一个 demo 证明了什么、没证明什么,那么项目中途真有不确定时,你会得到同样的审慎。先见为实不是口号;它只是让我们双方尽早搞清"该不该合作"的最省成本的方式。
← All notes← 全部笔记