文章总结： 本文阐述了AINative并行研发实践，通过TurboCache项目演示了两天内构建可用系统的过程。该方法强调利用gitworktree进行物理隔离，并结合AI工具管理上下文与依赖，将研发导向从功能完成转变为系统优先运行。这有效降低了认知负担，加速了真实反馈获取，显著提升了研发效率与迭代质量。 综合评分： 92 文章分类： 安全建设,安全开发,安全工具

---

从想法到可用系统：一次并行开发的完整工程实践

原创

周鹏 周鹏

云起无垠

2026年2月4日 19:06 北京

最近我在做一个新项目TurboCache，用了两天时间，把它推进到了一个可以真实部署、接真实流量的状态。

不是Demo，不是POC，而是一个真正“活着”的系统。

这件事本身并不稀奇。真正值得记录的，是它是怎么发生的。

因为这两天里，我并没有比以往写更多代码，却明显感觉到一件事：AI Native并行研发，正在改变系统“出现的时间点”。

1

先说结论：改变的不是速度，而是顺序

很多人看到“两天内做出系统”，第一反应是：

• 写代码变快了
• 工具更顺手了
• 人更卷了

但这次实践中，真正改变的并不是这些。

真正改变的是顺序：系统不再等“功能做完”才出现，而是在一开始就进入可运行状态。

这是一个非常关键的转变。传统的研发模式里，我们习惯了先把所有功能做完，再让系统整体运行。但在AI Native的并行研发模式下，系统从第一天就是活的，只是功能在逐步完善。

这种转变带来的影响，远比单纯的”速度提升”要深远得多。

2

什么叫「可用系统」

先澄清一个关键概念。

这里的“可用系统”，并不意味着：

• 功能已经完整
• 代码已经最优
• 架构已经冻结

而是指：系统已经进入“真实反馈阶段”。

在两天结束时，TurboCache已经满足：

• 能作为OpenAI/Anthropic API的反向代理正常工作
• Redis缓存逻辑真实生效，命中行为可验证
• 至少支持一个流式（SSE）和一个非流式请求
• 支持多上游路由（如OpenAI/Anthropic）
• Web 管理界面可完成基础配置和查看

也就是说，它已经：可以部署、可以跑、可以接真实流量。

这是一个非常重要的时间点：从这一刻开始，系统是“活的”。

你可以把它部署到测试环境，让真实的请求流过它，观察它的行为，发现它的问题。这种真实的反馈，是任何设计文档和代码审查都无法替代的。

3

过去的研发节奏，为什么总是慢半拍

很多团队默认的研发路径是这样的：功能设计→功能实现→功能堆叠→集成→系统可用。

在这个过程中：

• 系统往往到很后期才第一次整体运行
• 问题集中在集成阶段一次性暴露
• 调整成本极高

结果是：系统活得很晚，决策却做得很早。

我见过太多这样的项目：前期花了大量时间设计架构、定义接口、规划模块，等到真正集成的时候，才发现很多假设是错的。这时候要调整，成本已经非常高了。

更糟糕的是，因为系统一直没有真正运行起来，团队对”这个系统到底行不行”始终心里没底。这种不确定性会持续消耗团队的信心和动力。

4

AI Native 并行研发，带来了什么不同

在这次实践中，我刻意采用了一种不同的思路：不等功能做完，先让系统整体跑起来。

这背后有三个前提变化：

模块是并列的，而不是排队的

只要共享约定稳定，模块就可以并行推进。

传统的串行开发模式下，模块之间往往存在严格的依赖关系：A模块做完了，B模块才能开始。但在并行模式下，只要我们提前定义好模块之间的接口和约定，各个模块就可以同时开工。

这就像建房子，传统方式是先把地基打完，再砌墙，再装修。但如果我们提前规划好每个房间的尺寸和接口，地基、墙体、水电可以同时施工，只要最后能对接上就行。

并行不是“多写几条分支”，而是物理隔离

并行要发生在目录、窗口、运行实例层面，而不是脑子里。

很多人以为并行开发就是开几个Git分支，然后在不同分支之间切来切去。但这种方式的问题是，你的大脑还是串行的。每次切分支，你都需要重新加载上下文，回忆”这个分支现在做到哪一步了”。

真正的并行，需要物理隔离。每个模块有自己的目录、自己的终端窗口、自己的运行实例。切换模块时，你做的不是”切分支”，而是”切窗口”。这样，每个模块的上下文都是独立保存的，你不需要在脑子里维护多个状态。

认知负担必须被系统性降低

否则并行只会更累，而不会更快。

