Let me start with a few facts about myself. I am hairy, dark-skinned, 167 centimeters tall, and losing my hair. I chose none of these. They arrived without asking my opinion, moved in, and showed no intention of leaving. Probability explains this well enough: I was born in Southwest China to short parents, and among a crowd of short relatives I came out on the shorter side. Genetics is real, and it is not polite about it.

When I wear shorts in summer, my legs look like a forest pending inspection. When I stand against a white wall in a photo, I always come out darker than I imagined, as if the camera holds a private opinion about me. As for my hair: hair on someone else's head is called a hairstyle. Hair in my sink is called data. I say this not entirely out of self-mockery; there is some statistical literacy in it too.

All of these things once made me feel inferior, and I tried to fix every one of them. The process went roughly like this: search for solutions, order the tools, and finally discover that the problem was never under my jurisdiction. This is how people with an engineering background handle things. I admit it is not elegant, but I cannot think of a more elegant way.

People want to edit their factory settings

When I was young, I believed that with enough effort, a person could modify himself into a more acceptable version. Looking back, this belief was a bit like thinking that if you write enough code, the hardware will improve on its own.

So I researched hair removal, skin whitening, height growth, and hair loss treatment. My attitude toward my body resembled my attitude toward a malfunctioning computer: wherever something looked wrong, I wanted to open it up. Unfortunately, a body is not a computer. It cannot be reinstalled, and it cannot be restored to factory settings. Worse still, after careful analysis, the so-called factory settings turn out to be exactly where the problem is.

I did write some shabby code in my youth. As far as I know, when software breaks you can debug it; when hardware breaks you can only accept your fate. Height, skin color, and hair follicles all belong to hardware, the kind that does not accept returns.

None of these traits arrived democratically. There was no vote, no hearing; they simply took office. For a long time I refused to accept this: why can't a person choose his own appearance? Later I figured it out. I cannot even decide what time I wake up in the morning. Wanting to negotiate with follicles and bones on top of that is clearly overestimating myself.

Insecurity is a long interrogation

The frightening thing about insecurity is not that it makes you feel inadequate. It is that it keeps you ready to confess, at any moment, exactly why you are inadequate.

Other people are not looking at you, but you have already looked on their behalf. Other people are not laughing, but you have already laughed on their behalf. The elevator mirror lights up, and the interrogation begins: are the leg hairs too conspicuous, is the face too dark, am I a head shorter than the crowd, has the hairline retreated again. Anyone subjected to daily hearings like this would crack, let alone an ordinary, unusually hairy man.

The meanest part of this interrogation is that it never reaches a final verdict. I later realized that body anxiety is a petty creditor: the moment you pay off one debt, it issues a new invoice under a different name. Today it dislikes your skin; tomorrow your height. Today you have too much hair; tomorrow too little. It has no interest in solving any problem. It only needs you to stay in debt.

A person who constantly feels he owes the world a better body cannot get on with his life properly. I have known many such people, including my former self.

Trying to change taught me the boundary

Let me state clearly: I am not against change. What can be changed may of course be changed. A cleaner haircut, some exercise, sunscreen, scientific methods against hair loss—there is nothing wrong with any of these. A large part of civilization exists precisely so that people do not have to leave everything to fate.

The problem is that some changes solve problems, while others are taxes paid to shame. The two look alike but differ entirely in nature, and you can only tell them apart by trying.

I tried them all. In the end I had to admit: some things can be optimized a little, but the underlying logic cannot be rewritten. My height will not become 180 cm no matter how sincerely I search. My skin will not exchange itself for a new shade because I resent it. My hair will not report back for duty in formation because I reason with it earnestly in the shower. I reached this conclusion by induction. The sample size is sufficient; the conclusion is reliable.

Accepting this fact brought me no joy at all. Real acceptance is never graceful. It does not arrive with a sunset and a soundtrack. It is more like a man who has exhausted himself, sits down on the ground, and says: fine, this will do for now.

Acceptance does not mean liking everything

For a while, I misunderstood what it meant to make peace with myself. I thought it meant loving every hair, every inch of skin, every centimeter of height. Later I found this demand too high, and too false. There is no need to package every flaw as a gift. A gift at least comes with a ribbon. Hair loss does not.

