mm_ai 1.0.0

package/common/work/agent/write_knowledge_prompt/prompt/method.md

@@ -0,0 +1,21 @@
+# 编写 knowledge.md 方法
+
+## 前置条件
+- [ ] 已确定知识所属领域（分组）
+- [ ] 已了解该领域的常用标签
+
+## 步骤
+
+### 1. 确定知识内容和范围
+明确要描述的知识领域，收集相关规格、标准、规范数据。
+
+### 2. 编写正文
+- 使用表格组织结构化数据
+- 使用列表组织规则和标准
+- 每个一级标题（##）聚焦一个知识领域
+
+### 3. 检查清单
+- [ ] 内容是否纯声明性（无步骤流程）
+- [ ] tags 是否能匹配目标技能/智能体
+- [ ] 表格数据是否准确完整
+- [ ] 是否有模糊表述

package/common/work/agent/write_knowledge_prompt/prompt/rule.md

@@ -0,0 +1,30 @@
+# 编写 knowledge.md 规范
+
+## 模板结构
+
+```markdown
+# 知识标题
+
+## 章节1
+- 条目1
+- 条目2
+
+## 章节2
+| 列1 | 列2 |
+|:----|:----|
+| 值1 | 值2 |
+```
+
+## 内容规范
+
+1. **纯声明性**：仅包含事实、规格、标准、规范，无步骤流程
+2. **表格优先**：能用表格表达的数据优先用表格
+3. **标签关联**：tags 必须与对应技能/智能体的标签匹配
+4. **分层组织**：用 ## 和 ### 分层，每层聚焦一个主题
+5. **无工具调用**：不出现工具名、API、代码示例
+
+## 禁止行为
+- ❌ 禁止包含 Step 1/2/3 步骤编号
+- ❌ 禁止包含工具调用和文件操作
+- ❌ 禁止包含代码示例和 API 调用
+- ❌ 禁止使用"根据需要处理"等模糊表述

package/common/work/agent/write_knowledge_prompt/prompt/trick.md

@@ -0,0 +1,16 @@
+# 编写 knowledge.md 技巧
+
+## 1. tags 的选择策略
+- 从技能的 tags 反向匹配：知识 tags 覆盖技能 tags
+- 粒度适中：太细（`button_size_12px`）太粗（`design`）都不好
+- 参考举例：`["ui_design", "icon_design", "frontend_layout"]`
+
+## 2. 数据的准确性
+常识知识会被多个团队复用，数据必须准确。不确定时标注待确认。
+
+## 3. 表格设计
+- 首列放分类/级别，第二列放值
+- 用 `:--` 左对齐、`:--:` 居中、`--:` 右对齐控制格式
+- 避免表格太宽（超过 6 列拆分为多个表）
+
+

package/common/work/agent/write_knowledge_prompt/work.json

@@ -0,0 +1,7 @@
+{
+  "name": "write_knowledge_prompt",
+  "title": "编写 knowledge.md",
+  "description": "编写 knowledge.md 常识知识提示词文件的规范、方法和技巧",
+  "version": "1.0.0",
+  "group": "agent"
+}

package/common/work/agent/write_method/prompt/method.md

@@ -0,0 +1,20 @@
+# 编写方法文档 - 方法
+
+## 步骤
+
+### 1. 确认归属
+先明确要写哪个提示词的方法文档。
+
+### 2. 填充内容
+再逐项整理：
+- 前置条件：开始前需要满足的条件
+- 流程概览：用箭头图展示完整流程
+- 详细步骤：每一步做什么，编号用「### 步骤N：」
+- 决策分支：遇到不同情况怎么走
+- 完成标准：怎么判断流程执行完毕
+
+### 3. 检查语气
+然后通读全文，确认措辞是"先做/再做/然后"的流程性表述，没有"必须/禁止"或"可以/建议"混入。
+
+### 4. 检查步骤完整性
+最后逐步检查：每一步是否写清楚了做什么、怎么做，是否有遗漏。

package/common/work/agent/write_method/prompt/rule.md

@@ -0,0 +1,25 @@
+# 编写方法文档 - 规范
+
+## 语气规范
+
+方法文档必须用 **先做A，再做B，然后做C** 等流程性措辞。禁止用"必须/禁止"（规则的语气），禁止用"可以/建议"（技巧的语气）。
+
+## 内容边界
+
+- 只关注做这件事本身的操作流程
+- 禁止混入硬性标准（归规则文档）
+- 禁止混入经验建议（归技巧文档）
+
+## 步骤规范
+
+- 步骤编号统一用「### 步骤N：」格式
+- 每个步骤写清楚做什么、怎么做
+- 示例必须是完整可运行的
+
+## 结构完整性
+
+必须包含：前置条件 → 流程概览 → 详细步骤 → 决策分支 → 完成标准。
+
+## 表述规范
+
+禁止"根据需要处理"、"按实际情况调整"等模糊表述。

