我用一个 Skill,帮传统行业客户把 1111 页标书的苦力活干掉了
Hi,大家好,我是七帅。
这两天,我接到了一个挺有意思的咨询。
有位粉丝在后台找到我,后来加了我的微信。他的需求很直接,想让我帮他做一个能智能写标书的工具。
说实话,他所在的行业我并不熟,甚至可以说完全不懂。
可当他把资料发给我的那一刻,我马上就意识到,这不是一个小需求。
因为他发来的,不是一份普通文档。
是一整套他们之前做过的标书材料。
我打开一看,1111 页,60 多万字。
看到这个数字的时候,我心里一下就有数了。
这件事真正难的,可能根本不是“写”,而是“改”。这类工作,难点根本不在内容本身
后面跟他聊下来,我才更清楚这个场景。
他们每次投完标以后,这个标不一定一次就成。
有可能流标。
流标之后,还会有二次、三次投标。
而到了二次、三次投标的时候,最麻烦的事情就来了。
你不能完全重写,因为前面的基础内容其实已经有了。
可你又不能不改,因为新的投标信息、新的要求、新的细节,都得重新对上。
问题就在这里。
内容本身未必有多高深,真正折磨人的,是你要在 1000 多页、60 多万字里面,一点点去翻,一段段去找,一条条去改。
你得先把信息摘出来,再找到对应位置,再按新的要求改回去。
整个流程,思路确定之后,后面几乎全是苦力活。
而且是那种特别消耗人的苦力活。我一开始想的,不是怎么写,而是怎么把流程自动化
他找到我以后,我脑子里最先冒出来的问题不是:
“这份标书该怎么写?”
而是:
“这件事到底哪一部分可以被 AI 接管?”
后来我的思路越来越明确。
我觉得这个问题要解决,至少得满足两个前提。
第一,要把整个流程做成自动化工作流。
不是只解决某一个片段,而是尽量把从读取资料、理解结构、生成内容、修改内容这整条链路串起来。
第二,我必须拿到他之前做过的标杆标书。
因为你想让 AI 生成高质量的内容,前提不是空口告诉它“你写好一点”。
前提是,你得先让它知道:“好的标准到底长什么样。”
只有让 AI 去读一份真正像样的标书,理解里面的结构、语言、章节逻辑、内容组织方式,后面它生成出来的东西,才有可能接近业务可用。
所以我就跟他要了他们之前做过的一份很不错的标书,以及其他一些附带文件。
资料发过来的时候,其实挺乱的。
有 Word,有图片,还有各种附件格式,加起来 80 多兆。
但没关系,这种事我已经比较熟了。
先整理,再转换,再训练。我做的第一件事,就是把 1111 页标书转成 Markdown
拿到资料之后,我先把那份 1111 页的标书转成了 Markdown。
为什么要这么做?
因为对 AI 来说,Markdown 这种结构化文本更容易被读取、拆解、理解,也更方便后续拿去做 Skill 训练。
你想一下,如果一直抱着原始 Word 不放,里面还有各种图片、样式、分页、表格干扰,模型处理起来其实很笨重。
但一旦转成 Markdown,整个东西就清爽很多。
标题是什么,章节是什么,正文是什么,层级关系是什么,马上就能拉开。
这一步做完之后,真正核心的任务才开始。
也就是:
创建一个 Skill,让这个 Skill 能在 Claude Code 里面被反复调用。真正有价值的,不是一次性生成,而是做成可复用的 Skill
我一直觉得,很多人对 AI 的理解还停留在“问一次,答一次”。
但如果你真的想解决工作问题,只靠一次性对话是远远不够的。
真正有价值的,是把你解决问题的方法沉淀下来,变成一个以后可以反复调用的东西。
所以我做的,不只是让 Claude 帮我临时写几段内容。
而是让它去学习这份标书,学习这个行业里一份“好标书”大概长什么样,然后再按照我的要求和客户的要求,给这个 Skill 做约束。
约束它该读什么。
约束它该怎么理解。
约束它该怎么输出。
约束它遇到不同投标要求时,应该优先改哪些内容。
这些约束都定下来以后,再去定义最终产出的格式和质量标准。
中间其实调了几轮。
有些地方约束太松,生成结果会飘。
有些地方约束太死,Skill 体积又会变得很大,调用起来也不够轻。
最后经过几轮来回调试,这个 Skill 才算真正写完。Skill 写完以后,我又干了一件很现实的事:给它“减肥”
刚开始做好的时候,这个 Skill 体积并不小。
原因也很简单。
里面塞了不少参考文件,很多内容是为了让它学得更稳、理解得更全。
但问题来了。
Skill 不是越大越好。
很多时候,约束不变的情况下,Skill 越精简,调用效率越高,后续使用体验也越稳定。
所以后来我又让 Codex 帮我做了一轮压缩。
把 Markdown 的内容精简掉一部分,把一些冗余说明拿掉,把 SQL 的行数也尽量减少。
目标很明确:
在不牺牲核心约束的前提下,尽可能缩小整个 Skill 的体积。
这个过程其实很像做产品。
不是功能堆得越多越好,而是要找到那个真正能打的最小闭环。做完以后,我才发现真正的难题还在后面
Skill 做完之后,我突然想到一个问题。
这个客户,他既没有 Claude Code,也没有 Codex。
也就是说,你把一个很好用的东西做出来了,但对方根本没有能接住它的环境。
这就很真实了。
很多技术人做工具,做到这里就停了。
因为站在技术人的视角,会默认对方“装一下不就好了”。
但现实不是这样的。
现实是,很多传统行业用户,别说装 Claude Code 了,他可能连这几个名字都没听过。
所以后来我又多做了一步。
我尝试把这个 Skill 转成豆包、元宝、千问这些国内大模型平台也能调用的形式。
思路没问题。
可很快,一个更硬的限制出来了。
上下文字数太长了。
60 多万字,1100 多页。
我心里其实一直有个担心:
国内这些平台,到底能不能完整吃下这么长的内容?
后来他也试了,我也推荐他用扣子去搭。
但最后效果并不理想。
原因很简单,超长上下文场景下,很多平台不是完全不能做,而是做得不够稳、不够透、不够像真正在处理一份复杂业务文件。最后我直接远程带他装,把这件事落地了
后来没办法,他给我付了一点咨询费,我就直接远程指导他安装。
我们约了一场一小时的 WebEx 会议。
我远程操控他的电脑,把 Skill 安装上,把 Claude Code 也安装上。
虽然整个界面全是英文的,但背后调用的模型是国内的,不需要访问国外网站。
这一点其实特别关键。
因为对很多传统行业用户来说,技术门槛未必只是“会不会用”,还有“敢不敢装”。
只要一提到英文界面、提到代码、提到网络环境,很多人心里就先退一步了。
所以你不能只告诉他“这个工具很强”。
你得真的帮他把第一步迈过去。
装完之后,我们按他的要求现场试了一轮。
当天晚上跑下来,初步结果其实就已经不错了。
因为时间也比较晚了,我们就先收工,准备第二天再看。第二天,他给我发来感谢信的时候,我心里挺高兴的
到了第二天,他单独给我发了感谢信。
他说这个东西确实帮他解决了很大的问题,效率几乎是指数级地提升。
后来我们继续在微信上聊。
我也跟他说,其实你们这种传统行业里面,重复性的工作特别多。
不是没人做,而是大家长期都在用很传统的方式一点点手搓。
问题不在于这些人不努力。
问题在于,他们没有真正接触过这套信息化和 AI 化的工作方式。
所以很多本来可以交给模型去处理的繁琐活,最后还是落回到人肉身上。
而站在今天这个时间点,大模型已经能帮我们解决非常多这种工作了。
今天帮你解决的,只是一个开始。
我也希望你后面能慢慢建立起 AI native 的工作思维。
别只是把 AI 当成一个问答工具,而是把它当成一个能嵌进流程里的生产力工具。真正让我有感触的,不只是赚到咨询费
后来到了今天晚上,他拿到了最终结果。
他很高兴。
他说这份标书写得非常好,改得也非常好,亲口告诉我,这个东西真的很棒。
事情走到这里,我心里其实挺开心的。
当然,赚到一点咨询费是一部分。
但更重要的,是你能明显感受到,你帮别人解决了一个非常具体、非常痛、而且原本很难解决的问题。
这种反馈是很直接的。
你不是在讲概念,也不是在讲趋势。
你是在帮一个真实的人,省掉大量重复劳动,让他的工作一下轻很多。
这件事本身就很有价值。
我后来也跟他说,如果你身边同一个行业的人也有类似需求,可以继续介绍给我。
他也很爽快地答应了。这件事让我越来越确认:传统行业,真的有大量 AI 机会
回过头来看这件事,我最大的感触就是:
我们站在 IT 行业、互联网行业里,很容易产生一种错觉。
会觉得大家都会写 SQL,都会调各种智能体,都会用大模型,都会折腾自动化。
可一旦把视角往下沉,沉到一个个具体传统行业里,你会发现不是这样的。
很多人是真的不会用。
不是他懒,也不是他不想学。
而是没人带,没人讲,也没人帮他迈过第一道门槛。
可偏偏,他们手上又有大量强需求。
这些需求还特别具体,特别刚需,特别值得被 AI 改造。
所以我后面可能会花更多精力,去做一些面向传统行业的教程、讲解和案例分享。
因为我越来越觉得,这里面不是没有市场。
恰恰相反,这里面的需求非常大。
只是很多人痛了很久,还没找到真正能帮他的人。最后
我现在越来越相信一件事:
AI 最有价值的地方,不是让会的人更炫,而是让原本很重、很慢、很笨的工作,终于有机会被重新做一遍。
这次帮客户做标书 Skill,对我来说就是一个特别具体的例子。
他付出了一点咨询费,解决了最痛的问题。
我收到了费用,也收到了感谢。
这是一种很舒服的协作关系。
说白了,就是互利。
也是利他。
如果你现在所在的行业,也有大量这种重复、繁琐、规则清楚、但特别耗人的工作,其实真的可以认真想一想:
这件事,是不是已经可以交给 AI 了?
也许你缺的,不是更努力一点。
你缺的,只是一个合适的工具,和一个带你把它真正装起来、用起来的人。