企业官网建设流程全解析

最近我把整套 AI 编码工作流搬进了手机终端。不是在电脑前装样子，而是真的在外面用手机连上服务器，让 Pi 调度 Claude 和 Codex，把一个小工具从需求拆解、架构设计到代码实现全部跑完。今天把这套组合完整复盘一遍，内容包括工具分工、环境部署、实操流程、报错排查和我的踩坑心得。如果你平时有远程开发、移动办公的需求，或者正在折腾 AI 编程助手，这篇应该能帮你省不少时间。

1. 这套协作范式到底在解决什么问题

1.1 Pi、Claude、Codex 三个角色怎么分工

先说结论：我不是让某一个 AI 工具把所有事都干完，而是用 Pi 做编排，让 Claude 负责架构，让 Codex 负责写代码。这就像一支开发团队：Pi 是项目经理，Claude 是架构师，Codex 是程序员。各干各的，效率比单打独斗高得多。

三个工具在我这里的定位是这样的：

Pi 的定位不是重复造轮子，而是做一个透明调度器。它自己并不需要写业务代码，它的价值在于把“需求”翻译成 Claude 和 Codex 都能执行的任务，然后再把两者的产出拼回一个完整项目。这样做的好处是：Claude 不写码，所以它做架构审查时思考更干净，不会被局部实现带偏；Codex 不背架构责任，所以它写代码时可以完全聚焦函数实现，速度快。两者各取所长，再通过 Pi 串联起来，整个流程就顺了。

1.2 为什么一定要手机端掌控

你可能会问：在电脑上也能用这套组合，为什么非要手机？

我的回答是：手机端不是替代电脑，而是把“不可用的碎片时间”变成生产力。比如我正在地铁上，开发机收到监控告警，某个接口响应异常，这时候打开手机 SSH 进入服务器，让 Claude 快速扫一眼日志，让 Codex 修复问题，整个过程可能也就五分钟。等回到家再打开电脑，问题已经修复并验证完了。

另一个原因是手机端并不提升 AI 能力，但能最大化“人”的效率。真正需要我深度思考、仔细读代码的场景，我依然会开电脑；但百分之七十的 AI 编码任务，其实只需要给出指令、确认方向、看最终测试结果。这类任务完全可以在手机终端完成。因此，这套范式的核心是“掌控”，不是“写代码”。你不需要在手机上编辑大段代码，你只需要知道如何下达指令、如何检查产物。

1.3 这套范式适合哪些人

我自己体会下来，最受益的是这几类人：

• 远程开发者：主力开发机在机房或家里，日常通过 SSH 工作的人。
• 独立开发者：经常在外面却有临时需求，希望马上动手做原型验证的人。
• 频繁出差的技术管理者：不需要自己写多少代码，但需要能随时看技术方案和关键代码实现。
• AI 编程工具重度用户：手里已经用了不止一个 AI 助手，希望能“编排”它们而不是逐个手动切换。

如果你对命令行还不熟，连cd、ls都吃力，那我不建议一上来就照着这篇折腾。先花几天把 Linux 基础命令和 SSH 连接弄清楚，再来体验，否则遇到报错会很打击信心。

2. 前置环境：手机、远程开发机、AI工具链的一次到位

2.1 手机终端 App 的选择与配置

手机端最常用的终端工具是 Termius，我主力用的是它。免费版就够日常使用，支持 iOS、Android、Windows、macOS，同步很方便。它的界面比普通终端更贴近手机操作习惯，支持 SSH 密钥、指纹解锁、端口转发和分组管理。如果你喜欢更极客的体验，iOS 上也可以选 Blink Shell，配置自由度更高，但对小白不太友好。

在手机 Termius 里安装密钥对很简单，生成后将私钥保存在 Termius 的 Key 里，然后把它填到服务器的authorized_keys文件中。这样手机端连接服务器时就不需要输入密码，体验基本和电脑终端一致。建议测试阶段用密码登录，稳定后改为密钥登录并禁用密码认证。

手机终端因为屏幕小，键盘输入效率天然偏低。我建议：

