28 天完成 Sora 安卓版：4 人团队如何用 Codex 写出 85% 代码

【摘要】4 人小队配合 Codex，在 28 天内完成 Sora 安卓版开发，85% 代码由 AI 生成，人负责架构和决策，展示新一代工程协作范式。

引言

Sora 安卓版的开发过程，可以看作一次高度压缩的工程实战。团队只有 4 名工程师，从开工到正式上线只有 28 天，却交付了一款 全球可用、稳定率 99.9% 的复杂应用。更关键的一点是，约 85% 的代码由 Codex 自动生成，人类工程师把主要精力放在架构、体验和质量把关上。

这不是简单的效率故事，而是一次完整的软件工程分工重排。过去由人类开发者包办的很多环节，被交给了具备编程能力的大模型，人类开始退到更高一层的位置，做出系统性设计和产品判断。Codex 并没有“接管开发”，它更像一位刚入职但学习速度极快的高级工程师，需要有人给清晰目标、完整规范和持续反馈，才能持续输出可靠的代码。

围绕 Sora 安卓版这次实践，可以比较清晰地看到一种可复制的新模式：强工程师 + 强 AI 编码工具 + 结构化工程规范。这种模式不仅压缩了开发周期，也改变了团队角色分工，对普通技术团队具有很强的参考价值。

● 一、项目全貌与关键数据

1.1 背景与动机

Sora iOS 版在上线后出现使用量快速增长，大量用户开始通过移动端生成视频。很快，安卓用户对等价体验的需求被集中放大，安卓版本被提上高优先级日程。此时内部只有一个早期的安卓原型，距离可以面向公众发布的正式版本还差多个迭代阶段。

常规做法是拉一支十几人甚至数十人的移动端团队，按季度规划来推进。面对有限的时间窗口和高协同成本，团队选择了另一条路，把项目交给一支 小而精 的核心小队，再利用 Codex 作为主力编码工具，以更高的决策和执行密度完成安卓端的交付。

1.2 时间线与团队规模

整个项目的时间线非常清晰，节奏紧凑但有条理。

• 启动时间设定在 10 月 8 日，团队在此之前已经有一个可跑的安卓原型，可以展示基础功能。原型只覆盖关键路径，距离生产可用仍有较大差距。

• 正式开发从 10 月 8 日开始，持续到 11 月 5 日完成首发版本，对外推送更新。整体用时 28 天，包含开发、联调、测试和多设备适配。

• 团队规模始终保持在 4 名工程师，没有再持续扩容。这样可以控制沟通半径，让每个人都能清楚整个系统结构，并保持与 Codex 的高频交互。

这种配置在传统认知里更像一个“验证性项目”，而不是“面向全球用户的正式产品”。从 Sora 安卓版的复杂度和使用量来看，这个结果本身已经说明了协作模式发生了明显变化。

1.3 核心指标与项目画像

从一些关键数字，可以更直观地理解这个项目的轮廓。

从这些指标可以看出，这次实践既是一次工程效率实验，也是一次新型团队协作模式验证。核心并不在于“AI 写了多少行代码”，而在于人和 AI 在什么边界上各自负责什么工作，以及用什么方式把这两类工作稳定地拼在一起。

● 二、Codex 在开发流程中的实际用法

2.1 代码生成与跨端迁移

在这个项目中，Codex 主要承担了大部分编码工作。工程师以需求说明、接口文档、架构约束和交互描述的形式给出输入，Codex 负责生成具体实现。它在几个方面的作用非常突出。

第一点是 业务代码生成。只要工程师在对话里说明某个功能页面的状态、交互流程和接口返回结构，Codex 就能一次性写出相对完整的 Android 侧实现，包括 Activity 或 Compose UI、ViewModel、网络层调用以及数据模型转换。这样工程师不再需要从零搭建每个功能模块，而是更多在已有代码上做调整和优化。

第二点是 跨语言和跨框架迁移。由于 Sora 已经有成熟的 iOS 版本，很多业务逻辑、状态机设计和交互节奏在 Swift 代码中已经成熟总结。Codex 同时熟悉 Swift、Kotlin 和常见移动端框架，可以在阅读 iOS 实现后，生成对应的 Android 实现。这种能力让“照着 iOS 写安卓”的工作不再完全依赖人力重复劳动，迁移成本大幅下降。

