企业官网建设流程全解析

多数人的手机里装了三个AI应用：一个用来查资料，一个用来写代码，一个用来审代码。但它们是三座孤岛——你在Kimi里理清的思路，要复制粘贴到Claude里；Claude改完的代码，还得人肉搬运到Codex那边跑一遍。这套流程效率极低，尤其在脱离电脑的环境里。

我过去两个月一直在折腾一件事：把这三个模型从"独立问答工具"改造成"流水线上的三个工位"。手机端作为控制台，Kimi负责拆需求和写方案，Claude Code负责卡架构和做代码审查，Codex负责实际编码和自测。三者通过一个远程开发环境串联，我在手机上的每一次操作，都对应着这个"AI开发小队"的一次协同作业。这篇文章就是把这套多智能体协作范式的完整搭建过程、任务流设计、实测数据和踩坑记录摊开来讲。内容偏实战，适合已经用过至少一个AI编码工具、想在移动场景下把多个模型真正编排起来的开发者。

1. 为什么非要把三个AI塞进手机：场景逼迫下的协作重构

1.1 移动场景里"单模型问答"解决不了的问题

先还原一个真实场景。某天下午我在地铁上收到一条消息：客户那边临时要一个带用户注册和登录的接口，要求半小时内给出可运行的初版。电脑不在身边，手边只有手机。按以前的做法，我只能先打开Kimi问"注册接口怎么设计"，得到一段参考代码；再切到Claude问"这个设计有没有问题"；然后想办法在手机上的代码编辑器里改文件。三个App来回切，消息记录断开，上下文丢失，过程极其痛苦。

问题的本质在于：单模型问答天然是"一对一"的，而软件开发任务是"多工种协同"的——需要有人理解需求、有人设计架构、有人写代码、有人检查代码。你在一个对话框里同时要求四个角色，模型会陷入角色混乱，产出质量断崖式下降。多智能体协作的出发点，就是让每个模型只干自己最擅长的事。

1.2 Kimi、Claude、Codex 三个角色的分工逻辑

这套协作范式里，三个模型不是平等轮换，而是明确的流水线关系：

• Kimi：需求分析与方案设计。Kimi 的强项在长文本理解和中文场景的语义解析。你可以把一段很口语化、甚至带点情绪的需求描述（"用户登录老失败，帮我看看咋回事，顺便把注册也做了"）丢给它，它能帮你整理成结构化需求文档、拆解功能点、生成技术方案和任务清单。这一步是后面所有工作的地基。

• Claude Code：架构评审与约束检查。Claude Code 的优势在于对代码库的全局理解。给它一个项目的目录结构和核心代码，它能发现潜在的架构风险（比如循环依赖、无状态服务里塞了有状态数据、接口设计违背RESTful规范）。在这个工作流里，它是"设计总监"的角色，负责在动手编码前把方案漏洞挑出来。

• Codex：代码执行与自测。Codex 的优势是执行速度——命令执行、文件生成、测试运行都在环境里完成。它可以快速地把方案转成可运行的代码，跑通测试，输出结果。它适合充当"编码工人"。

协作关系简单说就是：Kimi负责想，Claude Code负责看，Codex 负责干。Kimi 产出的方案先由 Claude Code 修正，Claude Code 确认后的架构说明再交给 Codex 逐模块实现，Codex 的产物再回传给 Claude Code 做代码评审。这个闭环形成后，多智能体的意义才真正体现出来——不是三个模型依次发言，而是每个模型都在前一个模型的产出基础上继续增值。

1.3 与单模型、单Agent工作流的本质差别

现在市面上也有单Agent工作流，比如只用一个Claude Code，让它全程干完需求分析、编码、测试。这在项目小、需求清晰时没问题，但项目稍微复杂就会出两类情况：一是单个Agent会"一条路走到黑"，架构选型失误时无人纠偏；二是长对话中Agent的注意力会被大量中间步骤消耗，前后逻辑失联。

多智能体的本质价值在于环节间有审查点。Kimi的输出不直接变成代码，而是先经过Claude Code的检查；Claude Code的检查结果也不直接执行，而是作为Codex的输入。每个环节的产物都是一个"工件"，而不是一段对话里的只言片语。这种以工件为中心的传递方式，比单Agent的对话式上下文更稳定，也更适合手机端这种弱交互场景——你不需要盯着每一轮输出，只需要在关键节点确认。