Russell said that diversity is essential to happiness. I believe this. But believing it is one thing; having it apply to yourself is another. Knowing that diversity is good, and cheerfully accepting that you happen to sit on the "diverse" end of it, are separated by quite a few years.

Acceptance is not suddenly deciding that you are perfect. It is admitting that you are not, while refusing to spend the main energy of your life prosecuting that fact. I may dislike my body hair without hating summer. I may dislike my skin without avoiding cameras. I may admit that 167 is not tall without shrinking automatically next to taller people. I may take my hair loss seriously without entering every fallen strand into my personal history of fate.

This is not a victory. It is a ceasefire. A ceasefire is already good enough. A person has too much to do in one lifetime to fight a daily civil war against his own skin, bones, and follicles.

A person is not a medical form

The body matters, of course. No one can pretend not to have one, because hunger growls, fatigue hurts, and the hair that falls in the shower reminds you of reality in very concrete terms.

But a person cannot be just a medical form either.

If you break me down into indicators—hairy, dark, 167, prone to hair loss—I do look like an unimpressive product specification. But that is not how a person is meant to be used. A person has his own way of speaking, his habits of doing things, the things he loves, the sharp remarks he manages to swallow, and the sincere words he finally says. None of these can be measured with a ruler, so none of them appear on a medical form. What the form leaves out is not necessarily unimportant. As far as I know, the most important things are generally not on it.

These traits of mine once made me feel inferior to others. They are still here, but their jurisdiction has shrunk. They can still affect my photos, my clothes, my hairstyle, and my mood, but they no longer decide whether I deserve to live well.

The peace I can manage is roughly this: I do not sanctify what I cannot change, and I no longer humiliate it either. I am still hairy, still dark, still 167, still worried about my hair. But I no longer intend to put myself in the defendant's chair.

It is hard enough for a person to arrive in this world at all. If he must first pass an appearance review of his own making before being permitted to live at ease, that would be unreasonable. I did not figure this out early. Fortunately, I did not figure it out too late either.

先说几个关于我自己的事实。我体毛旺盛，皮肤偏黑，身高一六七，头发还在减少。这四条都不是我选的：它们来的时候没有征求我的意见，住下来以后也不打算搬走。这件事可以从概率上解释——我生在西南，父母不高，我在一众不高的亲戚里还偏矮。可见遗传这种东西确实存在，而且存在得不太客气。

夏天穿短裤，我的腿看上去像一片待验收的森林。站在白墙前拍照，照片里的我总比想象中黑一点，好像相机对我有私人意见。至于头发，长在别人头上叫发型，掉在我水池里叫数据。我这么说不完全是自嘲，里面多少有点统计学素养。

以上这些事，我都自卑过，也都试图修改过。修改的过程大致如下：先搜索解决方案，再下单工具，最后发现这个问题不归我管。工科出身的人处理事情一般是这个思路。我承认它不太体面，但我也想不出更体面的。

人总想修改出厂设置

年轻的时候我相信，一个人只要肯下功夫，就能把自己改成一个比较像样的版本。现在回头看，这种想法有点像相信代码写得够多，硬件就会自己变好。

于是我研究过除毛，研究过美白，研究过增高，也认真研究过脱发。我对身体的态度很像对待一台出了毛病的电脑：哪里不对，就想拆开看看。可惜身体不是电脑，不能重装系统，也不能恢复出厂设置。更要命的是，经过仔细分析，所谓出厂设置恰恰是问题本身。

我年轻时也写过几行不像样的代码。据我所知，软件出了问题可以调试，硬件出了问题只能认命。身高、肤色、毛囊都属于硬件，而且是不支持退换的那种。

这些东西来得都很不民主：没有投票，没有听证，直接就位了。我一度对此不服气——人为什么不能选择自己的长相？后来想通了：我连每天早上几点睡醒都决定不了，还想去决定毛囊和骨骼，这显然是不自量力。

自卑是一种长期审讯

自卑这个东西，可怕之处不在于让你觉得自己差，而在于让你随时准备交代自己为什么差。

