尧图网站建设 
这里写自定义目录标题欢迎使用Markdown编辑器一、Vibe Coding 到底是什么又改变了什么二、为什么 Vibe Coding 会突然流行起来三、Vibe Coding 与传统开发的本质区别四、Vibe Coding 的黄金实践把需求喂给 AI五、Vibe Coding 的黄金实践文档比代码更重要六、Vibe Coding 的黄金实践验证闭环与产物验收七、Vibe Coding 的边界与风险理性看待这个范式八、结语从会不会写代码到会不会指挥 AI新的改变功能快捷键合理的创建标题有助于目录的生成如何改变文本的样式插入链接与图片如何插入一段漂亮的代码片生成一个适合你的列表创建一个表格设定内容居中、居左、居右SmartyPants创建一个自定义列表如何创建一个注脚注释也是必不可少的KaTeX数学公式新的甘特图功能丰富你的文章UML图表流程图FLowchart流程图导出与导入导出导入欢迎使用Markdown编辑器你好 这是你第一次使用# Vibe Coding 开发工作流从人写代码到人指挥代码的工程化实践一、Vibe Coding 到底是什么又改变了什么Vibe Coding 这个词由 Andrej Karpathy 在 2025 年提出迅速成为 AI 编程领域最热门的概念之一。它的核心形态可以概括为用自然语言描述需求让 AI 帮你生成、修改和调试代码并通过对话不断把产品做出来。但很多人对 Vibe Coding 的理解停留在表面——以为它只是AI 帮你写代码或者不用写代码了。这其实是两个误读。第一Vibe Coding 并不意味着没有代码代码依然存在改变的是人和代码的交互方式过去你需要告诉电脑具体执行什么代码现在你更多是告诉 AI 你最终想要什么结果。第二它也绝不意味着开发者可以躺平恰恰相反它对开发者的需求拆解能力、上下文管理能力、验收判断能力提出了更高要求。用一个类比来理解传统编程像是自己开车每个动作都由你操控Vibe Coding 则更像是雇佣了一位能力很强的司机——你负责指路、把关方向、在关键路口做决策司机负责具体的驾驶操作。司机的水平固然重要但最终能不能顺利到达目的地很大程度上取决于你这个导航做得好不好。二、为什么 Vibe Coding 会突然流行起来Vibe Coding 的流行不是偶然它背后是 AI 编程工具能力的几次明显跃迁。最早期的 AI 编程工具本质是AI 帮你补全代码——开发者写上下文工具预测下一行。此时 AI 还是纯粹的辅助工具架构、文件、流程都由人掌控。第二阶段工具进化到AI 帮你改项目——人可以提出增加一个登录功能“把这个页面改成响应式”AI 能跨文件修改代码。到了第三阶段工具开始逼近AI 帮你完成任务——它能理解代码仓库、规划开发任务、自己写代码、跑测试、甚至通过浏览器操作真实环境验证产物完成长程任务。正是这种能力跃迁让用对话写软件从概念变成了现实。现在的 AI 编程助手不仅能生成代码还能自主完成创建项目→设计数据结构→生成页面→写交互逻辑→验证产物→修复问题的完整闭环。对一个不会写代码的产品经理、运营、甚至区域店长来说这意味着他们第一次可以把自己脑中的需求直接变成能用的工具。三、Vibe Coding 与传统开发的本质区别把 Vibe Coding 与传统编程并排对比差异就非常清晰了。传统编程的流程是理解需求 → 设计架构 → 写代码 → 调试 → 修改代码。开发者是信息的加工者每一步都需要亲自执行代码是唯一的事实来源。Vibe Coding 的流程则变成描述需求 → AI 写代码 → 看结果 → 提修改意见 → AI 继续改。开发者从加工者变成指挥者验收者把大量具体实现交给 AI自己专注于定义什么是正确的。这个转变带来的效率提升是显著的——原型的构建速度可以提升数倍一个人能完成过去一个团队才能做到的事。但转变也伴随着新的风险其中最大的一条是AI 对项目上下文的理解是短期的。它不像人类工程师那样长期稳定地记住整个项目的来龙去脉每次生成都依赖你当下提供的上下文。如果上下文没管理好就会出现这次改对了下次又改歪今天补了个功能明天又打破旧约束的问题。因此Vibe Coding 真正的关键技能从写代码转移到了管理上下文——而这正是本文后半部分要重点展开的工程实践。四、Vibe Coding 的黄金实践把需求喂给 AI把需求清晰地传达给 AI是 Vibe Coding 的第一个关键技能。很多失败的 Vibe Coding 项目根源都是需求表达出了问题——要么只描述了局部要么没有告诉 AI 最终目标结果 AI 把局部问题当成了需求本身做出完全跑偏的东西。我在实践中总结出几个有效方法。第一先讲目标再讲步骤。直接告诉 AI我最终要达成什么而不是只描述这一步怎么做。只给局部指令AI 会老老实实做局部却看不到全局——你做一个爬虫任务如果只说帮我抓取文章 URLAI 可能给你一个笨重而复杂的实现如果你说明我要批量抓取几十篇文章做文本分析要轻量可靠AI 就会选择更合理的方案。第二用计划书对齐需求。在让 AI 动手写码之前先让它输出一份实现计划功能拆解、数据结构设计、页面规划、各模块之间如何联动。这份计划既是 AI 理解需求的对齐产物也是你验收后续工作的基准。需求对齐再动手远比写了一半才发现跑偏来得高效。第三分步推进逐步收拢。一次会话不要塞进过多需求把大任务拆成小步骤每步验证后再推进下一步。AI 的上下文有限塞得越多遗忘和跑偏的概率越大。第四把验收标准写进指令。明确告诉 AI完成的标准是什么——比如这个功能要能在 Chrome 里正常操作“数据要能正确落库”。有验收标准的任务AI 会更自觉地完成闭环验证而不是看起来像那么回事。五、Vibe Coding 的黄金实践文档比代码更重要如果说需求传达是 Vibe Coding 的输入质量那么文档管理就是它的系统稳定性。在 AI 参与开发之后代码不再天然是项目的唯一事实来源——因为 AI 每次生成都依赖你提供的上下文而那些需求、约束、已有实现、命名规则、历史决策如果不写进文档就都是不可继承的隐性知识。这带来一个反直觉但极其重要的结论在 Vibe Coding 里唯一真正重要的事情是管理好文档。代码描述的是系统现在是什么文档描述的才是系统为什么是这样、接下来应该怎么继续——后者恰恰是 AI 每次接手项目时最需要的东西。实践中有几类文档尤为关键项目说明文档README项目定位、技术栈、目录结构、如何运行让 AI 第一次接手时能快速建立全局认知。需求与决策记录关键需求、技术选型、踩过的坑、被否掉的方案避免 AI 重复犯同样的错误。接口与数据结构说明各个模块的输入输出、数据模型这是 AI 跨文件修改时不破坏一致性的保障。运行与验证指南如何启动、如何测试、验收标准是什么让 AI 能自我验证而不是写完拉倒。把文档当作产品的上下文形态来维护每次改动都同步更新相关文档Vibe Coding 项目的可维护性会得到质变。很多人以为模型不稳定是 Vibe Coding 的核心痛点其实更常见的原因是上下文没有被产品化——文档没管好模型当然记不住。六、Vibe Coding 的黄金实践验证闭环与产物验收Vibe Coding 的第三个关键技能是验证。AI 生成的代码能不能跑、跑得对不对不能靠AI 说没问题来确认要靠真实的验证闭环。一个成熟的 AI 编程工作流应当要求 AI 具备自证能力写完代码后运行测试、启动服务、通过浏览器或其他工具在真实环境里操作一遍确认产物符合预期发现问题时回溯修改再次验证形成闭环。如果 AI 工具不具备这种能力开发者就要主动承担验收——小到跑通关键用例大到端到端走一遍核心流程。在验收环节我特别想提醒一个易被忽略的点不要只看能不能跑要看跑得对不对。AI 生成的代码很容易陷入能运行但逻辑错误的状态——页面能打开但数据不对接口能返回但业务逻辑错了。因此验收不能停留在没报错而要对照需求逐项核对行为是否符合预期。这也再次印证了需求阶段写清验收标准的重要性。七、Vibe Coding 的边界与风险理性看待这个范式效率再高Vibe Coding 也有清晰的边界和风险理性看待这些才能用对这个工具。第一复杂度墙。Vibe Coding 非常适合原型构建和小型应用但当项目复杂度上升到一定程度——涉及复杂的并发、安全、合规、性能要求时纯对话式开发的不可控性会成为瓶颈。AI 能高效生成代码但它对大型系统的架构一致性、全局约束的把控仍是短板。第二知识盲区。AI 生成的代码可能在表面上看没问题但在安全、性能、边界条件上埋着隐患。对非专业开发者来说这些隐患更难被察觉。涉及生产环境、真实交易、敏感数据的项目专业人工审查仍然不可替代。第三上下文失真。这是 Vibe Coding 最普遍的风险来源。项目越大、时间越长AI 对项目上下文的记忆越容易失真改着改着就偏离了项目的真实约束。对抗手段就是前文说的——文档管理 明确验收 分步推进。第四责任边界。当代码大量由 AI 生成出了问题谁来负责、如何追溯是团队和组织层面必须回答的问题。这在合规要求高的行业尤为敏感。八、结语从会不会写代码到会不会指挥 AIVibe Coding 改变的不只是写代码的方式更是开发者角色的重新定义从亲自实现一切转向定义目标、管理上下文、把关质量。在这个新范式里最有价值的技能不再是记住 API 和语法而是需求拆解能力、上下文管理能力、验收判断能力——这些能力决定了你能不能把 AI 这个强大的司机正确地带到目的地。对于正在拥抱 Vibe Coding 的团队我的建议是先用它把开发流程的原型阶段效率提起来同时在团队层面建立文档规范、验证流程和质量底线。Vibe Coding 不是让工程师失业的威胁而是把工程师从重复劳动中解放出来、让他们把精力放在更高价值判断上的机会。能不能抓住这个机会取决于你能不能完成从代码的执行者到代码的指挥者的认知升级。Markdown编辑器所展示的欢迎页。如果你想学习如何使用Markdown编辑器, 可以仔细阅读这篇文章了解一下Markdown的基本语法知识。新的改变我们对Markdown编辑器进行了一些功能拓展与语法支持除了标准的Markdown编辑器功能我们增加了如下几点新功能帮助你用它写博客全新的界面设计将会带来全新的写作体验在创作中心设置你喜爱的代码高亮样式Markdown将代码片显示选择的高亮样式进行展示增加了图片拖拽功能你可以将本地的图片直接拖拽到编辑区域直接展示全新的KaTeX数学公式语法增加了支持甘特图的mermaid语法1功能增加了多屏幕编辑Markdown文章功能增加了焦点写作模式、预览模式、简洁写作模式、左右区域同步滚轮设置等功能功能按钮位于编辑区域与预览区域中间增加了检查列表功能。功能快捷键撤销Ctrl/CommandZ重做Ctrl/CommandY加粗Ctrl/CommandB斜体Ctrl/CommandI标题Ctrl/CommandShiftH无序列表Ctrl/CommandShiftU有序列表Ctrl/CommandShiftO检查列表Ctrl/CommandShiftC插入代码Ctrl/CommandShiftK插入链接Ctrl/CommandShiftL插入图片Ctrl/CommandShiftG查找Ctrl/CommandF替换Ctrl/CommandG合理的创建标题有助于目录的生成直接输入1次#并按下space后将生成1级标题。输入2次#并按下space后将生成2级标题。以此类推我们支持6级标题。有助于使用TOC语法后生成一个完美的目录。如何改变文本的样式强调文本强调文本加粗文本加粗文本标记文本删除文本引用文本H2O is是液体。210运算结果是 1024.插入链接与图片链接: link.图片:带尺寸的图片:居中的图片:居中并且带尺寸的图片:当然我们为了让用户更加便捷我们增加了图片拖拽功能。如何插入一段漂亮的代码片去博客设置页面选择一款你喜欢的代码片高亮样式下面展示同样高亮的代码片.// An highlighted blockvarfoobar;生成一个适合你的列表项目项目项目项目1项目2项目3计划任务完成任务创建一个表格一个简单的表格是这么创建的项目Value电脑$1600手机$12导管$1设定内容居中、居左、居右使用:---------:居中使用:----------居左使用----------:居右第一列第二列第三列第一列文本居中第二列文本居右第三列文本居左SmartyPantsSmartyPants 是一个文本转换工具主要功能是将普通的 ASCII 标点符号自动转换为更美观的印刷体标点符号。例如原始符号转换后说明引号“引号”直引号变弯引号单引号‘单引号’直单引号变弯单引号--–两个连字符变短破折号---—三个连字符变长破折号...…三个点变省略号创建一个自定义列表MarkdownText-to-HTMLconversion toolAuthorsJohnLuke如何创建一个注脚一个具有注脚的文本。2注释也是必不可少的Markdown将文本转换为HTML。KaTeX数学公式您可以使用渲染LaTeX数学表达式 KaTeX:Gamma公式展示Γ ( n ) ( n − 1 ) ! ∀ n ∈ N \Gamma(n) (n-1)!\quad\forall n\in\mathbb NΓ(n)(n−1)!∀n∈N是通过欧拉积分Γ ( z ) ∫ 0 ∞ t z − 1 e − t d t . \Gamma(z) \int_0^\infty t^{z-1}e^{-t}dt\,.Γ(z)∫0∞tz−1e−tdt.你可以找到更多关于的信息LaTeX数学表达式here.新的甘特图功能丰富你的文章2014-01-072014-01-092014-01-112014-01-132014-01-152014-01-172014-01-192014-01-21已完成进行中计划一计划二现有任务Adding GANTT diagram functionality to mermaid关于甘特图语法参考 这儿,UML图表可以使用UML图表进行渲染例如下面产生的一个序列图王五李四张三王五李四张三李四想了很长时间, 文字太长了不适合放在一行.你好李四, 最近怎么样?你最近怎么样王五我很好谢谢!我很好谢谢!打量着王五...很好... 王五, 你怎么样?关于UML图表语法参考 这儿,流程图链接长方形圆圆角长方形菱形关于Mermaid语法参考 这儿,FLowchart流程图我们依旧会支持flowchart.js的流程图语法Created with Raphaël 2.3.0开始我的操作确认结束yesno关于Flowchart流程图语法参考 这儿.导出与导入导出如果你想尝试使用此编辑器, 你可以在此篇文章任意编辑。当你完成了一篇文章的写作, 在上方工具栏找到文章导出生成一个.md文件或者.html文件进行本地保存。导入如果你想加载一篇你写过的.md文件在上方工具栏可以选择导入功能进行对应扩展名的文件导入继续你的创作。mermaid语法说明 ↩︎注脚的解释 ↩︎ Vibe Coding 开发工作流：从“人写代码“到“人指挥代码“的工程化实践
这里写自定义目录标题欢迎使用Markdown编辑器一、Vibe Coding 到底是什么又改变了什么二、为什么 Vibe Coding 会突然流行起来三、Vibe Coding 与传统开发的本质区别四、Vibe Coding 的黄金实践把需求喂给 AI五、Vibe Coding 的黄金实践文档比代码更重要六、Vibe Coding 的黄金实践验证闭环与产物验收七、Vibe Coding 的边界与风险理性看待这个范式八、结语从会不会写代码到会不会指挥 AI新的改变功能快捷键合理的创建标题有助于目录的生成如何改变文本的样式插入链接与图片如何插入一段漂亮的代码片生成一个适合你的列表创建一个表格设定内容居中、居左、居右SmartyPants创建一个自定义列表如何创建一个注脚注释也是必不可少的KaTeX数学公式新的甘特图功能丰富你的文章UML图表流程图FLowchart流程图导出与导入导出导入欢迎使用Markdown编辑器你好 这是你第一次使用# Vibe Coding 开发工作流从人写代码到人指挥代码的工程化实践一、Vibe Coding 到底是什么又改变了什么Vibe Coding 这个词由 Andrej Karpathy 在 2025 年提出迅速成为 AI 编程领域最热门的概念之一。它的核心形态可以概括为用自然语言描述需求让 AI 帮你生成、修改和调试代码并通过对话不断把产品做出来。但很多人对 Vibe Coding 的理解停留在表面——以为它只是AI 帮你写代码或者不用写代码了。这其实是两个误读。第一Vibe Coding 并不意味着没有代码代码依然存在改变的是人和代码的交互方式过去你需要告诉电脑具体执行什么代码现在你更多是告诉 AI 你最终想要什么结果。第二它也绝不意味着开发者可以躺平恰恰相反它对开发者的需求拆解能力、上下文管理能力、验收判断能力提出了更高要求。用一个类比来理解传统编程像是自己开车每个动作都由你操控Vibe Coding 则更像是雇佣了一位能力很强的司机——你负责指路、把关方向、在关键路口做决策司机负责具体的驾驶操作。司机的水平固然重要但最终能不能顺利到达目的地很大程度上取决于你这个导航做得好不好。二、为什么 Vibe Coding 会突然流行起来Vibe Coding 的流行不是偶然它背后是 AI 编程工具能力的几次明显跃迁。最早期的 AI 编程工具本质是AI 帮你补全代码——开发者写上下文工具预测下一行。此时 AI 还是纯粹的辅助工具架构、文件、流程都由人掌控。第二阶段工具进化到AI 帮你改项目——人可以提出增加一个登录功能“把这个页面改成响应式”AI 能跨文件修改代码。到了第三阶段工具开始逼近AI 帮你完成任务——它能理解代码仓库、规划开发任务、自己写代码、跑测试、甚至通过浏览器操作真实环境验证产物完成长程任务。正是这种能力跃迁让用对话写软件从概念变成了现实。现在的 AI 编程助手不仅能生成代码还能自主完成创建项目→设计数据结构→生成页面→写交互逻辑→验证产物→修复问题的完整闭环。对一个不会写代码的产品经理、运营、甚至区域店长来说这意味着他们第一次可以把自己脑中的需求直接变成能用的工具。三、Vibe Coding 与传统开发的本质区别把 Vibe Coding 与传统编程并排对比差异就非常清晰了。传统编程的流程是理解需求 → 设计架构 → 写代码 → 调试 → 修改代码。开发者是信息的加工者每一步都需要亲自执行代码是唯一的事实来源。Vibe Coding 的流程则变成描述需求 → AI 写代码 → 看结果 → 提修改意见 → AI 继续改。开发者从加工者变成指挥者验收者把大量具体实现交给 AI自己专注于定义什么是正确的。这个转变带来的效率提升是显著的——原型的构建速度可以提升数倍一个人能完成过去一个团队才能做到的事。但转变也伴随着新的风险其中最大的一条是AI 对项目上下文的理解是短期的。它不像人类工程师那样长期稳定地记住整个项目的来龙去脉每次生成都依赖你当下提供的上下文。如果上下文没管理好就会出现这次改对了下次又改歪今天补了个功能明天又打破旧约束的问题。因此Vibe Coding 真正的关键技能从写代码转移到了管理上下文——而这正是本文后半部分要重点展开的工程实践。四、Vibe Coding 的黄金实践把需求喂给 AI把需求清晰地传达给 AI是 Vibe Coding 的第一个关键技能。很多失败的 Vibe Coding 项目根源都是需求表达出了问题——要么只描述了局部要么没有告诉 AI 最终目标结果 AI 把局部问题当成了需求本身做出完全跑偏的东西。我在实践中总结出几个有效方法。第一先讲目标再讲步骤。直接告诉 AI我最终要达成什么而不是只描述这一步怎么做。只给局部指令AI 会老老实实做局部却看不到全局——你做一个爬虫任务如果只说帮我抓取文章 URLAI 可能给你一个笨重而复杂的实现如果你说明我要批量抓取几十篇文章做文本分析要轻量可靠AI 就会选择更合理的方案。第二用计划书对齐需求。在让 AI 动手写码之前先让它输出一份实现计划功能拆解、数据结构设计、页面规划、各模块之间如何联动。这份计划既是 AI 理解需求的对齐产物也是你验收后续工作的基准。需求对齐再动手远比写了一半才发现跑偏来得高效。第三分步推进逐步收拢。一次会话不要塞进过多需求把大任务拆成小步骤每步验证后再推进下一步。AI 的上下文有限塞得越多遗忘和跑偏的概率越大。第四把验收标准写进指令。明确告诉 AI完成的标准是什么——比如这个功能要能在 Chrome 里正常操作“数据要能正确落库”。有验收标准的任务AI 会更自觉地完成闭环验证而不是看起来像那么回事。五、Vibe Coding 的黄金实践文档比代码更重要如果说需求传达是 Vibe Coding 的输入质量那么文档管理就是它的系统稳定性。在 AI 参与开发之后代码不再天然是项目的唯一事实来源——因为 AI 每次生成都依赖你提供的上下文而那些需求、约束、已有实现、命名规则、历史决策如果不写进文档就都是不可继承的隐性知识。这带来一个反直觉但极其重要的结论在 Vibe Coding 里唯一真正重要的事情是管理好文档。代码描述的是系统现在是什么文档描述的才是系统为什么是这样、接下来应该怎么继续——后者恰恰是 AI 每次接手项目时最需要的东西。实践中有几类文档尤为关键项目说明文档README项目定位、技术栈、目录结构、如何运行让 AI 第一次接手时能快速建立全局认知。需求与决策记录关键需求、技术选型、踩过的坑、被否掉的方案避免 AI 重复犯同样的错误。接口与数据结构说明各个模块的输入输出、数据模型这是 AI 跨文件修改时不破坏一致性的保障。运行与验证指南如何启动、如何测试、验收标准是什么让 AI 能自我验证而不是写完拉倒。把文档当作产品的上下文形态来维护每次改动都同步更新相关文档Vibe Coding 项目的可维护性会得到质变。很多人以为模型不稳定是 Vibe Coding 的核心痛点其实更常见的原因是上下文没有被产品化——文档没管好模型当然记不住。六、Vibe Coding 的黄金实践验证闭环与产物验收Vibe Coding 的第三个关键技能是验证。AI 生成的代码能不能跑、跑得对不对不能靠AI 说没问题来确认要靠真实的验证闭环。一个成熟的 AI 编程工作流应当要求 AI 具备自证能力写完代码后运行测试、启动服务、通过浏览器或其他工具在真实环境里操作一遍确认产物符合预期发现问题时回溯修改再次验证形成闭环。如果 AI 工具不具备这种能力开发者就要主动承担验收——小到跑通关键用例大到端到端走一遍核心流程。在验收环节我特别想提醒一个易被忽略的点不要只看能不能跑要看跑得对不对。AI 生成的代码很容易陷入能运行但逻辑错误的状态——页面能打开但数据不对接口能返回但业务逻辑错了。因此验收不能停留在没报错而要对照需求逐项核对行为是否符合预期。这也再次印证了需求阶段写清验收标准的重要性。七、Vibe Coding 的边界与风险理性看待这个范式效率再高Vibe Coding 也有清晰的边界和风险理性看待这些才能用对这个工具。第一复杂度墙。Vibe Coding 非常适合原型构建和小型应用但当项目复杂度上升到一定程度——涉及复杂的并发、安全、合规、性能要求时纯对话式开发的不可控性会成为瓶颈。AI 能高效生成代码但它对大型系统的架构一致性、全局约束的把控仍是短板。第二知识盲区。AI 生成的代码可能在表面上看没问题但在安全、性能、边界条件上埋着隐患。对非专业开发者来说这些隐患更难被察觉。涉及生产环境、真实交易、敏感数据的项目专业人工审查仍然不可替代。第三上下文失真。这是 Vibe Coding 最普遍的风险来源。项目越大、时间越长AI 对项目上下文的记忆越容易失真改着改着就偏离了项目的真实约束。对抗手段就是前文说的——文档管理 明确验收 分步推进。第四责任边界。当代码大量由 AI 生成出了问题谁来负责、如何追溯是团队和组织层面必须回答的问题。这在合规要求高的行业尤为敏感。八、结语从会不会写代码到会不会指挥 AIVibe Coding 改变的不只是写代码的方式更是开发者角色的重新定义从亲自实现一切转向定义目标、管理上下文、把关质量。在这个新范式里最有价值的技能不再是记住 API 和语法而是需求拆解能力、上下文管理能力、验收判断能力——这些能力决定了你能不能把 AI 这个强大的司机正确地带到目的地。对于正在拥抱 Vibe Coding 的团队我的建议是先用它把开发流程的原型阶段效率提起来同时在团队层面建立文档规范、验证流程和质量底线。Vibe Coding 不是让工程师失业的威胁而是把工程师从重复劳动中解放出来、让他们把精力放在更高价值判断上的机会。能不能抓住这个机会取决于你能不能完成从代码的执行者到代码的指挥者的认知升级。Markdown编辑器所展示的欢迎页。如果你想学习如何使用Markdown编辑器, 可以仔细阅读这篇文章了解一下Markdown的基本语法知识。新的改变我们对Markdown编辑器进行了一些功能拓展与语法支持除了标准的Markdown编辑器功能我们增加了如下几点新功能帮助你用它写博客全新的界面设计将会带来全新的写作体验在创作中心设置你喜爱的代码高亮样式Markdown将代码片显示选择的高亮样式进行展示增加了图片拖拽功能你可以将本地的图片直接拖拽到编辑区域直接展示全新的KaTeX数学公式语法增加了支持甘特图的mermaid语法1功能增加了多屏幕编辑Markdown文章功能增加了焦点写作模式、预览模式、简洁写作模式、左右区域同步滚轮设置等功能功能按钮位于编辑区域与预览区域中间增加了检查列表功能。功能快捷键撤销Ctrl/CommandZ重做Ctrl/CommandY加粗Ctrl/CommandB斜体Ctrl/CommandI标题Ctrl/CommandShiftH无序列表Ctrl/CommandShiftU有序列表Ctrl/CommandShiftO检查列表Ctrl/CommandShiftC插入代码Ctrl/CommandShiftK插入链接Ctrl/CommandShiftL插入图片Ctrl/CommandShiftG查找Ctrl/CommandF替换Ctrl/CommandG合理的创建标题有助于目录的生成直接输入1次#并按下space后将生成1级标题。输入2次#并按下space后将生成2级标题。以此类推我们支持6级标题。有助于使用TOC语法后生成一个完美的目录。如何改变文本的样式强调文本强调文本加粗文本加粗文本标记文本删除文本引用文本H2O is是液体。210运算结果是 1024.插入链接与图片链接: link.图片:带尺寸的图片:居中的图片:居中并且带尺寸的图片:当然我们为了让用户更加便捷我们增加了图片拖拽功能。如何插入一段漂亮的代码片去博客设置页面选择一款你喜欢的代码片高亮样式下面展示同样高亮的代码片.// An highlighted blockvarfoobar;生成一个适合你的列表项目项目项目项目1项目2项目3计划任务完成任务创建一个表格一个简单的表格是这么创建的项目Value电脑$1600手机$12导管$1设定内容居中、居左、居右使用:---------:居中使用:----------居左使用----------:居右第一列第二列第三列第一列文本居中第二列文本居右第三列文本居左SmartyPantsSmartyPants 是一个文本转换工具主要功能是将普通的 ASCII 标点符号自动转换为更美观的印刷体标点符号。例如原始符号转换后说明引号“引号”直引号变弯引号单引号‘单引号’直单引号变弯单引号--–两个连字符变短破折号---—三个连字符变长破折号...…三个点变省略号创建一个自定义列表MarkdownText-to-HTMLconversion toolAuthorsJohnLuke如何创建一个注脚一个具有注脚的文本。2注释也是必不可少的Markdown将文本转换为HTML。KaTeX数学公式您可以使用渲染LaTeX数学表达式 KaTeX:Gamma公式展示Γ ( n ) ( n − 1 ) ! ∀ n ∈ N \Gamma(n) (n-1)!\quad\forall n\in\mathbb NΓ(n)(n−1)!∀n∈N是通过欧拉积分Γ ( z ) ∫ 0 ∞ t z − 1 e − t d t . \Gamma(z) \int_0^\infty t^{z-1}e^{-t}dt\,.Γ(z)∫0∞tz−1e−tdt.你可以找到更多关于的信息LaTeX数学表达式here.新的甘特图功能丰富你的文章2014-01-072014-01-092014-01-112014-01-132014-01-152014-01-172014-01-192014-01-21已完成进行中计划一计划二现有任务Adding GANTT diagram functionality to mermaid关于甘特图语法参考 这儿,UML图表可以使用UML图表进行渲染例如下面产生的一个序列图王五李四张三王五李四张三李四想了很长时间, 文字太长了不适合放在一行.你好李四, 最近怎么样?你最近怎么样王五我很好谢谢!我很好谢谢!打量着王五...很好... 王五, 你怎么样?关于UML图表语法参考 这儿,流程图链接长方形圆圆角长方形菱形关于Mermaid语法参考 这儿,FLowchart流程图我们依旧会支持flowchart.js的流程图语法Created with Raphaël 2.3.0开始我的操作确认结束yesno关于Flowchart流程图语法参考 这儿.导出与导入导出如果你想尝试使用此编辑器, 你可以在此篇文章任意编辑。当你完成了一篇文章的写作, 在上方工具栏找到文章导出生成一个.md文件或者.html文件进行本地保存。导入如果你想加载一篇你写过的.md文件在上方工具栏可以选择导入功能进行对应扩展名的文件导入继续你的创作。mermaid语法说明 ↩︎注脚的解释 ↩︎