我也分享一下kimi-k2.6，glm-5.1，gpt-5.4和sonnet-4-6的python小项目对比

问题描述：

---

省流版: gpt-5.4 high > glm-5.1 > sonnet-4-6 = kimi-k2.6 > gpt-5.4 xhigh
结果也是非常暴论了。

昨天看了 @smallmain 佬的k2.6真实项目评测，发现语言选择可能会造成结果不太一样，正好最近要开一个新项目，想着用不同模型来初始化一下对比看看。

我在的公司是个极其小众行业的公司，北美个位数的同行，全球不超20家同行，技术栈很杂乱，上古项目有delphi，foxpro，C#，C++，Perl等等，最近这几年逐渐全面转python，go和TS了。我之前也给PSF外围项目打过工，看过非常多的python代码，所以心中有一个自己的“标准答案”，这个帖子的结论非常主观。

脱敏prompt

# BM Django Backend This project is the backend that serves API endpoints for the frontend named BM. Currently the project repo is empty. Create a Django application for the backend. ## Technical Stacks - uv: use uv as the python package and environment manager, do not use vanilla python or pip. - just: use the package `just` (which is available as a system-wide command) and create a `justfile` in this repo to store all the custom commands that help the DevOps process. - python version: Python 3.12 - database: MSSQL with ODBC 18 as the driver. You can use the mssql-django package as the Django database driver. - Frameworks: Use Django (latest) as the web application framework and latest DRF as the API framework. - Git tools: This project will be hosted in Bitbucket using Git. Use the bitbucket-pipelines.yml file to define the Bitbucket pipelines. Upon pushes to any branch, the pipeline should trigger a custom step named runUnitTest that runs all the Django unit tests. - Docker: this project needs to be packaged as a Docker image using a Dockerfile. Use Debian 13 based UV image as the base. - Deployment: this application will be hosted on a Kubernetes cluster with a custom domain. You do not need to worry about the Kubernetes setups or any Helm charts for now but assume that all code should be compatible with Debian 13 based docker images. ## Django Setups - any secret or credential needs to be exposed as an environment variable. - The frontend will be hosted at bm.my-company.com. - We will use Graph API to send out emails. Leave placeholders for the GRAPH API credentials. - Use MSODBC driver 18 for the database. Connection timeout set to 5 seconds. - MS SSO is needed, use django-azure-auth package (MS Entra), leave placeholders for the SSO settigns. - Use database as the cache backend, cache timeout defaults to 60 secs. Keep in mind that later on the cache would be moved to redis. ## Project Layout - app "auth": Extend the Django user model: 1. Remove the need for the username field. 2. Use email as the username field. - app "backend_api": The API router, all API URLs should be exposed through this app under `/api/v1/` - app "warehouse": All warehouse related views/functions live in this app, including API views. Although the final API URLs/router should still be in "backend_api" app. - app "client": same as "warehouse" app, all client related views/functions here. ## Models/Modules This app manages our client info, each client's warehouse stocks and tracks warehouse stock paths. We provide APIs to the forntend to fetch information like user info, client info, and stock status. All models mentioned below should have admin panels mapped. No delete is allowed, use soft-deletion. Each model should have timestamps to record when the record is created or updated. ### Models and API Views #### Users Model fields: email (unique), password, fullname (nullable), profile_image (remote url, nullable) API Views: CRUD, with an additional action of `/api/users/deleted/` that lists all soft-deleted users. #### Permission Use Ddjango permission system. User by default does not have any permission. The permission system should be initialized with can_create, can_modify, can_read, and can_delete permissions for each warehouse or client model. #### Warehouse Model fields: name (unique, max 100 char), client (FK to client object), location (max 200 char, nullable), country (max 2 char, ISO 3166 alpha-2 values), sku_count (int, no negative values) API Views: CRUD, with a custom action of `/api/warehouse/low_sku/` to list all warehouses with sku_count less than 100. #### WarehouseSKU Model fields: sku (unique, max 50 char), sku_name (max 200 char, nullable), last_restock (timestamp, nullable), warehouse (FK to Warehouse), item_count (int, no negative), item_count_unit (max char 20, defaults to "Unit") API Views: CRUD, with custom action of `/api/warehouse/{warehouse_id}/low_stocks/` to list all sku items with item_count less than 10,000. #### Client Model Fields: client_name, client_email, client_address API Views: CRUD ...其他行业相关细节不做展示