别人没有看你，你已经替别人看完了；别人没有笑你，你已经替别人笑完了。电梯里的镜子一亮，审讯就开始：腿毛是不是太扎眼，脸色是不是太深，站在人群里是不是矮了一截，发际线是不是又后退了。这么天天过堂，神仙也扛不住，何况我不是神仙，只是个毛发旺盛的普通人。

这种审讯最缺德的地方是没有终审。我后来发现，身体焦虑是个很小气的债主：你刚还完一笔，它马上换个名目再来。今天嫌你黑，明天嫌你矮；今天嫌你毛多，明天嫌你头发少。它根本不想解决问题，它只是需要你一直欠着。

一个人要是总觉得自己欠了世界一副好皮囊，日子就没法正经过了。这样的人我见过不少，包括从前的我。

修改过，才知道边界在哪里

需要声明，我并不反对改变。能改的地方，当然可以改。剪个清爽的发型，练练身体，注意防晒，用科学的方法对付脱发，这些都无可厚非。文明的很大一部分意义，就是让人不必事事听天由命。

问题在于，有些改变是解决问题，有些改变是向羞耻心纳税。这两件事外表相似，性质完全不同，需要试过才能分清。

我都试过。试到最后不得不承认：有些东西能优化一点，但底层逻辑改不了。身高不会因为我搜索得虔诚就变成一八零，肤色不会因为我恨它就自动换货，头发也不会因为我在洗澡时晓之以理就集体返岗。这个结论是我用归纳法得出的，样本充足，结论可靠。

接受这个事实的时候，我一点也不高兴。真正的接受从来都不太体面，不像电影里演的，配着夕阳和音乐。它更像一个人折腾累了，往地上一坐，说：行吧，先这样。

和解不是喜欢一切

有一阵子，我把“和自己和解”理解错了。我以为和解就是要热爱自己的每一根毛、每一寸皮肤、每一个身高刻度。后来发现这个要求太高，也太假。一个人没必要把所有缺点都包装成礼物——礼物好歹还扎个蝴蝶结，脱发不扎。

罗素说，参差多态乃是幸福的本源。这话我信。但信是一回事，轮到自己头上是另一回事。知道参差多态是好的，和欣然接受自己恰好属于“参差”的那一头，中间隔着不少年。

和解不是忽然觉得自己完美。和解是承认自己不完美，但不再把人生的主要精力花在审判这件事上。我可以不喜欢我的体毛，但不必因此恨夏天；可以不喜欢我的黑，但不必因此躲着相机；可以承认一六七不高，但不必在比我高的人旁边自动缩水；也可以认真对待脱发，但不必把每根掉下来的头发都记进个人的命运史。

这算不上胜利，只能算停战。停战已经很好了。人这一辈子要办的事太多，犯不着天天跟自己的皮肤、骨骼和毛囊打内战。

人不是一张体检表

身体当然重要。谁也不能假装自己没有身体，因为饿了会叫，累了会疼，洗澡时掉下来的头发会用很具体的方式提醒人什么叫现实。

但人也不能只是一张体检表。

假如把我拆成几个指标：多毛、黑、一六七、易脱发，那我看起来确实像一份不太体面的产品说明书。可是人不是拿来这么用的。人有自己说话的方式，做事的习惯，喜欢的东西，有忍住没说的刻薄话，也有终于说出口的真心话。这些东西没法用尺子量，所以体检表上一概没有。体检表上没有的东西，不见得就不重要——据我所知，最重要的东西一般都不在上面。

从前这几处地方让我觉得低人一等。现在它们还在，只是权力小多了。它们仍然能影响我的照片、衣服、发型和心情，但已经不能决定我配不配好好活着。

我能做到的和解，大致就是这样：不把改不了的东西神圣化，也不再羞辱它。我还是多毛，还是黑，还是一六七，还是为头发操心。但我不打算再把自己押上被告席了。

一个人来到这个世上，本来就不容易。要是还得先通过自己设立的外貌审查，才准许自己活得坦然，那就太不讲道理了。这个道理我明白得不算早，好在也不算太晚。

When work gets busy, I often write better. The best example was a small bug in an article summary: the mobile card left a blank line, and I found the root cause in the length check. The fix was tiny, but it gave me a real post.

Busy work filters topics

