mx2dream

还有个体会，就是要强调或者加入过程管理的规则，比如就某些范围和条件进行约束，其它的确保不能动。花大量的时间在互动讨论上，而不是前期讨论太少就急于开始，否则都不用等到后期就会给 AI 擦屁股擦到恶心。用好了会发现比 100 个实习生起到的效果都要好，自己都使用 vibe coding 了，自己的角色同样需要调整和适应，需要代入部分 owner 和 coach 的功能。经过这么切换和沉浸式体验后，终于开始有些暗爽的感觉了

自己设计一个初步的架构，跟 AI 以聊天模式反复讨论，别真的把它当成纯自然语言的编码方式，要不然怎么叫 vibe 呢。
具体操作是你可以让 AI 以结对的角色向你提问，某些方案需要经过你的确认之后才能开始执行。在经过十几个来回之后，让 AI 把讨论的最新的结果生成一份说明书，达到某个里程碑时进行实例测试和进度评估和后续计划修正，对比最初的产品开发文档并输出一份包含以上至少三方面内容的评估报告，经过跟你的讨论和确认之后，再输出一份下一阶段的开发文档。
弊端：次数或 Tokens 消耗得更快了；
好处：开发效率和质量有明显提升。

得不到的永远在骚动。虽然现在品味起来既美好又有一种难以言表的伤感，这种记忆已经根植于自己的年少，很难完全分离。当心中的道德卫兵赶来之前，还是会把它藏在心底的某个角落。等到某一天手里的碗都端不稳的时候，说不定还能让自己猛然间眼神坚定、捶胸顿足，全然忘了汤都洒了一身呢

老哥有没有一些稳定的现金流收入，原来的房子有没有考虑租出去获得一些租金，这个年龄如果想在赚大钱方面突破，应该是很难了。现实一点还不如把自己身体搞好，帮小孩适当地在当地打打基础。如果长期出差，大概会在夫妻、亲子、身体等方面欠下不少的情感债和健康债，曾经也有过一段时间类似的工作，深有体会。而你之后的健康曲线和财务收益曲线大概会继续逐渐向下，从风险的角度，反而应该想想以后可能会在哪些方面会触发风险，提前采取措施，尽量维持和减少可能的损失。

受限于项目复杂度，一般情况不会太卡。SOLO 模式我用起来反而不如常规的 Builder 模式

试试运气

@Sh1xin 这么看，你说的这些场景有点复杂了，不是单纯的技术问题了。从输入源就有问题，还涉及多部门，估计这个你一时很难解决，如果公司内部某些部门没有动力推进解决这些，问题会一直存在。对外部的小客户给一点优惠利益，你们再搞个统一的业务填报的入口，让他们往你们提供的入口迁移啊。不过这些事想想就很麻烦，就看你们自己的决策了。
还有个想法，反正识别表单类的场景一般涉及的上下文和缓存也不大，就不用专门留太多冗余了，如果你多跑几个 VLM ，比对之后达到一定标准就往下个流程走呢，或者买点专门提供这块方案的供应商谈谈。

@Sh1xin 试图用自动化解决绝大部分问题我认为也是一种幻觉，有些识别问题技术解决不了的就通过管理来解决。比如上传资料时按类别、清晰度、重要性和保密性等等打标签进行分级，如果资料级别达到比较高的程度，就在流程上专门引入人工校对或给相应权限的人复核就行了（否则全部自动化了还要人干什么），如果资料没那么重要，就不用太苛求太高的识别正确率了。

①知识库②智能客服问答③OCR 这些需求使用 30B 左右的参数有点浪费了。优先考虑总参数 100B 激活参数 10B 左右的稀疏模型高精度版，或 32B 尽量往上的稠密模型。这四张 A100，2 张主力跑 LLM 模型和框架，1 张用于 OCR 和向量检索嵌入，推荐先用传统 OCR 处理（比如 PaddleOCR 之类的），不推荐直接用 VLM 模型进行识别，总之尽量不要在第一步就引入 LLM 的幻觉），再搭配内外部知识库的 RAG 进行修正和降低幻觉，另外 1 张留给 KV 缓存和上下文，FlashAttention 建议打开，这东西在长上下文里对显存吞吐都有不少提升。另外，235B 有点太大了，没有多少冗余了。

你要是还有精力，还可以根据你们公司内部的专门需求折腾下 Agent 。
开始搭建好环境和框架之后，先搞几个 10B 左右的小模型测试一下，然后再换主力模型，这样稳一点。