第三点是对 样板代码 的自动处理。网络请求封装、错误处理模式、常用 UI 组件封装、数据类与序列化配置，这些内容都具有高度重复性。Codex 在这类场景下可以一次性生成较为完整的骨架，工程师再结合实际项目习惯进行少量修改，在保证统一风格的同时，节省了大量简单重复工作。

从效率数据来看，这类工具可以让开发者的编码时间缩短三成甚至更多。对 Sora 这样的复杂应用，这种比例在绝对工作量上意义非常大。

2.2 单元测试与质量守护

在传统项目中，单元测试经常在时间压力下被压缩或弱化。Sora 安卓版的开发过程反而呈现出另一种情况，Codex 会积极帮助生成测试用例，在质量上形成一层基础保护网。

工程师在完成模块设计后，将核心业务路径拆解成一系列可测试的函数或组件交给 Codex，要求其生成对应的单元测试。Codex 会根据代码结构和常见测试实践，输出大量测试用例。单个用例的深度可能不算极致，但整体覆盖范围很广。

这带来两个直接收益。第一是 回归缺陷明显减少。每次修改逻辑时，只要更新相关测试，再让 Codex 协助调整测试代码，回归问题能在 CI 流水线中尽早暴露。第二是 测试文化更容易落地。当写测试不再是一件繁琐的事情，团队心理上的阻力会小很多，大家更容易在日常迭代中维持基本的测试密度。

在这种模式下，测试代码不再是额外负担，而是编码过程自然的一部分。工程师把重点放在“需要验证什么行为”和“边界情况该如何定义”上，让 Codex 去完成具体断言和用例结构的拼装。

2.3 CI 故障分析与修复辅助

持续集成流水线是这个项目中另一个强依赖的基础设施。Sora 安卓版在 CI 层面并没有采用过于神秘的新技术，真正的变化在于 如何使用 Codex 来解读和修复 CI 失败。

常见流程是这样的。工程师提交代码后触发 CI，如果编译失败或测试失败，就会产生一段较长的日志。以前需要开发者自己花时间在日志里查栈、看依赖、猜原因，现在可以直接把核心日志输出片段交给 Codex，由它先行分析和归纳。

Codex 会根据日志提示、项目结构和已有代码生成一段修复建议，往往包含具体的补丁代码、可能的根因说明以及影响范围。工程师再根据自身对架构和业务的理解，对这些补丁进行筛选和调整，然后合入主干。

这种方式有两个好处。一个是减少了工程师在枯燥日志上的时间浪费，把精力集中在架构合理性和业务正确性上。另一个是让 CI 的反馈回路更紧凑，减少小问题长时间挂在流水线上的情况。

整体看，在 Sora 安卓版项目中，Codex 不只是一个“代码生成器”，更是融入了整个开发、测试、集成和修复周期，形成一个连续的技术支撑链条。

● 三、Codex 的能力边界与典型问题

3.1 架构推断的天然限制

Codex 在执行工程师给出的明确指令方面表现出高水准，但在“自己补全未说清楚的架构设定”这件事上存在天然限制。工程项目中的很多关键决策依赖隐性知识，单靠代码上下文很难看出。

例如团队偏好的 架构模式和具体落地方式，虽然很多 Android 项目都使用 MVVM 或 Clean Architecture，但不同团队对 ViewModel 的职责、Repository 的边界、Use Case 的拆分标准都有差异。如果没有在规范里写清楚，Codex 会按照自己从公开代码中学到的常见习惯来组织结构，这样与团队已有实践可能出现偏差。

又比如 错误处理与重试策略，有的团队偏好在数据层集中处理，有的则希望在业务层具备更细腻的控制逻辑。如果工程师没有在一开始就用自然语言描述清楚哪些错误应该吞掉，哪些需要抛出，Codex 的默认行为可能与产品诉求不符。长期下来，系统的行为会变得难以预测。

这类限制导致一个现实结论。Codex 不适合作为项目的“自动架构师”，更适合作为 在既定架构下高效填充实现细节的执行者。真正决定系统形态和模块边界的工作，仍然需要有经验的工程师来负责。

3.2 产品体验与真实世界反馈缺口

另一个关键边界在 用户体验和真实世界环境感知。移动应用能否好用，除了逻辑正确，更重要的是手感、反馈节奏和错误提示方式。这些都很难通过静态代码完全判断。

