Codex Magus 专家工具包使用指南

1. 先安装：下载、上传，再说“帮我安装一下”

1.1 下载安装包

文件下载位置：codex.zip

请下载与你正在使用的软件对应的 codex.zip。下载完成后，通常可以在电脑的“下载”文件夹里找到它。这里的 ZIP 就是把三个插件打包在一起的压缩文件。

1.2 把安装包上传给 Codex

1. 打开 Codex，进入可以发送消息和上传附件的聊天。
2. 把刚下载的 codex.zip 作为附件上传。可使用当前界面的附件入口；支持拖入文件时，也可以将文件拖入输入区域。
3. 确认聊天里已经显示该附件，并等待上传完成。
4. 在输入框发送下面这句话：

帮我安装一下。

5. 等待安装任务完成，阅读 Codex 返回的安装结果。

这条“直接上传 ZIP + 帮我安装一下”的安装路径，已由工具包维护者实际验证，可完成三个插件的安装。 你无需先手动解压，也无需为了按本文安装而输入命令行。

1.3 确认三个插件安装成功

安装后应可以使用以下三个专家：

专家	帮你做什么
Magus 需求分析师	把想法问清楚，整理成需求文档
Magus 解决方案设计师	根据确认的需求编写设计，制作可点击的页面原型
Magus 代码开发工程师	根据设计和原型，在目标 Magus 项目中开发功能并验证

如果安装结果没说清楚，可以接着发送：

请检查刚才的安装结果，分别告诉我以下三个插件是否安装成功、能否使用：
1. Magus 需求分析师
2. Magus 解决方案设计师
3. Magus 代码开发工程师
如果有失败项，请说明原因和下一步处理方法。

如果当前聊天还没有识别到新安装的专家，先新建聊天尝试；仍未识别时，重启客户端后再检查。暂时不要反复上传并重复安装，先让它检查已有安装及报错。

1.4 做一次简单试用

发送以下内容：

使用 $magus-requirement-analyst（Magus 需求分析师）。
我想做一个设备巡检管理功能，请先帮我梳理需求。
先解释你会怎样带我完成需求分析，再检索行业普遍案例，结合案例向我提问。

当它开始了解你的使用对象、业务目标和流程时，就可以继续后面的教程。此时只是在讨论需求，不会因为这段试用提示词就要求你先准备完整技术方案。

2. 安装后，先认识这套工具

2.1 可以把它理解成三位分工不同的同事

你负责说明业务情况、判断方案是否符合实际，并确认关键决定。三位专家分别帮助你整理需求、完成设计、实现代码。

它们之间主要通过保存下来的文件交接。即使你换了聊天，只要提供正确版本的文件，下一位专家也能知道依据是什么。

常见词	用大白话解释
插件	打包专家入口技能、专业技能及参考资源的一组可安装能力
专家	本工具包中定义角色职责、选择专业技能的入口技能（Skill）；例如需求分析师入口
技能（Skill）	指导助手完成特定任务的流程说明、规则和配套资源
工具（Tool）	当前环境提供的实际操作能力，例如搜索网页、读写文件和浏览器预览；技能指导怎样使用这些能力
需求简报	澄清过程中整理的业务结论，用来确认范围、规则和取舍；不等于正式需求文档
需求文档	写清楚谁要用、解决什么问题、有哪些规则、怎样算做完
设计文档	写清楚系统怎样组织、数据怎样流转、权限和流程怎样实现
静态交互原型	本工具包生成的单文件 HTML 页面样稿，用内存数据模拟页面和交互
前端	用户看得到、操作得到的页面
后端	处理业务、权限和数据的服务
接口	前端和后端交换数据，或系统之间协作的约定
验收	按约定逐项检查，确认功能满足要求
冻结版本 / 需求基线	已确认、带版本并作为设计依据的一版需求；业务变化后通过新需求版本调整
修订版	同一需求版本下的设计或原型调整；另存文件并保留旧版，继续标明来源需求版本
接口契约	调用路径、输入输出、响应结构等双方需要一致遵守的接口约定

这里的“三位同事”是职责比喻。Codex 通过入口技能切换工作方法，不会因此自动创建独立 Agent、新聊天或向其他聊天发送消息。

2.2 怎样调用专家

在聊天输入框中输入 $，可以唤起技能选择列表。找到并选择你要使用的专家技能，再继续输入任务内容并发送，不必手动记住或输入完整技能名称。

