企业官网建设流程全解析

最近我总算把公众号自动发文这套东西跑通了。简单说就是：AI 按我的选题生成文章，到点自动排版、自动进草稿箱、自动发布，全程不需要我手动打开公众号后台。听着挺爽是吧，但这东西从萌生想法到稳定运行，我前后折腾了小半个月，中途有三天差点想放弃。这篇就把这个过程，尤其是那些文档里不会写清楚的坑，一条条摊开讲。

先说我为什么要做这套系统。我手上管着一个垂直领域的公众号，更新频率要求比较高，每周至少要发三到四篇。内容本身不算复杂，但每天选题、写作、排版、找封面图这一套流程下来，一个人扛确实累。而且很多时候不是写不出来，是重复劳动太多——标题要凑、排版要调、图片要找，这些琐碎事比写作本身更消耗精力。于是我就想，能不能把“写”交给 AI，把“发”交给脚本，我只需要把控选题方向和最终审核。

这套系统最终做成什么样，我可以直接说结论：我每天只需要在前一天晚上把第二天要发的选题关键词丢进一个配置文件里，第二天早上系统会自动生成文章、生成摘要、做封面图、排版成公众号格式，然后存到草稿箱。我再花五分钟扫一眼内容，点一下发布按钮就行。后来连这个“点一下”我都觉得多余，又接了一个定时发布，每天上午九点整自动发出去。目前已经连续跑了大半个月，中间因为各种 bug 漏发过三次，但整体链路算是稳定了。

这篇文章不是教你怎么把公众号做成全自动印钞机，那种话术我也不信。我更想分享的是：一个普通开发者，在完全没碰过公众号接口文档的情况下，怎么把 AI 生成、内容排版、图片素材、定时发布这几件事串起来。整个过程里踩的坑，比我写代码花的时间多得多。下面按我实际推进的顺序来写。

1. 项目整体拆解：自动发文系统到底在解决什么问题

1.1 最开始的想法错在哪

我刚开始的想法特别简单：AI 写文章不是已经很成熟了吗，我调一个接口让它写，生成完我复制粘贴到公众号后台，再手动传个封面图，点个群发，这不就完事了？

真上手才发现这个思路完全跑不通。公众号后台的编辑器看着简单，但它的排版逻辑和普通网页完全是两套东西。AI 生成的内容是一大段 Markdown 或纯文本，直接粘进去的后果就是：没有标题层级、没有分段样式、图片链接全部失效、代码块一团糟。更别提封面图和摘要这些字段，后台编辑界面里好找，但你让脚本去操作后台，总不能靠模拟点击吧——那玩意儿页面一改版就废，稳定性没法保证。

所以第一步要做的不是写代码，而是想清楚：这个系统里，哪些环节必须靠人工，哪些环节可以自动化，哪些环节是“半自动”更合理。我的结论是：

• AI 写初稿，自动化，但生成完必须人工过目
• 排版转换，自动化，因为规则是固定的
• 图片生成和上传，自动化，但需要兜底方案
• 存入草稿箱，自动化，发布前给人留一个审核入口

这其实就是发布前多了一道“草稿箱审核”的闸门，宁可多一步，也不搞一键群发那种放任模式。

1.2 拆解出来的四个核心模块

想清楚了上面那层，整个系统的结构一下子就清晰了。对我来说，它本质上就是四个模块：

第一个是内容生成模块。给它一个主题或几个关键词，它要能输出一篇结构完整的公众号文章，还得带上标题、摘要、封面描述这些附加信息。

第二个是内容转换模块。AI 输出的是纯文本或 Markdown，得把它转成公众号后台能识别、读者看着舒服的排版格式。这里牵扯到图片处理、段落格式、引用块、标题层级映射。

第三个是素材管理模块。公众号文章里的图片不能是普通外链，必须传成公众号素材库里的链接。封面也要单独处理成一个“永久素材”，拿到对应的素材 ID。

第四个是发布执行模块。调用公众号接口把排版好的文章存成草稿，或者直接把草稿发布出去。这一步牵扯到 Token 管理、接口频率限制、错误重试。

这四个模块跑通以后，我再在外面套一层定时调度，整个系统就完整了。

1.3 技术选型我为什么这么定

