Carbon 语言目标演进：为何"惯用代码性能"与"面向开发者文档"必须成为一等目标

本文聚焦 Carbon Language 早期治理文档体系中的一份关键提案：proposals/p000120-add-idiomatic-code-performance-and-developer-facing-docs-to-goals.md。该提案回答了"惯用代码是否默认就该快"与"开发者文档是否是项目一等优先级"两个问题，并最终把答案固化进 docs/project/goals.md 这一目标主文档。读完本文，你将理解 Carbon 如何把"默认性能"与"易上手的开发者文档"纳入目标体系，以及该决策与 Goals、Principles、Success criteria、Roadmap 之间的层级关系。

一、提案背景：一份目标文档的两个缺口

Carbon 项目的目标体系起源于提案 p000051-goals.md，其产物是 docs/project/goals.md。这份文档定义了 Carbon 的项目目标（社区与文化、语言工具与生态）与语言目标（性能关键软件、软件与语言演进、易读易写、实用安全、快速可扩展开发、现代平台、与 C++ 互操作），并明确语言目标之间存在排序：发生权衡时按该顺序优先。

目标文档批准之后，社区在评审与迭代中发现了两个缺口：

1. 惯用代码的性能问题。Issue #106 提出了一个小而关键的问题：是否应该在目标中说点什么，比如"合理快速 by default"或"偏好可被编译为高效代码的构造"？提案作者认为"这显然是我们对性能想要的，应当明确写下来"。
2. 面向开发者文档的缺失。在考虑 PR #80 的论证时，作者注意到：整个目标体系中没有一条显式目标要求"提供面向开发者的文档"。虽然可以从现有生态相关文字中推断出来，但明确写入目标会更好。

这两个缺口恰好对应本文档（proposals/p000120-add-idiomatic-code-performance-and-developer-facing-docs-to-goals.md）的核心动机：把"惯用代码性能"与"开发者文档"从隐含假设升级为显式目标。

二、提案内容：补上两段关键目标文字

提案的正文非常克制：在目标文档中新增两段文字，分别回应性能与文档问题，同时做若干小的修正。这两段文字最终都落在 docs/project/goals.md 中，可以从当前仓库直接验证。

2.1 "惯用代码应该快"：落入 Performance-critical software 目标

在 docs/project/goals.md 的 "Performance-critical software" 一节下，目标文档用三个并列的小目标拆解性能问题：

• 为开发者提供对性能每个方面的控制：面对性能问题时，开发者应始终在 Carbon 内拥有解决工具；在最受限的场景中，必须能"打开引擎盖"（open up the hood）而无须切换到另一门语言。
• 惯用代码应该快（Idiomatic code should be fast）：开发者不应经常被迫在性能与可读性之间做选择。尽管性能调优在少数情况下可能需要复杂或令人惊讶的代码，Carbon 的设计应确保常规、惯用的代码通常都能产生高性能。
• 代码性能应可预测：读者和作者应能容易地理解代码的预期性能；性能无论好坏，都不应让开发者感到意外。

其中"惯用代码应该快"正是本次提案补入的内容。它与"打开引擎盖"形成互补：后者回答"性能出问题时有没有出路"，前者回答"不出问题时，默认代码是否已经够快"。

2.2 "平易近人、面向开发者的文档"：落入 Language tools and ecosystem

在 docs/project/goals.md 的 "Language tools and ecosystem" 一节下，新增了一条 "Approachable, developer-facing documentation"：

平易近人、面向开发者的文档。 开发者不应被要求通读规范来上手 Carbon。项目将提供用户指南（user guides）与其他文档，让学习如何使用 Carbon 变得容易。

这一条与同节已有的"参考实现""正式规范"目标并置，共同勾勒出 Carbon 生态的完整图景：参考实现提供一致体验，正式规范精确描述行为，而开发者文档负责"低门槛上手"。

三、论证：为什么这两个缺口值得写入 Goals

提案的 Justification 部分给出了两条核心论证逻辑，理解它们有助于把握目标文档的写作哲学。

3.1 性能论证："允许惯用代码可预测地慢"不是本意

