最近一年我几乎每天都在跟 Claude Code 打交道。从最早把它当成一个“高级代码问答机”一条命令跑进终端把需求往命令行里一贴等着它给我吐代码再手动复制回文件里到后来逐步把 Skills 和 MCP 引进来现在我更像是在带一个能自己动手、有记忆、会调用工具的“虚拟开发同事”。这篇内容不是什么官方教程而是我把 Claude Code 从“裸用”状态慢慢打磨成一套工程化 AI 开发工作流的真实记录。如果你也写过几次“一次性 Prompt”、被反复重复的上下文搞得心烦、或者希望 AI 不只是写代码、还能真的融入项目工具链里那这篇文章应该能给你一点可复制的经验。先快速交代一下背景我主要是做前端方向的工程开发但也兼顾自动化脚本、文档生成、日常脚本编写这类杂活。Claude Code 是我主力使用的终端 AI 编程工具配合 VS Code 使用MCP 我接入了文件系统、浏览器自动化、数据库查询、本地模型推理等几类服务Skills 则主要沉淀了代码审查、组件生成、提交信息规范化、依赖升级等高频动作。下面我按“为什么改造 → Skills 怎么做 → MCP 怎么接 → 完整工作台怎么搭 → 多 AI 协作和踩坑”这个脉络来讲最后附一份我整理的排查速查表。1. 从“裸用”到工程化我经历了什么1.1 裸用阶段一条命令走天下的日子最早使用 Claude Code 的阶段我的姿势非常原始打开终端输入claude进入交互模式然后把需求像写周报一样描述一遍。比如“帮我看看src/components/Button.jsx把它改成支持多种尺寸和 variant样式用 CSS Modules记得兼容现有用法”。Claude Code 确实能改改完还能跑测试。但问题随着项目变大逐渐暴露出来。第一个痛点是上下文反复“冷启动”。每次会话都要重新描述项目结构、设计规范、代码风格、不能用哪些依赖、路由怎么组织。今天讲一遍明天它照样忘记。哪怕我把要求写在CLAUDE.md里提示词还是越来越长动不动就把对话窗口塞满。第二个痛点是“没有肌肉记忆”。同样类型的组件它今天写一套结构、明天写另一套只有我盯着 Review 才不会被带偏。第三个痛点是它“没有手”没法主动去查接口文档、看数据库表结构、调浏览器验证页面表现所有需要外部信息的操作都得我手动复制粘贴喂给它。用一句话概括就是它像一位记忆极差、但单次任务能力很不错的实习生每次合作都要重新认识一遍项目。后来我统计了一下一个月下来大量 token 都花在了重复描述和来回纠正上真正花在“解决问题”上的反而不多。这个阶段让我确信光靠把提示词写得更长更细是不够的必须给工具本身增加“记忆层”和“工具层”。1.2 为什么我最终选择 Skills MCP 的组合在尝试了各种“人肉工程化”之后我最后留下来的核心组合是两个Skills 和 MCP。这俩不是同一个层面的东西但组合起来非常互补。Skills 解决的是“怎么把经验变成可复用的操作规范”。你可以把它理解成一份给 AI 看的 SOP标准作业程序当某个条件满足时自动加载对应的工作流程和约束。以前我需要花大量 token 告诉它“按我这个规范来”现在只需要在SKILL.md里定义好规范它遇到同类任务就会自动按这个流程执行。这相当于给 AI 装上了长期记忆和条件反射。MCP 解决的是“怎么让 AI 真正操作工具”。全称是 Model Context Protocol一个标准化的 Agent 工具接入协议。你可以把它理解为 AI 界的 USB-C以前每个工具都要单独写适配器现在只要暴露成 MCP ServerClaude Code 就能直接调用。文件读写、浏览器控制、数据库查询、Git 操作都能变成一种可被 AI 自然语言触发的工具。用个生活化的类比Skills 是你给新同事的那本“部门工作手册”里面写清楚什么情况走什么流程、交付标准是什么MCP 是这位同事的“OA 账号和权限”让他能真的去系统里查数据、发审批、改文档。没有 Skills他每次做事都问你要手册没有 MCP他即使知道该干什么也碰不到任何系统。两样都装上之后他才算一个能独立干活的人。2. Skills最被低估的 AI 工作流资产2.1 一次说清 Skills 和 Prompt 的边界很多刚接触 Claude Code 的同学容易把 Skills 理解成“一个特别长的 Prompt”其实两者的差别非常大。Prompt 是每次都会跟着对话上下文走的消耗 token、占据 context、并且如果想要改规则你得去改每一条历史消息里的提示词非常容易失效。而 Skills 是存放在本地目录里的结构化指令文件Claude Code 会根据用户请求和description里面的关键词动态决定要不要加载。也就是说平时它完全不占上下文只有触发时才“入场”。一个标准的 Skill 目录通常是这样的~/.claude/skills/ └── code-review/ ├── SKILL.md └── templates/ └── review_report.mdSKILL.md是核心开头有一段 YAML front matter定义技能的名称和描述。下面是示例--- name: code-review description: 对一段代码或一次 MR 变更进行系统审查检查正确性、安全性、性能与可维护性并输出结构化报告。适合在用户要求“审查代码”“review”“帮我看看这段代码有没有问题”时使用。 --- # Code Review Skill ## 执行步骤 1. 先阅读变更文件列表确认改动范围。 2. 按正确性、安全性、性能、可维护性四个维度逐个检查。 3. 每个问题必须给出问题位置、风险等级、修改建议。 ## 硬性约束 - 不要为了提问题而提问题没有实际影响的问题不要写进报告。 - 涉及安全风险如注入、越权、敏感信息泄露时必须高优先级标注。 - 输出中文报告按“P0/P1/P2”分级。 ## 附带资源 - 审查模板见 ./templates/review_report.md关键点在于description写得好不好直接决定 AI 在什么场景下会调用这个 skill。描述里要多写触发词和适用条件不要写成一堆抽象口号。比如“审查代码”就比“提升代码质量”更容易触发。从实际使用体验来看Skill 和 Prompt 还有一个很微妙的正反馈一旦把经验沉淀成 Skill我会更愿意继续优化它。以前改 Prompt 觉得是在给“一次性任务”打补丁现在改 Skill 是在维护“长期资产”心态完全不同。2.2 亲手开发一个高价值 Skill前端组件脚手架我开发的第一个实战 Skill 是“前端组件脚手架生成器”。起因非常简单写组件这事本身不难但团队内部有很多隐式约束——组件目录必须遵守index.ts、types.ts、hooks.ts的拆分习惯样式文件优先用 CSS Modules涉及业务数据的组件禁止直接发请求必须走数据层。这些约束已经存在很久了但每次让 Claude Code 写组件都像开盲盒。我的思路是让 AI 在生成组件前先按照一套“检查清单”逐步执行而不是直接甩出代码。于是我在.claude/skills/component-builder/下创建了SKILL.md里面定义了以下步骤--- name: component-builder description: 根据需求创建前端组件自动生成目录结构、类型定义、样式文件和 Story 文件。适合用户要求“新建组件”“写一个 xxx 组件”“封装 xxx UI”等场景。 --- # Component Builder Skill ## 第一步需求澄清 - 确认组件名、props 类型、依赖的数据源、是否接入路由。 - 如果用户没有给出设计稿先输出一份组件 API 草案让用户确认。 ## 第二步目录生成 - 在 src/components/{组件名}/ 下生成 index.ts、types.ts、hooks.ts、styles.module.css - 每个文件的代码职责必须单一禁止把类型定义放到 props.ts 之外。 ## 第三步代码生成 - 类型定义必须优先于组件实现。 - 组件体只保留 UI 渲染逻辑业务请求通过 hooks.ts 暴露。 - 样式类名使用 BEM-like 规则前缀为 {组件名小写}。 ## 第四步自检 - 检查是否遗漏 props 默认值。 - 检查是否有未清理的 console.log。 - 检查是否可以直接播放 Storybook 演示。这实际上等于把团队约定内化成了 AI 的“本能”。后续我再让 Claude Code 写组件时它不再直接输出一坨代码而是先问我几个关键澄清问题然后按清单一步步产出文件结构、命名风格、职责划分都能维持一致。这个 Skill 用了大概两个星期我就明显感觉到“外部 Review 负担”变小了。还有一点很重要Skill 是可以演进维护的。我把每次 Review 中发现的高频问题不断追加到“硬性约束”里。比如后来增加了“禁止在组件中直接操作 window 对象必须通过 useEffect 包裹”“日期格式化统一使用 dayjs不要用原生 Date 拼字符串”。经过几轮更新这个 Skill 已经从最初的十几个规则变成了一份带着我们团队现场经验的“活规范”。2.3 前端开发里推荐沉淀的 Skills 清单除了组件生成我陆陆续续沉淀了一批觉得“投资回报率”很高的 Skills这里整理出来给大家参考Skill 名称适用场景核心约束 / 输出code-review审查 MR、审查单文件、审查整体变更按正确性/安全/性能/可维护性四维输出问题分级 P0/P1/P2commit-message生成符合规范的 Git 提交信息读取 git diff 前缀输出 Conventional Commits 格式类型限 feat/fix/docs/refactor/test/choredependency-audit评估依赖升级影响面先对比 changelog再检查破坏性变更最后给出升级建议清单test-generator为组件或工具函数生成测试用例列出边界条件与异常情况优先使用 vitest 和 testing-library 语法docs-writer生成 API 文档 / README / CHANGELOG保留代码注释中的英文术语结构必须包含示例代码和注意事项这些 Skill 的共同特点是输出格式稳定、执行步骤清晰、评价标准明确。它们不追求全面而是聚焦“重复度高的动作”。我在实际工作中大概把日常 70% 以上“让 AI 做需要稳定格式的事”都转化成了 Skill。你在自己的项目里也完全可以定义一套符合团队文化的版本刚开始可以从 commit-message 这种“小但高频”的做起反馈周期短很容易坚持。3. MCP让 Agent 长出“手”3.1 MCP 协议到底解决了什么问题在 MCP 普及之前让 AI 调用外部工具通常有两种做法一种是把工具能力写进 Prompt 里然后靠 AI“假装调用”、由外层脚本解析并执行这种方式耦合重、容易出错另一种是给每个工具单独写插件代码比如某编辑器插件、某 CLI 插件的集成函数各玩各的无法复用。MCP 出现后统一了“模型上下文”与“外部工具”之间的通讯协议AI 通过标准接口去发现工具、读取资源、发起调用每个工具以 MCP Server 的形式提供服务模型侧只需要接入一个兼容客户端。这里可以继续用“USB-C”的类比以前接一个外设就要一根专用线如今所有设备都用同一个标准接口插上就能用。MCP Server 就像一个个自带接口的设备Claude Code 相当于支持这个接口的电脑主机。不需要在项目代码里写死某个工具的调用逻辑也不用纠结不同工具官方的 SDK 差异统一走协议就能通信。当然MCP 不是银弹它解决的问题主要是“接入标准化”和“工具发现”。真正要落地出效果还是得看你在实际项目里接了什么 Server、怎么配置权限、怎么设计工具边界。下面讲讲我实际接入过的几类服务。3.2 实战接入filesystem、database、browser 等工具我在 Claude Code 里的 MCP 配置主要分成三类本地文件与命令类、数据查询类、浏览器自动化类。下面是本地文件系统的配置片段{ mcpServers: { filesystem: { command: npx, args: [ -y, modelcontextprotocol/server-filesystem, /home/me/projects/frontend-app/src, /home/me/projects/frontend-app/docs ] }, playwright: { command: npx, args: [ -y, playwright/mcplatest ], env: { HEADLESS: true } }, sqlite-db: { command: npx, args: [ -y, mcp-server-sqlite, --db-path, /home/me/projects/frontend-app/data/dev.db ] } } }文件系统 Server 给 AI 提供了精确到目录的文件读写能力。它和直接在终端里用 Claude Code 的区别是我可以精确地告诉它“只允许访问 src 和 docs 目录”避免 AI 乱翻整个项目也降低误操作风险。配合前端开发时我经常让它直接去读某个组件目录下的所有文件再按规范生成新的相似组件。Playwright MCP 我主要用于“看真实运行效果”。以前让 AI 改一个页面样式它只能靠 CSS 推断效果现在它可以启动一个浏览器、打开本地开发服务器、实际截图给我看。遇到响应式布局问题我甚至会直接让它切到手机尺寸再逐屏截图。浏览器自动化给前端 Agent 补上了最关键的“视觉验证”闭环。数据库类 MCP 的价值主要在于“用事实说话”。当 AI 需要判断某个接口里的 SQL 是否有问题、或者某个列表查询为什么慢时它可以直接查表结构、看数据分布、甚至跑几条只读 SQL而不是凭空猜。我也会限制它只能连接测试库生产库绝对不能暴露给 Agent这属于底线问题。这里分享一个复用水平更高的经验不要把 MCP Server 停在“和 Claude Code 绑死”的状态及时更新~/.claude.json里的配置说明。因为我发现当工具越来越多时AI 反而会犯选择困难。我会在每个 MCP Server 的描述里写清楚“这个工具适合什么场景、禁止拿来做什么”比如对 database 类的工具注明“只读查询禁止执行 INSERT/UPDATE/DELETE”。这些说明在 Claude Code 的 MCP 信息栏里是可见的能显著减少误用概率。3.3 本地模型与外部服务的接入路径我身边很多小伙伴也在尝试把大模型部署到本地再接入 Claude Code。实现方式比想象中简单本地推理服务如果提供 OpenAI 兼容的 HTTP API你就可以用支持 OpenAI 协议的服务作为模型 Provider 来接入也可以考虑把本地模型包装成一个 MCP Server 来供调用。用 MCP 桥接的好处是主 Agent 依然使用 Claude 系列模型来进行规划与理解而一些成本敏感或隐私敏感的任务如大量代码片段分析、日志语义解析可以路由给本地模型去那边处理两边通过 MCP 协同兼顾效果与成本。不过我得提醒一句本地模型的能力上限和云端前沿模型还是有差距的尤其在复杂多步推理上容易掉链子。建议先从“分块总结”“文本分类”“简单信息抽取”这类任务入手不要一上来就让它主导整个工程级重构。等摸清了它的脾气再逐步扩大任务边界。另外MCP 生态并不仅限前端相关工具。我看到社区里还有游戏开发、芯片设计、EDA 甚至音视频处理领域的 MCP Server 出现。这说明 MCP 正在成为一个跨行业的“软件与 AI 协作总线”。如果你有特殊工具需要接入不妨先搜一下社区里有没有现成 Server没有的话也可以照着 MCP 规范封装一个成本比想象中低。4. 完整落地的“AI 开发工作台”方案4.1 我的工作流五阶段管道把 Skills 和 MCP 都接进去之后我日常开发不再是一个个零散的“提问-回答”循环而是一条比较稳定的五阶段管道。第一阶段是需求澄清。我会先跟 Claude Code 用自然语言对话把最终目标、约束条件、验收标准聊清楚。这个阶段通常会触发 component-builder 这类需要需求澄清的 Skill让 AI 先输出一个“需求理解摘要”给我确认。确认后第二阶段是任务规划。AI 会把一个较大的需求拆成若干子任务比如“改类型定义 → 写 hooks → 写组件 → 写 Story → 跑测试”每步都对应明确的产出物。第三阶段是技能执行。涉及重复动作时它会调用相关 Skill如果需要读取文件或跑外部命令就会走 MCP 工具。第四阶段是工具验证比如跑vitest、eslint、tsc --noEmit以及必要时的浏览器截图验证。最后第五阶段是人工 Review我只看 Checklist、关键 diff 和测试结果不再逐行盯代码。这个流程看上去不惊艳但实际效果非常明显一次性通过率大幅提升AI 生成的代码很少再出现“格式漂移”。它背后有一个很重要的原则先让 AI 输入大量“业务上下文”之前先“加载规范”再做“工具操作”最后才是“输出交付物”。这个顺序反了效果会大打折扣。如果一上来就让它写代码很可能跳过了很多隐性约束返工成本更高。4.2 在 VS Code 中的配置实战我的主力环境是终端 VS Code。Claude Code 官方提供了 VS Code 扩展安装后可以直接在侧边栏里对话也能让你选中的代码片段快速喂给 AI。我更习惯用终端版跑完整流程但会在 VS Code 里配置扩展主要是为了两件事一是查看 MCP Server 的运行状态和工具列表二是快速把当前打开文件作为上下文传给终端里的 Claude Code。配置时重点关注三个文件。第一个是项目根目录下的CLAUDE.md用来描述项目全局约定包括技术栈、目录结构、测试命令、常见注意事项。第二个是.claude/settings.json用来控制权限和默认行为。第三个是用户级配置文件~/.claude.json用来存放 MCP 服务器等全局配置。我的.claude/settings.json大致长这样{ permissions: { allow: [ Read, Glob, Grep, RunCommand ], deny: [ Write ], ask: [ Edit, Bash ] }, model: claude-sonnet-4-20250514, skills: { enabled: true } }值得说明的是permissions的设定逻辑我默认允许 AI 做阅读理解类操作允许跑一些特定命令对于文件写入和任意 Bash 命令先弹出来问我。写文件这件事最危险我默认禁止只有在明确需要它改多个文件时才临时放开并且只放开某几个目录。这样既可以享受 AI 自动改代码的便利又不至于被一把梭式操作带进沟里。此外我还会在CLAUDE.md里加上一句提示如果要做超过 5 个文件的修改必须先把改动计划列成清单给用户确认后再动手。这句简单的指令减少了大量“AI 自作主张改一堆文件”的惨案。配置完之后还要留意版本更新Claude Code 本身更新频率不低MCP 和相关 Skills 的兼容性也需要偶尔顺手看一眼。4.3 参数、权限和上下文管理很多使用者只关注“模型选哪个”“温度调多少”却忽略了更关键的两个变量权限边界和上下文清理策略。先讲上下文。Claude Code 和 ChatGPT 这类工具不同它默认能看到整个项目目录所以上下文消耗非常快。如果带着一大堆无关文件聊了一天后半程模型的判断力会明显下降。我的习惯是一个任务一个会话任务完成后用/clear清理上下文只把最终结论记到项目 CHANGELOG 或自己的笔记里。需要长期保持的信息比如“这个项目的测试命令是 pnpm test”“接口文档在 docs/api.md 里”写进CLAUDE.md比每次对话开头重新解释更可靠。再讲权限。permissions的力度要比你想象的更保守。“allow”列表写得太宽等于把钥匙全交给 AI“deny”列表其实是安全兜底。我在真实项目里踩到过 AI 误删了一个本不该删的目录的标签文件虽然最后通过 Git 恢复了但那种心跳加速的感觉不想再来一次。从那以后我把所有可能造成破坏的动作都放到了ask宁多问一次也不让它冲。最后讲模型选择。工程化工作流中模型的稳定性比单次跑分更重要。同一套 Skills 和 MCP在推理能力强的模型上表现很好在弱一点的模型上可能连调用格式都会错。所以我通常对于规划、重构这类复杂任务用能力更强的模型对于简单分类、信息抽取则可以用配置里的低成本模型。Claude Code 支持在配置里指定模型也可以在会话中用/model快捷切换。5. 多 AI 协作与翻车现场实录5.1 多 AI 角色分工规划者、执行者、审查者工程化到一定程度后我开始尝试“多 AI 协作”也就是让不同 Agent 实例承担不同角色。因为我注意到把一个又长又复杂的任务全塞给同一个 Agent它会在“规划”和“执行”两个状态之间反复横跳效率并不高。我现在常开的三个角色是规划者、执行者和审查者。规划者 Agent 读取需求文档和仓库结构产出任务拆解清单执行者 Agent 按照清单逐个完成代码改动过程中会调用 Skills 和 MCP 工具审查者 Agent 对执行者的 diff 进行 code review输出问题和建议。三者使用同一套 Skills 和 MCP 服务但会话是完全独立的所以在某一步出错时不会污染其他角色的状态。听起来很美好实际有两个前提。前提一是“分工边界要清晰”。执行者拿到清单后只允许修改清单里点名的文件不得顺手重构其他代码审查者只负责发现问题不负责修改。AI 特别容易越界所以你必须在 Skill 描述里写死职责边界。前提二是“交接物要结构化”。规划者输出的不是一段模糊描述而是一个 markdown 清单每项包含任务 ID、涉及文件、验收标准、关联 Skill执行者完成一项后也要更新该项状态。这样才能避免“上下文丢失”和“信息重复传递”。5.2 我亲历的几个典型事故与排查思路这里必须泼一盆冷水多 AI 协作绝不是把任务丢过去就万事大吉。我至少遇到三类典型事故。第一类是执行死循环。执行者 Agent 在跑测试时发现某个用例失败于是自动修改代码结果又引发另一个用例失败接着再改陷入循环。直到我一眼看到终端上刷屏的提交记录才反应过来。这个问题通常出在“自动执行开关开得太宽松”上。解决方式是给执行者加一条硬规则如果连续两次修改仍无法通过同一个测试停止自动修复必须请求人工介入。这相当于给 Agent 画了一个“止损线”。第二类是上下文爆炸。三个角色共用工作区时互相之间的交接文档越写越长到后来甚至超过了模型有效上下文窗口。现象就是 Agent 开始“遗忘”早期约定执行者会问规划者已经回答过的问题。排查后发现是交接物里塞了太多原始日志和完整文件内容正确做法是只放“摘要 指向文件的路径”细节由工具按需读取别把东西一股脑全塞进上下文。第三类是权限误操作。有一次我审批了一个 Git 操作请求结果 AI 连续执行了git push --force和分支删除差点把远程主干搞坏。原因是ask弹窗里的命令默认带上了--force参数而我在仔细看之前就点了确认。这件事之后我在 permissions 的 deny 列表里明确加上了git push --force、git branch -D等破坏性命令并且要求所有 Git 危险指令必须先列出影响范围再等 my 审批。这些事故并不意味着“多 AI 协作”不值得搞。恰恰相反方向是对的只是边界和机制必须一起设计。简单说AI 的能力越强越需要给它更清晰的轨道轨道不是限制而是让它在边界之内安全发挥。6. 常用排错速查表我整理了一份在工作中高频使用的排查速查表遇到类似问题直接对着查能省很多时间。症状可能原因排查与解决Claude Code 答非所问上下文过长、重要约定被挤出上下文窗口执行 /clear 开启新会话把关键约定固化进 CLAUDE.md不触发某个 SkillSkill 的 description 描述太泛或触发词不匹配检查 description 是否包含任务关键词补充触发词确认 skill 目录在正确位置MCP Server 报错连不上路径错误、npx 包未安装、端口占用检查 .claude.json 配置、尝试npx单独启动 Server 调试AI 频繁请求写文件权限permissions 里 Write 设置成 deny按需临时放行或改用 ask不要全局 allow Write自动修改死循环缺少止损条件、失败后继续重试在 Skill 中增加“连续失败即停止请求人工介入”规则上下文爆炸交接文档塞了太多原始内容改为“摘要 文件路径”的结构危险命令被执行deny 列表没覆盖破坏性命令添加 git push --force、rm -rf、drop table 等危险指令到 denySkill 爆发式增长互相干扰技能描述边界不清晰精简技能数量重写 description确保每个技能触发条件互斥MCP 工具返回结果格式不兼容服务器版本过旧、协议版本差异升级 MCP Server 和 Claude Code 到最新版本这个表里的问题绝大多数我自己都踩过。你不需要一次记住所有但建议把它收藏到某个项目笔记里遇到症状随手翻。关于“从会用到用得好”我的进阶建议有三条。一是给每次改造定义“验收指标”比如可以这样定义技能复用率提升、人工 Review 时间下降、一次通过率提高。没有指标你很难判断到底是 Skills 还是 MCP 起作用。二是保持小步迭代不要一次性把所有流程都自动化了先选一个重复度最高的动作做成 Skill再用起来、改起来。三是重视文档和注释Skill 和 MCP 的配置如果不写说明过两周你自己都会忘给配置文件夹补一个README.md是我最后悔没早点做的事。这个组合的延伸空间其实比看起来大。除了前端代码我还用它来生成自动化测试、整理接口文档、排查构建问题、甚至辅助分析构建日志。社区里有人把 MCP 接到设计稿转换、3D 引擎、电子设计自动化等工具配合 Skills 沉淀流程规范。核心方法论是通用先找重复再定流程然后沉淀成 Skill再通过 MCP 接入必要的工具最后用权限和上下文机制把风险管住。我个人在实际操作中最大的体会是工具本身并不神秘真正的门槛在于愿不愿意花时间去“建模”。Claude Code、Skills、MCP 组合起来像是一位可以随叫随到、但需要严格管理的数字员工。你给它清晰的 SOP它就能稳定输出你给它工具权限它就能独立干活但如果你不设定边界它也会给你创造出意想不到的麻烦。每次踩坑后我并不会觉得“AI 不行”而是意识到“流程设计还有漏洞”然后继续补规则。这套工作流给我带来的最大改变不是写代码变快了而是我敢把更多项目里“枯燥但有章可循”的事情交给它然后把自己解放出来专注在真正需要判断力和创造力的部分。