普通视图

发现新文章,点击刷新页面。
今天 — 2026年2月14日首页

AI 时代掌握 Markdown,是最基础也最必要的技能 (小红书长文也可以用哦)

作者 threerocks
2026年2月14日 12:23

AI 时代一来,最常用、最通用、最省心的技能,是 Markdown

就那套:

# 是标题

- 是列表

三个反引号是代码块……

以前我把它当程序员小玩具,写 README 用的。

现在我写提示词写知识库写会议纪要写项目计划、甚至写小红书草稿都在用它

很多大模型默认吐出来的也是 Markdown

你不学也会天天用;你学了,就能把它用得更顺、更像人机协作的公共语言

这篇文章就把 AI 时代的 Markdown 技能讲清楚:

  • 为啥说 Markdown 是 AI 时代基础必修
  • 新手怎么用 30 分钟上手
  • 我踩过的坑
  • 直接给你几套能复制走就用的模板

AI 时代大家都在写『文档』

以前我们写作给人看的。

现在很多文字要同时两类读者看:

  • 人:扫一眼懂不懂、读起来顺不顺
  • AI:能不能切分、能不能检索、能不能执行、会不会误解

Markdown 的优势特别像夹在中间的翻译官

  • 对人:比 Word 清爽,写起来也不费手
  • 对模型:结构清晰、层级明确、token 还省(真的省)

一个很现实的事:会 Markdown,不代表你是技术人;但不会 Markdown,你在 AI 时代做事会莫名卡住

比如:

  • 你发提示词给模型,一大段纯文本没结构,模型抓不到重点
  • 你做个人知识库,内容堆在一起,RAG 切分一塌糊涂
  • 你写项目计划,别人看不懂,Agent 更执行不了

Markdown 其实就是把我要说的话变成可计算的文字

为什么它是新手最容易掌握的技能

你想学一个新技能,最怕两件事:

你掌握 10% 的语法,就能覆盖 90% 场景;你今天学,今天就能用在:提示词、笔记、文档、发文、写代码说明。

而且它是纯文本。

这意味着,不依赖软件、不依赖平台、不怕格式丢失、还能被 Git 管起来。

你换工具、换平台、换设备,Markdown 都能带走。

这在 AI 时代太重要了,因为你的内容会被喂给各种模型、各种工具链。

30 分钟上手法

我自己教朋友(完全小白那种)就用这四个:

1)标题:# 真的就够了

这是大标题

这是小标题

这是更小的标题

最常见的坑:# 后面要空一格。

写成 #标题 有的平台不认,真的会气到。

2)列表:用 -1.,全篇统一就行

无序列表

  • 这是一条

  • 这也是一条

  • 这也是一条

有序列表

  1. 这是一条

  2. 这也是一条

  3. 这也是一条

列表上下不空行,有的平台会在一起。你就当空行是免费的,随便用。

3)链接

这是链接文字

你以后写提示词、写文档、写小红书参考来源,这个非常好用。

4)代码块


npm i

新手最常见的痛苦:代码复制出来一坨。加上代码块,世界瞬间清净。

踩过的坑

坑 1:换行不是你以为的换行

Markdown 里回车一下不一定等于换行

很多渲染器会把同一段落里的换行当成空格。

解决办法就两个:

  • 真分段:中间空一行(部分渲染引擎支持)
  • 想强制换行:上一行行尾加 3 个空格再接回车一下即可,或者用 <br>

坑 2:你从 Markdown 复制到某些平台,会出现一堆 ###

比如你发到某些富文本编辑器(包括部分社媒的长文功能),它不完整支持 Markdown,就会把符号原样贴上去。