技术选型这步，我踩的坑不多，但想明白的过程挺费劲。先说结论：我用 Python 写了一个后台服务，AI 部分直接调用大模型的 API，公众号侧调用官方提供的开放接口，定时任务用的系统自带的定时任务工具。整个服务架在一台低配服务器上，内存 1G 的那种，跑起来毫无压力。

为什么用 Python？没有别的原因，就是它的生态最省事。调接口用 requests，处理 Markdown 有现成的库，写个定时循环也不需要额外装东西。整体代码量也不算大，核心逻辑大概加起来不到 400 行，还没到要上框架的程度。

为什么不直接用一个自动化工具去模拟浏览器操作？这个问题我纠结过一阵。模拟操作看起来能绕过接口文档的学习成本，但它有两个致命问题：一是公众号后台页面结构一变你的脚本就废；二是模拟操作不够“正规”，触发风控的概率高得多，而且封号风险也比较大。官方开放接口虽然学起来费点劲，但是稳定、合规、不容易误伤账号。所以选型上我一句话总结：能用接口解决的，坚决不碰模拟点击。

2. AI 内容生成环节：重点不在“会写”，而在“能发”

2.1 提示词模板怎么设计才能不翻车

AI 生成内容的环节，最容易翻车的不是“写得好不好”，而是“生成出来的东西能不能被后面几个环节正常处理”。我第一次尝试的时候，直接调模型接口让它写一篇关于某个主题的文章，结果返回的是好几千字的大段文字，标题、段落全混在一起，我后面想拆都没法拆。

后来我把提示词改成了“结构化输出”的思路。什么意思呢？就是让模型严格按照我定义的格式返回内容，每个字段、每个标记都不能乱。我用的格式是 JSON，里面固定包含 title、summary、content、cover_abstract 这几个字段，其中 content 是 Markdown 格式的正文。提示词里会明确写：不要输出 JSON 以外的任何解释性文字，不要使用代码块包装 JSON，标题用一级标题，小标题用二级标题。

这里有个很好用的小技巧：把提示词里加上“你是公众号资深编辑”这类角色设定，同时给出一个我手工撰写的样例文章作为参考。模型输出刚生成的时候可能格式不稳定，但只要把样例贴进提示词里，稳定率能到九成以上。

等模型返回之后，我先做一层格式校验：用 JSON 解析器去解析，如果解析失败就重新调用一次接口。重试超过三次就直接跳过当天的发布，并通知我检查。这个方法听起来简陋，但实际跑下来已经很稳。毕竟模型的输出稳定性再高，也架不住偶发抽风，与其把希望寄托在“它不会出错”，不如把校验和重试当默认操作。

2.2 从 Markdown 到公众号排版：比想象中麻烦

AI 给的 content 是一段 Markdown，但公众号后台的接口需要的是 HTML 片段，而且这个 HTML 不是拿来就能用的。我最初直接把 Markdown 转成 HTML 提交上去，结果文章里的标题、加粗、列表全都变成了没有样式的纯文本，看起来跟普通段落没区别。

查了一下才发现，公众号的正文接口支持的是“富文本 HTML”，也就是里面可以带行内样式。比如一个标题，你光写<h2>不够，还得带上font-size、font-weight、margin这些样式属性，文章推送到读者那边才会正常显示。各个平台的富文本格式要求还不一样，但公众号这边基本就是“内联样式优先”的路子。

我的处理方式是：用一个现成的 Markdown 转 HTML 的库，先把 Markdown 转成标准 HTML，然后写一套正则和字符串替换规则，把里面的<h1>替换成带样式的<h1>，<blockquote>替换成带边框和背景色的样式块，图片标签统一加上max-width: 100%。这套规则我调了两天，主要是各种边边角角的样式细节，比如注意规避列表缩进、去掉多余的空行、处理表格边框。

做完这步我才明白，为什么很多人用公众号后台自带的排版工具或者第三方编辑器，而不是自己写代码处理。第三方模板确实省事，但那个排版风格是固定的，想自定义就得自己造轮子。我这套方案的好处是，所有样式写在代码里，以后想改风格只改一处就行。

2.3 封面图和摘要的生成策略

原本以为最难的都搞定了，结果封面图又折腾了我一晚上。公众号封面的要求比我想象的严格：比例要对（常用的有 2.35:1 的大图和 1:1 的小图），图片大小有限制，而且封面不能直接用普通 URL，必须上传成“永久素材”，拿到一个素材 ID 才能在草稿接口里引用。