这是最关键的一点。如果并行开发增加了你的认知负担，那它就失去了意义。你需要工具和流程来帮你管理这种复杂度，而不是靠大脑硬记。

AI在这里扮演了重要角色。它可以帮你记住每个模块的状态，提醒你模块之间的依赖关系，在合并前扫描潜在的冲突。这些工作以前都需要你自己做，现在可以交给AI了。

5

TurboCache 的结构，为什么适合并行

从结构上看，TurboCache并不是一个强串行系统。

简化后，它大致是：

• Proxy核心层：处理请求转发和响应
• Redis缓存层：管理缓存逻辑
• Upstream抽象层：对接不同的上游服务
• Admin API：提供管理接口
• Web Console：前端管理界面

这些模块在实现层面是并列关系，真正的耦合点只有一个：共享约定（依赖基线）。

这意味着：只要依赖基线稳定，模块就可以并行推进。

举个例子，Proxy核心层和Web Console之间几乎没有直接依赖。只要我们提前定义好Admin API的接口格式，这两个模块就可以完全独立开发。即使Proxy的实现细节发生变化，只要API接口不变，Web Console就不需要改动。

这种松耦合的架构，是并行开发的基础。如果你的系统是一个紧耦合的整体，那并行开发就会非常困难。

6

并行研发真正的瓶颈，不是技术能力

很多人认为并行研发难，是因为：

• Git不熟
• 架构没设计好
• AI Native研发经验不足

但在真实工程里，真正消耗时间的往往是：

• 频繁切分支、切上下文
• 记住「每个模块现在做到哪一步」
• 担心「我现在改的会不会影响别的模块」
• 合并前依赖记忆和直觉判断风险

这些并不难，但会持续消耗注意力。

一旦注意力被切碎，并行就会退化成“伪并行”。

我见过很多开发者，开了三四个分支，但实际上还是在串行工作。因为每次切分支，他们都需要花几分钟回忆”这个分支在做什么”，”上次做到哪里了”，”还有什么没做完”。这种认知负担会让并行开发的效率大打折扣。

更糟糕的是，当你不确定”我现在的改动会不会影响其他模块”时，你会变得非常谨慎，甚至不敢大胆重构。这种心理负担会让你的开发速度变慢，代码质量也会下降。

7

AI Native并行研发，本质解决的是「注意力问题」

在TurboCache这个项目里，我把并行拆成了三层：

结构层：模块是否真的可并行

模块边界是否清晰，共享约定是否稳定？这是并行的基础。如果模块之间的边界不清晰，或者共享约定经常变化，那并行开发就会变成一场灾难。

物理层：并行是否真的发生

不是切分支，而是切目录、切窗口、切运行实例。这是并行的实现。你需要真正的物理隔离，而不是在脑子里维护多个状态。

认知层：并行是否可持续

上下文是否容易丢失，切换成本是否可控？这是并行的关键。如果切换成本太高，或者上下文容易丢失，那并行开发就无法持续。

AI Native的价值，主要体现在第三层。

AI可以帮你记住每个模块的状态，提醒你模块之间的依赖关系，在合并前扫描潜在的冲突。这些工作以前都需要你自己做，现在可以交给AI了。

8

AI Native并行研发步骤

第一步：先做依赖基线，而不是马上写功能

在真正并行之前，我先做了一件看起来“不快”的事：把所有模块都会依赖的共享约定先写清楚。

包括：

• OpenAI API请求与响应的统一结构
• 缓存Key的生成规则
• 上游Provider的抽象接口
• 流式与非流式响应的统一封装

这一步的目的只有一个：降低后续并行开发时的不确定性。

很多人会觉得这一步太慢了，为什么不直接开始写代码？但实际上，这一步是在为后续的并行开发创造条件。如果你不提前定义好共享约定，那在并行开发过程中，每个模块都可能对这些约定有不同的理解，最后集成的时候就会出现大量的冲突和返工。

我花了大概半天时间来定义这些共享约定，但这半天的投入，为后续的并行开发节省了大量时间。

|这里讲一个真实案例：从一句话需求到可执行模块

一开始，多上游功能只有一句话：“要支持多上游，并且缓存能不能隔离？”

我没有直接写代码，而是先用云起无垠内部的需求澄清AI研发工具（clouditera:dev:clarify）：

最终明确了：

• 第一版只支持按上游维度隔离缓存
• 路由方式直接体现在URL路径中
• 管理界面只提供简单开关

这一步把不确定性前移并压缩了。

如果我直接开始写代码，很可能会做出一个过度设计的方案：支持多种隔离维度、复杂的路由规则、丰富的管理界面。但这些功能在第一版中并不需要，反而会增加开发复杂度。

