回顾前文 Harness 工程的基本理解与Multi-Agent系统的区别 本人目前使用最频繁的模型，本篇博客接替上门继续讨论编程大模型： deepseek-v4-pro[max] sonnet 4.6[web] qwen3.6-plus glm-5 后两个模型为gc模型，不在本次讨论范围内，不过会作为背景板提到一点。 大模型的缺陷 什么是大模型的缺陷，我认为这个是因人而异的，因为有需求才会有缺陷，没有需求等于没有缺陷。那我的需求是什么，四个字—— 写好代码 。可这四个字背后藏着的可不止四个字，我自己尝试去理解，大概能翻译出来以下几种意思。 代码能编译成功不报错 代码能真正实现功能 代码能模块化、完整度高 代码能实现业务功能 前端代码不仅页面设计好看、而且要交互体验好、还能跟后端接口顺利对接保持数据正确传递 后端代码不仅性能优秀、还要能良好处理数据存储、线程并发、顺利通过接口与前端交互 然后即使上面这6项要求，很遗憾地告诉大家，前面提到的4个模型，没有一个是能全面达到的，困难点几乎都在是后面三点。 不过deepseek-v4不知道是不是灰度加强了，第一天、第二天是达不到的，从4.28后开始，也就是第三次deepseek发福利延长到5月底的时候，以上6项已经全部满足。 那好，我们发现了的大模型的第一个缺陷——编程能力不足。上一篇博客也提到，Harness 是编程大模型的IDE，专门为编程大模型打辅助，即使我们发现了第一项，我们就需要去干活了，不过在干活之前，我们还要知道怎么干，所以我们需要分析分析（猜测猜测）大模型是因为什么导致的这些问题。 由于前三个问题，4个大模型基础都能满足，就不多占用文字了。后面三个为什么达不到，我猜测为以下原因： 人员自身问题 （问题4）：需求不明确、需求冲突但模型没提问，将计就计 模型不够聪明或自以为是 （问题4）：模型理解能力不够或突破上限，导致实现与需求对不齐 模型代码库有限 （问题5、问题6）：模型代码模板就那些，或预训练代码为低质量代码 逻辑创新不够 （问题1-6）：不关于结合上下文编写代码，或者说写代码死板 那好，我们已经 尝试 找到原因了，那我们就来 尝试 使用Harness的手段进行修复吧。首先我们来复习下，Harness 最简化工程分为三个阶段：规划（planner）——生成（generator）——验证（evaluator），两相对比下来，经常写智能体的专家，立马就知道如何下手了，那我就在这说一种最简单的方式： 规划（planner） 我们需要在planner的提示针对以上4个问题去强调： ### 角色定义 你作为一个规划师，你最重要的是严格遵守用户确认过的需求，不能再有其它发散balabala 如果你依旧觉得无法形成闭环，需求不明确，可再次向用户提问balabala ### 操作规范 你要深知，大模型的逻辑能力不够，你需要给到明确的规划，比如设计定义、接口文档、业务核心流程定义，不要尝试给模型发挥的空间，模型是个捣蛋鬼balabala 生成（generator） ### 角色定义 你作为整个工程最核心的环节，你一定不能出错，认真读取Planner的定义，严格执行，模型给你的代码，你需要深度思考，是否匹配，如果不匹配，需要打回直到契合业务balabala ### 操作规范 大模型最不擅长的就是前后端对接部分，而且大模型给你的代码质量并不一定就是可行的，你一定要看清楚每一行代码，你一定要看清楚接口文档去实现，否则这块代码将会影响整个工程的不可用，后果极其严重balabala 验证（evaluator） ### 角色定义 你是整个工程的质量检验员，过了你这一关，就直面用户了，一定要把好关，不能让不良工程，出自你的手。你要永久的辨证去看待每一个功能，不能留有一丝余地balabala ### 操作规范 大模型会有逃逸和偷懒的形为，你要始终提高警惕balabala 可以发现，我是 尝试 在harness的所有维度都去做了相关工作，由于大模型的不可控性，我们也只能尽可能的去弥补大模型的弱点。而这时我们就知道，什么大模型对我们来说，才是好模型，问题点越少，需要我们做得越少，那就是好模型。 到这里，我们就完成了一次harness 工程的迭代，发现大模型的缺陷——思考与规划——优化harness流程——得到一个新版本的harness。 1 个帖子 - 1 位参与者 阅读完整话题