比如一个复杂的生成流程，在高端机上几乎无感，但在中低端设备上可能出现加载卡顿。某个页面的滑动手势，在模拟器和真机上的表现有差异。动画节奏、过渡效果和盲人模式支持这类要求，都需要工程师亲自跑一轮，再根据体验写出清晰描述，交给 Codex 做后续修改。

Codex 无法直接感知这些现象，它只能根据工程师的文字反馈来调整实现。这意味着，团队需要设计一套稳定的体验反馈循环，确保每一轮改动都基于真实使用观察，而不是仅靠“看起来应该没问题”的推测。

在 Sora 安卓版项目中，人类工程师在这一层承担了大量工作。他们需要切到各种机型上体验关键路径，记录下每一处卡顿、每一段多余等待和每一个令人困惑的交互，再整理成可执行的需求说明。Codex 在这种场景中负责完成技术实现，人类负责提出体验问题和判断完成标准。

3.3 上下文重置与“重新入职”问题

每次与 Codex 开启新会话时，如果没有良好上下文承接，就很容易出现“需要再解释一遍团队习惯和项目约束”的情况。这种体验类似不断给新加入的同事做入职培训，只是对象变成了模型。

工程师如果在不同问题上频繁新建对话，而不引导 Codex 阅读同一套规范文档，就会遇到风格不一致、架构理解不统一的情况。某一批代码按 A 风格组织，另一批按 B 风格实现，合并后审查和迁移成本都会增加。

解决办法也并不复杂，关键是 把隐性上下文显性化。项目需要一套可以让 Codex 随时重温的工程手册，里面写清楚架构边界、目录结构、命名习惯、日志标准、测试要求和性能目标。每次开始新任务前，先让 Codex 阅读相关文档，再进入具体需求描述，这样可以显著降低“重新入职”的开销。

3.4 “能跑就行”本能带来的架构隐患

从表现上看，Codex 在很多情况下会选择最直接的方式把功能做出来。这种倾向在短期内提升开发速度，但如果缺少约束，就会在中长期留下不少架构隐患。

典型问题之一是 层次混乱。例如在一个本来应该由 Repository 处理的数据拉取逻辑中，Codex 可能把网络调用直接写在 ViewModel 或 UI 层中。代码能够正确运行，但破坏了分层设计，也让后续测试和替换实现变得困难。

另一个问题是 组件过度拆分或过度堆叠。在试图追求“清晰结构”的过程中，如果没有限制，Codex 可能引入数量较多的中间层或辅助类。这些类在命名和职责上可能比较牵强，使得项目结构在视觉上看起来很规整，实际理解成本却更高。

下面用一个抽象示例描述这种差异。

在错误示例中，UI 层直接依赖远程接口，测试和替换都变得僵硬。正确示例通过 ViewModel 和 Repository 形成清晰抽象，职责更明确。这类模式需要在规范中提前说明，并在 code review 中长期坚持，否则 Codex 很容易选择“能跑就行”的路径。

Sora 安卓版项目通过大量规范文件和严格审查，把这些倾向限制在可控范围内，在享受高效编码的同时，没有完全牺牲长期可维护性。

● 四、AGENT.md：给机器看的工程手册

4.1 文档形态与作用

项目中一个非常重要的实践是大量使用 AGENT.md 这类文件。可以把它理解成专门写给 Codex 阅读的工程手册，又同时对人类工程师生效。

和传统的 README 不同，AGENT.md 更强调对 “如何写代码” 进行约束，而不是讲项目背景。它以自然语言列出清晰的规则，让 Codex 在生成代码前有一套可以遵循的硬约束，从而减少架构漂移和风格不一致。

常见内容包括项目的层次设计、推荐使用的库或框架、禁止直接调用的接口、错误处理策略、异步调度约定和测试编写要求。工程师在文档中尽量用朴素的描述方式，把这些看似零散的团队习惯整理成条目，让 Codex 能在有限的上下文内快速掌握。

4.2 关键约束项的设计

为了发挥 AGENT.md 的作用，文档本身需要结构清晰，覆盖几个关键维度。

• 目录与模块结构 应该在文档中明确列出。每个模块负责什么，依赖哪些其他模块，哪些依赖是禁止出现的，都需要清楚说明。这能防止 Codex 在生成代码时跨模块引用造成耦合。

• 分层与职责边界 需要有具体示例。比如 ViewModel 只能持有 UI 状态和调用 Use Case，不能直接访问网络；Repository 负责数据源切换，需要屏蔽底层细节；Use Case 处理业务流程，对错误进行分类和转换。通过文字配合少量伪代码说明，可以让 Codex 准确理解每一层的责任。