这个项目初始化流程非常简单，就是很基础的auth+CRUD，容易踩坑的地方有

• ODBC 18用MS官方的mssql-django包，需要关闭pyodbc的pooling以防和Django ORM的pooling管理冲突，不关闭短期不会出现什么问题但长时间运行或数据库高并发会时，底层pyodbc会复用dead connection导致health prob失败。这个问题只有少数github issues有过讨论，但模型思考数据库设置并查询文档的话是可以查到的。
• prompt并未指明web server选择，但现在基本都是用daphne，过去的gunicorn或者uvicorn利用率已经逐渐减少了，这项主要看训练数据清洗程度和模型是不是会同步知识库更倾向新且稳定的工具
• 提供了tavily和context7工具，prompt明确要求最新Django和DRF，模型应该主动查询最新版本号和changelog。Django 6相较于Django5或更早版本有几个breaking changes
• 因为指明了用uv，模型应该也采用ruff做format check/linter
• 在未指明测试框架时，Django项目应直接用Django test API而不是pytest或其他同类工具（因为Django已有工具，模型不该自作主张）
• 权限直接利用Django的权限系统，prompt也已经指明应该init权限，有几种实现方式无关对错
• migrations应该直接用Django的命令生成，而不是由模型自作主张写（说的就是你，claude），模型写出来的往往有migration冲突，尤其对于已有项目的更新维护这项对于Django来说是个重大灾难
• prompt已经指明前端host，CORS和CSRF应该按照前端host设置，并且同时考虑开发流程，allowed_hosts，CORS和CSRF应该在DEBUG=True时同时添加 localhost/127.0.0.1
• prompt虽然提及了cache相关设置但并未说明任何代码应该利用cache，所以模型应该在settings.py中预留cache设置但不主动给我把任何东西扔进cache里

结果

所有模型均接入opencode保证环境统一，没有omo或者omo-slim挡路。

下面展示的tree结构都删去了可能和公司有关的文件或文件夹，只展示Django相关的东西

kimi-k2.6（自己买的官方订阅）max thinking（opencode里叫max，貌似官方没有这个思考档位？）

❯ tree -I "__pycache__" -L 4 . ├── bitbucket-pipelines.yml ├── Dockerfile ├── justfile ├── pyproject.toml ├── src │ └── bm_django_backend │ ├── auth_app │ │ ├── __init__.py │ │ ├── admin.py │ │ ├── apps.py │ │ ├── managers.py │ │ ├── migrations │ │ ├── models.py │ │ ├── serializers.py │ │ ├── tests.py │ │ └── views.py │ ├── backend_api │ │ ├── __init__.py │ │ ├── admin.py │ │ ├── apps.py │ │ ├── migrations │ │ ├── models.py │ │ ├── tests.py │ │ ├── urls.py │ │ └── views.py │ ├── bm_django_backend │ │ ├── __init__.py │ │ ├── asgi.py │ │ ├── settings.py │ │ ├── urls.py │ │ └── wsgi.py │ ├── client │ │ ├── __init__.py │ │ ├── admin.py │ │ ├── apps.py │ │ ├── migrations │ │ ├── models.py │ │ ├── serializers.py │ │ ├── tests.py │ │ └── views.py │ ├── common │ │ ├── __init__.py │ │ ├── apps.py │ │ └── models.py │ ├── db.sqlite3 │ ├── manage.py │ └── warehouse │ ├── __init__.py │ ├── admin.py │ ├── apps.py │ ├── migrations │ ├── models.py │ ├── serializers.py │ ├── tests.py │ └── views.py └── uv.lock

