有一个问题我犹豫了大概快一年：要不要招一个前端的JavaScript开发。因为大量的框架结构开始收敛到这一个点上。
然后，在上个周末，我不再犹豫了，因为我找到了，Claude3.5。
仅仅是公交车上的一个多小时，一点一点，它做了一个完整版本的hold'em扑克游戏。
从朴素版
到一些朋友反馈界面已经很好看的可用版。
甚至，我想了一段时间，但是一直没有时间着手实施的服务器版本（用来训练模型）。
当我可以以一个程序员的方式去思考，却不必去过多触碰并不太熟悉的前端代码时，感觉太好了。我一直知道自己是一个想法相对多的人，我也知道也解决我的问题的方式是相适配的执行力和对过多冲动想法的克制。
如今，似乎有了新的解决方案，而对于我们一直在构建的‘低代码’方案，也有了完全不同的解法。
相比之下，下面的siren的例子就过于朴素了，但是，这是三十多年前很多程序员包括我从完全文字方式走向“多模态”的第一步：让机器发出声音。
既然想法可以再次放飞，我会要的更多，比如，把现在的整个数据分析平台重构，甚至探讨三维世界的可能性。
或者，我想同时测试模型的理解力和执行力，所以我尝试着只是给了模型两页说明书。
它，‘造’了一台相机！
所有这些，让我有足够的动力继续提升‘生产力’。
可以肯定的是，我确实不需要JavaScript程序员了，但是另一个问题也紧接着而来：如果我们简单的把一个项目拆成产品经理（或者业务）和开发，那么在Claude3.5这样的模型（我相信这只是开始）到来后，他们的关系又会如何变化？
似乎，只要有足够的想法，就可以快速实现至少是原型的版本，但是开发会说这种原型到落地，技术上要解决的问题太多，这种方案是不可能的？
似乎，先发挥模型的知识库和理解力，不了解的业务知识模型也能回答个七七八八，那么开发也可以快速完成业务原型，可是pm会说这种在业务上落地，根本是不可能的？
有意思，或许，‘一人公司’是一个不错的解。
对了，有一样不太会改变，我们要生产‘美’的东西。