在聊天中写明专家名称即可表达你要使用的能力，也可以显式写出技能入口：

要做的事情	提示词中的入口
梳理需求、生成需求文档	$magus-requirement-analyst
生成设计文档、制作原型	$magus-solution-designer
开发、审查或修复代码	$magus-code-developer

如果技能选择器显示了带插件前缀的完整名称，请选择实际显示的条目。下文用短名称便于阅读；若短名称没有匹配，改用选择器中的完整名称，或明确写出中文专家名称。三个入口代表三种工作职责，可以在同一聊天中按步骤使用。

2.3 一整个需求会怎样完成

描述业务想法
    ↓
需求分析师先检索行业普遍案例
    ↓
结合行业案例分主题提问，你回答业务事实
    ↓
输出需求简报，你确认范围和规则
    ↓
按你的生成要求产出需求文档，并自动保存
    ↓
解决方案设计师编写系统设计，你评审关键选择
    ↓
生成可交互原型，你检查页面与流程
    ↓
代码开发工程师读取项目，先做平台能力预检，再完成前后端实现和验证
    ↓
你按验收条件试用，提出问题并完成修复

每一步都可以提出修改。更改业务范围时，先更新需求，再同步设计、原型和代码，避免几份产物互相矛盾。

3. 开始前准备什么

3.1 只有一个想法，也可以开始

需求阶段只要用自己的话说明问题即可。例如：

我们现在用 Excel 记录设备巡检，任务经常漏做。我想让主管分配任务，巡检员填写结果，主管能查看异常。

不需要你先懂数据库、编程语言或页面组件。已有业务表格、流程说明、截图时可以补充，没有也可以先讨论。

3.2 进入开发前，需要准备目标项目

开发专家需要知道代码应该写到哪里。请准备团队现有的 Magus 项目文件夹，并让 Codex 能够读取和修改它。只有聊天附件、没有可操作的目标代码目录时，不能视为已经具备实际开发条件。

不清楚如何打开项目或没有项目代码时，请让项目负责人提供项目和运行说明，再请专家检查。新项目也应先明确目标目录、平台依赖和运行方式。

你可以把电脑上的文件夹路径复制给它。例如 Windows 的 D:/projects/inspection，或 macOS 的 /Users/你的用户名/projects/inspection。这些都是格式示例，要换成自己的真实路径。

3.3 让文档集中保存在一个地方

本教程建议在目标项目中建立 docs 文件夹。docs 可以理解为“项目资料夹”，不需要你自己写命令创建，直接发给专家：

请在当前项目中准备 docs 文件夹，用来保存本次需求、设计和原型文件。
后续生成文件后，请告诉我保存位置，并提供可打开的文件链接。

如果还没有代码项目，可以先指定一个用于保存文档的工作文件夹；进入开发时再把文档提供给目标项目。

下面的 docs/文件名 表示“当前项目 docs 文件夹里的文件”。如果软件无法读取这个位置，请上传对应文件或提供实际完整路径。

3.4 生成文件会自动保存

明确要求生成或修订需求文档、设计文档或原型时，专家默认直接保存文件，并返回绝对路径文件链接及简短摘要。无需再说“保存下来”，也无需另行确认是否落盘。仅要求查看已有文件时，会读取或打开文件，不会自动重新生成。

• 指定目录和文件名时，优先使用你指定的位置；下文的 docs/... 用于统一整理材料。
• 未指定时，使用当前工作目录及默认名称：需求文档-<主题>-v<版本号>.md、设计文档-<主题>-v<需求版本>.md、原型-<主题>-v<需求版本>.html。
• 需求文档修订时增加版本号；同一需求版本下的设计和原型修订时增加修订后缀，保留旧文件。后缀以实际返回结果为准。
• 明确要求“仅在对话中展示，不保存文件”时，才只在对话中交付。后续需要跨聊天交接时，应再要求保存文件。

自动保存的前提是任务已经进入文件生成阶段且目标目录可写。普通需求讨论和待确认需求简报不会自动触发正式文档生成；保存失败时应先解决路径或权限问题，不能把聊天中的内容当作已保存的文件。

4. 跟着做：以“设备巡检”为例走完整个流程