AI 生成图片这个事本身不难，难的是让生成出来的图符合公众号封面的比例和主题。我先让 AI 根据文章标题生成一段封面图的描述词，然后用图片生成接口出图，出完图再程序化裁剪成目标尺寸。这套流程跑通以后看着挺顺，但实际用起来有一个特别尴尬的问题：AI 出图的质量不稳定，有时候文字会被写错，有时候画面风格跟文章内容完全不搭。

我最后的解决方案比较鸡贼：封面图不让 AI 从零画，而是让 AI 生成一个简单的背景，主标题文字我用代码画上去。具体方法是调一个图像处理库，在生成好的背景图上居中绘制标题文字，字体加粗、颜色选白色，再配上一点阴影效果。这样出来的封面虽然不如设计软件做的精致，但胜在稳定，而且不会出现文字乱码问题。摘要更简单，就是让 AI 在生成文章的时候顺便产出一段 50 字以内的摘要，直接填到对应字段里。

3. 自动发布环节：公众号接口的完整调用链

3.1 接口权限和基础信息：动手前先看这个

公众号自动发布，绕不开的就是平台的开放接口。这里我吃了不少亏，先说最容易忽略的一点：不是所有公众号都有接口权限。

个人订阅号默认没有文章发布的接口权限，需要完成主体认证（比如企业、组织类型）后才有一整套接口能力。所以如果你手里的是一个个人公众号，想自动发文，第一步其实是确认账号类型，别代码写完了才发现调用的时候报错。

接口权限确认以后，要准备几个关键参数：开发者 ID、开发者密码、服务器 IP 白名单。这几个东西都在公众号后台的开发配置里设置。其中 IP 白名单这个坑特别隐蔽——它要求你填写服务器出口 IP，如果服务器 IP 变了或者你在本地调试，调用接口就会直接报错，提示“IP 不在白名单”。我一开始在本地跑测试，以为是代码问题，排查了半天才发现是白名单没加。

还有一个比较重的约束：已认证的订阅号，每天只能群发一次。自动发布系统如果频率没有控制好，很容易撞上这个限制。我的做法是每天只安排一篇定时发布，把“频率问题”从根上避开。

3.2 Token 获取与过期处理：一号坑

公众号开放接口用起来，第一步就是拿 access_token。这个 token 是所有接口调用的入场券，有效期是 7200 秒，也就是两个小时。第一次写的时候我天真地想：那就每次调用接口之前先拿一次 token，多省事。

结果一跑就发现不对。token 接口本身调用频率有限制，频繁请求会被限流，返回一个“请求太快”的错误码。而且每次重新获取 token，旧的 token 会立即失效。这意味着如果并发请求里头一次用了旧 token、一次用了新 token，就会相互挤掉，导致一部分请求失败。

正确做法是：token 拿到以后缓存起来，设置一个 7200 秒的定时过期逻辑，或者干脆在过期前提前五分钟刷新。我后来写了一个简单的 Token 管理器：先查缓存，缓存里没有或者快过期了才去接口拉新的，拉完存进内存，再加一把线程锁防止并发重复刷新。这个管理器虽然代码只有二十几行，但解决了我在这个环节能遇到的绝大多数问题。

3.3 图片素材：外链不行，必须走素材库

如果你自己试着调过公众号的发布接口，一定会遇到一个神奇的现象：正文里放了外链图片，存草稿的时候也没报错，但文章真正发布出去，读者看到的图全是裂的。

这是公众号平台的一个老规矩：文章里的图片不能直接用普通 URL，必须是素材库里的图片链接。图片要先通过“新增素材”接口上传，传完会给你一个 URL，把正文里的图片地址替换成这个 URL，发布出去才能正常显示。

有一点必须注意：上传图片素材有两种，一种是临时素材，有效期只有三天；另一种是永久素材，长期有效。文章正文和封面，建议都用永久素材。临时素材适合拿来测试，但正式跑自动化发布，绝不能用临时素材，否则三天后文章里的图就全挂了。

我在代码里专门写了一个图片处理函数：识别 Markdown 里的图片链接，逐个上传到素材库，再把原链接替换成素材 URL。这个函数运行时会打印出每一张图片的处理日志，方便我检查有没有传失败的。第一次跑的时候，有张图因为格式问题上传失败，日志里我看不到错误原因，后来才发现是那张图本身损坏了。所以这个函数里，我加了一个校验：图片文件大小必须大于 0，格式只允许 JPG、PNG、GIF，不符合条件的直接跳过并告警。

