AI基础篇：复杂 AI Skill 的减重与边界设计

一个复杂 AI Skill 变重，往往不是因为它做得太多，而是因为它把“谁负责”“怎么做”“交付什么”“如何验证”混在了一起。

这篇文章复盘一次设计阶段 Skill 的减重实践。案例本身来自设计工作流，但真正想讨论的是一个更通用的问题：当一个 AI Skill 逐渐变成“全能角色”时，应该如何重新划分责任、方法、产物和验证边界。

问题不是 Skill 太重，而是复杂度没有归位

这次优化一开始看起来是在给一个 Skill 减重。入口文件太长，规则越来越多，设计、澄清、调查、拆解、交接都挤在一起，直觉上很容易得出一个结论：这个 Skill 太重了。

但继续往下看，会发现“重”只是表象。

真正的问题不是它拥有太多能力，而是不同性质的规则被放在了同一个位置：角色责任、工作方法、产物契约和防退化要求混在一起，让一个本该有清晰边界的 Skill，慢慢变成了什么都背在身上的“全能角色”。

所以这次实践沉淀下来的核心判断是：

复杂 AI Skill 的减重，不是删能力，而是重新安放复杂度。

也就是说，优化重点不是让 Skill 少做事，而是让它更清楚：哪些是自己必须负责的事实，哪些只是完成责任时可以调用的方法，哪些应该沉淀为稳定产物，哪些需要用验证机制防止退化。

背景：一开始解决的不是“架构问题”

最早的问题很朴素：我们希望 AI 能把一个需求整理成可实施的设计方案。

一开始，这个 Skill 很像一个单独的设计者：

用户输入需求
  -> AI 理解需求
  -> AI 写出设计方案
  -> AI 拆出任务

这个版本很轻，响应也快。但真正进入实践后，很快会遇到现实问题：

• 需求没有说清楚时，AI 会替用户补目标。
• 系统现状没有查清楚时，方案会飘在空中。
• 任务拆得太粗时，开发拿到的只是“意图”，不是可执行边界。
• 文档写得太像总结时，下游很难验证、回滚和追溯。

于是我们自然会继续加规则：

• 先澄清目标和边界。
• 做正向需求调查和反向系统调查。
• 复杂流程要画图。
• 数据模型要说明表关系。
• 接口协议要写清楚。
• 任务要能独立实施、验证和回滚。
• 用户确认前不能交付。

这些规则都对，但它们堆在一起之后，Skill 开始变味了。

它不再像一个设计者，而像一个把产品经理、架构师、技术负责人、文档作者、流程管理员都揉在一起的“大角色”。

真正的问题开始浮出来：

我们到底是在设计一个“角色”，还是在堆一份“全流程说明书”？

设计思考一：先判断复杂度属于哪里

当一个 Skill 变重时，第一个冲动往往是拆。

比如把它拆成：

• 需求澄清 Skill。
• 正向调查 Skill。
• 反向调查 Skill。
• 方案设计 Skill。
• 任务设计 Skill。
• 图形设计 Skill。

看起来很模块化，但这一步要特别小心。

因为 Skill 不是普通函数。每拆出一个 Skill，就多了一层：

• 触发条件。
• 上下文交接。
• 产物边界。
• 权限边界。
• 失败恢复。
• 责任归属。

如果一个能力只是当前角色内部的一步，把它拆成独立 Skill，主角色反而会变成调度器。这样看似瘦了，实际变成了一个更重的流程引擎。

这次实践里，真正有价值的判断不是“内容多不多”，而是：

这个能力有没有独立责任边界？

如果没有，它更应该是当前 Skill 的工作方法，而不是独立 Skill。

这也是这次实践里第一次重要转向：不是把重量切碎，而是先判断重量属于哪里。

设计思考二：先确定责任，再选择方法

后来我们把问题换了一个问法：

如果这个角色只保留一个不可替代责任，那是什么？

• 不是“写设计文档”。
• 不是“问清楚需求”。
• 不是“画图”。
• 不是“拆任务”。
• 也不是“安排下一个角色”。

这些都只是过程或产物。

它真正不可替代的责任是：

对正式设计事实的完整性、一致性、可执行性和可交付性负责。

