夜雨聆风
企业到底应该怎么从“整理自己的资料”，一步一步走到“封装出真正能用的业务Agent”？
很多人一上来就问：
用GPT好，还是用Coze好？
用Claude Code好，还是用Codex好？
是不是应该直接做Agent？
是不是应该一步到位做自动化？
但我越来越觉得，这些问题都不是第一问题。
真正的第一问题是：
企业有没有把自己的业务资料，整理成AI能理解、能调用、能持续迭代的知识资产？
如果这个问题没解决，不管你用GPT、Coze、Claude Code还是Codex，最后大概率都会遇到同一个结果：
Agent看起来很炫，但用起来不稳。
第一次输出还可以，第二次就开始飘。
演示的时候很好，真实业务一跑就出问题。
老板觉得AI很强，团队回去以后还是不知道怎么落地。
原因也不复杂。
大模型本身很强，但它默认并不懂你的企业。
它不知道你的产品。
不知道你的客户。
不知道你的类目。
不知道你的价格带。
不知道你的客服话术。
不知道你的主图经验。
不知道你的小红书内容风格。
不知道你过去哪些打法有效，哪些打法踩过坑。
不知道你的团队流程，也不知道你的业务边界。
所以，企业AI落地的第一步，不是急着搭Agent，而是先把企业自己的经验、资料、流程、案例和标准，变成AI可以调用的Markdown知识库。
这件事，我现在越来越愿意把它叫做：
企业知识库工程。
现在AI工具太多了。
ChatGPT、GPTs、Coze、Claude Code、Codex，还有各种图像、视频、工作流、自动化工具。
工具越多，企业越容易焦虑。
因为每个工具看起来都很厉害，每个平台都有人在讲，每个案例都像是“马上能改变企业”。
但企业真正落地AI，不能按工具来设计流程。
正确的顺序应该是按阶段来选择工具。
大致可以分成这么几步：
企业原始资料整理
↓
资料清洗与语义化
↓
生成Markdown知识库
↓
用真实业务任务测试
↓
根据测试结果反复修改Markdown
↓
继续测试，继续迭代
↓
形成满意版本
↓
封装成业务Agent
↓
进入工作流、批量化和复杂Agent
这里每一步的技术选择都不一样。
有些阶段适合GPT。
有些阶段适合Claude Code或Codex。
有些阶段适合Coze。
有些阶段根本不应该急着用平台，而是应该先整理资料。
这就是我现在的一个基本判断：
不要用工具牵着企业走，而要让工具服务企业AI落地的不同阶段。
企业AI落地，最怕资料散。
产品资料在运营电脑里。
客服话术在客服主管微信里。
直播话术在主播脑子里。
主图经验在设计师经验里。
复盘记录在老板聊天记录里。
爆款案例在某个表格里。
客户问题在客服系统里。
短视频方法论散落在历史文档和团队会议里。
这些东西没有整理之前，企业说自己要做AI，其实AI没有东西可以真正调用。
所以第一步不是写Prompt，也不是搭Agent，而是盘点资料。
企业资料大致可以分成几类：
文本资料，包括产品资料、品牌资料、客户画像、用户痛点、历史文案、客服话术、直播话术、SOP、复盘记录。
表格资料，包括SKU表、商品表、销售数据、评论数据、竞品数据、投流数据、内容数据。
图片资料，包括主图、详情页、海报、小红书封面、竞品视觉、买家秀、包装图。
视频资料，包括短视频、直播切片、达人视频、竞品视频、口播视频、素材片段。
网页和截图资料，包括竞品链接、店铺页面、评价区截图、后台数据截图、小红书笔记、抖音内容。
这些资料本身不是知识库。
它们只是原材料。
原材料要经过清洗、拆解、提炼、结构化，才能变成AI可调用的知识资产。
这里有一个很重要的分工。
针对文本资料、表格资料、本地文档，Claude Code和Codex这类本地文件型Agent会越来越有优势。
因为资料都在本地。
Markdown也在本地。
测试样例也在本地。
修改可以原地完成。
版本可以持续维护。
它更像一个“本地知识库工程师”。
但是图片和视频资料不一样。
电商企业有大量重要经验，其实不是文字，而是在图片和视频里。
比如一张高点击主图，真正有价值的不是“这是一张产品图”，而是：
为什么这个构图有点击率？
卖点放在什么位置？
人群暗示是怎么做的？
视觉冲突在哪里？
文案层级怎么安排？
信任感从哪里来？
转化钩子是什么？
一个短视频也不是简单看它讲了什么，而是要拆：
前3秒怎么抓人？
痛点怎么铺垫？
卖点什么时候出现？
镜头怎么切？
字幕怎么配？
评论区怎么引导？
最后怎么转化？
这些东西，GPT的多模态理解会更友好。
所以我现在更倾向于这样分工：
文本资料、表格资料、本地文档
→ 交给Claude Code / Codex整理
图片、截图、海报、详情页、主图、封面
→ 先交给GPT做视觉理解和语义提取
短视频、直播切片、竞品视频
→ 先交给GPT拆脚本、拆节奏、拆画面逻辑
最后所有结果
→ 统一沉淀成Markdown知识库
这里有一句话非常关键：
图片和视频不能直接变成稳定知识库，必须先被语义化。
所谓语义化，就是把图片和视频里的隐性经验翻译成文字规则。
只有变成文字规则，后面的Agent才好调用。
很多企业一做知识库，就容易犯一个错误：
把所有资料堆进一个超长文档里。
产品资料、客户画像、用户痛点、内容风格、客服话术、直播话术、案例复盘，全都塞在一起。
这种文档人看着累，AI调用也不稳定。
真正适合企业Agent使用的知识库，应该是多份结构清晰、边界明确、可以独立维护的Markdown文件。
比如一个小红书内容Agent，可以这样拆：
00_Agent总说明.md
01_品牌定位.md
02_产品知识库.md
03_客户画像.md
04_用户痛点.md
05_小红书内容方法论.md
06_爆款笔记结构库.md
07_标题风格库.md
08_封面风格库.md
09_禁用表达与边界.md
10_输出模板.md
11_测试样例.md
12_迭代记录.md
这样做有几个好处。
第一，方便维护。
产品变了，只改产品知识库。
风格变了，只改内容风格。
输出不稳定，只检查模板和测试样例。
边界出问题，就改禁用表达和规则。
第二，方便迁移。
今天可以给GPTs用，明天可以给Coze用，后天可以给Claude Code或Codex用。
第三，方便测试。
哪个文件影响了输出，比较容易定位。
第四，方便团队协作。
运营负责产品资料，客服负责话术，内容负责人负责内容方法论，AI负责人负责统一整理和测试。
这就不是简单写文档了。
这已经接近软件工程里的模块化思想。
所以我越来越觉得：
Markdown知识库不是普通文档，而是企业AI系统的源码。
很多企业做AI会有一个问题：
想一开始就做得很完整。
产品知识库要全。
客户画像要全。
话术库要全。
案例库要全。
SOP要全。
最好一套Agent直接覆盖所有业务。
这个思路很容易把事情做死。
企业AI落地更合理的方式，是先选一个高频、明确、可测试的岗位任务。
比如：
小红书文案。
主图策划。
短视频脚本。
客服异议处理。
评论分析。
直播卖点提炼。
竞品分析。
详情页结构策划。
先围绕一个任务，整理最小可用知识库。
第一版不追求完美，只追求三件事：
能用
能测
能迭代
只要能跑起来，就有了后续优化的基础。
最怕的是还没测试，就在文档里追求完美。
因为知识库质量不是靠想象判断的，而是靠真实任务测试出来的。
很多企业测试Agent的方式也有问题。
他们会问：
“你会做什么？”
“帮我写一篇文案。”
“你觉得我们品牌怎么样？”
这种测试没有意义。
真正测试知识库，一定要用真实业务任务。
比如：
请基于这个产品，写5篇不同角度的小红书笔记。
请根据我们的品牌风格，生成10个主图创意方向。
请分析这100条用户评论，提炼购买动机和用户顾虑。
请根据这个SKU，生成一版直播间口播话术。
请根据竞品详情页，拆解它的卖点表达结构。
请根据我们的客服规则，回答用户关于价格、效果、售后的疑问。
测试的时候，要看几个标准：
是否调用了产品知识。
是否符合品牌风格。
是否理解客户痛点。
是否避免了禁用表达。
是否输出结构稳定。
是否能连续产出接近质量的结果。
是否能被团队直接使用。
是否有明显胡编、夸大或偏离业务的地方。
如果输出不好，不要第一反应就怪模型。
很多时候不是模型不行，而是知识库不够清楚，指令不够明确，案例不够典型，输出模板不够稳定。
所以测试的价值，不是为了证明Agent很厉害。
测试的真正价值是：
用真实输出反推知识库哪里需要修改。
这一步非常关键。
知识库不是写完就结束。
它一定会不断修改。
新产品上线了，要更新产品知识库。
客户问题变了，要更新痛点库。
平台规则变了，要更新内容边界。
团队风格调整了，要更新输出模板。
测试发现Agent总是跑偏，要回去改指令和案例。
业务流程变化了，要更新SOP。
所以，企业内部一定要有人持续维护这套知识库。
这个人不是简单的“会用AI的人”。
他更像企业AI负责人。
他要懂业务，也要懂AI。
他要能看懂输出问题，也要能回到知识库里定位问题。
他要能整理资料，也要能设计测试样例。
他要能和老板沟通方向，也要能和运营、客服、内容、设计协作。
我觉得未来很多企业都会需要这样一个角色。
不是因为AI工具难，而是因为企业AI落地需要持续维护。
AI不是买回来就能自动运转的机器。
企业AI能力更像一个系统。
系统背后需要知识库、指令、流程、测试、迭代和负责人。
如果只是做一个轻量知识库，GPT对话里共创一下，然后上传到GPTs测试，问题不大。
但一旦企业资料复杂起来，GPT对话就会遇到几个卡点。
第一，上下文会爆。
资料越多，对话越长，前面讲过什么、为什么修改、当前版本是什么，都容易乱。
第二，版本不清楚。
今天生成一版，明天改一版，后天再改一版，很难清楚知道到底改了哪里。
第三，不能原地修改。
GPT更像是重新生成一份，而不是像程序员改代码一样，在原文件里精确修改。
第四，测试和修改链路割裂。
知识库在一个地方生成，Agent在另一个地方测试，测试结果再复制回来修改，摩擦很大。
但Claude Code / Codex这类本地文件型Agent，天然更适合复杂知识库工程。
因为它可以在本地文件体系里工作。
资料在本地。
Markdown在本地。
测试样例在本地。
迭代记录在本地。
修改也在本地。
它可以帮你打开某个Markdown文件，按测试反馈原地修改。
可以帮你拆分文件。
可以帮你统一命名。
可以帮你检查重复内容。
可以帮你维护迭代记录。
可以围绕一个项目文件夹持续推进。
这就从“对话生成文档”，变成了“本地知识库工程”。
我认为这是一个很大的变化。
我的建议是，不要神化任何一个工具。
不同工具适合不同阶段。
GPT适合做什么？
适合多模态理解。
适合看图片、看截图、拆海报、拆详情页、拆视频节奏。
适合共创知识库框架。
适合提炼业务规则。
适合生成Agent总指令初稿。
适合做轻量级Agent测试。
简单说：
GPT更适合看懂业务、提炼规则、验证轻量Agent。
Claude Code / Codex适合做什么？
适合读取本地文件。
适合整理大量文本资料。
适合生成多份Markdown。
适合原地修改文件。
适合维护版本和测试样例。
适合后续进入复杂Agent和本地自动化。
简单说：
Claude Code / Codex更适合整理资产、维护知识库工程、探索复杂Agent。
Coze适合做什么？
适合理解流程。
适合多步骤任务。
适合节点式工作流。
适合输入、处理、输出的可视化。
适合批量内容生成和业务流程演示。
简单说：
Coze更适合让企业理解工作流和批量化。
所以我会把它总结成一句话：
GPT看懂业务，CC整理资产，Coze跑流程，Codex探索复杂自动化，最终沉淀的是企业自己的Markdown知识库和业务Agent。
当然，工具未来一定还会变。
但这个分工逻辑不会轻易过时。
因为它不是按工具功能来分，而是按企业AI落地阶段来分。
很多企业一看到Agent，就想赶紧封装。
但我建议，在封装之前，先问四个问题。
第一个问题：
这个Agent到底解决哪个岗位任务？
不要做一个“什么都会”的Agent。
越是什么都会，越容易什么都不稳定。
第二个问题：
它调用了哪些知识库？
产品知识库有没有？
客户画像有没有？
痛点库有没有？
案例库有没有？
输出模板有没有？
禁用表达有没有？
测试样例有没有？
第三个问题：
它有没有经过真实任务测试？
不是演示测试。
不是随便问一句。
而是拿真实产品、真实场景、真实客户问题来测。
第四个问题：
测试结果不好时，企业知道该改哪里吗？
是改指令？
改产品知识？
改案例？
改输出模板？
改边界规则？
还是补充测试样例？
如果这四个问题回答不清楚，Agent封装得再漂亮，也只是一个玩具。
真正有用的业务Agent，背后一定不是一段提示词。
它背后应该是一套：
业务目标
岗位流程
私有知识库
输出标准
测试样例
迭代机制
负责人
这才是企业AI落地应该追求的东西。
企业AI化是分阶段的。
很多老板一听到AI，就想直接做自动化。
最好自动生成内容。
自动发布。
自动回复。
自动分析。
自动投放。
自动复盘。
自动决策。
这个愿望可以理解。
但现实里，如果单点任务都不稳定，直接做流程自动化，只会把问题放大。
一个小红书文案Agent都不稳定，批量生成100篇，只会批量制造垃圾。
一个客服话术Agent都不稳定，接入真实客服流程，风险会更大。
一个评论分析Agent都不准确，自动生成经营建议就更危险。
所以顺序一定不能乱：
先手搓
↓
再沉淀知识库
↓
再做单岗位Agent
↓
再做批量工作流
↓
再探索复杂自动化
企业AI落地，不是越快越好。
而是每一层都要有足够稳定的基础。
今天很多人学AI，太容易被平台牵着走。
今天学一个工具。
明天换一个工具。
后天又来一个新平台。
每次都从头开始。
这样会很累。
因为工具会变，模型会变，平台会变，Agent框架也会变。
但企业自己的东西不会轻易变。
你的产品知识不会轻易变。
你的客户画像不会轻易变。
你的内容方法论不会轻易变。
你的成交话术不会轻易变。
你的成功案例和失败复盘不会轻易变。
你的岗位流程和SOP不会轻易变。
这些才是企业真正长期有价值的AI资产。
所以，企业不要只问：
“哪个AI工具最好用？”
而应该问：
“我们有没有把自己的企业经验，整理成AI可以理解和调用的资产？”
当你有了一套高质量Markdown知识库，GPTs可以用，Coze可以用，Claude Code可以用，Codex可以用，未来新的Agent工具也可以继续迁移。
平台只是运行环境。
知识库才是企业AI系统的源码。
如果把这套方法压缩成一条路径，我会这么写：
第一步：资料集中
把企业产品、客户、内容、话术、案例、SOP、图片、视频资料集中起来。
第二步：资料语义化
文本直接整理；图片和视频先用GPT拆成文字规则。
第三步：知识库Markdown化
用Claude Code / Codex把资料整理成多份可维护的Markdown文件。
第四步：岗位任务测试
先选一个高频任务，比如小红书文案、主图策划、客服话术、评论分析。
第五步：测试反馈反推知识库修改
输出不好，不要先怪模型，先回到知识库、指令、模板和案例里找问题。
第六步：多轮迭代
改Markdown，再测试；再改Markdown，再测试。
第七步：封装业务Agent
满意后再封装成GPTs、Coze Agent，或者继续在Claude Code / Codex里做复杂Agent。
第八步：进入工作流
当单点Agent稳定后，再考虑批量化、流程化和自动化。
这条路径看起来没有那么性感。
它不像“一个提示词搞定全公司”那么刺激。
也不像“全自动AI员工”那么吸引眼球。
但它更接近真实企业落地。
因为企业AI化，本来就不是一次性买一个工具，也不是上一个平台就完成了。
它是一套长期能力建设。
企业要做的，不是追逐每一个新工具，而是逐步建立自己的知识资产、岗位Agent、工作流和内部AI负责人能力。
最后再说一遍我最近越来越强烈的判断：
企业AI落地，不是先问用GPT、Coze、Claude Code还是Codex。
正确顺序是：先整理企业资料，再把资料清洗成Markdown知识库，再用真实业务任务测试知识库，再根据测试结果反复迭代，最后才封装成业务Agent。
GPT适合多模态理解和轻量Agent验证，Claude Code / Codex适合本地知识库工程化，Coze适合理解流程和批量化。
平台只是运行环境，Markdown知识库才是企业AI系统的源码。
这件事越往后走，我越确定：
未来真正会用AI的企业，不一定是追工具最快的企业。
而是最早把自己的业务经验，变成可调用、可维护、可迁移的AI知识资产的企业。