package/common/work/agent/write_method/prompt/trick.md

@@ -0,0 +1,15 @@
+# 编写方法文档 - 技巧
+
+## 1. 语气快速定位法
+
+不确定内容该放哪个文档时，可以看语气词判断：方法文档看"先做/再做"，规则文档看"必须/禁止"，技巧文档看"可以/建议"。
+
+## 2. 写完通读找混入词
+
+写完后建议通读一遍，遇到"必须/禁止"标记出来移出到规则文档，遇到"可以/建议"标记出来移出到技巧文档。
+
+## 3. 容易踩的坑
+
+- 步骤写得笼统，只说"做什么"没说"怎么做"
+- 遗漏了决策分支——遇到不同情况应说明处理方式
+- 前置条件和完成标准写成一样——前置是开始前要满足的，完成是结束后要验证的

package/common/work/agent/write_method/work.json

@@ -0,0 +1 @@
+{"name":"write_method","description":"编写方法文档","type":"dynamic","group":"agent"}

package/common/work/agent/write_rule/prompt/method.md

@@ -0,0 +1,19 @@
+# 编写规则文档 - 方法
+
+## 步骤
+
+### 1. 确认归属
+先明确要写哪个提示词的规则文档。
+
+### 2. 填充内容
+再逐项整理：
+- 适用对象和范围：规则针对谁、什么场景适用
+- 规范条目：每条用"必须/禁止"表述，分类列出
+- 正反示例：每条配 ✅ 正确示例和 ❌ 错误示例
+- 违反后果：说明不遵守的后果
+
+### 3. 检查语气
+然后通读全文，确认所有措辞都是"必须/禁止/不得"，没有"建议/推荐/可以"混入。
+
+### 4. 检查表述
+最后逐句检查是否有"根据需要处理"等模糊表述，有则改为具体条件分支。

package/common/work/agent/write_rule/prompt/rule.md

@@ -0,0 +1,19 @@
+# 编写规则文档 - 规范
+
+## 语气规范
+
+规则文档必须用 **必须/禁止/不得/不能** 表述。禁止用"建议/推荐/可以"等软性措辞。每条规则都是一个明确的约束条件。
+
+## 内容边界
+
+- 只关注做这件事本身的硬性标准
+- 禁止混入操作流程（归方法文档）
+- 禁止混入经验建议（归技巧文档）
+
+## 正反示例与违反后果
+
+每条规则必须配 ✅ 正确示例和 ❌ 错误示例，示例必须完整可运行。同时说明违反后果，后果必须具体。
+
+## 表述规范
+
+禁止"根据需要处理"、"按实际情况调整"、"适当处理"、"视情况而定"等模糊表述。

package/common/work/agent/write_rule/prompt/trick.md

@@ -0,0 +1,15 @@
+# 编写规则文档 - 技巧
+
+## 1. 语气快速定位法
+
+不确定内容该放哪个文档时，可以看语气词判断：规则文档看"必须/禁止"，方法文档看"先做/再做"，技巧文档看"可以/建议"。
+
+## 2. 写完通读找软词
+
+写完后建议通读一遍，重点找"建议、推荐、可以、不妨"等软性措辞。这些词不应出现在规则文档中，应移出到技巧文档。
+
+## 3. 容易踩的坑
+
+- 规则写了"怎么做"而不是"必须做什么"——混淆了规则和方法
+- 违反后果写得太笼统——应具体到"会导致什么结果"
+- 示例用了"代码略"——应替换为完整可运行的示例

package/common/work/agent/write_rule/work.json

@@ -0,0 +1 @@
+{"name":"write_rule","description":"编写规则文档","type":"dynamic","group":"agent"}

package/common/work/agent/write_skill_json/prompt/method.md

