过去，判断一个项目是否开源，最直观的标准是能否看到、修改和分发源代码。进入 AIGC 开发阶段后，真正决定产出质量的往往不只有代码，还包括提示词、上下文组织、模型参数、工具调用、评测数据和迭代记录。
2026 北京开源创新赛设置 AIGC 赛道并强调全民参与，反映出一个值得开发者关注的变化：开源对象正在从“程序成品”扩展到“人与 AI 如何共同完成创造”。代码依然重要，但一套可解释、可复现、可继续改进的协作方法，同样可以成为有价值的开源成果。
AI 项目中，真正需要公开的是什么
一个 AIGC 项目可能只有几十行调用模型的代码，但其效果依赖大量没有写进程序的隐性知识。例如：
- 系统提示词如何限定角色、目标和输出格式；
- 长文档如何切分，哪些内容会放入上下文；
- 模型生成失败后，工作流如何重试或降级；
- 什么样的测试样本被视为“足够好”；
- 人工在哪些节点审核，哪些任务允许自动执行；
- 不同模型、温度和提示词版本之间有什么差异。
如果仓库只放一个 API 调用脚本，其他人虽然能运行，却很难重现作者的结果。更完整的开放方式，是把项目整理成一份可执行的实验记录：输入是什么、提示词是什么、运行条件是什么、输出如何评价，以及失败案例如何处理。
这并不是降低代码的重要性，而是承认 AIGC 系统的行为由多种资产共同决定。提示词相当于可迭代的接口说明，评测集相当于回归测试，工作流则把模型、工具和人工审核连接起来。
把提示词当作需要版本管理的工程资产
提示词最容易陷入“复制一段文字就算开源”的误区。一段孤立提示词缺少输入约束、预期输出和测试样本，换一个模型或业务场景后可能立即失效。
更实用的仓库可以采用下面的结构：
open-aigc-workflow/
├── README.md
├── prompts/
│ └── system.txt
├── cases.jsonl
├── run_eval.py
├── results/
└── LICENSE
其中，README.md 应说明适用场景和运行步骤；prompts/ 保存可追踪版本的提示词；cases.jsonl 提供不包含敏感数据的测试样本；results/ 可以保留代表性结果和失败分析。若项目允许他人修改、发布或商用，还应明确许可证及第三方模型的使用边界。
提交记录也应描述行为变化，而不只是写“更新 prompt”。例如：
fix(prompt): 要求回答引用输入中的事实，减少无依据补充
feat(eval): 增加空输入和冲突需求测试样本
这样的历史记录能帮助后来者理解为什么修改，而不只是看到修改了什么。
一个可以直接改造的最小评测项目
下面是一种可以这样实践的通用方案，并不代表赛事指定接口或提交格式。示例调用兼容 OpenAI 风格的 Chat Completions 服务，用测试用例检查回答是否覆盖预期关键词。正式项目应换成更可靠的人工评审、规则评测或模型评测。
先创建文件：
mkdir -p open-aigc-workflow/prompts open-aigc-workflow/results
cd open-aigc-workflow
cat > prompts/system.txt <<'EOF'
你是一名技术文档助手。
只根据用户提供的信息回答；信息不足时明确指出缺失内容。
输出应简洁、可执行，并优先使用列表。
EOF
cat > cases.jsonl <<'EOF'
{"id":"case-001","input":"请说明开源一个提示词工作流至少要提供什么。","expected_keywords":["提示词","测试","运行"]}
{"id":"case-002","input":"测试数据包含用户手机号，能直接提交到公开仓库吗？","expected_keywords":["脱敏","隐私"]}
EOF
然后保存以下 run_eval.py：
import json
import os
import pathlib
import urllib.request
BASE_URL = os.environ.get("AIGC_BASE_URL", "https://api.example.com/v1").rstrip("/")
API_KEY = os.environ["AIGC_API_KEY"]
MODEL = os.environ.get("AIGC_MODEL", "your-model-name")
system_prompt = pathlib.Path("prompts/system.txt").read_text(encoding="utf-8")
cases = [
json.loads(line)
for line in pathlib.Path("cases.jsonl").read_text(encoding="utf-8").splitlines()
if line.strip()
]
def chat(user_input):
payload = json.dumps({
"model": MODEL,
"temperature": 0,
"messages": [
{"role": "system", "content": system_prompt},
{"role": "user", "content": user_input}
]
}).encode("utf-8")
request = urllib.request.Request(
f"{BASE_URL}/chat/completions",
data=payload,
headers={
"Authorization": f"Bearer {API_KEY}",
"Content-Type": "application/json"
},
method="POST"
)
with urllib.request.urlopen(request, timeout=60) as response:
data = json.load(response)
return data["choices"][0]["message"]["content"]
pathlib.Path("results").mkdir(exist_ok=True)
passed = 0
with pathlib.Path("results/latest.jsonl").open("w", encoding="utf-8") as output:
for case in cases:
answer = chat(case["input"])
missing = [word for word in case["expected_keywords"] if word not in answer]
result = {
"id": case["id"],
"answer": answer,
"passed": not missing,
"missing_keywords": missing
}
passed += int(result["passed"])
output.write(json.dumps(result, ensure_ascii=False) + "\n")
print(f'{case["id"]}: {"PASS" if result["passed"] else "FAIL"}')
print(f"score: {passed}/{len(cases)}")
运行前，把地址、密钥和模型名替换为自己使用的服务配置：
export AIGC_BASE_URL="https://your-provider.example/v1"
export AIGC_API_KEY="replace-with-your-key"
export AIGC_MODEL="replace-with-your-model"
python run_eval.py
这套示例的价值不在关键词评分本身，而在于它把提示词、样本、配置和结果拆成了可审查的文件。其他开发者可以只修改 system.txt，再次运行同一批用例，观察行为是否改善。密钥不得写入仓库，真实用户数据也应先获得授权并完成脱敏。
参赛或发布前，检查成果能否被复现
面向 AIGC 赛道准备作品时，与其只展示一次效果理想的演示，不如让评审者和社区成员看到完整路径。由于具体参赛资格、作品格式和许可要求应以赛事正式规则为准，项目层面可以先完成以下检查：
- 新用户是否能根据 README 在合理时间内运行项目；
- 提示词、模型名称、关键参数和依赖版本是否明确；
- 是否提供正常、边界和失败测试用例；
- 示例数据是否获得授权，并移除了个人信息和商业秘密；
- 是否说明外部模型、数据集和工具的许可证或服务限制；
- 是否记录已知缺陷、幻觉风险、成本和人工审核节点；
- 是否允许贡献者比较修改前后的结果。
AIGC 让更多不会编写大型系统的人也能参与数字创造，但“全民可参与”不等于只提交一条偶然有效的提示词。真正有生命力的开放成果，应让别人看懂方法、复现实验、指出问题，并在已有基础上继续迭代。开源的载体正在变化，而它最核心的承诺仍然没有变：把创造过程公开，让后来者不必从头踩一遍相同的坑。