教代理用你的口吻写作

你正在读的这篇博客是 AI 代理写的。但听起来像是我写的。

这不是巧合。我写了一个 skill——一套可复用的指令——教代理如何用我的口吻写、按我的内容 schema 来、按我会用的结构组织文章。这篇文章既是说明，也是证明。

真正的问题不是能力

每次让代理写博客，结果都像新闻稿：语法正确、语气空洞、堆满我不可能用的企业腔和感叹号。

本能会怪模型。但模型可以用任何口吻写——它只是不知道该用哪种。没有约束时，它就退回到训练数据的平均：安全、泛化、企业腔。没有方向本身就是方向。

这个认识改变了我对和代理协作的看法。瓶颈不是智能，是上下文。而上下文不是传一次就完事的东西——你要编码进去，它才会在每次交互里持续存在。

Schema 容易。用 Zod 给 frontmatter 下定义——必填字段、类型、校验规则——精确可验证，要么输出符合要么构建报错，没有歧义。

口吻完全是另一回事。你怎么告诉代理：段落要短、句子要陈述句、用斜体做「重新框定」而不是单纯强调、宁可删掉一段也不加感叹号？

我得到的答案是：用例子代替描述。对代理说「要 conversational」几乎没用。给它五段你自己文章里的引用，并注明每段为什么有你的风格，才能得到你几乎可以直接保留的输出。

另一点是：反模式比正模式更重要。正向指令（「用短段落」）模型很容易漂移。负向约束（「绝不用感叹号」「绝不用 kind of / sort of 打马虎眼」）是硬线，比再多正向指导都更可靠地把输出从泛化里拉回来。

这里有个反直觉的机制：我给 skill 加的约束越多，输出越好。不是因为规则多了写得更死板——而是约束把模型最不擅长做的那类决定拿掉了。

没约束的代理会在语气上纠结：这段该正式还是随意、该不该热情？没有信号就取中间值，写出来不像任何人。

有约束的代理不用做这个决定。口吻指南说：第一人称、不 hedging、结尾要有立场。Schema 说：每段 1–3 句、不要 H1。检查清单说：返回前要验证。每条约束都消灭一类泛化输出。

这和我对产品设计的看法一致：最好的产品不是功能最多的，而是把最少的选择推给用户。对代理来说，skill 起的就是这个作用。

这篇就是用它所描述的那套 skill 写的。我让代理用 website-content skill 写「教代理你的口吻」这篇文章。代理读了口吻指南、内化了内容 schema，按我的结构产出了初稿——开头挑衅、中间立论、结尾有结论。

我没有逐句口述。我是教系统我怎么看待写作，然后让它执行。

这个区别很重要。Skill 的价值不是替你生成文字，而是把程序性知识——那种通常只在你脑子里的机构性理解——抓出来，变成可复现的。

含义比写作更广。任何你会反复向代理解释上下文的可重复流程，都适合这套做法：代码审查标准、发布流程、数据库约定、设计系统规则。

有意思的问题不是「代理能不能做这个」——显然能。有意思的是：你脑子里有哪些知识从来没写下来，因为没人需要你写？那些知识正是代理缺的。

Skill 就是用来补这个缺的。不是给人写文档，而是给代理写操作说明。格式是 SKILL.md，生态是 skills.sh。难的不是工具，是把「你实际怎么做、怎么想、为什么你的做法和默认不一样」说清楚所需的内省。