核心观点 - 代码仅占工程师创造价值的10%-20%，而80%-90%的价值在于结构化沟通[8] - 规约（Specification）比代码更重要，是承载意图和价值观的无损载体[18][24] - 未来工程师的核心竞争力将转向定义"做什么"和"为什么做"，而非"如何做"[3][12] 代码与沟通的价值 - 工程师的传统产出是代码，但代码只是意图的"有损投影"，无法完整传递原始设计思想[24] - 结构化沟通包括需求收集、目标定义、验证等环节，这些才是真正的价值瓶颈[10] - 未来最擅长沟通的人将成为最优秀的程序员，"如果你能沟通，你就能编程"[12][13] 规约的优势 - 规约是人类对齐工具，可用于讨论、辩论和版本控制，而prompt常被丢弃[18][19] - OpenAI的模型规约采用Markdown格式，实现跨部门协作（产品/法务/研究团队）[27] - 规约具备可组合性、可执行性、可测试性等特性，类似代码但面向意图而非语法[46] 行业实践案例 - GPT-4o的"马屁精问题"通过模型规约中的"不要谄媚"条款被快速识别和修复[31][32] - OpenAI采用"审议式对齐"技术，将规约转化为模型权重中的"肌肉记忆"[35][36] - 模型规约包含唯一ID和对应测试用例，形成闭环验证体系[29][30] 未来趋势 - 编程工具可能进化为"集成思想澄清器"(ITC)，专注于规约的模糊点识别[48] - 智能体对齐领域急需规约化，暴露产品细节思考的成熟度问题[48] - 规约创作者范围扩大，产品经理、立法者都可能成为新型"程序员"[26][40]

OpenAI推出Codex编码工具 - OpenAI正式推出AI编码工具Codex 目前向ChatGPT Plus用户开放 在需求高峰期间可能对Plus用户设置速率限制[1] - Codex可在任务执行过程中访问互联网 支持安装依赖项 运行测试 升级软件包等功能 该功能向ChatGPT Plus/Pro/Team用户开放 日常默认关闭[3] - Codex既可在ChatGPT网页浏览器中运行 也能通过Codex CLI在本地运行 支持交互式和非交互式两种模式[6] Codex CLI技术特性 - Codex CLI专为习惯使用终端的开发者设计 支持版本控制 理解并执行代码仓库 是"聊天驱动型开发工具"[6] - Codex CLI在GitHub开源 已获27.9k Star 当前代码占比最高的是Rust语言[7] - Codex CLI具有零配置启动 全自动审批机制 多模态交互等特性[10] Rust重写Codex CLI - OpenAI用Rust重写Codex CLI 目标是提升性能和安全性 避免对Node.js的依赖[3] - Rust重写带来四个关键改进：零依赖安装 沙箱化 性能优化 支持MCP协议[20] - 基于Rust的Codex CLI仍可通过JavaScript Python等语言扩展 目前并行开发TypeScript和Rust版本[17] Rust语言行业趋势 - Rust作为系统级语言比Node.js更高效 但开发难度更高[19] - 近期行业出现Rust重写浪潮 Vue.js创始人用Rust实现的Rolldown使生产构建时间减少3-16倍[21] - AI编码工具Zed用60万行Rust代码重构 声称成为"最快AI代码编辑器"[23] 团队背景 - Codex CLI项目维护者Fouad Matin加入OpenAI约一年 此前创立三家科技公司 并在Segment领导产品和工程开发[9] - Matin曾表示TypeScript是最适合UI的语言 但后来转向Rust重写以实现更高效率[12][14]

OpenAI 用 Rust 重写 Codex CLI - OpenAI 已用 Rust 语言重写其 AI 命令行编程工具 Codex CLI，目的是提升性能、安全性并避免对 Node.js 的依赖 [1] - Codex 是一款实验性编程代理工具，可在 ChatGPT 网页浏览器环境或本地通过 CLI 运行，支持交互式和非交互式模式 [1] - 2025 年 4 月 17 日 Codex CLI 在 GitHub 上开源，支持 macOS、Linux 和 Windows 系统 [1] - 原版本基于 TypeScript 和 Node.js，现已用 Rust 完成重写，但 TypeScript 版本仍会维护至 Rust 版本功能对等 [1] 选择 Rust 重写的原因 - 零依赖安装：原版本要求 Node.js 22 及以上，可能成为用户门槛 [2][4] - 沙盒化需求：macOS 使用 Apple Seatbelt，Linux 默认不启用沙盒，Rust 版本实现了 macOS 的 sandbox-exec 和 Linux 的 Landlock 沙盒机制 [4] - 性能优化：Rust 无垃圾回收机制，内存需求更低 [5] - 可复用现有 Rust 版 MCP 实现：Codex CLI 将同时具备 MCP 客户端和服务器功能 [5] - 截至 6 月 6 日，Rust 在项目中占比 46.7%，超过 TypeScript 的 44.7% [5] 行业对 Rust 的认可 - Vue 创作者尤雨溪推出基于 Rust 的 Rolldown-Vite，替代原 Rollup.js 打包工具 [6] - 采用 Rust 后生产构建时间缩短 3 到 16 倍，内存使用量最多减少 100 倍 [6]