@@ -0,0 +1,31 @@
+# 编写 skill.json 方法
+
+## 步骤
+
+### 1. 查询可用工具
+使用 `get_tool_list` 查询系统中已有的所有工具名称，确认该技能依赖的工具都在列表中。
+
+### 2. 确认信息
+确认当前技能的以下信息：
+- 技能标识名（name）：英文小写下划线，如 write_skill_json
+- 技能中文标题（title）：如"技能JSON配置编写"
+- 技能描述（description）：50字以内，含用途和触发关键词
+- 依赖工具列表（tools）：技能运行所需的**所有**工具名称
+
+### 3. 逐项填写
+按模板逐项填入：
+- name：填入技能标识名
+- title：填入技能中文标题
+- description：用一句话描述用途，末尾加"触发关键词：..."，控制在50字内
+- version：填入初始版本号 1.0.0
+- prompt_file：固定为 ./skill.md
+- tools：**必填**，填入技能依赖的所有工具名称数组
+
+### 4. 检查格式
+- tools 数组是否已填写具体工具名（非空数组）
+- 字段名是否用双引号包裹
+- 字符串值是否用双引号包裹
+- 数组各项之间是否有逗号
+- 最后一项后面是否有多余逗号
+- JSON 是否可通过 JSON.parse 校验
+- description 是否超过 50 字

package/common/work/agent/write_skill_json/prompt/rule.md

@@ -0,0 +1,50 @@
+# 编写 skill.json 规范
+
+## 模板
+
+```json
+{
+  "name": "技能标识名（英文小写下划线）",
+  "title": "技能中文标题",
+  "description": "一句话描述，50字以内，含用途和触发关键词",
+  "version": "1.0.0",
+  "prompt_file": "./skill.md",
+  "tools": ["工具名1", "工具名2"]
+}
+```
+
+## 字段说明
+
+| 字段 | 必填 | 类型 | 说明 |
+|------|:----:|:----:|------|
+| name | 是 | string | 技能标识名，限英文小写和下划线，不允许中文、数字，全局唯一 |
+| title | 是 | string | 技能中文标题，简明扼要 |
+| description | 是 | string | 一句话描述，50字以内，包含技能用途和触发关键词 |
+| version | 是 | string | 语义化版本号，格式 x.x.x，初始 1.0.0 |
+| prompt_file | 是 | string | 技能提示词文件名，固定为 ./skill.md |
+| tools | 是 | array[string] | **必填**！技能依赖的所有工具名称列表，不可为空数组 |
+
+## 核心规则
+
+### tools 字段必须填写具体工具名
+- **禁止**留空数组 `[]`，必须填写该技能运行所需的全部工具名称
+- 工具名来自系统中已有的工具（通过 `get_tool_list` 查询）
+- 示例：`"tools": ["read_work", "read_text", "write_text", "make_dir"]`
+
+### description 必须包含触发关键词
+- 在描述末尾加上"触发关键词：xxx、xxx"格式
+- 示例：`"description": "编写技能配置文件的规范。触发关键词：skill.json、技能配置"`
+
+## 格式要求
+
+- 所有字段名和字符串值必须用双引号包裹
+- 数组各项之间用逗号分隔
+- 最后一项后面不能有多余逗号
+- JSON 标准不支持注释，不得写入 // 或 /* */ 注释
+- 文件编码统一为 UTF-8
+
+## 禁止行为
+- ❌ 禁止 tools 留空数组（系统无法校验工具依赖）
+- ❌ 禁止写入 triggers 字段（系统无此字段）
+- ❌ 禁止写入 author 字段（系统无此字段）
+- ❌ 禁止在 JSON 中写注释

package/common/work/agent/write_skill_json/prompt/trick.md

@@ -0,0 +1,25 @@
+# 编写 skill.json 技巧
+
+## 1. 工具名要全
+
+从 skill.md 的执行步骤中逐一提取所有出现的工具名，不要遗漏。遗漏工具名会导致智能体运行时缺少工具而报错。
+
+## 2. 快速检查法
+
+填完后从后往前逐项检查：先看最后一项有没有多余逗号，再看数组逗号，再看字段逗号。从后往前检查最容易发现多余逗号。
+
+## 3. 描述卡字数
+
+description 写完后默数一遍，超过 50 字就删修饰词。先写核心用途，再补触发关键词，不够位置就不补。
+
+## 4. 容易踩的坑
+
+- **tools 留空数组**：忘记填工具名，系统无法校验依赖
+- name 忘记改成当前技能标识名，直接复制了模板里的示例文本
+- description 写了超过 50 字，被系统截断或校验不通过
+- version 漏了中间的次版本号，写成 1.0 而不是 1.0.0
+- tools 数组漏填了依赖工具，导致技能运行时缺少工具报错
+- prompt_file 路径写错，写成了绝对路径或少了 ./ 前缀
+- 在 JSON 里写了注释（// 或 /* */），导致 JSON.parse 报错
+- 最后一项后面多了逗号，导致 JSON 格式不合法
+- **误写 triggers 或 author 字段**（系统无此字段）

