---
name: telecom-rd-standards
description: 按中国电信软件研发规范起草、规划、审查和改进软件项目。用于新项目立项与技术方案、代码审查、架构、数据库、接口、安全、测试、CI/CD、仓库、制品、部署审查，以及研发云互联互通或 OpenAPI 集成；当任务提及中国电信、研发规范、研发云、C1-C4、代码审查、项目方案、合规或交付治理时使用。
---

# 中国电信软件研发规范

以本包内原始 DOCX 对应的脱敏 Markdown 整理版为导航依据。不得臆造强制控制，也不得把 C0 建议默认为强制要求。

## 按需加载与复用

1. 先阅读项目根目录的 `AGENTS.md`，再按 `INDEX.md` 的任务—规范选择矩阵最小化加载；不得为普通小改动通读全部规范。
2. 新项目、设计、审查、交付或需要作出规范结论的任务，加载本技能和对应功能规范；普通小范围实现或自查，先读取相关速查指南。
3. 安全、密钥、鉴权、数据库权限、外部接口、CI/CD、制品和部署变更，无论范围大小都加载相应功能规范。
4. 仅在标记 `规范要求`、给出 C 级别结论、提出阻断/整改项、处理高风险变更、遇到条款争议，或功能规范明确要求时，核验对应原文及章节；争议、表格、模板和版式回查原始 DOCX。
5. 在同一任务中复用已读取且未变更的内容；任务范围、目标 C 级别、技术栈、数据敏感性、外部接口或部署方式变化时，重新选择并补充加载。

## 建立基线

1. 明确任务类型：项目起草、代码审查、设计审查、交付审查或研发云集成。
2. 明确项目类别和目标能力等级；未分级项目暂按 C1，并要求项目负责人最终确认。C0 为最佳实践建议，C1-C4 为逐级增强的要求。
3. 明确语言/框架、数据存储、部署目标、外部接口、数据敏感性以及是否使用研发云。
4. 按任务加载下面对应的功能规范；需要作出规范结论或处理高风险事项时，通过 [规范原文索引](references/standards-map.md) 核验相应原文的章节和 C 级别。摘要与原文冲突时以原文为准。
5. 遵守保密要求：项目代码和文档属于中国电信内部资料，不得放入互联网暴露的存储、处理或传输工具。

## 新项目起草

先进行简要的结构化方案设计：

1. 写明业务目标、用户、成功度量、约束和非目标。
2. 列出假设、未知项、风险、数据分类和依赖；只追问会影响架构、安全、成本或交付的未知项。
3. 存在真实取舍时，给出 2-3 个方案，并从合规、安全、可运维性、交付成本和可逆性比较，推荐一个方案并说明理由。
4. 将选定方案转为可合规交付的计划：角色、需求追踪、设计产物、仓库和分支、测试、安全扫描、制品追溯/SBOM、流水线门禁和部署审批/回退。
5. 输出决策记录和初始待办；每个待办包含负责人、验收条件、关联需求、风险和目标版本。

需求与交付物使用 [生命周期检查清单](references/lifecycle-checklists.md) 中的流程和模板。每个需求都应能追溯到设计、代码、测试、发布和部署。

所有方案项标记为 `规范要求`、`工程建议` 或 `待确认`。只有原文明确支持的控制才能标为规范要求，且必须保留来源章节和 C 级别；不得把架构偏好、工具惯例或未经核验的数值阈值写成中国电信要求。

## 按功能加载规范

只读取与任务匹配的文件，再按其列出的原文核验：

- 新项目、架构或模块结构：[01-project-init-and-architecture.md](references/01-project-init-and-architecture.md)
- 需求、变更、验收或追踪：[02-requirements-and-traceability.md](references/02-requirements-and-traceability.md)
- Python 或前端实现/审查：[03-code-standards.md](references/03-code-standards.md)
- 表结构、SQL、迁移或数据库账号：[04-database-and-data-model.md](references/04-database-and-data-model.md)
- REST/OpenAPI、外部系统或研发云：[05-api-and-rd-cloud-integration.md](references/05-api-and-rd-cloud-integration.md)
- 安全、密钥、鉴权、依赖或部署加固：[06-security-and-secrets.md](references/06-security-and-secrets.md)
- 仓库、分支、提交、版本或评审流程：[07-repository-and-change-management.md](references/07-repository-and-change-management.md)
- CI/CD、制品、组件、SBOM 或发版：[08-ci-artifacts-and-release.md](references/08-ci-artifacts-and-release.md)
- 测试、缺陷、部署、验证或回退：[09-testing-and-deployment.md](references/09-testing-and-deployment.md)

## 审查工作

审查证据而不是意图：检查实际差异、配置、流水线、测试结果、部署方案和相关文档。

按下列顺序输出：

| 优先级 | 含义 | 输出格式 |
| --- | --- | --- |
| 阻断 | 违反原文强制控制，或造成重大安全/发布风险 | `【阻断】[C级别] 问题 — 证据 — 原文章节 — 必须整改项` |
| 需整改 | 未达到项目目标 C 级别的控制 | `【需整改】[C级别] 问题 — 证据 — 原文章节 — 整改项` |
| 建议 | C0 改进项或其他非强制实践 | `【建议】问题 — 收益 — 建议动作` |
| 通过/不适用 | 控制已有证据或不在范围内 | 简明说明证据或理由 |

代码审查优先检查：日志中的密钥和敏感数据、硬编码凭据、弱/私有加密、输入输出校验、授权、错误暴露、会话、第三方依赖风险；再检查语言规范、仓库/提交/分支、测试和追溯。结论必须引用原文和章节，不得仅凭文件名宣称合规。

设计、数据库、接口、流水线、制品或部署审查，先读取相应功能规范与 [生命周期检查清单](references/lifecycle-checklists.md)，对有争议或高影响控制再核验完整原文。

## 研发云与外部集成

使用 [研发云集成要点](references/rd-cloud-integration.md) 处理 OAuth、平台/用户级授权、OpenAPI、数据订阅和脚手架服务。不得在输出中暴露密钥、客户端凭据、账号密钥、令牌或签名头；按原文落实最小权限、审批账号、时间戳/防重放和网络传输控制。

## 交付格式

每次输出结尾说明：目标 C 级别（或“待确认”）、审查范围、阻断/整改项、建议、证据缺口和最小下一步。新项目还要包含选定方案、决策记录和首批合规里程碑。