MCP 和 Skills 不是按场景二选一，而是先看结果、再看它是否真省 context：官方 MCP/CLI 简单但结果杂乱、几轮就撑满窗口时，才值得自己做成 Skill。
AI根据立正公开的文章和视频整理，不是他本人回复。重要的判断，请回到出处核对。
先问结果，别先追名词
材料里的观点有人去年跟领导推 MCP，今年觉得 MCP 不好用要换 Skills，结果领导刚听懂 MCP，就要求所有东西都做成 MCP。只盯零件和概念、不盯结果，往往适得其反1。所以选型前先问：这个任务要的产出是什么、验收标准是什么，而不是先决定用哪个协议。MCP 是让 AI 调用外部工具的标准接口，Skills 更像把一套做法和知识打包给 AI 复用；两者解决的不是同一层问题。
官方 MCP 够用就别自建
材料里的观点Tally 官方有 MCP 和 CLI，配置更简单，但这类上一代做法有个通病：搜索结果杂乱，必须整段进 AI 的上下文窗口，没几轮就撑满，于是频繁压缩、抓不住重点、幻觉变多2。如果任务简单、调用次数少、结果干净，直接用官方 MCP 或 CLI 最省事；只有当它反复把窗口塞满、AI 找不到重点时，才值得改成先落盘、让 AI 自己选择读哪部分的做法2。判断标准是 context 是否被浪费，不是哪个名字更新。
把工具做成 AI 能用的样子
把产品做成 Skill，意味着从“给人用的界面”转向“给 AI 调用的原子能力”，让 Agent 无需切窗口就能直接操作3。这比接一个聊天框难，因为它要求团队真正理解 AI 的推理和调用边界3。适合这么做的，是那些会被 Agent 反复调用、且结构化调用比人点界面更准的场景；如果只是偶尔用一次、或团队还没搞清 AI 擅长什么，先接个对话入口、用真实任务测一测更划算。
材料没有给出按团队规模或项目类型选型的通用标准，上面的判断只适用于“结果是否干净、context 是否被浪费”这一条线索。
出处
- 1AI的正确打开方式：不学概念，学动作
用 MCP 与 Skills 反复横跳的实例，说明只追概念不看结果的代价，适合先读。
- 2课代表和鸭哥工作的实况 | how the sausage is made
对比官方 MCP/CLI 与自建 Skill 在 context 占用上的差别，适合判断何时该自建。
- 3如果你在旧系统上贴个聊天框，那说明你们团队并不真懂AI
解释把产品做成 AI 可调用 Skill 的方向和门槛，适合判断团队该不该投入重构。
你也有想问的？
卡住的时候，问问立正：回答只从立正讲过、写过的东西里来，每一段都能点回原文。
问类似的问题也可以接着问：
别人还问了
- 如何用 AI 辅助 产品设计
用 AI 做产品设计，关键不是让 AI 画图或写代码，而是把 AI 放进产品运行过程里承担任务，并把自己的判断标准写成 AI 能读的上下文。
- 什么是创意？创意也是对现有元素的组合排列吗？是的话，在这种情况下，怎么判断一个点子是否是真正创新的创意？最后如何获得创意？
创意可以看成对现有元素的重新组合，但判断它是否真创新，要看它是否解决了一个此前没被满足的真实需求；获得创意的路径是靠近真实问题、快速交给现实修正，而不是坐在房间里凭空想点子。
- 如何能找到building的第一个东西
先做一个能跑通的最小版本，用它来发现你原本看不见的需求；building 是习惯，不是一次学会的知识。
- 想做的事情太多，身边的噪音也太多，害怕选择了一条路放弃了别的东西，什么都想抓住，到头来什么都做不好。ai时代日新月异，该如何保持well informed，同时找到并且坚定自己的conviction
先分清哪些是决定方向的层级、哪些只是执行方法，再把“保持知情”当成筛选信息的能力而非追新；信念感来自对底层逻辑的理解，不是靠意志硬撑。
- 如何有效的整合和利用数据？
整合数据的关键不是把数据堆在一起，而是先建立对业务、产品和用户的正确心智模型，再用实验检验每个改动，让数据回答它真正能回答的那部分决策。
- Ai平权下，资源更值钱，那么学习知识的目的是什么
AI让知识本身不再稀缺，学习的目的从「记住答案」转向「能判断、能行动、能交换」——用行动和思考引领求知，而不是先囤知识。