package/common/work/agent/write_skill_json/work.json

@@ -0,0 +1 @@
+{"name":"write_skill_json","description":"编写 skill.json 技能配置文件的规范、方法和技巧","type":"dynamic","group":"agent"}

package/common/work/agent/write_skill_prompt/prompt/method.md

@@ -0,0 +1,37 @@
+# 智能体提示词编写方法
+
+**描述**: 按流程编写技能提示词，确保结构完整、可执行、字数合规
+
+## 步骤
+
+### 1. 参考同类
+查看同分类技能提示词，了解写法和粒度。留意上下游依赖。
+
+### 2. 分析需求
+明确四要素：场景、输入、输出、依赖工具。
+
+### 3. 编写本体
+按模板逐章编写。
+
+```
+# 技能名称
+
+## 执行步骤
+### 步骤N：步骤标题
+> 步骤标题 = 为什么要产出这个部分
+1. 读取编写规范、方法、技巧
+2. 保存成文本文件或其他文件
+
+**输出**: 产出物说明
+**失败**: 失败处理说明
+
+## 输出成果
+1. 成果1
+
+## 禁止行为
+- ❌ 禁止...
+```
+
+> ⚠️ 注意：
+> 1. 工具名称不写在 skill.md 中，而是写在 skill.json 的 tools 数组里
+> 2. skill.md 中不写"基本信息"章节，所有元数据在 skill.json 中

package/common/work/agent/write_skill_prompt/prompt/rule.md

@@ -0,0 +1,35 @@
+# 技能提示词编写规则
+
+## 模板结构
+1. **标题**：`# 技能名称`，一级标题
+2. **步骤标题**：`## 执行步骤`
+3. **子步骤标题**：`### 步骤N：标题`
+4. **输出行**：`**输出**: 产出物说明`
+5. **失败行**：`**失败**: 失败处理说明`
+
+## 必备章节
+6. **五要素缺一不可**：描述、步骤、输出、失败、禁止行为
+7. **描述放在JSON中**：技能描述不写在 skill.md 中，写在 skill.json 的 description 字段
+
+## 关于工具
+8. **工具名不写在 skill.md 中**，而是写在 skill.json 的 tools 数组里，这样系统才能校验
+9. **每步写明工具和参数**，否则不可执行
+
+## 禁止"基本信息"章节
+10. **skill.md 中禁止写"基本信息"章节**（如名称、描述、依赖工具等）
+11. 所有元数据（name、title、description、tools、version）都放在 skill.json 中
+
+## 表述
+12. **禁止模糊表述**：不用"根据需要处理""按实际情况调整"等。用条件分支替代
+13. **子步骤内不用过渡词**：编号已表顺序
+
+## 字数
+14. **500-1000字**：超1500加载不全，不足500内容不全
+15. **超1500字拆分**：详细内容移入参考部分，主体用 `>` 引用
+
+## MECE
+16. **重叠>50%合并**，否则智能体选择混乱
+17. **重叠20%-50%抽公共**，否则重复内容易漏改
+
+## 示例
+18. **示例完整可运行**，禁止"代码略""参考上文"

package/common/work/agent/write_skill_prompt/prompt/trick.md

@@ -0,0 +1,31 @@
+# 技能提示词编写技巧
+
+## 模板写法
+1. **描述要精炼**：一句话说清"什么场景+解决什么问题"，50字内
+2. **子步骤标题用动宾结构**：如"分析需求""编写本体""检查字数"
+3. **子步骤内用动词开头**：如"列出""对比""统计"
+
+## 参考
+4. **只看同分类**：不同分类写法差异大
+5. **关注上下游**：被引用时在输出中注明格式
+
+## MECE
+6. **重叠<20%注明分工**：在禁止行为中写"本技能不处理XXX，由【技能名】负责"
+7. **功能矩阵辅助**：画技能×功能点矩阵，标记重叠区域
+
+## 表述
+8. **自问"我能照着做吗？"**：不能执行就是模糊表述
+9. **用具体命名替代泛指**：如"保存为`{项目名}_检查报告_v{版本号}`"
+
+## 瘦身
+10. **超1500字逐步移出**：先移模板→再移清单→再移示例，达标即停
+11. **优先删过渡词**："首先""然后""最后"在编号面前是冗余
+
+## 常见问题
+
+| 问题 | 原因 | 解决 |
+|------|------|------|
+| 步骤无法执行 | 缺工具或参数不明确 | 补充工具和参数 |
+| 功能重叠 | 未做MECE检查 | 合并/拆分/注明分工 |
+| 字数超标 | 未做字数检查 | 瘦身移出到参考部分 |
+| 调用错技能 | 未注明分工边界 | 写明本技能不处理什么、由谁处理 |