于是 Designer 的定位就变了：

从：设计执行者
到：设计事实 Owner

这个转变很关键。

“设计执行者”会倾向于把所有设计动作都背到自己身上；“设计事实 Owner”只对最终事实是否闭环负责。

它可以调用很多方法：

• 问题框定。
• 需求双向确认。
• 双向调查。
• 汇总复核。
• 业务对齐。
• 分层拆解。
• 整体方案设计。
• 任务详细设计。

但这些是方法，不是身份。

在这个案例里，Designer 有内部流程并不代表它是流程负责人。只要它不决定外部生命周期、不改外部流程状态、不替开发或审查做结论，它就仍然是设计阶段内的事实负责人。

设计思考三：让规则回到它该在的位置

这次优化最重要的动作，不是新增规则，而是给规则找位置。

入口只放“身份和门禁”

入口文件应该像角色的宪法，而不是完整手册。

它只需要说明：

• 我什么时候被触发。
• 我负责什么。
• 我不负责什么。
• 哪些门禁不能越过。
• 最终交付什么。

比如：

需求未完成双向确认，不进入调查。
调查未复核，不生成正式设计。
用户未确认，不提交完成结果。

这些是硬边界，应该常驻。

而“怎么做需求双向确认”“怎么画数据模型”“任务类型有哪些”，不应该堆在入口里。

方法放进引用文件

方法文件承载“怎么做”。

例如需求双向确认这件事，它很重要，但它不是独立角色。它只是当前角色进入调查前用来闭合业务理解的方法。

它的规则应该放在方法库里：

• 一次只问一个关键问题。
• 每个问题给出推荐口径。
• 能从已有材料判断的事实，不反问用户。
• 不让用户决定常规技术细节。
• 用户回答后先复述理解，再进入下一分支。

这些规则越具体，越不应该塞在入口里。入口越厚，AI 越容易在无关细节里消耗注意力。

产物契约单独收口

产物契约回答的是“交付物长什么样”。

例如：

• 哪些文件由当前角色产出。
• 需求点、设计项、任务如何编号。
• 稳定锚点怎么定义。
• 追溯关系怎么保持稳定。
• 交接结构如何可解析。
• 用户确认和版本标识怎么绑定。

这些规则不能靠“尽量写清楚”。它们需要稳定、可检查、可回归。

所以产物契约应该单独放，不和工作方法混在一起。

产物只展示结果，不暴露运行规则

产物是给最终阅读者和下游角色用的，不是给 AI 运行时看的备忘录。

如果产物是文档或模板，它可以有：

• 当前现状。
• 目标效果。
• 整体方案。
• 数据模型。
• 任务详细设计。
• 验证与回滚。

但产物里不应该出现：

• “一次只问一个问题”。
• “优先这样画图”。
• “超过多少行就省略”。
• “运行时先判断什么再判断什么”。

这些是生成规则，不是产物内容。

把运行规则暴露到产物里，会让交付物变得像提示词泄漏，也会污染阅读者的关注点。

设计思考四：用责任边界决定拆分方式

到这一步，问题已经不是“要不要拆”，而是“什么情况下才配独立成 Skill”。如果已经确认需要做取舍，可以用下面 5 个问题判断：

判断问题	是	否
能不能被用户单独触发	考虑独立 Skill	更像方法
有没有独立输入和独立产物	考虑独立 Skill	更像方法
是否有独立受众	考虑独立 Skill	更像方法
是否需要独立权限边界	考虑独立 Skill	更像方法
是否能脱离当前角色上下文运行	考虑独立 Skill	更像方法

用这个标准看，很多看起来“很大”的内容，其实不该拆：

内容	这次实践中的判断
需求双向确认	不拆 Skill，作为当前角色的前置方法
正向调查	不拆 Skill，作为当前角色的调查视角
反向调查	可用隔离执行，但责任仍归当前角色汇总
方案设计	不拆 Skill，属于正式设计事实构造
任务拆解	不拆 Skill，属于设计到开发的交付边界
面向另一类受众的衍生文档	可以独立，因为受众和产物都不同

拆 Skill 的目标不是“让文件变少”，而是让责任更清楚。