耗时13m21s

一次跑通，pooling没关，选择了gunicorn做web server。

把代码放进了src文件夹里（kimi写JS上瘾了？），这个结构在Django中不算主流，以至于justfile和Dockerfile中所有命令都有个先cd进src的操作，浪费token并且没有实际好处，如果想提取这个项目做一个可以复用的Django插件的话要大费周章。

CORS和CSRF没添加localhost，前端本机测试时需要手动添加。

权限init都被写在了各自的init里，也算是合格，但是浪费启动时间。

写了个custom permission class并且在API view中复用了，这点好评，没有不断的monkey patch每个DRF view。

因为我没有提供mssql的任何东西，所以kimi选择用sqlite做fallback跑测试。

个人感觉 - 已经非常能用了而且跑的很快，有些东西需要对Django和sql server比较熟悉踩过坑才能知道，文件夹结构是个大问题，无论手动还是让模型去除src文件夹都要花很多时间而且很多东西要改。如果没有src的话可以给个9/10分，但现在只能说是7分水平（再次提醒，结论非常主观）。

gpt-5.4（公司的Azure Foundry账号API接入）xhigh thinking

其实平时都是用high，但是想着这篇帖子不用xhigh的话会被很多人说为什么不xxx，索性干到了xhigh。

又一次验证了xhigh的经典行为-左右脑互搏了55分钟才开始写代码，看思考过程大部分真的是完全没必要，毕竟这个项目这么简单。比如中间花了十几分钟思考azure_auth包只写了兼容DJango 3以上，它左右脑互搏了半天我们用django 6是不是会有问题。有这个时间直接调用context7问一下Django 4/5/6的breaking change不更直接吗？最后思考了十几分钟结论是"I should follow the instructions and research for solution if the user encounters any problem"?那你思考半天干蛋呢？

另外在开始写代码之前，看到我提供了ccc skill（cocoindex code），还用ccc给我init并且索引了一下repo，我都说了这个文件夹是空的。。。

❯ tree -I "__pycache__" -L 4 . ├── apps │ ├── __init__.py │ ├── auth │ │ ├── __init__.py │ │ ├── admin.py │ │ ├── apps.py │ │ ├── forms.py │ │ ├── managers.py │ │ ├── migrations │ │ │ ├── __init__.py │ │ │ └── 0001_initial.py │ │ ├── models.py │ │ ├── serializers.py │ │ ├── signals.py │ │ ├── tests.py │ │ └── views.py │ ├── backend_api │ │ ├── __init__.py │ │ ├── apps.py │ │ ├── migrations │ │ │ └── __init__.py │ │ └── urls.py │ ├── client │ │ ├── __init__.py │ │ ├── admin.py │ │ ├── apps.py │ │ ├── migrations │ │ │ ├── __init__.py │ │ │ └── 0001_initial.py │ │ ├── models.py │ │ ├── serializers.py │ │ ├── tests.py │ │ └── views.py │ └── warehouse │ ├── __init__.py │ ├── admin.py │ ├── apps.py │ ├── migrations │ │ ├── __init__.py │ │ └── 0001_initial.py │ ├── models.py │ ├── serializers.py │ ├── tests.py │ └── views.py ├── bitbucket-pipelines.yml ├── bm_backend │ ├── __init__.py │ ├── asgi.py │ ├── common │ │ ├── __init__.py │ │ ├── admin.py │ │ ├── models.py │ │ ├── permissions.py │ │ └── validators.py │ ├── settings.py │ ├── urls.py │ └── wsgi.py ├── Dockerfile ├── justfile ├── manage.py ├── pyproject.toml ├── scripts │ └── ensure_database.py └── uv.lock

总耗时1h18m（真有你的）

