你把 v0 放里面不太合适。1. v0 生成的本来就是原型，没有后端 2. 你可以让 v0 生成完 UI 后再生成文档

我的建议是强力推行，并且同时开始推行 AI 编写代码(agent 模式，claude code, codex 或者 jules 这些)。同时持续对比有单元测试情况下和没有单元测试情况下 ai 生成代码的质量。最终达成以下目标：op 成为 ai coding 和单元测试专家且工资翻倍，公司开发人员减少 2/3 ，降低公司成本以及减少开发沟通内耗

收归测试人手其实只是借口，推行单元测试的最终目的是干掉开发。AI 代码的质量非常依赖单元测试，如果系统都没办法进行单元测试，那肯定也没法让 AI 同时编写代码和测试，并确保测试通过

@matrix1010 33 分钟开始，research 部分

@LeslieLeung 模型层面应该也需要针对 json shema 训练的，可以看看这个 openai dev day 的视频 https://youtu.be/kE4BkATIl9c?si=0Oy7D2fmnMoWUXQc&t=1986 。豆包确实支持，但不知道是只 decoding 层面约束还是模型也做了针对性训练

@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 的依赖时也是一样的情况