3.4 从草稿到发布：我最终留了一个人工审核口子

公众号发布相关的接口，有几个不同的层级。最稳妥的是“存草稿”：把排版好的文章和封面信息提交到草稿箱。存草稿不会真正推送，也不会触发每天一次的群发限制，所以可以反复测试。再往上一步是“发布接口”或“群发接口”，这才是真正把文章推送给读者的操作。

我的方案是：平时的流程走“存草稿”，然后我手动打开公众号后台，看一眼排版和封面没问题，再点发布。后来觉得这样还不够自动，又把“一键发布”也接了进去，但我把发布动作单独设了一个开关：配置文件里auto_publish这个字段设成 true，系统才会自动发布，否则只存草稿。

这个设计说不上多高级，但对我这种一人运营、又不想太冒险的情况特别合适。毕竟 AI 生成内容再稳定，也可能出现事实错误或者措辞不当，全自动发布能省事，但省不了“审稿”这一步。半自动的状态，一天花五分钟看一遍，系统跑得踏实，我也睡得踏实。

4. 定时调度与稳定性保障：从“跑通一次”到“每天自动跑”

4.1 定时任务方案：我用的是最小可行方案

系统四个模块都调试通过之后，剩下的事儿就是让它在每天固定的时间自动跑起来。这一步遇到的坑不算多，但值得好好说。

最开始我用的是自己写一个死循环脚本，在循环里检查当前时间，到点了就执行发文流程。这个方案在本地跑测试没问题，但放到服务器上就遇到一个麻烦：Python 脚本一旦因为网络波动或者其他异常退出了，整个任务就静默死掉，第二天文章就不会发。

后来我换成了系统自带的定时任务工具。配置方式很简单，定一个每天早上的执行时间，把运行指令填进去，到点系统就会自动启动一个发文流程，跑完自动退出。这样做的最大好处是：即使某次任务失败退出，也不会影响下一次的执行，系统的调度机制会负责到点拉起新进程。

这里必须提醒一句：时区问题。我的服务器默认时区不是本地时区，一开始配置定时任务的时候，指定的是服务器本地时间，结果第一次自动发文比我预期的整整晚了 8 个小时。后来我在定时任务配置里特意加了时区参数，又在执行脚本里用时间函数强制指定时区，这个问题才彻底解决。

4.2 失败重试与告警：别把 API 调用假设成永远成功

自动发文系统跑起来以后，最大的风险不是代码逻辑写错，而是各种外部依赖在关键时刻突然出问题。AI 接口可能超时，素材上传可能失败，公众号接口可能因为网络原因返回一个 5xx 错误。这些情况如果没有任何保护机制，一次失败就会漏发一天的内容。

我在每个关键节点都做了重试机制。规则简单粗暴：AI 生成文章失败，重试三次，每次间隔 10 秒；图片上传失败，重试两次，失败的图片放弃并继续；提交草稿失败，重试三次，还是失败就跳过当天并告警。

告警这个环节，我用的是最省事的方式：webhook 通知。系统里写了一个发通知的函数，任何一步失败超过重试次数，就发一条消息到我手机。消息内容包含失败原因、出错模块和当天的文章标题。这样即使我不在电脑前，也知道系统出了状况。这套告警机制跑下来，我大概收到过七八次通知，每一次都帮我避免了一次“遗漏发文”。

还有个细节我觉得特别值得写：重试的时候要注意“幂等性”。比如存草稿这个操作，如果第一次调用超时了，你无法确定它到底是没执行成功，还是执行成功了但响应没送达。如果这个时候直接重试，可能产生一篇重复的草稿。我的解决办法是：每次发文前生成一个唯一编号，草稿接口里携带这个编号，失联后重试时先查一下这个编号是否已经存在，存在就跳过，不存在才重新提交。这个设计虽然多写了几行代码，但避免了一大类“重复提交”问题。

4.3 内容质量的日常维护：稳定输出的三个小技巧

AI 写文章这事儿，用久了你会发现一个问题：刚开始觉得质量还行，用一段时间以后，输出内容会变得套路化、同质化，甚至有点絮叨。这不是你错觉，是模型在相同提示词下输出概率分布趋于稳定导致的。

