任务指令56 阅读

达灵感如何把 Skill、任务和项目连接起来

很多人一开始理解达灵感，会把它想成“Codex 提示词库”或“Skill 下载站”。这个方向可以起步，但长期看不够。因为用户真正遇到的问题不是缺一个 Skill 名称，而是不知道在自己的项目里，应该先做什么任务、用哪个 Skill、需要带上哪些项目规则，以及执行完以后如何沉淀成下一次可复用的流程。

发布时间 2026/07/07

一、为什么达灵感不能只做成一个 Skill 库

所以达灵感更适合做成一个三层系统：项目负责保存上下文，任务负责定义一次具体执行目标，Skill 负责沉淀可重复执行的方法。三者连接起来以后，用户才不是在复制零散提示词，而是在搭建自己的 Codex 工作流。

OpenAI 的 Codex 文档也能支撑这个方向：Codex 的 Skills 被定义为可复用工作流的作者格式；AGENTS.md 会在 Codex 开始工作前读取，用来给项目提供稳定规则；官方最佳实践也建议把反复使用的工作流转成 Skill，而不是反复复制长提示词。

二、先定义三者关系：项目、任务、Skill 各自负责什么

模块	负责什么	解决的问题	典型例子
项目 Project	保存长期上下文和约束	让 Codex 知道这是哪个产品、什么技术栈、什么业务规则、什么不能改	达灵感官网、设计公司官网、会员素材站、SaaS Dashboard
任务任务	描述一次明确可执行的目标	把模糊需求变成 Codex 能执行、能验收、能复盘的动作	检查首页 SEO、统一按钮样式、生成新人入职清单
Skill	沉淀高频可复用流程	减少重复提示词，让同类任务稳定按同一套步骤执行	UI 体检 Skill、CSV 报告 Skill、PR 审查 Skill、SEO 文章生成 Skill

一个简单判断方法是：项目回答“在哪个上下文里做”，任务回答“这次具体做什么”，Skill 回答“这类事以后都按什么流程做”。

三、达灵感的核心产品逻辑：不要让 Skill、任务和项目平铺

如果达灵感首页只是摆满 Skill 卡片，用户会遇到三个问题：第一，不知道自己该选哪个；第二，选了以后不知道怎么带入自己的项目；第三，执行一次以后，下次还要重新组织上下文。

更合理的结构是：用户先创建项目，再从项目里选择任务，任务再自动匹配 Skill。Skill 不直接替代任务，而是为任务提供标准化执行流程。

推荐结构：项目 Project ├─ 项目上下文：产品定位、技术栈、目录结构、业务规则、设计规范 ├─ 项目规则：AGENTS.md、命名规范、测试命令、验收标准 ├─ 任务任务 │ ├─ 一次性任务：检查首页、修复 Bug、生成报告 │ ├─ 周期任务：每周 SEO 检查、每月内容复盘 │ └─ 复杂任务：分阶段开发、重构、迁移 └─ Skill ├─ 被任务显式调用 ├─ 被任务类型自动推荐 └─ 被高频任务反向沉淀

四、用一个真实场景理解三者如何连接

假设用户有一个设计公司官网项目，他想让 Codex 检查网站 UI 是否成熟。如果达灵感只有提示词库，用户只能复制一段“帮我检查 UI”的提示词；但如果达灵感连接了 Skill、任务和项目，流程会更完整。

层级	系统里保存的内容	执行时如何发挥作用
项目	界达设计官网；服务包括 UI/UX、官网建设、品牌视觉、AI 设计服务；技术栈为 Next.js + Tailwind；不能改布局大结构。	Codex 执行任何任务前先读取这些约束，避免乱改定位和界面。
任务	检查首页哪里不像成熟设计公司官网，并输出可执行修改清单。	任务把目标、范围、输出格式和验收标准写清楚。
Skill	UI 体检 Skill：检查视觉层级、间距、按钮、卡片、文案、空状态、响应式和可访问性。	Skill 提供固定检查步骤和评分维度，保证每次检查稳定。