The most common excuse for not creating content is not having enough time. I have used it myself.

But limited time is not always a disadvantage. It pushes away broad topics that sound useful but stay vague.

You stop writing "how to improve productivity." You start writing "how I reduced one recurring task from 30 minutes to 5 minutes this week."

The first one sounds like an opinion. The second one is experience.

Creators do not always need more time. They need more specific problems.

Urgent problems are real material

If you are busy, you are probably dealing with real tasks every day.

Those tasks create concrete friction:

• Which workflow wastes the most time
• Which tool feels awkward
• Which sentence needs to be explained three times
• Which decision keeps circling back
• Which mistake you just made and others may repeat

That friction is content material.

People with plenty of empty time often start from "what do I want to say?" Busy people start from "what did I just solve?"

The second starting point is better.

Short time forces practical writing

If you only have 30 minutes to write, you have little room for filler.

You only need to answer three questions:

• What problem did I face?
• How did I solve it?
• Why is this useful to someone else?

That is enough.

An article does not need every background detail or the full theory. If it explains one concrete problem and leaves behind one reusable method, it already has value.

Do not chase completeness

Many people fail to publish not because they lack time, but because they want every piece to feel complete.

When you are busy, completeness is the first thing to drop.

You can write one observation, one workflow, one judgment, or one failure case. A short piece is fine if the information density is high.

For example:

• Why a tool does not fit your workflow
• Why a prompt failed
• Why a project was delayed
• Why a decision turned out wrong
• Why a small change saved a lot of time

Each one can become a standalone post.

Turn work into notes

The best material is not in a topic list. It is inside your work.

Track three types of notes:

• Problems you just solved
• Mistakes you just made
• Methods you just changed

Do not wait until the weekend. Details fade quickly.

The note does not need to be complete. One sentence is enough: what happened, why it got stuck, and how you handled it.

When you write, expand that sentence.

Busy people need a fixed structure

When you are busy, do not design a new structure for every post.

Use a simple fixed format:

1. State the problem
2. Name the old misconception
3. Explain the new approach
4. Define where it applies

A fixed format reduces startup cost. You do not need to figure out the article first. You only need to put real experience into a stable container.

Writing does not have to start from zero every time.

Being busy is not the blocker

Being busy reduces writing time, but it can improve topic quality.

You are not writing imagined problems. You are writing problems that just happened. You are not giving polished advice. You are sharing methods that were just tested.

If you always feel too busy to create content, change the goal.

Do not start by chasing output volume. Start by turning real friction into useful notes.

Limited time forces specificity.
Specificity is what most content lacks.

我曾把写作寄希望于周末。到了周末，先打扫卫生，再整理书桌，顺便研究午饭。一天过完，文章没写，书桌倒是很干净。

后来我改在忙的时候写。白天有个问题浪费我半小时，晚上就写下来。事情不大，但它真实发生过。

忙会帮你过滤选题

有一个完整下午，我容易想写效率、成长、方法——题目很大，动笔才发现里面什么都没有。

忙的时候没资格招待这种题目，只能写眼前的事：一个任务为什么花掉 30 分钟，一个提示词为什么失败，一个流程为什么总卡住。

题目小了，文章反而站得住。

紧急问题更接近真实需求

你很忙，说明每天都在付学费——交给流程、工具和错误判断。

哪个步骤重复了三遍，哪个功能藏得太深，哪个决定做完又推翻。这些麻烦就是材料，不是从书上抄来的，也不太容易撞题，因为你真的付过时间。

闲下来问「我有什么观点」，答案常常很大；忙起来问「我刚解决了什么」，答案至少有来路。

只用回答三个问题

只有 30 分钟时，我不会先解释什么是效率。我只回答：

• 遇到了什么问题？
• 怎么解决的？
• 对别人有什么用？

回答完就停。读者不是来看道理展览的，只想知道你做了什么、结果怎么样。能让他少试一次错，文章就有用了。

放弃完整感

很多人写不出来，是把文章当竣工验收——背景、原因、方法、风险，一项不能少。结果是标准很高，字数很少。

忙的时候只写一件事就够了。写少了可以补，写空了没办法。

当天就记，别等周末

素材别等灵感，灵感经常迟到，工作不会。