通过需求澄清，我把范围缩小到了最小可用版本，这样就可以更快地让系统跑起来，然后基于真实反馈来决定下一步要做什么。

第二步：git worktree，让并行真的发生

如果只是用git checkout，并行开发基本是不大可能的。

我使用的是git worktree+多终端：

/turbocache (main)   |   ├── tc-core       -> feature/core-proxy-cache   ├── tc-upstream   -> feature/multi-upstream   ├── tc-admin      -> feature/admin-api   └── tc-frontend   -> feature/frontend-console

每个worktree：

• 独立目录
• 独立分支
• 独立运行

切换模块时，我做的不是”切分支”，而是”切窗口”。这种方式的好处是，每个模块的上下文都是独立保存的。当我从tc-core切换到tc-frontend时，我不需要重新加载上下文，因为tc-frontend的代码、终端、运行实例都还在那里，我只需要切换窗口就可以继续工作。

使用的工具链：

• 终端复用：tmux（也可以用 iTerm2 或 Windows Terminal）
• 编辑器：VSCode，每个 worktree 打开独立窗口
• 构建工具：每个 worktree 独立运行（不同端口）

我在VSCode中打开了4个窗口，每个窗口对应一个worktree。在tmux中也创建了4个窗格，每个窗格对应一个worktree的终端。这样，我可以随时在不同模块之间切换，而不需要重新加载上下文。

|Day 1：并行真正发生的一天

第一天的真实情况，更像这样：

没有任何一个模块是”完成的”，但它们同时在前进。这种”同时未完成”的状态，恰恰是并行开发的核心特征。

系统轮廓在第一天就已经出现。

到第一天结束时，虽然每个模块都还有很多功能没做完，但系统已经可以整体运行了。我可以启动Proxy，发送一个请求，看到它被转发到上游，响应被缓存到Redis，然后在Web Console中查看缓存命中情况。

这种”系统整体可运行”的状态，给了我巨大的信心。我知道架构是对的，模块之间的接口是通的，剩下的只是补充功能和优化细节。

9

AI 在这里，真正做了什么

很多人谈AI+研发，会不自觉聚焦在“写代码”。

但在这次实践中，AI最重要的价值并不在这里。

它更多承担的是：

• 上下文记录器：帮我记住每个模块当前状态
• 一致性提醒器：避免偏离最初的约定
• 风险扫描器：在合并前提示潜在影响范围

换句话说：AI接管了“消耗注意力但不创造价值”的那部分工作。我不需要在脑子里记住”tc-core现在做到哪一步了”，”tc-admin还有什么功能没做完”，”这两个模块之间有没有依赖关系”。这些信息都由AI来管理，我只需要专注于写代码和做决策。

具体在哪些环节减少了注意力消耗？

1. 需求澄清阶段：用clarify工具把模糊想法变成明确的边界，避免后续返工

2. 开发阶段：AI记住每个模块的上下文，切换模块时不需要重新回忆

3. 合并阶段：AI扫描改动范围，给出合并顺序建议（见下文）

这三个环节，以前都需要我自己来做，现在可以交给AI了。这让我可以把更多精力放在真正重要的事情上：设计架构、写代码、做决策。

10

两个命令，明显压缩了非编码时间

clouditera:dev:clarify：尽早把边界说清楚

clarify的核心作用是：在写代码之前，把不确定性处理掉。

这一步看起来”慢”，但实际上是在为并行开发创造条件：

• 明确了模块边界
• 固化了共享约定
• 避免了后续返工

我见过太多项目，因为需求不清晰，导致开发过程中反复返工。每次返工，不仅浪费时间，还会打击团队的士气。通过需求澄清，我们可以在开始之前就把这些不确定性处理掉，让后续的开发更加顺畅。

clouditera:git:pr：把收尾成本降到最低

Feature Branch      │      ▼/clouditera:git:pr      │      ▼Clean, Reviewable PR

并行开发时，这是一个非常关键的减负点。

当你同时开发多个模块时，每个模块都需要创建PR、写描述、等待审查。如果这个过程很繁琐，那并行开发的效率就会大打折扣。

clouditera:git:pr命令可以自动生成PR描述，分析改动范围，提供审查建议。这让我可以快速创建高质量的PR，而不需要花大量时间写描述和整理改动。

11

并行之后，代码是如何合并的？

一个刻意的约束是：worktree只负责开发，不负责合并，所有合并都在main分支完成。在合并前，我会让AI帮我：

• 扫描改动范围：分析每个分支修改了哪些文件
• 判断依赖关系：识别模块间的依赖（例如Admin API依赖Core Proxy的缓存接口）
• 给出合并顺序：建议先合并Core Proxy，再合并依赖它的模块