以下案例只是教你怎么操作。里面的业务内容是示例，请按自己的实际情况替换；不要为了照抄教程而确认不符合实际的规则。提示词中的路径也要以实际生成的文件为准：任何一步生成修订版后，后续引用都应换成对应的新路径。

第一步：说出想法，先检索行业案例，再澄清需求

复制并发送：

使用 $magus-requirement-analyst（Magus 需求分析师）。
我想做一个设备巡检管理功能。
目前我们用 Excel 安排和记录巡检，经常发生任务漏做、异常跟进不及时的问题。
希望主管可以安排巡检任务，巡检员填写巡检结果，主管查看完成情况和异常。

请先检索行业普遍案例，再结合案例帮我开展详细需求澄清。
澄清时每轮围绕一个主题，通常提出 2–5 个关键问题；按当前问答工具的题量上限拆分。
每轮说明当前主题、已完成主题和待处理主题；没有可用问答工具时用文字提问。
遇到专业术语，请用简单的话解释。信息不足时先问我。
先不要编写系统设计或开发代码。

接下来怎么配合： 按真实情况回答它的问题。不知道的事项可以直接说“我还没确定，请给我几个选择并说明影响”。它会先检索行业普遍案例，再结合案例开展详细提问，帮助你做选择；这些参考不会自动成为你的业务规则。若检索不可用或找不到可靠案例，它应说明限制。

例如，它问“巡检员能看到哪些任务”，你可以回答：

巡检员只能看分配给自己的任务，主管能看本班组的所有任务。
跨班组的数据权限我还没确定，请先给我建议和影响。

这一步会得到： 对业务目标、用户角色、范围、流程和待确认事项的逐步梳理。你需要重点检查“它理解得对不对”，暂时不用关心代码怎么写。

第二步：确认需求简报，生成需求文档

信息充分后，专家会先输出待确认需求简报。你也可以主动让它整理：

请整理当前需求简报，让我确认。
请分开列出：已确认的内容、仍需我决定的内容、你的建议。
同时说明本期要做什么、明确不做什么，以及每项功能怎样验收。

阅读时重点看：使用人有没有遗漏、流程是否符合实际、哪些行为需要权限、异常怎么处理、本期范围是否过大。

如果内容有问题，直接说清楚修改，例如“本期先不做手机端”和“异常处理需要记录负责人和处理结果”。重要问题都解决后再发送：

使用 $magus-requirement-analyst（Magus 需求分析师）。
我确认上面的需求简报和范围，作为设备巡检 v1.0 的需求基线。
请生成正式需求文档，保存到 docs/需求文档-设备巡检-v1.0.md。
在文档中记录版本、确认状态、功能范围、业务规则和验收条件。
如仍有会影响范围或核心规则的未决事项，请先指出。

这一步会得到： 一份自动保存、可以打开的 Markdown 需求文档。.md 是普通文本格式，可在支持 Markdown 的编辑器中阅读，也可以让专家解释其中某一段。

确认简报与生成文档可以在同一条消息中完成，如上面的示例。如果你之前已要求“确认后生成需求文档”，确认完成后就可以继续生成，无需重复授权。仅确认简报而没有提出生成要求时，不会自动成文；示例中的“保存到”只是指定文件位置。

怎样判断可以继续： 需求版本清楚、你已确认业务范围、核心规则没有悬而未决，每项主要功能都有能检查的验收条件。请检查返回的文件链接，确认文档已实际保存，作为后续设计的输入。

第三步：根据需求生成系统设计

复制并发送：

使用 $magus-solution-designer（Magus 解决方案设计师）。
请读取已确认的 docs/需求文档-设备巡检-v1.0.md，生成独立的系统设计文档，
保存到 docs/设计文档-设备巡检-v1.0.md。

请覆盖系统边界、模块划分、角色权限、实体字段与关系、状态机和关键流程、
数据流、平台复用与集成、异常处理、审计、安全和非功能要求及页面清单，
并记录来源需求文件与版本，区分需求事实、设计选择和待确认假设。
设计中需要我选择的内容，请解释选项和影响。
完成后先用非技术语言概括方案，方便我评审。

如果它提示需求文件缺少确认状态或版本，请补充确认，或让需求分析师更新文件后再继续。

这一步会得到： 独立设计文档，以及设计假设和待确认项。需求文档和设计文档分别保存，方便后续追溯。

