我在短时间内做了多个 Skill。最初很容易被“名字有记忆点”“页面能跑起来”带着走，但这两件事都不等于真实可用。复盘之后，我重新设定了验收标准：项目必须回应具体场景，并让没有参与开发的人也能理解、运行和检查结果。
为什么主线选择 Agent、MCP 与 Skill
截至 2026 年 8 月，几个公开信号指向同一件事：市场关注点已经从单轮聊天转向能接入工具、理解上下文并完成业务流程的智能体。微软的 Agents League 把企业 Agent、编排、数据接入、安全与实际采用放在一起考察；OpenAI 的 WebMCP Challenge 鼓励把网站能力变成 Agent 可调用的工具；Google 公布的 Gemini Live Agent Challenge 有来自 151 个国家的 1,536 个项目；国内的 火山引擎 Agent Cup 2026 也直接面向真实场景与企业命题。
这说明工具接入、上下文理解、工作流编排和安全治理正在成为共同问题。但技术热度不是结论：最终仍要回到具体场景，判断系统是否真的减少了重复劳动、错误或协作成本。
先问“谁会在什么流程里使用这个结果”，再问“我能不能用 AI 做出来”。顺序反了，项目很容易只剩演示。
先过五道真实价值筛选
- 问题够具体吗：它现在是否消耗了明确的人力、时间或风险成本？
- 谁对结果负责：使用者、审核者和最终决策者分别是谁？
- 交付物明确吗：最后得到的是报告、工作流、可运行工具，还是一句无法验收的“已优化”？
- 效果能证明吗：是否有输入输出案例、测试、局限说明和复现步骤？
- 资产能复用吗：下一次使用能否复用大部分结构，而不是每次从零开始？
六个项目，不应该套用同一种产品形态
| 项目 | 关键差异 | 更适合深入的方向 |
|---|---|---|
| vibe-project-migrator | 对存量项目做只读审计、规范迁移与证据留存 | 工程治理、团队协作、变更审计 |
| xianren-zhilu-skill | 先分析用户素材的脸部神态与动作，再匹配人物和热梗 | 多模态分析、创作工作流编排 |
| pindou-skill | 把任意图片或 3D 参考转成可施工手册，而不只是像素图 | 结构分解、约束求解、施工指导 |
| agent-skill-podium | 用官方证据维护可追溯赛果，不做来源不明的榜单 | 公开数据、来源验证、定时维护 |
| shekong-skill | 输出能直接照读的多轮预案与退出边界 | 场景建模、对话分支、安全边界 |
| moyu-skill | 纯本地模拟 Agent 流式输出，启动后零模型调用 | 跨平台终端体验与本地可视化 |
这张表最重要的作用是承认差异：有的项目核心是数据可信，有的是多模态分析，有的是复杂约束下的施工转换。只有先找到真正困难的部分，技术选择才不会变成随意堆叠。
从原型到产品的三个工程层级
1. 针对一个流程完成闭环
先围绕单一场景完成输入、处理、人工确认和输出，明确失败时如何退出。这个阶段的目标不是覆盖所有用户，而是验证最关键的技术假设。
2. 抽取可复用的 Skill 与实施手册
当多个案例出现相同结构，再把重复部分抽成模板。需要同时写清输入、输出、适用边界、真实示例和升级路线；否则所谓“复用”只是复制文件。
3. 进入持续运行的垂直系统
当需求频率、数据来源和工作流足够稳定，才适合做成托管服务。此时要补齐账号、权限、隐私、可观测性、成本控制和失败恢复，工程重点已经与 Demo 完全不同。
继续深入 Agent / MCP / Skill 工程化与 AI 项目治理；短视频和拼豆项目则作为垂直案例，用来验证素材分析、工作流编排和复杂交付物生成。
开源仓库应该保留怎样的工程证据
“熟悉大模型”很难被验证。一条完整的工程证据链更有意义：
- 为什么选择这个问题，用户与约束是什么；
- 架构和关键决策如何取舍，哪些能力刻意没有做；
- 怎样处理权限、安全、成本、失败与人工确认；
- 是否有真实输入输出、自动测试、部署地址和版本记录；
- 上线后发现了什么不足，下一轮如何改。
因此，技术博客不会只写教程。每篇文章都要尽量链接真实仓库，公开限制，记录验证结果。重点不是展示使用了多少新名词，而是还原一个判断如何变成可运行结果。