一个真实的例子：

AI 分析结果：1. feature/core-proxy-cache 修改了 cache.ts（核心接口）2. feature/admin-api 依赖了 cache.ts 的接口3. feature/multi-upstream 和 feature/frontend-console 互不依赖
建议合并顺序：1. core-proxy-cache（提供基础接口）2. admin-api 和 multi-upstream（可并行合并）3. frontend-console（最后合并，依赖 Admin API）

如果有冲突，再由我验证行为是否符合预期。

这种方式的好处是，我不需要在脑子里维护模块之间的依赖关系。AI会帮我分析，我只需要根据分析结果来决定合并顺序。这大大降低了合并的复杂度和风险。

12

并行开发的常见陷阱

虽然这次实践很顺利，但并行开发也有一些需要注意的坑：

依赖基线不稳定导致的返工

如果在并行开发过程中，共享约定发生了变化（例如缓存Key的生成规则改了），所有依赖它的模块都需要返工。

避免方法：

• 在并行前把共享约定写清楚，甚至写成接口定义文件
• 如果必须修改，立即同步到所有worktree

我在这个项目中，把共享约定写成了TypeScript的接口定义文件，并且在每个 worktree中都引用了这个文件。这样，如果接口发生变化，TypeScript编译器会立即报错，我就可以及时发现并修复。

worktree 管理不当导致的混乱

worktree太多、分支名不清晰、忘记清理废弃的worktree，都会导致混乱。

避免方法：

• 使用清晰的命名规则（例如tc-core对应feature/core-proxy-cache）
• 定期运行git worktree list检查状态
• 及时清理已合并的worktree

我建立了一个简单的命名规则：worktree目录名以tc-开头，后面跟模块名；分支名以feature/开头，后面跟功能描述。这样，我可以一眼看出每个worktree对应哪个分支，避免混乱。

过度并行导致的集成困难

如果一次性并行开发5+个模块，合并时可能会遇到大量冲突，反而降低效率。

避免方法：

• 控制并行数量（3-4个模块是比较合理的）
• 优先合并核心模块，再合并依赖模块

在这个项目中，我同时开发了4个模块，这是一个比较合理的数量。如果模块太多，管理成本会急剧上升，反而得不偿失。

13

为什么这件事对个人和团队都重要

当系统在第一天就能跑起来，会发生几件非常关键的变化：

• 可以更早接入真实流量
• 可以更早发现设计上的错误
• 可以更早调整优先级和方向

这意味着：研发不再是“赌设计”，而是“基于反馈演进”。

传统的研发模式下，我们需要在开始之前就把所有设计都想清楚，然后按照设计来实现。但这种方式的问题是，很多假设在真实环境中是不成立的。等到系统真正运行起来，才发现设计有问题，这时候调整成本已经非常高了。

而在AI Native并行研发模式下，系统从第一天就是活的。我们可以快速验证设计假设，发现问题，调整方向。这种快速迭代的能力，是传统研发模式无法比拟的。

这点很重要。

如果这只是“某个人写代码更快”，那它的价值是有限的。

但AI Native并行研发真正指向的是：

• 更低的上下文切换成本
• 更早的系统级反馈
• 更可控的复杂度增长

这些变化，对团队规模越大、系统越复杂的场景，价值越高。

在一个10人的团队中，如果每个人都能采用这种并行研发模式，那整个团队的效率提升将是指数级的。因为不仅每个人的效率提升了，团队之间的协作成本也降低了。

14

写在最后

我越来越清楚地感受到：AI Native不是“加一个工具”，而是研发范式正在发生变化。

从以功能完成为导向转向以系统可运行为导向；从人在脑子里并行转向系统帮助人并行。

这种范式转变，不仅仅是工具的升级，更是思维方式的转变。我们需要重新思考”什么是好的研发流程”，”什么是高效的协作方式”，”什么是可持续的开发模式”。

这次两天内让系统跑起来的经历，让我确认了一件事：AI Native并行研发真正改变的，不是“写代码的速度”，而是“系统进入真实世界的时间点”。

而这个时间点，往往决定了一个项目后续的全部节奏。

安全极客是一个致力于信息安全知识共享与交流的专业社区平台，主要围绕GPTSecurity、智能模糊测试、软件供应链安全、红蓝攻防四大主题构建内容分享生态。云起无垠作为联合发起方，欢迎广大安全专家的加入，共同探讨前沿安全技术，促进行业内的知识分享与合作。

---

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：云起无垠 周鹏 周鹏《从想法到可用系统：一次并行开发的完整工程实践》