@strawberrydafu 现在类别是写死的服装/姿势/表情， 而且只有服装能提取。下一步我准备把类别变成完全可以自定义的，你可以自己添加类别，然后提取/生成的时候都可以选这些自定义类别

我在公司同时做 3 个比较复杂的项目，差不多 95%以上的代码都是 Jules 生成的。有几个小经验:

- 架构层面必须我来告诉 agent ，不能让他自己发挥，比如选什么数据库/orm ，代码怎么分层，怎么写单元测试
- 不要使用冷门语言/框架
- 后端有单元测试
- 详细的 agents.md
- 完善的提交检查，让 agent 在提交代码前把 lint/test 什么的都跑一遍，通过再提交
- 使用 plan 模式(Jules 叫 Interactive Plan)，交互让 agent 根据你的原始计划生成详细且明确的新计划

最近折腾的一个小开源项目也是这样的思路 https://github.com/Yiling-J/forgery 。可以参考一下

@andrew2558 Google AI Studio 设计的，虽然都是 Gemini ，但 Google AI Studio 里的 Gemini 似乎品味比 Jules 好一些

你把 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 框架，因为功能很单一项目复杂度不会一直增长