你主要看什么： 谁能看和操作哪些数据、任务经过哪些状态、主要页面有哪些、异常由谁处理，以及是否引入了没有约定的新功能。技术内容可以让它翻译成业务影响。

例如：

请用主管和巡检员的一天来解释这份设计。
告诉我每个人会看到什么、能做什么，以及任务从创建到结束的过程。

第四步：确认关键设计，生成页面原型

确认设计中的关键选择后发送：

使用 $magus-solution-designer（Magus 解决方案设计师）。
我确认 docs/设计文档-设备巡检-v1.0.md 中已评审的关键选择。
请将确认结果写入设计修订版，另存文件并保留原文件，来源需求仍为 v1.0。
请依据本次实际保存的设计修订版生成静态交互原型，
保存到 docs/原型-设备巡检-v1.0.html。

请先核对来源需求版本、列出设计中的页面、角色和交互；关键设计仍有缺口时先指出。
只按该设计修订版生成页面和交互，并采用 Magus 平台视觉规范。
请在交付说明中列出原型实际对应的需求文件、设计文件及修订号。
完成后提供文件链接，并在环境支持时打开预览。
告诉我可以怎样测试这些页面。

这一步会得到： 一个 .html 文件，也就是可以用浏览器打开的页面原型。请在当前环境支持的浏览器或预览工具中打开 HTML 文件；如果没有自动打开，可从文件链接找到它，再用本地浏览器打开。

原型用来确认页面、布局和操作流程，使用的是浏览器内存中的示例数据。它不会调用真实业务接口，不会保存真实业务记录，刷新后会恢复初始状态。原型是自包含的单文件 HTML，不使用外部资源、不发送网络请求，也不执行真实表单提交、文件上传或下载。设计中的这类功能只用于展示入口和模拟反馈。

建议怎样检查： 按设计中已包含的功能，试着切换页面、使用筛选和分页、打开详情或弹窗、模拟新增或编辑，看看流程是否顺手。不属于本次设计的功能无需为了教程补上。

发现问题时，可以这样说：

任务列表里的“负责人”不容易找到，请放到更靠前的位置。
请检查这次调整是否涉及设计文档；如涉及，请同步更新设计和原型，
保留旧文件，并告诉我后续应该使用哪个修订版本。

如果提出的是“增加审批流程”这种业务变化，应回到需求阶段确认范围，再同步后续产物。

第五步：提供项目，让开发专家完成代码

进入这一步前，确认你已打开实际项目，需求已确认、设计关键选择已确认、原型已评审，并准备好三个文件。第四步已另存设计修订版，下方“填写”项必须换成实际返回的路径；其他文件若有修订，也要替换。

使用 $magus-code-developer（Magus 代码开发工程师）。
请在当前打开的 Magus 项目中实现设备巡检功能。
输入文件如下：
- 需求：docs/需求文档-设备巡检-v1.0.md
- 设计：填写第四步实际保存、已确认的设计修订版路径
- 原型：docs/原型-设备巡检-v1.0.html
以上文件已完成对应阶段的确认。

请先读取项目说明和现有代码，检查文件版本及开发环境，
并在开发阶段先使用 magus-platform-api 做平台能力预检，复用已有平台能力。
如发现与既有设计冲突，请先说明影响、确认取舍并同步设计及原型，再实施。
然后按照设计和原型实现完整前端、后端及相关接口契约。
请使用随包的 Magus 开发技能，完成与改动有关的项目验证。
如遇到需要我决定的关键冲突，请用我能理解的话说明。
完成后告诉我改了什么、实际使用了哪些技能、平台能力复用边界、
怎样启动和试用、执行了哪些检查、哪些通过、哪些还未验证或被环境阻断。

它会怎样开展工作： 先检查现有项目和平台能力，再按实际任务使用前端、后端、组件及接口检查等技能。无需你逐一记住这些技术技能的名字。

“平台能力预检”可以理解为开发专家结合真实项目，检查已有用户、权限、字典、文件等能力能否复用，减少重复开发。它只在开发阶段执行，由开发专家在实施前完成；无需在需求、系统设计或原型阶段单独调用，也不是进入这些阶段的前置条件。

这一步会得到： 目标项目中的代码修改、验证结果、运行说明，以及需要继续处理的问题。它默认按前后端完整范围工作；如果你只要前端或后端，请在提示词中明确说明。