我的应对方式有三个。第一个是定期更换提示词里的角色描述和示例文章，两周换一次，换完立刻感觉文章风格会有变化。第二个是在文章生成后加一道“去重检测”，把生成的文章跟历史文章做一次相似度比较，如果重复度超过阈值，就自动重新生成或调整选题角度。第三个更简单：每天手动干预一下选题。我前一天晚上看一遍第二天的推送主题，偶尔手动改一下提示词里的重点方向，相当于给 AI 一个“当天偏好”。

这套组合拳下来，文章的重复感明显降低了。虽然谈不上篇篇精品，但至少读者不会觉得你天天在发一个模子里刻出来的内容。

5. 踩坑实录：那些官方文档里查不到的 8 类问题

5.1 接口调用顺序和数据格式：最容易被忽略的报错

先说一个我浪费了大半天才发现的低级问题：公众号接口对参数类型和字段名的大小写特别敏感。举个例子，新增草稿接口里，正文内容字段的英文名是content，封面素材 ID 字段是thumb_media_id。我一开始照着网上某篇文章的代码抄，字段名抄错了，结果接口一直报“参数错误”，我还以为是 Token 过期了。

这种事排查起来特别费劲，因为接口报错信息有时候很笼统，不具体告诉你哪个字段不对。我的建议是：不要随手抄代码，直接去看官方接口文档的请求示例，字段名、缩进、嵌套结构对着文档来。另外，注意 JSON 字段名的大小写，有些接口返回的字段是 snake_case，有些是 camelCase，不能想当然。

5.2 IP 白名单和服务器环境问题

IP 白名单这个问题我在前面提了一嘴，但值得单独再说说，因为它的迷惑性太强了。

公众号开发者后台配置了一个“服务器 IP 白名单”，只有白名单里的 IP 才能调用接口。这个白名单的检测逻辑，是在你获取 Token 的时候校验的，所以它的报错时机也特别早。我当时在本地电脑上测试 Token 获取，一直报错“tinysou has no privilege to access the api”，一度以为是公众号没有开通接口权限。后来把本地 IP 加进去，问题立刻消失了。

这中间还遇到一个变体问题：服务器的出口 IP 和域名解析出来的 IP 可能不是同一个。如果你在服务器上调用接口，切记要看服务器实际的公网出口 IP，而不是看你的主域名解析到哪个 IP。有两次我换了服务器，旧 IP 没清掉，新 IP 没加白名单，折腾了很久才发现是这么个低级问题。

5.3 图片链接和素材过期问题

图片素材这一块，我在前文已经详细说过了，但有几个边角料问题还是值得补充。

第一个是：封面缩略图接口和文章正文图片接口，虽然都叫素材，但字段和使用位置不同。封面的素材 ID 是单独的字段传给草稿接口的，正文里的图片是直接替换成素材 URL 塞进 HTML 里的。搞混了就会遇到诡异现象：正文正常，封面不显示。

第二个是：永久素材虽然叫“永久”，但平台上对素材总数是有上限的。如果你每天发文章，每天传新封面图，素材库数量会不断膨胀。跑到一个月的时候，我收到过一个“素材数量已达上限”的报错。后来我加了一个清理逻辑：定期删除那种用过就不再使用的临时图片，只保留文章正在用的封面和正文图。

第三个是：上传素材时图片格式和大小限制。JPG、PNG、GIF 这些常用格式没问题，但有些 AI 生成的图片格式其实是 WEBP，或者文件大小超过限制。上传前做一轮格式校验和压缩，能省掉很多排查问题的精力。

5.4 内容安全审核拦截的问题

公众号文章发布前会经过内容安全审核，自动接口也一样。AI 生成的文章里，如果出现一些敏感的表述，或者触发了平台规则，接口会返回一个审核失败的错误码。这个错误码返回得很干脆，但不会告诉你具体是哪个词有问题，只告诉你“内容涉嫌违规”。

这可以说是整个系统里最不可能全自动化的环节了。因为我没办法通过代码预判平台审核的尺度，只能把“内容审核”这一步当成一道硬性门槛。我的做法是：每次存草稿之后，先触发一次内容安全检测接口，对标题、摘要、正文分别做检查。检测接口返回一个建议，如果内容是“违规”的，就自动把当天的文章撤回重新生成，最多重试两次。如果两次都违规，就直接告警我人工处理，不自动发布。