两次跑通，除了我提到的包之外，gpt还给我引用了一堆其他包，其中两个没有在pyproject中写明dependency。在测试中用了大量的patch模拟返回，并且在function中间做import所以这两个missing package在runtime未报错。我自己看了一遍代码，IDE也提示找不到这个包才发现的这个问题。大概率如果不看的话要一直等到调用相应的API才会触发这个低级错误。

pooling没关，整体文件夹结构是大概十年前很流行的一个repo放前后端的结构，也就是说我的prompt被理解成我会把前端集成到同一个repo中。

写了大量的自定义权限检查，但是绝大多数都可以用Django自带的几口一行搞定，属于是非常无用功。

只写了mssql的数据库设置，并且所有东西都暴露成env var了，但是并没问我数据库地址/用户名/密码，数据库“无法连接”，gpt一开始不断尝试跑测试均为失败。后来又思考了几分钟发现我有docker，就用docker给我跑了个sql server跑测试，并且也发现了1433端口被占用所以选择了14333接口。然而你都发现了1433被占用了并且docker ps显示sqlserver，你问问我本地数据库密码不好吗？

权限init利用了Django signals做hook，这个简单的任务调用这么重的接口属实没什么必要，会拖累启动速度。

Dockerfile写的杂乱无章并且ODBC被安装了两次。容器启动用的是自定义just命令但是没安装just。真要部署的话还是需要再来一轮review。

总体来说gpt还是干的不错的，我的要求基本都达到了，跑失败也是因为依赖缺失，只要prompt规定严格按照PEP8和black格式的话，这个问题应该可以在一开始被gpt发现并修复。给个6分。如果你不是专业写代码的人，用gpt还是可以保证东西能跑的，后续维护另说了（大概率步龙虾后尘）。