如果它提示缺少依赖、私有包访问权限、配置或后端服务，请把问题交给项目负责人协助补齐，再让它继续实际验证。插件提供开发规则与资料，运行依赖仍由目标项目环境提供。

第六步：按需求验收，发现问题再修复

先让开发专家给出小白也能照着做的检查步骤：

使用 $magus-code-developer（Magus 代码开发工程师）。
请根据本次已确认需求文档整理验收清单，保存到 docs/验收清单-设备巡检-v1.0.md。
每一项写清楚：使用哪个角色、先准备什么、按什么步骤操作、应该看到什么结果。
请区分你已实际验证的项目、需要我手动验证的项目和环境阻断项。
同时用分步骤的方式告诉我怎样启动并打开本次功能。

按照清单操作。测试内容应覆盖需求中的正常流程、权限限制和异常情形。例如巡检员是否只能查看自己的任务、必填项未填写时是否提示，这些规则以你最终确认的文档为准。

遇到问题时，尽量提供“操作步骤 + 预期结果 + 实际结果”，例如：

我用巡检员账号打开“我的任务”，输入任务名称后点击查询。
预期：只显示名称匹配的本人任务。
实际：列表没有变化。
请检查并修复，完成后重新验证这个场景，并说明影响范围。

怎样判断完成： 约定范围已实现，关键验收场景符合预期，验证结论清楚，剩余问题和影响已说明。页面看起来正常、原型能点击或代码能编译，都不能单独代替完整业务验收。

5. 怎样保存文件、切换聊天和交接

5.1 建议保留的文件

你的项目/
└── docs/
    ├── 需求文档-设备巡检-v1.0.md
    ├── 设计文档-设备巡检-v1.0.md
    ├── 设计文档-设备巡检-v1.0-修订1.md
    ├── 原型-设备巡检-v1.0.html
    └── 验收清单-设备巡检-v1.0.md

上面的“修订1”只是后缀示例，实际命名以专家返回的文件为准。需求仍为 v1.0 时，设计修订不代表需求变成 v1.1。

验收清单是教程建议额外生成的交付材料。每份文件都要以实际生成的版本为准；有修订时保留旧版，并明确后续使用哪一版。

5.2 不换聊天也可以按阶段推进

第一次使用时，可以在同一聊天里依次完成教程步骤，明确每次调用的专家和输入文件。每个阶段完成后都检查文件已保存，不要只依赖聊天消息。

5.3 换聊天时，重新提供文件和确认状态

不同聊天不应被当成自动共享了全部讨论。新聊天或切换专家后，请上传前阶段产物，或提供当前环境可访问的文件路径。

可以复制以下交接模板，填好再发送：

本次项目：设备巡检
当前要做的阶段：设计 / 原型 / 开发 / 验收（保留一项）
需求文件与版本：填写实际文件名和版本
设计文件、修订号及来源需求版本：填写实际文件名；尚未生成可写“无”
原型文件及对应设计修订版：填写实际文件名；尚未生成可写“无”
确认状态：哪些内容已确认，哪些仍未确认
本次目标：写清楚希望这次完成什么
项目目录：填写目标项目的实际路径
未决事项：如实填写，没有则写“无”
请先读取提供的文件再开始，不要猜测其他聊天里的结论。

6. 已有材料时，从合适的阶段开始

你手上有什么	从哪里开始
只有想法、聊天记录或零散表格	需求澄清
有需求草稿，但范围和规则未确认	先让需求分析师补齐和确认
有已确认、带版本的需求文档	系统设计
有完整设计及对应的已确认需求文档	提供需求版本和设计修订版，评审关键设计后生成原型
有已确认需求、设计修订版、匹配原型和目标代码项目	进入开发阶段，核对版本并先做平台能力预检，再实施和验证
已有功能，需要排查或修复问题	提供项目、复现步骤和预期行为；明确的现有代码修复不强求补写设计文档

如果只需要需求文档，可以完成需求阶段后结束；只需要设计和原型，也可以到原型评审完成为止。

7. 后续需求变了，怎样继续

不要只告诉开发专家“顺便加一下”就让文档失去依据。先说清变更，再评估对本期范围、权限、数据和页面的影响。

例如增加“主管审核巡检结果”：