2. 手机端搭建多智能体工作台的基础形态

2.1 手机端承载AI编码团队的路径选择

手机本身的算力和存储赛不下一个完整的编码环境，所以"手机掌控"实际包含两端：手机上跑的是轻量客户端（界面层、指令入口），真正的开发环境在远程主机上（执行层）。这是目前最现实的路径。

我在搭建过程中对比过几条路：

我最终采用的是第一种：一台云主机上装好开发环境、Node.js/Python运行时、Git，手机端用终端模拟器通过SSH连接。好处是整个链路里没有第三方中转，所有的AI命令行工具直接跑在云主机上，稳定性和可控性最好。

2.2 远程开发环境与手机客户端的连接配置

云主机的选择上，我建议至少2核4G内存，硬盘40G以上。这个配置跑三个AI工具加上代码构建基本够用。系统选Ubuntu 22.04 LTS，生态兼容性好，Node.js 和 Python 的安装源都很成熟。

连接链路是这样搭建的：

1. 云主机上创建专门的开发者用户，配置SSH Key登录，关闭密码登录。手机端生成的公钥要提前加到云主机的 authorized_keys 里。
2. 手机端安装支持SSH的终端应用，配置好主机IP、端口和私钥。这里有个关键设置：终端应用里要把字符集设为UTF-8，否则AI工具输出的中文注释会乱码。
3. 云主机上安装 Tmux 或 screen。这个很多人会忽略，但它是手机端操作的基础设施——SSH连接断掉后，Tmux里的会话还在继续运行，重连后可以接续。在地铁上切换4G和WiFi时，这个功能能救命。
4. 配置代理环境变量让AI工具能访问各自的API服务。这一步需要在云主机上按各工具的要求配置好。

注意：如果 SSH 在一段时间后断开，检查云主机的安全组规则和 sshd 配置，尤其确认ClientAliveInterval是否设置。实测设成60秒能避免大部分移动网络切换导致的连接僵死。

2.3 三个AI命令行工具的安装与权限收敛

在云主机上安装三个工具，顺序有讲究：

Kimi我并没有装命令行客户端，而是直接用它的网页版配合一个轻量的终端浏览器方案。手机SSH进入云主机后，通过一个基于终端的文本浏览器或API调用脚本，把Kimi的回复抓回来。后来发现直接在手机普通浏览器打开Kimi网页版反而更方便，所以它的角色定位是"方案生产器"，产出文本后复制到云主机的工作目录即可。

Claude Code的安装比较直接：Node.js 环境准备好后，执行官方安装命令。装完进入项目目录运行claude，按提示完成认证。关键在于认证方式——手机端没法弹浏览器，所以要把认证流程放到电脑或手机浏览器上完成，之后把生成的凭证文件传到云主机的用户目录下。之后在云主机上运行 Claude Code 就无需重复认证。

Codex的安装类似，但它的配置要更细。官方安装命令装完后，需要设置默认模型和权限模式。我建议第一次运行先在交互模式下把命令执行全部确认一遍，确认无误后再切换到较为宽松的自动执行模式。安全起见，我给 Codex 和 Claude Code 都设置了独立的系统用户，限制它们的文件写权限，只允许在工作目录下读写。

工具装完后，建议写一个环境检查脚本，把两个工具的版本、认证状态、API连通性一次性检查完。这一步在手机上极其实用——你不想每次连接后都手动敲一遍验证命令。

3. 三模型协作的任务流设计：从需求到代码的完整链路

3.1 第一棒：Kimi 负责需求拆解与技术方案生成

协作流的第一步，是把原始需求喂给Kimi。这里有个容易被忽略的技巧：Kimi的输入不能只给一句话需求，最好附加约束条件。比如"做一个用户注册接口"是无效输入，"做一个用户注册接口，技术栈Node.js+SQLite，要求密码加盐存储，token有效期24小时"才是有效输入。约束越明确，Kimi产出的技术方案偏离度越低。

Kimi的产出应该是一份包含以下内容的需求方案文档：

• 功能列表（注册、登录、Token校验、用户信息查询）
• 接口定义（路由、请求方法、请求参数、响应格式）
• 数据库设计（表结构、字段类型、索引）
• 目录结构建议
• 实现顺序与预估工作量