package/common/work/agent/write_skill_prompt/work.json

@@ -0,0 +1 @@
+{"name":"write_skill_prompt","description":"编写 skill.md 技能提示词文件的规范、方法和技巧，含模板结构、五要素检查、字数规范和MECE原则","type":"dynamic","group":"agent"}

package/common/work/agent/write_trick/prompt/method.md

@@ -0,0 +1,21 @@
+# 编写技巧文档 - 方法
+
+## 步骤
+
+### 1. 确认归属
+先明确要写哪个提示词的技巧文档。
+
+### 2. 填充内容
+再逐项整理每个技巧：
+- 适用场景：什么情况下用这个技巧
+- 具体做法：怎么操作
+- 对比说明：不用会怎样，用了会怎样
+- 注意事项：有什么坑要避开
+
+按主题分类组织多个技巧，末尾可附常见问题速查表。
+
+### 3. 检查语气
+然后通读全文，确认措辞是"可以/建议/推荐"的建议性表述，没有"必须/禁止"或"先做/再做"混入。
+
+### 4. 检查完整性
+最后逐条检查：每个技巧是否都有适用场景、具体做法、对比说明、注意事项。

package/common/work/agent/write_trick/prompt/rule.md

@@ -0,0 +1,19 @@
+# 编写技巧文档 - 规范
+
+## 语气规范
+
+技巧文档必须用 **可以/建议/推荐/不妨** 等建议性措辞。禁止用"必须/禁止/不得"（规则的语气），禁止用"先做A再做B"（方法的语气）。
+
+## 内容边界
+
+- 只关注做这件事本身的经验之谈
+- 禁止混入硬性标准（归规则文档）
+- 禁止混入操作流程（归方法文档）
+
+## 结构完整性
+
+每个技巧必须包含：适用场景、具体做法、对比说明、注意事项。
+
+## 表述规范
+
+禁止"必须/禁止/不得"等强制性措辞，禁止"先做A再做B"等流程性措辞，禁止"根据需要处理"等模糊表述。

package/common/work/agent/write_trick/prompt/trick.md

@@ -0,0 +1,19 @@
+# 编写技巧文档 - 技巧
+
+## 1. 语气快速定位法
+
+不确定内容该放哪个文档时，可以看语气词判断：技巧文档看"可以/建议"，规则文档看"必须/禁止"，方法文档看"先做/再做"。
+
+## 2. 写完通读找混入词
+
+写完后建议通读一遍，遇到"必须/禁止"标记出来移出到规则文档，遇到"先做A再做B"的流程性描述标记出来移出到方法文档。
+
+## 3. 对比说明用表格
+
+写对比说明时，建议用表格展示"不用 vs 用"的差异，从多个维度对比，让读者直观看到技巧的价值。
+
+## 4. 容易踩的坑
+
+- 技巧写成了规则——用了"必须"而不是"可以"
+- 技巧写成了方法——用了"先做A再做B"的流程表述
+- 遗漏了注意事项——只讲好处不讲坑，使用者容易踩雷

package/common/work/agent/write_trick/work.json

@@ -0,0 +1 @@
+{"name":"write_trick","description":"编写技巧文档","type":"dynamic","group":"agent"}

package/common/work/agent/write_work_json/prompt/method.md

@@ -0,0 +1,20 @@
+# 编写 work.json 方法
+
+## 步骤
+
+### 1. 确认信息
+确认当前工作项的分组和标识名。
+
+### 2. 逐项填写
+按模板逐项填入：
+- name：填入工作项标识名
+- title：填入中文标题
+- description：用一句话描述用途，控制在50字内
+- version：填入初始版本号 1.0.0
+- group：填入当前提示词的分组名
+
+### 3. 检查格式
+- 字段名是否用双引号
+- 字符串值是否用双引号
+- 数组各项之间是否有逗号
+- 最后一项后面是否有多余逗号

package/common/work/agent/write_work_json/prompt/rule.md