• 终端字号调到 14 到 16，太小会费眼睛。
• 配合外接蓝牙键盘，整体效率会提升一个档次。
• 一定要设置代码高亮关键字，尤其在查看报错信息时能快速定位。

2.2 远程开发机需要什么样的配置和软件

远程开发机是真正跑代码的地方，建议满足基础配置即可：2 核 CPU、4GB 内存、50GB SSD。我自己的服务器是 2C4G，同时跑 Claude、Codex 的 CLI 进程和一个小型 Python 项目，完全够用。

系统推荐 Ubuntu 22.04 LTS 或 Debian 12。需要提前装好 Node.js（版本最好 20 以上）、Python（3.10 以上）、Git、Docker。AI 编码工具有些依赖 Node.js 运行时，所以 Node 版本尽量新，避免安装时报引擎冲突。

部署远程开发机时我建议创建一个专用用户，不要直接用 root。比如创建一个名为pi的用户，所有 AI 编码工具都装在这个用户下，这样权限隔离干净，万一工具被恶意 prompt 诱导执行了危险命令，也不会影响系统核心。

谈到网络环境，这里有个容易被忽略的前提：服务器必须能正常访问 Claude 和 Codex 的 API 服务。如果服务器无法连通对应 API 端点，后面所有模型调用都会失败。具体怎么保证访问，取决于你的服务器所在区域和网络策略，我这边不展开，你只需要在部署前用curl简单测一下连通性即可。

2.3 安装 Pi、Claude Code、Codex 的完整命令

安装思路很简单：先把系统依赖组件准备好，然后通过 npm 全局安装三个 CLI 工具。下面是我常用的命令，具体安装包名以官方文档为准：

# 更新系统基础组件 sudo apt update sudo apt install -y git curl build-essential # 安装 Node.js 20（这里使用 NodeSource 官方仓库） curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash - sudo apt install -y nodejs # 验证 Node 与 npm 版本 node -v npm -v # 全局安装 AI 编码工具 npm install -g @anthropic-ai/claude-code npm install -g @openai/codex npm install -g pi-agent

安装完成后，需要在当前用户的环境变量里配置 API Key。可以写入~/.bashrc：

echo 'export ANTHROPIC_API_KEY="sk-ant-xxxx"' >> ~/.bashrc echo 'export OPENAI_API_KEY="sk-xxxx"' >> ~/.bashrc source ~/.bashrc

这里要注意，API Key 属于敏感信息，不要让配置好的密钥文件被其他用户可读。建议用chmod 600 ~/.bashrc或者通过专用密钥管理工具保存。

2.4 安全加固的实操建议

手机设备丢失、服务器被入侵，都是这套范式下容易让人忽略的风险点。我的做法是：

• 修改 SSH 默认端口，并只允许密钥登录。
• 编辑/etc/ssh/sshd_config，把PasswordAuthentication设为no。
• 用fail2ban自动封禁频繁尝试连接的 IP。
• 手机 Termius 里开启应用锁，至少设置 6 位 PIN，有条件可以用生物识别解锁。
• 不要用同一套密钥同时保存多个生产服务器，至少分出工作密钥和个人密钥。

安全这件事看起来不产生直接收益，但一旦出事，损失的开发时间远比配置成本高。

3. 核心协作逻辑：Pi 如何把架构和编码拧成一股绳

3.1 Pi 配置一个透明调度器

Pi 的强大之处在于它能读取配置文件，按你定义的角色和流程工作。我先给一个简化版的pi.config.json，你后续可以按自己项目调整：

{ "project": "todo-api", "roles": { "architect": { "backend": "claude", "prompt_prefix": "你是一名有二十年经验的系统架构师，只负责设计、审查和风险评估，不要直接编写实现代码。" }, "coder": { "backend": "codex", "prompt_prefix": "你是一个高效的工程师，严格参考架构文档输出代码，优先保证实现完整、可运行、测试通过。" } }, "pipeline": [ "architect", "coder", "architect_review" ], "language": "python", "test_command": "pytest" }

