1. 从“会用工具”到“造生产线”Codex 多场景自动化到底在解决什么问题很多人第一次接触 Codex脑子里想的还是“帮我补全一段代码”或者“解释一下这个报错”。这个认知放在两年前没问题但放到现在已经明显落后了。Codex 这类智能体真正值钱的地方不是单次问答而是把它当成一条可以反复运转的自动化生产线——你给它一个目标它自己拆任务、调工具、写文件、跑验证、修错误最后把成品交到你手上。这套玩法才是“超级个体”和普通使用者之间的分水岭。我自己是从写脚本做批量文件处理开始接触自动化的后来陆续试过自动化测试、数据清洗、内容流水线踩过的坑不算少。Codex 智能体最吸引我的点在于它把“写代码”和“执行代码”这两件事缝在了一起。以前你要先让模型写脚本再自己复制到终端跑报错了再贴回去让它改来回折腾。现在通过 AGENTS.MD 这类约定文件你可以把项目背景、目录结构、命令规范、禁止事项一次性交代清楚智能体每次开工前都会读一遍相当于给新员工发了一本员工手册。这篇文章适合三类人看。第一类是已经会用 Codex 做单点任务但想把它升级成多场景流水线的开发者第二类是想系统学习智能体应用却不知道从哪个真实项目切入的初学者第三类是做自动化测试、数据处理、内容生产希望用智能体替代重复劳动的技术从业者。我会从整体设计思路讲到具体实操把参数选择、目录约定、容错处理这些细节都摊开说尽量让你看完就能照着搭一套自己的东西。需要先说明一点下面涉及的工具选型、目录结构、参数配置有一部分是基于我自己的实践总结有一部分是基于行业里比较通行的做法做的合理补全。Codex 本身在迭代具体命令可能随版本变化但底层思路是稳定的你理解了逻辑换个版本照样能用。2. 整体设计与思路拆解为什么是 AGENTS.MD 加多场景流水线2.1 单次对话为什么撑不起生产级需求先说说我早期踩的坑。最开始我用 Codex 处理一批 CSV 数据每次都是打开对话框把需求描述一遍等它生成代码复制出来跑报错了再贴回去。处理三五个文件还行一旦上到几十上百个问题就全冒出来了。第一是上下文丢失聊到后面它已经忘了最初的数据格式约定第二是重复描述每个新会话都要把项目背景重新讲一遍浪费时间第三是错误累积同一个类型的报错在不同文件里反复出现我却要一次次手动纠正。这三个问题的根源是一样的单次对话没有“项目记忆”。智能体每次都是从零开始理解你的意图它不知道你的目录长什么样不知道你用什么测试框架不知道哪些操作是禁区。这就像你雇了一个临时工每天上班都要重新培训一遍效率可想而知。2.2 AGENTS.MD 扮演的“项目宪法”角色解决思路其实很朴素把那些每次都要重复交代的东西写成一个文件放在项目根目录让智能体每次开工前自动读取。这个文件就是 AGENTS.MD。它的作用类似于团队的开发规范文档但读者是智能体而不是人。我在自己的项目里AGENTS.MD 通常包含这么几块内容。第一块是项目概述用三五句话说明这个项目是干什么的、技术栈是什么、主要目录有哪些。第二块是命令规范比如安装依赖用哪个命令、跑测试用哪个命令、格式化代码用哪个命令写清楚之后智能体就不会乱猜。第三块是目录约定告诉它源码放哪、测试放哪、临时文件放哪、日志放哪。第四块是禁止事项比如不许直接改生产配置、不许删除数据文件、不许在没跑测试的情况下提交。第五块是风格要求比如命名用驼峰还是下划线、注释用中文还是英文、提交信息怎么写。这份文件写得好不好直接决定了智能体的产出质量。我见过有人把 AGENTS.MD 写成一句话“这是一个 Python 项目”结果智能体生成的代码风格飘忽不定目录也乱放。也见过有人写得极其详细连每个函数的命名前缀都规定好智能体的产出就非常稳定。我的建议是宁可一开始写细一点后面根据实际踩坑再补充也不要图省事写得太粗。2.3 多场景流水线的分层设计有了 AGENTS.MD 打底接下来就是设计流水线的分层。我把自己的自动化项目分成三层。最底层是工具层负责具体的原子操作比如读写文件、发请求、跑命令、解析数据。中间层是编排层负责把多个工具按顺序串起来处理分支和循环管理中间状态。最上层是场景层针对不同的业务需求调用编排层的能力完成具体任务。这么分层的好处是复用。比如我写了一个“读取 CSV 并清洗”的工具数据处理场景能用报表生成场景也能用内容分析场景还能用。如果全写成一坨换个场景就得重写。分层之后新增场景只需要在场景层加一个入口底层工具不用动。具体到 Codex 智能体工具层通常对应它调用的那些函数或命令编排层对应它的任务规划能力场景层对应你给它的具体指令。你要做的是把工具层和编排层的约定写进 AGENTS.MD让智能体知道有哪些能力可用、该怎么组合。场景层则是每次任务开始时动态给出的这样灵活性最高。2.4 为什么选 Codex 而不是别的方案市面上做智能体自动化的方案不少有平台化的也有纯代码的。平台化的好处是开箱即用拖拖拽拽就能搭流程但灵活性差遇到平台不支持的操作就卡住了。纯代码的好处是灵活什么都能做但门槛高什么都得自己写。Codex 这类方案处在中间位置。它本身有很强的代码生成能力你不需要从零写每个工具描述清楚需求它就能帮你生成。同时它又能执行代码、调用命令具备真正的行动能力。这种“能想又能做”的特性特别适合多场景自动化——你不需要为每个场景单独开发只需要把场景描述清楚剩下的交给它。我实测下来Codex 在处理“需要写代码来解决”的任务时优势最明显。比如数据格式转换、批量文件重命名、接口测试脚本生成这些任务用平台化工具做很别扭用 Codex 就很顺。反过来如果是纯流程编排、不需要写代码的任务平台化工具可能更省事。所以选型的关键是看你的场景里“写代码”占多大比重。3. 核心细节解析与实操要点把约定写对把边界划清3.1 AGENTS.MD 的写法与常见误区写 AGENTS.MD 有几个要点。第一是位置必须放在项目根目录智能体默认会从这里开始找。第二是格式用 Markdown 写标题层级清晰方便智能体解析。第三是内容要具体、可执行避免模糊表述。我见过一个典型的反面例子有人写“代码要写得优雅一点”。这种表述对智能体来说毫无意义它不知道什么叫优雅。正确的写法是“函数不超过 50 行每个函数只做一件事变量命名用完整单词不用缩写”。你看这就可执行了。再举个例子有人写“测试要覆盖全面”。同样模糊。改成“每个公开函数至少有一个单元测试边界条件必须覆盖空值、零值、超大值三种情况”智能体就知道该怎么做了。还有一个误区是把 AGENTS.MD 写得太长。我见过有人写了三千多字结果智能体读取的时候反而抓不住重点。我的经验是控制在五百到一千字之间把最关键的约定写清楚细节可以放在单独的文档里在 AGENTS.MD 里引用。3.2 目录结构约定与文件命名规范目录结构这块我推荐一个经过验证的布局。根目录下放 AGENTS.MD 和 README。源码放在 src 目录测试放在 tests 目录配置放在 config 目录临时产物放在 tmp 目录日志放在 logs 目录文档放在 docs 目录。这个布局的好处是职责清晰智能体一看就知道该往哪放东西。文件命名我建议统一用下划线分隔的小写字母比如 data_cleaner.py、report_generator.py。避免用驼峰或者中划线因为不同系统对大小写和中划线的处理不一致容易出问题。日期相关的文件用 YYYYMMDD 格式比如 20260115_report.csv这样排序的时候天然有序。临时文件这块要特别注意。我早期没约定临时目录结果智能体把中间产物到处乱放根目录很快就乱了。后来我在 AGENTS.MD 里明确写了“所有中间产物必须放在 tmp 目录任务结束后清理”情况就好多了。日志同理统一放 logs 目录按日期分文件。3.3 命令规范与执行边界命令规范是 AGENTS.MD 里最实用的部分。你要把项目里常用的命令都列出来包括安装依赖、运行测试、格式化代码、启动服务、构建产物。每个命令写清楚用途和参数智能体就不会自己瞎猜。比如我会写安装依赖用 pip install -r requirements.txt跑测试用 pytest tests/ -v格式化用 black src/ tests/检查类型用 mypy src/。这样智能体在需要执行这些操作时直接调用对应命令就行不用每次重新推导。执行边界这块我建议明确列出禁止操作。比如禁止直接修改 config 目录下的生产配置禁止删除 data 目录下的原始数据禁止在没有跑通测试的情况下提交代码禁止执行涉及网络请求的命令除非明确授权。这些边界划清楚能避免很多意外。提示命令规范里最好标注哪些命令是只读的、哪些是有副作用的。智能体在执行有副作用的命令前会更谨慎这能降低误操作的概率。3.4 容错设计与错误处理约定自动化流水线最怕的就是中途出错然后整个卡住。我在 AGENTS.MD 里专门加了一节讲错误处理。核心原则是能重试的重试不能重试的记录并跳过绝不静默失败。具体来说网络请求失败重试三次每次间隔递增。文件读写失败先检查权限和路径确认无误后重试一次。数据解析失败记录原始内容和错误信息跳过这条继续处理下一条。所有错误都要写进日志任务结束后汇总报告。我还约定了一个“错误预算”的概念。如果单次任务里错误率超过百分之十就中止任务并报警因为这说明可能是系统性问题继续跑下去只会产生更多垃圾数据。如果错误率低于百分之十就继续跑完最后统一处理。这套容错设计让我在处理大批量数据时省了很多心。以前一个文件出错整个任务就挂了现在它能自己跳过继续跑最后给我一份错误清单我针对性地处理就行。4. 实操过程与核心环节实现从零搭一条数据处理流水线4.1 环境准备与项目初始化先说环境。我用的 Python 版本是 3.11这个版本在性能和兼容性之间比较平衡。依赖管理用 requirements.txt简单直接。测试框架用 pytest生态成熟插件多。格式化用 black类型检查用 mypy这两个工具能保证代码风格统一、减少低级错误。项目初始化我一般这么做。先建目录结构mkdir 出 src、tests、config、tmp、logs、docs 这几个目录。然后在根目录建 AGENTS.MD 和 README.md。接着建 requirements.txt把基础依赖写进去。最后建一个空的 src/init.py让 src 成为一个包。初始化完成后我会先跑一遍 pytest确认环境没问题。虽然这时候还没有测试用例但 pytest 能正常启动就说明环境配好了。这一步看着多余其实能提前发现很多环境问题比如 Python 版本不对、依赖没装全、路径配置错误。4.2 编写 AGENTS.MD 的完整示例下面是我一个数据处理项目的 AGENTS.MD 实际内容你可以参考这个结构改成自己的。# 项目说明 这是一个 CSV 数据处理项目负责读取原始数据、清洗转换、生成报表。 技术栈Python 3.11 pandas pytest。 # 目录约定 - src/源码 - tests/测试 - config/配置文件禁止直接修改生产配置 - tmp/临时产物任务结束后清理 - logs/日志按日期分文件 - docs/文档 # 命令规范 - 安装依赖pip install -r requirements.txt - 运行测试pytest tests/ -v - 格式化black src/ tests/ - 类型检查mypy src/ - 运行主程序python -m src.main # 代码风格 - 函数不超过 50 行每个函数只做一件事 - 变量命名用完整单词不用缩写 - 公开函数必须有类型注解和文档字符串 - 注释用中文解释为什么而不是做什么 # 错误处理 - 网络请求失败重试 3 次间隔 1/2/4 秒 - 文件读写失败先检查权限和路径再重试 1 次 - 数据解析失败记录原始内容跳过继续 - 所有错误写入 logs 目录任务结束汇总 - 单次任务错误率超过 10% 中止并报警 # 禁止事项 - 禁止直接修改 config/ 下的生产配置 - 禁止删除 data/ 下的原始数据 - 禁止在测试未通过时提交代码 - 禁止执行未经授权的网络请求这份文件大概六百字覆盖了核心约定。我实测下来智能体读取这份文件后生成的代码风格明显统一目录也不会乱放错误处理也规范了很多。4.3 核心工具函数的实现与参数选择工具层我一般会实现几个基础函数。第一个是文件读取支持 CSV、JSON、Excel 三种格式根据扩展名自动选择解析方式。第二个是数据清洗处理空值、去重、类型转换。第三个是数据转换比如列重命名、列计算、行列转置。第四个是文件写入同样支持多种格式。第五个是日志记录统一格式和输出位置。参数选择这块有几个经验。读取 CSV 的时候encoding 参数我一般显式指定为 utf-8避免不同系统默认编码不一致导致乱码。如果数据里有中文还会加 utf-8-sig 处理 BOM 头。分隔符默认逗号但如果数据里有逗号就改用制表符或者分号。数据清洗的时候空值处理策略要明确。是删除含空值的行还是用默认值填充还是保留空值这个要根据业务需求定。我一般会在 AGENTS.MD 里写清楚比如“数值列空值填 0文本列空值填空字符串关键列空值删除整行”。类型转换要小心。pandas 读取 CSV 的时候有时候会把数字列识别成字符串特别是列里有空值的时候。我一般会显式指定每列的类型用 dtype 参数。这样虽然麻烦一点但能避免很多后续问题。4.4 编排层的任务规划与状态管理编排层负责把工具串起来。我一般用一个主函数作为入口里面按顺序调用各个工具中间用变量传递状态。比如先读取原始数据存到变量 raw_data然后清洗存到 cleaned_data然后转换存到 transformed_data最后写入输出到目标文件。状态管理这块我建议把中间状态都存到 tmp 目录而不是全放内存。原因是数据量大的时候内存扛不住而且中途出错的话已经处理好的部分不用重跑。每个中间状态文件用步骤名加时间戳命名比如 step1_raw_20260115.csv这样出问题的时候能快速定位到哪一步。任务规划我一般让智能体自己拆。给它一个高层目标比如“清洗这批销售数据并生成月度报表”它会自己拆成读取、清洗、聚合、生成报表这几步。我只需要在 AGENTS.MD 里约定好每步的输入输出格式它就能串起来。这种“我定规矩、它做执行”的模式比我自己写死流程灵活得多。4.5 场景层的多任务并行与调度场景层是面向具体业务的。我目前跑着三个场景。第一个是每日数据清洗每天早上跑一次处理前一天的数据。第二个是周度报表生成每周一跑汇总上周数据。第三个是异常检测每小时跑一次扫描最新数据里的异常值。这三个场景共用底层的工具和编排能力只是入口和调度频率不同。我用系统的定时任务来调度每个场景一个入口脚本脚本里调用编排层的主函数传入不同的参数。这样新增场景只需要加一个入口脚本和一条定时任务底层完全不用动。多任务并行这块要注意资源竞争。如果两个场景同时读写同一个文件可能出问题。我的做法是每个场景用独立的 tmp 子目录和日志文件避免互相干扰。如果确实需要共享数据就用文件锁或者队列来协调。5. 常见问题与排查技巧实录那些文档里不会写的坑5.1 智能体不读 AGENTS.MD 怎么办这是最常见的问题。有时候智能体好像完全没看 AGENTS.MD生成的代码风格乱七八糟目录也乱放。排查下来通常是几个原因。第一是文件位置不对必须在项目根目录不能放在子目录里。第二是文件名大小写不对必须是 AGENTS.MD不能是 agents.md 或者 Agents.md。第三是文件格式有问题比如用了非 Markdown 格式或者有语法错误导致解析失败。如果确认这三点都没问题还是不读那可能是智能体的上下文窗口被其他内容占满了。这时候要精简对话历史或者开新会话。我一般会在任务开始时明确说一句“请先读取 AGENTS.MD 并遵守其中的约定”这样能提高它读取的概率。5.2 命令执行失败与权限问题命令执行失败的原因很多。最常见的是权限不足比如想写文件但目录只读想执行脚本但没有执行权限。排查方法是先手动执行一遍同样的命令看报什么错。如果手动能跑通智能体跑不通那可能是工作目录不对或者环境变量没继承。还有一个坑是路径问题。智能体执行命令时的工作目录可能和你预期的不一样。我一般会在 AGENTS.MD 里明确写“所有命令在项目根目录执行”并且在命令里用相对路径而不是绝对路径。这样能减少路径相关的错误。如果遇到权限问题先检查文件和目录的权限设置。Linux 下用 ls -l 看权限用 chmod 改权限。Windows 下检查文件属性确认不是只读。如果涉及系统级操作可能需要管理员权限这时候要谨慎确认操作安全后再执行。5.3 数据格式不一致导致的解析错误处理外部数据的时候格式不一致是家常便饭。同一个 CSV 文件有的行用逗号分隔有的行用制表符有的列是数字有的列是字符串有的文件有表头有的没有。这些都会导致解析错误。我的应对策略是“先探测、再解析”。读取之前先用一个小脚本探测文件格式看分隔符是什么、有没有表头、每列大概是什么类型。探测结果存到配置里正式读取的时候按配置来。这样虽然多一步但能避免大量解析错误。如果数据源不稳定格式经常变那就加一层容错。解析失败的时候不直接报错而是记录原始行内容尝试用备选格式再解析一次。两次都失败才跳过。这样能最大程度保住数据。5.4 任务中途失败后的恢复策略自动化任务跑一半失败是让人很头疼的事。如果从头重跑已经处理好的部分白做了如果不重跑又不知道从哪继续。我的做法是给每个任务加检查点。具体来说每处理完一批数据就把进度写到一个进度文件里记录已经处理到哪一行、哪个文件。任务重启的时候先读进度文件从上次中断的地方继续。这样即使中途失败重跑的成本也很低。检查点的粒度要权衡。太粗了恢复成本高太细了写进度文件的开销大。我一般按批次来每批一千条或者每个文件处理完写一次。这个粒度下即使失败最多重跑一批成本可接受。5.5 常见问题速查表问题现象可能原因排查方法解决思路智能体不遵守约定AGENTS.MD 位置或格式错误检查文件位置和文件名移到根目录确认文件名正确命令执行失败权限不足或路径错误手动执行同样命令对比检查权限统一用相对路径数据解析报错格式不一致探测文件实际格式先探测再解析加容错任务中途卡住某步阻塞或死循环看日志定位卡在哪步加超时加检查点产出风格不统一约定不明确检查 AGENTS.MD 风格部分补充具体可执行的风格要求内存占用过高数据全放内存监控内存使用中间状态落盘分批处理重复处理同一数据缺少幂等设计检查是否有去重逻辑加唯一标识处理前查重这张表是我踩坑踩出来的基本覆盖了八成以上的常见问题。遇到新问题的时候先对照这张表排查能省不少时间。注意排查问题的时候日志是第一手资料。我建议日志里记录足够的信息包括时间戳、任务名、步骤名、输入输出摘要、错误堆栈。日志格式统一方便用工具分析。不要怕日志多出问题的时候你会感谢自己记了这么多。6. 从单场景到多场景的扩展思路6.1 场景复用的三个层次当你跑通一个场景之后自然会想扩展到更多场景。扩展的复用分三个层次。第一层是工具复用底层的读写、清洗、转换函数直接拿来用。第二层是编排复用任务规划、状态管理、错误处理的逻辑直接拿来用。第三层是约定复用AGENTS.MD 里的目录约定、命令规范、风格要求直接拿来用。复用程度越高新增场景的成本越低。我现在的项目里新增一个场景平均只需要写一个入口脚本和一份场景说明底层完全不用动。这就是分层设计带来的红利。6.2 新增场景的标准流程新增场景我一般按这个流程走。第一步明确场景的输入输出输入是什么格式的数据输出是什么格式的产物。第二步拆解任务步骤从输入到输出需要经过哪几步处理。第三步检查现有工具能否覆盖这些步骤能覆盖的直接用不能覆盖的补新工具。第四步写入口脚本调用编排层的主函数传入场景参数。第五步加定时任务配置调度频率。第六步跑一遍验证确认产出符合预期。这个流程走下来熟练之后半小时就能加一个新场景。关键是前期的分层设计要做好否则每加一个场景都要大改那就得不偿失了。6.3 场景之间的协调与冲突避免多场景并行的时候冲突主要来自三个方面。第一是文件冲突两个场景同时读写同一个文件。第二是资源冲突两个场景同时占用大量内存或 CPU。第三是逻辑冲突两个场景对同一份数据的处理方式不一致。文件冲突的解决办法是隔离每个场景用独立的目录和文件。资源冲突的解决办法是错峰调度把重资源的场景安排在不同时间段。逻辑冲突的解决办法是统一约定在 AGENTS.MD 里明确每种数据的处理标准所有场景都遵守。我实测下来只要这三点做到位多场景并行基本不会出问题。偶尔有冲突日志里也能快速定位到是哪个场景引起的。6.4 性能优化的几个实用技巧场景多了之后性能会成为瓶颈。我总结几个实用的优化技巧。第一是批处理不要一条一条处理攒够一批一起处理减少 IO 次数。第二是并行互相独立的步骤用多进程或多线程并行充分利用多核。第三是缓存重复计算的结果缓存起来下次直接用。第四是惰性加载数据用到的时候再读不要一开始全读进内存。这几个技巧里批处理的收益最明显。我有个场景原来一条一条处理跑一次要半小时改成每批一千条之后五分钟就跑完了。并行和缓存的收益次之惰性加载主要省内存。6.5 监控与告警的搭建场景跑起来之后你需要知道它跑得好不好。我搭了一套简单的监控。每个场景跑完写一条记录到日志包含开始时间、结束时间、处理条数、错误条数、耗时。然后写一个汇总脚本每天跑一次统计各场景的运行情况生成报表。告警这块我设了几个阈值。错误率超过百分之十告警耗时超过历史平均值两倍告警连续两次失败告警。告警方式用邮件或者消息推送简单直接。这样即使我不盯着出问题也能第一时间知道。监控和告警看着是额外工作但实际上是省时间的。没有监控的时候我经常是过了好几天才发现某个场景早就挂了。有了监控之后问题基本当天就能发现并处理。7. 我在这套体系里踩过的真实坑7.1 过度依赖智能体导致的失控早期我太信任智能体了觉得它什么都能搞定结果有一次它自作主张删了一批中间文件导致我无法追溯问题。那次之后我明白了智能体再聪明也是执行者边界必须由人来划。现在我的 AGENTS.MD 里禁止事项写得特别细什么能删什么不能删什么能改什么不能改都列得清清楚楚。这个教训的核心是自动化不等于放任。你要给智能体足够的自由度去解决问题但也要给它明确的边界防止越界。这个平衡点需要根据实际经验来调太松了容易失控太紧了又发挥不出它的能力。7.2 约定写得太细反而僵化有一段时间我走向了另一个极端把 AGENTS.MD 写得极其详细连每个函数用什么算法都规定好了。结果智能体变得很死板遇到约定没覆盖的情况就卡住不会变通。后来我把约定分成两类一类是必须遵守的硬约束比如目录结构、命令规范、禁止事项另一类是建议性的软约束比如代码风格、错误处理策略。硬约束严格执行软约束允许智能体根据情况调整。这样灵活性和规范性就平衡了。7.3 忽略日志导致的排查困难还有一个坑是日志写得太少。早期我觉得日志占空间就只记错误不记正常流程。结果有一次任务跑出来的结果不对但我不知道中间哪一步出了问题因为正常步骤没日志。后来我把日志补全每个关键步骤都记输入输出摘要排查效率一下子高了很多。日志这东西平时看着没用出问题的时候就是救命稻草。我现在的原则是宁可多记不要少记。日志文件定期归档不占太多空间。7.4 没有版本控制带来的混乱最后一个坑是没做版本控制。早期我直接改文件改错了想回退都回不去。后来引入 git每次改动都提交出问题可以回退到任意版本。AGENTS.MD 本身也纳入版本控制这样约定的变更历史也能追溯。版本控制还有个好处是能对比。有时候智能体改出来的结果不对我可以 diff 一下看它改了什么快速定位问题。这个功能在调试的时候特别有用。8. 给想入门的你几条实在建议如果你刚开始接触 Codex 智能体自动化我的建议是从小场景切入不要一上来就搞大而全的系统。先找一个你每天都在做的重复劳动比如整理文件、清洗数据、生成报表用智能体把它自动化掉。跑通一个之后你自然就知道该怎么扩展了。AGENTS.MD 一定要写而且要认真写。这是整套体系的地基地基打不好上面盖什么都晃。写的时候多想想“如果我是新来的员工需要知道什么才能顺利干活”把这些都写进去。错误处理和日志不要省。这两个东西在顺利的时候看不出价值出问题的时候就是你的左膀右臂。我见过太多人为了赶进度跳过这两块结果后期排查问题的时间远超省下来的时间。最后保持耐心。智能体自动化不是一蹴而就的需要反复调试和优化。我自己的体系也是迭代了几个月才稳定下来。遇到问题不要灰心每个坑踩过去都是经验积累多了你就成了别人眼里的专家。