过去一段时间，我明显感觉自己的工作方式变了。

不是因为某个模型突然变得无所不能，也不是因为 IDE 里多了一个聊天窗口，而是因为我开始越来越频繁地把一整段工作交给 AI 去推进：看 PR、写 review comment、补测试、提交代码、更新 PR 描述、写飞书文档、排查持续集成、联调接口、登录远程机器安装服务、构建博客、同步微信公众号。

这些事情以前当然也能做，但它们会占掉很多碎片时间。更麻烦的是，很多工作不是单点动作，而是一串动作：读上下文、判断风险、执行命令、验证结果、整理交付物。真正有价值的变化，是 AI 终于可以参与这一整串过程。

这篇文章不是工具评测，也不是“某某工具彻底替代程序员”的口号。我把最近一些真实工作场景做了脱敏整理，想聊的是：怎样把 Codex、Claude Code、Cursor、gh、lark-cli 这类工具组合起来，让 AI 变成一个可审计、可验证、能交付结果的工作助手。

先说脱敏口径：文中的项目名、内部文档地址、内部配置、远程机器、账号、订阅地址、用户标识都做了泛化处理。方法和流程保留，敏感细节不保留。

我现在怎么分工：Cursor 看现场，Codex 跑完整任务

我现在不会把所有 AI 工具放在同一个篮子里比较。

Cursor 更像是编辑器现场。它知道我正在看哪个文件，知道光标停在哪里，知道当前项目结构，也适合做局部修改、补全、解释和轻量重构。它最顺手的地方，是你在写代码时不需要离开编辑器。

Claude Code 更像是终端里的工程代理。它天然贴近 shell、git、日志、脚本和仓库级任务。很多需要跨目录、跨命令、持续追踪状态的工作，用终端代理会更自然。

Codex 在我这里更多承担“把任务做完”的角色。我会让它读代码、改文件、跑测试、提交、推 PR、写文档、登录远程服务器安装服务。它不只是给建议，而是直接推进到可交付状态。

这些工具旁边还会配两个很重要的命令行工具：gh 和 lark-cli。前者把 GitHub PR、issue、review、workflow 接进工作流；后者把飞书文档、知识库、图片、表格这些办公协作接进来。

真正的效率来自组合，而不是来自单个工具。

看 PR：AI 不是替你点 Approve，而是替你复现问题

最近有一次 PR review 很典型。那个 PR 修的是 Web API 限流和响应头问题，表面上看改动不算大：几个 endpoint 补了参数，middleware 里补了限流 header，测试也跟着补了。

如果只是让 AI “看一下有没有问题”，大概率会得到一份泛泛的总结。更好的问法是明确审查方向。

给 Codex 的 prompt：

看这个 PR，重点检查限流器和认证依赖的执行顺序。需要给出是否阻断、影响路径、最小复现和建议修法。

AI 先用 gh pr view 拉下 PR 文件、评论和已有 review，再读相关代码。最后它发现了一个很关键的问题：某些认证依赖会在 route-level limiter wrapper 之前短路。也就是说，缺少或错误的 Authorization 请求可能直接返回 401，根本没进入限流器，自然也不会带上限流头。

这个结论不是拍脑袋来的。AI 写了一个最小 FastAPI/slowapi 复现片段，跑出连续 401 都没有限流头的结果，然后把 review comment 写成了“问题、影响、复现、建议修法”的结构。

这就是我觉得 AI 做 review 有价值的地方：它不是替你做业务判断，而是帮你把“我怀疑这里有问题”变成可复现、可讨论、可修复的证据。

写 PR：中文、测试计划和 reviewer notes 要变成默认规则

另一类高频任务是提交代码、push 远端、创建或更新 PR。

这件事看起来简单，但如果长期做，你会发现 PR 描述质量很容易漂。有时只有一句标题，有时测试计划漏写，有时 review 关注点没解释清楚。AI 在这里很适合做“格式守门员”。

给 Codex 的 prompt：

提交代码并 push 远端，然后创建到目标分支的 PR。PR 标题和描述必须用中文，先查看仓库 PR 模板，描述里写清楚 Summary、Test Plan 和 Reviewer Notes；如果测试没有执行，说明原因。

我现在给它的默认要求是：

git status --short
git diff --check
git add <files>
git commit -m "fix: 中文描述"
git push -u origin <branch>
gh pr create --base <base> --head <branch> --title "中文标题" --body-file /tmp/pr_body.md

但命令只是表面，真正要写进规则的是：

• PR 标题和描述默认用中文。
• 描述里必须有 Summary、Test Plan、Reviewer Notes。
• 创建 PR 前先看仓库模板，不要自己发明一套格式。
• 有测试没跑通时，要说明原因，是环境缺 token、需要真实第三方服务，还是测试本身失败。