刚发生时，你记得按钮在哪、报错是什么、自己为什么判断错。过两天只剩一团情绪，情绪不能当操作步骤。

一句话就行：「卡在哪，为什么卡，最后怎么处理。」真正写文章时再展开。

固定一个格式

忙的时候不要每篇重新发明结构，发明结构也是一种拖延。

固定一个简单格式：先说问题，再说误区，然后说新做法，最后说适用边界。

结构稳定，脑子就能少干一件杂活。

忙不是障碍，空泛才是

工作忙会拿走整块时间，也会把问题送到你面前。白天刚解决的事，晚上写下来，至少知道方法有没有用。

别先给自己立日更目标，那是给未来的自己找麻烦。先记录每次真实摩擦：卡在哪，怎么处理，别人能不能照着做。

时间少会逼你具体。具体不一定动听，但别人拿来能试。能试，就比空泛强。

The faster AI writes code, the less I want to start by reading code.

Code and plans both get long

I used to trace the files first: where the entry point is, where the state comes from, how data moves, and where the result is rendered. That worked in small projects.

Now AI may change routes, components, styles, data scripts, and config in one pass. Each file can be readable on its own, but together they become a web. After reading the code, I still may not know where the change boundary is.

Plans are not much better. They list files, steps, edge cases, and verification. For simple tasks, that is useful. For complex tasks, it becomes another long document. Code complexity turns into text complexity.

So I now look at diagrams first.

Diagrams should answer one question

I tried Mermaid, but complex diagrams get messy. More nodes create crossing arrows. More groups make the diagram wider. The diagram may render, but it is still hard to read.

Then I started using PlantUML. It is better when I split diagrams by question:

• Use a sequence diagram for call order
• Use a component diagram for module relationships
• Use a state diagram for state changes

I ask AI for diagrams first

Now I usually ask AI for this first:

First, draw a PlantUML diagram that explains how these files call each other.
If state changes are involved, draw a separate state diagram.

The diagram helps me see the entry point, data source, business logic, and side effects. After that, I decide whether I need to read the code.

docu.md handles the rendering

One more tool I recommend is docu.md.

PlantUML is easy to maintain inside Markdown, but normal previews may not render it. The docu.md browser extension can render PlantUML in Markdown. It also supports Mermaid, Graphviz, LaTeX, and code highlighting.

Now I ask AI to generate a doc.md file with the task background, key files, PlantUML diagrams, and a short explanation. I open it in the browser, read the diagrams, scan the headings, and then return to the code.

I no longer start from code details or a long plan.

I look at the diagram first.

When I choose a model now, I first ask whether it can handle my real tasks. Leaderboards come second.

Leaderboards are not enough

Model leaderboards change every day.

One model reaches the top today. Another claims to beat it tomorrow. A score tells me how a model performs on public tasks, but not whether it can match my tone, fix my code, or understand my context.

I have seen many strong models fail in daily use. They miss constraints in writing, hallucinate in research, and change the wrong boundary in coding. A model can be good at benchmarks and still fail on a vague two-sentence request.

Public leaderboards rank average ability. Your own eval ranks which model can do your work.

Your eval is also few-shot material

Building an eval set can feel heavy.

You need to collect cases, write expected outputs, and define rubrics. That can sound like unnecessary process.

But those 20 cases have a second use: they become your few-shot library.

Each case contains an input, an expected output, and a scoring standard. You are recording how you want AI to handle this type of task.

The next time you face a similar task, you can paste 2-3 cases into the prompt. Even a weaker model can do better when it sees your pattern.

Start with 20 real failures

The first version should not chase scale.

Start with 20 high-quality cases. Once you can see clear differences between models, expand the set to 100+.

The best cases come from your AI usage over the past 1-2 months:

• Failed conversations
• Tasks with the wrong tone
• Summaries that missed key details
• Code tasks with the wrong change boundary
• Research answers with hallucinations
• Tasks that only worked after repeated follow-up

Real failures are more valuable than invented questions.

You are not testing whether a model can answer a polished prompt. You are testing whether it fails in the situations you actually face.

Each case needs three parts

Each case needs three parts:

Input: the original prompt. Keep it messy if that is how the real request looked.