• 错误处理与日志规范 要求统一。团队可以在文档中给出几类标准错误，例如用户可见错误、可重试错误和系统级错误，并规定各自的处理方式和日志级别。Codex 在编码时就可以根据类别选择合适分支，避免出现大量不一致的错误弹窗或日志格式。

• 测试写法与覆盖目标 也需要提前写清楚。比如要求每个公共接口至少有正常流和异常流两个测试，要求关键业务路径必须在单元测试和集成测试中都出现。Codex 在生成测试时，就会采用一致风格，减少后期维护难度。

通过这些约束项，AGENT.md 不再是可有可无的说明文档，而成为驱动 AI 协作的核心工具。

4.3 接入日常开发流程的方式

AGENT.md 的价值只有在 持续使用 的前提下才能体现。Sora 安卓版项目的做法可以抽象为一个闭环流程。

这个闭环中，人类工程师先设计初始架构和规范，把能够写清楚的经验尽量写进 AGENT.md。随后 Codex 在每次任务前阅读这些规范，再按要求生成代码。工程师在 code review 和测试环节中，识别那些反复出现的模式问题，把修正经验再次写回文档，让下一轮生成时少踩同样的坑。

这样一来，AGENT.md 不再是一次性产物，而是随项目演进不断更新的“协作协议”。文档既教给新同事如何写代码，也规范 Codex 的输出行为，慢慢沉淀出一套稳定的工程风格。

在小规模团队中，这种方式尤其有效。由于参与人数不多，规范的演进比较集中，不容易出现多套标准并存的情况。AGENT.md 成为团队记忆的单一来源，人和 Codex 都以此为参考，整体一致性更容易保证。

● 五、人类工程师角色的重构

5.1 从写代码转向设计边界

在 Codex 承担大部分具体编码工作之后，人类工程师的角色从“敲代码的人”转向“设计系统边界的人”。工作重心不再是写完多少行代码，而是定义哪些模块、划分哪些接口以及明确哪些约束。

在 Sora 安卓版项目中，几名工程师需要在早期就把整体架构定型，包括数据流向、核心流程抽象、模块划分方式和长期可扩展点。他们会先手工搭出最初的骨架代码，用简洁实现把每一层、大致路径和依赖关系固定下来，再让 Codex 在这些骨架内填充详细逻辑。

这种方式下，系统架构不再被日常小改动慢慢侵蚀，因为每次新增功能和修改行为时，工程师都可以要求 Codex 按既定模式写代码，而不是临时在任意位置插入逻辑。架构演进仍然由人来掌握节奏，Codex 只是配合实施变化。

5.2 体验把控与性能调优

另一项关键责任是 产品体验和性能。移动端应用的成败，很多时候不取决于功能是否齐全，而取决于操作是否流畅、反馈是否清晰和异常场景处理是否友好。

Sora 安卓版中，工程师需要在多种机型、不同网络环境和各种使用场景下验证关键操作路径。他们会收集界面卡顿点、交互中断点和用户容易迷失的地方，然后整理成简洁任务，再交给 Codex 进行实现修改。

例如在一个视频生成流程中，如果发现用户在等待过程中没有足够反馈，工程师就会要求增加明确的进度提示和状态说明。Codex 会负责写具体 UI 更新逻辑和状态管理代码，工程师则用真机验证是否达到了预期效果。同时，针对较重操作的性能问题，工程师会基于性能分析工具的结果设计优化策略，再让 Codex 帮助落地具体代码。

在这种分工下，人类工程师把时间投入在观察、判断和决策上，而不是在每一处布局和样式上耗费大量精力。

5.3 质量守门与代码审查

尽管 Codex 能在大多数情况下产出可工作的代码，最终质量责任仍然在工程师手里。Sora 安卓版项目中，严格的 code review 是必不可少的一环。

工程师在审查时需要关注几个维度。第一是 架构一致性，检查新代码是否遵守模块边界，是否把逻辑写到了不该出现的层次。第二是 行为正确性，包括边界条件、异常处理和状态恢复。第三是 可维护性，代码是否易于阅读，命名是否清晰，是否引入了不必要的复杂抽象。

Codex 同样可以在审查过程中扮演辅助角色。比如工程师对某段逻辑存在疑虑时，可以要求 Codex 找出可能的边界情况，或者生成几组额外测试用例帮助验证。最终决定是否采纳某种实现方式，仍然由工程师基于全局理解来做判断。