当我在项目目录执行pi run "完成一个 Todo API"时，Pi 会先调用 architect 角色，也就是 Claude，让它输出一份架构方案；然后 Pi 解析这份方案，拆解出编码任务，交给 coder 角色也就是 Codex 去逐项实现；最后 Pi 再调用 Claude 做一次审查，发现问题就丢回给 Codex 修复。

这个设计思路的核心是“任务间通过文件交接”。Pi 不会把所有上下文都塞在一个超长对话里，而是让 Claude 把架构输出为architecture.md，让 Codex 把代码写入实际工程文件，让审查意见写入review.md。文件成了工具之间的“信息传递载体”，不会因为对话太长导致上下文爆炸，也不会因为某一轮回复丢失导致全部重来。

3.2 Claude 做架构把关时到底在看什么

很多人在用 Claude 做架构时，喜欢让它输出一堆泛泛的“设计原则”，比如高内聚低耦合。但真正有效的架构把关应该聚焦到可执行层面。我在 Pi 里给 Claude 的提示词是这样设计的：

请审阅当前项目，重点检查以下内容： 1. API 路径和状态码是否符合 RESTful 规范，是否存在歧义。 2. 数据模型字段是否冗余，关键查询是否缺少索引。 3. 认证授权方案是否有漏洞，token 是否设置了过期时间。 4. 异常处理是否覆盖了边界条件。 5. 单元测试是否覆盖核心逻辑，是否容易维护。 不要直接修改代码，输出一份结构化审查报告，并给出修改优先级。

Claude 的输出会落到review.md，里面每个问题都带优先级和具体修改建议。Pi 会把这些问题整理成一个待办列表，然后按优先级丢给 Codex 修复。这样架构把关就不会变成“走过场”，而是真的能兜住质量问题。

3.3 任务拆解与编码执行的节奏

当 Pi 拿到 Claude 的架构文档后，它会自动拆出类似这样的任务队列：

1. 初始化 FastAPI 项目结构，包含app/、tests/、requirements.txt。
2. 实现 Todo 数据模型，字段包括标题、描述、状态、创建时间、更新时间。
3. 实现 JWT 认证中间件，要求所有/todos/接口必须携带有效 token。
4. 编写 pytest 测试，覆盖 CRUD 接口和鉴权失败场景。
5. 执行测试并将输出反馈给 Claude 审查。

每个任务都有明确的验收条件，Codex 只需要按条件实现即可，不需要思考“下一步该做什么”。这就是 Pi 作为调度器的价值：它让 AI 编码变得有节奏，避免 Codex 一上来就自由发挥导致工程结构混乱。

4. 手机端实战记录：从发起任务到验收的完整链路

4.1 第一步：连接服务器并进入持久会话

手机端我用的 Termius，操作路径如下：

ssh pi@your-server tmux new -s piwork cd ~/todo-api pi run "请基于架构文档，完成整个 Todo API"

这里为什么要用 tmux？因为手机网络不稳定，一旦 SSH 断连，普通终端里的进程很容易被挂断，导致任务丢失。tmux 会让会话脱离 SSH 连接运行，即使手机断网，服务器上的任务也不会中断。回来后执行tmux attach -t piwork就能重新看到运行结果。这算是我在手机端开发最依赖的一个小技巧。

4.2 第二步：观察 Pi 调度过程中的关键输出

实际运行pi run时，输出大概长这样（我整理成日志形式）：

[Pi] 读取架构文档 architecture.md ... [Pi] 架构方案确认，开始拆分任务 [Pi] 拆分为 5 个子任务： 1. 初始化FastAPI项目结构 2. 实现Todo CRUD模型 3. 实现JWT鉴权中间件 4. 编写pytest单元测试 5. 执行测试并修复失败 [Pi] 将任务1交给 Codex ... [Codex] 任务1完成，耗时 18 秒 [Pi] 将任务2交给 Codex ... [Codex] 任务2完成，耗时 14 秒 [Pi] 将任务3交给 Codex ... [Codex] 任务3完成，耗时 26 秒 [Pi] 将任务4交给 Codex ... [Codex] 任务4完成，耗时 31 秒 [Pi] 执行 pytest ... [Pi] 发现 2 个失败用例，调用 Claude 审查 [Claude] 审查结论：鉴权中间件缺少 token 过期时间校验，建议修复 [Pi] 将修复任务交给 Codex ... [Codex] 修复完成，重新执行 pytest [Pi] 所有测试通过，本轮任务完成

