鹅厂员工觉得好的code模型应该具备什么能力？

▼

“懂得不写代码"的智慧

现在无论是claude还是gemini，在写代码时，会把你仔细交代的任务完成的很好，但前提是要明确把一些工具库跟它说清楚，否则它可能会放飞自我，虽然实现了，但其实多做了很多冗余工作，比如为了实现某个结果，中间要用缓存或者DB，自己实现了个缓存或Dao，但实际上大仓里就有现成的实现，它们往往不知道复用。。。

并且现在越来越感觉很多人觉得代码模型牛就是可以狂写代码，比如最近看到很多讨论说XX大模型Agent狂写代码XX小时不停歇。。

但我觉得其实Code最高级的能力是知道什么时候不该写。比如用户想实现一个功能，模型得能说"诶，你这需求其实某个库已经有现成的了，直接用就行"，或者"你这么搞会踩坑，换个思路吧"，或者”你是不是想达到xx目的，有一种模式更适合实现这个目的，这样改造会更好“。这种“懂得不写代码"的智慧 判断力比单纯生成代码难多了。

其实把LLM当作程序猿来评价就OK了，对于Code能力基本要求都差不多。但是LLM烧的是Token，可以一直高速输出，所以有些要求可以适度降低（时间换能力），大概列几条吧：

1、好的开始是成功的一半：要求LLM能理解用户的需求，这里不是说要模型多聪明，程序猿确定需求时也是不停沟通拉会来完善对需求的理解，所以不能说“LLM可以一句话”开发才是厉害，因为一句话也没多少信息。平时真实的工作都是很细节的，需要模型和用户之间达成确定共识。比较推荐的让LLM给一个plan，然后修改到符合用户预期。

2、良好的代码风格：有了架子就是填肉了，我是喜欢LLM输出可读性高的代码，长点和慢点都还好，不好读的话确实浪费用户的理解时间，而且一般可读性差的代码质量也堪忧。

3、优秀的代码调试能力：与其要求模型能一次写对，不如要求模型能把有错误的代码改好。因为模型可以高速的24小时运行，所以试错成本比程序猿要低很多。但这里要求这里是真的改好，而不是那种看到一个Error去加一个 try-except分支那种”叠垃圾“的方式。

4、这点不是对模型的要求：要有一个LLM友好的开发环境，能让模型很好串联穿上面三个过程。让LLM有足够的资源可以使用，最好还能帮助LLM做Context工程。

1.能看懂现有代码， 了解现有代码的习惯，生成代码时别瞎改风格。

2.  出了问题，能修bug，看报错能秒懂是哪儿错了，直接给改好。

还能帮忙优化代码，发现哪里重复、哪里慢，给你更优雅的写法。

 3. 不能胡编乱造，不知道就说不知道，别瞎编代码坑人。

对于AI代码辅助还不够理想的领域的话，现在最头疼的就是调试和修Bug这块。微软最近的研究显示，连Claude、GPT这些大模型在调试任务上的成功率都不到50%，有的甚至只有20%出头——一个bug修完冒出三个新bug，简直是"打地鼠"现场。

还有就是处理复杂业务逻辑的时候，AI容易"想当然"，它只会照着训练数据里的模式来，碰到你公司独特的业务规则，生成的代码往往差点意思。再加上它的上下文窗口有限，大项目里跨几个文件的改动，AI经常"丢三落四"，前面改了后面忘。

目前Claude新出的debug模式我认为是一个很不错的尝试，感觉可以多探索不同模式进行优化，只有更多的探索才能知道更好的方式

1.支持 200k 以上的上下文，codex模型已经支持400k上下文了；长时的异步任务会越来越多

2.function calling 高准确率；之前调过一些国内模型，在参数格式和要求上难以保证，这导致执行容易出错

3.高 Cache 能力；code 模型需要执行长任务，cache 比率会大大影响任务成本

4.低延时；这个自不必说了，在补全和NES场景下要求更高

5.Thinking 能力，需要能够做好规划和反思

6.多模态能力，随着编码范式的改变，语音和图片输入需求会越来越多；举例，页面程序UAT测试自动截图反馈场景

先做到以上，再在这个基础上继续迭代。

不懂就不懂，不要瞎说

现在的代码模型在写单个函数、小模块这些方面已经很强了，但一碰到工程级别的大项目，就很容易暴露短板。最明显的问题就是——架构层面的把控能力不足。

AI生成代码的时候，往往是"头痛医头"，你问它一个功能它就给你一段代码，但它很难站在整个项目的角度去思考模块划分、分层设计、依赖关系这些东西。一开始基础架构没搭好，后面越写越乱，最后就变成一坨屎山，重构的成本比重写还高。

所以我觉得一个真正好的 code 模型，除了基本的代码生成能力之外，还应该具备：

架构感知能力——能理解项目整体结构，生成的代码要符合当前项目的设计规范，而不是各写各的。

上下文一致性——在大工程里能保持命名风格、设计模式、模块职责的一致性，不要前后矛盾。

主动提醒和建议——比如发现你的设计有耦合过重、职责不清的问题时，能给出架构层面的优化建议。

所以，也说明架构设计能力短期内还是得靠人。AI可以当好帮手，但开发者自身的架构思维和工程素养，反而在AI时代变得更重要了