Markdown 毁誉参半。
有人觉得它写起来方便，生成和控制又容易，好用。
有人觉得它一边写标记干扰思路，标准又不统一，困扰。
我想了解一下 Ruby 圈的想法，如果你用来写技术文档，你希望它是 Markdown 的编辑器，还是所见即所得的那种，或者你觉得有其他更好的方案？
如果能忍住整篇文章打完再排版的话，所见即所得。 如果不能，还是得要即时标记。
我觉得乱打一通后再去慢慢编辑才是正确的，而且效率应该会更高。也就是输出和编辑要分开才对。 但是我想很多人都是想一次过的，然后手离开键盘去用鼠标又非常麻烦。
PS. 我想我会去尝试改变这个习惯，改成输出后再去编辑。
两者都不是很好的选择。但如果必须选一个，我偏好 Markdown。不用太费神去调整格式，写起来直观，所有内容都是可见的，所以修改起来也方便，尤其是链接。
但是 Markdown 受限于编辑器，显示效果太朴素。这是所见即所得编辑器的优势。如果有一个编辑器能够同时做到编辑的易用性和功能的丰富性，估计会少很多纠结。可惜就算是目前体验最好的 medium 也只做到了前者，没完全达到后者。
@kgen 同意楼上的，主要是跟现有的所见即所得编辑器比起来，markdown 更能接受一些，虽然两者都不是很让人满意，所以我现在也在用 rei 提到的 AsciiDoc，但是像你说的要面向技术圈的广大受众，那还是 markdown 更适合一些，毕竟愿意尝试新东西的人还是少数
我用 PlainSite 是直接写 HTML。如果只是生成 p、em、a、blockquote 这类标签，写 HTML 也没什么压力。如果要自定义格式，Markdown 又不够用，比如表格，还得上 HTML。而且，若我要在超连接中插图片和加粗文字，那格式写起来一点没 HTML 好。
——好吧，只是因为我以前是画网页的写 HTML 写多了。
不过有时我是用 WYSIWYG 编辑器将文章大体写好，再手动转换成 HTML 稍调格式发布。
看楼上的众多评论，有了些（还不成熟的）想法：
- 无论是哪种编辑器最终的产出物都是 HTML（这决定了它的存在范围，如果是做其他用处比如印刷出版就没意义了，或者要加上更多需要考虑的要素了），从这个意义上来讲，是否有更好的编写 HTML 的方式？如果有，那么就消除了标签对应关系的烦恼，你唯一要学的就是 HTML 而已（这一点符合技术圈的广大受众，但不符合超出技术圈的），并且不是要很精通 HTML，因为目标是不需要考虑结构，全部是流水式的（除了个别复杂的排版需求，比如表格，嵌套式列表等）。
我是这样想的，其实 Markdown 能实现的，HTML 都可以做得更好。不能直接用 HTML 的原因可能很多，比如：
- 标签有特定格式，总是打
<>让人受不了——但是像 emmet 这样的工具可以解决此类问题； - 标签与内容会出现歧义，必须有方式来区别标签和标签的字面意义——Haml Jade 这类的工具都有类似的解决方法；
- 最麻烦的是，HTML 是结构化的文档，必须遵守一些嵌套的规则——这才是 Markdown 之流最大的意义，即破除结构化（其实也不完全，比如嵌套式列表还得靠缩进吧，当然嵌套式列表本身看起来就是缩进的，所以也还说得过去）；
- 除了标签之外，更讨厌的是属性，谁记得住那么多。还好，文档写作几乎不需要什么属性来辅助，最最常用的无非就是超文本的内容，链接 图片 等等；我不知道有什么特别好的替代方案，Markdown 本身还可以吧，但需要学，它和 HTML 不一样。
- 等等我一下子没想到的问题
如果基于 Markdown 但是不需要改变标签（不用学新标签和 HTML 的对应关系），换言之 Markdown 有办法能识别所有的 HTML 标签且无需改动它们，可以支持像 emmet 那样快捷生成片段（不用全部功能，有一些很方便，比如嵌套式标签，而且这个都不太重要），加上 Markdown 本身无结构化的特性，内容的写作方面我觉得足够了。
wysiwyg 永远解决不了的问题就是你无法只用键盘完成所有的操作。你说快捷键？如果功能多了呢？如果和操作环境冲突呢？你不是还得要去记？再说快捷键不能解决所有问题，比如说插入一个链接，快捷键要么先让你处理 placeholder，要么先让你处理 link，可我有的时候就是忘了这个顺序导致不得不复制/粘贴好几次，总是无法一步到位。
还有 wysiwyg 对于结构的解释是依赖于编辑器本身的处理逻辑的，作者无法精确控制，有时候不得不用 hack 的方式来达到一些目的，这也是它的缺陷之一。总之 wysiwyg 是预先定义的规则下的写作，而不是自由写作，如果不考虑 HTML 自身的限制，它才是自由写作（当然，浏览器决定了 HTML 的规则，但这已经是极限，无法要求更多）。
- 在呈现上，也就是好看与否，因 HTML 的缘故，也就限定给 CSS 了。然而这一点几乎不受编辑者控制，特别是 markdown；wysiwyg 稍微好一些，但也不过是提供了预置的样式让你可以看得见，若是想自己完全控制那就要进入代码模式，也就等于 !wysiwyg 了。然而这一点没啥好的解决办法，你总不能再提供一个自定义 CSS 吧，那就不是写作而是页面开发了……如果做一个产品，做到两点就够了：
- 提供足够好的输出设计，就像 medium 那样，大部分人都满意就足够了；
- 在此基础上，提供自定义模板和预置模板，满足一部分人不折腾不舒服斯基的习惯就好了；
除此之外，夫复何求？
- 功能方面，其实第一点就已经决定了，不管是 Markdown 也好 asciidoc 也罢，又或者是预想中的新工具，全都是孙猴子，最终逃不过 HTML 的五指山。所以功能的上限已经是决定了的，无非就是实现一套描述这些功能的规则，其代价有多大而已。解决了第一点的问题，这个就迎刃而解——我都和 HTML 一比一无缝对接了，你还要啥自行车？
当然了，我们还有 JavaScript。但和 CSS 一样，这是不需要由作者掌控的范畴，可以用外挂的形式往上加，不过这是最后最后才需要去考虑的问题，锦上添花而已。
说到这，觉得自己说的都是废话，第一点里提到的不信别人没想过。大概 HTML 真的没法再简单了吧。
html 也只是一种格式化标记语言而已，很多写作语言还可以有 docbook, latex, postscript 等等面向不同终端和功能需求的格式化输出方式
markdown 和 asciidoc 本身语法就具备了部分 "所见即所得" 的特点，和 html 所见不知是啥是有很大区别的
html 没有指定语法是 ruby, 就高亮一段代码的能力，也没有给一段 dot 代码，就给你画出图的能力，能力并不是 markdown 和 asciidoc 等的超集，而是各有专长。
@kgen 功能的丰富性这点是相对而言的。我一直认为面向普通写作者的写作平台和面向程序员的写作平台是有点区别的。国外的 medium 和国内的简书在普通写作者的写作平台方面已经做得挺好了。但程序员会有些特殊要求，比如我个人：
- 代码高亮，这是基本的。
- 嵌入 jsfiddle, jsbin 等做代码示例。
- 偶尔使用表格。
这两点在使用 octopress 或者 jekyll 定制的时候并不麻烦，对第三方写作平台而言应该也不是麻烦事情，但支持这些功能的往往是写作和展示分开的，大部分就是 markdown 写作，再切换到 view 模式查看。支持所见即所得的平台比如 medium 似乎还不支持我说的第二点（如果说错了欢迎有人告知）。因为这需要从体验上去下功夫，本来就不是件很容易的事情。而且做出来还不见得被目标用户（程序员）买账，因为程序员本来就是不怕折腾甚至喜欢折腾的群体。
@kgen 至于所见即所得的偏好，我前段时间尝试过几个平台，jekyll, ghost, medium 之后，最偏好 medium 的做法。那种流畅的感觉体验过就回不去了的。
相比所见即所得的平台或编辑器，markdown 在保持简单的同时能做更多的我需要的事情，但不代表喜欢，只是因为没有更好的选择。
#42 楼 @darkbaby123 你提到的代码高亮，嵌入 jsfiddle 我理解，但是偶尔使用表格这一点，相比于 markdown 默认提供的表格语法，你希望有什么功能或 UI 增强？
@kgen Markdown 的 table 语法足够用了，但对齐比较麻烦（少数用到的情况我都是用 Vim 对齐的）；所见即所的编辑器不知道有没有支持的。毕竟对大多数人来说这是个比较少用到的功能。
使用类似与 vi 或者 emacs 的用户必然选择 markdown 或者类似的 org。鼠标会打断节奏～所有东西都是文本，也方便使用 ack 或者 grep 搜索。
Markdown 的所见即所得编辑器有两种：
- 原文编辑，实时预览
- 不抹除标记的情况下，给原文上格式
跟真正的所见即所得编辑器相比，在阅读体验方便还是弱一些，当然编辑体验肯定是强的。