我的小技巧:

  • 在 VS Code 里(或者其他 Markdown 预览器)先打开预览(Mac:Cmd + Shift + V
  • 在预览里复制,再粘贴到平台

这个技巧我自己用来发公众号也挺稳。

坑 3:文件名有空格/中文,后面做知识库会很难受

我以前喜欢起名:“今天学 Markdown 好开心.md”

后来要做链接引用、做同步、做脚本处理,全变成麻烦。

解决办法:

  • kebab-caseai-markdown-guide.md
  • 或者加日期:2026-02-14-notes.md

中文当然也能用,只是后续工具链会更容易出小毛病(尤其跨平台)。

它不只是排版,它是结构化提示词的容器

我以前写提示词是:一大段话丢给模型,靠缘分。

后来我发现:你用 Markdown 把提示词分区,模型执行力会明显变好。

你可以直接复制这个模板:

你的角色

你是一个严谨但很会讲人话的编辑。

背景

我要写一篇小红书长文,主题是:掌握 Markdown 是 AI 时代的基础技能。

读者是完全新手。

输出要求

  • 口语化

  • 有真实使用场景

  • 不要“首先/其次/总结一下”那种模板腔

  • 给出可复制的 Markdown 示例

我已经有的素材

  • 我经常用 VS Code 写 Markdown

  • 我会把笔记喂给 AI 做总结

你需要交付

成稿 + 配图提示词

这玩意儿本质上就是,你用标题告诉模型这块是什么,减少它乱猜。

做个人知识库、做 RAG、做第二大脑

我以前记笔记是什么都往一个长文档里堆,然后想找东西就靠搜索,搜不到就崩溃。

后来我学会一个很简单的思路:

把一条知识写成一个小条目,用标题+短段落+列表。

你甚至可以给每条笔记加一个 YAML 头(有些工具会识别):


title: Markdown 换行规则

tags: [markdown, writing, ai]

created: 2026-02-14


结论

段落之间要空一行。需要强制换行就用行尾两个空格或 <br>

我踩过的坑

  • 直接回车在某些渲染器里不会换行

示例

第一行

第二行

这种结构对你也友好,对 AI 也友好,AI 检索的时候能更容易切到对的块,总结也更不容易跑偏

进阶一点点:表格、任务清单、引用

这几个我个人用得特别多,但我只在平台支持的时候用(比如 GitHub、Notion、一些博客系统)。

任务清单

  • 学会标题

  • 学会列表

  • 学会代码块

引用

这是一段引用。

我用它来放原文/结论/别人的观点。

表格

| 场景 | 用 Markdown 的原因 |

| --- | --- |

| 写提示词 | 结构清晰,模型更听话 |

| 写知识库 | 易切分,易检索 |

| 写文档 | 跨平台,不怕格式丢 |

写作这事,在 AI 时代更像你的生活感 + 结构能力的组合。

Markdown 负责结构,你负责生活感。

前端将死,Agent 永生

作者 threerocks
2026年2月13日 23:13

我在家里一边收拾家里小鱼缸,一边刷到 Chrome 146 那个 WebMCP 的消息,然后顺手点进去看了半天,越看越觉得:

前端这条最后防线,可能真的要松动了。

以前我们讲用户增长DAU留存,讲得头头是道。但一旦你开始认真看 WebMCP,你会发现这套语言体系像在讲上个世纪的传真机。

我不是在夸张。

不是说 UI 不重要了(品牌、美感、情绪价值还是很贵),而是 谁是软件的用户 这件事,正在换人。等等,不对,是换“东西”:Agent 才是新的用户

这篇我就按我自己的理解,把 WebMCP 讲一下,到底是什么和你听过的 MCP 有啥关系、为啥我说它像 UI 里的 API、以及我踩过的几个坑,尤其是安全那块。

WebMCP 是什么?

以前 Agent 操作网页,基本两条路:

  • 一条是“装人”:截图、OCR、推理、找按钮、点错了再来一遍,token 烧到你心梗
  • 一条是“扒皮”:读 DOM、读无障碍树、猜结构、网站一改版就崩,稳定性也不太行

WebMCP 的感觉很不一样,它更像:

你不让 Agent 看像素,也不让它猜 DOM,你直接告诉它:我这页能干什么,参数是什么,给你一个确定性的工具接口。

WebMCP 就相当于 UI 里的 API。

你把它想象成:以前你给人类做 UI;现在你给 Agent 也做一层工具 UI

人类点按钮,Agent 调函数。两个用户,同一个状态,同一个会话(cookie / session),在一个页面里并肩工作。

三种 WebMCP

1)Web 标准提案:navigator.modelContext