Expected Output: the answer you wanted. Write it yourself or edit a model draft.

Rubric: the scoring standard. Avoid vague comments like "pretty good." Split the judgment into concrete checks:

JSONL is an easy storage format. Score each answer from 1 to 10, or use Pass/Fail with a concrete reason.

Prioritize edge cases

The set needs diversity, but it should not spread effort evenly.

Include simple, intermediate, and hard tasks. Include writing, coding, summarization, search, rewriting, and analysis.

The cases that separate models are usually edge cases: wrong tone, missed constraints, misunderstood context, invented facts, or answered directly when the model should have asked a follow-up question.

These cases expose model weaknesses quickly.

Compare manually first

The lightest workflow is to feed the same case to several models and compare the answers yourself.

That already solves most model-selection problems.

If you want a more convincing result, turn the workflow into a table:

• One row per case
• One column per model output
• One column for the ground truth
• One column for score and reason

Later, you can use a judge model. Give it the input, expected output, rubric, and candidate answer. Ask it to score the answer and explain why.

Judge models can also be biased, so sample-check part of the scores.

Build your own standard

Public leaderboards are still useful, but only as a first filter.

What matters in daily work is whether a model understands your tone, codebase, business context, and follow-up habits.

Only your own eval set can answer those questions.

Start with 20 real cases. Expand to 100+ after you see clear differences. Add rubrics and a judge model when you need a stable process.

Those cases can also become few-shot examples.

That is more reliable than chasing the newest leaderboard.

代码和 Plan 都会变长

以前顺着文件看逻辑就行：入口在哪，数据怎么传，最后在哪渲染。

现在 AI 改一次功能，可能同时动路由、组件、样式、数据脚本和配置。每个文件单独看都懂，合起来像一张网。看完代码还是不知道改动边界在哪。

Plan 也没好多少。复杂任务里，代码复杂度被翻译成了文字复杂度。

所以我现在先看图。

按问题拆图

Mermaid 简单场景够用，复杂了就乱——节点多了箭头互相穿插，分组多了图越拉越宽。

后来我用 PlantUML，按问题类型选图：

• 看调用顺序 → sequence diagram
• 看模块关系 → component diagram
• 看状态变化 → state diagram

先让 AI 画图

我现在通常让 AI 先生成：

先用 PlantUML 画一张图，说明这几个文件之间的调用关系。
如果涉及状态变化，再单独画一张 state diagram。

图能帮我快速判断入口在哪、数据从哪来、哪些地方可能互相影响。图看懂以后，再决定要不要看代码。

docu.md 负责渲染

PlantUML 写在 Markdown 里好维护，但普通预览不一定能渲染。docu.md 的浏览器插件可以渲染 PlantUML，也支持 Mermaid、Graphviz、LaTeX。

现在我会让 AI 生成一个 doc.md，放任务背景、关键文件、PlantUML 图和少量说明。浏览器打开，看图、扫标题、再回代码。

我不再从代码细节开始，也不再从一长段 Plan 开始。我先看图。

现在我选模型，先看它能不能解决我的真实任务，再看它在榜单上排第几。

榜单测的是标准题，不是你的任务

模型榜单每天都在变。一个模型今天登顶，明天就被超过。

但跑分高不代表它能写出我要的语气、改对我的代码、理解我的上下文。我遇到过不少：分数很高的模型，拿来干活却漏约束、编细节、答非所问。

腾讯混元团队的姚顺雨也提到：榜单很容易过拟合，榜单问题多是规范的单轮题；真实用户的问题更模糊，往往只有一两句话，还需要多轮追问。原文

CSuite 的文章给了同一个方向：真正有用的评测，可以来自你自己的 20 个真实输入，而不是几千道公开题。

榜单排的是平均能力。你自己的评测集排的是「哪个模型能做好你的工作」。

评测集也是 few-shot 库

自建评测集看起来有点重：整理 20 个 case，写期望输出，再写评分标准。

但这 20 个 case 还有第二个用途：它们会变成你的 few-shot 示例。

每个 case 都包含 Input、期望输出和评分标准。你记录的不是「模型 A 比模型 B 高 2 分」，而是「我希望 AI 这样回答」。

