← Back to blog

给 AI 最大的执行权限，但把爆炸半径压到最小：我在 Startup 落地 Coding 工作流的半年迭代

AIAgentClaude Code工程实践开发工具
Table of contents

封面：Agent 不是用来管的，是用来防爆的

距离上次介绍我的 coding 研发工作流已经过去四个月了，我的这套工作流在这段时间也做了一些调整。我觉得是挺方便的一套工作流，总结如下，大家可以拿去让 AI 开箱即用。

1. 我的常用 Agent + Skill + MCP

在 coding 这个场景下，Agent 我几乎只用 Claude Code，很少会用其他的 Agent。Claude 模型也是我日常使用的主力，毕竟 GPT 的防御性编程懂的都懂，其他家的 coding 能力又和 Claude 有着很明显的差距。

实测下来国模的 DS-4.1、GLM-5.3 的非 flash 模型基本也到 coding 场景可用的程度了，但我用这些模型更多的是为了测试国模能力，依旧不推荐使用在生产环境中。

生产环境还是推荐使用 SOTA（Fable）或者是次优、但是也足够省心的模型（Opus 5.5），相信我，省下来的这些沟通、修补、重做的时间绝对值得多花的这些钱。

Fable 给我的感觉依旧是无人能超越，Opus 在上限方面会比较小，但是泛化和发散性能力已经足够，很少有我需要擦屁股的情况。

这几个月试过很多 Skill，基本比较热门的都有过尝试，比如 superpower、ce 等等，之前 ce 用过很长一段时间，也是一个大力推荐的 skill。

在 Claude 模型来到五时代之后，我根据 Anthropic 的工程实践，把全局配置、记忆，以及项目级别的 Context 进行了一波压缩，同时也丢弃了很多不用的 MCP 和 Skill。我现在几乎只用 matt 这一个 skill，它的作用主要有两个：

  • 问清楚一些边界问题以及我没有考虑到的事项，把这些都讨论敲定，减少落地跑偏的可能性，增强 Human 对项目的掌控程度；

  • 把以上这些问题答案沉淀到 spec 文档中供 Agent 参考，并且大任务可以通过持久化文件的方式进行状态维护，方便大任务跨 session 推进。

MCP 更多的是因人而异，我接入了我们平台的 MCP 以及公司项目管理工具的一些 MCP，比如 Lark 用于读各种项目文档、meegle 跟踪需求单等等。

2. 物理隔离

只要是改动代码的需求，第一步永远是拉最新的代码 + 开一个独立的 git worktree，绝不在主 IDE 工作区直接改。

很多团队用 AI 容易把本地环境改乱，核心是忽视了并发。在真实的生产节奏里，我经常同时派发两到三到六个 Agent 并行开工。如果全挤在同一个本地目录，依赖安装、分支切换和未提交的修改瞬间就会有并发冲突。

我们的做法是：

  1. 统一将工作区隔离到 /private/tmp/<project>-<feature> 下的独立临时路径；

  2. 主 IDE 工作区永远停留在干净的主集成分支上，用于全局代码检索与最终效果核对；

  3. Agent 拥有自己独立的依赖树和 git 索引，一旦写偏了、思路发散或者把底层搞炸了，直接把临时 worktree rm -rf 删掉，两秒就能重置，彻底消除了对 Agent 改坏本地代码的心智负担。

3. 计划先行

拿到稍大一点的需求，千万别让它直接开始改文件，大概率改到第三个文件时就会把架构逻辑写崩。

必须强制它在动代码前给出一份完整的 Plan：

  1. 核心目的与影响面：改动涉及哪些下游模块、触碰哪些数据库字段、对外接口契约有没有破坏性变更；

  2. 改动文件清单：精确列出准备新增、修改哪些文件，不在计划内的代码一行都不准碰；

  3. 边界与测试方案：正常流程怎么走、极端异常怎么兜底、单元测试准备怎么写。

  4. 如果是跨天或工作量庞大的大需求，建议必须加上状态持久化文件（比如 process.md / task.md）。把整个任务拆成几个明确的 Checkpoint，每完成一步勾选一步。这样哪怕中途上下文超限、或者切换不同 Agent 协作，新的 session 读一眼这个状态文件就能瞬间完成无缝热启动，继续推进。把精力花在前 5 分钟审计划上，能省掉后面两个小时无休止的返工纠偏。

4. 终极测试分工

在测试这一步，很多人的做法是完全错误的：让 AI 写完代码，自己打开 Postman 或者控制台手动去点、去拼参数，这等于把人变成了 AI 的廉价人肉测试机。

在我们的流程里，人机分工有着非常清晰的边界：人类只负责校验最终的业务效果，AI 的目标则是直接做到对应环境的完整测试。

比如我让 Agent 新增了一个业务接口，标准工作流是：

  1. 代码提交并自动部署到 DEV 联调环境，把 DEV 环境的登录态和 API 调用权限直接交给它；

  2. 它必须在 DEV 环境独立完成完整的闭环测试。既要把输入合法参数的正常业务逻辑跑通（数据落库、返回值结构正确）；更要把各种异常情况全部跑通（传非法参数、缺失认证 token、并发竞争冲突、模拟超时返回预期的 4xx/5xx）；

  3. 正反两面的测试用例全部自测通过、断言全绿，才算完成了 AI 维度的代码交付。

到了这一步，作为人类工程师，我只需要去实际体验一下页面功能有没有达到预期效果即可，脏活累活全部在环境里被 AI 自动化消化掉了。

