我写了一个让 AI 更像我自己的 skill

你们可能也发现了，我上一篇写 Agent 的文章，AI 味其实不算重，但多少有点“公众号长文”的味道。

原因也很简单：我当时偷懒用了之前做的 khazix-writer。

这个 skill 本身没什么问题，它很适合写公众号长文，结构完整、节奏顺、转折也比较自然。但问题在于，它不完全像我平时写技术文章的方式。

所以这次我专门做了一个自己的写作 skill，叫 xinhhd-writer。

这篇文章不打算讲具体 prompt 怎么写，也不准备贴一堆规则。更想说的是：如果想让 AI 写起来更像自己，真正要做的不是让它模仿语气，而是把自己的写作判断沉淀成一个可复用的工作流。

换成人话：

不是告诉 AI “请模仿我的风格”。

而是告诉 AI：

• 我通常怎么选题
• 我会先问什么问题
• 我希望文章讲到什么深度
• 哪些表达我觉得太虚
• 哪些地方必须有工程落点
• 什么情况下不能继续往下编

这才是我理解的 AI Native 写作工作流。

为什么只靠“模仿风格”不够

很多人让 AI 写文章，第一反应是：

你模仿一下我的风格。

这个方向当然有用，但它解决的是比较表层的问题。

比如句子长一点还是短一点，语气正式一点还是口语一点，标题要不要有冲突感，段落之间怎么转场。这些东西确实会影响读起来像不像一个人。

但写作风格不只是语言风格。

尤其是技术写作，真正决定一篇文章“像不像你”的，往往不是某几个口头禅，而是背后的判断方式。

比如我自己写技术文章时，会比较在意几个问题：

第一，这个选题有没有真实问题。

如果只是介绍一个概念，我通常不太想写。因为概念本身没有稀缺性，读者随便搜一下都能看到。更重要的是，这个技术为什么值得看？它解决了什么工程问题？原来的方案哪里不够？

第二，文章能不能从人话进入，但最后落到技术细节。

我不喜欢一上来堆术语，也不喜欢一直停留在浅层解释。比较理想的方式是，先让业务同学或工程同学知道这个问题和自己有什么关系，然后再进入机制、架构、流程、代码、配置、实验或者限制。

第三，不能没有证据。

没有截图就不要写“如下图所示”，没有数据就不要写“显著提升”，没有真实项目背景就不要编一个“某客户案例”。AI 写作最容易出问题的地方，就是它为了让文章看起来完整，会自动补齐一些实际上不存在的东西。

第四，最后要能回到工程场景。

很多技术文章看完以后，读者知道了一个名词，但不知道它能怎么用、适合什么场景、不适合什么场景、落地的时候会遇到什么坑。对我来说，这种文章就还差一口气。

这些判断，才是真正需要写进 skill 里的东西。

我怎么分析自己的写作方式

做这个 skill 的第一步，不是写 prompt，而是反过来分析自己。

我大概看了几类自己以前的文章：

• 论文或新技术解读
• 工程复盘
• 系统方案介绍
• AI 应用和 Agent 相关实践
• 数据平台、Text2SQL、RAG 这类偏落地的技术文章

看完以后会发现，虽然主题不一样，但底层结构其实比较稳定。

我通常不是从“这个技术是什么”开始写，而是从“这个问题为什么值得讨论”开始。

比如讲一个新方法，我会先问：

它解决了现有方案的什么问题？

讲一个工程方案，我会先问：

原来的链路哪里不够？

讲一个 AI 应用，我会先问：

这个东西在真实业务里到底卡在哪里？

也就是说，文章的入口不是知识点，而是问题。

然后再往下拆：

这个问题背后有哪些技术路径？这些技术路径之间是什么关系？每种方案的收益和限制是什么？如果放到真实工程系统里，哪些部分能用，哪些部分还需要改造？

最后再收回来，给一个比较明确的判断：

这东西适合什么场景，不适合什么场景，如果要继续做，下一步应该补什么。

这个结构听起来很普通，但对 AI 来说非常重要。因为如果不显式告诉它，它很容易写成一种“标准技术文章”：

先背景，后介绍，再优势，最后展望。

这类文章不是不能看，但太泛了。读完以后，信息密度不够，也不像一个真实工程同学在复盘问题。

skill 的本质是把判断标准结构化

