| title | 文档内容审查报告（措辞 / 表达 / AI 编写痕迹） |
|---|---|
| description | ReCloud Studio 文档站全量 28 篇审查，覆盖表达不当四维度与 AI 痕迹三类信号 |
审查范围：全站 28 个
.mdx页面（约 4570 词，全 zh-CN）。 审查维度：重复冗余 / 空洞套话 / 语气错位 / 事实错误。 AI 痕迹信号：排比套话结构 / 跨文件复制粘贴 / 英文式翻译腔。 严重程度：🔴 严重（制度性矛盾、语气严重错位、事实错误）｜🟡 中等｜🟢 轻微。 组织方式：先「跨文件共性问题汇总」，后「逐页明细」。 说明：本报告只标注问题与改写建议（before → after），不直接修改文件。标[需核实]处为事实性待确认项。
以下为系统性、跨多页重复或同源生成的问题，建议统一在单一来源修复，避免逐页修补导致规则漂移。
以下结构在约 15 个页面末尾出现，仅邮箱前缀不同：
如果您对…有任何疑问，请通过以下方式联系我们：
- **邮箱**: xxx@worldexecute.me
- **GitHub**: 在项目中创建问题报告
命中页面：security/index、security/privacy-policy、open-source/public-license、open-source/internal-license（变体）、brand/index、brand/brand-guidelines、management/index、management/composition、management/powers、management/obligations、management/decision-making、management/impeachment、development/index、development/project-management、development/tech-standards。
➡️ 建议：抽离为 Starlight 公共组件 / MDX include 片段，全站统一维护邮箱与议题入口；各页仅传不同邮箱前缀。
| 文件 | 行号 | 命名 | 原文片段 |
|---|---|---|---|
| composition.mdx | 35 | 独立调查小组 / 独立计票小组 | 由与事项无利害关系的核心贡献者临时组成（变体） |
| obligations.mdx | 100 | 独立的审查小组 | 由独立的审查小组（由与事项无利害关系的核心贡献者临时组成）审查申诉 |
| impeachment.mdx | 32 | 独立的调查小组 | 成立独立的调查小组（由与事项无利害关系的核心贡献者临时组成） |
| conduct/index.mdx | 48 | 独立审查小组 | 同 obligations 句 |
| conduct/code-of-conduct.mdx | 91 | 独立审查小组 | 同 obligations 句 |
➡️ 建议：在 composition.mdx 统一定义术语「独立审查（调查）小组」及组成规则一次，其余页面仅引用，删除括号内长句复制，并统一「审查 / 调查」称谓。
「用户是决定一个团队成败的关键」「代码公开可见，接受社区监督」「通过协作与分享推动技术进步」「以创新创造为导向，不断探索新技术」在 manifesto/index、manifesto/mission、manifesto/identity 间逐字复制；且「技术的进步」与「技术进步」措辞不一致。
➡️ 建议：确立 manifesto/mission.mdx 为价值观唯一权威页，其余页面改为链接引用，并全站统一表述。
organization/index.mdx复制了 team-architecture / member-roles / external-relations 的架构图、角色表、对外关系列表。development/index.mdx几乎等于project-management.mdx+tech-standards.mdx的压缩复述（生命周期、角色、工具、代码/版本/测试/文档规范逐条对应）。
➡️ 建议：索引页改为「概述 + 子页链接 + 一句定位」，删除与子页重复的清单，提供真正导航增量。
brand/index 的「禁止修改（不得变形 / 不得变色 / 不得添加效果）」三条例与 brand-guidelines 逐字相同；「授权流程（提交申请 / 说明用途 / 等待审批 / 获得许可）」四步也逐字相同；且 brand/index 称「Logo 最小尺寸 32x32 像素」与 guidelines 的多场景细则（印刷 1inch、展示 10inch）冲突。
➡️ 建议：brand-guidelines 为细则权威源，brand/index 改为「详见《品牌使用规范》」引用，并修正尺寸概称。
management/index.mdx:41-51 与 management/powers.mdx:124-134 的「定期报告 / 财务公开 / 独立审计 / 投诉机制」逐字重复。
➡️ 建议：单页权威、他页链接。
「由 Tech Lead 与 Community Lead 共同代理」「剩余任期不足 2 个月则重新选举，否则由管理委员会临时指定代理」同时出现在 composition.mdx:90-92 与 impeachment.mdx:76-83，存在规则漂移风险。
➡️ 建议：composition.mdx 为唯一权威来源，impeachment 引用链接。
security/index.mdx:59-62 与 security/privacy-policy.mdx:81-84 的「加密存储 / 传输安全 / 访问控制 / 安全监控」四项整段重复。
➡️ 建议：二选一为权威描述，另一处引用或合并。
conduct/index.mdx 与 conduct/code-of-conduct.mdx 在「适用范围 1.2」「违规警告 4.1」「独立审查小组 5.3」「社区维护者定义」多处整句复制，且存在主体冲突（见 2.3 章 🔴 项）。
➡️ 建议：code-of-conduct 为权威定义，index 改为引用。
team-architecture.mdx 与 member-roles.mdx 对「角色全集」描述不一致：前者含「社区负责人（Community Lead）」「运营组（社区运营 / 内容运营）」「管理委员会」，后者仅 5 个角色且缺上述三者；三处引用（team-architecture 行 33/48、member-roles 行 102）彼此矛盾。
➡️ 建议：以 member-roles.mdx 为唯一角色权威源，补定义「社区负责人」「运营组」等，其余页面引用。
多页呈现高度规整的「- **名词**: 动词 + 同名名词」三层排比，信息密度低、可核查性差，为典型生成式结构：
manifesto/culture.mdx：「我们相信 X。通过 X，我们能够：」三连 + 「用户的 X 是…」三连（最典型，🔴）。management/powers.mdx：权力三层排比堆叠。management/decision-making.mdx：流程 / 原则 / 记录三层排比。management/obligations.mdx：义务各节「必须 + 同义」排比。open-source/*、brand/*：权利 / 义务 / 允许 / 禁止四类对称铺陈。external-relations.mdx：三类合作各 4 条排比。member-roles.mdx：五角色各「职责 / 权限」同构。
➡️ 建议：改为叙述式或表格，打破「恰好 N 条、句式平行」的生成痕迹；空泛条目补充可执行判定。
security/index、security/privacy-policy、conduct/*、management/impeachment、management/decision-making、management/powers、manifesto/mission 等开头/条文中使用「高度重视 / 重视并保护 / 致力于让… / 科学民主 / 确保组织健康发展」等愿景句式，与制度性严谨条文语气错位。
➡️ 建议：制度条文用「须 / 不得 / 负责」强制句式与可核查表述，删除公关化铺垫。
按 manifesto → organization → conduct/security → open-source/brand → management → development/index 顺序。每条格式：[严重程度] 类型 | 位置 | 问题，附 Before 与 After(建议)。
- [🟡中等] AI跨文件复制 | 核心纲领/17 | 与 mission.mdx:37 整句相同（已知重复句「用户是决定一个团队成败的关键」）
- Before: 用户至上: 用户是决定一个团队成败的关键
- After(建议): 合并到 mission.mdx 定义，本页改为引用。
- [🟡中等] AI跨文件复制 | 核心纲领/18 | 与 mission.mdx:38 整句相同（「代码公开可见，接受社区监督」）
- Before: 开源透明: 代码公开可见，接受社区监督
- After(建议): 集中定义，避免两页重复。
- [🟡中等] AI跨文件复制 | 核心纲领/20 | 与 identity.mdx:14、mission.mdx:40 重复（「通过协作与分享推动技术进步」，措辞「技术的进步/技术进步」不一致）
- Before: 社区驱动: 通过协作与分享推动技术进步
- After(建议): 仅一处展开，全站统一措辞。
- [🟡中等] 重复冗余 | 核心纲领/19 | 与 mission.mdx:39 完全重复（「以创新创造为导向，不断探索新技术」）
- Before: 创新驱动: 以创新创造为导向，不断探索新技术
- After(建议): 删除本页重复条目。
- [🟢轻微] 空洞套话 | 身份与定义/13 | 「有温度的产品」为模糊营销词
- Before: 我们以大多数用户为中心，探索并创造出有温度的产品
- After(建议): 我们以用户需求为中心，构建易用、可靠的开源产品 [需核实「以大多数用户」语义]。
- [🟡中等] AI跨文件复制 | 核心身份/14 | 与 index.mdx:20、mission.mdx:40 重复（「通过协作与分享推动技术进步」），且「我们相信社区的力量」为 AI 排比领起句
- Before: 我们相信社区的力量，通过协作与分享推动技术进步
- After(建议): 删除后半句（已在总纲/使命重复），本页只留身份定性。
- [🟡中等] AI跨文件复制 | 核心身份/13、15 | 「让代码透明可见」「所有贡献者都应得到公平对待」分别与 index.mdx:18、mission.mdx 重复
- Before: 我们构建开源软件，让代码透明可见 / 所有贡献者都应得到公平对待
- After(建议): 集中到总纲或使命定义，本页用「详见…」引用。
- [🟢轻微] 空洞套话 | 组织文化/24 | 「秉承开源精神」「相信透明、协作与共享的力量」为收尾口号套话
- Before: ReCloud Studio 秉承开源精神，以社区驱动的方式构建软件。我们相信透明、协作与共享的力量。
- After(建议): 合并进核心身份节，删除独立口号段。
- [🟡中等] AI跨文件复制 | 价值观/37 | 与 index.mdx:17 完全相同（已知重复句）
- Before: 用户至上: 用户是决定一个团队成败的关键
- After(建议): 保留本页为权威定义，删除 index 复制。
- [🟡中等] AI跨文件复制 | 价值观/38 | 与 index.mdx:18 相同（「代码公开可见，接受社区监督」）
- Before: 开源透明: 代码公开可见，接受社区监督
- After(建议): 集中定义。
- [🟡中等] AI跨文件复制 | 价值观/40 | 与 index.mdx:20、identity.mdx:14 重复
- Before: 社区驱动: 通过协作与分享推动技术进步
- After(建议): 同上。
- [🟡中等] 重复冗余 | 价值观/39 | 与 index.mdx:19 重复
- Before: 创新驱动: 以创新创造为导向，不断探索新技术
- After(建议): 同上。
- [🟡中等] 重复冗余 | 愿景/19、20、26 | 「决策过程透明公开」与「决策过程公开透明」仅词序不同，自我重复
- Before: 决策过程透明公开（20） / 决策过程公开透明（26）
- After(建议): 全站统一为「决策过程公开透明」。
- [🟢轻微] AI翻译腔 | 使命/9、11 | 「真切地体会到科技带来的美好」抽象翻译腔，无具体承诺
- Before: 让更多人真切地体会到科技带来的美好。我们相信，好的技术应该服务于人…
- After(建议): 明确可验证目标，如「降低开源软件使用门槛，让非专业用户也能部署我们的工具」[需核实具体产品承诺]。
- [🔴严重] AI排比结构 | 核心文化/11、19、27 | 「我们相信 X。通过 X，我们能够：」三连排比，三条结构完全对称，强 AI 痕迹
- Before: 我们相信开源的力量。通过开源，我们能够：- 让更多人参与… / 我们重视团队协作。通过协作，我们能够：… / 我们鼓励创新。通过创新，我们能够：…
- After(建议): 改为按「实践要求」展开，例如：
### 开源精神 我们要求所有主流项目默认公开源代码，并： - 在公开仓库接收 issue 与 PR - 发布变更日志供社区审计 - 重大决策在讨论期公示
- [🟡中等] 重复冗余 | 精神内核-用户至上/37-41 | 与 mission 价值观语义重复，且本身「用户的 X 是…」三连排比
- Before: 我们始终把用户放在首位：- 用户的需求是出发点 - 用户的满意度是标准 - 用户的反馈是动力
- After(建议): 与使命的用户至上合并，本页只写文化层具体行为 [需核实]。
- [🟢轻微] 空洞套话 | 行为准则/45-49 | 五条通用正能量条目，无可执行、无组织特异性
- Before: 诚实守信: 说到做到，不轻易承诺 / 尊重他人… / 积极主动… / 持续学习… / 团队合作…
- After(建议): 补可执行约束（如「公开承诺的功能须有里程碑跟踪；评审不得人身攻击」），或链接 conduct 章节。
- [🟢轻微] 结构失衡 | 全篇 | 「核心文化」3 节 vs 「精神内核」1 节，层级不均
- Before: 核心文化含 3 节，精神内核仅用户至上 1 节
- After(建议): 合并或补全。
- [🟡中等] 重复冗余 | 团队架构/成员角色/对外关系/11-38 | 三节分别复制三个子页核心内容（含 ASCII 图与表格），索引价值低
- Before: 行 13-20 架构图、24-30 角色表、34-38 对外关系列表
- After(建议): 改为「概述 + 子页链接 + 一句定位」，删除与子页重复内容。
- [🟢轻微] AI翻译腔 | 团队体系/9 | 「在清晰的层级架构之上，倡导扁平、平等的协作文化」介词结构直译
- Before: ReCloud Studio 在清晰的层级架构之上，倡导扁平、平等的协作文化，鼓励成员直接沟通与平等协作。
- After(建议): ReCloud Studio 采用层级清晰但文化扁平的组织方式，鼓励成员直接、平等地协作。
- [🟡中等] 跨文件近似复制 | 对外关系/34 | 与 external-relations.mdx:9 句式高度雷同
- Before: 我们与外部组织保持开放的合作关系：
- After(建议): 索引页此处仅留链接与一句话概述。
- [🟡中等] 事实错误（跨文件不一致） | 汇报关系/决策流程/33、48 | 引入「社区负责人（Community Lead）」「管理委员会」但未在 member-roles 定义
- Before: 行 33「社区负责人（Community Lead）: 向管理员汇报」；行 48「重大决策由管理委员会集体讨论」
- After(建议): 在 member-roles 补定义，或明确管理委员会组成 [需核实是否真实存在]。
- [🟡中等] 事实错误（跨文件不一致） | 组织架构/17-25 | 架构图含「社区运营 / 内容运营」属运营组，但 member-roles 五个角色未涵盖
- Before: 行 21「社区运营」、行 25「内容运营」
- After(建议): 在 member-roles 增补运营组角色，或本页注明归属 [需核实是否正式设岗]。
- [🟢轻微] 空洞套话 | 决策流程-重大决策/50-54 | 普适流程模板，未说明触发条件、表决规则、时限
- Before: 提出议题 → 收集意见 → 讨论方案 → 集体决策 → 执行与反馈
- After(建议): 补充重大决策定义、表决门槛、记录公示位置。
- [🟢轻微] 空洞套话 | 团队组成/9 | 「由以下团队组成：」后纯列举，无规模/准入边界
- Before: ReCloud Studio 由以下团队组成：
- After(建议): 补各团队规模或准入方式（如「社区贡献者通过 PR 合并后纳入」）。
- [🟢轻微] AI排比结构 | 社区贡献者/用户社区/18-33 | 两类群体各四分式排比罗列，信息密度低
- Before: 行 22-25 代码/文档/翻译/测试贡献者；行 31-33 普通/活跃/布道者
- After(建议): 合并说明或补每类「如何成为」门槛。
- [🟢轻微] 重复冗余 | 协作方式/41-43 | 工具名 + 功能解释属常识复述
- Before: GitHub Issues: 任务分配和问题跟踪 / Pull Requests: 代码审查和合并 / 文档协作: 在线文档编辑和评论
- After(建议): 改为「详见各项目 CONTRIBUTING」或仅保留链接。
- [🟡中等] 事实错误（跨文件不一致） | 角色晋升/102 | 写「负责人（Tech Lead / Community Lead）」但未定义 Community Lead
- Before: 从核心贡献者到负责人（Tech Lead / Community Lead）
- After(建议): 先补 Community Lead 定义，或改为仅 Tech Lead。
- [🟢轻微] 重复冗余 | 贡献者/56 | 「贡献者参与项目的贡献：」主谓宾循环
- Before: 贡献者参与项目的贡献：
- After(建议): 贡献者通过提交 PR 参与项目：
- [🟢轻微] AI排比结构 | 角色定义全章/9-82 | 五角色严格按「职责 4 条 / 权限 3-4 条」同构，AI 批量生成特征明显；部分空泛
- Before: 每个角色均为「职责:」+ 4 项、「权限:」+ 3-4 项
- After(建议): 空泛条目具体化（如「社区支持」→「在 Issues 中回应新手提问」），允许不同角色条目数不一致。
- [🟢轻微] 空洞套话 | 核心贡献者/41 | 「核心贡献者是团队的中坚力量：」定性套话
- Before: 核心贡献者是团队的中坚力量：
- After(建议): 直接以职责列表开头，删定性引导句。
- [🟡中等] AI排比结构 | 合作原则及三子节/9-36 | 「开放、透明、互利」三连词 + 三类各 4 条平行短句，结构完全对称
- Before: 行 9「开放、透明、互利的合作关系」；行 15-18、24-27、33-36 三组四联排比
- After(建议): 保留三类合作但打破逐字对称，按实际合作深度区分描述。
- [🟡中等] 跨文件近似复制 | 合作原则/9 | 与 index.mdx:34 高度近似
- Before: 我们与外部组织保持开放、透明、互利的合作关系。
- After(建议): 索引页删去此概述仅留链接。
- [🟢轻微] 空洞套话 | 合作流程/40-45 | 六步通用商务模板，未含 ReCloud 特有约束
- Before: 初步接触 → 需求沟通 → 方案制定 → 协议签订 → 项目执行 → 成果评估
- After(建议): 在「协议签订」前插入「品牌与开源合规审查」节点。
- [🟡中等] AI跨文件复制 | 适用范围/38 | 与 code-of-conduct.mdx:15 整句相同
- Before: 本行为准则适用于所有社区空间，包括但不限于 GitHub 仓库、官方邮箱与社交媒体频道以及面对面或虚拟活动。任何违反本行为准则的人都可能受到社区维护者的制裁或驱逐。
- After(建议): 以 code-of-conduct 1.2 为准，此处改为引用。
- [🟢轻微] AI跨文件复制 | 执行/33 | 与 code-of-conduct.mdx:68 相同（违规警告句）
- Before: 违规者将收到私人警告，说明违规行为以及预期采取的纠正措施。
- After(建议): 本页引用 code-of-conduct 4.1。
- [🟡中等] AI跨文件复制 | 申诉机制/48 | 「独立审查小组（由与事项无利害关系的核心贡献者临时组成）」与 code-of-conduct.mdx:91 重复
- Before: 由独立审查小组（由与事项无利害关系的核心贡献者临时组成）复核并做出最终决定。
- After(建议): 定义一次，此处引用。
- [🟡中等] 语气错位 | 我们的承诺/9 | 「友好、安全和公平的地方」公关愿景腔置于制度条文
- Before: 我们致力于让我们的社区成为一个友好、安全和公平的地方。
- After(建议): 我们制定本准则，以明确社区成员在协作过程中的行为标准与权利义务。
- [🟡中等] 事实错误/主体冲突 | 适用范围/38 vs code-of-conduct.mdx:83 | index 称「社区维护者」制裁，code-of-conduct 5.1 称解释权归「管理层」
- Before: 任何违反本行为准则的人都可能受到社区维护者的制裁或驱逐。
- After(建议): 统一制裁/解释主体表述 [需核实权责划分]。
- [🟡中等] AI跨文件复制 | 1.2/15 | 与 index.mdx:38 整句复制
- Before: 本行为准则适用于所有社区空间，包括但不限于 GitHub 仓库、官方邮箱与社交媒体频道以及面对面或虚拟活动。
- After(建议): 保留此篇为权威定义，index 改为引用。
- [🟢轻微] AI跨文件复制 | 4.1/68 | 警告句与 index.mdx:33 复制
- Before: 警告: 违规者将收到私人警告，说明违规行为以及预期采取的纠正措施。
- After(建议): 以本篇为详述，index 引用。
- [🟡中等] AI跨文件复制 | 5.3/91 | 「独立审查小组（…）」与 index.mdx:48 重复
- Before: 由独立审查小组（由与事项无利害关系的核心贡献者临时组成）复核并做出最终决定。
- After(建议): 定义一次，另一处引用。
- [🟡中等] 重复冗余/生硬拼接 | 4.2/76 & 5.3/91 | 「社区维护者由管理员与社区负责人共同担任」两处出现，5.3 硬接句末
- Before: …复核并做出最终决定。社区维护者由管理员（Director）与社区负责人（Community Lead）共同担任。
- After(建议): 定义移至总则/4.2，5.3 仅留申诉流程。
- [🟡中等] 语气错位 | 1.1/11 | 「友好、安全和公平的环境中协作」同套话
- Before: 确保所有参与者都能在友好、安全和公平的环境中协作。
- After(建议): 确保所有参与者在明确的规则下公平协作，并享有可预期的救济途径。
- [🔴严重] 事实错误/语气错位 | 5.1/83 vs 5.3/91 | 「解释权归管理层」与「独立审查小组做出最终决定」主体冲突
- Before: 本行为准则的解释权归 ReCloud Studio 管理层所有。…由独立审查小组（…）复核并做出最终决定。
- After(建议): 明确「管理层拥有解释权，但最终裁决由独立审查小组作出」，消除矛盾。
- [🟢轻微] 空洞套话 | 5.2/87 | 「将根据实际情况进行修订」无版本/记录机制
- Before: 本行为准则将根据实际情况进行修订，修订历史将在官方文档中记录。
- After(建议): 明确修订触发条件、审批人与变更日志位置。
- [🔴严重] 语气错位 | 概述/9 | 「高度重视…承诺采取一切必要措施」公关稿腔置于制度条文
- Before: ReCloud Studio 高度重视用户数据的安全与隐私保护。我们承诺采取一切必要措施保护用户数据不被泄露、篡改或丢失。
- After(建议): ReCloud Studio 对用户数据的安全与隐私保护负直接责任，通过以下技术与管理制度防止数据泄露、篡改或丢失。
- [🟡中等] 空洞套话 | 安全原则/15、19、23、27 | 各原则单句空话，无字段级/操作级内容
- Before: 只收集必要的用户数据，不收集与服务无关的信息。
- After(建议): 列明各模块最小数据字段（如登录仅需邮箱）及超期删除机制。
- [🟡中等] AI跨文件复制 | 技术措施/59-62 vs privacy-policy.mdx:81-84 | 「加密存储/传输安全/访问控制/安全监控」四项整段重复
- Before: - 加密存储: 使用加密技术保护敏感数据 / - 传输安全: 使用 HTTPS 等安全协议 / - 访问控制: 严格访问控制策略 / - 安全监控: 部署安全监控系统
- After(建议): index 保留概要，privacy-policy 引用或合并。
- [🟢轻微] AI排比结构 | 管理措施/66-69 | 「培训/制度/应急/审计」排比但每条仅一句空泛
- Before: - 安全培训: 定期进行安全培训 / - 安全制度: 建立完善的安全管理制度 / …
- After(建议): 每条补频率与责任方。
- [🟢轻微] 重复冗余 | 安全审计/27 vs 定期审计/69 | 「安全审计」两度出现
- Before: 定期进行安全审计，及时发现和修复安全漏洞。 / - 定期审计: 定期进行安全审计和检查。
- After(建议): 合并为一条，注明周期与输出物。
- [🟢轻微] 语气错位 | 联系方式/93-96 | 统一收尾块（已知）
- Before: 如果发现安全问题，请立即通过以下方式联系我们：- 邮箱: security@worldexecute.me - GitHub: 在项目中创建安全问题报告
- After(建议): 保留，但与隐私页联系段统一模板字段。
- [🔴严重] 语气错位 | 隐私承诺/9 | 「重视并保护用户的隐私权」公关腔，置于政策条文
- Before: ReCloud Studio 重视并保护用户的隐私权。我们仅在必要范围内收集、使用或分享用户的个人信息…
- After(建议): ReCloud Studio 依据《个人信息保护法》等法律法规，在必要范围内收集、使用或分享用户个人信息，并遵循以下原则：
- [🟡中等] AI排比结构 | 用户权利/96-114 | 五条「用户有权…」机械排比，每条仅一句且无申请路径/时限
- Before: 用户有权访问其个人信息。 / 用户有权更正… / 用户有权要求删除…
- After(建议): 每条补申请渠道与响应时限（如「通过 privacy@worldexecute.me 提交，30 日内响应」）。
- [🟡中等] AI跨文件复制 | 数据安全/81-84 vs security/index.mdx:59-62 | 四项安全措施整段重复
- Before: - 加密存储: 敏感数据使用加密存储 / - 传输安全: 使用 HTTPS / - 访问控制: 严格控制访问权限 / - 安全监控: 部署安全监控系统
- After(建议): 二选一为权威描述，另一处引用。
- [🟢轻微] 空洞套话 | 我们不会做的/57-59 | 三条承诺式空话，无例外与救济说明
- Before: - 出售数据: 我们不会出售用户的个人信息 / - 未经授权分享: …
- After(建议): 补例外情形（如司法要求）与举报路径。
- [🟢轻微] 事实核查 | 儿童隐私/118 | 「不满 14 周岁」阈值与 PIPL 一致，但「主要面向一般用户」模糊 [需核实] 是否存在未成年用户实际场景及监护人验证
- Before: 我们主要面向一般用户提供服务，不专门针对儿童。若用户不满 14 周岁，应在监护人知情并同意的前提下使用…
- After(建议): 明确是否实际收集未成年人信息及监护人同意核验方式。
- [🟢轻微] 重复冗余 | 相关页面/15、126 | 与 security/index 双向互链且正文两次出现「相关页面」
- [🟢轻微] 重复冗余 | 概述/9 vs public-license/9 | 对外项目采用 AGPL-3.0 声明两文件首段几乎原句重复
- Before: 我们所有对外公开的项目均采用 GNU Affero General Public License v3.0 (AGPL-3.0) 协议。
- After(建议): 概述保留一句，细节交 public-license，本处改「具体权利与义务见《开源项目使用指南》。」
- [🟡中等] AI跨文件复制 | 使用我们的代码/35-50 vs public-license 权利/义务 | 整段「权利/义务」清单与 public-license 高度重合
- Before: 使用/学习/贡献/分发四权利；五义务
- After(建议): index 作总览只留一句指向 public-license，删除整段。
- [🟢轻微] 空洞套话 | 您的权利/39-42 | 「使用/学习/贡献/分发」同义铺陈式排比
- Before: 使用: 可以自由使用我们的代码 / 学习: 可以学习我们的代码实现
- After(建议): 合并为「您可自由使用、学习、修改并向我们回馈代码」。
- [🟢轻微] AI翻译腔 | 您的义务/47 | 「声明: 在使用我们的代码时，必须声明代码来源」标题与正文同义反复
- Before: 声明: 在使用我们的代码时，必须声明代码来源
- After(建议): 署名: 使用时须注明代码来源与许可证。
- [🟡中等] 事实错误/自洽 | 概述/9 | 称内部项目「采用 AGPL-3.0 协议许可」但未厘清与 AGPL 第 13 条强制公开义务的张力
- Before: 内部项目的代码采用 AGPL-3.0 协议许可，但访问权限仅限内部成员
- After(建议): 补「内部项目不对外分发/提供服务，AGPL 公开义务暂不触发；若将来对外提供网络服务须满足第 13 条」[需核实内部项目是否真以 AGPL 文本授权]。
- [🟢轻微] AI排比结构 | 权利/29-39、义务/43-53 | 「小标题 + 三条」模板化排比
- Before: 开发使用/测试使用/学习使用三条并列
- After(建议): 合并为段落式描述以降低模板感。
- [🟡中等] AI跨文件复制/空话 | 联系方式/57-59 | 收尾块同模板，且「内部沟通: 通过内部沟通渠道联系」无实际入口
- Before: - 内部沟通: 通过内部沟通渠道联系
- After(建议): 给出具体渠道名，否则删除该空条目。
- [🟡中等] AI跨文件复制 | 联系我们/81-84 | 已知收尾块，与 brand/index、brand-guidelines 同构
- Before: 如果您对我们的开源协议有任何疑问，请通过以下方式联系我们：- 邮箱: opensource@worldexecute.me - GitHub: 在项目中创建问题报告
- After(建议): 统一抽为组件；邮箱 opensource@ 需确认已开通 [需核实]。
- [🟢轻微] 空洞套话 | 使用示例/69-77 | 「错误使用」示例仅注释式说教，未展示真实违规后果
- Before: // 不要这样做：没有声明来源，且使用闭源协议…
- After(建议): 改为「以下情形违反 AGPL：① 闭源分发；② 网络服务不公开源码」。
- [🟢轻微] AI翻译腔 | 网络公开义务/52 | 「提供下载: 必须提供源代码的下载方式」标题即正文
- Before: - 提供下载: 必须提供源代码的下载方式
- After(建议): 下载渠道: 须提供可获取完整源码的链接。
- [🟢轻微] 事实核对 | 概述/9 | 「使用我们的开源代码前」暗示所有代码皆开源，与 internal-license「内部非开源」并存易混淆
- Before: 使用我们的开源代码前，请仔细阅读以下说明。
- After(建议): 使用我们对外公开的开源代码前…
- [🔴严重] AI跨文件复制 | 禁止修改/61-63 vs brand-guidelines/48-50 | 三条「不得变形/不得变色/不得添加效果」逐字相同
- Before: - 不得变形: 不得改变 Logo 的形状 / - 不得变色: 不得改变 Logo 的颜色 / - 不得添加效果: 不得为 Logo 添加阴影、边框等效果
- After(建议): index 仅留「详见《品牌使用规范》的禁止修改章节」，删除三条复制。
- [🟡中等] AI跨文件复制 | 授权流程/69-72 vs brand-guidelines/69-72 | 「提交申请/说明用途/等待审批/获得许可」四步完全相同
- Before: 1. 提交申请 2. 说明用途 3. 等待审批 4. 获得许可
- After(建议): 仅一处保留完整流程，另一处链接引用。
- [🟡中等] 事实错误/自洽 | 尺寸要求/50 vs brand-guidelines/19-24 | 「Logo 最小 32x32 像素」与细则多场景冲突
- Before: - 最小尺寸: Logo 的最小尺寸为 32x32 像素
- After(建议): 改为「不同场景最小尺寸见《品牌使用规范》；网页图标最低 32x32 px」。
- [🟢轻微] 空洞套话 | 概述/9 | 「我们致力于保护品牌的一致性和完整性」套话
- Before: 我们致力于保护品牌的一致性和完整性。
- After(建议): 改为「未经授权使用品牌可能误导公众并损害组织声誉，故制定本规范」。
- [🟢轻微] AI排比结构 | 允许/禁止的使用/34-44 | 四项对称铺陈
- Before: 引用/合作/教育/新闻四并列
- After(建议): 合并为「可在引用、合作、教育、新闻报道中如实使用」。
- [🟢轻微] 空洞套话 | Logo/21-23 | 「主 Logo: ReCloud Studio 官方标识」循环定义
- Before: - 主 Logo: ReCloud Studio 官方标识
- After(建议): 给出实际文件名/矢量图位置或删除空描述。
- [🟡中等] AI跨文件复制 | 联系方式/80-83 | 已知收尾块（同 public-license、brand/index）
- Before: 如果您对品牌使用规范有任何疑问，请通过以下方式联系我们：- 邮箱: brand@worldexecute.me - GitHub: 在项目中创建问题报告
- After(建议): 统一为共享片段；brand@ 需确认已开通 [需核实]。
- [🔴严重] AI跨文件复制 | 禁止修改/48-50 | 与 brand/index/61-63 逐字重复
- Before: 同 index 三条
- After(建议): 保留此处权威版本，index 改为引用。
- [🟡中等] AI跨文件复制 | 授权流程/69-72 | 与 brand/index/69-72 逐字重复
- Before: 四步相同
- After(建议): 单源维护。
- [🟢轻微] AI排比结构 | 图标风格/34-36、颜色/38-42、禁止/55-57 | 多项模板化排比
- Before: 线性图标/统一粗细/统一尺寸
- After(建议): 合并为「图标须为线性风格，线条粗细与尺寸统一」。
- [🟢轻微] 空洞套话 | 留白区域/28 | 「必须保留足够的留白区域」中「足够」无量化
- Before: Logo 周围必须保留足够的留白区域，最小留白区域为 Logo 高度的 50%。
- After(建议): 直接写「Logo 周围留白不得小于其高度的 50%」。
- [🟡中等] 空洞套话 | 概述/9 | 「在充分征询社区意见的基础上」模糊限定语，无机制支撑
- Before: 管理层（Leadership）是团队的最高决策机构（在充分征询社区意见的基础上），负责制定组织的发展战略和重大决策。
- After(建议): 管理层（Leadership）是团队的最高决策机构，负责制定发展战略与重大决策（征询机制见决策机制章节）。
- [🟡中等] AI跨文件复制 | 联系方式/55-59 | 全站统一收尾块（六页一致）
- Before: 如果您对管理规范有任何疑问，请通过以下方式联系我们：- 邮箱: management@worldexecute.me - GitHub: 在项目中创建问题报告
- After(建议): 抽离为公共组件。
- [🟢轻微] 重复冗余 | 职责与权限/19-31 | 「重大决策」两度出现且与定义处复述
- Before: - 重大决策: 做出重大决策 / - 决策权: 有权做出重大决策
- After(建议): 删除重复项，统一在决策机制章节定义。
- [🟢轻微] 重复冗余 | 监督机制/41-51 | 与 powers.mdx:124-134 几乎逐字重复
- Before: 定期报告/独立审计/投诉机制三项
- After(建议): 本页改概述 + 链接至 powers.mdx。
- [🟡中等] AI跨文件复制 | 联系方式/94-98 | 与全站六页统一收尾块同句复制
- Before: 如果您对管理组织的构成与选拔有任何疑问，请通过以下方式联系我们：- 邮箱: management@worldexecute.me - GitHub: 在项目中创建问题报告
- After(建议): 抽离公共组件。
- [🟡中等] AI跨文件复制 | 特殊情况/90-92 vs impeachment.mdx:76-83 | 代理/重选规则分叉复制
- Before: 管理员（Director）缺席: 由 Tech Lead 与 Community Lead 共同代理职责 / 辞职: 剩余任期不足 2 个月则重新选举，否则由管理委员会临时指定代理
- After(建议): composition 为唯一权威来源，impeachment 引用。
- [🟢轻微] 空洞套话 | 选拔原则/41-44 | 四项「形容词 + 同义复述」排比空话
- Before: - 公平竞争: 所有合格候选人都有公平的竞争机会 / - 公开透明: 选拔过程公开透明
- After(建议): 合并为「选拔须公开、公平、以能力与贡献为优先，重大选拔由全体成员投票」。
- [🟢轻微] 重复冗余 | 选举阶段/50-55 vs 任期届满/83-86 | 表述重复
- Before: 计票阶段/公布结果…
- After(建议): 选举流程聚焦差异步骤，交接/换届细节仅留任期管理。
- [🟡中等] AI排比结构 | 权力清单/38-104 | 全章「X 权 > 子项 > 三项『- 名词: 有权+名词』」极度规整三层排比，AI 生成痕迹强
- Before: - 团队负责人: 有权任命各团队负责人 / - 核心成员: 有权任命核心团队成员 / …
- After(建议): 压缩为角色权限表或按角色分段叙述，删除「有权+同名名词」自我重复。
- [🟡中等] AI跨文件复制 | 监督机制/124-134 | 与 index.mdx:41-51 逐字重复
- Before: 定期报告/独立审计/投诉机制三项
- After(建议): 删除本页监督段，链接回 index 或 obligations。
- [🟡中等] 语气错位 | 行使原则/108-113 | 「合法合规/公平公正/透明公开/接受监督」无主语口号，应用「须/不得」强制句式
- Before: - 合法合规: 权力行使必须合法合规 / - 公平公正: 权力行使必须公平公正
- After(建议): 改写为「行使权力须合法合规、公平公正，重大事项公开透明并接受监督」。
- [🟢轻微] 空洞套话 | 概述/9 | 「行使权力时必须遵守相关规范」无信息占位句
- Before: ReCloud Studio 管理层拥有以下权力，行使权力时必须遵守相关规范。
- After(建议): 改为「具体行使规范与限制见下方各节及《义务与限制》」。
- [🔴严重] AI跨文件复制 + 命名矛盾 | 申诉流程/100 | 「独立的审查小组（…）」与 impeachment.mdx:32「独立的调查小组（…）」同句复制且命名不一致
- Before: 2. 审查申诉: 由独立的审查小组（由与事项无利害关系的核心贡献者临时组成）审查申诉
- After(建议): 统一命名为「独立审查（调查）小组」，定义一次（composition.mdx 已定义），本页与 impeachment 均引用。
- [🟡中等] 重复冗余 | 违规处理/71-87 vs impeachment 弹劾后果/48-52 | 「罢免职务」两处出现，处理层级未区分
- Before: obligations.mdx:81 情节严重者罢免职务 / impeachment.mdx:50 被弹劾人立即罢免职务
- After(建议): 明确 obligations 的违规处理仅指非弹劾类内部处分，弹劾罢免归属 impeachment。
- [🟡中等] AI跨文件复制 | 联系方式/104-108 | 全站统一收尾块
- Before: 如果您对管理组织的义务与限制有任何疑问，请通过以下方式联系我们：- 邮箱: management@worldexecute.me - GitHub: 在项目中创建问题报告
- After(建议): 抽离公共组件。
- [🟢轻微] 空洞套话 | 义务各节/13-41 | 「必须忠实履行职责/必须维护组织的整体利益」同义反复
- Before: - 忠实履职: 必须忠实履行职责 / - 维护利益: 必须维护组织的整体利益
- After(建议): 改写为可核查义务（如「不得从事与组织利益冲突的外部任职」）。
- [🟢轻微] 事实错误 | 决策权限制/57-61 | 标注「集体决策」但 powers.mdx 战略决策归属管理员/Director 单独，角色归属存在张力 [需核实管理员在重大决策中的个人裁量边界]
- Before: ### 决策权限制（集体决策）/ - 集体决策: 重大决策必须集体决策
- After(建议): 明确「重大决策由管理委员会集体决策，管理员无单独否决/单方决定权」。
- [🔴严重] 重复冗余 + 内部矛盾 | 重大决策定义/11-20 vs 决策类型>重大决策/39-47 | 两节对「重大决策」列举不一致且重复
- Before: 定义含「品牌战略、罢免、对外签约与国际交流」；类型节缺失这些项
- After(建议): 删除「决策类型>重大决策」整节改引用，并补齐类型节缺失项，确保两处一致。
- [🟡中等] 语气错位 | 概述/9 | 「科学、民主的决策机制，确保决策的合理性和有效性」公关套话
- Before: ReCloud Studio 管理层采用科学、民主的决策机制，确保决策的合理性和有效性。
- After(建议): 概述改为「本页规定重大与日常决策的划分、会议与表决程序」。
- [🟡中等] AI排比结构 | 流程/50-85、原则/89-105、记录/109-121 | 大量「- 名词: 名词+性/化/度」三层排比，「充分讨论」重复出现
- Before: - 数据驱动: 基于数据和事实做出决策 / - 专业判断: 依靠专业判断做出决策 / - 风险评估: 充分评估决策风险
- After(建议): 合并为原则性条目，改用叙述式。
- [🟡中等] 内部矛盾 | 表决规则 | 会议制度/25「平票由管理员裁决」与 决策表决/77「一人一票，多数决」未对齐
- Before: - 表决原则: 一人一票，多数决
- After(建议): 改为「一人一票，过半数通过；平票时由管理员（Director）裁决」。
- [🟡中等] AI跨文件复制 | 联系方式/155-159 | 全站统一收尾块
- After(建议): 抽离公共组件。
- [🟢轻微] 空洞套话 | 紧急决策/129-131 | 「快速反应/事后报告/追认程序」抽象占位，未给时限
- Before: - 快速反应: 快速做出决策 / - 事后报告: 决策后及时报告
- After(建议): 明确「紧急决策须于 X 小时内书面通报，Y 日内追认」[需核实具体时限]。
- [🔴严重] AI跨文件复制 + 命名矛盾 | 调查/32 | 「独立的调查小组（…）」与 obligations.mdx:100「独立的审查小组（…）」同句复制，且 composition 称「独立调查小组/独立计票小组」三页命名不统一
- Before: - 调查小组: 成立独立的调查小组（由与事项无利害关系的核心贡献者临时组成）
- After(建议): composition.mdx 统一定义术语，本页与 obligations 引用，删除复制长句。
- [🟡中等] AI跨文件复制 | 特殊更替/74-83 vs composition.mdx:90-92 | 代理/重选规则分叉
- Before: 短期缺席: 由 Tech Lead 与 Community Lead 共同代理 / 长期缺席: 剩余任期不足 2 个月则重新选举，否则由管理委员会临时指定代理
- After(建议): composition 为唯一权威，本页引用链接。
- [🟡中等] 语气错位 | 概述/9 | 「建立完善的弹劾与更替机制，确保组织的健康发展和领导层的有效运作」公关稿腔，用于弹劾严肃条文判错位
- Before: ReCloud Studio 管理组织建立完善的弹劾与更替机制，确保组织的健康发展和领导层的有效运作。
- After(建议): 改为「本章规定管理成员的弹劾条件、程序与职务更替规则」。
- [🟡中等] AI跨文件复制 | 联系方式/135-139 | 全站统一收尾块
- After(建议): 抽离公共组件。
- [🟢轻微] 空洞套话 | 弹劾后果/48-52 | 「声誉影响: 对个人声誉造成影响」空话
- Before: - 声誉影响: 对个人声誉造成影响
- After(建议): 删除或改为「弹劾结果记入永久档案并公示」。
- [🟢轻微] 重复冗余 | 争议处理/115-119 vs obligations 申诉机制 | 程序相似但未交叉引用
- Before: 内部调解/独立审查/最终裁决
- After(建议): 明确本页争议针对选举/弹劾/更替，obligations 申诉针对违规处分，互相链接。
- [🔴严重] AI跨文件复制 | /24 | 「用户是决定一个团队成败的关键」与 manifesto/index.mdx:17、mission.mdx:37 完全一致，首页应独立表述
- Before: 我们相信，用户是决定一个团队成败的关键
- After(建议): 改写为首页自有表述，或明确引用总纲而非原句复制。
- [🟡中等] 重复冗余 | /22 vs /4、/7 | 首段重复 hero tagline（「我们构建公平、透明、社区驱动的软件」）
- Before: ReCloud Studio 是一个致力于开源软件开发的小型团队。我们构建公平、透明、社区驱动的软件。
- After(建议): 删除第二句或补团队定位具体信息 [需核实实际方向]。
- [🟡中等] 空洞套话 | /24 | 「更好的未来正在到来…真切地感受到科技带来的美好」营销式空洞
- Before: 我们始终相信更好的未来正在到来。我们相信，用户是决定一个团队成败的关键，更好的体验能够让更多人真切地感受到科技带来的美好。
- After(建议): 删除或改为「我们以用户价值为导向，优先打磨开发者体验」。
- [🟡中等] AI跨文件复制 | /28 | 「代码公开可见，接受社区监督」与 manifesto 两页高度一致
- Before: 对外公开项目的代码公开可见（AGPL-3.0），接受社区的监督与贡献。
- After(建议): 注明「详见《开源协议》章节」，避免与总纲逐字重复。
- [🟡中等] 重复冗余 | /27、/36、/56-57 | 同一 CardGrid 内 AGPL-3.0 被提 3 次
- Before: 我们所有对外公开的项目均采用 AGPL-3.0 协议 / 所有项目均采用 AGPL-3.0 协议，了解使用规则。
- After(建议): 保留一处强调，其余改「详见《开源协议》」。
- [🔴严重] AI跨文件复制 | 全篇 | 「项目管理规范」「技术开发规范」与 project-management.mdx、tech-standards.mdx 句子层面大面积重复，索引页未提供独有导航价值
- Before: ## 项目管理规范 / ## 技术开发规范（与另两页高度重合）
- After(建议): 改为真正索引页——2-3 句概述 + 链接，删除与子页重复清单。
- [🟡中等] 空洞套话 | /9 | 「确保项目的高效开发和高质量交付」目标空话
- Before: ReCloud Studio 制定项目管理与技术开发规范，确保项目的高效开发和高质量交付。
- After(建议): 改为「涵盖生命周期、角色、工具链与代码/测试/发布标准」。
- [🟢轻微] 空洞套话 | /40-43 | 代码规范四项同义循环
- Before: 代码风格: 遵守项目的代码风格指南 等
- After(建议): 直接链接 tech-standards 对应小节。
- [🟡中等] AI跨文件复制 | /47-50 vs tech-standards.mdx:38-41 | 「使用 Git Flow 或 GitHub Flow」「遵守 Conventional Commits」「所有代码必须经过审查」「使用 Squash Merge 或 Rebase」逐句相同
- After(建议): 子页已详述，索引页删除或引用。
- [🟡中等] AI跨文件复制 | /94-97、/101-104 vs tech-standards.mdx | 「文档类型」四项、「文档要求」四项逐字相同
- After(建议): 合并到 tech-standards，索引页不重复。
- [🟢轻微] AI排比结构 | /70-73 | 审查原则「及时性/建设性/尊重性/学习性」四词排比套话
- Before: 学习性: 将审查视为学习机会
- After(建议): 删除或并入一句话。
- [🟡中等] AI跨文件复制 | /108-110 | 统一联系方式收尾块（全站 13 处之一）
- After(建议): 抽为公共组件。
- [🟡中等] AI跨文件复制 | /13-53 vs development/index.mdx:15-20 | 项目生命周期六阶段两页重复
- After(建议): 索引页仅引用本页。
- [🟡中等] AI跨文件复制 | /78 vs development/index.mdx:27 | 「视项目规模需要，可临时增设…」几乎原句复制
- After(建议): 保留本页权威表述，索引页引用。
- [🟢轻微] AI排比结构 | /96-113 | 敏捷/透明/质量三节各四词排比，偏套话但属合理清单
- After(建议): 可接受；精简可合并为段落。
- [🟡中等] AI跨文件复制 | /110 vs tech-standards.mdx:40、index.mdx:49 | 「所有代码必须经过审查」三页逐字相同
- After(建议): 统一一处定义，其余引用。
- [🟡中等] AI跨文件复制 | /133-135 | 统一联系方式收尾块
- After(建议): 抽公共组件。
- [🟢轻微] 空洞套话 | /15-18 | 通用规范「清晰性/可维护性/可测试性/一致性」四词同义循环
- Before: 清晰性: 代码必须清晰易懂 等
- After(建议): 保留作原则标题或合并为一段。
- [🟡中等] 事实错误 | /189 | 「包管理: bun（前端）、cargo（Rust）、go（Go）」——go 非包管理器（依赖由 go mod 管理）
- Before: 包管理: bun（前端）、cargo（Rust）、go（Go）
- After(建议): 改为「bun（前端）、cargo（Rust）、Go Modules（Go）」或把 go 移至构建工具。
- [🟡中等] 事实错误 | /202 | 「持续部署: Cloudflare Pages、Vercel」——本站（及 AGENTS.md）仅用 Cloudflare Pages
- Before: 持续部署: Cloudflare Pages、Vercel
- After(建议): 改为「Cloudflare Pages」[需核实是否确有其他项目用 Vercel]。
- [🟢轻微] 事实错误/不严谨 | /190 | 「构建工具: Vite、Webpack、esbuild」三者定位不同，非并列同层
- Before: 构建工具: Vite、Webpack、esbuild
- After(建议): 改为「Vite / esbuild（前端构建），Webpack（遗留项目）」[需核实]。
- [🟢轻微] 自洽提示 | 版本控制节 | SemVer 仅在 development/index.mdx:61 提及，tech-standards 版本控制章未显式列出
- After(建议): 在版本控制节补「版本号遵循 SemVer」，与索引页一致。
- [🟡中等] AI跨文件复制 | /208-210 | 统一联系方式收尾块
- After(建议): 抽公共组件。
- [🟢轻微] 重复冗余 | /29 vs development/index.mdx:42 | 「为复杂逻辑添加注释」两页重复
- After(建议): 索引页删除，保留本页。
落地改写前需人工确认，避免建议本身出错：
opensource@、brand@、security@、dev@、management@、privacy@等邮箱前缀是否均已开通。- 「独立审查小组 / 独立调查小组」的真实组成规则与最终裁决权归属（conduct、management 多页矛盾）。
- 「社区负责人（Community Lead）」「运营组（社区运营 / 内容运营）」「管理委员会」是否真实设岗（organization 角色断层）。
- 内部项目是否真以 AGPL-3.0 文本授权，还是仅沿用其条款精神（open-source/internal-license）。
- 是否存在未成年用户实际场景及监护人验证机制（privacy-policy 儿童隐私）。
- 紧急决策 / 申诉的具体时限数值（decision-making、obligations）。
- 技术栈事实：
go是否归为包管理（应为 Go Modules）、是否实际使用 Vercel 部署（应为仅 Cloudflare Pages）、构建工具实际清单（tech-standards）。 - 首页「以大多数用户为中心」「小型团队」「聚焦方向」等表述是否与组织实际一致。
- 单源化（优先，消除大部分 🟡 复制）：为「价值观 / 角色定义 / 监督机制 / 代理重选规则 / 独立小组定义 / 安全措施 / 行为准则」各确立唯一权威页，其余改引用。可一次性消除约 30+ 处跨文件复制。
- 组件化联系方式块：将统一收尾块抽为 Starlight 组件或 MDX include，全站传不同邮箱前缀，消除 ~15 处重复与维护漂移。
- 破除排比模板感：powers / decision-making / obligations / culture / open-source / brand 等页的「恰好 N 条、句式平行」结构改为叙述式或表格，空泛条目补可执行判定。
- 制度章节去公关腔：security / conduct / management 开头与条文改用「须 / 不得 / 负责」强制句式与可核查表述。
- 修复 🔴 严重项：decision-making 重大决策两节矛盾、conduct 解释权 vs 最终裁决主体冲突、brand 两页复制、首页照搬总纲、development/index 与子页同质、tech-standards 事实标签错误——须先核实第三章清单再改。
- 索引页重构：organization/index、development/index 由「子页压缩复述」改为「概述 + 链接 + 一句定位」。
以上为审查结论。是否进入落地改写阶段，请确认；改写将另按单源化与组件化方案逐页执行。