一个不同的主意

　　7月初我回了趟广东，参加高中毕业20周年的同学聚会（是的，我有这么大年纪了）。按之前的想法，从广东回来，就应该恢复阅览室的工作了。

　　工作意外暂停了一段时间，当然不算什么好事。但乐观地想，也可以看成一次打破之前僵局的机会。所以，与其一下子回到阅览室的日常工作，不如利用这次重启，先跳出之前的思路，看看有没有什么不同的路径，可以另辟蹊径实现“认真阅读”。

　　如果你读过过去几期的本专栏，应该也不难猜到，我们想探索一些“认真阅读”和AI的结合。

　　这几个月我虽然没有在全职工作，但脑子没有停下来，积累了不少“认真阅读”和AI结合的主意。这些想法不敢说有多创新，甚至我自己都觉得有些浅显，但的确都是市场上目前还没有别人做出来的，也就无从体验。空口无凭、眼见为实，人类的想象力是很有限的。对于不存在的东西，即使是你自己创造的，等你看到它、体验它的时候，也会发现和自己的想象很不一样。

　　所以，第一步还是要做出来我们自己可以体验的原型产品，看看能不能“眼前一亮”。

　　怎么做出原型呢？我打算自己来写代码。

　　一方面是，过去几个月一直在研究这个领域，对这些主意在技术上如何实现，心里大致有数。再加上对自己的代码能力有一些不切实际的高估，觉得自己应该没有问题。工作启动的第一天，两个小时我就做出来能用的第一个版本了，更让人误以为自己是天才。

　　另一方面，其实对于这些主意来说，原型制作可以被认为是产品设计过程的一部分，而不是开发过程的一部分。上期提到，创新必须同时满足商业可持续性、人的渴求和技术可行性，简单粗暴地理解成产品经理、设计师和工程师各自对应的角色的话，在传统的开发流程中，产品经理先做好产品规划，确定产品要解决什么业务问题；评审通过后再由设计师完成用户体验设计和界面设计；设计稿确定后，才交给工程师开发上线。这样的一个流程倒过来看，相当于是预设，技术上的可行性是无法影响设计决策的，设计也无法影响商业决策。

　　互联网行业已经非常成熟，大多数时候上面这个预设是对的。很多团队中，对工程师的最高评价简单说来是“有求必应”，能很好地实现前序流程的要求，不需要也无法影响前序决策。

　　但AI近半年的发展给产品的技术可行性带来了翻天覆地的变化。很多以前“不可行”的事情，现在一瞬间就变得“可行”了。而且，以目前的发展速度，即使这周还不可行，说不定下周就可行了。“可行性”变成了整个环节中最大的变量。即使只考虑设计和工程，这也意味着两者会变成一个相互影响纠缠的过程，在目前这个阶段中没有谁先谁后的区别。

　　比如，设计师原本想实现的体验，可能工程师会发现做不出来。但工程师在探索过程中发现的新的可行性，说不定又会被设计师慧眼识珠，放到新的场景和交互中。这样子往前不断迭代。摸索的感觉就像在沙滩上捡贝壳一样，无法预先规划。

　　如果沿用传统的工作方式，思路很容易被过去对可行性的认识局限住。现阶段想在AI产品上做出创新和突破，应该使用更激进的方 式。

　　当然，这对团队要求很高，需要设计师、工程师和产品经理非常紧密地沟通。什么样的沟通成本最低呢？不管人和人之间的沟通效率有多高，都没有自己和自己的沟通效率高。所以我想试试自己来写代码搭建原型，之后要进入开发阶段的时候，再请真正的工程师来加入。

　　我本科毕业后加入Google的用户体验团队，名片上印的头衔是“用户体验开发工程师”，是我自己给自己写的。看起来好像很厉害，但其实是藏拙了。

　　有机会加入Google本来就是一件运气非常好的事情。我本科学物理，除了大一的《计算概论》和《算法与数据结构》两门入门课程，学的和软件工程没有什么关系，和设计更不沾边。只是因为一直对媒体、互联网感兴趣，本科期间花了不少课余时间设计制作网站，也因此对如何开发编写网页比较熟悉。那是2006年前后，“用户体验设计”这个概念国内刚刚开始接触到。我印象很深刻，我在Google大堂等面试的时候，还在用大堂的电脑浏览白鸦的blog，他是最早的布道者之一。

　　虽然我经常自称设计师，但我猜想我当时单凭设计能力还是无法加入Google的。至于写代码，这里稍作解释，虽然看起来都是在黑漆漆的界面上敲字母，但“写网页”其实和“编程”没有什么关系，更像是一个手艺活儿，是一种创作方式。感谢当时领导Google中国的开复和美国总部的设计团队，能为个例来定制职位。当时的设想，就是我这样一个角色加入团队，可以帮助其他设计师或者独立完成一些需要制作原型的设计任务。

　　当时Google的用户体验设计团队属于工程部，其实大部分总部的设计师同事也是工程背景的，经常在设计评审上看到的“设计稿”，都已经是可以交互的原型了，而不是静态的设计图。我后来自己负责的设计项目大多数也是用这种方式。