说实话，这个机制没办法保证 100% 不被拦截，但确实帮我挡掉了很多潜在问题。特别是 AI 有时候会把某些词组合得很微妙，机器检测不出来，但审核系统能识别，所以人审这一步，暂时还是省不掉的。

5.5 时间、时区与“次日零点”的认知偏差

这个坑很小，但是特别容易踩。公众号后台显示的群发时间，是按你账号主体所在地的时区走的，而我的服务器时区不一样。我第一次设置早晨九点定时发布，结果后台记录的推送时间变成了凌晨一点。读者啥时候能看到先不说，至少跟我的预期完全对不上。

后来我在代码里统一用带时区的时间对象来获取“当前时间”和“定时时间”，确保服务器、脚本、公众号后台三边的时间基准一致。这个事看起来很小，但如果你不统一处理，它会幽灵一样潜伏在系统里，隔三差五冒出来恶心你一次。

另外还有一个“零点”的坑。我一开始判断“今天是否已经发过文章”，用的逻辑是比对“今天日期”。但公众号接口返回的发布时间是带时区的完整时间戳，如果你直接用datetime.now().date()去跟它比较，跨时区情况下会把“昨天深夜”和“今天凌晨”搞混。最简单的解法是：在存储“是否已发布”这个状态的时候，存完整时间戳，而不是只存日期。

5.6 依赖“一次性成功”的心理预期

很多朋友做自动化系统，一开始的预期是“配好就永远不用管了”。我一开始也是这么想的。实际跑下来你会发现，自动化系统省掉的是重复劳动，但并没有省掉“偶尔看一眼”的责任。你仍然需要面对 AI 接口偶尔超时的问题、公众号后台偶尔升级带来的兼容问题、以及节假日前后平台审核策略变化带来的影响。

我现在的态度是：自动化不是“无人化”，而是“把人工从琐碎中解放出来，只做决策”。系统帮我顶住了 90% 的重复劳动，剩下的 10%，每天花五分钟处理一下就好。这样想，踩坑也就没那么痛苦了。

6. 运行现状与我的实际体会

这套系统从第一个版本跑通到现在，已经稳定运营了一段时间。目前是每天早上自动执行：先读取当天的选题配置，然后调 AI 生成文章，处理封面图，转格式，传素材，存草稿，最后按配置决定是自动发布还是等待人工确认。整个过程从开始到结束，大概需要三到四分钟，运行期间基本不需要我做什么。

要说最大的变化，其实不是“省了多少时间”，而是我的工作节奏彻底变了。以前我每天最焦虑的时刻是晚上，想着第二天要发什么，一边熬夜写，一边担心质量不行。现在这部分压力完全前移到了选题环节——只要前一天晚上把选题定好，后面的事系统会自动处理。我反而能腾出更多时间去想选题、做调研、回复读者留言，这些事对公众号的价值，远比我闷头排版要高得多。

最后再分享一个小技巧：我每天会在系统运行结束以后，把当天的运行日志自动发一份到自己的一个备用收件箱里，里面记录了每个环节的耗时、成功与否、图片处理了几张、文章标题是什么。这个习惯帮了大忙，因为有时候系统显示“成功”，但实际效果可能和你预期有偏差——比如某张封面图被代码裁剪得比例不对，或者正文里某张图上传失败但没触发告警。日志就像黑匣子，排查问题的时候，翻一翻日志基本能定位到七八成的原因。

至于这套系统以后还能怎么扩展，我目前在琢磨两个方向。一是加一个“历史文章风格学习”模块，让 AI 在写新文章之前，先读几篇我历史文章的开头和结尾，模仿语气，这样文章的连贯感会更明显。二是把选题来源也接进来，每天从行业热榜信息里自动筛选几个可能的选题，推给我选。这样整个链条从选题到发布就全部打通了，我每天的活儿只剩下一件事——做决定。

如果你也在折腾类似的东西，我的建议是别急着追求全自动，先把“半自动”跑通再说。你花几天时间把从 AI 生成到存草稿这条路走通，就已经能省下百分之八十的重复劳动了。剩下的那百分之二十，量力而行就好。毕竟工具是拿来用的，不是拿来供着的，它为你服务，而不是反过来。