AI应用方法论:不存在“最好的AI模型”,就像不存在“最好的工具”同一个问题，问 ChatGPT 得到一个答案，问 Claude 得到另一个，问 Gemini 又得到第三个。三个答案都对了一部分，但也都错了一部分。
每个模型的预训练语料、强化学习偏好、更新截止时间都不一样，对同一事实的“记忆强度”和解读角度自然存在偏差。ChatGPT 往往更“安全”、圆滑、避免争议；Claude 更谨慎、结构化、喜欢加免责声明；Gemini 则有时更保守或直接拒绝某些话题。
它们本质上都在生成最“似是而非”的文本，很容易把真信息和合理推测混在一起。
过去一年，我在做 AI 相关的咨询和开发工作。接触的案例越多，我越意识到一个事实：
不存在“最好的AI模型”，就像不存在“最好的工具”。
每个模型都有自己的盲点。
Claude 诚实但有时过于谨慎，GPT 知识广博但偶尔自信地编造，Gemini 注重事实但对代码细节不够敏感，DeepSeek 代码能力强但在创意任务上偏弱。
以前我的思路是找一个“综合能力最强”的模型，用它搞定一切。
但这不可能，也不合理。
后来我想通了：
与其找一个完美的模型，不如组建一支 “模型协作团队”。
简单来说，就是放弃开发一个“通用软件产品”的执念，转而针对具体场景快速生成“一次性工具”。以前做一个财务分析软件，要花几个月调研需求、设计架构、开发测试。等你做完了，客户的业务可能已经变了。客户拿来一张格式混乱的Excel报表，我打开AI工具，描述需求：“把这1000条会计科目按准则分类，标记异常项。”30分钟生成一个专用工具。处理完毕，工具使命完成，扔掉。下一次遇到类似问题，我不需要从头开始，因为我知道怎么拆解问题、怎么设计流程、怎么让AI帮我快速生成解决方案。“模型协作团队”和“软件日抛化”这两个概念看起来风马牛不相及，但它们的底层逻辑是一样的：在软件日抛化中，我们不依赖一个“万能软件”，而是根据场景临时组装工具。在模型协作团队中，我们不依赖一个“万能模型”，而是根据任务临时组合多个模型。遵循同一个原则：去中心化、场景驱动、即时组建、用完即散。但真正让这套体系运转起来的，必须要有——技能工程（Skill、SOP）。遇到问题，写一段提示词，让AI回答。答得好就用，答得不好就重写提示词。这种方式的问题是每次都是从零开始。没有积累，没有复用，没有进化。后来接触到“技能工程”这个概念，才明白问题出在哪。一个技能不仅告诉AI“做什么”，还告诉它“怎么做”，并且可以被测试、版本化、在不同任务间迁移。审查的标准流程、常见的bug模式清单、输出的格式规范。
这个技能可以被反复使用，而且可以不断优化。我把这个技能分享给团队，大家都能用。从写提示词到封装技能，是从“手工作坊”到“标准化生产”的跃迁。- 软件日抛化告诉我：不要执着于“产品”，要关注“场景”。
- 模型协作团队告诉我：不要迷信“单个模型”，要利用“群体智慧”。
- 技能工程告诉我：不要停留在“临时提示”，要构建“可复用能力”。
- 遇到问题，用技能工程拆解SOP，确定需要哪些能力。
这个过程让我从一个“AI使用者”变成了一个“AI系统的设计师”。帮一家电商公司分析用户评论数据，找出产品质量问题的共性。按照以前的思路，我会找一个数据分析工具，导入数据，跑分析，写报告。第一步是技能工程。
我把“用户评论分析”拆解成5个子任务：数据清洗、情感分类、关键词提取、模式识别、报告生成。每个子任务我都提前封装好了对应的技能包。第二步是模型协作团队。
数据清洗用DeepSeek，代码能力强。情感分类用Claude，判断准确。关键词提取用GPT，词汇丰富。报告生成用Gemini，结构化好。第三步是软件日抛化。
我没有开发一个“用户评论分析系统”，而是针对这批数据生成了几个一次性脚本和分析模板。处理完，脚本使命完成，但技能包留下来了。第四步是沉淀资产。
这次处理中发现了一些新的评论模式，我把它们补充进了技能包的常见模式库中。整个过程用了不到半天。如果按传统方式，至少要一周。通过我过去一年的实践、试错和反思（上周开始思考采用新方法）。- ·软件日抛化是我在做咨询项目时被迫想出来的办法，因为客户的需求变化太快，传统开发模式根本跟不上。
- 模型协作团队是我在被AI的“幻觉”坑了无数次之后摸索出来的应对策略，单个模型不靠谱，那就让多个模型互相校验。
- 技能工程是我在重复劳动中悟出来的道理，每次都写一样的提示词太傻了，为什么不把经验封装起来？
事实上，AI只是工具。真正有价值的，是你如何使用这些工具、如何组合它们、如何在实践中形成自己的方法论。如果你也在用AI，不妨问问自己：你是在“用”AI，还是在“构建”自己的AI系统？
夜雨聆风