质量守门的角色在这种模式下并没有减弱，反而需要更强的判断力和对系统整体的掌握。因为一旦放宽标准，Codex 很容易在无意识中引入大量欠考虑的实现，短期影响不明显，长期积累会变成债务。

5.4 小团队协作与沟通模式

四人小队配合 Codex 的做法，也改变了团队内部的协作模式。传统大团队需要复杂的任务切分、需求排期和跨组协调，这些过程本身就消耗大量管理成本。

在小队模式下，每个人都清楚整体架构和关键业务路径。任务分配更偏向按功能或子系统划分，每个负责人的上下游都很明确。Codex 作为统一的编码助手，被每个人以相似方式使用，从而在风格和模式上保持一致。

这种结构有几个优点。沟通的链路变短，减少了信息在多层转述中的损失。规范文档可以被少数人维护，避免长期分裂。对于需要快速试错和连续迭代的项目，这种紧凑协作方式能明显降低管理开销，把更多时间留给真正的技术和产品决策。

● 六、对普通开发团队的落地指南

6.1 起步方案：三步搭建协作环境

把 Sora 安卓版的经验直接照搬到任何团队不现实，但可以提炼出一套较为通用的起步路径。

第一步是 选定一个足够聚焦的试点项目。可以是现有应用中的一个新功能，也可以是一个独立的内部工具。项目需要边界清晰、业务范围有限，但不能过于简单，才能体现协作模式的价值。

第二步是 搭建和简化 CI 与测试环境。没有自动化测试和持续集成，很多潜在质量问题会被掩盖，AI 工具的修复能力也无从发挥。团队需要先把单元测试和基础流水线跑通，保证每次提交都能得到清晰反馈。

第三步是 撰写首版工程手册。可以从最简单的部分入手，比如目录结构、架构分层和命名规范，用自然语言写成 AGENT.md。随后在实际协作过程中，不断把暴露出来的共性问题写回文档，让规范逐步完善。

在这三个步骤完成之后，再大规模使用 Codex 辅助编码，整体体验会好得多。

6.2 规范设计与文档清单

为了让 Codex 高效工作，团队需要准备一套面向机器和人都可读的规范清单。

建议至少包含以下几个部分。

• 项目结构说明 包含模块划分、依赖方向和禁止交叉依赖的规则。每个模块用一两句话说明职责，再附上简单示意图。

• 架构风格指南 对 MVVM、MVI 或 Clean Architecture 的落地方式做出具体约定，明确每一层的输入输出以及禁止行为。可以附上小段伪代码作为参考，帮助 Codex 理解。

• 错误和日志策略 定义错误类别、提示文案风格和日志格式。要求对用户可见的错误提供统一处理方式，对潜在安全问题进行脱敏处理。Codex 在生成代码时就会统一采用这些模式。

• 异步与并发约束 规定在哪些场景可以使用协程、线程池或回调，定义主线程和后台线程的使用边界，避免随意切换线程造成难以排查的问题。

• 测试要求与模板 提供常见测试场景的模板，例如对网络请求、缓存策略和边界输入的测试模式。要求每个功能提交前都补齐对应测试，让 Codex 负责撰写具体断言。

这些内容写清楚之后，团队内外的工程师以及 Codex 都能有一套统一参考点，减少了“各写各的”的情况。

6.3 常见误区与应对策略

在实践过程中，很多团队会掉进几个相似的坑，可以从 Sora 安卓版的经验中提前规避。

第一种误区是试图让 Codex 自己设计复杂架构。这种做法往往会得到一个表面工整、实际却不符合团队需求的结构，后续重构成本会很高。更合理的做法是由架构师先搭好骨架，把关键抽象、接口和边界定义好，再让 Codex 在这些边界内填充实现。

第二种误区是认为 Codex 可以自动保证代码质量和风格。如果没有 AGENT.md 之类的统一规范，Codex 会在不同对话中采用不同的实现习惯，产生很多不一致的代码片段。对策是从一开始就把规范写清楚，并在每次对话前要求 Codex 阅读。

第三种误区是用 Codex 替代工程师在 体验和性能优化 上的投入。由于 Codex 无法体验真实设备与用户行为，如果团队在这方面投入不足，最终产品体验会明显打折扣。更合适的分工是让 Codex 负责技术实现和优化细节，人负责提出体验问题和判断优化是否有效。