这在手机屏幕上是很清爽的体验。我不需要看代码细节，只需要关注任务进度和最终结果。中间如果某一步卡住，Pi 会输出暂停原因，我再决定是继续等待还是调整 prompt。

4.3 第三步：通过手机浏览器和 curl 做验收

代码生成完、测试通过，并不代表真的没问题。我还会在手机上用 curl 做一轮接口验收：

# 启动服务 uvicorn app.main:app --host 0.0.0.0 --port 8000 # 获取 token curl -X POST http://localhost:8000/auth/token -H "Content-Type: application/json" -d '{"username":"demo","password":"demo123"}' # 创建一个 todo curl -X POST http://localhost:8000/todos/ -H "Content-Type: application/json" -H "Authorization: Bearer <token>" -d '{"title":"测试待办","description":"手机端验收"}' # 查询 todo 列表 curl http://localhost:8000/todos/ -H "Authorization: Bearer <token>"

如果开发机安全组允许，还可以直接在手机浏览器打开http://服务器IP:8000/docs，看 FastAPI 自动生成的 Swagger 文档，点几个按钮验证接口是否正常。这样整套链路就闭环了。

4.4 手机端操作体验优化

用手机端掌控这套流程，有几个细节能明显提升体验：

• 把 Pi 的日志调成 summary 模式，不要输出大段完整代码，只看任务状态和关键报错。
• 给 Termius 配置常用的命令别名，比如piwork直接进入指定 tmux 会话并切换到项目目录。
• 在手机输入 prompt 时，尽量用短句和关键词，避免屏幕键盘反复切换。
• 如果遇到需要修改单个文件的小需求，先用 Pi 让 Claude 给出精确的修改意见，再让 Codex 执行，比自己逐字输入省事得多。

5. 常见问题与排查技巧实录

5.1 高频问题速查表

5.2 报错定位思路：不要只盯着错误信息本身

很多人在排查 Codex 或 Claude 的 CLI 报错时，会第一时间怀疑工具本身有问题。但实测下来，大部分问题出在环境变量和网络连不上。我总结了一个简单的排查顺序：先看是否连得上 API，再看 Key 是否有效，然后看 CLI 版本是否过旧，最后才考虑是不是配置文件写错。按照这个顺序，绝大多数问题能在五分钟内定位。

5.3 我踩过的几个坑与调整方案

刚开始我用这套组合时，犯过一个典型错误：让 Claude 在一条消息里既设计架构又写实现代码。结果架构设计不完整，代码也很粗糙。后来我把角色彻底拆开，Claude 只输出架构文档，Codex 只按文档写代码，质量立刻提升不少。另外，我还让 Pi 每次任务结束后自动执行一次git diff和pytest，只有两者都通过，任务才算完成。这样能尽早发现问题，不必等人介入。

还有一个容易被忽略的坑：手机终端里滚动查看长日志非常痛苦。我后来让 Pi 把关键输出写入独立的run.log，保证出错时我可以直接grep关键词，而不是在屏幕上手动翻几千行输出。

6. 最后再分享两点个人使用心得

这套手机端掌控方案我前前后后调整了一周，最大的体会是：AI 工具的环境搭建并不难，难的是让 Cl、Codex 和 Pi 之间形成稳定配合。文件交接、角色分离、自动测试门禁，这三件事加上去之后，整个流程的可靠性才真正立住了。

另外，我不建议让 Pi 在每个任务结束后都调用 Claude 做一次全量代码审查。频率太高会拖慢速度，也没有必要。我把审查触发条件设置为：测试未通过，或代码变更超过指定行数，或涉及鉴权、支付这类高风险模块时才审查。这样既能保证质量，又不会让任务流程变得繁琐。

如果你也想在手机上体验这套组合，建议先从一个小项目开始，比如一个带增删改查的 Todo API，照着我上面的流程跑一遍。跑通之后，你会对手里的工具组合有完全不一样的感觉。