Tubi Meetup：怎样把 AI 变成一支工程团队

如果代码的生成成本继续下降，工程师最值钱的能力还会是写代码吗？如果一个人可以同时调度多个 Agent，团队会变小，还是会承担更大的系统？当实现速度不再是瓶颈，我们又该怎样规划自己的下一段职业生涯？

过去两年，我们谈论 AI 编程时，常常把注意力放在一个很窄的问题上：怎样写出更好的 Prompt，怎样让 ChatGPT、Claude Code、Codex 或 Cursor 更快地产生代码。但当 AI 真正进入一个持续数月、跨越多个模块、最终必须交付的项目后，决定成败的往往不是某一次对话有多精彩，而是项目是否拥有一套稳定的工程系统。

这也是我准备在本周 Tubi Meetup 分享的主题：把 AI 变成工程团队。

这场讲座不会演示“输入一句话，生成一个应用”的魔术。它会从三个真实而且差异很大的工程案例出发：一个轻量的 Rust AWS 本地模拟器、一套从球鞋上的传感器延伸到云端机器学习的可穿戴设备，以及若干本 400—600 页、能够自动构建和发布的中文技术书。三个案例分别属于纯软件、软硬件和知识内容世界，却逐渐指向同一个结论：

AI 原生工程不是 Prompt Engineering，而是围绕 AI 构建可执行的上下文、任务分解、反馈验证和交付系统。

写得更快，不等于交付得更快

传统工程流程通常被描述为理解需求、设计、编码、调试和测试。AI 大幅压缩了其中的实现成本，但它没有自动消除架构取舍、质量责任和事实验证。相反，当代码和文字能够以过去数倍甚至数十倍的速度产生时，模糊的需求、不稳定的接口和缺失的测试也会以同样的速度被放大。

因此，工程师的工作正在发生迁移：从亲手完成每一个实现细节，转向定义问题、写清约束、设计验证方法、分解和调度任务、审查 AI 产物，并处理那些无法被模板覆盖的例外与未知。

我把 AI 工程产能概括为一个乘法公式：

模型能力 × 上下文质量 × 任务分解 × 反馈速度 × 验证强度 × 人的判断。

它之所以是乘法，是因为任何一项接近零，整个系统都可能失效。再强的模型，如果不知道项目的长期规则，也只能反复猜测；再完整的 Spec，如果没有快速测试和外部反馈，也无法阻止一个“看起来合理”的错误逐渐扩散。

构建协议型软件系统

第一个案例 Rustack，是一个参考 localstack，使用 Rust 构建的轻量 AWS 本地模拟器。目前项目覆盖 18 个服务、779 个路由操作，启动时间不到一秒，Docker 镜像约 8 MB。

它面对的难题并不是写出几个 CRUD Handler，而是协议广度和兼容性。AWS SDK 关心请求签名、HTTP 路由、XML 或 JSON 序列化、错误模型以及大量细微的行为语义。一个接口“能够返回结果”，不代表它与真实客户端兼容。

Rustack 没有从铺满所有服务开始，而是先选择 S3 作为纵向切片：客户端请求经过签名校验、协议解析、业务逻辑和存储，最后产生 SDK 能够理解的响应。S3 足够复杂，会暴露 XML、SigV4、流式数据、对象版本和 Multipart 等问题；同时它拥有成熟的 SDK 和第三方兼容性测试，可以为 AI 提供机器可读的失败信号。

这个过程逐渐形成三层项目上下文。AGENTS.md 保存长期不变的工程规则，例如错误处理、并发模型、质量门禁和“不能留下 TODO”；Skills 保存可重复执行的工作流程；Specs 则约束当前功能的数据模型、组件关系、边界条件和退出标准。Prompt 是一次性的，而这些上下文可以版本化、Review，并随着项目一起演进。

更重要的是，外部测试会成为 AI 最好的教师。DynamoDB 的实现最初可能拥有“看起来正确”的 CRUD，但 Alternator 测试会进一步揭示表达式优先级、精确数值、Nested Path、ReturnValues、分页限制和 Validation 顺序。兼容率从约 40% 提升到 80% 以上，依靠的不是让 Agent 玩俄罗斯轮盘赌，而是把每个失败转化成可复现的语义差距、回归测试和 Spec 修正。

和 AI 一起打造软硬件全栈系统

第二个案例进入软硬件系统：在球鞋上安装传感器，采集足球运动中的加速度、转向、跑动和触球相关数据，通过手机或场边设备接收，再由云端完成处理和个性化分析。

“做一个足球传感器”并不是可执行的需求。真正能够驱动工程工作的，是重量、体积、续航、采样频率、传输延迟、通信距离、并发设备数、防水抗冲击和数据完整性等约束。

AI 在项目早期非常适合帮助软件工程师快速建立领域地图：从用户目标推导物理量，从物理量推导传感器、采样和计算，再延伸到通信、移动端、云端和机器学习。但 MCU（微控制器）、IMU（惯性测量单元）、GNSS（全球卫星导航系统）、BLE（低功耗蓝牙） 和电源管理方案都只能被视为候选假设。最终答案必须回到 Datasheet、Reference Design、开发板、电流分析仪、射频测试和真实运动数据。

这类项目必须同时设计硬件、固件、移动端、云端控制平面和数据管线。最有效的并行方式，不是等待 PCB 完成后再写 App，而是先稳定数据契约：设备 ID、Session、序列号、时间戳、采样率、传感器值、电池、固件版本和质量标志如何表达；丢包怎样发现；两只鞋和手机怎样进行时间对齐；协议如何向前演进。

