要走的路还更远

　　AI便签工具的正式版终于开发完了。最后一步，将版本号修改为1.0.0，提交，发布。

　　断断续续地，这个“小”产品居然开发了一年多，远远超过了我最初的预期。除了一部分工作由阅览室的两位创始读者兼职完成，大部分的设计、研发工作都是我自己动手完成的。这是我第一次从0到1地独立完成一个产品的开发和上线，我也算是“独立开发者”了—我并不以此为豪，因为如果纯粹从商业角度考虑，这并不是一个具有性价比的理智决定。我没有想过要将生命中整整一年的时间花在这样的一个“小”产品上，而且还是以工程师的角色。这肯定不是我擅长的事情。

　　虽然如此，我还是很高兴自己坚持把它做完了。完成一个事情，对我来说很重要。

　　那么，如果再做一次，会有什么区别？

　　回想2023年7月重启阅览室的工作，当时我的想法很简单：每周做一个不同的产品原型，这样子一个月可以做出4个，借此“热身”，进入工作状态。一开始决定自己来写代码而不是招人来做，是考虑到原型对代码质量的要求不高，我作为一个三脚猫功夫的程序员在AI的辅助下完全可以胜任，另一方面是认为对于这个阶段的AI产品来说，要做出创新和突破，设计和工程无法分开，需要一边开发一边摸索可能性。自己来做，虽然工程上没有那么熟练，效率可能反而会更高一些，迭代速度更快（见2023年9月刊《一个不同的主意》）。

　　从原型制作阶段的实践来看，这些想法大体是对的。以可以上线邀请朋友来内测为标准，制作一个原型实际上大约要花一个月的时间，而不是一周，这当中的差异主要还是我高估了自己学习新技术和编写代码的能力，但应该还是比找人来做要快的。

　　AI便签是其中的2号原型。原型制作完成后，我们觉得这个产品应该能在市场上占有一席之地，决定再花一些时间把它开发成可以正式发布的产品（2023年10月刊《解锁创造力的惊喜》）。那是2023年9月，这个“一些时间”，当时我们的估计是一个月。

　　首先，一个再简单的产品，只要它是一个完整的产品，就没法太简单。

　　拿这个AI便签产品来说，最初的原型我只写了千余行代码，到现在，则已经超过万行了。代码量增加了10倍，核心功能其实没有增加。那增加了什么东西呢？作为原型和作为一个供人使用、还打算卖钱的正式产品，要求多少还是有些区别的。举个例子，这个产品有一个核心功能是将笔记保存到用户的Notion账号中，一开始为了节约开发成本，我们请用户手动绑定Notion账号，用户需要在电脑上手动操作十余步，将两串代码复制粘贴到我们的输入框中。能完成这个流程的用户不足10%。现在，用户只需要点击两次确认，就可以完成这个过程。代价，是2000多行代码。

　　这是一个付费产品，我们需要开发对应的支付系统和权限管理；原型代码的稳定性不足，用户经常无法及时得到结果，也需要改进；还有语音输入、帮助和新手引导、营销用的官网、注册表单……等等。做原型的时候不需要考虑这些，正式上线的时候都需要。

　　所以说，只要是个完整产品，就不要太轻视它的复杂度，这些“没有不行”的功能，大概就要占90%的工作量。需求文档中每个小小的点，都是工作量。

　　两三周前的一天，我在制作产品的注册表单。为了节约时间，我用的是现成的表单工具，即使是这样，从早上开始做，等做完的时候天也已经黑了。回想一整天的工作，也没有什么浪费时间的地方。只能说，这些工作本来就要花这么多时间，只是因为大部分的工作都由自己完成，这些工作量体现得更加明显而已。

　　这些虽然占了工作量的大部分，毕竟还算是确定的工作量，做一件少一件。这一年中的大部分时间，并不是花在这类问题上的。

　　2023年9月，决定将原型开发成正式上线的产品时，我也清楚自己的工程能力不足以完成这项软件工程工作，于是决定找专业的人来帮忙（2023年10月刊《解锁创造力的惊喜》）。我在社交平台上发布招聘帖后，有3位阅览室的创始读者以兼职的形式加入了我们，他们都是工程师。

　　我本来以为，从原型到正式产品是一个水到渠成的过程，对有经验的工程师们来说，都是迎刃而解的“已知问题”。实际上，一个AI产品的开发，即使是在原型的基础上将它完善成符合正式上线质量标准的产品，也有一些开发其他产品时没有的挑战。其中，我认为最重要的是大语言模型的输出质量不够稳定可靠的问题。来帮忙的几位工程师之前都没有开发过大语言模型应用，要解决这个问题，对他们来说也需要重新学习、探索如何解决（2023年11月刊《有不确定性，才可能创新，才能自由自在》）。