这样用户看到的不是一个孤立 Skill，而是一个完整动作：在某个项目里，用某个 Skill，执行一个明确任务，最后得到可以提交给 Codex 或团队执行的产物。

五、达灵感的信息架构可以这样设计

达灵感的页面和数据库结构应该围绕“从项目到任务，再到 Skill”的路径设计，而不是只围绕分类导航设计。

项目页：展示项目定位、技术栈、常用规则、已绑定 Skill、历史任务、待办任务、AGENTS.md 片段。
任务库：按照角色、场景、目标和难度组织，例如设计师、开发者、运营、HR、数据分析、客服、电商。
Skill 库：按照可复用流程组织，例如 UI 审查、SEO 审查、数据报告、PR 审查、内容生成、招聘筛选。
模板页：提供可复制的一键执行指令、任务验收清单、输出格式、AGENTS.md 规则。
连接关系：一个项目可以绑定多个 Skill；一个 Skill 可以服务多个任务；一个任务可以在不同项目中生成不同版本。

六、推荐的数据模型

如果要把达灵感做成真实产品，而不是静态文章站，至少需要以下核心表或内容模型。

模型	关键字段	作用	备注
projects	name, type, stack, goals, constraints, agents_md, references	保存项目上下文	这是任务和 Skill 的母体
tasks	title, role, scenario, input_结构化数据, output_结构化数据, acceptance_criteria	定义可执行任务	任务必须能被验收
skills	name, description, trigger_phrases, steps, files, scripts, examples	沉淀复用流程	描述要清楚触发条件
task_runs	project_id, task_id, skill_id, input, output, status, score	记录执行历史	用于复盘和改进
rules	scope, content, source, priority	保存项目规则	可转成 AGENTS.md
collections	name, user_role, use_case, item_ids	组织专题包	比如“设计师 Codex 任务包”

七、什么任务应该沉淀成 Skill

不是所有任务都应该变成 Skill。达灵感需要给用户一个明确判断标准，否则 Skill 库会越来越乱。

同一类任务已经执行 3 次以上，并且每次步骤大体相同。
每次都需要重复输入同样的规则、检查维度或输出格式。
任务有明确输入和输出，例如“输入 CSV，输出数据报告”。
任务可以形成验收标准，例如“必须输出风险等级、涉及文件、修复建议”。
任务对结果稳定性有要求，例如 PR 审查、UI 体检、上线前检查。

反过来，如果一个需求高度临时、上下文很碎、没有稳定步骤，就应该先保留为任务，而不是急着做成 Skill。

八、达灵感可以内置的连接规则

为了让系统自动推荐更准确，达灵感可以给 Skill、任务和项目设置连接规则。

按角色连接：设计师项目优先推荐 UI 审查、设计系统、落地页转化、Figma 规范类 Skill。
按技术栈连接：Next.js 项目优先推荐 App Router 检查、构建失败修复、性能优化、SEO 配置类任务。
按业务目标连接：内容站项目优先推荐 SEO 文章结构、内链检查、常见问题缺失检查、AI 搜索引用优化。
按历史行为连接：用户连续执行多次同类任务后，提示“是否沉淀为项目 Skill”。
按项目规则连接：任务执行前自动拼接项目 AGENTS.md、技术栈、目录结构和验收规则。

九、可复制的 Codex 一键执行指令

下面这些指令可以直接用于让 Codex 帮你在达灵感项目里设计或实现这个连接系统。

指令 1：梳理 Skill、任务和项目的产品关系

请你作为产品架构顾问，帮我梳理达灵感中 Skill、任务和项目的关系。项目背景：达灵感是一个围绕 Codex 工作流的任务库和 Skill 库产品，用户可能是设计师、开发者、运营、HR、数据分析师或创业者。请输出： 1. Project、任务、Skill 三者的定义 2. 三者之间的一对多 / 多对多关系 3. 用户从创建项目到执行任务再到沉淀 Skill 的完整路径 4. 首页、项目页、任务详情页、Skill 详情页分别应该展示什么 5. 哪些任务适合沉淀成 Skill，哪些不适合 6. 最后给出一版信息架构和导航结构要求： - 不要写成概念科普 - 要能落地到真实产品页面 - 输出 Markdown 结构 - 每一条建议后面说明为什么