技术选型与性能表现 - 公司原有技术栈以Ruby和Node.js为主，面临支持10万并发用户的实时服务需求时，Ruby被确认不适合该场景 [2][3] - 团队进行四种语言概念验证（Elixir、Rust、Ruby、Node.js），Rust版本由新手开发者编写但仍以显著性能优势胜出：速度最快、内存占用最少 [5][8] - Elixir在并发处理中表现优异，Node.js受限于单线程需分布式部署，Ruby性能垫底 [9][10] Rust的采纳与开发过程 - 团队最终选择Rust因其通用性潜力，包括网络编程、Web服务及多语言SDK开发等战略价值 [10] - 项目时间紧张，由单一开发者采用极简架构实现：基于WebSocket的API，内存哈希表存储，事件推送至Kafka [13][14] - 开发效率极高：2周完成第一版，1-2周部署，一个月内扩展功能，稳定运行零故障 [15][18] 性能优化与管理层冲突 - 服务在50万并发用户活动前招聘3名Rust开发者优化，最终单台64核机器支持100万并发（P99延迟10ms）、200万并发（P99延迟25ms） [19][21] - 管理层因服务过于稳定质疑团队价值，强制要求转用Ruby/Node.js，导致3名Rust开发者离职 [20][22] - 禁用Rust后尝试Node.js重写失败，因单线程无法处理高负载，最终依赖第三方服务仍性能不足 [24][25][26] 结果与行业启示 - 原Rust服务持续在生产环境稳定运行但无人维护，成为"被遗忘的英雄" [28][29] - 技术决策受管理层变动显著影响，人力资源倾向主流技术栈（如Node.js/Ruby）与性能需求存在矛盾 [22][23] - 极端稳定性反成团队风险，揭示技术成功与管理预期错位的悖论 [1][29]

项目背景与技术选型 - 一家快速成长的独角兽初创公司主力应用采用Ruby on Rails和Node.js，未使用高性能编译型语言如Rust或Go [3] - 公司计划开发实时在线状态服务，初期需支撑10万并发用户，团队认为Ruby不适合此场景 [3] - 技术选型阶段，团队用Elixir、Rust、Ruby和Node.js编写原型进行性能测试，Rust因灵活性和性能脱颖而出 [4][6][7] Rust项目开发与性能表现 - Rust版本在基准测试中速度最快、内存占用最低，Elixir次之，Node.js受限于单线程，Ruby最慢 [10] - MVP版本仅用两周开发完成，两周部署上线，采用内存哈希表和Kafka事件推送的极简设计 [8][9] - 服务稳定支撑10万并发用户，后续扩展功能也未出现故障 [11] - 优化后性能显著提升：支持100万并发（p99延迟10ms）和200万并发（p99延迟25ms） [12] 管理决策与Rust团队解散 - 公司战略调整导致实时功能搁置，Rust团队解散，服务转入低维护状态 [12] - 新管理层认为Rust工程师"冗余"，要求其转岗至Ruby/Node.js或离职，3名Rust开发者全部离开 [14][15] - 决策层未采纳推广Rust的建议，尽管已有成熟服务、工程师和多个适用业务场景 [15] 技术重写与后续影响 - 管理层强制用Node.js重写Rust服务，首次尝试因架构复杂性失败，需依赖第三方平台Ably但性能不达标 [16] - 最终Rust服务虽仍在运行，但因缺乏维护团队，扩展需求被放弃或采用次优方案 [17] - 开发者社区反馈此类事件普遍存在，管理层常因不理解技术价值而抵触非主流技术 [18] 行业现象与开发者观点 - 类似案例常见：技术成功反导致团队被裁，因"无维护需求"难以向管理层证明价值 [17][18] - 企业扩张中管理更替易破坏技术创新，决策者倾向选择主流技术而非最优方案 [18] - Rust等高性能语言面临推广困境，尤其在非技术驱动型组织中 [15][18]

