@cannotagreemore 你司要不要考虑换一换？建议看看 https://news.ycombinator.com/item?id=44414630 。作为 Theine 的作者我向你推荐 otter

解析不了 json 格式是指输出的 json 不对？让模型用自然语言输出能不能正常识别

@RealApe 你可能没见过工作十年连 regex 和 wildcards 都分不清，而且提交代码前自己也不测试的。初级程序员的下限低到远超你想象，而且还有各种情绪，特别是年纪大的初级程序员又混又菜，就算在写普通业务方面也远差于 AI(高级程序员指导下的 AI)。最近我用 jules 生成了大量代码，风格并不太稳定，比如 test 的 mock 方式就经常不太一样

普通程序员配合 AI 就能抵上一个高级程序员不太可能，一个高级程序员配 5 个 AI >> 和 5 个初级程序员协作很有可能。初级程序员配合多个 AI 你将会见证系统稳定性大幅下降，代码风格五花八门，代码库的熵快速增加

好家伙，op 上一个帖子是 10 年前

现在的闭源模型或者 ollama/vllm 这些基本都支持 structed output 了吧，你直接动态构建一个 schema 传过去不就行了。数组数量不一致你可以转换为 object: {"1": "hello", "2": "what is it", ...}, 强制 structed output 符合这个结构

对于企业来说最重要的一点是收益与风险。只有在高收益的情况下才会愿意承担高风险，理想的情况是高收益低风险。所以 Readme 里首先应该明确选择你这个项目对比其他竞品的收益是什么，最好能精确到具体数字。风险方面，star 数量勉强能算一个指标，忽悠一些水平比较有限的程序员。有一定水平的程序员在决策时肯定会综合考虑项目背景(比如大厂出品，CNCF 认证), 代码质量(CI/CD 完善程度，是否有完备的单元/集成/e2e 测试)，是否有大厂已经在用以及是否有商业支持(出了问题谁背锅)等各种方面。对于开源项目来说 Issue 和 PR 也很重要，比如改一堆文件，PR 就一行字甚至没有字，也没有任何测试，这样的 PR 如果挺多而且合并了就是个很危险的信号

@lesismal Topological sort of the directed graph defined by the providers using a depth-first search using a stack. https://github.com/google/wire/blob/main/internal/wire/analyze.go#L105 。web 类项目从开始就用 DI 框架其实是我的个人习惯，因为这类项目总会趋向于越来越复杂。我的 cache 库就没有 DI 框架，因为功能很单一项目复杂度不会一直增长

刷新了几次，时有时无，无的概率比较高

https://github.com/microsoft/typescript-go/graphs/contributors 第三个不就是 rbuckton

创业公司失败的概率是 95%，所以不要以长久/稳定之类的来衡量。我觉得最重要的是看人，人靠谱的话就算没成功也当交个朋友。所以创业公司面试最好是当面和创始人聊聊，一个合格的创始人应该情绪稳定，有风度而且思路清晰。另外如果加入创业公司后发现情况不对也建议尽快离开

@lesismal 在依赖复杂的情况下顺序是个大问题。因为依赖本身是个 graph ，你加入一个新的 service ，这个 service 会依赖一些已有的 services ，这里问题不大。但假如一部分已有的 services 也依赖这个新的 service ，那所有 services 的初始化顺序可能就要改变。不使用 DI 框架的情况下你需要人工(AI 也许也行)来判断这个新 service 初始化的代码应该放哪里，以及是否要调整已有 services 的初始化顺序。修改某个 service 的依赖时也是一样的情况

@lesismal 我的比较简单，但 grafana 就不一样了。这是 server: https://github.com/grafana/grafana/blob/main/pkg/api/http_server.go#L340 ，这是 DI: https://github.com/grafana/grafana/blob/main/pkg/server/wire.go#L204 。DI 框架的好处是不用考虑顺序，框架会自动处理，同时初始化时也不用手写各种 NewXxx 的方法

@lesismal 我自己这个项目就很直观 https://github.com/Yiling-J/tablepilot/blob/main/services/table/table.go ，我要给 table service 写测试，table service 依赖 ai service ，ai service 有自己的测试不用再测一遍所以直接 mock 。为了能 mock 就需要把 ai service 在创建 table service 时传进去，这就是依赖注入。di 在 web 类项目很常见，但功能单一依赖很少的单一功能库可能不太需要

@echoless csv 一开始就支持，tsv 和 xlsx 暂时不支持。license 和商业化现阶段我不太关心。而且开源项目火了以后走商业化改 license 现在也挺常见

@RangerWolf 找一个 2024 年一月的重大事件问问，比如某选举。https://en.wikipedia.org/wiki/2024 。4o-mini 的 cutoff 日期应该是 2023 年，deepseek v3 的日期可能是 2024 年但不确定，github model 的 DeepSeek-V3-0324 是能回答的。但如果 system prompt 里限制了不准回答 2024 及以后的问题估计也测不出来

如果是解锁版 deepseek 就挺难判断了。但两个的 knowledge cutoff 日期不一样，可以试一试问日期相关的