这种规则一旦写进 agent instructions，后面就不用每次提醒。AI 会自动把“代码改完”推进到“PR 可审”。

写飞书文档：先读已有结构，再生成图片，最后检查中文字体

飞书文档是另一个很适合交给 AI 的场景。

有一次我需要写一篇 Search 服务的技术说明，要求参考一篇已有的 Executer 技术文档，并读取某个知识库节点下所有搜索优化相关文档。这个任务如果人工做，最耗时间的不是写字，而是收集上下文、整理结构、生成图、插图、检查链接。

给 Codex 的 prompt：

参照已有技术文档的结构，读取指定知识库节点下的相关文档，生成一篇新的 Search 技术交接文档。需要包含总体架构、请求链路、代码结构、现状问题、优化规划和新人交接清单；图片必须是 PNG，中文不能乱码。

AI 的做法是先用 lark-cli docs +fetch 读取参考文档结构，再读取目标节点下所有相关文档，然后把内容整理成：

• 服务在系统中的位置
• 请求链路
• 核心代码结构
• 数据和索引同步
• 当前问题
• 优化规划
• 新同事交接清单

文档里还需要架构图、请求链路图和路线图。第一次生成图片时，中文出现了乱码。这件事反而让我沉淀出一个很实用的规则：

飞书文档里的图片必须是真正的 PNG；如果图片中有中文，必须使用支持 CJK 的字体，并在本地预览确认没有乱码、截断和低对比度。

后来重绘图片时改用了中文字体，本地预览没问题后再上传替换。这个细节看起来小，但如果文档是给新人交接用的，图片乱码会直接破坏可信度。

查搜索索引：让 AI 做一次完整的“找样本、跑命令、验证结果”

搜索优化里还有一个很典型的工程任务：找一个缺少索引正文或向量字段的样本，测试索引更新命令是否能补齐字段。

这类任务不难，但步骤繁琐：

1. 连接指定数据源。
2. 找出启用状态但索引字段缺失的样本。
3. dry-run 更新索引。
4. 真正更新。
5. 验证字段和更新时间。
6. 再确认同步脚本是否会把变化带到线上。

适合给 AI 的不是“解释一下索引更新怎么做”，而是给出可执行的排查目标。

给 Codex 的 prompt：

使用指定 profile，只读查询一个缺失索引字段的样本，先给 SQL 和候选结果，再 dry-run 更新索引。确认无误后执行更新，并验证 updated_at 是否变化。

这句话里有几个关键限制：指定 profile、先只读、先 dry-run、验证更新时间。它们能防止 AI 直接上来做写操作，也能让最后的结果有证据。

这里还有一个经验：如果只是按某一批工具做局部更新，不应该推进全局水位；更新索引字段时必须同步更新时间，否则后续增量同步可能抓不到变化。这样的规则非常适合写进项目级 instructions。

排查失败的持续集成：把日志变成最小修复路径

还有一类很适合交给 AI 的任务，是排查持续集成失败。

CI 失败通常不是只有一行错误。它会牵扯到 workflow、job、环境变量、依赖缓存、测试夹具、最近提交和已有评论。人工当然也能查，但每次都要打开页面、翻日志、复制命令、定位失败文件，很耗碎片时间。

给 Codex 的 prompt：

这个 GitHub Actions run 失败了。请用 gh 查看失败 job 和日志，定位失败原因，判断是否需要改代码；如果需要修改，直接做最小修复，跑相关测试，并把原因和验证结果用中文说明。

我希望 AI 给出的不是“可能是测试挂了”这种废话，而是完整链路：

• 哪个 workflow、哪个 job、哪一步失败。
• 失败日志里最关键的错误是什么。
• 是否能在本地用更小范围的命令复现。
• 如果要改代码，改动是否足够小。
• 修复后跑了哪些验证。

这样做的好处是，CI 从一个网页上的红叉，变成了一条可以被复核的修复路径。尤其是当 PR 已经有很多文件变更时，AI 能快速把注意力收敛到真正相关的文件和测试上。

接口联调：让 AI 同时准备请求、脚本和验收清单

很多接口联调不是难在写一条 curl，而是难在把“怎么验证它真的可用”说清楚。

比如一个服务需要在局域网里通过 API 访问。我会让 AI 同时做三件事：整理请求示例、写一个最小测试脚本、补一段文档说明。这样后面换人接手时，不需要从聊天记录里翻命令。

给 Codex 的 prompt：

为这个本地服务写一个接口测试脚本，并给出 curl 调用示例。脚本要支持配置服务地址和模型名称，输出响应时间、返回摘要和错误信息；完成后在本地跑一遍，把结果更新到博客文章里。