5. 规范化出栈

很多小团队觉得分支管理麻烦，喜欢直接把改动 push 到集成分支。但在 AI 时代，PR（Pull Request）是人机之间最重要的一道安全防火墙。

我们的分支与出栈规范是这样的：

  • 分支隔离：任何改动必须在独立 feature 分支开发，禁止直接向共享集成分支推送；

  • 双语规范：通过 gh pr create 自动提 PR，Title 强制采用英文 Conventional Commit（便于自动化构建 CHANGELOG），正文用中文清晰阐述修改动机、改动范围与验证证据，严禁把代码 diff 机械复制到正文；

  • AI 对抗性 Review：配置了 chatgpt-codex-connector 作为 Reviewer，只有 gpt 挑不出任何毛病之后才允许合入 PR 并 Deploy，这也是我最推荐的 AI Review 方式。gpt 这德性就很适合做对抗性 review，经常有一些大合入会在 review 阶段卡 20、30 轮，把这些代码层面的隐患解决完；

  • CI 巡检自闭环：PR 创建后，GitHub Actions 自动跑 Lint、静态类型检查、单元测试和镜像构建。如果 CI 红了，人类不需要去翻报错，直接让 Agent 调 API 读取 Actions 日志自己定位堆栈、自己打补丁提交，直到所有 required checks 全绿；

  • 防污染拦截：合并 PR 前，必须自动核对本次合并是否意外夹带了其他同事尚未发布的提交，守住干净集成分支的底线。

6. 极速回退防线

很多团队上线慢，是因为每次发版都提心吊胆，花几个小时在各项结果校验上。我们的原则是：因为没有时间花在繁重的线上结果校验上，所以必须把精力放在保证线上能极速回退。

代码合入并不是终点，我们通过 PostHog 这种 A、B 工具搭了一套秒级开关体系：

  • 核心功能或改动较大的逻辑，代码里必须默认包裹 PostHog Feature Flag（特性开关）；

  • 自动发布上线后，默认并不直接全量暴露，或者随时保持开关可控状态；

  • 一旦线上发生任何未预期的异常波动、或者真实用户反馈出现偏差，根本不需要走繁琐的代码回滚、等流水线重新打包发布的传统链路（那个流程至少耗时 10 到 30 分钟，业务早就炸穿了）；

  • 直接在 PostHog 后台把对应 Flag 一键关掉，1 到 2 分钟内线上立刻回退止血。

先保证线上有随时秒级刹车的能力，把爆炸半径压到最小，我们才敢真正放手让 Agent 高速迭代。

7. 生产守门员：定期跑部署看板与全量日志巡检

每次合并代码到 Prod 生产环境，我都有一套雷打不动的固定动作：跑一次自建的部署看板（Deployment Board）。

这个看板主要承担两个核心使命：

  1. 版本绝对透视：一屏看清每个环境当前运行的镜像 SHA 和代码版本，彻底杜绝「以为已经发布了，但线上其实还在跑半个月前老版本」的幽灵问题；

  2. 全量日志异常巡检：它会穿透拉取所有环境全部服务的最新业务日志，自动过滤、聚类并抓出所有隐藏的 Error 级别报错。

这里分享一个我们真实的血泪事故：之前有一位同事在本地写完了改动，自测没问题，但由于某个配置没对齐，其实服务在后台已经在疯狂报错了。但因为前端没有直接崩掉，谁都没有察觉，等我们后来排查时发现，线上堆积的 error 日志其实已经高达几十万条了。

从那之后，每次发布前后跑部署看板、自动巡检全量服务日志就成了硬性制度。只有确认最近五分钟没有新增的未捕获 Traceback 和 5xx，线上才算真正通过验收。

8. 文档工程化：三层编排体系是唯一的长期记忆

Agent 本质上是无状态的，如果你不把规则沉淀下来，它换一个 session 依然会犯同样的错。在团队里，骂模型蠢没有任何意义，必须把文档当成代码库来治理，而且文档一定是最重要的代码。

我们的文档编排结构非常清晰地分为三层：

  • 第一层：项目根目录入口（CLAUDE.md / AGENTS.md）：存放每个项目唯一的顶层工程约定。比如启动和测试命令、Dev/Prod 真实环境地址、特殊的跨服务鉴权逻辑、以及绝对不能踩的红线规约；

  • 第二层：规则与踩坑经验库（memories/ 或 docs/rules/）：按领域分层归档（如 engineering/ 记录工程实践、infra/ 记录云原生运维）。专门沉淀历史踩坑复盘（比如哪个命名空间是废弃的、哪个第三方库在异步下有死锁隐患），每一条必须用一句精准的索引钩子命名，并且一定要和代码足够近；

  • 第三层：任务级需求规约与状态文件（specs/ 与 process.md）：大型改动敲定后的 PRD、接口定义与 Checkpoint 进度追踪，落盘在本地随 Git 跟踪。

把踩过的每一个坑写成规则，换个仓库、换个会话，同样的经验自动继承。

当你建立起了一套由 Worktree 隔离、计划对齐、环境级自测试、CI 严密防线、PostHog 秒切回退、部署看板日志兜底、三层文档记忆 构成的坚固防线之后，把繁重的试错和测试交给 Agent，人类工程师只站在最后一道关口做决策与验收。这才是生产级 AI 开发真正的自由度。

← Back to blog