这是 Google / Microsoft 推的 W3C 社区组提案,Chrome 146 早期预览里已经能体验到一点点苗头。核心是浏览器给你一个原生 API:navigator.modelContext,让网站注册工具。

工具大概长这样(示意):

它跟你熟悉的后端 MCP server不一样:这是 纯浏览器端 的。网页自己就是server
也因此它天然复用浏览器的登录态,不用你再搞一坨 OAuth 流程(这点我太爱了,真心的)。

2)MCP-B

这是 Alex Nahas 那条路线,把 MCP TypeScript SDK 搬到浏览器里,用 postMessage 做传输,让扩展/客户端能发现并调用你页面里的工具。

它的典型接入方式很像50 行搞定那种:

注意哈:allowedOrigins: ["*"] 这种只适合 demo,真上生产会被你未来的自己追杀(后面我会讲原因)。

3)Jason McGhee 的开源库

还有一个你会经常看到的 WebMCP,是那个右下角冒出来一个小蓝方块的库。它的特点是接入极简单:页面里丢一个脚本,小蓝块就出来,然后你用 MCP 客户端生成 token、粘进去,就能连上。

它更多是让网站快速具备可交互能力的产品化形态。适合做 demo、做推广、做早期验证(小红书这种传播场景很友好)。

所以我现在的口头区分是:

  • WebMCP(标准):浏览器 API navigator.modelContext
  • MCP-B(桥接):把 MCP SDK + 浏览器传输拼起来,让现在就能跑
  • 小蓝块 WebMCP(库):体验型接入,适合快速展示

你要问我哪个会赢——我倾向于:
标准一定会吃掉大部分生态,但在标准普及之前,桥接会先养活一群人。

为啥我说“前端将死”?

我看完前段时间很火的那篇《互联网已死,Agent 永生》,最大的震撼其实不是情绪,而是那个前提变化:

旧世界:人是软件的用户
新世界:Agent 才是软件的新主人

放到 WebMCP 上,翻译成更直白的话就是:

  • 以前你做一个 web app,核心问题是:用户能不能点明白、流程顺不顺、按钮够不够大
  • 现在你做一个 web app,新增一个核心问题是:Agent 能不能稳定调用、Schema 清不清楚、失败能不能自愈

你会发现很多前端经验突然不灵了:

  • 你把按钮做得再好看,Agent 不一定会点(它可能根本不点)
  • 你把页面做得再炫,Agent 只关心:有没有 checkout() 这种工具
  • 你以前写用户使用手册,现在更像在写工具契约和调用说明

我甚至觉得未来会出现一种很怪的 KPI:

  • 不是 DAU,而是 TAU:Tool Active Usage(工具调用活跃)
  • 不是转化率,而是 成功调用率 / 平均重试次数 / 幂等率

碎碎念一句:
我之前一直觉得给 Agent 做东西很虚,直到看到 WebMCP 这种结构化工具落在浏览器里,才意识到它会把很多事情变成工程问题,而不是玄学。

WebMCP 真正让人兴奋的点

传统做法里,你想让 Agent 操作你的产品,往往得:

  • 额外开一套后端 MCP server(或者写一堆 automation)
  • 再搞 OAuth / API key / 权限
  • 再处理Agent 做完动作,网页状态怎么同步

WebMCP 的思路是:
别折腾了,Agent 就在浏览器里,直接复用现有 session。

这会带来两个很现实的好处:

  • 你不用把登录态复制给 Agent(也就少了一堆密钥泄露风险)
  • UI 和工具天然同源:人点完和 Agent 调完,看到的是同一个页面状态

这种人和 Agent 共用一套界面的感觉,很像以后会变成默认模式:
人负责拍板 + 审核,Agent 负责跑腿 + 串流程。