指令 2：生成达灵感的数据模型

请你基于当前项目代码，帮我设计达灵感的数据模型。目标：把 Project、任务、Skill、任务Run、Rule、Collection 连接起来，让用户可以在一个项目里选择任务、调用 Skill、保存执行记录，并把高频任务沉淀为 Skill。请完成： 1. 检查当前项目的数据层和目录结构 2. 设计最小可用的数据模型 3. 说明每个模型的字段、类型、是否必填、默认值 4. 说明 Project 和任务、任务和 Skill、Project 和 Skill 的关系 5. 给出 TypeScript 类型定义 6. 给出前端页面需要用到的 mock data 7. 不要接入真实数据库，先用本地 mock 数据实现验收标准： - 类型命名清晰 - 字段不要过度复杂 - 支持后续迁移到 Supabase 或其他数据库 - 不影响现有页面样式和路由

指令 3：让 Codex 设计任务到 Skill 的推荐逻辑

请你为达灵感设计一个“任务推荐 Skill”的匹配逻辑。输入： - 当前项目类型 - 技术栈 - 用户角色 - 当前任务标题和描述 - 任务分类标签 - Skill 的 name、description、trigger_phrases、tags、input_结构化数据、output_结构化数据请输出： 1. 匹配规则说明 2. 推荐分数计算方式 3. 推荐理由字段 4. 前端展示文案 5. TypeScript 工具函数 6. 3 组测试样例限制： - 先不要引入向量数据库 - 先用规则匹配 + 标签权重 + 关键词匹配 - 保持代码易读，方便以后替换为 embedding 检索

指令 4：把重复任务沉淀成 Skill

请你检查当前达灵感项目中的任务数据，找出适合沉淀为 Skill 的重复任务。判断标准： 1. 同类任务出现 3 次以上 2. 输入和输出结构相似 3. 执行步骤可以标准化 4. 有明确验收标准 5. 可以被多个项目复用请输出： - 可沉淀为 Skill 的任务列表 - 每个 Skill 的 name、description、trigger_phrases - SKILL.md 初稿 - 该 Skill 应该关联哪些任务 - 哪些任务暂时不适合变成 Skill，并说明原因要求： - 不要为了数量强行生成 Skill - 每个 Skill 只解决一个清晰问题 - description 要写清楚什么时候触发，什么时候不触发

指令 5：生成项目级 AGENTS.md

请你为当前达灵感项目生成一份 AGENTS.md。请先读取项目目录结构、package.json、README、已有页面和组件，然后生成项目级规则。 AGENTS.md 需要包含： 1. 项目定位 2. 技术栈和启动命令 3. 目录结构说明 4. UI 和组件规范 5. 内容生成规范 6. 任务 / Skill / Project 三个核心概念的命名规则 7. Codex 修改代码前后的检查要求 8. 禁止事项要求： - 文件内容要短，不要超过 120 行 - 只写每次任务都应该遵守的规则 - 不要把产品文案和临时需求写进去 - 生成后说明你新增了哪些规则，以及为什么

十、达灵感页面应该怎么设计

页面设计上，达灵感要避免把用户扔进一个大列表。更好的路径是先问用户“你现在在哪个项目里工作”，再问“你现在想完成什么任务”，最后推荐“这类任务适合用哪个 Skill”。

项目首页

顶部展示项目名称、类型、技术栈、业务目标和当前进度。
中间展示推荐任务，例如“检查 SEO 结构”“统一 UI 风格”“生成内容发布计划”。
右侧展示已绑定 Skill，例如 UI 体检、SEO 审查、CSV 报告。
底部展示最近任务记录和项目规则变化。

任务详情页

说明这个任务适合谁、解决什么问题、需要输入什么、输出什么。
自动显示推荐 Skill 和推荐理由。
提供“复制给 Codex”的完整指令。
展示验收清单，避免用户只看生成结果，不知道怎么判断好坏。