如果拆完之后主角色只剩“调别人干活”，那不是减重，是把复杂度换了个地方藏起来。

所以这次实践里的减重，不是把能力删掉。需求澄清、系统调查、流程图、数据模型、任务拆解仍然存在。变化在于：这些能力不再挤在入口里扮演“角色本身”，而是退回到方法、引用和契约的位置上。

我更愿意把它理解成一句话：

减重不是让系统变简单，而是让复杂度被正确安放。

这次实践里真正想保留的理念

这次优化不是一次文件整理，而是一次 AI 协作角色设计的复盘。

我觉得有五个理念值得留下。

1. 角色不是人设，角色是责任边界

很多时候我们会把 AI 角色设计成“像某个人”：

• 像产品经理。
• 像架构师。
• 像技术负责人。
• 像文档作者。

但角色越像人，边界越容易糊。

更稳定的写法是：

这个角色对什么事实负责？
它不能越过哪些边界？
它交付给谁？
谁来审查它？

这比“你是一个资深专家”可靠得多。

2. 流程不是问题，越界才是问题

以这次 Designer 案例来说，内部有流程没有问题。

任何复杂设计都需要顺序：

先对齐目标
再调查事实
再汇总冲突
再形成方案
再拆成任务
最后确认交付

问题不在于角色内部有流程，而在于它是否开始管理外部生命周期。

只要它不改外部路由、不决定下一个角色、不替下游做裁决，它就不是流程控制器。

3. 方法可以丰富，入口必须克制

入口文件应该越读越像目录和宪法。

它需要稳定、短、硬。

真正复杂的方法放到引用文件里。这样 AI 在需要时读取，不需要时不背着跑。

这也是上下文管理的基本思想：不要让每一次任务都为所有细节付费。

4. 产物要稳定，过程要可替换

过程可以灵活，产物必须稳定。

比如需求双向确认可以是一问一答，也可以是表格，也可以是会议纪要归纳。只要最后形成同一份可追溯的需求理解，它就是合格过程。

但正式设计事实必须稳定：

• 同一个需求点能被追溯。
• 同一个设计项能被审查。
• 同一个任务能被开发实施。
• 同一个确认版本能绑定可校验标识。

AI 可以灵活，但交付不能飘。

5. eval 是理念的刹车片

好的 Skill 不能只靠说明书。

如果一个理念真的重要，就应该有防退化用例。

例如：

• 只有流程指令时，不要硬设计。
• 需求未完成双向确认时，不要提前调查和分配稳定标识。
• 调查未复核时，不要生成正式方案。
• 任务不能停留在意图描述。
• 用户未确认时，不要提交完成结果。

这些不是测试覆盖率意义上的“完整测试”，而是行为护栏。

它们提醒后续迭代者：这里不是随便改改文字，这是角色边界。

落地检查清单

如果你也在设计或重构复杂 AI Skill，可以用这张表快速自检：

检查项	要问的问题	不通过时的处理
角色责任	这个 Skill 对什么事实的完整性、一致性和可交付性负责？	先停下，不要急着写流程
责任和方法	不做这件事是否失职；换一种做法是否仍能达成结果？	责任进入口或门禁，方法进引用文件
产物契约	下游需要哪些稳定文件、字段、标识和交接结构？	从过程中抽出，形成可检查契约
拆分边界	它能独立触发、独立产出、服务独立受众并拥有独立权限边界吗？	大多是否时，先做引用文件
防退化	哪些行为最容易长回“全能角色”？	写成 eval 或固定检查项

这张表的作用不是让 Skill 变得更“规整”，而是防止每次优化都变成继续加规则。复杂度可以存在，但它要放在正确的位置。

结语

这次实践最后让我意识到：复杂 AI Skill 的设计，不是把 AI 写得更像一个全能专家，而是让它更清楚自己对什么负责。

能力可以很多，但身份必须克制。

流程可以存在，但不能越界。

方法可以复杂，但入口必须轻。

产物可以给人看，但契约必须让下游能执行。

一句话总结就是：

让角色负责，让方法按需出现，让产物稳定交付。

这就是这次以设计阶段 Skill 为案例，最终沉淀出的复杂 AI Skill 减重与边界设计。