从公众号划线功能和GitHub的贡献日历，聊聊用户输入输出产品思维
看两个例子。
开发的同学应该很了解了，这图是 GitHub/Gitee 平台上的 ContributionCalendar，贡献日历，可以显示你某日的代码产出情况。
这是公众号的划线功能，它和读书类应用的笔记是一类型的，用于收藏、高亮、分享之类的用途。
仔细看一下这两张图，GitHub 的贡献日历中，有一个“Hi”字符，公众号划线划了“OK”字符。
这两个功能，让我想到一个要命的问题，他们平台在这地方有没有做内容风控呢？他们可以怎样去做呢？
说是“内容风控”，但其实这两处的内容比较抽象，本质上是用户的一种标注操作的可视化结果，用户“将功能利用起来转化为内容”，让静态的文章、日历瞬间具备了用户自定义的内容承载能力。
利用这种机制，可以形成敏感符号、文字、二维码甚至图形，只要平台没考虑过，那它们就可以绕开传统风控体系。
甚至，现在更难受的是，就算平台考虑了这个情况，应对起来也比较麻烦。
动态、合成。 文章发布时是静态文本（乃至图片、视频、音频），可预审，但用户的标注组合是实时渲染的。平台在审核时无法预测用户会如何操作组合，预审因此失效。
表达由用户操作决定。 同一篇文章，通过不同的划线方式可能完全正常，也可能拼出敏感内容。敏感性不再由原文决定，而是由读者的操作决定。
非传统的内容载体、内容类型。 像这种“新形态”的内容承载通道，产生新形态的“内容类型”，你可以说它是文本，也可以说它是图像，难定义就是因为你都不知道什么策略去防控好。并且一般的风控治理逻辑本身也没想过这种内容载体与内容类型。
不可预测与难以量化。 标注的可能组合数量庞大，恶意构造和误用难以通过传统关键词、正则表达式或白名单提前穷举。
用户输入输出产品思维
到这里我们来聊一下这种情况出现风险的本质，其实就是用户输入与输出不仅仅是“文本/图像/音频/视频”。
长期以来，平台的风控策略主要聚焦在文本识别、多媒体识别等传统维度，但我们前边这两个简单的例子其实已经明示了，技术层面，用户的每一次可视化标注，都可能映射为可被视觉识别的形态，比如线条、像素块、遮罩，这些形态可以组合为有意义的表达。
也就是说，平台要面对的不仅是用户的常规内容输入输出，还有用户操作输入输出，这是一个更广义、更动态、难以量化的风险来源。
而传统上，“非内容侧”的用户输入，更多地会去进行“技术上安全”的防护，所以不会那么直接被认为它的本质也是输入与输出。
但一切都是交互，都是输入输出。
一切产品，不管你是怎么思考把它做出来的，底层都是按用户输入输出 IO 模型去堆起来的，虽然产品经理做这个产品的时候都不知道这背后是 IO 模型在发力。
大多数产品经理在做产品时，也并不会从这个模型出发。
几种视角来抽象交互类型：
用户 - 内容，发布文章/图片/视频/音频、阅读、评论、点赞、点踩、收藏、分享、划线……这些都是用户直接对内容的输入输出操作。
用户 - 产品功能，基础 UI/UX 操作、消息通知系统、Push 推送、搜索、功能指导、商店……这些体现了用户与平台功能的交互，虽然不直接生成内容，但同样遵循 IO 模型。
用户 - 用户，私信、关注、问答、内容资源交易、打赏、群聊……这里是社交互动层面的输入输出，构成更复杂的交互网络。
理解了这个模型，你会发现，不管产品看起来多么复杂、多么创新，本质都是在不同类型的 IO 闭环上堆起来的。
同时，你也能够理清楚，当你用 IO 模型从高层去做产品，会得到的什么。
掌控全局。IO 模型把所有交互抽象出来，让你能清楚看到产品大的小的环节，包括内容侧、功能侧、社交侧等的交互情况。你可以有意识地优化每一个输入和输出，而不是零散地迭代功能。
降低风险。传统上，技术侧的风控，安全、运维之类的角色会去进行技术性防御，当产品设计从 IO 模型出发，技术侧和内容侧的风险都可以被系统化控制。你知道每个输入可能产生的输出，能提前设计防护和治理机制，而不是等到问题爆发再去补救。
体系化开脑洞。通过 IO 模型，你可以更大胆地探索新的交互形式，做更有意思的产品，就像开头讲的这两种例子。
同时，在当下大模型时代，因为 IO 模型这种对产品的体系化思维，你可以更好地畅想一下，除了前边提到的“用户-内容” “用户-产品功能”“用户-用户”，现在可以新增“AI-用户”、“AI-内容”、“AI-产品功能”、“AI-AI”交互维度。
这里 AI 我不管你是大模型对话模式还是 Agent 执行模式，又或者只是一些大模型相关中间件，它既可以是内容，也可以不是内容；既可以是用户，也可以不是用户；既可以是产品功能，也可以不是产品功能。
AI 集成了自身的“输入输出”能力和“自主性”，相比人类这种“传统用户”，可以直接设计到产品各个环节，而不仅仅是“产品使用者”。
它释放了太多切入空间。主要看你怎么用，产品怎么做。
但你要思考的是，输入与输出。