以后遇到类似任务，把 2-3 个 case 放进 prompt，即使用稍弱的模型，也会因为有了示例更接近你的偏好。

评测集不是一次性表格，它是你的 AI 使用说明书。

先收 20 个真实失败 case

第一版不要追求规模，20 个就够。能看出模型之间的明显差异后，再扩到 100+。

case 来源：你最近 1-2 个月翻车的记录——失败的聊天、没按风格输出的任务、漏掉关键细节的总结、改错边界的代码、出现幻觉的回答、需要反复追问才完成的任务。

真实失败案例比凭空造题更有价值。你要测的不是模型会不会答一道漂亮题，而是它会不会在你经常翻车的地方再翻一次。

每个 case 三样东西

Input：原始 prompt。可以修错别字，但别把问题改得太完美——真实用户本来就会省略背景、混用口语。

期望输出：你理想中的答案。手写也行，让最好的模型生成再由你改到满意也行。

评分标准：拆成可判断的维度，别写「整体不错」：

存成 JSONL，每行一个 case：

{"id":"writing-001","input":"改写产品介绍，保留功能点，不要营销腔。","expected":"语气自然、信息完整、没有夸张形容词。"}
{"id":"coding-001","input":"找出移动端按钮换行原因，只给最小修改。","expected":"指出 CSS 原因，并给出不影响桌面端的改法。"}

评分可以用 1-10 分，也可以用 Pass/Fail 加理由。

优先挑边缘案例

评测集需要多样性，但不要平均用力。覆盖写作、代码、总结、搜索、改写、分析即可。

真正拉开模型差距的，通常是边缘案例：语气不对、遗漏约束、误解上下文、编造事实、需要追问却直接回答。

先人工比较，再引入裁判模型

最轻量的做法：把同一个 case 喂给几个模型，手动比较回复。你已经能看出哪个适合写作、哪个适合代码、哪个看起来聪明但总漏关键约束。

想更系统化，做成表格：每行一个 case，每列一个模型输出，旁边放期望输出，最后一列放评分和理由。

再往后，才需要裁判模型打分。裁判模型也会偏，记得抽查。

别追榜单，沉淀自己的标准

公开榜单只适合做第一层筛选。真正影响日常效率的，是模型能不能理解你的语气、代码库、业务上下文和追问习惯。这些问题只能靠你自己的评测集回答。

先收 20 个真实 case → 看到差异后扩到 100+ → 需要稳定流程时加入 Rubric 和裁判模型。

这些 case 还能反过来变成 few-shot，你用它比较模型，也用它让模型更懂你。这比追着榜单换模型可靠。

Why is there "Mr" in my name? Nothing deep: mrlark.com was the shortest domain I could register, and "Mr" came with it.

If I could register lark.com, I would just be Lark. If I could register musk.com, I would not mind being Musk either. My online name was not invented; it was what remained.

That may sound casual, but I paid tuition twice before I learned it. In the end, a good name is plain: it should be easy to say and easy to remember.

That lesson came from two bad names I used before.

Two bad names I used

My first name was "Xiaolin's Mischief Dragon."

It was a mix of The Dragon Maid of Kobayashi's House and Water Margin: one is an anime, the other is a classic Chinese novel. When I came up with it, I thought I was being clever. It had a little anime energy and a little classical-literature energy.

Later I found three problems:

• It was too long. Seven Chinese characters are already a lot to remember.
• The reference was too obscure. People who had not watched the anime missed one half, and people who had not read Water Margin missed the other.
• It was hard to address. In Chinese, people usually use two-character names, so I still did not know whether people should call me "Xiaolin" or "Jianglong."

Later I changed it to "Yinke Jun," using "Yinke" as a sound-alike for Ink.

That name was shorter, but it still had two problems:

• The reference was still too obscure. Most people saw "Yinke" and thought of stamping or carving, not Ink.
• It was still awkward to say. "Yinke" and "Yinke Jun" both felt a little stiff.

The two names looked different, but the real problem was the same: they were names I liked, not names other people could use.

A name should be easy for readers

After those two failures, I understood something simple: the main user of a name is the reader.