@@ -0,0 +1,28 @@
+# 编写 work.json 规范
+
+## 模板
+
+```json
+{
+  "name": "工作项标识名（英文下划线）",
+  "title": "工作项中文标题",
+  "description": "一句话描述，50字以内",
+  "version": "1.0.0"
+}
+```
+
+## 字段说明
+
+| 字段 | 必填 | 说明 |
+|------|:----:|------|
+| name | 是 | 工作项标识名，限英文和下划线，不允许中文、数字 |
+| title | 是 | 工作项中文标题 |
+| description | 是 | 一句话描述，50字以内 |
+| version | 是 | 版本号，格式 x.x.x |
+| group | 是 | 工作项所属分组名，限英文和下划线，不允许中文、数字 |
+
+## 格式要求
+
+- 所有字段名和字符串值必须用双引号包裹
+- 数组各项之间用逗号分隔
+- 最后一项后面不能有多余逗号

package/common/work/agent/write_work_json/prompt/trick.md

@@ -0,0 +1,15 @@
+# 编写 work.json 技巧
+
+## 1. 快速检查法
+
+填完后从后往前逐项检查：先看最后一项有没有多余逗号，再看数组逗号，再看字段逗号。从后往前检查最容易发现多余逗号。
+
+## 2. 描述卡字数
+
+description 写完后默数一遍，超过50字就删修饰词。先写核心用途，再补限定词，不够位置就不补。
+
+## 3. 容易踩的坑
+
+- name 忘记改成当前标识名，直接复制了模板里的示例文本
+- 引用顺序写成技巧在前、规则在后
+- version 漏了中间的次版本号，写成 1.0 而不是 1.0.0

package/common/work/agent/write_work_json/work.json

@@ -0,0 +1 @@
+{"name":"write_work_json","description":"编写 work.json 配置文件的规范、方法和技巧","type":"dynamic","group":"agent"}

package/common/work/design/architecture_design/prompt/method.md

@@ -0,0 +1,10 @@
+# 建筑设计方法
+
+## 流程概览
+
+分析需求 → 设计建筑
+
+## 步骤
+
+1. 分析画风指南和世界观文档
+2. 设计建筑的外观、结构和风格

package/common/work/design/architecture_design/prompt/rule.md

@@ -0,0 +1,9 @@
+# 建筑设计规范
+
+## 1. 风格一致性
+
+建筑风格必须与画风指南一致。
+
+## 2. 文化匹配
+
+建筑风格必须符合世界观中的文化设定。

package/common/work/design/architecture_design/prompt/trick.md

@@ -0,0 +1,3 @@
+# 建筑设计技巧
+
+建筑反映文化：建筑风格应体现该文明的科技水平和审美取向。

package/common/work/design/architecture_design/work.json

@@ -0,0 +1 @@
+{"name":"architecture_design","description":"设计建筑的多面外观、风格样式和空间结构","type":"dynamic","group":"design"}

package/common/work/design/art_style_guide/prompt/method.md

@@ -0,0 +1,30 @@
+# 画风设计方法
+
+## 前置条件
+
+- [ ] 已获取项目概念文档
+- [ ] 已了解项目类型和目标受众
+
+---
+
+## 流程概览
+
+```
+分析需求 → 编写画风设计文档 → 输出画风指南
+```
+
+---
+
+## 详细步骤
+
+### 步骤1：分析需求
+
+分析概念文档，了解项目类型和目标受众。
+
+### 步骤2：编写画风设计文档
+
+定义美术类别、文化风格、色彩基调、线条质感、人物画风规范、场景画风规范。
+
+### 步骤3：输出画风指南
+
+确保文档包含风格一致性检查清单。

package/common/work/design/art_style_guide/prompt/rule.md

@@ -0,0 +1,32 @@
+# 画风设计规范
+
+## 适用对象和范围
+
+本规范适用于所有定义项目整体画风的设计场景。
+
+---
+
+## 1. 画风一致性规范
+
+**规则**：同一项目禁止出现多种不兼容的画风。
+
+- ✅ 正确：所有角色、建筑、场景、道具使用同一画风
+- ❌ 错误：部分角色二次元、部分角色写实
+
+**违反后果**：画风不一致导致视觉体验混乱。
+
+---
+
+## 2. 画风引用规范
+
+**规则**：每个视觉设计文档必须注明遵循的画风指南。
+
+**违反后果**：未引用画风指南导致设计偏离风格。
+
+---
+
+## 3. 画风维度完整规范
+
+**规则**：画风设计必须覆盖美术类别、文化风格、视觉基调三个核心维度。
+
+**违反后果**：维度缺失导致画风定义不完整。