这份文档不需要特别长，但要结构完整。它相当于整个协作链路的"需求规格说明书"，后续所有环节都以它为准。

3.2 第二棒：Claude Code 做架构评审与约束检查

Kimi 的方案文档生成后，不能直接交给 Codex 写码。中间必须过一遍 Claude Code。这一步是整套协作范式里价值最高的环节。

我在云主机上建了一个review/目录，把Kimi生成的方案文档放进去，然后启动 Claude Code，执行类似这样的指令：

claude "请评审 /root/workspace/review/auth_plan.md 这份技术方案。 重点检查：1. 接口设计是否符合 RESTful 规范； 2. 数据库索引设计是否合理； 3. 是否存在安全漏洞（SQL注入、明文密码、token生成方式等）； 4. 目录结构是否符合可扩展要求。 请输出具体的修改建议，不要直接改文件。"

Claude Code 会逐条检查，并给出修改建议。我遇到过的典型问题是：它指出过Kimi方案中"用密码的MD5哈希作为token"这个严重安全风险，也纠正过数据库表设计中缺少唯一索引的问题。这些反馈在实际开发中价值极高——如果没有这层审查，Codex会忠实执行一个带bug的方案，最终的代码要花更多时间返工。

注意，这里的角色定位是"架构把关"，不是"代码实现"。不要让 Claude Code 在这个阶段动手写业务代码，否则它会陷入具体的实现细节而忽略全局把控。它的核心任务是对方案挑毛病。

3.3 第三棒：Codex 执行编码与自测

方案评审通过后，把修改后的方案文档作为输入，让 Codex 开始实现。Codex 的执行指令要拆到"功能模块"粒度，不要一次给它整个大项目的请求。比如注册接口这个功能，可以这样拆分：

第一步让 Codex 初始化项目结构并安装依赖：

codex "根据 /root/workspace/review/auth_plan_final.md 中的目录结构， 在 /root/workspace/project 下初始化 Node.js 项目，安装 express、better-sqlite3、 jsonwebtoken、bcryptjs 依赖。不要写业务代码，只做初始化配置。"

第二步实现数据库层和注册接口：

codex "在项目目录下，按照方案文档的数据库设计，创建 SQLite 数据库文件 和 users 表结构。然后实现注册接口 POST /api/register， 要求密码使用 bcrypt 加盐存储，用户名唯一。注册成功后返回 user_id。"

第三步实现登录和 Token 逻辑，第四步是中间件和错误处理。每一步执行完，Codex 都会自动运行测试，把结果反馈回来。

Codex 的"秒级编码"并不是说一个复杂接口一秒钟写完，而是每一步的响应速度很快——启动和上下文加载基本无感，生成代码和执行测试通常在十几秒内完成。相比在纯对话式工具里反复粘贴代码再手动切换运行环境，这个体验是代际差别。

3.4 回合制反馈机制与上下文传递

整套协作流不是一次性单向执行，而是需要多个回合。每个回合结束后，要把产物回传。

基于实测，我推荐一个"工件传递表"：

关键原则是：每个工件的文件名都带版本号，不要覆盖之前的版本。比如auth_plan_v1.md、auth_plan_v2_reviewed.md。这样任何环节出了偏差，都能回退到上一个稳定版本，而不是在手机上痛苦地翻聊天记录找回之前的内容。

第二点是上下文要显式传递。Codex 在第三步编码时，并不知道 Claude Code 的评审报告内容，除非你在指令里指定它读取：codex "先阅读 /root/workspace/review/auth_plan_review_report.md，然后按照报告中的修改建议... "。不要假设模型之间有记忆，任何关键信息都要以文件形式落到磁盘上传递。

这个回合制机制确保了整个协作过程可追踪、可审计。手机端的价值在这里体现得淋漓尽致——你不需要同时盯三个会话，只需要在每个回合结束时扫一眼产出的文件即可。

4. 实测场景：手机端完成一个带数据库的小接口

4.1 任务背景与技术栈

为了验证这套协作范式在真实场景下的表现，我用手机端从头到尾走了一遍完整流程。任务是：实现一个"笔记管理"后端服务的用户认证模块，包括注册、登录、Token验证三个接口，要求使用 Node.js + Express + SQLite 技术栈，支持基础的安全实践（密码加盐、Token过期）。