　　比如，当我设计Google拼音输入法某个功能的时候，想设计一种其他输入法都没有做过的、新的交互（和现在许多有AI加持的编辑器做自动补全的体验有些像）。传统的设计方法要交付的是流程图：用户在键盘上敲某个键，下一步会发生什么，一步一步画出来。但对于一个输入法而言，键盘的键那么多，流程的可能分叉数不胜数，都画在一张图上过于复杂不说，对于其他同事来说，看着这样的一张图其实也没有办法想象用户最后的感受。

　　输入法的开发成本很高。我后来的做法，就是在网页上做了一个“假”输入法，大致实现了输入法的基本功能，也将我想要的体验做了出来。对于评估的同事来说，这个原型可以帮助他们直接感受到用户的最终体验。对于工程师同事来说，对着这个去开发“真的输入法”，也更直观一些。当然，这个“假”输入法的所有代码，质量是很差的。它只是设计过程的一部分，用完即弃。

　　我对于探索新的交互形式特别感兴趣，也是喜欢这种工作方式能带来的创新。

　　回到我们的“计划”：7月的每一周我们都要做一个不同的原型，实现一个不同的主意。这样到月底的时候我们就有了4个原型，可以决定挑其中的哪些去进入真正的开发过程。

　　有了AI工具的帮助，写代码的过程比过去简单多了。所谓熟能生巧，但对于我们这种三脚猫功夫的程序员来说，隔几个月甚至一两年才写一个小项目，每次都需要花不少时间重新热身，阻碍工作进度的都是一些特别初级的问题。比如说，我打算用Python来写这几个原型，那么我写完了一段Python程序，到底应该怎么让它运转起来呢？安装、调试各种配套工具的时间，可能都比写代码的时间多得多。再比如，作为一门编程语言，Python有规定的语法，而我对此并不完全熟悉。只要有一些写不对，就会出错，就要花时间学习理解，到底哪里错 了。

　　有了AI编程助手以后，可以向AI用自然语言描述我想做什么，由AI直接生成对应的代码。在代码编辑器里面敲几个字母，AI也很容易根据上下文猜出我想做什么，直接自动续写一整段代码。代码运行报错，也可以直接把报错信息贴给AI，让AI直接告诉我到底哪里出错了、为什么。

　　其实和学外语还是有一点像的，都是用不同的语言来表达自己的想法，只是写代码不是向人表达，而是向机器表达。AI加入后的写代码体验，无疑减少了许多表达的阻力，让整个工作更容易进入所谓的“心流”，顺畅地将自己脑子里面的东西持续地写出来。联想起我和AI用英语聊天的体验其实也类似，由于完全不需要讲究语法或者句式是否优美，乱七八糟连比带划地敲出去，反而降低了表达的门槛。

　　而且，和其他工作比，写代码这个工作中的每个小任务的预期产出都非常明确，就像解题一样，还挺容易沉迷其中的。复工恢复状态下，我花在这上面的时间比较多，也总容易想起刚毕业时的工作。那是我目前职场生涯中唯一的两年“打工”生涯，还是挺简单、挺纯粹 的。

　　不过，原本打算一周做完的原型，最后还是花了一个半月。第一天觉得自己是天才，等到第30天的时候，开始想，要不还是找个人帮忙算了……

　　如果说AI能帮忙解决90%的问题，那就是剩下这10%的问题，占用了太多时间。如果是一位熟练的工程师，解决我遇到的问题，应该会比我快很多。AI辅助编程是这一代大语言模型中最早商用的应用，即使这样，也还是有很大改进空间的。

　　通用大语言模型的一些问题，在AI辅助编程中同样存在。比如，AI的数据更新不及时；很多时候AI只能提供一些建议，很少能直接替我完成一项任务；对于特定领域的知识AI并不了解，但又无法去查阅对应资料，等等。

　　目前AI辅助编程，主要也是通过聊天和编辑器中自动补全的形式来实现，经常需要到处复制粘贴，也并不方便。因此，我还是不觉得聊天就是AI的终极交互形态。

　　等第一个原型做出来，把我们觉得重要的功能都实现，让我们自己能体验到，已经是8月中旬了。现在是8月下旬，做了两个原型，还差两个。

　　我们的目标是做出自己每天都想用的产品，这样子对原型的完整度要求高一些，是需要真的日常使用的。的确，在第一个原型的制作过程中，我们自己每天使用这个原型，根据使用体验不断调整它的设计，有意料之外的惊喜，也有失望。一个半月过去，虽然核心想法没有变，整个想法和最初相比已经做了很多调整 了。

　　这两个原型我们还没有准备好公之于众，现在只是定向邀请我们觉得可能有需求的朋友们来使用。它们都和“认真阅读”有关，只是在特定场景下，换了一些不同的方式。不管是帮助自己回想起曾经阅读的片段、提升查找效率，还是发现不曾想到的角度，甚至提供一些情感支持，都有一些我们之前没有想到的体 验。

　　希望可以尽快和大家见面。