ECC Kiro django-reviewer 实战指南面向 Django 生产级质量的 AI 代码评审 AgentORM、DRF、迁移与安全检查【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECCECCEverything Claude Code仓库在.kiro/agents/目录下提供了一套可直接安装到 Kiro 的 AI Agent 配置其中 django-reviewer 是专门针对 Django 项目的代码评审专家。本文以该 Agent 的定义文件为核心完整拆解它的触发流程、按严重级别分层的评审清单安全、ORM 正确性、迁移安全、DRF 模式、性能、代码质量与测试缺口、诊断命令与批准标准并结合仓库中配套的 django-patterns 与 django-security 技能说明每一项检查背后的正确写法。读完本文你可以将这套 Django 评审流程安装到自己的 Kiro 项目并理解每一条检查项对应的手动排查方法。django-reviewer 在 ECC Kiro 体系中的定位ECC 的.kiro/目录是一套可分发的 Kiro 工作流包.kiro/README.md 中给出了组件清单——33 个 AgentJSON 与 MD 双格式、43 个 Skill、22 个 Steering 文件、13 个 Hook 与 2 个脚本可通过安装脚本一次性注入任意 Kiro 项目# 进入 .kiro 目录 cd .kiro # 安装到指定项目 ./install.sh /path/to/your/project # 或安装到当前目录 ./install.sh # 或全局安装作用于所有 Kiro 项目 ./install.sh ~从 install.sh 源码看安装器对agents、skills、steering、hooks、scripts、settings六个子目录做“非破坏性拷贝”仅当目标文件不存在时才复制因此你安装后对 Agent 提示词的任何定制都不会被重装覆盖。在 Agent 清单中.kiro/README.md 将django-reviewer描述为 “Django code reviewer. ORM patterns, DRF, migrations, and Django security.”。它的使用方式有两种来自该 READMEIDE 中在 Kiro 会话里输入/django-reviewer显式调用CLI 中/agent swap切换到该 Agent或直接kiro-cli --agent django-reviewer启动。同一仓库还在根目录维护了一个更长的 agents/django-reviewer.md面向 Claude Code 等其他 harness两者评审清单同源Kiro 版.kiro/agents/django-reviewer.md是本文主体。Agent 配置文件frontmatter 与工具权限.kiro/agents/django-reviewer.md的 YAML frontmatter 定义了 Agent 的基本契约--- name: django-reviewer description: Expert Django code reviewer specializing in ORM correctness, DRF patterns, migration safety, security misconfigurations, and production-grade Django practices. Use for all Django code changes. MUST BE USED for Django projects. allowedTools: - read - shell ---description向 Agent 调度层说明“何时使用”——所有 Django 代码变更都必须MUST BE USED经过该 Agent 评审allowedTools仅开放read读文件与shell执行git diff、manage.py check等诊断命令。这意味着该 Agent 是“只评审、不代改”的角色评审输出是问题清单而非自动补丁。同目录下的 django-reviewer.json 是同一 Agent 的 CLI 格式声明其中tools: [builtin]、allowedTools: [fs_read, shell]并且把整份 Markdown 提示词内嵌在prompt字段中——Kiro CLI 通过/agent swap加载 JSONIDE 则读取 Markdown双格式保证了两端行为一致。Agent 开头有一段重要约束Note: This agent focuses on Django-specific concerns. Ensurepython-reviewerhas been invoked for general Python quality checks before or after this review.即 django-reviewer 只负责 Django 框架层面的问题ORM、DRF、迁移、Django 安全配置通用的 Python 质量检查PEP 8、类型标注、异常处理、并发等由 python-reviewer 负责。两个 Agent 的“当被调用时”流程几乎一致都是先跑git diff -- *.py再看改动文件形成“通用 Python 检查 框架专项检查”的双层评审。评审触发流程被调用时的 7 个标准步骤文档的 “When invoked” 一节规定了 Agent 每次被调起后的固定动作序列执行git diff -- *.py查看最近改动的 Python 文件若存在 Django 项目执行python manage.py checkDjango 系统检查执行python manage.py makemigrations --check检测是否有模型改动尚未生成迁移检查迁移文件中的三类高危点RunPython操作缺少reverse_code迁移无法回滚对大表的数据迁移未做分批处理batching非外键的过滤列缺少db_indexForeignKey 字段自带索引无需重复标注若环境可用执行ruff check .与mypy .聚焦在改动的.py文件及与之相关的迁移文件立即开始评审。这套流程的设计意图很清晰先用确定性工具Django 系统检查、迁移检查、linter、类型检查器建立客观基线再由 LLM 做语义级审查避免评审 Agent 在“漏迁移”“缺索引”这类可机器判定的问题上浪费判断力。其中makemigrations --check尤其关键——它只检查“模型与迁移是否一致”而不生成文件是 CI 里防止“改了模型忘记生成迁移”这一经典事故的常用手段。评审优先级清单Review PrioritiesAgent 的评审标准按 CRITICAL / HIGH / MEDIUM 三级组织。以下完整继承原文档的每一条目并按级别展开讲解。CRITICAL — 安全这一级别的任何一条命中都足以阻断合并检查项说明与正确做法SQL 注入用 f-string 或%格式化拼接原始 SQL。必须使用%s参数占位或直接用 ORM对用户输入使用mark_safe未先显式escape()就标记为安全字符串等价于关闭 Django 的 XSS 自动转义无正当理由的 CSRF 豁免非 webhook 视图上使用csrf_exempt生产环境DEBUG True会向访问者泄露完整堆栈与配置硬编码SECRET_KEY必须从环境变量读取DRF 视图缺少permission_classes会回落到全局默认权限——必须确认这是有意为之文件上传未校验扩展名/大小存在路径穿越风险这些检查项在 django-security 技能中有对应的正反代码示例。例如 SQL 注入一栏# 危险直接插值用户输入 User.objects.raw(fSELECT * FROM users WHERE username {username}) # 正确参数化 User.objects.raw(SELECT * FROM users WHERE username %s, [username]) # 正确优先使用 ORM参数自动转义 User.objects.filter(email__iexactemail)XSS 防护一栏则要求“先转义、再标记安全”或使用format_htmlfrom django.utils.safestring import mark_safe from django.utils.html import escape, format_html # 危险 mark_safe(user_input) # 正确 mark_safe(escape(user_input)) format_html(span classuser{}/span, escape(username))而csrf_exempt的豁免只应保留给外部服务回调的 webhook 视图且应配合签名校验。CRITICAL — ORM 正确性数据丢失与静默异常是这一级别的主题循环中的 N1 查询在遍历中访问关联对象而未使用select_related外键/一对一或prefetch_related多对多/反向关系。配套技能 django-patterns 给出的对照示例# 坏每个 product 都触发一次 category 查询 for product in Product.objects.all(): print(product.category.name) # 好JOIN 一次取回 for product in Product.objects.select_related(category).all(): print(product.category.name)该技能还推荐用自定义 QuerySetProductQuerySet提供with_category()/with_tags()方法配合objects ProductQuerySet.as_manager()把这类优化固化到模型层而不是散落在各处 view 中。多步写操作缺少atomic()涉及多张表的写入序列必须包在transaction.atomic()里否则中途失败会留下半提交状态bulk_create未处理冲突主键/唯一键重复时的静默数据丢失风险应配合update_conflicts之类的冲突策略get()未处理DoesNotExist查无对象时抛出未捕获异常。CRITICAL — 迁移安全改了模型却没有迁移用python manage.py makemigrations --check验证非零退出码即代表有缺失破坏向后兼容的删列操作必须分两次部署——第一次先把列改为可空nullable第二次再真正删除避免滚动发布期间旧代码写新 schema 时报错RunPython缺少reverse_code数据迁移无法回滚生产事故时无法安全 downgrade。HIGH — DRF 模式Serializer 未显式声明fieldsfields __all__会把模型所有列可能含敏感列暴露给 API列表端点没有分页无界查询可能一次返回百万行缺少read_only_fieldsid、created_at等自动生成字段可被 API 写入认证端点没有限流登录/注册接口直接暴露于暴力破解。配套的 django-patterns 技能里有一个符合上述全部要求的 ViewSet 范式queryset上使用select_related(category).prefetch_related(tags)防 N1、显式permission_classes [IsAuthenticated, IsOwnerOrReadOnly]、通过get_serializer_class()区分创建/读取序列化器、用户上下文注入放在perform_create而非validate中。限流配置则见 django-securityREST_FRAMEWORK { DEFAULT_THROTTLE_CLASSES: [ rest_framework.throttling.AnonRateThrottle, rest_framework.throttling.UserRateThrottle, ], DEFAULT_THROTTLE_RATES: { anon: 100/day, user: 1000/day, upload: 10/hour, } }HIGH — 性能外键/过滤字段缺db_index过滤查询退化为全表扫描注意触发流程第 4 步中已说明ForeignKey 默认带索引这里主要指非 FK 的过滤列视图内同步调用外部 API阻塞请求线程应下沉到 Celery 异步任务len(queryset)代替.count()前者会把整个结果集取到内存再数长度存在性判断不用exists()if queryset:会无谓地拉取对象应写if queryset.exists():。django-patterns 技能中的索引示例展示了如何在Meta.indexes中为高频过滤/排序列建复合索引如[category, is_active]、[-created_at]这正是本条检查的修复手段。HIGH — 代码质量业务逻辑写在 view 或 serializer 里应下沉到services.py服务层django-patterns 中的OrderService.create_order示例即演示了“事务内的多表写入集中在服务层”的写法模型字段的可变默认值default[]/default{}是经典陷阱应写defaultlist/defaultdict热路径更新不带update_fields的save()大模型或高吞吐代码中更新个别字段时应传update_fields以避免写回全部列。文档同时注明对象创建与表单驱动的整体保存标准save()是正确的不必强加。MEDIUM — 最佳实践用print()代替日志应使用logging.getLogger(__name__)缺related_name反向访问器只能写成user_set可读性差硬编码 URL应使用reverse()或reverse_lazy()模型缺__str__Django admin 与日志可读性受损。MEDIUM — 测试缺口没有权限边界测试必须验证未授权访问返回 403/401缺pytest.mark.django_db访问数据库的测试不加该标记会抛出RuntimeError: Database access not allowed——测试会显式失败但错误信息在陌生场景下容易误读未使用 Factory测试里裸写Model.objects.create()脆弱且难以维护。诊断命令Diagnostic Commands文档为评审提供了可直接复制的六条基线命令覆盖系统检查、迁移一致性、lint、类型、安全扫描与测试覆盖率python manage.py check python manage.py makemigrations --check ruff check . mypy . --ignore-missing-imports bandit -r . -ll pytest --covapps --cov-reportterm-missing -q各命令的作用manage.py check运行 Django 系统检查框架可捕获 settings、模型、URL 配置错误makemigrations --check校验迁移与模型同步状态ruff做快速 lintmypy --ignore-missing-imports在缺少第三方类型桩时仍可完成类型检查bandit -r . -ll递归扫描仅报告中等及以上严重度-ll表示只显示 high 级以上的安全问题最后一条跑测试并输出逐行缺失的覆盖率报告配合“测试缺口”一节的检查项使用。批准标准Approval CriteriaAgent 的最终结论被压缩为三档Approve通过没有 CRITICAL 或 HIGH 级别问题Warning警告仅存在 MEDIUM 问题——可以合并但需谨慎Block阻断发现任何 CRITICAL 或 HIGH 问题。这套阈值与 .kiro/steering/review-mode.md 中定义的通用严重级别体系Critical 安全漏洞/数据丢失风险High 破坏功能/重大性能问题Medium 可维护性问题保持一致使得 django-reviewer 的输出可以直接并入 ECC 的整体评审模式。配套技能引用与评审闭环文档末尾的 Reference 一节指向两个技能作为深度参考skill: django-patterns→ 仓库内对应 .kiro/skills/django-patterns/SKILL.md根目录也有同源副本 skills/django-patterns/SKILL.md项目结构split settings、Model/QuerySet/Manager 设计、DRF Serializer 与 ViewSet 范式、服务层、缓存策略、Signals、中间件skill: django-security→ 对应 .kiro/skills/django-security/SKILL.md根目录副本 skills/django-security/SKILL.md生产 settings 安全头、认证授权、SQL 注入/XSS/CSRF 防护、文件上传校验、API 限流与安全事件日志并附一张可逐项打勾的 “Quick Security Checklist”。在 Kiro 的自动化层面还有一层呼应.kiro/hooks/python-lint-on-edit.kiro.hook 会在编辑*.py文件时触发askAgent检查据 .kiro/README.md 的描述用于尽早发现类型错误、PEP 8 违规与常见反模式而 django-reviewer 则承担提交前的完整框架级评审。也就是说ECC 的设计是“编辑时轻量提醒 提交前 Agent 深审 诊断命令兜底”的三段式质量闭环。总结把它作为你的 Django 质量门禁.kiro/agents/django-reviewer.md的本质是一份“可执行的评审制度”它把生产级 Django 项目最容易出事故的七类问题注入/密钥/CSRF 等安全配置、N1 与事务等 ORM 正确性、迁移不可逆、DRF 暴露面、查询性能、服务分层与可变默认值、权限测试缺口固化成带优先级的检查清单并规定了“先跑工具、后做语义评审、最后按 CRITICAL/HIGH/MEDIUM 三档给结论”的工作流。通过 install.sh 将其装入项目后任何一次 Django 代码变更都可以用/django-reviewerIDE或/agent swap django-reviewerCLI触发同一套评审且评审边界与python-reviewer明确切分与django-patterns/django-security两个技能形成“检查—修复参考”的完整引用链。该 Agent 的自我定位原文结尾值得作为团队的评审共识直接引用“Would this code safely serve 10,000 concurrent users without data loss, security breach, or a 3am pager alert?”这段代码能否在万级并发下安全运行而不发生数据丢失、安全漏洞或凌晨三点的告警——这正是整份清单所有检查项的验收标准。【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考