AI 编程工具已经进入开源项目的提交记录、代码评审和文档维护流程。对维护者来说，真正棘手的问题不再是“是否允许 AI”，而是如何界定贡献者责任、怎样衡量实际收益，以及 CMS 应该把哪些生成能力交给最终用户。
围绕 Wagtail 社区所面对的这些问题，可以整理出一套更具操作性的思路：不要按工具给贡献分类，而要按风险治理；不要只计算生成速度，而要追踪维护成本；不要把 CMS 中的生成按钮直接接到发布流程，而应把它设计成可审阅、可追溯的内容助手。
AI 生成了代码，责任仍然属于提交者
开源项目很难可靠判断某段代码是否由 AI 生成。即使能够判断，这个标签本身也不能说明代码质量。更可执行的规则是：贡献者必须理解、验证并对最终提交负责。
项目可以在贡献指南中明确以下边界：
- 允许使用 AI 辅助构思、生成测试、解释代码或起草文档，但提交者必须审阅结果。
- 不得把密钥、未公开漏洞、用户数据或受保密协议约束的代码发送给第三方模型。
- 如果 AI 显著参与了实现，提交者应披露使用范围以及自己完成的验证，而不必公开私人账号或无关的提示词历史。
- 许可证、版权来源和依赖关系仍需人工检查，不能把模型输出视为天然可用的原创代码。
- 身份认证、权限、数据迁移和安全修复等高风险改动，需要更严格的人工评审，不因测试通过而降低门槛。
可以这样改造仓库的 .github/pull_request_template.md：
## Change summary
Describe the problem and why this implementation is appropriate.
## Validation
- [ ] I ran the relevant tests and linters
- [ ] I reviewed every changed file
- [ ] I checked for secrets, personal data, and incompatible copied material
## AI assistance
- [ ] No generative AI was used
- [ ] Generative AI was used for this contribution
If AI was used, describe its scope and your verification:
- Tasks assisted by AI:
- Tests performed:
- Areas that need extra reviewer attention:
这份模板的重点不是给 AI 提交贴标签，而是把“我用了什么”转换为“我验证了什么”。维护者也不应因为贡献者勾选了 AI 选项就自动拒绝提交，或者反过来降低审查强度。
衡量 AI 效果，不能只看写代码有多快
AI 工具最容易展示的指标是生成速度，但这通常只覆盖开发流程的前半段。代码可能十分钟生成，却让维护者多花两小时确认边界条件。更合理的评估至少应覆盖四类指标：
- 交付效率：从开始处理到合并的时间、首次评审等待时间、修改轮次。
- 质量结果：回滚率、缺陷率、测试失败率，以及合并后短期修复次数。
- 维护者负担：评审时间、解释需求的次数、重复关闭低质量提交的成本。
- 参与体验：新贡献者是否更容易完成首次提交，资深维护者是否认为工作流得到改善。
下面的标准库脚本可以对一份简单的 PR 数据做初步分组。它不能证明 AI 导致了结果变化，但适合建立基线。
先创建 pr_metrics.csv：
pr_id,ai_used,lead_time_hours,rework_commits,merged
101,yes,6.5,2,yes
102,no,9.0,1,yes
103,yes,4.0,5,no
104,no,12.0,2,yes
105,yes,7.5,1,yes
再保存以下脚本为 ai_metrics.py：
#!/usr/bin/env python3
import csv
import statistics
import sys
from collections import defaultdict
path = sys.argv[1] if len(sys.argv) > 1 else 'pr_metrics.csv'
groups = defaultdict(list)
with open(path, newline='', encoding='utf-8') as file:
for row in csv.DictReader(file):
group = 'AI-assisted' if row['ai_used'].lower() == 'yes' else 'No AI disclosed'
groups[group].append({
'lead_time': float(row['lead_time_hours']),
'rework': int(row['rework_commits']),
'merged': row['merged'].lower() == 'yes',
})
for name, rows in sorted(groups.items()):
merge_rate = sum(item['merged'] for item in rows) / len(rows) * 100
median_lead = statistics.median(item['lead_time'] for item in rows)
median_rework = statistics.median(item['rework'] for item in rows)
print('{}: n={}, merge_rate={:.1f}%, median_lead={:.1f}h, median_rework={:.1f}'.format(
name, len(rows), merge_rate, median_lead, median_rework
))
运行：
python ai_metrics.py pr_metrics.csv
解读结果时需要谨慎。AI 辅助组可能包含更多新手任务，也可能集中在文档和测试等低风险改动。更可靠的分析应按贡献者经验、PR 类型、改动规模和模块风险分层，并观察数周或数月，而不是根据少量 PR 宣布效率提升。
CMS 用户需要的是可控助手，而不是自动发布器
对于 Wagtail 这类内容管理系统，生成式功能的价值通常来自具体编辑任务，而不是提供一个无边界聊天框。可以优先验证这些场景：
- 根据已有正文生成摘要、标题候选和元描述。
- 为图片起草替代文本，再由编辑结合上下文确认。
- 按站点风格改写段落，同时保留原文对照。
- 建议标签、内部链接或内容分类。
- 起草翻译版本，但明确标注机器生成状态。
设计这些能力时，生成操作不应直接绕过 CMS 原有的权限和审批流程。一套较安全的工作流可以是：
feature: summarize-page
input:
fields:
- title
- body
exclude:
- author_email
- unpublished_notes
output:
target_field: summary
mode: suggestion
controls:
require_human_acceptance: true
allow_direct_publish: false
store_model_name: true
store_prompt_version: true
keep_before_after_diff: true
这只是可改造的策略示例，并非 Wagtail 的现成配置格式。它体现了几个关键约束：只发送必要字段、默认生成建议、保留前后差异，并记录模型与提示版本。这样才能在内容出错、风格漂移或供应商升级模型时追溯原因。
还要特别处理三类风险：
- 事实与品牌风险：摘要和改写可能添加原文不存在的信息，编辑界面应提供来源对照与差异视图。
- 数据治理风险：未发布内容可能包含商业计划或个人信息，需要明确数据是否被第三方保留或用于训练。
- 成本与可用性风险：模型 API 可能限流、涨价或中断，CMS 的核心编辑和发布能力不能因此失效。
一套适合逐步落地的检查清单
开源项目不必一次制定完美的 AI 政策。更稳妥的方式是先选择一个低风险范围，收集数据，再根据实际维护成本调整规则：
- 在贡献指南中声明责任、隐私和许可证要求。
- 让贡献者披露 AI 的使用范围与验证方式，而不是提交完整聊天记录。
- 对文档、测试与核心安全代码采用不同的评审强度。
- 同时记录交付时间、返工、缺陷和评审负担。
- CMS 生成结果默认进入草稿或建议状态，不允许静默发布。
- 保留模型、提示版本、输入范围和人工接受记录。
- 为外部模型不可用准备降级路径，并设置调用预算。
AI 可以降低表达和实现的门槛，也可能把成本从作者转移给评审者。成熟的治理方式不是简单地允许或禁止，而是让责任归属、质量证据和内容审批都保持清晰。