我的 AI Coding 工作流：Claude Code、Codex 与 Skill

我早期使用 AI 编码工具时，最常见的方式是复制一段需求，请模型直接生成页面或函数。短任务看起来很快，但代码一旦进入真实项目，模型不了解目录约束、历史决策和测试方式，后续修正成本可能比手写更高。随着使用次数增加，我逐步把 AI Coding 从“生成代码”调整为一条可验证的协作流程。

本文以 2025 年 11 月 25 日的一次本地工作流代理探索作为时间起点，整理我现在常用的方法。它是个人经验复盘，不是公开项目的性能报告，也不会把未公开工具描述成已经被外部验证的产品。

先准备上下文，再开始对话

我通常先确认任务的真实边界：用户要解决什么问题，哪些文件属于当前范围，现有行为如何验证，是否存在未提交修改。对于陌生仓库，我会先让工具读取入口、数据结构、测试和最近提交，再讨论方案。缺少这一步时，模型很容易根据文件名猜测；有了当前代码和可复现现象，建议才有工程意义。

上下文也不是越多越好。我更倾向提供与当前决策直接相关的文件，并明确哪些是事实、哪些是推测。遇到截图、README 或设计文档中的完成声明，还要回到代码、测试或运行结果核对。这个习惯能够降低“模型沿着错误前提写得很完整”的风险。

我会把任务拆成分析、设计、实现和验证几个阶段。分析阶段找根因和影响范围；设计阶段确认数据流和边界；实现阶段尽量保持改动小而集中；验证阶段运行类型检查、测试、构建或浏览器操作。每个阶段都有可观察产物，而不是一次对话直接跨到“已经完成”。

这并不意味着所有小修改都需要长文档。简单文案可以直接改，但仍应检查实际页面；复杂功能才需要规格和计划。所谓 Vibe Coding 对我而言不是放弃理解，而是让模型承担搜索、机械实现和候选方案生成，我仍负责目标、取舍与最终验收。

Claude Code 和 Codex 是我主要使用的工具。它们都能读取仓库、执行命令和修改文件，适合持续跟进一个任务。我会根据当时的上下文、工具能力和验证需求选择，而不是把某个模型当作固定答案。Cursor 使用过，但更多是编辑器中的辅助体验，不是当前主要工作流。

模型给出的代码不会因为来自更强工具就自动可信。我会查看 diff，确认没有误删用户修改；涉及 Git、部署、密钥和外部写入时，权限必须单独判断；测试通过也要核对测试是否覆盖了用户真正要求的结果。Code Review 阶段更关注边界条件、事实依据和回归范围，而不仅是格式。

重复任务中，单靠每次临时提示很难保持一致。我尝试把稳定的流程写成 Agent Skill：明确什么时候触发、需要读取哪些资料、允许调用什么工具、何时必须暂停，以及最后怎样验证。Skill 的价值不是保存一段万能 Prompt，而是把操作约束和质量门槛变成可复用说明。

我也逐渐意识到，Skill 不能只写“生成一份报告”或“修复问题”。它需要定义输入缺失时怎么办、私有信息如何处理、哪些动作需要授权、输出由什么证据支持。为 Skill 配套验证脚本或固定检查项，比继续增加描述性形容词更有效。

为了理解浏览器、桌面应用与本地 AI CLI 的协作方式，我尝试过本地命令代理和 Electron 控制台。探索重点包括仅监听本机地址、命令白名单、工作目录白名单、可选令牌、任务状态和日志。这里使用“尝试”是有意的：相关仓库没有公开，本文也不声称它们具备生产部署、多人隔离或稳定运行指标。

这类代理的风险非常直接。只要浏览器可以传入任意命令或目录，它就可能越过项目边界。因此默认拒绝、最小授权、明确工作目录和可停止任务，比界面是否炫酷重要。即便模型建议执行命令，真正的执行权仍应由受控工具和用户确认决定。

现在我更看重的闭环是：先建立事实上下文，再让 AI 提出方案；用小步修改降低偏差；通过测试、构建和真实页面验证；最后检查 diff 和交付边界。AI 提高了探索速度，也让我可以独立覆盖更多前后端环节，但它没有替代工程判断。

公开说明：本文涉及的本地工作流仓库尚未公开，相关细节属于个人实验和方法总结，不能由公开代码独立验证，也不应被理解为成熟产品成果。可以从我的 GitHub 主页查看目前公开的其他实践。