在传统行业中，标书AI优化正成为提升效率的关键工具。一位客户带来了长达1111页、总计60多万字的标书材料。尽管对他所处的业务领域并不熟悉，但收到资料的那一刻，我就意识到——这绝非一次普通需求。整套标书材料，数字本身就很直观：1111页、60多万字。

这些数字背后，真正的难点并非“撰写”，而在于“修改”。这类工作的核心痛点，其实并不在于内容本身有多深奥，而是如何在保持准确性的同时快速响应新要求。

流程通常如此：每次投标并不总能一次成功，流标是常有的事。一旦流标，随后就是多次投标接踵而至。这时，最折磨人的并非重头再来——基础内容已经具备；真正麻烦的是，你不得不去修改，因为新的投标信息、最新要求、新增细节都必须准确对齐。员工不得不在1000多页、60多万字的内容里逐一翻阅、逐段查找、逐条修改。思路确定之后，后续几乎全是机械性工作，是那种极度消耗精力与时间的重复性繁重劳动。

问题拆解：明确哪些环节适合AI接管与工作流构建

接到需求后，第一时间浮现的疑问不是“这份标书该怎么写”，而是“这件事究竟哪些环节可以被AI接管”。思路逐渐清晰：要解决这个问题，至少需要满足两个前提。

第一，把整个处理流程打造成自动化工作流。不能只解决某个孤立片段，而是要从读取资料、理解结构、生成内容到修改内容，整条链路串通起来。第二，必须拿到客户之前完成的标杆标书。想让AI生成高质量内容，前提不是空口要求“你输出好一点”，而是要先让模型知道“优质标准到底长什么样”。只有让AI去读一份真正像样的标书，理解其中的结构、语言、章节逻辑和内容组织方式，后续生成的结果才有机会接近业务可用。

客户发来的资料比较零散，包含Word、图片以及其他附件格式，合计超过80MB。不过这类情况已有应对经验，标准流程就是：先统一整理，再完成格式转换，最后进行模型训练。

第一步：将1111页标书转化为Markdown格式

拿到资料后，首先将那份1111页的标书转成了Markdown。为什么选择这种格式？因为对AI模型而言，Markdown这类结构化文本更易于被读取、拆解和理解，也更方便后续用于Skill训练。如果始终保留原始Word格式，其中夹杂的图片、样式、分页和表格信息会干扰模型处理效率。一旦转为Markdown，标题、章节、正文内容以及层级关系立刻清晰可辨。完成这一步，真正的核心任务才算开始。

核心环节：构建可复用的专业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应用机会

回顾整个过程，最大的感触是：站在IT行业或互联网行业中，很容易产生一种错觉——觉得大家都会写SQL、都会调智能体、都会使用大模型、都会操作自动化工具。可一旦把视角下沉，沉到一个个具体传统行业里，你会发现实际情况并非如此。很多人真的不会使用这些技术。不是因为他们懒惰，也不是不想学，而是缺少引导、缺少讲解、缺少人来帮他们迈过那道最初的门槛。

但偏偏，他们手上又拥有大量强烈需求。这些需求极其具体、刚性、值得用AI进行改造。未来，我可能会投入更多精力，制作面向传统行业的实用教程、讲解视频和案例分享。因为这里的需求非常庞大，只是很多人痛了很久，却始终未能找到真正能帮助他们的人。

写在最后

AI最具价值的地方，并非让已经懂行的人变得更炫酷，而是让原本那些沉重、缓慢、笨拙的工作，终于有机会被重新高效执行。这次帮助客户构建标书Skill的经历，就是一个非常具体的例证。他支付了少量咨询费用，解决了最核心的痛点；我收到了费用，也获得了真诚的感谢。这是一种非常舒适的协作关系——互利共赢，也是真正的利他之道。

如果你现在所在的行业，也存在大量重复、繁琐、规则明确且特别消耗人力的工作，真的值得认真思考：这件事，是否已经可以交给AI来提升效率？或许你缺少的并非更多努力，而是一个合适的工具，以及一个真正带你迈出第一步、学会使用它的人。