整个过程中，我只看手机屏幕操作，不走电脑。从需求提出到最终代码通过测试，总共耗时约40分钟，其中前10分钟主要花在环境连接和准备工作上。

4.2 协作过程中的关键指令与产出

阶段一：Kimi 产出方案。手机浏览器打开Kimi对话，输入：

我要实现一个笔记管理服务的用户认证模块。 技术栈：Node.js + Express + SQLite。 功能：注册、登录、Token验证。 安全要求：密码不能明文存，token要过期。 数据库就一张users表就行。 请输出技术方案，包含接口定义、表结构和目录结构，不要输出完整代码。

Kimi 返回的方案包含三张表（考虑到了用户刷新Token的场景），接口定义7个，目录结构4个模块。整体中规中矩，作为初稿合格。

阶段二：Claude Code 评审。把Kimi输出整理为auth_plan_v1.md存入云主机，运行 Claude Code 评审。评审报告指出了三个问题：

• users 表缺少created_at字段，不便于后续排查和运营统计；
• 登录接口缺少失败次数的限制，存在暴力破解风险；
• 刷新Token的接口没有校验旧Token是否过期。

我根据评审意见让 Kimi 修改了方案文档，生成auth_plan_v2_reviewed.md。

阶段三：Codex 编码。把修订版方案作为输入，分4步让 Codex 实现：

1. 初始化 Node 项目并安装依赖；
2. 创建数据库和 users 表；
3. 实现注册、登录、Token验证三个接口；
4. 运行测试并修复出现的 bug。

Codex 在执行第二步时报了一个错：bcryptjs 安装慢导致超时。我直接指示它换用内置的 crypto 模块的 scrypt 算法，绕开外部依赖。这一步体现了人在环中的价值——不需要懂细节，但要在方案受阻时做决策。

阶段四：Claude Code 终审。Codex 的代码写完后，我让 Claude Code 做最终代码评审。它确认代码整体质量合格，但指出了一个小问题：Token中间件里对 Authorization 头的解析没有处理大小写变体，少数客户端会用小写authorization。我让 Codex 快速修复后，重新跑一遍测试，全部通过。

4.3 实测结果与效率对比

最终产出的代码包括6个文件、约240行代码，测试通过率100%。整个过程耗时约40分钟，其中实际"AI工作"时间约20分钟，剩下20分钟是信息在两个工具间的整理、传递和决策。

对比纯人工操作——需求分析15分钟、写代码40分钟、自测20分钟、走查20分钟——总计约95分钟。对比单Agent（只用Codex从头干到尾）——约60分钟，但代码质量和后续返工风险高于协作模式。

我不是说这套流程快得夸张，它的最大价值不在于"快"，而在于质量稳定性。三个模型各管一段，任何一个环节都不容易被人为疏忽带偏。因为每个模型只在自己的强项环节起作用，不会因为角色混淆而产生畸形的设计。

5. 踩坑记录：多智能体协作里真正消耗时间的地方

5.1 上下文截断与格式错乱的应对

第一个坑出现在Kimi产出的方案文档里。在一次真实使用中，Kimi输出的内容带上了大量markdown格式符号和代码块语法高亮标签。这些内容粘贴到 md 文件后，直接被 Claude Code 当成正文解析，导致评审报告出现大量无意义的"代码块未闭合"提示。

解决办法：在向Kimi索要方案时，明确要求"纯文本输出，不要使用代码块标记，只要结构化文字"。Kimi支持结构化文本输出，但需要显式指定。同理，从Claude Code拿评审报告时，也要在指令里加"输出纯文本格式，不要包裹在代码块里"。

另一个问题是长文档被截断。Claude Code 处理超过一定长度的文档时，偶尔会漏掉中间部分。实测下来，超过1万字符的文档被截断的概率显著增加。应对方式是拆分——把需求方案拆成"接口设计"和"数据库设计"两个文件分别评审，而不是一次性丢一个超长文档。

5.2 工具权限边界：哪些必须人肉确认

多智能体协作越流畅，人越容易放松警惕。我遇到过几个需要强制人工确认的场景：

• 架构层面的取舍。Kimi 和 Claude Code 可能会在"用单体还是微服务"这类问题上给出完全对立的建议。模型没有真实业务背景认知，这种关键决策不能全自动流转，必须人来拍板。