Rust重写案例的核心观点 - 公司用Rust重写高流量服务后性能显著提升，但最终因组织文化冲突被禁用 [1][4][28] - Rust解决了内存泄漏、竞态条件等核心问题，运行速度和扩展能力远超原有技术栈 [7] - 技术优势暴露了组织低效问题，导致管理层恐慌性禁用 [8][22][26] Rust的技术优势 - **性能突破**：重写后服务运行速度"快得惊人"，扩展能力优秀到让其他服务相形见绌 [7] - **开发效率**：3个月完成重写，新功能开发速度超出项目管理能力，新人上手仅需数周 [10] - **人才吸引**：Rust岗位收到数百份优质简历，候选人普遍具备大型开源项目经验 [12][13][14] - **工具链碾压**：Cargo和Clippy工具链的完善度使内部工具链显得原始落后 [15] 组织文化冲突 - **效率反噬**：开发速度飙升导致产品经理跟不上需求更新节奏，打破原有交付节奏 [10][18] - **能力暴露**：Rust的清晰架构使业务逻辑透明化，消除了交付缓慢的借口 [18] - **舒适区威胁**：技术债务积累和技术平庸现状被直接暴露，引发管理层不安 [20][22] 决策与后果 - **禁用过程**：CTO在零争议sprint会后紧急评审，最终以"显得太优秀"为由禁用Rust [19][21] - **技术倒退**：90%服务换回Go语言，主动选择"够慢"和"模糊"的技术特性 [23] - **持续影响**：团队每日怀念Rust的精准性，尤其在系统稳定性需求时感到后悔 [24][25] 行业启示 - **技术政治化**：技术选型本质是政治选择，高效工具在低效组织中可能被排斥 [22] - **变革阻力**：Rust的成功重写揭示了组织深层次问题，但公司选择维持现状 [26][27] - **讽刺现象**：网友评论指出该案例反映开发者对技术变革的集体不安全感 [30][31]

技术选型与项目背景 - 公司是一家疫情期间快速成长的独角兽初创公司，主力应用采用Ruby on Rails编写，视频处理工具使用Node.js实现，初期未采用高性能编译型语言如Rust或Go [2] - 公司计划开发实时服务以显示用户在线状态和操作行为，初期需支撑10万并发用户，团队普遍认为Ruby不适合实现此类系统 [2] - 技术选型阶段团队倾向Rust，但管理层要求进行多语言原型对比测试，最终测试语言包括Elixir、Rust、Ruby和Node.js [3] Rust技术表现 - 基准测试结果显示Rust版本速度最快、内存占用最低，Elixir次之，Node.js受限于单线程运行时，Ruby表现最慢 [3] - Rust原型虽存在小bug（高负载下阻塞运行时几秒），但对熟悉Rust的开发者来说易于修复 [3] - 团队综合考虑性能、易用性和公司适配性后最终选择Rust实现实时服务，原本偏好Elixir的开发者实际使用后也投票支持Rust [4] - Rust服务MVP版本仅用两周完成，再花两周部署上线，稳定支撑10万并发用户无压力，后续功能扩展也未出现故障 [5] 项目发展与团队变动 - 公司战略调整导致实时功能被搁置，Rust服务转入维护模式，原开发团队解散 [6] - 公司筹备大型活动时预计需支撑50万并发用户，管理层招聘3名Rust工程师优化服务，调整系统配置后性能显著提升：支持100万并发（p99延迟10ms）和200万并发（p99延迟25ms） [6] - 服务过于稳定导致Rust工程师无事可做，新管理层上任后认为团队冗余，强制要求Rust工程师转岗或离职 [7][8] - 3名Rust开发者全部离职，公司放弃推广Rust的宝贵机会，尽管存在多个业务场景亟需高性能组件 [8] 技术重写与行业反响 - 管理层决定将Rust服务重写为Node.js版本以便现有团队维护，但首次重写尝试失败 [9] - Node.js受限于单线程运行时，需重构架构（多进程、多节点、队列或数据库中转）才能支撑百万连接，实现复杂度远高于Rust方案 [9][10] - 目前Rust服务仍在运行但缺乏维护团队，扩展需求被放弃或改用次优方案替代 [10] - 开发者社区普遍反映类似情况在各公司常见，新管理层常因不理解技术价值而做出破坏创新能力的决策 [10]