随着 613 版本一起更新的啊，3.5 降价了，但推出了稍微贵一些的 16k 版本，并不需要申请。

效果的话由于 tokens 变长了，长文总结或者 agent 之类的用法超出限制的可能性减小了，聊天也可以记录更多上下文了。

但上下文始终会对结果产生影响，长了有时未必是好事。

另外新模型支持的 Function calling 功能很有用，效果比 langchain 好一些，想尝试的话可以试试我写的小工具 https://github.com/laipz8200/openai-agent

@abersheeran #6 入参部分使用的话构造请求应该能更方便，但我的初衷是希望可以把现成的函数加上注释直接拿来用，如果强求用户这样定义入参或许不好，总之还是感谢。

@abersheeran #1 我没找到 pydantic 有可以处理函数的方法，目前用的__doc__是 Python 自己的特性，pydantic 只用来定义数据结构了，求问 pydantic 的哪个特性可以用来生成描述？

数据库好像还是不太行，FastAPI 本身很好用了，语法那是 Python 的问题，不是框架的。

而且真正需要异步的地方也不多，重点的任务都扔 Celery 了。

学过 Rust ，学完有种拔剑四顾心茫然的感觉：

无 GC 场景？比如交易之类的，个人项目很难接触到这种东西。

底层？功力不够不知道做什么。

应用？那我有太多其他语言可以选择了。

很尴尬……

@sdjl #57 我觉得 8 楼贴的文章里的观点非常好，我经常听到「不了解业务做不了好程序员」，「不懂一点开发做不了好产品」之类的说法，说明这些岗位的工作之间是存在交集的。

理想状态当然是每个人都对要做的事有充分的认知，然后大家在各自擅长的方向上展开合作，现实则是如果其中有一个人能力不太行，其他人就不得不被动地承担原本应该由他完成的工作，甚至可能因为沟通的问题使得效率进一步降低。

我是从专业细分的角度考虑这个问题的：

现代社会不断细分专业，让每个人都成为社会这个大的流水线上的一员，其目标毫无疑问是寻找具有效率的生产方式，但很多时候团队成员的能力不足以达成这个目的。

对企业而言，好的企业肯定不会因为害怕培养出复合型人才后人家跑掉就放弃培养，但很多企业 /产线可能本身就更偏向于流水线式的生产，而不是更关注团队中个人的创造力之类的东西，那么自然就倾向于保证员工的可替代性，降低人力成本等等方面。

对个人而言，成为螺丝钉一般不如成为复合型人才更有吸引力，又或者由于现在越来越多的复杂领域需要同时具有多个领域知识的复合型人才，之前强调单一专业的方向已经不再是最优解了，所以有能力的话应该去寻找能让你发挥的地方，找更好的企业 /团队，甚至自己组建这样的团队。

上世纪很多有名的科学家都是跨多个学科的，比如同时在数学和物理、化学、天文等领域有所成就，而现在也一直都有类似的观点被提出来，比如所谓的“T”型，兼顾知识的深度和广度。我个人认为知识的广度和深度都很重要，广度让你能从更全面的角度思考问题，而深度决定你能否在专业上取得突破，由于人的精力终究是有限的，怎么在这两方面取得平衡应该会是个很值得研究的问题吧？

我支持什么都干，产品运营开发运维推广销售这些都可以自己做，老板也自己当，因为做好这些有一个共同的前提，就是对你做的事有充分的认识，职责分到多个人身上之后，沟通成本会显著提高，如果每个人对所处领域的认识有差异，就会出现问题。
然而从企业的角度来看，打造流水线，让每个人可以在细分领域不断深入，只做一件事无疑是更有效率的。

一般建议放外面，除非你某个函数只调用一次，或者有什么不得不放在里面的理由

browsing 还行，其他插件目前感觉一般，跟自己做 toc 区别不大……
但 GPT-4 总体上确实比 3 强多了，除了速度。
每三小时那个限制好像不是很严格，我使用频率高的时候也没触发过。

什么都用 js 只会害了你（不是）

Star+1 ，这个楼中楼真不错

我折腾到最后就 vscode 了，插件支持的正好都是我常用的功能，用 vscode 还省去了配置，也不需要操心 lsp

@xiaocaiji111 #98 ORM 一般会提供只生成 SQL 不实际执行的功能，以供人在关键的地方编写测试来确保生成的 SQL 是正确的。不过这样的话就和手写 SQL 没什么区别了，所以如果追求每个 SQL 都测的话用 ORM 就没什么特别的优势，反过来说，不需要每个都测时它挺有用的。

我觉得国内的话，行不行可能主要看营销，不完全是产品本身……

ActiveRecord, SQLAlchemy 使用者前来围观……朋友一直说 Hibernate 过时了，Mybatis 更好，看来并不是这样？

心疼楼主……不过建议给人打个码，毕竟领导没招谁惹谁，名字被贴网上不太合适

Java 的话，看看 Django 吧，什么都有，对你来说也许更熟悉一些？

没有实际用过 Java ，理论上 CRUD 初期 POJO 的结构可以一路传到任何地方，只需要在前端接口变更 /数据库结构变更等情况发生时再创建对应的对象做转换就可以了。
问题是如果一开始没做这件事，等问题发生时去处理的人又没能意识到这里需要一个现在没有的对象，项目就会逐渐变得无法理解……