Once a name is chosen, I barely use it except when I introduce myself. Readers, on the other hand, see it again and again. They see it when they read my articles, and they see it when they want to contact me.

So the standard should come from the reader. For readers, a name only needs two things: it should be easy to say, and easy to remember.

Easy to say means no hesitation when someone leaves a comment or mentions you in conversation. "Mr Lark, this was a good article" sounds normal. "Xiaolin's Mischief Dragon, this was a good article" does not.

Easy to remember means people can find you again. That is where the domain comes in.

A name should have a short domain

Why care about a domain? Because platforms are unreliable.

Today a platform may think you are worth recommending. Tomorrow it may decide you no longer fit its direction and stop showing your work.

A domain is the fixed place you control. With mrlark.com, anyone who wants to see what I am doing has somewhere stable to go. A platform can stop recommending me, but on my own site, I am still the main character.

So my rule is to reverse the usual order: check the domain first, then choose from the names that are still available. A name can fit the domain, but the domain cannot fit the name.

That is how I ended up with "Mr Lark": first mrlark.com, then "Mr."

It may not be the most striking name at first glance, but it can be spoken, it can be remembered, and I am willing to keep using it. That is enough.

名字里为什么带个「先生」？答案一点都不深沉：mrlark.com 是我能注册到的最短域名，「先生」纯属域名的附属品。

要是能注册到 lark.com，我就叫拉克；要是能注册到 musk.com，我也不介意叫马斯克。可见我的网名不是起出来的，是剩下来的。

这听起来随便，其实是我交了两次学费换来的。折腾到最后我发现，好名字的标准其实朴素得很：叫得出口，记得住。

这个道理，得从我取过的两个坏名字讲起。

我取过两个坏名字

我最早叫「小霖家的混江龙」。

这个名字是《小林家的龙女仆》和《水浒传》的混血：前者是一部动漫，后者是书里一位好汉的绰号。起这个名字的时候，我以为自己很有文化：既有二次元，又有古典名著，古今合璧。

后来发现它有三大毛病。

• 一是太长，足足七个字。人的记忆又不是硬盘，装不下这么长的字符串。

• 二是梗太生僻。不看动漫的人不知道龙女仆，不读《水浒》的人不知道混江龙。两个圈子都逛过的人，比我预想的少得多。

• 三是没法称呼。国人叫人，习惯用两个字，于是问题来了：到底该叫我「小霖」，还是「江龙」？我自己都不知道。

后来我痛定思痛，改叫「印刻君」，取「印刻」谐音 Ink。这次只有三个字，短是短了，但依然犯了两个毛病：

• 梗太生僻。多数人看到「印刻」，想不到 Ink，只想到刻章；
• 还是不好称呼，「印刻」和「刻君」，叫哪个都别扭。

两个名字看起来问题不同，本质上是同一个问题：它们都是给我自己看的，不是给别人用的。

名字是方便读者的

两次失败让我想明白一件事：名字这东西，主要用户是读者。

道理很简单：名字起了之后，我除了自我介绍，并不会用到几次，读者却要反复面对它。读文章时会看到我的名字，想咨询还能看到我的名字。

既然用户是读者，就得按读者的方便来。读者对一个名字的要求无非两条：叫得出口，记得住。

叫得出口，读者评论我文章时、就不会纠结怎么称呼你。「拉克你这篇文章不错」听起来很正常，「小霖家的混江龙你这篇文章不错」听起来就有点中二了。

记得住：方便读者找到你。这就是域名的事情。

名字最好有短域名

为什么是域名？因为平台靠不住。

平台今天觉得你不错，给你流量扶持；明天觉得你不符合平台的发展基调，就可能不给你推荐。

域名就是自媒体人的不动产。有了 mrlark.com，读者偶尔想看看我在干什么，就有一个固定的地方可以去。平台可以不推荐我，但在我自己的网站，我永远是主角。

所以我的建议，是把取名的次序倒过来：先去查域名，看哪些短域名还注册得到，再从能注册的里面挑名字。名字可以迁就域名，域名没法迁就名字。

我现在叫「拉克先生」，就是这么来的。先有 mrlark.com，后有「先生」。

它未必是第一眼最惊艳的名字，但它能被叫出来，能被记住。这就够了。