这个 prompt 里有几个实用点：服务地址和模型名称要可配置，不能写死；输出要包含错误信息，否则失败时没法定位；跑完后要把结果写回文档，避免“脚本有了，但没人知道怎么用”。

类似的场景还包括：给新接口生成 smoke test、给 webhook 写本地回放脚本、给批处理命令补 dry-run 样例、给后台页面补一个最小验收清单。AI 在这些任务里不是替你设计系统，而是把容易遗漏的“最后一公里”补齐。

远程安装服务：把“能跑”推进到 systemd 和验证命令

AI 也很适合做远程机器上的重复运维工作。

比如安装一个兼容 Clash 订阅的代理服务。这个任务看起来像运维，其实也可以拆成非常工程化的链路：

给 Codex 的 prompt：

参照之前在另一台机器上的部署方式，在这台服务器上安装同样的代理服务。需要配置成 systemd 服务、开机运行、局域网可用；敏感配置不要写入公开文档。完成后给出状态检查、日志查看和最小可用性测试命令。

1. 确认机器、系统、架构、端口占用。
2. 配置 SSH 免密。
3. 安装代理软件。
4. 写配置文件。
5. 设置局域网访问。
6. 创建 systemd service。
7. 开机启动。
8. 用日志和 curl --proxy 验证。
9. 更新服务器说明文档。

这里最重要的是敏感信息边界。服务器地址、账号、密码、订阅链接都不应该写进公开文章或 PR。AI 可以在本地命令和远程配置中使用这些信息，但最终沉淀出来的文档应该只保留占位符和操作方法。

我现在对这类任务的要求是：远程安装后必须给出 systemctl status、日志查看命令和最小可用性测试命令。否则“装好了”这句话没有意义。

lark-cli 和 gh：把协作系统接进来

如果只在编辑器里用 AI，它能做的事情会被限制在代码附近。

真正让工作流闭环的是 gh 和 lark-cli。

给 Codex 的 prompt：

写一篇 AI 辅助工作的飞书文档，放到指定知识库节点下。内容包括 lark-cli、gh、Codex、Claude Code、Cursor 等工具在开发中的应用；需要结合真实案例，总结成可以交接给新同事的方法论。

gh 负责把 GitHub 接进来：读 PR、查 comment、看 checks、创建 PR、发 review、看 workflow 失败原因。很多时候 AI 不需要浏览器，只要有 gh，它就能把 GitHub 上的协作上下文拉下来。

lark-cli 负责把飞书接进来：创建文档、读取知识库、插入图片、移动图片块、更新文档内容。只要文档操作可以命令化，AI 就能把“写一份交接文档”从一句话推进到一篇真正可打开的文档。

工具本身不神奇，关键是它们给 AI 提供了行动接口。

我最后沉淀下来的几条规则

这段时间用下来，我觉得最值得写进全局规则的是这几条：

• PR 标题、描述、review comment 默认用中文，并包含 Summary、Test Plan、Reviewer Notes。
• 飞书文档需要图片时，生成真正的 PNG；图片中文字必须使用中文字体并本地预览。
• 涉及内部系统、远程机器、代理订阅、密码、token 时，只在本地命令和远程配置中使用，不写入公开文档或 PR。
• 高风险写操作必须先给 dry-run、候选清单和回滚策略。
• 远程安装服务后必须配置 systemd、开机启动、日志查看命令和最小可用性测试命令。
• AI 完成任务后必须给出验证证据：测试结果、服务状态、接口返回、PR 链接或文档链接。

这些规则看起来不像“AI prompt 技巧”，更像工程纪律。但越是把 AI 用到真实工作里，越会发现工程纪律比花哨 prompt 更重要。

真正的变化：工作从“问答”变成“委派”

以前我对 AI 的使用更像问答：解释一段代码、帮我写个函数、给个方案。

现在越来越像委派：这是目标，这是仓库，这是约束，这是不能碰的边界。你去读上下文，执行必要命令，做最小修改，跑测试，给我结果和证据。

这两者差别很大。

问答只需要回答得像样。委派要求它真的把事做完，而且做完后经得起检查。也正因为如此，AI 辅助工作的核心不只是模型能力，而是上下文、工具、权限、验证和沉淀。

当这些东西接起来之后，AI 就不只是聊天框了。它会变成一个能进入工程现场、能留下证据、能把零碎工作推进到交付状态的助手。

当然，人仍然要决定目标、边界和最终责任。AI 能帮我们少做很多重复劳动，但不应该替我们承担判断。

这可能也是我现在最愿意接受的一种 AI 工作方式：不是把人从工作里拿掉，而是把人从大量低价值的衔接动作里解放出来。