你激活了 sharp-skills 一个模块，但你的项目从来不是单点活儿

你激活了 sharp-skills 一个模块但你的项目从来不是单点活儿我维护 sharp-skills 一年多后台数据显示一个有意思的现象60% 以上的使用者只激活一个模块——通常是sharp-tech-writing或者sharp-copywriting挑一个用。剩下 40% 的人激活两个或三个但往往不是按业务场景激活的是看着顺眼就勾上。实际工程里单点活儿是少数。一个完整的开发任务至少跨三个品控维度你写代码注释tech-writing、写 API 文档api-design、可能还要写 changelog 或者 commit messagecopywriting。只激活一个模块剩下的两个维度 AI 会按自己的平均水准输出——没人约束它。这套系统最初设计成 6 个模块是因为品控不能一锅炖。但用户实际用起来要么单点要么全开中间状态很少。我花了大半年时间才想明白为什么并补上了一个关键的中间层模块协同层。单模块激活的两个常见问题问题一交叉污染失效。举一个具体例子。你激活了sharp-api-design希望 AI 写接口文档时遵循你的命名规范、错误码规范、cURL 示例规范。但项目同时还在用 Git工程上需要写 commit message。AI 在写 commit message 的时候完全不受api-design约束结果出来的 commit message 跟你期待的格式完全不一样feat: add user API 而不是你团队习惯的 [Backend][User-API] feat: 新增用户接口。这个问题是模块只管自己的领域。品控不应该是我管哪块就只管哪块应该是有业务交集的地方能联动。问题二模块冲突。更隐蔽的问题。你同时激活了sharp-tech-writing和sharp-copywriting。前者要求技术文档要客观、避免营销腔后者要求营销文案要有感染力、避免干巴巴。两个规则单独看都对放一起就矛盾AI 在写产品发布说明半文档半文案的时候不知道该听谁。这种冲突不是品控规则设计得不好是模块之间没说清楚优先级和场景。sharp-skills 6 个模块在内部定义里有priority和applies_to字段但用户激活的时候很少去配这两个。模块协同层的核心思路我做的是模块协同层不强制激活所有模块而是根据任务意图动态选择应该激活哪些以及它们的优先级。实现不复杂。在 Agent 调用 sharp-skills 之前加一个任务分类器——根据用户当前的输入意图决定激活哪些模块以及它们的权重。yaml协同层配置示例scenarios: - name: api_documentation trigger: [接口文档, API 文档, swagger] modules: - sharp-api-design: 1.0 # 主要约束 - sharp-tech-writing: 0.7 # 次要约束 - sharp-copywriting: 0.2 # 弱约束接口文档基本不需要营销腔name: blog_post trigger: [公众号, 博客, 技术文章] modules:sharp-copywriting: 1.0 # 主要约束sharp-tech-writing: 0.8 # 次要约束sharp-dataviz: 0.5 # 看场景激活name: code_review_comment trigger: [review, CR, 代码审查] modules:sharp-tech-writing: 1.0sharp-api-design: 0.6 关键不是这套配置本身是它解决了什么问题第一交叉污染失效的问题。API 文档场景下commit message 不属于 api-design 管的领域但因为任务意图是开发任务协同层会同时激活 tech-writing 和 copywriting低优先级来兜底。哪怕用户只勾了 api-design协同层会自动按场景补上。第二模块冲突的问题。不同场景下模块的优先级是显式声明的AI 看到的规则顺序就是优先级顺序不会两个模块规则相互打架。博客文章场景下 copywriting 在前、tech-writing 在后AI 先满足有感染力的约束再满足客观的约束。协同层设计的三个坑第一个坑协同层自己也变成规则集。我第一版做的是把协同规则也写成一组规则文件让 AI 自己根据场景判断激活哪些模块。结果可想而知——AI 经常判断错场景把 API 文档当成博客写或者反过来。协同层不该让 AI 决策应该用规则引擎或者简单的关键词匹配把意图分类做硬。python协同层的核心就是 if-else不要套 AIdef get_active_modules(user_input: str) - list: if 接口 in user_input or API in user_input: return [(sharp-api-design, 1.0), (sharp-tech-writing, 0.7)] if 博客 in user_input or 公众号 in user_input: return [(sharp-copywriting, 1.0), (sharp-tech-writing, 0.8)] # 默认技术写作主导 return [(sharp-tech-writing, 0.9)] 这 5 行代码做的事比让 AI 判断我现在该激活哪些模块靠谱 100 倍。第二个坑协同层权重配死。一开始我把所有场景的模块权重都写死在配置文件里。结果一个新场景出现就要改配置重启服务。生产环境不敢随便重启配置延迟生效最后协同层形同虚设。正确做法是把权重放在调用方的 context 里。每次调用 sharp-skills 的时候带上当前场景 当前模块权重协同层只是把这些信息组合成最终的规则列表不持久化任何东西。这样新增场景不需要改协同层本身改调用方就行。第三个坑协同层本身的可观测性。协同层一旦上线团队就会开始争论AI 这次输出为什么这样。如果协同层是黑盒团队只能去查 sharp-skills 的日志、看激活了哪些规则。最好在协同层加一个激活报告——每次调用都返回本次激活了哪些模块、为什么激活、权重是多少。这个报告跟 AI 输出一起给到调用方调试成本能降低 80%。json { scenario: api_documentation, trigger_match: [接口文档], active_modules: [ {name: sharp-api-design, weight: 1.0, rules_loaded: 24}, {name: sharp-tech-writing, weight: 0.7, rules_loaded: 18} ], context_budget_used: 12480 }有了这份报告AI 输出诡异的时候你能立刻定位到是协同层激活错了还是某个模块的规则有问题。一个被忽略的真相回到开头那个数据60% 用户只用单模块。我后来发现这不是用户的问题是产品的引导问题。sharp-skills 之前的 readme 只说6 个模块独立可用没说模块协同这件事。用户自然就一个一个用因为没人告诉他怎么用全套。加完协同层之后readme 里加了一段默认激活协同模式根据任务意图自动选择模块。如果你只想用某一个模块请显式禁用协同模式。 结果一周内协同模式使用率从 0 涨到 70%——不是技术变好了是引导变好了。很多时候品控系统做不好不是规则不够多是用户没被引导到正确的使用方式上。品控工具的设计者和使用者之间有一道认知鸿沟规则写得再漂亮跨不过去也是白搭。我在做一个用卡皮巴拉讲设计模式的微信小程序「爪爪代码冒险记」23 个设计模式用漫画 答题的方式讲目前正在开发中。如果你觉得这类内容有意思搜一下「爪爪代码冒险记」或者等我后面的文章。