王俊煜
前两天整理了一下今年春节之后的工作日志，发现大部分时间自己都在做同一件事情：测试评估两个AI产品在上线测试过程中发现的问题。
这两个产品所处的阶段几乎一样，已经上线测试了，有小规模的真实用户在使用。通过观测这些用户如何使用，我们发现了一些比较明显的问题。在推向更多用户之前，必须解决这些问题。
举一个例子，其中一个产品主要面向海外用户，我们只优化了英语的体验，非英语用户很容易遇到一个问题，即我们的AI会错误地将用户输入的文字翻译成英语后保存。即使我自己的中英文读写都流畅，多了一次语言切换，还是给脑子增加了很大的额外负担。本来我们这个产品追求的一个体验就是让用户在思考中形成心流，这个问题出现时，会完全破坏这个体验。
这个问题在产品上线前我们就知道，只是觉得不会经常遇到，解决起来应该也不难，就没有花精力去解决。上线后我们发现，即使只是测试阶段，非英语用户也占了大多数，有接近一半的用户在实际使用中遇到了这个问题。那就变成了一定要解决的问题。
还有几个这种程度的类似问题也是在上线测试后才引起我们注意的，这本身也是上线测试的价值。
许多互联网产品都会挂上“ 测试版”（Beta）的标志，上线请用户帮忙测试。但其实除了上线测试，更直接、也是更传统的对产品质量的保障，是团队内部研发过程中的测试。一个产品的研发流程，大致分为规划、设计、开发、测试、上线几个阶段，其中测试可能是被关注得最少的，至少过去我关注得不多。不过这可能也是我做事的一个特点，做初创企业更关心在什幺事情上可以取得突破，就不太容易关注保障性的工作。
离开豌豆荚后，我的团队规模一直很小，我也一直没有再招聘全职的测试工程师，而是将其分散到各个职能。除了一部分自动化测试，产品功能主要依靠手工测试。出了几次事故后，虽然还是没有专业团队，我还是花了一些精力引入了专业一些的流程。撰写了测试手册，里面收录了几百个功能测试点。每次测试时整个团队分头认领，花两三个小时就可以在不同的系统、机型上勾完这些测试点，非专业团队也可以用专业流程来办事，准确又高 效。
自从引入专业流程，产品发布的时候我再也不会提心吊胆了。我自己在这个事情上还是花了不少时间的，所以可能也不能说我对保障性的工作关注得不多。只是我热衷的是研究行业的最佳实践，然后只要部署到位，就认为自己可以高枕无忧了。英语里有句话叫“trust theprocess”，在这里可以翻译成“相信流程”，大概就是这个意思。
但AI产品的测试方法看起来不太一样。这两个AI产品本身的逻辑都蛮简单的，复杂的都是大语言模型本身。要解决我上面提到的问题，一是涉及对我们使用的大语言模型更细致的调整，二是需要调整提示词（Prompt）的设计。解决具体问题不难，但大语言模型输出的是开放答案，本身有一些随机性和不可预测性，有时候为了补西墙会不小心拆了东墙，修复了一个问题，却带来了新的问题。这个产品的测试，如果也想让自己高枕无忧，就不是在过去的测试点清单上打勾就可以了。
此外，如果需要不断提升产品的效果，不仅仅是保证不出现问题，也需要对AI的输出做定量的评估。过去我们也做过搜索引擎，对算法的评估是类似的，同一个功能点需要测试许多不同的场景。但AI功能的输出和用户的交互历史有关，如果使用纯人工测试，意味着需要反复聊很多次天，这样子变数非常多，不像搜索引擎一样只需要输入一个关键词就可以评估。
所以，我又开始找某种最佳实践。
回想了一下，自去年7月恢复工作以来，我的工作更像是程序员，而不是设计师，大部分的时间都在写代码。我上一次在工作中需要大量写代码，还是刚毕业的时候，17年前了。
之前在专栏中我也表达过，有时候难免会担心，这算不算是职业生涯的倒退。当然，我也会认为，这可以带给我信心，产品研发流程中的每个环节我都掌握了。我管自己叫程序员而不是软件工程师，是觉得我的三脚猫功夫搭个草房子还可以，称不上“工程师”。但在AI的帮助下，这半年我的编程水平还是有很大进步的，可能慢慢地可以搭一个木头房子了。
做产品设计需不需要懂技术，是一个亘古不变的话题。在过去，我的答案是，如果你要创造新的东西，你还是需要知道面前这块画布的特性的。而在今天这个AI快速发展的阶段，没有人能准确说出AI的能力边界。要了解这块画布，必须动手。
之前介绍过IDEO的理论：产品创新需要同时满足人的渴求、技术可行性和商业可持续性。AI带来的是技术可行性的巨大变化，这是我作为产品设计师感到兴奋的。挑战则是，如果说设计师的工作是创造性地解决用户的问题，由于技术的不确定性，设计方案也必须在研发过程中不断调整。这时候，设计师多花点时间写代码、探索AI的能力边界是应该的，这样才能创新。
和半年前相比，不管是GP Ts，还是类似Coze、Dify这样的工具，成熟度都有了很大提升。用它们都可以快速搭建出一个产品的雏形。但这些工具目前也只是照顾到大多数情况下需要用到的东西，做出一个60分的演示没有太大问题，如果要设计更创新的体验，或者需要提升到80分、90分，眼下还是需要自己写代码的。代码，在这里就是一个设计工具。
但我的另外一个建议是不宜钻研过深。如果技术思维过强，做事情容易过于从技术可行性出发，忘记用户的问题是什幺。
开始写代码之后的另外一个好处，是对产品品质可以有更直接的影响。创新和品质，大概就是我做产品最关心的两个方面。
作为处女座，我做这些事情还是很愉悦的。2007年刚毕业的时候我以设计师和工程师的双重身份入职Google，也接受了工程师的入职培训。印象最深的是，导师说，你作为工程师不能花太多时间写代码，最多1/ 3，否则质量就会有问题了。剩下1/3要用来读别人的代码，也就是代码审查，再花1/ 3的时间做程序的设 计。
我的很多工作习惯都是那时候养成的。我在Google的第一个项目是设计App Engine的管理后台，这是Google第一个面向开发者的托管服务，当时还不流行“云”这个概念，它可能是Google Cloud最早的雏形。Python之父Guidovan Rossum恰好和我同一天入职，也加入了这个项目。我是刚写下自己的第一行Python的新手，Guide是Py thon的发明者，但他也没有特殊待遇，和我一样需要先在入职培训中通过Google的Python考试，才能持证上岗，有资格提交Python代码。
Guido通过考试时在自己的周报中特意写下了这件事，在当时传为笑谈。
过去我自己做的公司，像Google一样的代码审查从来没有严格实施过，多数是走过场（“帮我过一下”）。据我所知，似乎也没有哪个中国公司能做到。显然，认真的代码审查会让开发节奏变慢，但是不是能有效提升质量，让效率更高？今天我自己实际上手来做这个事情，对工程开发的方法更有体会了。
这也是和结果有关的。我们一直做的产品的定位还是对质量有比较高的要求的，但过去很多年的一个困扰，是质量无法达到理想状态。当然，坦白说，我觉得这个工作还是应该由技术合伙人或者CTO来承担，只是我们现在还太早期了，不一定需要这个角色。
说回如何测试AI产品，其实已经有很多人发明了很多轮子。刻薄点说，可能大家都还不太知道AI能做什幺，所以才把精力花在造轮子上了。
细节略去不表，总之我额外花了几周时间找到一个看起来不错的轮子，把它安装到了我们的产品中。这件事情最终花费的时间大大超出了我的预期。我永远都觉得“下周可以弄完”。而且，由于这个过程中还是有挺多重复的工作的，尽管当中的许多可以由AI协助完成，还是花费了我很多时间。在这个过程中我还是时常怀疑，这是不是对自己时间的有效使 用。
如果再做一次，我相信是可以节省很多时间。有了经验，可能就知道哪些事情可以跳过，这样可以节约很多时间。但是不是一开始就可以不选择这个方式？如果还是手工测试后就闭着眼睛上线，效果会有多大区别？
我此刻可能还没有答案。尤其是我试用过的很多A I产品，包括大公司做的，其实都无法正常工作。这个月发货的“首款人工智能硬件”AI Pin被The Verge称为“可能是现代技术史上评价最差的产品发布”，我看了几个测评，不需要严谨的测试，简单试用你就知道它无法完成用户期望它完成的工作。这些当然不是好的例子，我们不希望做这样的产品。
但我们的两个AI产品迟迟未能成功上线，每次有这种“失控”的感觉，我就容易变得烦躁起来。
现在，我的确会更直观地理解，为什幺研发项目的时间很难估算准确。很多年前我读过一篇文章，文中拿从旧金山沿海岸线徒步到洛杉矶举例，称从地图上看无非是四百多英里的距离，简单的除法告诉我们，理论上7天可以走完。实际上呢？我没有搜索到很准确的答案，有人说他的一个退役军人朋友尝试过，大概花了6个月。这当中的细节、不确定性，都是在地图上无法看到的。
所以可能软件工程的美妙就是要在未知中探索。商业也是一样—如果我们不是要解决一个已知问题的话。