使用 $magus-requirement-analyst（Magus 需求分析师）。
基于 docs/需求文档-设备巡检-v1.0.md，新增“主管审核巡检结果”的需求。
请先分析会影响哪些角色、状态、流程和验收条件，向我澄清关键问题。
确认后生成 v1.1 需求文档并保留 v1.0，说明本次变更。

新需求确认后，依次让设计专家生成对应 v1.1 的设计和原型，再让开发专家依据这些新文件调整代码。版本号用于区分依据，不代表每次修改都需要重新开始全部工作。

如果只调整原型列宽等展示细节，也要让专家说明是否影响设计，保留修订文件，并在交接时指出正确文件。

8. 常见问题

我需要先学会写提示词吗？

不需要。先使用本文模板，替换项目名称、真实业务描述和文件路径即可。用自然语言说明问题比堆砌专业词更有帮助。

安装后只显示一个专家，怎么办？

把安装结果发回聊天，让它检查三个插件的安装状态和可用入口。确认检查的是整个工具包，而不只是其中一个插件；必要时新建聊天或重启客户端后再试。

它一直问我问题，为什么还没生成文档？

需求专家会先补齐关键事实并输出待确认需求简报。你可以让它列出“还差哪几个决定才能成文”。确认后可以直接说“我确认以上简报，请生成需求文档”；如果你此前已要求确认后生成，就无需重复提出生成要求。普通讨论或仅确认简报不会自动等于正式成文。

生成文档后，还要再说“保存下来”吗？

不需要。需求文档、设计文档和原型生成或修订时默认直接保存。指定路径只是为了方便归档；不指定时使用当前工作目录和默认命名规则。完成后检查返回的文件链接即可。需求简报属于澄清过程，不会自动作为正式需求文档保存。

我还没决定，能先出一版看看吗？

可以明确要求“先生成标注假设的草稿”。但要区分草稿和已确认版本，后续正式设计需要明确的已确认需求依据。不能把模型的建议默认为你的业务决定。

它说找不到文件，怎么办？

检查文件名和版本是否与实际一致，再上传文件，或提供完整路径。特别是换了聊天、项目或电脑后，原来的相对路径可能不再有效。

原型里的新增记录刷新后没了，是故障吗？

这是静态原型的预期行为。原型模拟操作，刷新恢复初始数据；真正的数据保存要在开发阶段通过真实前后端实现。

我觉得页面不合适，应该找谁？

页面布局、视觉和交互先找解决方案设计师。业务流程、权限或范围变化先找需求分析师。已经开发的功能出现故障，找代码开发工程师，并提供复现步骤。

为什么开发时还要我提供项目和配置？

工具包包含专家规则和技术参考资料，不包含你的实际业务代码、私有依赖访问凭据或运行中的业务服务。开发需要结合真实项目及其环境。

我不懂运行命令和报错，怎么办？

把报错原文、运行位置和刚执行的操作发给开发专家，请它说明原因并给出下一步。如果涉及团队环境或访问权限，再请项目负责人协助。

它说“已完成”，我就可以直接上线吗？

先查看完成范围和验证记录，再按验收清单试用。“代码实现完成”“本地验证通过”“测试环境验收通过”和“生产上线”是不同状态。本教程的交付范围是需求、设计、原型、开发及验证；上线按团队实际发布流程另行安排。

9. 每个阶段结束时，照着检查

阶段	继续下一步前要确认的事情
安装	三个插件安装完成，对应专家能够识别
需求	简报已确认，已要求生成文档，文件已自动保存且带版本、确认状态
设计	对应正确需求版本，关键选择已确认，设计修订版明确
原型	页面与设计一致，主要交互已检查，使用的修订版明确
开发	已先做平台能力预检并明确复用边界，代码已写入目标项目，实际验证结果和未验证范围已说明
验收	关键业务流程符合需求，剩余问题已记录并处理或明确安排

你负责业务判断，专家负责把判断逐步整理为可评审的文件和可验证的实现。第一次使用时，按本教程一步一步发送提示词即可。

10. 补充参考

本指南的 ZIP 安装流程来自工具包维护者的实测，不同客户端中的入口显示以实际界面为准。专家职责与交接规则以随包配置为依据：

• Codex 包说明与安装方式
• 需求分析入口
• 解决方案设计入口
• 代码开发入口

技能和插件的通用概念可参考 OpenAI 官方技能说明与插件说明。这些概念说明不代替本工具包的具体阶段规则。