在硬件到手之前，还可以用软件生成正常、丢包、乱序、时钟漂移和多人并发的模拟数据流。Rust 解析核心、iOS Session、云端入口和可视化可以先围绕这个“数字替身”运行起来。等真实设备接入时，面对的就不再是一个完全未知的系统边界。

然而，这个案例最重要的提醒仍然是：AI 的输出只是可验证的工程假设。平均功耗不能通过简单相加得到，BLE 标称距离不等于鞋内和人体遮挡下的现场距离，IMU 看起来靠谱的数据也可能包含偏置、温漂和时钟漂移。软件依靠测试，硬件最终依靠测量。

构建长期一致的知识系统

第三个案例是使用 AI 写一本 400—500 页的技术书。大家或多或少已经适应用 AI 写文档，博客，邮件等一次性的长内容。但如何构建一本书呢？它的难点不在于生成一段流畅文字，而在于几十万字如何保持事实、结构、术语和文风的一致性。

写书和软件工程有许多对应关系：读者契约类似 PRD，全书主线类似系统架构，术语与概念契约类似 API，知识脉络类似依赖图，事实核查和文风检查类似测试与 Lint，而 Typst/PDF 构建和 GitHub Release 则对应 Build 与 Release。

Agent 不需要在上下文里“记住整本书”。真正重要的约束可以进入仓库：每本书拥有自己的写作契约、全书计划、章节计划、研究材料、Review 记录、插图和构建输出。写作契约明确目标读者、叙事立场、公式和类比的使用方式，也明确哪些表达属于 AI 腔、翻译腔或讲义腔。

一章内容也不是一个 Prompt 直接完成的。更可靠的流程是：全书规划、章节规划、研究问题、资料汇编、初稿、技术审查、结构审查、文风审查、事实核查、图表制作、排版渲染和最终人工审校。研究与写作分离，可以降低“合理但不存在”的事实混入正文；独立审查则帮助发现每一章单看都不错、合起来却没有主线的问题。

实践中的成本也值得诚实呈现：一本 400—600 页的书，Agent 工作至少约 25 小时，可能消耗 40%—50% 的 Codex Pro 周额度，人工仍然需要约 5—10 小时进行粗审、校对和工作流优化。AI 没有把出版变成一键生成，它只是把数月的重复劳动压缩成几十小时的 Agent 执行，并把人的注意力移动到主线、取舍、事实、文风和最终责任上。

三个项目背后的共同方法

Rustack 的最终验证者是测试、兼容性套件和 Benchmark；可穿戴设备的最终验证者是仪器、实物和现场数据；技术书的最终验证者是来源、审稿和读者理解。验证方法不同，工程循环却高度一致：

Intent → Constraints → Specs → Task Decomposition → Agent Execution → Verification → Independent Review → Artifact & Memory。

每一次失败都不应该只在当前对话里被临时修复。它应该沉淀为新的测试、Spec、Skill 或工程规则，让下一次执行从更高的起点开始。这种能够持续积累的仓库记忆，才是 AI 工程真正的复利资产。

AI 时代，工程师的未来

讲座的最后一个主题会把视角从项目拉回工程师自身。AI 不只提高编码速度，它正在改变软件的生产单位：过去团队容易用代码行、Commit 或 PR 衡量进展；未来更有意义的单位是“已验证的能力增量”：从需求、设计和实现，一直到测试与运行证据的完整闭环。

这也意味着开发生命周期会重新分配注意力。模板代码、机械迁移和孤立实现会越来越便宜；领域建模、架构取舍、验证设计、事故分析以及对用户后果负责，会变得更加重要。团队不会因为 Agent 出现就自动消失，但拓扑会改变：人负责方向、权限、取舍与升级路径，不同 Agent 承担研究、Spec、实现、测试和 Review，真实用户与生产环境继续提供最终反馈。

对个人而言，未来的护城河至少有四层。最底层是熟练使用模型和工具；再向上是系统设计与领域理解；然后是验证能力与责任；最上层则是领导力和工程品味——知道什么值得做，什么结果足够好，以及什么时候必须停下来重新定义问题。工具层最容易学习，也最容易被复制；真正形成长期差异的，是上面三层。

现场还会给出一个具体的 30／90／365 天行动框架：先选择一个真实、重复的任务建立上下文和回归测试；再用 90 天完成一个端到端项目，把失败沉淀为 Spec 与 Skill；最终形成自己的领域资产和 AI 工程方法，能够带领人和 Agent 一起交付复杂结果。

本周日，Tubi Meetup 现场见

如果你已经在使用 Codex、Claude Code、Cursor 等工具，但仍然觉得 AI 只能承担零散任务；如果你正在思考怎样让 Agent 参与长期项目、跨团队协作或软硬件开发；或者你关心技术管理者和架构师在 AI 时代的新职责，欢迎来参加这次 Tubi Meetup。

活动时间为 2026 年 7 月 19 日（本周日）14:00—17:30。现场会完整展开三个案例、统一方法论与“工程师的未来”主题，并穿插现场演示。

参与现场活动的同学，请扫以下二维码在活动行里进行报名。

观看线上直播的同学，可以扫描以下二维码登录极客时间进行观看。

这不是一场关于“让 AI 多写一点代码”的分享，而是一次关于如何重新组织工程工作的讨论。

当实现变得廉价，定义问题、建立反馈和判断质量，正在成为工程师最昂贵的能力。期待本周日下午在 Tubi Meetup 与大家见面。