一个用户的九条留言：为什么「用户提的需求」比「自己的想法」难做

10 月 3 日，一位用户在我的项目 YiziMarkdown 的 issue 里贴了一行示例：演示模式里，一行过长的行内代码被截断了。顺手TA还说了一句，「演示模式是你做的最有特色的功能」。

我很开心这位用户的认可，并在上周的v0.3.3中，专门修复了TA提到的bug，增加了TA提出的演示分栏、字体字号、填充宽度之类的功能需求。

到 10 月 18 日，这条 issue 下面已经有了九条留言：字号、代码块字号、导出 PDF 的字体、导出 Word 的列表符号、垂直对齐、能不能按演示布局导出……中间还夹着一句：「收起格式工具栏的功能，只要窗口大小改变又会展开，标题栏无法双击最大化，这个算不算 bug？」

说实话，有用户这么用心的用你的产品，而且对你的产品进行反馈，作为一名vebicoding开发者，是非常荣幸的。

我回TA「好的，我看一下。不好意思，最近几天项目上太忙了，没来得及调整」。那句话不是抱怨，是很正常的一句追问，但它提醒了我 issue 的另一半成本：它会在你的计划之外，持续产生期待。

这一版我前后做了两三天。累的地方不在代码。

为什么「用户提的需求」比「自己的想法」难

如果是自己想做的功能，流程很简单：想到哪，改到哪，改完自己先用一遍，爽，发布。

用户提的需求，第一个动作不是打开agent，而是思考：这是TA有共鸣的共性需求，还是只有TA一个人会遇到的情况？该不该做？如果做，做到哪一步算够？

这里有个容易被误解的地方：不是「别人想到了一个你没想到的需求，你就会很开心地开始开发」。真实的心态往往是审慎、犹豫，甚至有时候会有那么一点点抗拒——因为你要为一个不是自己提的东西，投入时间，还接下长期的维护责任。

而用户通常会直接给出方案：TA说想要类似 moonslide 的分栏，想要把演示导出成 PPT。你要判断的从来不是那个方案，而是方案背后的诉求。

同一个星期里，四种处理方式

第一种，看起来是建议，其实是 bug。「收起格式工具栏只要窗口一变又自己展开」「标题栏双击不能最大化」——这些不属于偏好，属于我之前做错了，是bug。所以我做的不是「采纳建议」，而是把它做透：现在有两套收折机制，随窗口自动收折的不带记忆，用户主动收折的会记住；顶栏空白处双击最大化和右键菜单也一并补上。

第二种，是个人偏好。 TA说初始字号 14 或 16 更合适、代码块字号太小。这种事不该我替TA决定——字号设一次就会持久化，所以默认值留着不动，把可调的地方留给人。默认值是给新用户的，偏好是留给老用户的，两件事要分开。

第三种，超出了产品边界，但诉求要接住。 TA提「导出 PPT」，我拒了：这个产品处理的是 markdown 文档，演示是为了让人在不太正式的场合不用碰 PPT 这种东西；逐元素适配也很麻烦。TA补充说其实是想要「导出演示的 PDF」，那就可以研究。至于分栏，TA想要的是一套复杂标记，我给了 ***——不引入新语法，从 markdown 原生语法里去推断布局。更早的一版里，也有人想要标签系统，我也没做，因为YiziMarkdow的定位是文档编辑，不是知识管理。

拒绝一个需求，不等于拒绝那个诉求，中间往往有一条更窄的路。

第四种，暂时不做决定。 垂直对齐的起始高度、演示导出 PDF，我回复的是「还需要评估」「演示功能的边界也需要梳理」。允许自己先不决定，但要把为什么说清楚。

同一周里，TA还报了新的一批问题：导出的 PDF 字体过大、Word 里每行下边距过大、嵌套的无序列表符号不对、代码块多出一行，还有一个「多打一个空格会渲染出两个复选框」。修一个，旁边三个就露出来——这才是这几天最真实的疲惫：不是某一件事难，而是边界一直在移动。

然后我回头问了自己一个问题

如果我用「这是不是共性需求」去审查用户提的东西，那么我自己加的功能、自己定的规则，凭什么过关？

它们本质上也是「一个用户的需求」，只是那个用户刚好是我。

老实说，过不了同样严格的审查。所以我干脆把尺子换了一下：不去问「这是不是所有人都要的」——这个问题永远证明不了，而是问三件事：

不做会不会坏？（会，那是 bug，必须做。） 做了之后，是不是所有人都会顺手一点？（是，那是共性，值得做。） 能不能说清它服务谁、边界在哪、以后谁来维护？（能，那就可以做。）

拿这把尺子量我自己想的东西：把设置里的「关于」改名成「版本与更新」，是因为名字已经不准了；加一个「其TA产品」页签，是因为它只是一张只读列表加几个官方链接，代价和维护都接近零——都过得去。

只有一个没过，恰恰来自我自己的需求。

最后一件我没做的事

想了很久的一件事：在编辑器里加一个「发布」功能，一键把当前文档发到我的个人网站的blog。我花了半天把接口、平台、各种标准都摸了一遍，最后没做——不是技术做不到，是我说服不了自己「它不是只为我」。

要想让别人也能用，就得去接一大堆平台；只服务我自己，就等于在一个给别人用的产品里，开一扇只为我开的门。服务谁？说不清。边界？说不清。维护？长期是我自己的事。它没通过那把尺子。

这是这篇里，我 「拒绝自己」 的例子。

写在最后

那位用户的那条 issue，最后帮我看见了一件我自己看不见的事：有些地方「可优可不优」，我用久了就不觉得。TA那句「这个算不算 bug」，真正有用的地方不是需求，是一面镜子。

我给TA的回复里有一句是真心的：「是您热心的建议，让我对顶栏、格式工具栏，以及各个功能区右键菜单等原本可优可不优的体验，做了精细化的修改。」

这一版功能不多，想得最多。想清楚的过程没有人看见，但它决定了我砍掉什么、留下什么，以及下一次还能不能心安理得地发版。

对用户的需求要审，对自己的需求要审得更狠——因为对自己，你总有办法说服自己。