　　由于这项工作需要不断调整提示词、参数、重新设计与模型的交互，和产品设计的意图紧密相关，最后还是我自己完成的。今年从年初到夏天，我都在做这个工作，在2024年8月刊的《从60分到90分》中我做了详细的记录。

　　如果仅从结果的角度考虑，再来一次的话，我想，也许及时知难而退是效率更高的做法。只是未知的领域往往会引起我学习的兴趣，这样的一个挑战反而对我来说充满了吸引力。而一旦开始深入研究，能探究的东西又越多，就越来越难收场了。

　　解决这个问题的过程同样是一个软件工程工作，说到底我也还是没能逃开，只能硬上。AI编程在过去这一年中有很明显的进步。我刚开始开发原型的时候，主要是依靠AI局部补全代码，今天的AI已经可以按照你提出的需求，凭空写出来一个完整的应用了—但写出来的代码质量也只能说勉强能运行。我觉得今天的AI编程其实特别适合用来做一些“日抛型”的产品，比如给自己写个一次性使用的数据处理脚本，给孩子写个小游戏，或者，就像之前一样用来做个产品原型，这些都可以全自动完成，效率和一年前相比可以说有10倍的提升。但我们在做的是一个有一定复杂度的、严肃的软件工程项目，AI仍然很难独立将代码一次性写对，这种情况下仍然需要开发者去理解其实现原理、给出更详细和有针对性的指令。这对人的要求其实并没有降低，因为你要作的是软件架构、设计方面的决策，这甚至不是刚入门的工程师能完成的。

　　我只能说我努力去学了。我的学习习惯，往好的说是比较追求系统性，很难满足于只得到一个不求甚解的答案，一定要搞清楚为什么；说不好的，就是太慢。

　　回头来看，放弃可能是更理性的决定。某种程度上，我们这个AI便签产品也在探索大语言模型的能力边界。问题是，我的主要兴趣实际是在产品交互上，花时间去探索这个边界，以性价比考虑的话，是不太理智的。如果回到那个时候，如果确信大语言模型的能力无法轻而易举地实现我想实现的效果，我应该果断搁置这个产品，去做那些大语言模型已经被证明能做得很好的事情。等大语言模型的能力演进后，再回来。

　　如果仅仅追求效率，就应该尽量多做自己熟悉的事情，少做自己没做过的事情。在过去几年的工作中，由于我经常成为团队瓶颈，答应的事情没有办法按时完成，我真的定量统计过，自己估算的时间和实际花费时间的差别。数据统计表明，在那些我最熟悉和擅长的领域，我所花的时间和预估的时间差别是最小的，甚至会比预估时间更快，例如产品策略、信息架构设计、界面设计等。而一个领域我越不熟悉，预估时间的偏差就越大。

　　这里面还有一个因素是，即使是一个自己不擅长的领域，我也很难放弃对质量标准的要求，这也导致我要花更多的时间去学习，每个问题世界上最好的解法是什么。虽然最后出来的效果往往都不错，但就是过程所花的时间是不可控的。一个典型的例子，就是产品的视觉设计。前面说到的软件工程问题、提升大语言模型的输出可靠性问题，都属于此类。

　　这个过程中最痛苦的还是工作量永远没有办法预估。朋友问我什么时候能上线，我永远都回答“下周”—我每次这么回答的时候，都是真的觉得眼前的工作量不多了。我猜这大概和在沙漠里看到海市蜃楼的感受是类似的，总是觉得终点近在咫尺，却永远走不到。这个状态持续得久了，希望慢慢变成绝望，对自己的信心是很大的打击，也容易迷失方向，不知道自己今天起床工作是为了什么，和目标结果有什么关系。我倒不担心自己做得不够好，只担心做得不够快，还没有走到终点的时候就已经渴死了。这种情绪在过去几年一直围绕着我，在过去这一年中更加登峰造极。

　　当然，站在今天的角度，那些曾经不熟悉的事情，到今天都已经变成我掌握的技能了。就拿大语言模型的输出可靠性来说，现在我可以说自己对于怎么做出一个质量较高的大语言模型应用，已经有明确的概念了。而且我也发现，大部分的产品团队并没有花时间去做这个事情，那么这就变成我的一个优势了。

　　回想起第一个版本的原型，去年夏天的一个下午，我利用prompt在ChatGPT中模拟了设想中的交互场景，兴奋地认为自己找到了一个新的产品方向，然后开始依葫芦画瓢地学写代码—如今真是已经走了很远。

　　上线后，要走的路还更远。