所以我做 xinhhd-writer 的时候，重点不是让它记住几个固定表达，而是把写作过程里的判断标准结构化。

比如，一篇技术长文应该先判断文章类型。

是论文解读？工程复盘？方案介绍？还是产品化落地？

不同文章类型，结构不应该一样。

论文解读不能只总结论文，要能把论文方法翻译到业务工程场景里。

工程复盘不能只给结论，要讲现象、原理、瓶颈、方案和效果。

方案介绍不能只罗列功能，要回答为什么这个方案成立，以及真实系统里怎么接。

再比如，写作时要不断检查素材是否够。

有没有真实背景？有没有代码、配置、截图、数据、引用？有没有作者自己的判断和踩坑？如果没有，就应该明确提示缺口，而不是强行写成“完整案例”。

这点对我来说很重要。

因为 AI 最大的问题不是不会写，而是太会写。它可以把一个素材很少的话题写得特别完整，甚至完整到让人误以为这些东西都真实存在。

所以 skill 里必须有一个约束：

没有证据的地方，不要替我编。

这不是写作风格问题，而是技术写作的底线问题。

为什么这更像一个工作流，而不是一个 prompt

做到这里以后，我越来越觉得，skill 不是一个更长的 prompt。

它更像是一个小型工作流。

普通 prompt 解决的是一次生成：

帮我写一篇文章。

而 skill 解决的是一类任务：

以后遇到这种文章，你都按这个方式判断、提问、组织、写作和自检。

它里面包含的其实是一个连续过程：

先判断选题是否成立。

再判断素材是否够。

然后选择文章结构。

接着决定开头怎么切入。

正文里先建立直觉，再讲机制和细节。

最后检查有没有编造、有没有空泛、有没有缺少工程落点。

如果素材不够，就先问问题，而不是硬写。

这就是我这次做 xinhhd-writer 最大的收获：

让 AI 像自己，不是让它复刻自己的语气，而是让它复刻自己的决策过程。

语气只是结果，决策过程才是原因。

一个小变化：从“帮我写”到“和我一起写”

做完这个 skill 之后，我对 AI 写作的理解也有一点变化。

以前我们很容易把 AI 写作理解成外包：

我给一个题目，你帮我写一篇。

但如果真的想写出有自己味道的东西，这个模式其实不太够。

更好的方式是协作：

我给方向，AI 帮我追问。

我给素材，AI 帮我组织。

我给判断，AI 帮我展开。

AI 写完以后，再根据我的标准自检一遍：有没有空话？有没有编造？有没有缺少技术细节？有没有真的落到工程场景？

这个时候，AI 就不是一个“代笔工具”，而更像一个写作过程里的工程助手。

它能提高效率，但不替代判断。

尤其是技术写作，判断永远比表达更重要。

表达可以润色，结构可以调整，但如果核心判断是虚的，文章写得越顺，问题反而越大。

后面我会怎么用它

之后我再写一些技术文章，比如 Agent、RAG、Text2SQL、数据平台、评测系统、工程复盘这类内容，应该会更多使用这个 xinhhd-writer。

它不一定每次都直接给出终稿，但至少能帮我做几件事：

第一，先判断这个选题有没有写的价值。

第二，提醒我哪些素材还缺。

第三，帮我把文章结构拉出来，而不是直接进入自由发挥。

第四，在写完以后做一次自检，看看是不是又写虚了、写散了，或者写成了标准公众号体。

这也是我觉得 skill 有意思的地方。

它不是为了让 AI 变成某个“万能写手”，而是把一个人的工作习惯沉淀下来，让 AI 在这个习惯里帮你做事。

写作是这样，写代码、做调研、读论文、做方案，其实也都可以是这样。

最后

这次做 xinhhd-writer，本质上是一次 AI Native 写作工作流的复盘。

我不是想做一个“更会写文章的 AI”，而是想做一个更懂我写作判断的助手。

所以最终沉淀下来的不是几句口头禅，也不是某种固定文风，而是一套更稳定的写作过程：

从问题进入，从直觉展开，到机制和工程细节，再回到真实落地。

这可能也是我现在对 skill 最核心的理解：

skill 不是让 AI 变聪明，而是把你的经验、偏好和边界，变成 AI 可以反复调用的上下文。

欢迎大家讨论。

如果你也在做自己的 AI 写作工作流，我也挺想知道：你们会把哪些东西写进自己的 skill 里？