一、先从 Skill 说起：为什么"开源 skill 拿来就用"是个幻觉
占冰强： 你之前的文章里提过一个结论——Skill 可能必须定制才行。你们是基于什么场景得出这个判断的？
郭美青： 那篇文章发得比较早，是 Skill 刚出来一个多月的时候。我第一时间做了很多实践，理解它的设计范式，实际做了几个之后就发现一个问题。
Skill 的设计目标是复用。既然能复用，就有一个标准，那它就能在社区里形成生态，出现类似 Skill 市场的东西。但你会发现，比如我要做一个搜索引擎的 skill，"怎么才算搜得好"这件事本身就有讲究。以前我们可能把它包装成一个 MCP 工具，有一个标准的 query 参数就能完成搜索，本质是一个简单的 API 封装。可一旦落到场景里就不一样了：医疗搜索和金融资讯搜索，同样一个 skill，因为要去的目的地变了，你对它的评价标准也变了。医疗搜索是搜医学指南、搜论文，还是搜别的？搜中文文献，还是搜前沿的英文文献？这里面全是场景的偏好、场景的 know-how 和标准定义。
正因为标准不同，开源社区的 skill 一旦涉及场景，你就没办法直接拿来用，因为你的标准和它的标准不一样。你能拿来的，无非是一些很底层、很通用的 skill——比如网盘、存储、飞书文档这类本来就是通用工具的东西。但一进入场景化，每个人的品味、要求、业务能力都不一样，所以才有了"必须定制"这个结论。
占冰强： 那顺着说，你怎么看 Skill Marketplace 这件事，它能不能成立？
郭美青： 随着时间推移，我有种感觉：模型在慢慢地把 Skill 内化进去，尤其是那些非常好的 skill。这就导致一个很尴尬的局面——做得好的 skill 的人，最后都成了模型公司的养料。
二、"顶级阳谋"：你贡献的每一份好东西，都在给模型喂料
郭美青： 这个套路是：很多人做了非常好的 skill，又用这些 skill 吸引来一大批用户，然后共同给模型公司当养料。我当时还写过另一篇文章，讲这是一个顶级的阳谋——它明摆着在那儿，但你没有办法。做 Scale 的、做 agent 的，好像都在这个羊毛里面。
占冰强： 那站在你们公司的角度，怎么看生态里的这个位置？
郭美青： 坦诚讲，这事挺难的，整个行业都焦虑，连微软这样的公司也焦虑。Nadella 前段时间还专门写文章"喷"Anthropic：既要给他们付高昂的 token 费用，同时又给他们提供训练养料，把自己企业的所有 know-how 全贡献上去了。
难就难在，即便你完全抛开顶级模型不用、一点不贡献，你也没办法规避同行会用、会去训练。而且从训练的角度，他并不真的需要那么多数据——后训练更核心的是数据的质量，而不是体量。
占冰强： 相当于说，以前大公司把数据当资产；但现在看，提升模型在某个领域的能力，数据的体量并不重要，质量才重要。
郭美青： 对。所以你能干的，就是把模型当成一个随时可替换的东西，在它之上去构建 Harness。虽然 Harness 的一部分能力也会被内化到模型里，但一旦你构建起一个面向真实场景和真实生意的产品，这个产品包装了你对 Harness 这一层的理解，再快速去获取用户、积累品牌和用户——这可能才是你真正的壁垒。
但这个壁垒也不持久。今天你有了用户，别人跟你做一样的东西，效果比你好，瞬间又把用户抢走。所以这个时代很残酷：你既要基于场景构建出壁垒，又要飞速快跑，永远跑在最前面。
三、Skill 的本质是"补丁"，模型越强，补丁越可能变累赘
占冰强： Skill 数量一多就容易互相打架，你们怎么处理？
郭美青： 我的经验值是超过 20 个之后就要小心——当然这也看你驾驭的能力。如果不是精心组织、边界清晰，而是看到一个收一个，到一定程度一定会出问题：该用 A 的时候用了 B。我自己公共目录有 40 多个，不同项目还有专属的。关键是你能不能精心组织，并且在用的过程中洞察到误用的 case，找到问题再去修。随着模型变聪明，它走错了还会绕回来，影响其实没那么大，无非多耗一些 token。
占冰强： 但它会不会起副作用？现在很多人建议，coding 时不要再在每个文件夹下写 agent.md 那种描述文件了，因为结果反而更差。这其实反映出：模型的能力可能已经超过了很多人的认知，变成了外行指挥内行。
郭美青： 事实就是这样。Skill 本质是个补丁，是 SOP 的补丁，而且是用文字组织的。 模型学到之后，会把优质数据内化进训练，未来你原先打的补丁反倒会变成累赘。比如你当时基于旧版模型写的约束，到了新版模型，很多能力已经内化进去了，你那些约束反而成了对模型决策的束缚。
所以关键是 Skill 里的边界怎么组织。我把 Skill 分了几层：第一层是"你是谁、解决什么问题"，定位描述，任何时候都需要；第二层是"工作原则、什么能干什么不能干"，比较通用的约束；再往下是"调哪个工具、怎么调最高效"——写到这一层，你其实已经在给模型打补丁了。因为它当前跑通了，但未必是最优解，只是你此刻的经验判断。等模型变强，人家找到更高效的方法，你之前写的"怎么调工具"就多余了。
占冰强： 那就衍生出一个维护问题：辛辛苦苦做的 Skill，哪天模型能力超越了，它反而给模型拉后腿，怎么办？
郭美青： 我的经验是：首先你心里得清楚，什么是补丁，什么是真正的约束（Harness）。 然后尽量把当前的补丁"外化"出去——单独放到一个脚本或经验文件里，在主 skill.md 里用引用的方式告诉模型"参考这个文件里的工具使用经验"。等模型变强了，你把那个文件删掉就行。
我还统计过一个数据：一些挺有名的开源 agent，仓库里内置七八十个 Skill，其中大概九成只有一个 skill.md 文件——你能想象它有多粗制滥造。所以 Skill 的测评其实很重要。现在用 create skill 创建时，会默认生成一个评测目录，结束时自动跑一下看效果。但坦诚讲还很初级，因为 Skill 可大可小，复杂的东西要测评是件非常专业的事。
四、把这些新词串起来：从 PE 到 Context、Harness、Loop、Graph
占冰强： 从 Context 到 Harness、Loop，现在又冒出 Graph，造了一堆概念。这些东西各自在解决什么问题？
郭美青： 这个话题有点大，我们先把它讲清楚。每一个新名词其实都代表信息差，信息差就让大家焦虑，程序员群体尤其怕被替代。所以有必要说清楚：什么是变的，什么是不变的。
你放开去看，从 23 年 ChatGPT 出来到今天，走的是一条主线，就是 OpenAI 定的那个 AI 五级路线图：第一级 chatbot（对话），第二级 reasoner（推理），第三级 agent（代理），第四级 innovator（创新者），最后是组织者。理解了这条主线，这些事情就都简单了。
•chatbot 阶段（23 年）：模型只能多轮对话，不能干活。你跟它打交道靠的是 PE（prompt engineering），提示词调得好不好，直接决定它的理解和回答。很多人花大量时间调 PE，这些好提示词慢慢就内化到模型里了。
•reasoner 阶段（24 年年中 o1 之后）：第一次有了真正的推理模型，它会先输出一堆 thinking。这时最大的变化是：以前要长篇大论写提示词，现在你简单说一句，它就理解得很准。
•Context Engineering（24 年底起）：模型窗口长了、推理强了，怎么给它更完整的输入就成了主要工作——把工具清单描述好、把 RAG 的召回调准、把超长上下文压缩组织好。因为 agent 有一个 loop，上下文像滚雪球一样越滚越大，你得保证每一轮推理的质量。
•Harness（今年 1 月 Codex 之后）：Claude Code 代码泄漏后，大家很快复刻出自己的 agent，上下文工程都对齐了，天花板又被压到没多少提升空间。新的变量是"环境"——给 agent 准备好软件环境、网络环境，配好带领域 know-how 的 skill，处理装不上软件、版本冲突这些脏活累活。这一整坨统称 Harness。其实从 23 年做 agent 的人一直在干这些，只是后来起了个名字；核心是大多数人不懂环境、不懂沙箱和权限，所以 Harness 对他们是很大的补充。
占冰强： Harness 之后为什么又提 Loop？
郭美青： 你会发现，这一步步走下来，人一直在往后退，要参与的事情越来越少。 原来写代码你得一步步参与：告诉它做什么、让它测试、再让它发布。现在你可以一句话说完——给它一个需求文档，跟它说"帮我完整实现，再设计一套测试方案去验收，没通过就继续改，直到通过为止"。
五、Loop 不高大上，核心是"验证器"；真正不变的是 What
郭美青： 这其实就是一个 Loop。它不是什么高大上的概念，核心就是有一个验证环节。 不管你是在提示词里约束验证标准，还是自己写一套程序去验证，总归要有一个验证器。有了验证器，它就知道达没达到要求，没达到就继续转。所以一个提示词也能做 Loop，你要拆得更细，用 subagent 去做验证、把上下文隔离开也可以，它是个可大可小的概念。
占冰强： 那 Loop 的边界在哪？是不是最终取决于模型提升的边界？
郭美青： 这是个很好的问题。关键是想清楚什么是会变的——会被模型吞掉的东西都会变；不变的是 What：你要做什么，以及你判断这件事做成的标准。 这个不会变，因为每个人都不一样，模型没法假设你的标准就是它以为的那个。
写代码有个事实标准，就是"能跑起来"。但一个前端 demo 能点、能用，可能就算通过了；而一个上千万 DAU 的企业级产品，你除了功能正确，还要验证性能、安全、扩展性、编码规范，一堆维度。我们的产品分 Android、iOS、Web、H5 很多端，每个端的验证基础设施还不一样。所以"什么叫验收通过"，标准差别巨大。现在是生产力在飞速提升，但需求和标准的变化相对缓慢——所以标准在相当长一段时间里，反而是那个相对不变的东西。
占冰强： 那为什么 Graph 这一波炒作的人反而不多？
郭美青： 一方面是造词太快，Loop、Harness 到现在都才几个月。更重要的是，这些技术的受众不一样。 Context Engineering 是很底层的能力——怎么跟模型讲清楚话、怎么把上下文和知识库准备好，这对所有人都适用，它把参与门槛降到了人人可参与，是很有象征性的一步。但到了 Harness，大多数人根本不懂环境，用 AI vibe coding 出个东西已经是极限了，它离普通用户越来越远。Loop 对普通用户反而还好，因为它是一种"使用方式"，你只要定义清楚验收标准，用提示词就能完成；只有要做得专业（用多个 subagent 去编排调度）才更复杂。所以 Harness 和 Loop 有点像上一波人的圈内自嗨，没有把更多人拉进来。
占冰强： 那 Graph 到底是什么？
郭美青： 还记得扣子（Coze）吧？它是最早的编排式平台：你自己定义节点，前面一个意图识别节点做分流，后面每个节点用模型做抽取、做总结，每一步的输入输出完全受控——那个东西其实就是 Graph。今天又提 Graph，好像又回去了。包括 Claude Code 出的 Dynamic Workflow：它针对一个复杂任务，用写代码的方式先抽取出一个确定性的工作流，每一步先干嘛后干嘛，再在节点里留坑让模型自主发挥。这跟扣子没本质区别，只不过扣子是人手工编排，Dynamic Workflow 把编排交给了模型。所以我年初在 AIGCLink 分享时就判断：workflow agent 和自主 agent 今年会融合，Dynamic 就是融合的方向。
六、"品味"落到实处，就是评估标准和 benchmark
占冰强： 站在模型公司的角度，Loop 这些工程给你们解决了什么？
郭美青： 说实话，跟大家没本质区别。它是一种使用范式——模型强了之后，你不用再关注执行和实现，核心是怎么去评估它。所以我们要花更多时间去定义评估标准和评估机制，当然这本来就是模型公司的基本功。
网上很多人谈 AI 时代的"品味"，品味这个词很虚，它具象化其实就是评估标准。 你把一件事拆成几个指标——回答的正确性、是否符合人的阅读习惯——每个指标再设不同的打分等级，给它一些 rubrics、一些打分的事实标准。这就是你品味的选择。同样做医疗 agent，有些公司侧重这个，有些侧重那个。
占冰强： 所以这就形成了数据飞轮——谁能收集到足够多的真实用户意图、回答始终在头部，谁就赢；而真实的内功是你的 benchmark，你对行业 know-how 的理解全体现在里面。那你们训练和数据的投入大概是什么比例？
郭美青： 有个说法是，训练本身其实只占 5% 到 10%。为什么？因为算法工程师大量时间都在处理数据、排查 bad case、做评估，真正训练的时候无非执行一条命令，中间监督一下。打个比喻，模型公司里训练的算法工程师有点像餐厅里炒菜的师傅： 数据、benchmark 都汇到他这儿，他根据指标该炒就炒、香不香自己闻、火候到没到自己判断，然后端出去；只是备菜、买肉、买调料都有专人。
这也是为什么"What"那么难——它代表两件事：一是 know-how，二是你能不能把 know-how 变成一个可量化的评估标准。这两件是算法工程师的核心能力，得用很科学的方法去做，而不是像很多自媒体评测那样，随便丢几个 prompt、拿三五个结果对比一下。我 23 年底第一次做 AI 分享讲"企业级提示词工程"，最后落到评测标准上；今年重新整理，发现里面所有东西到今天依然适用——因为它讲的就是不变的东西。
七、几个"暴论"：模型公司像工厂，未来每家公司都有自己的模型
占冰强： 我有几个偏"暴论"的判断。第一个比喻：现在这批模型公司，有点像工业时代刚开始的那些工厂——他们造出一堆好用的、机器一样的 AI 产品；而软件行业这批人像农业，拿这些产品去"种地"。以前收十亩地要十几二十天，现在半天就够，人人都能上手。但尴尬的是：收成好不好其实跟你没关系，取决于工厂造的机器好不好。
第二个：未来这个行业容纳不了这么多人，就像工业时代来了，农业容纳不下那么多人。所以我们应该做一些"面向 AI"的事。我还有个暴论——未来模型公司可能会像今天的网站一样，每家公司都有一个。 2000 年会做网站就很牛，今天人人都有网站；再过几年，可能人人都有模型，不一定是最大的，但做个"小模型"是可以的。否则我实在想不出，搞 AI 的怎么确保自己一直不被模型公司内化。
郭美青： 而且这件事现在其实已经可以做了，只是成本问题。开源模型提供了很好的解法，但体积太大，小企业部署不了，也不一定能做推理层的优化。可你看，稍大一点、技术强一点的公司都在这么干了——不是把所有产品都去调 API，因为 API 成本太高，而且有数据出域的问题。像我们做医疗，绝不会直接调外部 API，而是自己训、或者拿小一点的开源模型做后训练。借助 Harness，很多场景任务在几百亿参数的模型上已经能解决得很好。
所以趋势很清楚：私有化部署的模型在未来几年一定是重要趋势，有人已经在提 27 年是端模型元年。小公司可以先借助 web coding；等 GPU 成本降下来、AI Infra 的推理优化再往前走，效果和成本达到一个平衡点，每个创业公司花十几万买台机器做推理服务，其实是很现实的。
占冰强： 那再往后，到了"创新者"阶段会怎样？
郭美青： 这很难预测，但可以假设。到那时 agent 一定非常自主，能记住你说过的所有事、非常了解你。前沿 AI 会去卷人类还没解决的难题——物理、数学、医学。但有个核心：AI 再强，"定义要去做什么"依然是人去定义的，AI 是辅助。你给它一个使命，比如"去解决癌症问题"，它自己用 Loop、造 Graph，最终按你认可的标准给你结论。但边界也在：很多科学创新要进实验室做实验，AI 现在做不到。
我还有个预测：智能体的下一阶段，通用模型会具备一种能力，帮你去训练你所在垂直领域的小模型——这样你拥有的是自己的数据资产，而不是把数据当养料喂给模型公司。为什么会这样？因为 Anthropic 一个方向一个方向都在干，但资源有限，它不可能在学术、医疗、法律、生物每个领域都最强。这些方向就会分化出来，就像 2000 年先有四大门户，后来搜索引擎这个变革一出，门户里的板块分化成各种细分网站。模型大概率也会分久必合、合久必分——因为创新必然来自边缘，而边缘对一个中心化组织往往是看不见的。 所以 Nadella 说马太效应越来越大，这一点我不认可，只能说明现在还非常早期。
八、给从业者的忠告：别把当下当终局，从上往下去找确定性
占冰强： 最后一个问题：很多听众也在这行从业，你能不能给大家一个忠告？我特别怕有人做了个 AI、接了两三个单，就把它当成一劳永逸的确定性抱着不放。
郭美青： 这是我纯粹的个人建议。这几年我一直在 AI 应用最前面做实践，见过太多案例，确实像占冰强说的，死一波又一波。
如果你把当前状态当成终局去构建产品，以为它能持久，现阶段是不行的。因为模型的智能是底层的基石，就像盖房子——地基还没稳你就往上盖，地基一变，上层建筑就摇摇欲坠。 所以我建议去寻找确定性。
你看今天所有 AI 工具类产品，路径都是从底向上的：先有模型能力，再往上构建工具、产品——它是技术驱动，不是业务驱动。但你反过来，如果你本身有一门生意，哪怕只是在闲鱼上卖点小东西，你就有了用户。 需求会变，但你可以把"洞察需求变化"这件事本身当成你的确定性。先把生意建起来，你和 AI 的关系就变成：我只是用它来巩固我的生意。底层技术再怎么变，你这波用户是相对确定的，你再用更好的 AI 让服务变得更好。这是一个自上向下的东西。
我们今天很多技术人都在拿着锤子找钉子：觉得 AI 这么强、我技术又强，那就造个工具。但你相当于先有产品才有用户。反过来，如果你先有一门生意，深入到行业里，再从上往下去找需要的技术——模型公司不会切到那么细分的赛道，那点收益对他们太小。等模型足够强时，你的体量也上来了，用户对你已经形成了信任，换你是有成本的。
很多产品用户一下起来，核心不是技术强，而是人家有流量、有品牌。今天市面上一堆 AI 工具其实比某些大厂产品做得更好，但它胜在切中了场景、提供了可靠稳定的工具。所以我的建议是换个思路：要创业、要做事，最好先从上往下做，不要从下往上做。
占冰强： 郭老师这个建议特别好。别天天喊"我是锤子、我要找钉子"——那钉子也不敢冒出来。要么直接去行业里拿订单，要么就深入进去找到真正有价值的问题。先别急着找产品，先做一个"成交闭环"，这可能是当下最重要的。 实在找不到，去打工修炼企业需要的能力也没问题；或者像我这样，每天做做直播，也是正经事。