第四种误区是忽视 code review 的必要性。即使 Codex 在多数场景下表现稳定，也无法保证每一次生成都符合业务意图。保持严格的代码审查流程，仍然是任何严肃项目的底线。

● 七、关于“程序员会不会被替代”的冷静判断

7.1 哪些工作会被大幅压缩

从 Sora 安卓版的实践可以看出，一部分工作在新模式下会被明显压缩。

重复性很强的 样板代码编写 是第一类。大量布局代码、请求封装和数据模型转换，都可以由 Codex 快速生成。第二类是 跨平台迁移中的机械劳动，例如把一套 iOS 实现翻译成 Android 代码。第三类是 基础单元测试编写，Codex 能根据函数签名和业务逻辑生成大量覆盖还算合理的测试用例。

这些工作并不会完全消失，只是由 Codex 代为完成的大部分，人类工程师更多承担定义输入和审查输出的角色。同样的产出，在人力投入上会显得更轻。

7.2 哪些能力会变得更稀缺

在这种协作模式下，一些能力的价值会被放大。

首先是 系统架构设计能力。如何在业务需求和技术实现之间找到合适抽象，如何定义清晰模块边界，如何在可维护性和性能之间做平衡，这些都需要有经验的工程师做决策。Codex 能够执行这些决策，却无法在复杂约束下自主做出合适选择。

其次是 对业务和用户的深度理解。只有真正理解用户目标、使用环境和痛点，才能设计出合理的流程和提示，才能在体验取舍上做出符合产品方向的决定。Codex 在获取这类信息时只能依赖工程师的描述，因此描述质量和判断能力非常关键。

第三是 清晰表达与抽象能力。工程师需要把复杂需求拆成 Codex 能理解和执行的指令，用自然语言写出准确边界和规则。这既考验技术深度，也考验沟通表达水平。会写规范、会拆需求、会讲清楚约束的人，会变得更加重要。

7.3 对个人成长路径的建议

面对这种变化，开发者需要调整对自身能力结构的规划。

可以有意识把精力从单纯刷语法、记 API 上转移到 结构化思考和架构实践 上，多参与系统设计评审，多分析大型项目代码结构。对业务和用户多花一些时间，练习如何把模糊需求整理成清晰的技术目标和约束，顺带提升自己在产品侧的敏感度。

在日常工作中，有意识练习 与 Codex 协作 的方式也很重要。比如在描述需求时力求准确和完整，在收到代码后进行系统化审查，再结合审查结果更新个人的规范库。这样一段时间后，会形成一套适合自己的协作节奏，既能保持节省下来的时间，又能持续提升产出质量。

从长远看，那些既懂工程技术、又能做架构决策、还能把需求讲清楚的人，会成为团队中最难替代的角色。

结论

Sora 安卓版项目用一组简单数字，展示了一种新的软件研发方式。4 名工程师，28 天周期，85% 代码由 Codex 生成，稳定率达到 99.9%，背后是人和工具清晰分工后的合力。

Codex 在代码生成、跨端迁移、单元测试和 CI 修复等方面承担了大量具体工作，让工程师从重复劳动中解放出来，把时间集中在架构、体验和质量把关上。与此同时，Codex 的局限也非常明确，无法自动设计合理架构，无法感知真实用户体验，也无法在缺乏规范的前提下保证长期可维护性。

通过引入 AGENT.md 等工程手册，团队把隐性的开发习惯转化为显性规则，让 Codex 在统一约束下写代码。小规模团队在这种模式中展现出高效优势，用更少的沟通成本维护一致性，用更紧凑的反馈循环改进产品。

对普通开发团队而言，这不是一条遥远的路线。选择合适的试点项目，搭建基础 CI 与测试环境，编写首版工程手册，再用 Codex 辅助编码和修复，完全有机会在几个月内习惯这种协作模式。重复性劳动会减少，架构与体验相关的工作会增多，工程师的价值重心也会随之上移。

从未来视角看，Sora 安卓版的开发不是一个偶然的成功案例，而是新型工程协作方式的一次完整演练。软件行业的分工结构正在发生缓慢但明确的变化，谁先适应，谁就能把这种变化转化为长期优势。

📢💻 【省心锐评】

把 AI 当高效执行者，把人放在架构和决策位置，再用规范把两者绑在一起，软件开发才会真正提速而不失控。