别再给 AI 工具付月费了,一个 Markdown 文件就够了

你有没有算过，过去一年你在 AI 工具上花了多少钱？

内容生成、社交媒体管理、知识库、自动化工作流……每个月几十到几百美金，加起来够买一台 MacBook Pro 了。而一位 19 岁的开发者，用两个文件就搞定了这一切。

● ● ●

一、19 岁开发者的"叛逆"：200 行代码 vs 整个 SaaS 行业

Ronin（@DeRonin_），CloseAI_hq 的 CEO，MindAI 顾问，X 上 10 万+ 粉丝。他的风格很直接：不整花活，只给能用的东西。

最近他发布了一套方案，核心就两个文件——

1. wiki.md：你的"内容大脑"，用 Markdown 记录受众画像、跟踪的 15 个创作者、30 天爆款话题、语气指南、内容规则

2. dashboard.html：单页 HTML，读取 wiki.md，渲染成可交互的仪表盘，内置 Agent 触发按钮

每天的工作流是这样的：早上 9 点打开 dashboard.html → 看到 5 个按受众 DNA 排序的热门话题 + 3 篇 KOL 推文 + 存档内容 → 点击"起草推文"→ 15 秒生成草稿 → 编辑排期 → 15 分钟完成全天内容。

💡 核心论点：这不是"省钱"的故事，而是"控制权回归"的故事。当 SaaS 厂商决定你的功能边界、API 限额和数据归属时，一个本地 Markdown 文件意味着：规则由你制定，数据由你保管，迭代由你控制。

● ● ●

二、Markdown 是 AI 的"母语"——不是人学 AI，而是 AI 读人

这里有一个反直觉的认知翻转。

过去两年，我们都在学怎么"驯服"AI：写更好的 prompt、用更复杂的链式调用、记各种参数调优技巧。但 Ronin 的方案揭示了一个更本质的事实——AI 最擅长读的，恰恰是人类本来就会写的格式。

Markdown 是什么？它就是一种带格式的纯文本。你写 # 标题、- 列表、**加粗**，AI 不仅能读懂，而且读得比人类还准。因为 Markdown 的结构化程度刚好落在"机器友好"和"人类可读"的甜蜜点上。

wiki.md 本质上是什么？它不是技术文档，它是用 AI 母语写成的需求说明书。你把"我的受众是 25-35 岁产品经理"写进去，AI 读到的不是字符串，而是上下文。你把"语气要犀利但不冒犯"写进去，AI 理解的不是形容词，而是生成约束。

"Prompt engineering 的终极形态，不是学会对 AI 说话，而是让 AI 学会读你的文档。"

这和 Andrej Karpathy 今年 4 月发布的 LLM Wiki 概念一脉相承——个人持久化知识库，增量维护，LLM 辅助综合。Claude Code 社区也已经形成了标准化的 LLM Wiki 工作流模板。一个趋势正在形成：Markdown 正在从"写给人看的格式"变成"写给 AI 读的协议"。

打个比方：以前我们像学外语一样学 prompt，现在发现 AI 早就学会了我们的"方言"。与其我们费劲巴拉地适配它，不如让它来适配我们写了十年的笔记。

● ● ●

三、从"买软件"到"拥有软件"：一场静默的范式转移

让我们诚实一点：SaaS 模式的问题从来不是价格。

$20/月的订阅费，对大多数创作者来说不是负担。真正的痛点是——你的内容策略存在别人的服务器上，你的 API 调用被别人的限额卡住，你的数据训练了别人的模型。某天产品改版，你用了两年的功能突然消失；某天公司被收购，你的数据成了谈判筹码。

Ronin 的方案之所以引发共鸣，是因为它击中了这个时代的一个深层焦虑：我们越来越依赖工具，却越来越不拥有工具。

维度	SaaS 工具	wiki.md + dashboard
数据归属	厂商服务器	你的本地硬盘
功能边界	厂商决定路线图	你改几行 HTML 就行
API 限制	月调用量封顶	只受 LLM API 约束
迭代速度	等官方更新	随时自定义
学习成本	适应新界面	会 Markdown 就完成 50%
订阅成本	$20-200/月	零订阅，只花 LLM API 费

"拥有你自己的工具栈，彻底改变游戏规则。"——@0xSprite_

这个趋势不是孤立的。self-hosted（自建托管）、local-first（本地优先）运动在开发者社区已经蔓延多年。中文社区也出现了类似案例：724-Office 项目用 Hermes Agent + WSL2 + 微信，26 个工具、3500 行 Python，实现 7×24 小时自动化。个人 Agent 工作流正在中英文社区同步爆发。

驱动力从来不是"省钱"——而是控制权的回归。就像从租房到买房，不是为了省房租，而是为了"这面墙我可以砸"。

● ● ●

四、Z 世代的工具哲学：能用文件解决的不装 App

Ronin 今年 19 岁。这个年龄细节不是点缀，它是一个信号。

Z 世代对软件的态度，和他们的前辈有本质不同。80 后、90 后经历了"软件崇拜"——Photoshop、Office、各种专业工具，功能越多越好、界面越复杂越专业。但 Z 世代成长在 App 爆炸的时代，他们见过太多"为了功能而功能"的产品，对过度工程化有一种本能的反感。

他们的哲学是：能用文件解决的不装 App，能用脚本解决的不买订阅，能自己搭的不等官方。

这听起来像极客傲慢，其实不是。这是一种经过验证的极简主义：当工具链足够简单，你才能理解它的每个齿轮；当你理解每个齿轮，你才能真正控制它。

当然，这个方案有明确的边界：

1. 适合个人创作者和小团队——多人协作、权限管理、并发编辑，这些确实需要更重的系统（社区已经有人反馈"没有锁机制、没有版本控制"是痛点）

2. 假设你有可用的 Agent API——这不是零代码方案，你需要能调用 LLM 的能力

3. 需要你主动维护 wiki.md—— Garbage in, garbage out，知识库的质量取决于你的输入

但对于目标用户来说，这些限制恰恰是优点。它逼你思考：我真的需要那个功能吗？还是我只是被 SaaS 厂商的营销话术催眠了？

● ● ●

五、给你的行动清单

如果你被 Ronin 的方案打动，这里是可以立刻开始的三件事：

✅ 今晚就建一个 wiki.md——不用完美，先写下你的受众画像和 3 个内容规则

✅ 明天让 Claude 帮你生成 dashboard.html——把 Markdown 丢给它，说"帮我做一个读取这个文件的仪表盘"

✅ 这周添加第一个 Agent 按钮——从"批量起草推文"开始，验证整个工作流跑通

最后送你一句话：未来不属于用最多工具的人，属于最清楚自己需要什么的人。一个 Markdown 文件，可能就是你的起点。

● ● ●

参考来源：Ronin (@DeRonin_) 原方案；Andrej Karpathy LLM Wiki (2026-04)；Claude Code Playbooks；724-Office GitHub 项目。