从软件开发者到 AI 架构师：这一年改变了什么

我的 AI 学习之路，并不是从什么宏大战略开始的。一切始于 Claude Code 和 skills。

起初，skills 像是那块缺失的拼图。我可以把一套工作方式写下来，然后让 AI 反复使用。一个 skill 可以教模型怎么做 code review、怎么写计划、怎么跑 workflow。感觉不像是写 prompt，更像是在创造可复用的行为模式。

就在那时，我开始对写 skill 产生了兴趣。不是因为格式有多复杂，恰恰相反——它之所以强大，正是因为简单。一个 skill 本质上就是封装了一句话：遇到这类任务，就这么干。

有那么一阵子，我觉得这就够了。

Skill 循环的问题

但 skills 用得越多，我越能感受到它的软肋。

Skill 说到底还是 prompt。

它是一个 prompt 去约束另一个 prompt，而那个 prompt 又在试图约束模型的输出。说白了，就是 prompt engineering 叠 prompt engineering。它能提高概率，让模型更有可能遵循某个流程，给模型更好的上下文。

但它没法保证结果一定发生。

这个区别很关键。"模型通常会遵循这个 skill"确实有用，但它不等于"系统保证这个流程执行过了"。如果模型漏掉了触发条件、误读了 skill、忘了边界，或者因为上下文已经被污染得太厉害而漂移了——skill 本身没什么补救手段。它只能在下一次更用力地请求。

我开始把这叫做 prompt 循环问题。你在用文字去规范一个同样靠文字运转的系统。用过 LLM 的人都知道这意味着什么：它有效，直到它失效。

试着把 skill 变成状态机

我的下一个想法是：如果 prompt 不够用，能不能把它和代码结合起来？

我开始用 skill 加 TypeScript 脚本，尝试搭一种类似状态机的 workflow。思路很简单：

Skill 识别任务
  -> 脚本执行一个具体动作
  -> 脚本返回结构化状态
  -> Skill 决定下一步
  -> 下一个脚本运行

这很接近我之前在Agent as Feature那篇文章里设想的东西。让 AI 去推理任务，但给它可以触发的具体动作。Skill 承载流程，脚本干脏活累活。一个动作的返回结果决定流程下一步往哪走。

说实话，这套东西从一开始就能跑。

但恰恰这是最让人沮丧的地方。很多想法确实能跑。它们足够让你兴奋，足够你拿去做 demo、做真实的 workflow，甚至做出有用的工具。

但"能跑"和"有保障"是两码事。

软肋还是那个：模型必须正确读取 skill、选对脚本、传对状态，然后在不漂移的前提下继续推进流程。上下文腐烂的问题依然存在。一旦对话变得嘈杂，或者模型对 workflow 建立了错误的心智模型，状态机就不像机器了，更像是一个建议。

我加了代码进去，但控制平面仍然活在模型的解释里。

用 MCP 工具替换脚本

再后来，我开始用 MCP 工具替代 TypeScript 脚本。

这感觉更自然。一个工具有名称、有描述、有 input schema、有清晰的输出结构。它更接近现代 AI 系统与外部能力交互的方式。不再是让模型记住某个脚本藏在哪儿，而是让工具成为模型可用接口的一部分。

这是进步。

工具的边界更清晰了。模型能更直接地看到能力。输入可以结构化，输出可以校验。跟藏在 skill 背后的临时脚本相比，MCP 更像是一个原生的 AI pipeline 构件。

但它并没有完全解决问题。

模型仍然要选对工具，仍然要在对的时机调用它，仍然要正确理解返回结果并决定下一步。Tool calling 给了你更好的接口，但它不会魔法般地把模型推理变成确定性执行。

可靠性确实提高了，但还没高到能改变我的结论。

我最后走到了哪里

在尝试了足够多"Agent as Feature"的实践之后，我不得不承认一件一开始不太愿意承认的事。

在当下，把大部分信任押在 LLM 上，对很多系统来说太激进了。

未来也许会变。我期待模型会更强，tool calling 会更靠谱，agent 框架会更成熟。但站在当下这个时间点，面对当下模型的行为表现，我不想让 LLM 来当关键 workflow 的控制平面。

我现在更倾向于用 SDK 来搭建定制化方案。

这不是说"别用 AI"。它的意思是，流程应该归代码管。应用来决定每一轮发生什么。SDK 调用只是流程中一个有边界的步骤。你可以校验输入、约束输出、跑 eval、记录结果、安全重试，然后由代码决定下一步动作——而不是指望模型自己把 workflow 跑对。

我现在信任的架构长这样：

代码持有状态
代码选择下一步
代码校验模型输出
代码决定继续、重试还是停止
LLM 处理有边界盒子里的模糊部分

这是我用一系列实验换来的教训。

Skill 有用，MCP 工具有用，Agent 有用。但 prompt 不是强制力，工具描述也不是治理机制。如果你需要流程按特定方式执行，就把流程放进代码里。

如果能跟更早的自己说几句话

我仍然喜欢 skill。我仍然觉得它是帮助大家更好使用 AI 的最简单方式之一。对个人用户和企业用户来说，skill 可以把可重复的实践编码化，减少他们脑子里需要记住的 prompt 知识。

但我不会再把 skill 和系统混为一谈。

Skill 是指导，工具是接口，Agent 是推理单元，而 workflow 需要一个控制平面。

这个控制平面可以是 workflow engine，可以是应用后端，也可以是自定义的 SDK 编排。关键在于：确定性的部分要保持确定性，而模型要用在它的不确定性是资产而非负债的地方。

一开始，我是被 prompt 能多大程度塑造 AI 行为这件事打动了。现在依然被打动。

但我也更谨慎了。

未来不是"用 Agent 替换一切"。未来是学会 Agent 该放在哪儿、代码该放在哪儿，以及怎么让两者协同工作——而不是假装它们是同一种东西。