主题: 附录 B. 与 Qwen Code 的兼容性
难度等级: 中级 (中等)
预计学习时间: 2-3 小时
前置要求: 对 CLI（命令行界面）使用的基本理解
使用版本控制系统（Git）的经验
对 LLM 和 AI 助手在开发中工作原理的一般理解
熟悉 CI/CD 概念和脚本编写（Bash/Python）
学习目标: 区分 Qwen Code 的内置功能与需要用户自行实现的过程。
正确应用"标准量表"（标准、推荐、前沿）对工作流程进行分类。
在 .qwen/commands/ 目录结构中创建和集成自定义命令。
使用 MCP 服务器和允许列表（allowlists）设计安全的外部 API 集成。
理解角色（验证者、实施者、安全、协调者）以及它们如何在模型、脚本和人之间分配。
概述: 本指南专注于使用 Qwen Code 的生产流程架构和兼容性。材料帮助开发人员在平台标准功能和用户扩展之间划清界限。您将了解如何将流程从基本的 CLI 使用扩展到与外部 API 的复杂编排，同时不损害系统的安全性和可预测性。指南基于三层成熟度（标准量表）概念，并提供有关实施钩子、脚本和命令的实用建议。
关键概念: 标准量表：流程分类的三级模型：标准（Qwen Code 的内置功能）、推荐（存储在仓库中的自定义命令、脚本和技能）以及前沿（与 Kubernetes 或 Grafana 等外部服务的复杂生产编排）。
qwen code 内置层：开箱即用的基本功能：/plan（规划）、/review（代码审查）、/skills（技能）、内存管理（/memory）、shell 命令调用（!command）以及用于 CI 的无头模式（qwen -p）。
自定义命令：以 Markdown 文件形式呈现的特定于项目的指令（例如 .qwen/commands/sdd/specify.md）。允许标准化步骤，例如通过 /sdd:clarify 调用的需求澄清（/clarify）或任务生成。
项目脚本：用 Python 或 Bash 编写的确定性检查（例如 validate_schema.py 或 check_invariants.py）。与 LLM 不同，它们提供明确的"绿色"或"红色"状态，没有模型幻觉的风险。
钩子（hooks）和护栏（guardrails）：Qwen Code 的保护和触发器系统，使用官方事件（PreToolUse、PostToolUse、UserPromptSubmit 等）实时控制模型操作。
MCP（模型上下文协议）：用于安全连接外部 API（Jira、Grafana 等）的规范。需要创建允许列表（允许操作的列表）、读/写权限分离以及严格的密钥策略。
练习题: 名称: 创建自定义命令 /sdd:clarify
问题: 您需要在团队中标准化需求澄清流程。/clarify 命令不是 Qwen Code 的内置命令。为此命令创建文件结构和基本提示模板。
解决方案: 1. 在项目根目录创建目录：.qwen/commands/sdd/。2. 在其中创建 clarify.md 文件。3. 在文件中添加文本："你是一名业务分析师。分析来自 {{args}} 和 @specs/ 的上下文。在规划之前提出澄清问题以消除歧义。停止条件：最多提出 5 个问题并等待用户回答。" 4. 在 CLI 中调用命令：/sdd:clarify 支付网关集成。
难度: intermediate
名称: 为监控设置安全的 MCP 服务器
问题: 团队希望 Qwen Code 能够检查 Grafana 中的警报。描述 MCP 服务器的允许列表（allowlist）架构，以防止模型修改仪表板或执行恶意命令。
解决方案: 1. 创建一个作为 Grafana API 代理的 MCP 服务器。2. 在允许列表中仅添加具有"只读"访问权限的工具（例如 get_alerts、query_metrics）。3. 禁止任何写入工具（create_dashboard、delete_panel）。4. 确保 Grafana 的 API 令牌存储在编排器的环境变量中，而不是传递给 QWEN.md。
难度: advanced
名称: 按标准量表对流程进行分类
问题: 将以下三个任务按标准量表的级别进行分类：A) 使用 Qwen 自动修复代码中的拼写错误。B) 用于检查规范覆盖率的 Python 脚本。C) 与 PagerDuty 集成以自动创建事件。
解决方案: A) 标准（Qwen Code 的基本自动编辑功能）。B) 推荐（位于 scripts/spec_ci/ 目录中的项目脚本，作为确定性检查运行）。C) 前沿（需要外部编排器和 MCP 服务器来与 PagerDuty API 集成）。
难度: beginner
案例研究: 名称: 在企业项目中实施 Spec CI（规范网关）
场景: 一个大型开发团队采用这种方法：先在规范中描述需求，然后编写代码。Qwen Code 用于协助编写规范。
挑战: 有时 Qwen Code 生成的规范不符合公司内部的 JSON 格式或包含逻辑矛盾。手动检查这一点花费了太多时间。
解决方案: 团队应用了"推荐"级别。他们编写了在 GitHub Actions 中运行的项目脚本（validate_schema.py 和 check_coverage.py）。Qwen Code 通过标志 qwen -p 用于生成草稿，但规范的最终接受完全依赖于确定性脚本，而不是 LLM 响应的说服力。
结果: 规范的可靠性提高到 100%。开发人员在解析时不再遇到意外错误，验证过程变得完全自动化。
经验教训: 在生产中，验证依赖于模型（LLM）响应的说服力是不可接受的。
检查的绿色状态应取决于验证代码，而不是生成中没有错误。
相关概念: 规范网关（Spec CI）
标准量表（推荐）
项目脚本
名称: 与云基础设施的安全集成
场景: 开发人员希望使用 Qwen Code 对 Kubernetes 集群中的问题进行分类并更新 Jira 中的工单。
挑战: 通过 shell 命令（!command）传递直接访问权限可能导致 Kubernetes 中资源的意外删除或令牌在聊天历史记录中的泄露。
解决方案: 使用"前沿"级别。部署了具有严格允许列表的 MCP 服务器以代替直接访问：Kubernetes 工具仅限于读取（get_pods、describe_logs），而为 Jira 设置了明确的确认条件。访问令牌被隐藏在环境变量中，从未进入 QWEN.md。
结果: Qwen Code 成功帮助诊断故障和更新工单。借助护栏和 MCP 架构，意外执行破坏性命令（例如删除 pod）的风险已降至零。
经验教训: 生产 API 不应成为不受限制的 shell 命令。
禁止在提示中传递密钥对项目安全至关重要。
相关概念: MCP（模型上下文协议）
LLM 安全性
护栏（Guardrails）
学习建议: 记住检查的主要规则：如果结果取决于模型的判断或响应，则这还不是生产流程。真正的验证必须委托给项目脚本。
始终从"标准"开始。如果您对 Qwen Code 的基本内置命令满意，请勿尝试立即实施"前沿"（Kubernetes、编排器）。
研究 .qwen/commands/ 文件夹的结构。创建带有停止规则的自定义 .md 文件是将 Qwen Code 适应您流程的最快方法。
使用外部服务时，请在脑海中设计 MCP 服务器：确定哪些操作属于"只读"，哪些需要"回滚"。
附加资源: qwen code 官方文档（命令）：https://qwenlm.github.io/qwen-code-docs/en/users/features/commands/
Qwen code 无头模式：https://qwenlm.github.io/qwen-code-docs/en/users/features/headless/
MCP（模型上下文协议）文档：https://qwenlm.github.io/qwen-code-docs/en/users/features/mcp/
qwen code 官方文档（钩子）：https://qwenlm.github.io/qwen-code-docs/en/users/features/hooks/
LLM 应用程序 OWASP Top 10（安全）：https://owasp.org/www-project-top-10-for-large-language-model-applications/
Google SRE 书（用于理解编排原则）：https://sre.google/sre-book/
摘要: 附录 B 划定了 Qwen Code 的内置功能与团队必须自行实现的流程之间的明确界限。使用标准量表（标准、推荐、前沿）有助于正确评估实施的复杂性。关键结论：Qwen Code 是一个强大的助手，但在关键节点（规范验证、文件仲裁、安全性）上，系统必须依赖于确定性项目脚本和通过钩子及 MCP 服务器严格配置的护栏。