• 删除文件或重构目录的操作。Codex 执行重构时，会把不需要的文件顺手删除。有一次它删掉了一个备份目录里的旧脚本，虽然无关紧要，但暴露出权限控制的必要性。我给 Codex 的工作目录加了写权限限制，只允许它写project/下的代码文件，其余目录只读。

• 外部依赖的引入。Codex 有时会自作主张安装额外的 npm 包，这些包可能是过时的甚至包含漏洞。我要求它每次安装依赖前都先输出将要执行的命令，人工确认后再执行。这个措施在手机上很容易实现——就是多敲一次y。

5.3 手机端输入效率的补救方案

手机端的天然短板是文字输入效率低。在实践中我摸索出几个补救手段：

一是模板化指令。把常用的评审指令、编码指令存成模板文件，需要时通过终端的命令补全机制或脚本一键发送，不用每次都敲几十字的指令。

二是语音输入转文字。手机系统自带的语音识别能力已经足够应付技术指令的录入。实测在安静环境下，语音输入"请评审auth_plan_v1.md的安全设计，重点检查token生成方式"这种长度的指令，准确率在95%以上。

三是利用终端的多窗口功能。手机终端支持分屏或新开标签页，我通常开三个会话：一个SSH连接到云主机跑命令，一个拿来查文档，一个放公式或参数备忘。虽然屏幕小，但信息分区后操作效率明显提升。

6. 这套协作范式的边界与我的调整建议

6.1 适用人群与不适用场景

先说适合谁。这套"手机端Kimi+Claude+Codex"协作范式，最适合以下几种人：

• 经常在通勤或外出场景下需要响应紧急开发需求的全栈或后端开发者；
• 已经在用AI辅助编程，但觉得单模型问答效率不够高的进阶用户；
• 需要对代码有质量把控、又不想在每个环节全程盯着的技术管理者。

反过来，纯前端视觉类任务不适合走这套流程。Claude Code 和 Codex 对UI细节的把控不如专用工具，手机屏幕也无法有效预览渲染效果。另外，对代码安全极其敏感的金融或医疗项目，不建议让多个第三方AI工具直接操作核心代码库，可以作为建议参考但不要让它们直接改文件。

6.2 协作模式的演进方向：从流水线到编排层

目前的"Kimi → Claude Code → Codex"是顺序流水线，但真实开发任务往往是交织的。我预测这套范式下一步会走向"编排层"——由一个统一的调度器管理多个模型，根据任务类型动态决定谁来处理。

现在的实践中已经有了雏形：我在云主机上写了一个简单的 shell 脚本，叫做task-router.sh，根据传入的任务类型关键字自动调用不同的工具——包含"方案""设计"关键字时路由到Kimi，包含"审查""评审"时路由到Claude Code，包含"实现""编码"时路由到Codex。这个脚本只有几十行，但已经把"人工判断由谁处理"这个环节自动化了。

更进一步的方向是上下文缓存层。目前三个模型之间的信息传递靠文件，但如果引入一个共享的向量检索库，让每个模型都能查询历史决策记录，协作效率会再上一个台阶。这是我在下一阶段准备尝试的方向。

6.3 给新手的上手路径建议

如果你第一次接触多智能体协作，不要一上来就搭完整的三工具流水线。我建议分三步走：

第一步：先单独熟练使用 Claude Code 和 Codex 中的任意一个，在云环境里跑通一个完整项目，理解它们的输出习惯和命令格式。这个过程大概需要一周。

第二步：在电脑端把"Kimi产方案 → Claude Code 评审"的链路跑通，感受工件传递和文档版本管理的节奏。

第三步：再迁到手机端。此时你已经有固定的指令模板和工作习惯，手机端只是换了交互介质而已，不会有陡峭的学习曲线。

最后说一个个人体会：多智能体协作初期最花时间的不是技术搭建，而是"信任建立"。你得先弄清每个模型在什么环节可靠、在什么环节会飘，才能放心地把任务交给它。我到现在也没有完全信任Co dex在没有人工确认的情况下删除文件，但在方案设计和代码生成这些环节，这套协作范式确实让我在手机上也能维持一个完整开发者的产出能力。未来如果编排层成熟了，手里这台手机可能就是整个开发团队的控制台了。