WebMCP 的安全坑

我读到 WebMCP 的安全最佳实践那篇的时候,第一反应是:“完了,这玩意儿如果大家不按规则来,迟早会出事。”

1)WebMCP 的威胁模型变了

以前我们做 web 安全,默认用户控制自己的浏览器
但 WebMCP 的世界里,一个 Agent 可能同时连着好几个网站的工具:

  • 你的网站工具(正常)
  • 用户开着的别的网站工具(未知)
  • 某个恶意网站的工具(专门来搞你的)

然后那个恶意工具可能会诱导 Agent:

  • 把你这边拿到的敏感数据,顺手汇报出去
  • 用你的登录态执行不该执行的动作(比如转账、下单、删数据)

你得把 Agent 当成一个可能被 prompt injection 过的脚本执行器
听起来很刺耳,但真的要这么设计。

2)致命三元组

当下面三件事同一页同时存在,风险直接上天:

  • 你能读到私密数据(邮件、聊天记录、订单、地址)
  • Agent 会处理不可信内容(外部邮件正文、用户输入、第三方内容)
  • 你还有对外通信能力(发请求、发消息、上传)

记住:不要把敏感数据直接喂给 Agent。

有一句我直接记下来了:
“Sensitive information must NEVER be passed to the AI agent’s context. Always use references instead.”

翻译成人话就是:

  • 你要给 Agent 的不是完整聊天记录 JSON,而是一个引用 ID
  • 真正的数据留在同源安全存储里,需要时让用户在 UI 上确认再展示/执行

3)描述要老实,标记要明确,还要二次确认

你想象一下:
一个工具嘴上说“add_to_cart”,实际干了“complete_purchase”。
Agent 是很难识别这种工具自述与行为不一致的。

所以我现在的偏执做法是:

  • 只要能扣钱、删数据、发外部消息:必须让用户弹窗确认
  • 工具描述写清楚会发生什么,别耍小聪明
  • 工具参数里加一个必须传的确认短语(比如 CONFIRM_PURCHASE 这种)

我知道这听起来很烦,但真的比被盗刷烦少多了。

可以应用的场景

场景 A:想快速做一个能演示的 demo(给老板/投资人/用户看)

我会优先上小蓝块那类方案:

  • 你只要让网页能被连接,工具能出现,就够了
  • 先选 1-3 个最核心动作做工具,比如“查询当前订单”“把商品加入购物车”“生成一段摘要”
  • 工具返回尽量短,别给一大坨无意义字段

这个阶段最重要的是:
让人看到Agent 不用装人,也能把事干了

场景 B:想让真实用户用起来

我会走 MCP-B 那条路线:

  • 把你现有前端逻辑包成工具
  • 输入/输出 schema 认真做,越明确越好(能减少幻觉和误用)
  • 把工具分层:只读工具一组,改状态工具一组,危险工具单独一组

然后立刻做三件事:

  • 工具幂等:重复调用不应该炸
  • 错误要可读:别把堆栈直接抛出去(也别泄露内部信息)
  • origin 白名单:生产环境别写 "*"

场景 C:你押注未来,想吃标准红利

那就盯 navigator.modelContext 这条线:

  • 能用的时候就用原生 API
  • 不能用的时候就用 polyfill/桥接做兼容

我甚至觉得以后会出现一种Agent SEO:你的网站有没有对 Agent 友好的工具契约,会变成一种竞争力。

给前端同学的安慰(我也需要)

我说“前端将死”,其实是在说一种旧范式在死:只为人类服务的前端,在死。

但你要真让我选,我反而觉得前端会变得更重要,只是重要的点变了:

  • 你要会把 UI 操作提炼成稳定工具
  • 你要会设计 schema、错误语义、幂等性
  • 你要懂安全
  • 你还得懂人类体验

未来的好前端,可能是:既能写好看 UI,也能写好给 Agent 调的工具层

我讲真,这种人会很贵

❌
❌