Skill 详情页

说明 Skill 的适用范围和不适用范围。
展示触发语、输入格式、输出格式、执行步骤和示例任务。
允许用户把 Skill 绑定到项目。
允许用户根据项目规则生成一份定制版 Skill。

十一、AGENTS.md 与 Skill 的边界

达灵感需要特别讲清楚 AGENTS.md 和 Skill 的区别。很多用户会把二者混在一起，最后导致项目规则和任务流程都变得很臃肿。

AGENTS.md 写每次都要遵守的项目规则，例如技术栈、测试命令、命名规范、目录规则。
Skill 写某一类任务的执行流程，例如“如何做 UI 体检”“如何把 CSV 变成报告”。
任务写这次具体要做的事情，例如“检查首页卡片样式是否混乱”。
项目上下文写业务事实，例如目标用户、产品定位、品牌语气、不能改的功能边界。

一个实用原则是：如果这条规则每次打开项目都要遵守，放 AGENTS.md；如果它只在某类任务中使用，放 Skill；如果它只针对这一次需求，放任务。

十二、常见错误

错误 1：把所有提示词都叫 Skill

这会导致 Skill 失去价值。Skill 应该是可重复执行的流程，不是一句话提示词。达灵感应该鼓励用户把高频任务沉淀成 Skill，而不是把每个标题都包装成 Skill。

错误 2：项目上下文缺失

没有项目上下文，Codex 只能按通用经验回答。比如同样是“优化首页”，设计公司官网、素材会员站、SaaS 产品首页和电商详情页的判断标准完全不同。

错误 3：任务没有验收标准

任务如果只写“帮我优化一下”，结果就无法评估。达灵感里的每个任务都应该包含输出格式、约束条件和验收标准。

错误 4：Skill 太大

一个 Skill 不应该同时覆盖 SEO、UI、代码审查、内容生成和数据分析。范围越大，触发越混乱，结果越不稳定。

十三、达灵感的最终价值

达灵感的价值不在于收集最多的提示词，也不在于做一个看起来很大的 Skill 市场。真正有价值的是帮助用户把零散 AI 使用经验沉淀成项目资产。

当用户有了项目上下文，任务就不会飘；当任务有了标准输入输出，Codex 就更容易执行；当高频任务沉淀成 Skill，用户就不用每次重新组织流程。达灵感要解决的是“如何让 Codex 长期稳定地为一个项目工作”，而不是“如何写一条更长的提示词”。

所以，达灵感最适合的定位是：面向真实项目的 Codex 工作流系统。它连接项目上下文、可执行任务、可复用 Skill 和执行记录，让用户从一次性提问，升级为长期可复用的 AI 项目工作台。

十四、上线前验收清单

项目页是否能保存项目定位、技术栈、业务规则和 AGENTS.md 片段。
任务是否都有输入、输出、约束和验收标准。
Skill 是否有清晰 description、触发语、步骤和不适用范围。
任务详情页是否能自动推荐相关 Skill，并说明推荐理由。
Skill 是否可以绑定到一个或多个项目。
任务执行记录是否能保存输入、输出、状态和复盘结果。
高频任务是否能被转成 Skill 草稿。
AGENTS.md 是否只保存长期项目规则，而不是临时需求。
用户是否能一键复制完整 Codex 指令。
系统是否避免把 Skill、任务和项目平铺成三个孤立列表。

十五、参考资料

OpenAI Developers - Agent Skills: https://developers.openai.com/codex/skills

OpenAI Developers - Custom instructions with AGENTS.md: https://developers.openai.com/codex/guides/agents-md

OpenAI Developers - Codex best practices: https://developers.openai.com/codex/learn/best-practices

OpenAI Developers - Codex customization: https://developers.openai.com/codex/concepts/customization

OpenAI Developers - Model 上下文 Protocol: https://developers.openai.com/codex/mcp

Codex任务指令达灵感项目资源Skill任务项目