gpt-5.4 high thinking (应 @vriancao 佬的要求）

仍然为opencode接入，保持变量。

❯ tree -I "__pycache__" -L 4 . ├── accounts │ ├── __init__.py │ ├── admin.py │ ├── apps.py │ ├── azure.py │ ├── managers.py │ ├── migrations │ │ ├── __init__.py │ │ └── 0001_initial.py │ └── models.py ├── backend_api │ ├── __init__.py │ ├── apps.py │ ├── serializers.py │ ├── tests.py │ ├── urls.py │ └── views.py ├── bitbucket-pipelines.yml ├── client │ ├── __init__.py │ ├── admin.py │ ├── apps.py │ ├── migrations │ │ ├── __init__.py │ │ └── 0001_initial.py │ └── models.py ├── common │ ├── __init__.py │ ├── admin.py │ ├── apps.py │ └── models.py ├── config │ ├── __init__.py │ ├── asgi.py │ ├── settings.py │ ├── urls.py │ └── wsgi.py ├── Dockerfile ├── justfile ├── main.py ├── manage.py ├── pyproject.toml ├── README.md ├── uv.lock └── warehouse ├── __init__.py ├── admin.py ├── apps.py ├── migrations │ ├── __init__.py │ └── 0001_initial.py └── models.py

总耗时34m22s

和xhigh一样，自己又建了一个sqlserver container跑测试。初始创建项目没有用django命令而是自己开始调用bash新建文件夹和文件，导致项目主文件夹被命名成了config，一般来说Django会把主文件夹命名成和项目一样的名字，这点比较奇怪，应该是参考了知识库里某些AI生成的项目。

pooling也没关，但是考虑到其他模型都有这个问题，这个就不算问题了。同样用的是gunicorn。

justfile写的也有点奇怪

set shell := ["zsh", "-cu"] manage *args: export UV_CACHE_DIR=/tmp/uv-cache && if [ -f .env ]; then set -a && source .env && set +a; fi && uv run manage.py {{args}} fmt: ruff format . ruff check --fix . test: export UV_CACHE_DIR=/tmp/uv-cache && if [ -f .env ]; then set -a && source .env && set +a; fi && uv run manage.py test --noinput makemigrations: export UV_CACHE_DIR=/tmp/uv-cache && if [ -f .env ]; then set -a && source .env && set +a; fi && uv run manage.py makemigrations migrate: export UV_CACHE_DIR=/tmp/uv-cache && if [ -f .env ]; then set -a && source .env && set +a; fi && uv run manage.py migrate

这个明显是跑命令是撞到了opencode的sandbox，只能把uv cache换到一个可写入的地方。但是justfile的工作方式会自己生成一个子shell跑命令，即使模型调用也不会撞sandbox。这波不属于错误但想多了。

除此之外基本是一个非常完美Django起手架构，没有真实的错误可挑。结构漂亮，权限完全按照Django标准设置并初始化，所有引用包都是最新并且调用了context7检查breaking change是否影响包，pyproject的全套命令都是astral的工具-uv，ruff，ty。

因为提及了部署到k8s还给我加了个health prob的API方便helm chart定义。CORS和CSRF没有添加localhost但是相比于其他模型或xhigh终于把这两项也暴露成了env变量，并且给我创建了一个.env把这两项留空了。

unit test写的比xhigh少但是基本测试覆盖到了。

拿来直接用的话只需要改动几个地方，复用也简单。个人这波给9分。

high和xhigh渠道/prompt/工具全部一样，这两种完全不同的结果其实很符合我平时用codex的体感（codex也是接入AZ Foundry，不是官方订阅），xhigh思考太多以至于几乎次次跑偏，无用功太多而且左右脑互搏的时候会把正确答案消除。high反而比较稳定的完成任务，画蛇添足的地方也比较少。gpt唯一的缺点就是慢，如果一天里要添加好几个feature可能下班了它还没跑完。

Claude-sonnet-4-6 （公司提供的GH Copilot接入）high thinking

选择sonnet是因为这个月的copilot限额已经没多少了，应该跑不完opus，我也不想自费接入openrouter或者用自己的订阅，看个乐子吧（虽然我真心觉得这么简单的东西没必要上opus）

最开始的思考过程中思考了一会ODBC 18和Debian 13的兼容性，但是没利用任何工具去自己查询一下，最后思考的结果是

Actually, I should stick with what the instructions ask for—Debian 13/Trixie—even if the Microsoft repository might not have a prod.list for it yet. If it doesn’t exist, the user can adjust, but I’ll follow the spec as given.

怕是你也蒸馏过gpt吧？

❯ tree -I "__pycache__" -L 4 . ├── apps │ ├── __init__.py │ ├── backend_api │ │ ├── __init__.py │ │ ├── apps.py │ │ └── urls.py │ ├── client │ │ ├── __init__.py │ │ ├── admin.py │ │ ├── apps.py │ │ ├── migrations │ │ │ └── __init__.py │ │ ├── models.py │ │ ├── serializers.py │ │ └── views.py │ ├── core │ │ ├── __init__.py │ │ ├── admin.py │ │ └── models.py │ ├── users │ │ ├── __init__.py │ │ ├── admin.py │ │ ├── apps.py │ │ ├── managers.py │ │ ├── migrations │ │ │ └── __init__.py │ │ ├── models.py │ │ ├── serializers.py │ │ └── views.py │ └── warehouse │ ├── __init__.py │ ├── admin.py │ ├── apps.py │ ├── migrations │ │ └── __init__.py │ ├── models.py │ ├── serializers.py │ └── views.py ├── bitbucket-pipelines.yml ├── bm_backend │ ├── __init__.py │ ├── asgi.py │ ├── settings.py │ ├── urls.py │ └── wsgi.py ├── Dockerfile ├── justfile ├── manage.py ├── pyproject.toml └── uv.lock

总耗时22m5s

pooling没关，因为没有数据库密码测试也没跑（手动测试可以跑通，test有失败，失败原因是因为test写错了而不是代码有问题）。

权限init完全没做，也是选择了gunicorn做web server，在系统有全局ruff的情况下仍然把ruff添加进了dev dependency，多少有点画蛇添足。

BB pipelines里面后端host直接写死localhost。但是Dockerfile是所有模型里写的最好最简洁并且每一行都有意义的。

评分7分，尤其权限问题扣大分。

glm-5.1 （公司提供的海外版订阅，溢价好几倍那玩意）glm接入opencode无thinking level

起手就把提到的包用context7查了一遍。5.1也出现了经典的左右脑互搏，本来思考的蛮不错的然后开始质疑自己，质疑质疑着就跑偏然后思考的越来越多。但幸亏非高峰期glm输出快，整体时间还是可以接受的，带薪上个厕所就差不多了。

权限问题 - glm在思考过程中直接点名可以在model的Meta class中利用permissions来让Django自动在migrate过程创建permissions，是唯一一个直接利用Django自带方法解决权限建立问题的。

整体思考了没一会就开始写代码了，并且很快写完开始尝试runserver，跑了几次均有失败开始自动改正，改完之后最终跑起来了结束。

❯ tree -I "__pycache__" -L 4 . ├── auth │ ├── __init__.py │ ├── admin.py │ ├── apps.py │ ├── management │ │ ├── __init__.py │ │ └── commands │ │ ├── __init__.py │ │ └── init_permissions.py │ ├── managers.py │ ├── migrations │ │ ├── __init__.py │ │ └── 0001_initial.py │ ├── models.py │ ├── serializers.py │ ├── tests.py │ └── views.py ├── backend_api │ ├── __init__.py │ ├── admin.py │ ├── apps.py │ ├── migrations │ │ └── __init__.py │ ├── models.py │ ├── tests.py │ ├── urls.py │ └── views.py ├── bitbucket-pipelines.yml ├── bm_backend │ ├── __init__.py │ ├── asgi.py │ ├── base.py │ ├── settings.py │ ├── urls.py │ └── wsgi.py ├── client │ ├── __init__.py │ ├── admin.py │ ├── apps.py │ ├── migrations │ │ ├── __init__.py │ │ └── 0001_initial.py │ ├── models.py │ ├── serializers.py │ ├── tests.py │ └── views.py ├── Dockerfile ├── justfile ├── manage.py ├── pyproject.toml ├── uv.lock └── warehouse ├── __init__.py ├── admin.py ├── apps.py ├── migrations │ ├── __init__.py │ └── 0001_initial.py ├── models.py ├── serializers.py ├── tests.py └── views.py

耗时13m20s

项目结构赏心悦目，想复用的话直接可以拿来用。glm是所有4个模型里唯一一个知道利用has_delete_permission来关闭admin删除按钮，并同时覆盖 model的delete func来做假删除的。

BB pipeline没在step里按照ODBC 18，也就是说测试跑不了，CICD会在第一步失败。然而glm没写任何测试，也算是闭环了。

Dockerfile一共就四步

FROM ghcr.io/astral-sh/uv:debian13 WORKDIR /app COPY pyproject.toml uv.lock ./ RUN uv sync --frozen --no-dev --no-install-project COPY . . EXPOSE 8000 CMD ["uv", "run", "manage.py", "runserver", "0.0.0.0:8000"]

且不说ODBC没有装，uv:debian13也并不存在，并且在Dockerfile中直接用development server也是无出其右的垃圾选手。

评分给个8分，完全没考虑生产环境但代码美观漂亮并且符合我的要求，不做无用功，想部署还是需要大面积改动CICD相关代码。

---

其实公司还提供了minimax，但是跑完gpt-5.4 xhigh 之后力竭了，算鸟。题外话-虽然大家很看不上minimax，但是我接触到的（美国中部）的大大小小的公司有一半都会给员工提供minimax，这个模型在不复杂的任务中好评率还是蛮高的。

总结

所有4个模型都有不同程度的不按我所想写代码的情况出现，只有gpt一个一次无法跑通（但也不是因为代码问题）。如果这个项目真的拿到生产环境中的话，所有模型给的结果都需要我再次告诉模型进行改动来符合最新的python规范或者方便后续维护。

再次叠甲-结论非常主观！对我个人来说，gpt的xhigh我可能永远也不会开，按照佬友的说法xhigh在debug中有奇效，然而我过去几次极端debug情况gpt xhigh都没能解决，可能纯后端或架构工作不是gpt擅长的领域。简单任务里现在各家旗舰模型差别真没有那么大，哪个快用哪个吧，复杂的东西谁家模型一次都解决不了，都需要和模型多次对话并且加入自己的思考来引导模型才能解决。

希望国模能别玩脏的也别过了发布期就降智，祝愿A\早日倒闭，谢谢。

网友解答：

---

--【壹】--：

这点我忘了说了 opencode subagents我们全关了，只用一个context window，如果有大项目我们人工分割成小项目（我们还在用古老的sprint方式做项目），所以每个小功能有个100k window都能做完，剩下的余量留给debug或人工审核优化。codex是我平时主力，用opencode是为了控制变量。

对于cc的话，不知原因在我们的其他项目里一直表现的不是很好，可能要Azure Foundry背锅？

AI这个东西确实是符合自己流程的才是最好的模型，之前公司提供过Anthropic的官方订阅，大家用的不积极就没有下文了。后台统计同事们用得最多的模型是minimax这种L站路边一条的东西

---

--【贰】--：

gpt大概率是吃了xhigh的苦，平时gpt是我的主力，high thinking下没惹出过这么大笑话，xhigh反倒成了负优化，思维太发散导致畏手畏脚。glm5/5.1在prompt够细的情况下表现一直不错，就是太吃细节，如果想一两句话做个功能基本无望

---

--【叁】--：

不妨试一下让GPT回到Codex中跑，也许效果会好一些

xhigh我这边一直很靠谱，GPT自己也倾向于自行解决各种问题，它能想到起一个MySQL做测试，应该不至于不会装依赖。

然后GPT指令跟随是强项，要显性的强调利用MCP工具，勤使用，不要犹豫etc. 通过这种提示GPT就会改善习惯

另外如果GPT面对古老的东西表现似乎要比其他模型更好，我之前X上看到有个人让GPT-5.4自主探索分析然后制作了一个80年代东西的驱动，其他模型完全迷茫不知道该干嘛，只有GPT搞定了

---

--【肆】--：

非常有价值的测试！感谢佬友提供的宝贵经验！

另外想问问可以用GPT-5.4的其他档位跑一次试试看么？

---

--【伍】--：

我的GLM5.1在opencode中跑, Sonnet4.6在Copilot中跑, 都非常懒, 非常傻, 远不如CC里面灵性, GPT也是, 在Opencode中喜欢乱调用General和Explore子代理总结, 总是漏代码, 漏东西.

把这俩丢CC, GPT丢Codex里, 感觉就完全不一样

---

--【陆】--：

肯定是比不了ACE的，毕竟ACE是拿来赚钱的。ccc会在本地跑一个小模型用来索引和搜索，数据不出去，对于有保密需求的商业项目更适合。query出来噪音会比较多，要不就是没rerank要不就是rerank模型太拉，不过拿来给各家旗舰模型来单纯的做代码搜索够用了，多费一些token，总归是比grep一堆文件+读取理解来的省

---

--【柒】--：

k2.6没试过，glm 5.1 是真不行。综合肯定不如gpt5.4

---

--【捌】--：

cocoindex 好像很有意思，刚 1.0 了。code search 比起 ACE 呢？

---

--【玖】--：

我看了它文档，full 模式的那个模型肯定很拉，最早 openwebui 也是用它做 embeddings, 根本没有实用价值。ccc 用 lite 模式安装的话也可以用三方 embeddings 嘛，比如 voyage. 我一直想扔掉 ACE，总归是要把索引建到别人那。。

---

--【拾】--：

没想到你的项目 glm 这么强，gpt 5.4 这么拉。

不过实践检验就是好，多来点！