1094 lines
15 KiB
Plaintext
1094 lines
15 KiB
Plaintext
2026年讯和技术大赛 · 参赛者手
|
||
册
|
||
|
||
AI驱动 · 范式革新
|
||
|
||
AI推进部 · 2026年6月
|
||
|
||
目录
|
||
|
||
1. 赛事概述
|
||
|
||
2. 双赛道详解
|
||
|
||
3. 日程与里程碑
|
||
|
||
4. 开发范式与AI日志
|
||
|
||
5. AI工具与开发环境
|
||
|
||
6. 成果物清单
|
||
|
||
7. 评审标准（暂定）
|
||
|
||
8. 设备与信息安全
|
||
|
||
1. 赛事概述
|
||
|
||
方针与目标
|
||
|
||
维度
|
||
|
||
内容
|
||
|
||
整体目标
|
||
|
||
让开发团队掌握Agent开发能力和AI工具使用，培养具备
|
||
|
||
创新思维的实战型人才
|
||
|
||
赛事口号 「AI驱动·范式革新」 —— 推动公司研发能力的范式跃迁
|
||
|
||
对公司的
|
||
|
||
价值
|
||
|
||
技术能力提升 · 产品活用 · 人才发掘 · 技术沉淀
|
||
|
||
五大赛事特色
|
||
|
||
|
||
|
||
|
||
|
||
|
||
# 特色
|
||
|
||
说明
|
||
|
||
1 全程AI驱动
|
||
|
||
从需求澄清到设计、开发、测试，全程必须利用AI
|
||
|
||
完成
|
||
|
||
2
|
||
|
||
3
|
||
|
||
4
|
||
|
||
5
|
||
|
||
聚焦AI实战
|
||
|
||
让AI真正解决业务问题，交付可运行、可演示的完
|
||
|
||
应用
|
||
|
||
整作品
|
||
|
||
强调开发范
|
||
|
||
追求可传播、可复用的标准化开发范式，让AI从工
|
||
|
||
式应用
|
||
|
||
具升级为思维伙伴
|
||
|
||
强调作品落
|
||
|
||
拒绝PPT大赛，成果物强制包含源码、演示视频、
|
||
|
||
地
|
||
|
||
实验报告
|
||
|
||
评审融入AI
|
||
|
||
元素
|
||
|
||
用AI辅助评审，提升效率与客观性
|
||
|
||
双赛道概览
|
||
|
||
赛道一：Agent开发实战赛
|
||
|
||
深度探索，原型孵化
|
||
|
||
设计Agent架构 + 实现自主智能
|
||
|
||
6个月（6月-11月）
|
||
|
||
赛道二：IDE+开
|
||
|
||
发范式创新赛
|
||
|
||
稳健实践，工具
|
||
|
||
落地
|
||
|
||
设计开发工作流
|
||
|
||
+ 实现IDE插件/
|
||
|
||
工具
|
||
|
||
3个月（7月-9
|
||
|
||
月）
|
||
|
||
每队人数不限，鼓励跨部门组合；各部门至
|
||
|
||
少组织一支队伍；各本部内均须有参赛队伍
|
||
|
||
同左
|
||
|
||
项
|
||
|
||
目
|
||
|
||
定
|
||
|
||
位
|
||
|
||
核
|
||
|
||
心
|
||
|
||
任
|
||
|
||
务
|
||
|
||
周
|
||
|
||
期
|
||
|
||
组
|
||
|
||
队
|
||
|
||
要
|
||
|
||
求
|
||
|
||
2. 双赛道详解
|
||
|
||
|
||
|
||
赛道一：Agent开发实战赛
|
||
|
||
核心要求：Agent是成果物的核心，必须能自主完成"感知→规划→行动"业
|
||
务闭环。
|
||
|
||
期望形态：Agent + 必要交互界面 + 数据存储 + 工具调用
|
||
|
||
不需要 Agent生成完整系统
|
||
|
||
不建议 只做纯对话Agent
|
||
|
||
前后端支撑是完成选题的自然需求，也是验证Agent业务可行性的载体
|
||
|
||
选题范围：各团队自选业务场景，聚焦Agent能解决的实际问题。
|
||
|
||
赛道二：IDE+开发范式创新赛
|
||
|
||
核心要求：设计并实现一个IDE插件或命令行工具，将AI驱动的开发范式落
|
||
|
||
地为可用的工程工具。
|
||
|
||
期望形态：IDE插件 + 开发范式设计 + 效率提升数据
|
||
|
||
不需要 生成论文或研究报告
|
||
|
||
不建议 使用Agent框架
|
||
|
||
核心是实际能用的工程作品
|
||
|
||
选题范围：各团队自选开发痛点，聚焦提升开发效率的自动化工具。
|
||
|
||
3. 日程与里程碑
|
||
|
||
赛道一：Agent开发实战赛（6个月）
|
||
|
||
|
||
|
||
|
||
|
||
阶段
|
||
|
||
时间
|
||
|
||
里程碑
|
||
|
||
交付物
|
||
|
||
赛事启
|
||
|
||
动
|
||
|
||
6月
|
||
|
||
—
|
||
|
||
本手册
|
||
|
||
组队·选
|
||
|
||
6月-7
|
||
|
||
题
|
||
|
||
原型设
|
||
|
||
计
|
||
|
||
月
|
||
|
||
7月
|
||
|
||
选题确定
|
||
|
||
项目说明（初版）
|
||
|
||
设计文档完
|
||
|
||
成
|
||
|
||
设计文档（含范式图、架构图）
|
||
|
||
产品开
|
||
|
||
7月-9
|
||
|
||
中期作品展
|
||
|
||
可运行原型 + AI使用日志（持续
|
||
|
||
发
|
||
|
||
月
|
||
|
||
示
|
||
|
||
更新）
|
||
|
||
最终冲
|
||
|
||
刺
|
||
|
||
现场评
|
||
|
||
审
|
||
|
||
10月
|
||
|
||
功能冻结
|
||
|
||
全部成果物
|
||
|
||
11月
|
||
|
||
最终展示
|
||
|
||
+答辩
|
||
|
||
演示视频 + 最终成果物
|
||
|
||
赛道二：IDE+开发范式创新赛（3个月）
|
||
|
||
阶段
|
||
|
||
时间
|
||
|
||
里程碑
|
||
|
||
赛事启动
|
||
|
||
7月
|
||
|
||
—
|
||
|
||
交付物
|
||
|
||
本手册
|
||
|
||
组队·选题 7月
|
||
|
||
选题确定
|
||
|
||
项目说明（初版）
|
||
|
||
开发实践
|
||
|
||
7月-8月 中期报告
|
||
|
||
设计文档 + 可运行原型
|
||
|
||
最终冲刺
|
||
|
||
现场评审
|
||
|
||
9月
|
||
|
||
9月
|
||
|
||
功能冻结
|
||
|
||
全部成果物
|
||
|
||
最终展示+答辩
|
||
|
||
演示视频 + 最终成果物
|
||
|
||
4. 开发范式与AI日志
|
||
|
||
大赛有两个核心要求：开发范式和全程AI驱动。
|
||
|
||
开发范式——团队使用AI进行开发的方法论和工作流程（如：需求分析
|
||
→AI生成方案→人工审核→AI编码→测试验证→反馈迭代）。范式图必须
|
||
提交，它是评审的核心依据。
|
||
|
||
|
||
|
||
全程AI驱动——所有代码必须由AI生成而非手写，需要可验证机制。
|
||
|
||
因此需要AI使用日志，同时服务于两个目的：
|
||
|
||
1. 范式验证：日志中的"范式步骤"列对应范式图中的每一步，评委对照二
|
||
|
||
者验证范式是否真实执行。
|
||
|
||
2. 代码溯源：日志中的"涉及文件"列记录AI修改了哪些代码文件，评委抽
|
||
|
||
检文件回查日志，确认代码由AI生成、防止手写。
|
||
|
||
AI使用日志取得方法
|
||
|
||
将以下规则写入项目的指令文件（各工具对应的文件名参考下表），AI即
|
||
|
||
会在每次创建或修改代码文件后自动追加一条记录到项目根目录的
|
||
|
||
_AI_USAGE_LOG.md 。
|
||
|
||
工具
|
||
|
||
指令文件位置
|
||
|
||
OpenCode
|
||
|
||
opencode.md 或 AGENTS.md
|
||
|
||
Claude Code
|
||
|
||
CLAUDE.md 或 .claude/CLAUDE.md
|
||
|
||
Trae（字节跳动）
|
||
|
||
Cursor
|
||
|
||
.trae/rules/*.md （建议写入
|
||
|
||
alwaysApply: true 的规则文件）
|
||
|
||
.cursor/rules/*.mdc （建议写入
|
||
|
||
alwaysApply: true 的规则文件）
|
||
|
||
GitHub Copilot
|
||
|
||
.github/copilot-instructions.md
|
||
|
||
Windsurf（Codeium） .windsurfrules
|
||
|
||
|
||
工具
|
||
|
||
指令文件位置
|
||
|
||
Gemini CLI（Google） GEMINI.md
|
||
|
||
Lingma（阿里通义灵
|
||
|
||
码）
|
||
|
||
.lingma/rules/*.md
|
||
|
||
CodeBuddy（腾讯）
|
||
|
||
.codebuddy/rules/*.md
|
||
|
||
Roo Code
|
||
|
||
.roo/rules/*.md
|
||
|
||
Kiro
|
||
|
||
.kiro/steering/*.md
|
||
|
||
参考方法：在使用的指令文件中追加以下内容：
|
||
|
||
## 日志规则（自动执行）
|
||
|
||
每次创建或修改代码文件后，在项目根目录的 `_AI_USAGE_LOG.md` 中追
|
||
加一条记录，必须包含以下字段：日期时间、范式步骤、修改摘要、涉及文件、
|
||
|
||
使用模型
|
||
|
||
说明：
|
||
|
||
AI自动填充"日期时间""修改摘要""涉及文件"和"使用模型"，若AI无法获
|
||
|
||
取当前使用模型，可以手动加上。
|
||
|
||
"范式步骤"列先写"待补充"，开发结束后由团队对照范式图替换成对应
|
||
的步骤名称即可（如"需求分析→AI生成方案"）。
|
||
评委验证时：选中源码文件 → 选手在日志中找到对应记录 → 说明当时
|
||
的Prompt。
|
||
|
||
编程语言限制
|
||
|
||
编程语言和框架不限，任何能实现选题的技术栈均可。推荐的AI工具
|
||
|
||
（OpenCode等）也支持多种语言。
|
||
|
||
5. AI工具与开发环境
|
||
|
||
费用与网络
|
||
|
||
组委会不提供API Token，推荐使用完全免费的方案：
|
||
|
||
|
||
|
||
|
||
★ 推荐：OpenCode + DeepSeek/Qwen（完全免费开源，国内可直接
|
||
|
||
使用）
|
||
|
||
☆ 备选：Trae（免费，字节出品，国内友好）
|
||
|
||
也可使用付费模型，费用自理。
|
||
|
||
工具对比一览
|
||
|
||
费用
|
||
|
||
网络
|
||
|
||
推荐度
|
||
|
||
类型
|
||
|
||
编程
|
||
|
||
完全免费
|
||
|
||
需要API
|
||
|
||
Agent（CLI）
|
||
|
||
开源
|
||
|
||
访问
|
||
|
||
工具
|
||
|
||
OpenCode
|
||
|
||
Trae
|
||
|
||
Claude
|
||
|
||
Code
|
||
|
||
Cursor
|
||
|
||
IDE（VSCode
|
||
|
||
核心）
|
||
|
||
编程
|
||
|
||
免费
|
||
|
||
需付费订
|
||
|
||
Agent（CLI）
|
||
|
||
阅
|
||
|
||
IDE（VSCode
|
||
|
||
核心）
|
||
|
||
免费版
|
||
|
||
+付费
|
||
|
||
★★★★★
|
||
|
||
★★★★☆
|
||
|
||
国内直
|
||
|
||
连
|
||
|
||
需翻墙
|
||
|
||
★★★☆☆
|
||
|
||
需翻墙
|
||
|
||
★★★☆☆
|
||
|
||
国内直
|
||
|
||
连
|
||
|
||
★★★☆☆
|
||
|
||
DeepSeek
|
||
|
||
Chat
|
||
|
||
网页对话
|
||
|
||
免费
|
||
|
||
ChatGPT
|
||
|
||
网页对话
|
||
|
||
免费版有
|
||
|
||
限额
|
||
|
||
需翻墙
|
||
|
||
★★☆☆☆
|
||
|
||
推荐组合
|
||
|
||
推
|
||
|
||
荐
|
||
|
||
★
|
||
|
||
首
|
||
|
||
选
|
||
|
||
☆
|
||
|
||
备
|
||
|
||
选
|
||
|
||
组合
|
||
|
||
理由
|
||
|
||
OpenCode
|
||
|
||
完全免费、国内可用、CLI 轻量、日志自动生成。
|
||
|
||
+
|
||
|
||
项目根目录创建 AGENTS.md 写入项目说明和日志
|
||
|
||
DeepSeek
|
||
|
||
规则，终端输入 opencode 即可开始
|
||
|
||
Trae +
|
||
|
||
DeepSeek
|
||
|
||
免费、国内直连、图形化 IDE、也支持
|
||
|
||
.trae/rules 自动生成日志，适合偏好图形界面
|
||
|
||
的团队
|
||
|
||
|
||
|
||
6. 成果物清单
|
||
|
||
两赛道共用同一套成果物体系，每赛道6项成果物，按以下顺序提交：
|
||
|
||
项目说明 → 设计文档 → 源码 → 实验报告 → AI使用日志 → 演示视频
|
||
|
||
〔成果物01〕 项目说明
|
||
|
||
提 交 物：项目概要
|
||
|
||
包含内容：
|
||
|
||
项目性质声明（新规/升级）
|
||
|
||
项目概述（选题背景、要解决什么问题）
|
||
|
||
整体功能说明（核心能力与使用方式）
|
||
|
||
效果总结（达到了什么效果，核心指标摘要）
|
||
|
||
团队分工（各成员的角色和职责）
|
||
|
||
〔成果物02〕 设计文档
|
||
|
||
提 交 物：完整的设计方案
|
||
|
||
包含内容：
|
||
|
||
场景描述与业务价值说明
|
||
|
||
开发范式流程图——团队自己的AI开发步骤（如"需求分析→AI生成
|
||
方案→人工审核→AI编码→测试验证→反馈迭代"），含闭环反馈
|
||
|
||
架构图（赛道一：感知-规划-行动-记忆；赛道二：插件/工具整体架
|
||
|
||
构）
|
||
|
||
架构说明（组件划分、数据流、关键设计决策）
|
||
|
||
使用的工具/API清单及调用方式
|
||
|
||
范式图说明：范式图不是产品架构图，而是团队开发过程的工作流设
|
||
|
||
计。图中每个步骤的名称将在AI使用日志的"范式步骤"列中对应出现，
|
||
|
||
供评委对照验证。
|
||
|
||
〔成果物03〕 源码（含README）
|
||
|
||
|
||
|
||
|
||
|
||
提 交 物：完整的项目源码
|
||
|
||
包含内容：
|
||
|
||
源码完整，能正常安装和运行
|
||
|
||
README包含：安装步骤、运行方法、运行环境要求、API密钥配
|
||
|
||
置说明、依赖清单
|
||
|
||
如含前端界面，说明启动方式
|
||
|
||
⚠ 基础前提项：评审现场无法按README启动运行的，后续所有评分
|
||
项扣分。
|
||
|
||
〔成果物04〕 实验报告
|
||
|
||
提 交 物：完整的测试用例执行结果和日志
|
||
|
||
包含内容：
|
||
|
||
完整的测试用例清单及执行结果
|
||
|
||
评估数据（成功率、耗时、修正次数）
|
||
|
||
附测试执行日志文件（每用例至少1条关键输出）
|
||
|
||
〔成果物05〕 AI使用日志
|
||
|
||
提 交 物：AI在开发全过程中的使用记录
|
||
|
||
包含内容：
|
||
|
||
按本文档规定的格式填写（见「AI使用日志取得方法」）
|
||
|
||
每条记录标注范式步骤（与设计文档范式图中的步骤名称一致）
|
||
|
||
每条记录标注涉及文件（被AI创建或修改的代码文件路径）
|
||
|
||
覆盖每个环节（需求澄清、设计、编码、测试）
|
||
|
||
每环节标注使用的AI模型
|
||
|
||
含AI生成的中间产物
|
||
|
||
代码溯源说明：AI日志的"涉及文件"列是防止手写代码的关键机制。评
|
||
|
||
委通过抽检源码文件路径回查日志，确认代码确实是AI生成的。
|
||
|
||
〔成果物06〕 演示视频
|
||
|
||
|
||
|
||
|
||
项
|
||
|
||
目
|
||
|
||
时
|
||
|
||
长
|
||
|
||
要
|
||
|
||
求
|
||
|
||
赛道一
|
||
|
||
≤15分钟
|
||
|
||
赛道二
|
||
|
||
≤5分钟
|
||
|
||
完整成功流程 + Agent闭环 + 工具
|
||
|
||
完整工作流 + IDE集成效果
|
||
|
||
调用 + 异常恢复
|
||
|
||
+ 异常处理
|
||
|
||
7. 评审标准（暂定）
|
||
|
||
7.1 项目性质说明
|
||
|
||
为确保评审公平性，评审体现项目类型差异。评分表各维度已区分新规项
|
||
|
||
目和升级项目的考核要点，评委据此独立评审。
|
||
|
||
团队在提交「项目说明」时须明确项目性质（新规/升级），一经确认不可
|
||
|
||
变更。
|
||
|
||
7.2 赛道一：Agent开发实战赛
|
||
|
||
评分表（总分100分）
|
||
|
||
|
||
|
||
|
||
|
||
维度
|
||
|
||
权重 考核方式
|
||
|
||
场景价值
|
||
|
||
与合理性
|
||
|
||
15%
|
||
|
||
新规项目：评估选题是否真实业务痛点，Agent
|
||
|
||
是否不可或缺，价值是否可量化
|
||
|
||
升级项目：评估改造需求是否明确，改造效果是
|
||
|
||
否有定量数据佐证
|
||
|
||
范式图↔AI日志对照 + 架构图审查：评估范式是
|
||
否完整可复制，日志是否覆盖各步骤，架构设计
|
||
|
||
是否合理
|
||
|
||
升级项目另需：存量系统分析，评估改造策略是
|
||
|
||
否合理，迁移风险是否可控，有无改造前后架构
|
||
|
||
对比
|
||
|
||
视频（工具调用）+ 实验报告：评估是否调用外
|
||
|
||
部工具/API，有无降级和重试机制
|
||
|
||
现场运行+实验报告：评估核心路径是否完整跑
|
||
|
||
通，运行是否稳定，有无崩溃和超时处理
|
||
|
||
升级项目另需：评估与原系统兼容性，有无回
|
||
|
||
滚/灰度策略，迁移验证是否通过
|
||
|
||
25%
|
||
|
||
10%
|
||
|
||
15%
|
||
|
||
新规项目：评估关联系统数量、技术栈复杂度、
|
||
|
||
业务覆盖面
|
||
|
||
10%
|
||
|
||
升级项目：评估新增项目的规模、涉及的功能点
|
||
|
||
数量、技术实现难度
|
||
|
||
项目说明中均须包含规模与技术难度的自我评估
|
||
|
||
5%
|
||
|
||
10%
|
||
|
||
视频+文档审查：评估视频是否清晰完整，是否
|
||
|
||
演示了异常场景，自评是否准确
|
||
|
||
逐条审查+文件抽检：评估日志是否覆盖需求/设
|
||
|
||
计/编码/测试各环节，文件路径是否可回查
|
||
|
||
实验报告审查：评估是否有完整的成功率/耗时
|
||
|
||
数据，有无改进建议，数据是否真实
|
||
|
||
10%
|
||
|
||
升级项目另需：改造前后定量对比数据，投入产
|
||
|
||
出比(ROI)和实际运行数据，改进建议是否经验证
|
||
|
||
有效
|
||
|
||
开发范式
|
||
|
||
与架构设
|
||
|
||
计
|
||
|
||
工具使用
|
||
|
||
与集成深
|
||
|
||
度
|
||
|
||
实现完整
|
||
|
||
度与稳定
|
||
|
||
性
|
||
|
||
规模、功
|
||
|
||
能点、技
|
||
|
||
术难度
|
||
|
||
演示与文
|
||
|
||
档
|
||
|
||
AI使用日
|
||
|
||
志
|
||
|
||
效果评估
|
||
|
||
与数据
|
||
|
||
7.3 赛道二：IDE+开发范式创新赛
|
||
|
||
评分表（总分100分）
|
||
|
||
维度
|
||
|
||
权重 考核方式
|
||
|
||
开发范式
|
||
|
||
设计清晰
|
||
|
||
度
|
||
|
||
范式图↔AI日志对照：评估范式是否完整可复
|
||
制，日志是否覆盖各步骤
|
||
|
||
20%
|
||
|
||
升级项目另需：存量流程分析，评估范式是否分
|
||
|
||
析了现有流程痛点，是否为合理改进，有无改造
|
||
|
||
前后范式对比
|
||
|
||
IDE集成深
|
||
|
||
度
|
||
|
||
20%
|
||
|
||
现场演示：评估是否在IDE内集成，能否自动获
|
||
|
||
取上下文，是否一键触发
|
||
|
||
人工审核：评估是否有对比数据，原始数据是否
|
||
|
||
完整
|
||
|
||
提效幅度
|
||
|
||
20%
|
||
|
||
新规项目：提供对比数据证明提效
|
||
|
||
升级项目：提供对比数据证明提效，另需投入产
|
||
|
||
出比(投入人天/产出效果)和效果可验证数据
|
||
|
||
现场运行+实验报告：评估是否可一键安装，运
|
||
|
||
行是否稳定，有无重试/降级机制
|
||
|
||
升级项目另需：评估与原环境兼容性，错误处理
|
||
|
||
和恢复机制是否完善，异常场景是否全覆盖
|
||
|
||
新规项目：评估范式复杂度、技术栈广度、业务
|
||
|
||
场景覆盖面
|
||
|
||
10%
|
||
|
||
升级项目：评估新增项目的规模、功能点数量、
|
||
|
||
技术实现难度
|
||
|
||
项目说明中均须包含规模与技术难度的自我评估
|
||
|
||
5%
|
||
|
||
10%
|
||
|
||
视频+文档审查：评估视频是否清晰完整，是否
|
||
|
||
含异常演示，自评是否准确
|
||
|
||
逐条审查+文件抽检：评估日志是否覆盖各环
|
||
|
||
节，文件路径是否可回查
|
||
|
||
稳定性与
|
||
|
||
易用性
|
||
|
||
15%
|
||
|
||
规模、功
|
||
|
||
能点、技
|
||
|
||
术难度
|
||
|
||
演示与文
|
||
|
||
档
|
||
|
||
AI使用日
|
||
|
||
志
|
||
|
||
7.4 共通规则
|
||
|
||
|
||
|
||
|
||
源码可运行：无法启动运行的，所有评分项扣分
|
||
|
||
升级项目强制要求：成果物中须包含「存量系统分析」文档和「改造前
|
||
|
||
后对比」数据，缺失则对应维度扣分
|
||
|
||
AI日志不可缺失：未提交或空白，扣分
|
||
|
||
8. 设备与信息安全
|
||
|
||
8.1 笔记本借用规则
|
||
|
||
业务管理部为没有开发用笔记本的参赛团队提供借用服务。
|
||
|
||
项目
|
||
|
||
说明
|
||
|
||
借用对象
|
||
|
||
参赛团队中缺少开发用笔记本的成员
|
||
|
||
网络限制
|
||
|
||
借出笔记本无法连接公司WiFi，需使用个人热点
|
||
|
||
软件安装
|
||
|
||
须确认版本版权，避免侵权
|
||
|
||
使用范围
|
||
|
||
可在公司内使用，也可携带外出使用
|
||
|
||
咨询窗口
|
||
|
||
业务管理部
|
||
|
||
8.2 信息安全注意事项
|
||
|
||
参赛过程中请遵守公司信息安全规定：
|
||
|
||
|
||
|
||
|
||
项目
|
||
|
||
要求
|
||
|
||
顾客数据、公司信息等不得
|
||
|
||
上传至外部公开仓库
|
||
|
||
说明
|
||
|
||
—
|
||
|
||
代码
|
||
|
||
安全
|
||
|
||
数据
|
||
|
||
安全
|
||
|
||
API
|
||
|
||
Key管
|
||
|
||
理
|
||
|
||
AI工
|
||
|
||
具选
|
||
|
||
择
|
||
|
||
软件
|
||
|
||
版权
|
||
|
||
不得将公司内部数据用于AI
|
||
|
||
客户信息、业务数据等严禁
|
||
|
||
训练或上传
|
||
|
||
外传
|
||
|
||
配置在环境变量或配置文件
|
||
|
||
不得硬编码在源码中，提交
|
||
|
||
中
|
||
|
||
前清理
|
||
|
||
优先使用国内AI服务
|
||
|
||
DeepSeek、Qwen等，海外
|
||
|
||
服务避免传敏感信息
|
||
|
||
确认许可证类型
|
||
|
||
禁止使用盗版软件
|
||
|
||
|
||
|