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 减重与边界设计。