昨天看了 @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还是可以保证东西能跑的，后续维护另说了（大概率步龙虾后尘）。
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\早日倒闭，谢谢。
1 个帖子 - 1 位参与者