在 "Performance-critical software" 目标中，原文本确立了"用 Carbon 写出高性能代码是可能的"。但提案指出，若严格按字面理解，这句话可能被读成："只要开发者有工具'打开引擎盖'，惯用代码就算可预测地慢也没关系。"

这并非本意。因此需要显式补上惯用代码性能的承诺——它提供了一种保证：无论开发者是否做性能调优，Carbon 都会持续一致地优先考虑性能。这一定位与 README.md 中"Performance matching C++ using LLVM"的定位一致，也与性能目标在语言目标优先级列表中位居第一的排序相呼应。

3.2 文档论证：规范不等于上手指南

"Language tools and ecosystem" 一节已明确包含正式规范（specification）与工具链，但规范面向的是精确性，不是学习路径。开发者文档属于生态的一部分，也支撑新 Carbon 开发者的"爬坡训练"（ramp-up training）。把这类文档列为显式项目优先级，意味着它在权衡中不会被默认牺牲。在仓库中可以看到这条目标的落地：docs/ 目录下既有面向规范与设计的 docs/spec 与 docs/design，也有面向新手的 docs/guides（含术语表 docs/guides/glossary.md 等），正是"用户指南与规范并行"的具体形态。

3.3 其他改动

提案还顺带对目标文本做了一些小的渐进式修正（incremental improvements），作者将其纳入同一变更，主要是为了让评审视角保持一致。

四、备选方案：为什么不用 Principle 来承载性能承诺

提案的 Alternatives considered 部分专门讨论了另一条路径：把"惯用代码性能"做成一条 principle（原则）而非写进 goals（目标）。

从 docs/project/principles/README.md 可以看到项目的层级设计：

Principles 用于收集目标中那些适用范围广、影响大、有时不那么显而易见的推论。原则澄清目标，但不取代目标与优先级。

也就是说，principle 适合承载"基于目标的非显然推论"。而提案作者的判断是：

• "惯用代码应该快"陈述成本极低、一句话就能说清；
• 它不值得单独拆成一篇文章/一份原则文档；
• 从成本收益看，留在 goals 文档里更划算。

这一取舍体现了 Carbon 治理文档的一条方法论：目标文档负责"什么重要"，原则文档负责"如何据此决策"，二者各有分工，避免内容碎片化。

五、决策的落地：目标如何驱动后续治理

提案的 Rationale 部分指出，该变更修补了原提案的若干粗糙边缘与缺失碎片，是"launch and iterate"流程的预期组成部分——用户可见文档与默认性能，应当是 Carbon 的一等优先级。

在今天的仓库中，这一决策通过目标体系持续发挥影响：

• 目标（Goals）：docs/project/goals.md 中的两条新增文字即本提案的直接产物，其中语言目标仍保持"按顺序权衡"的排序结构。
• 原则（Principles）：docs/project/principles/README.md 在目标之下收集推论，例如 success_criteria.md 提供"具体、可衡量的关键结果"，并说明"缺失它们将被视为重大问题，提案若削弱它们将受到额外审查"。
• 路线图（Roadmap）：docs/project/roadmap_process.md 明确将 goals.md、success_criteria.md 等作为路线图过程的输入，形成"目标 → 原则/成功标准 → 路线图与提案"的决策链条。

换言之，本提案的价值不在于文字本身，而在于把两个容易在权衡中被牺牲的诉求——默认性能与开发者上手体验——提升到了"任何提案都需要为之辩护"的层级。

六、总结

proposals/p000120-add-idiomatic-code-performance-and-developer-facing-docs-to-goals.md 是一份小而关键的治理提案，它完成了三件事：

1. 把"惯用代码应该快"确立为 Performance-critical software 目标的组成部分，堵住了"只要能手写优化，默认慢也可以"的解读空间；
2. 把"平易近人、面向开发者的文档"显式写入 Language tools and ecosystem 目标，使文档与规范、参考实现并列为一等生态要素；
3. 论证了这些内容应留在 Goals 而非拆成 Principle，保持了治理文档的简洁与一致。

对于研究 Carbon 治理体系的读者，这份提案是理解"一个诉求如何被正式化进目标文档"的最小可读样本；而对于关注 Carbon 语言本身的读者，docs/project/goals.md 中的这两段文字，则是观察语言优先级演进的直接窗口。