AionUi 任务模板tasks-template.md深度解析面向 AI 编码智能体的 TDD 任务拆分流水线【免费下载链接】AionUiOpen-source 24/7 Cowork app for OpenClaw, Hermes, Claude Code, Codex, OpenCode and 20 more CLI Agent | Customize your assistants | Team them upStar if you like it!项目地址: https://gitcode.com/GitHub_Trending/ai/AionUi导读本文围绕 AionUi 仓库中的 tasks-template.md 展开它是 AionUi 的 AI 辅助研发流水线中负责任务生成的核心模板把特性设计文档contracts、data-model、research自动转化为带编号、带并行标记、严格遵循 TDD 顺序的可执行任务列表tasks.md。读完本文你将掌握[ID] [P?]任务格式、五个实施阶段的编排逻辑、依赖图与并行执行规则、任务生成规则与验证清单并能结合仓库中的 plan-template.md、spec-template.md、AGENTS.md 与 package.json 看清这套模板在真实工程中的落地方式。一、模板在 AionUi 自动化研发流水线中的位置AionUi 在.specify/目录下维护了一套面向 AI 智能体Claude Code、Gemini CLI、opencode 等的规格 → 计划 → 任务 → 实施流水线tasks-template.md是其中的最后一道产物模板文件作用对应命令spec-template.md将用户描述解析为特性规格spec.md只描述 WHAT不涉及 HOW/specplan-template.md基于规格产出实施计划plan.md执行 Phase 0 研究与 Phase 1 设计/plantasks-template.md基于计划与设计文档产出任务清单tasks.md/tasksagent-file-template.md汇总各计划中的技术栈、命令与代码风格供智能体读取计划阶段增量更新从 plan-template.md 可以确认命令分工是刻意解耦的/plan命令在完成宪法检查、研究Phase 0与设计Phase 1后必须停在步骤 7明确写有 The /plan command STOPS at step 7. Phases 2-4 are executed by other commands: Phase 2: /tasks command creates tasks.md。也就是说tasks-template.md正是/tasks命令的输出规范。任务生成的前提输入在模板头部声明Input: Design documents from /specs/[###-feature-name]/ Prerequisites: plan.md (required), research.md,>1. Load plan.md from feature directory → If not found: ERROR No implementation plan found → Extract: tech stack, libraries, structure 2. Load optional design documents: →>[ID] [P?] Description[P]Parallel 标记表示该任务可并行执行前提是操作不同文件、无相互依赖。没有[P]的任务则必须串行执行。描述中必须包含精确文件路径例如Contract test POST /api/users in tests/contract/test_users_post.py路径写进任务描述既方便智能体直接定位也是并行性判断的依据见下文任务生成规则。ID 连续编号按 T001、T002…… 顺序编号编号顺序即建议执行顺序的骨架。这种ID 并行标记 带路径描述的三段式格式是模板刻意设计的机器可读契约AI 智能体无需理解模糊的自然语言指令直接按格式执行即可同时便于人类在 code review 时逐条核对。四、路径约定Path Conventions模板按项目形态预设了三套源码结构任务描述中的路径应与之匹配# Option 1: Single project默认 src/、tests/ 位于仓库根目录 # Option 2: Web application检测到 frontend backend 时 backend/src/、frontend/src/ # Option 3: Mobile API检测到 iOS/Android 时 api/src/、ios/src/ 或 android/src/模板明确说明Paths shown below assume single project - adjust based on plan.md structure即示例任务中的src/、tests/是单项目形态的占位最终路径以 plan.md 的 Project Type 判定为准。这与 plan-template.md 中 Structure Decision: DEFAULT to Option 1 unless Technical Context indicates web/mobile app 的决策逻辑衔接。在 AionUi 仓库中web 形态的判定并非空谈仓库同时包含 mobile/React Native/Expo 移动端与 packages/web-hostWeb 宿主说明同一流水线确实需要按项目类型切换结构决策。五、五个实施阶段详解Phase 3.1 – 3.5模板以Phase 3.x命名任务分组承接 plan-template.md 中 Phase 3: Task execution、Phase 4: Implementation、Phase 5: Validation 的后续阶段划分。示例任务以经典的 用户注册 鉴权 特性为样例完整清单如下。Phase 3.1Setup项目搭建任务内容T001按实施计划创建项目结构T002用 [语言] [框架] 依赖初始化项目T003[P]配置 lint 与格式化工具Setup 阶段所有任务都只涉及工程脚手架文件因此 T003 与 T001/T002 互不干扰可并行。在 AionUi 真实仓库中这类工具链要求有明确对应物AGENTS.md 规定代码质量门禁包括 oxlint、oxfmt、strict TypeScript、覆盖率 ≥ 80%package.json 提供lint/lint:fix/format脚本.pre-commit-config.yaml配置了 pre-commit 钩子lint-staged 自动格式化。也就是说模板里 T003 的产物落到仓库里就是这些具体的工具配置。Phase 3.2Tests FirstTDD⚠️ 必须在 3.3 之前完成这是整个模板的关键闸门原文以 CRITICAL 强调CRITICAL: These tests MUST be written and MUST FAIL before ANY implementation任务内容T004[P]契约测试 POST /api/userstests/contract/test_users_post.pyT005[P]契约测试 GET /api/users/{id}tests/contract/test_users_get.pyT006[P]集成测试用户注册tests/integration/test_registration.pyT007[P]集成测试鉴权流程tests/integration/test_auth.py四个测试任务操作四个不同文件全部标记[P]可一次性并行启动。测试必须先写、且必须先失败是 TDD 的硬约束——只有看到红失败才能证明测试真的在验证行为而不是空转。AionUi 仓库为这套测试分层提供了真实落点契约测试目录tests/下按unit/、integration/、e2e/分层package.json 提供test:contract脚本vitest run tests/contract --passWithNoTests集成测试目录tests/integration 中存在如migrateAssistants.realFixture.test.ts这类真实夹具驱动的测试测试框架为 Vitest 4vitest.config.tse2e 使用 Playwrightplaywright.config.ts。Phase 3.3Core Implementation仅在所有测试失败之后任务内容T008[P]User 模型src/models/user.pyT009[P]UserService CRUDsrc/services/user_service.pyT010[P]CLI --create-usersrc/cli/user_commands.pyT011POST /api/users 端点T012GET /api/users/{id} 端点T013输入校验T014错误处理与日志注意这里的并行策略T008/T009/T010 分属模型、服务、CLI 三个文件可并行而 T011/T012 依赖模型与服务T013/T014 又依赖端点实现因此不带[P]按依赖顺序串行。Phase 3.4Integration集成任务内容T015将 UserService 连接到数据库T016鉴权中间件T017请求/响应日志T018CORS 与安全响应头集成阶段开始触碰跨层横切关注点。其中 T016 与 T018 有直接依赖——安全头通常依赖鉴权中间件先行见下文依赖图。Phase 3.5Polish打磨任务内容T019[P]校验逻辑单元测试tests/unit/test_validation.pyT020性能测试要求 200msT021[P]更新文档 docs/api.mdT022消除重复代码T023运行 manual-testing.mdPolish 阶段的性能门槛200ms在 plan-template.md 中属于 Constraints 域的占位如200ms p95实际数值应由 plan.md 的领域指标决定。AionUi 仓库同样维护了性能基准设施scripts/run-benchmarks.ts、bench:startup等脚本见 package.json以及 tests/bench说明性能验证在该仓库中确实是一个独立于功能测试的检查维度。六、依赖规则与并行示例模板用两个小节固化任务的依赖与并行语义Dependencies依赖约束- Tests (T004-T007) before implementation (T008-T014) - T008 blocks T009, T015 - T016 blocks T018 - Implementation before polish (T019-T023)这些规则直接回答了执行流第 6 步生成依赖图的输出形态测试先行、模型阻塞服务与 DB 接入、鉴权中间件阻塞安全头配置、实现先于打磨。依赖图中的边一旦确定并行窗口也随之确定——只有无依赖边相连的任务才允许同时启动。Parallel Example并行启动示例模板给出了同时启动 4 个测试任务的标准姿势# Launch T004-T007 together: Task: Contract test POST /api/users in tests/contract/test_users_post.py Task: Contract test GET /api/users/{id} in tests/contract/test_users_get.py Task: Integration test registration in tests/integration/test_registration.py Task: Integration test auth in tests/integration/test_auth.py这个示例展示了并行执行示例的生成方式把每个[P]任务展开为一条独立的 Task 指令交给多个智能体实例或多线程执行器同时消费。四个测试文件互不写入天然满足[P]的前提。Notes执行纪律[P]任务 不同文件、无依赖实现前必须验证测试确实失败每个任务完成后立即提交Commit after each task避免模糊任务、同文件冲突。每任务一提交与 AGENTS.md 中的提交门禁just push会先执行 lint → format-check → typecheck → test 再推送形成呼应任务粒度越细提交越原子回滚与 review 越容易。七、任务生成规则Task Generation Rules模板末尾把如何从输入文档生成任务抽象为四条可编程规则供执行流第 3 步调用From Contracts每个契约文件 → 一个契约测试任务[P]每个端点 → 一个实现任务。From Data Model每个实体 → 一个模型创建任务[P]实体间关系 → 服务层任务。From User Stories每个用户故事 → 一个集成测试[P]快速上手场景 → 校验任务。Ordering顺序固定为 Setup → Tests → Models → Services → Endpoints → Polish依赖会阻塞并行执行。这条规则集保证了任务生成是可复现的确定性过程同一份设计文档任何时候运行/tasks都会产出结构一致的任务清单。这也是模板被设计成纯声明式无任何分支逻辑之外的智能的原因——确定性输出更容易被智能体精确执行也更容易被审查者核对。八、验证清单Validation Checklist执行流第 8 步的出口闸门落到一份可勾选的清单上所有契约都有对应测试所有实体都有模型任务所有测试都排在实现之前并行任务真正相互独立每个任务都指定了精确文件路径没有任何[P]任务与另一个任务修改同一文件。最后两条尤其值得注意它们把文件路径提升为并行正确性的第一公民——只要两个[P]任务写同一个文件无论逻辑上看起来多独立都必须降级为串行。这是避免合并冲突、保证任务可回滚的硬性判定标准。九、模板与仓库工程实践的对照tasks-template.md是通用模板但 AionUi 仓库为其注入了具体的工程约束两者对照可加深理解模板要求AionUi 仓库对应Configure linting and formatting (T003)oxlint oxfmt lint-stagedpackage.json、.pre-commit-config.yaml提交前自动格式化Contract tests (T004-T005)test:contract脚本、tests/unit 下的*.dom.test.ts(x)与契约型断言Integration tests (T006-T007)tests/integration 目录如migrateAssistants.realFixture.test.tsTests before implementationAGENTS.md 将failing tests列为硬性阻塞项Hard blockers覆盖率目标 ≥ 80%Implementation before polishAGENTS.md 的 Ratchet 规则常规特性开发不做范围外的清理No scope expansionCommit after each taskAGENTS.mdAI 智能体不得擅自推送推送走just push门禁Docs update (T021)仓库维护多语言文档体系docs/新功能需同步文档Performance validation (T020)bench:startup、scripts/run-benchmarks.ts 等基准设施此外.specify/memory/constitution.md 中 Modular commit message format (feat/fix/chore/docs/refactor)、TypeScript 全栈类型安全、模块化可测试架构等原则也为模板中每个任务粒度对应一次可验证的提交提供了治理层面的背书。十、总结与使用建议tasks-template.md的核心价值可以概括为四句话TDD 是硬约束测试任务T004-T007必须先行且必须失败实现任务T008-T014只能在红灯亮起后开始并行是显式声明只有操作不同文件的独立任务才能标记[P]同文件任务一律串行路径是正确性依据每个任务描述携带精确文件路径既是定位手段也是并行/串行判定的依据验证是出口闸门契约↔测试、实体↔模型、端点↔实现三者必须闭环否则任务清单不允许交付。对希望复刻这套工作流的团队建议按以下顺序落地先建立 spec-template.md 规格化输入 → 再以 plan-template.md 固化计划与研究 → 最后让/tasks依据本文模板生成任务清单并在每个阶段用 AGENTS.md 式的项目约定约束智能体的执行纪律。这样人类专注设计决策与验收AI 智能体专注按确定性模板高效执行两者各司其职。【免费下载链接】AionUiOpen-source 24/7 Cowork app for OpenClaw, Hermes, Claude Code, Codex, OpenCode and 20 more CLI Agent | Customize your assistants | Team them upStar if you like it!项目地址: https://gitcode.com/GitHub_Trending/ai/AionUi创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
AionUi 任务模板（tasks-template.md）深度解析：面向 AI 编码智能体的 TDD 任务拆分流水线
AionUi 任务模板tasks-template.md深度解析面向 AI 编码智能体的 TDD 任务拆分流水线【免费下载链接】AionUiOpen-source 24/7 Cowork app for OpenClaw, Hermes, Claude Code, Codex, OpenCode and 20 more CLI Agent | Customize your assistants | Team them upStar if you like it!项目地址: https://gitcode.com/GitHub_Trending/ai/AionUi导读本文围绕 AionUi 仓库中的 tasks-template.md 展开它是 AionUi 的 AI 辅助研发流水线中负责任务生成的核心模板把特性设计文档contracts、data-model、research自动转化为带编号、带并行标记、严格遵循 TDD 顺序的可执行任务列表tasks.md。读完本文你将掌握[ID] [P?]任务格式、五个实施阶段的编排逻辑、依赖图与并行执行规则、任务生成规则与验证清单并能结合仓库中的 plan-template.md、spec-template.md、AGENTS.md 与 package.json 看清这套模板在真实工程中的落地方式。一、模板在 AionUi 自动化研发流水线中的位置AionUi 在.specify/目录下维护了一套面向 AI 智能体Claude Code、Gemini CLI、opencode 等的规格 → 计划 → 任务 → 实施流水线tasks-template.md是其中的最后一道产物模板文件作用对应命令spec-template.md将用户描述解析为特性规格spec.md只描述 WHAT不涉及 HOW/specplan-template.md基于规格产出实施计划plan.md执行 Phase 0 研究与 Phase 1 设计/plantasks-template.md基于计划与设计文档产出任务清单tasks.md/tasksagent-file-template.md汇总各计划中的技术栈、命令与代码风格供智能体读取计划阶段增量更新从 plan-template.md 可以确认命令分工是刻意解耦的/plan命令在完成宪法检查、研究Phase 0与设计Phase 1后必须停在步骤 7明确写有 The /plan command STOPS at step 7. Phases 2-4 are executed by other commands: Phase 2: /tasks command creates tasks.md。也就是说tasks-template.md正是/tasks命令的输出规范。任务生成的前提输入在模板头部声明Input: Design documents from /specs/[###-feature-name]/ Prerequisites: plan.md (required), research.md,>1. Load plan.md from feature directory → If not found: ERROR No implementation plan found → Extract: tech stack, libraries, structure 2. Load optional design documents: →>[ID] [P?] Description[P]Parallel 标记表示该任务可并行执行前提是操作不同文件、无相互依赖。没有[P]的任务则必须串行执行。描述中必须包含精确文件路径例如Contract test POST /api/users in tests/contract/test_users_post.py路径写进任务描述既方便智能体直接定位也是并行性判断的依据见下文任务生成规则。ID 连续编号按 T001、T002…… 顺序编号编号顺序即建议执行顺序的骨架。这种ID 并行标记 带路径描述的三段式格式是模板刻意设计的机器可读契约AI 智能体无需理解模糊的自然语言指令直接按格式执行即可同时便于人类在 code review 时逐条核对。四、路径约定Path Conventions模板按项目形态预设了三套源码结构任务描述中的路径应与之匹配# Option 1: Single project默认 src/、tests/ 位于仓库根目录 # Option 2: Web application检测到 frontend backend 时 backend/src/、frontend/src/ # Option 3: Mobile API检测到 iOS/Android 时 api/src/、ios/src/ 或 android/src/模板明确说明Paths shown below assume single project - adjust based on plan.md structure即示例任务中的src/、tests/是单项目形态的占位最终路径以 plan.md 的 Project Type 判定为准。这与 plan-template.md 中 Structure Decision: DEFAULT to Option 1 unless Technical Context indicates web/mobile app 的决策逻辑衔接。在 AionUi 仓库中web 形态的判定并非空谈仓库同时包含 mobile/React Native/Expo 移动端与 packages/web-hostWeb 宿主说明同一流水线确实需要按项目类型切换结构决策。五、五个实施阶段详解Phase 3.1 – 3.5模板以Phase 3.x命名任务分组承接 plan-template.md 中 Phase 3: Task execution、Phase 4: Implementation、Phase 5: Validation 的后续阶段划分。示例任务以经典的 用户注册 鉴权 特性为样例完整清单如下。Phase 3.1Setup项目搭建任务内容T001按实施计划创建项目结构T002用 [语言] [框架] 依赖初始化项目T003[P]配置 lint 与格式化工具Setup 阶段所有任务都只涉及工程脚手架文件因此 T003 与 T001/T002 互不干扰可并行。在 AionUi 真实仓库中这类工具链要求有明确对应物AGENTS.md 规定代码质量门禁包括 oxlint、oxfmt、strict TypeScript、覆盖率 ≥ 80%package.json 提供lint/lint:fix/format脚本.pre-commit-config.yaml配置了 pre-commit 钩子lint-staged 自动格式化。也就是说模板里 T003 的产物落到仓库里就是这些具体的工具配置。Phase 3.2Tests FirstTDD⚠️ 必须在 3.3 之前完成这是整个模板的关键闸门原文以 CRITICAL 强调CRITICAL: These tests MUST be written and MUST FAIL before ANY implementation任务内容T004[P]契约测试 POST /api/userstests/contract/test_users_post.pyT005[P]契约测试 GET /api/users/{id}tests/contract/test_users_get.pyT006[P]集成测试用户注册tests/integration/test_registration.pyT007[P]集成测试鉴权流程tests/integration/test_auth.py四个测试任务操作四个不同文件全部标记[P]可一次性并行启动。测试必须先写、且必须先失败是 TDD 的硬约束——只有看到红失败才能证明测试真的在验证行为而不是空转。AionUi 仓库为这套测试分层提供了真实落点契约测试目录tests/下按unit/、integration/、e2e/分层package.json 提供test:contract脚本vitest run tests/contract --passWithNoTests集成测试目录tests/integration 中存在如migrateAssistants.realFixture.test.ts这类真实夹具驱动的测试测试框架为 Vitest 4vitest.config.tse2e 使用 Playwrightplaywright.config.ts。Phase 3.3Core Implementation仅在所有测试失败之后任务内容T008[P]User 模型src/models/user.pyT009[P]UserService CRUDsrc/services/user_service.pyT010[P]CLI --create-usersrc/cli/user_commands.pyT011POST /api/users 端点T012GET /api/users/{id} 端点T013输入校验T014错误处理与日志注意这里的并行策略T008/T009/T010 分属模型、服务、CLI 三个文件可并行而 T011/T012 依赖模型与服务T013/T014 又依赖端点实现因此不带[P]按依赖顺序串行。Phase 3.4Integration集成任务内容T015将 UserService 连接到数据库T016鉴权中间件T017请求/响应日志T018CORS 与安全响应头集成阶段开始触碰跨层横切关注点。其中 T016 与 T018 有直接依赖——安全头通常依赖鉴权中间件先行见下文依赖图。Phase 3.5Polish打磨任务内容T019[P]校验逻辑单元测试tests/unit/test_validation.pyT020性能测试要求 200msT021[P]更新文档 docs/api.mdT022消除重复代码T023运行 manual-testing.mdPolish 阶段的性能门槛200ms在 plan-template.md 中属于 Constraints 域的占位如200ms p95实际数值应由 plan.md 的领域指标决定。AionUi 仓库同样维护了性能基准设施scripts/run-benchmarks.ts、bench:startup等脚本见 package.json以及 tests/bench说明性能验证在该仓库中确实是一个独立于功能测试的检查维度。六、依赖规则与并行示例模板用两个小节固化任务的依赖与并行语义Dependencies依赖约束- Tests (T004-T007) before implementation (T008-T014) - T008 blocks T009, T015 - T016 blocks T018 - Implementation before polish (T019-T023)这些规则直接回答了执行流第 6 步生成依赖图的输出形态测试先行、模型阻塞服务与 DB 接入、鉴权中间件阻塞安全头配置、实现先于打磨。依赖图中的边一旦确定并行窗口也随之确定——只有无依赖边相连的任务才允许同时启动。Parallel Example并行启动示例模板给出了同时启动 4 个测试任务的标准姿势# Launch T004-T007 together: Task: Contract test POST /api/users in tests/contract/test_users_post.py Task: Contract test GET /api/users/{id} in tests/contract/test_users_get.py Task: Integration test registration in tests/integration/test_registration.py Task: Integration test auth in tests/integration/test_auth.py这个示例展示了并行执行示例的生成方式把每个[P]任务展开为一条独立的 Task 指令交给多个智能体实例或多线程执行器同时消费。四个测试文件互不写入天然满足[P]的前提。Notes执行纪律[P]任务 不同文件、无依赖实现前必须验证测试确实失败每个任务完成后立即提交Commit after each task避免模糊任务、同文件冲突。每任务一提交与 AGENTS.md 中的提交门禁just push会先执行 lint → format-check → typecheck → test 再推送形成呼应任务粒度越细提交越原子回滚与 review 越容易。七、任务生成规则Task Generation Rules模板末尾把如何从输入文档生成任务抽象为四条可编程规则供执行流第 3 步调用From Contracts每个契约文件 → 一个契约测试任务[P]每个端点 → 一个实现任务。From Data Model每个实体 → 一个模型创建任务[P]实体间关系 → 服务层任务。From User Stories每个用户故事 → 一个集成测试[P]快速上手场景 → 校验任务。Ordering顺序固定为 Setup → Tests → Models → Services → Endpoints → Polish依赖会阻塞并行执行。这条规则集保证了任务生成是可复现的确定性过程同一份设计文档任何时候运行/tasks都会产出结构一致的任务清单。这也是模板被设计成纯声明式无任何分支逻辑之外的智能的原因——确定性输出更容易被智能体精确执行也更容易被审查者核对。八、验证清单Validation Checklist执行流第 8 步的出口闸门落到一份可勾选的清单上所有契约都有对应测试所有实体都有模型任务所有测试都排在实现之前并行任务真正相互独立每个任务都指定了精确文件路径没有任何[P]任务与另一个任务修改同一文件。最后两条尤其值得注意它们把文件路径提升为并行正确性的第一公民——只要两个[P]任务写同一个文件无论逻辑上看起来多独立都必须降级为串行。这是避免合并冲突、保证任务可回滚的硬性判定标准。九、模板与仓库工程实践的对照tasks-template.md是通用模板但 AionUi 仓库为其注入了具体的工程约束两者对照可加深理解模板要求AionUi 仓库对应Configure linting and formatting (T003)oxlint oxfmt lint-stagedpackage.json、.pre-commit-config.yaml提交前自动格式化Contract tests (T004-T005)test:contract脚本、tests/unit 下的*.dom.test.ts(x)与契约型断言Integration tests (T006-T007)tests/integration 目录如migrateAssistants.realFixture.test.tsTests before implementationAGENTS.md 将failing tests列为硬性阻塞项Hard blockers覆盖率目标 ≥ 80%Implementation before polishAGENTS.md 的 Ratchet 规则常规特性开发不做范围外的清理No scope expansionCommit after each taskAGENTS.mdAI 智能体不得擅自推送推送走just push门禁Docs update (T021)仓库维护多语言文档体系docs/新功能需同步文档Performance validation (T020)bench:startup、scripts/run-benchmarks.ts 等基准设施此外.specify/memory/constitution.md 中 Modular commit message format (feat/fix/chore/docs/refactor)、TypeScript 全栈类型安全、模块化可测试架构等原则也为模板中每个任务粒度对应一次可验证的提交提供了治理层面的背书。十、总结与使用建议tasks-template.md的核心价值可以概括为四句话TDD 是硬约束测试任务T004-T007必须先行且必须失败实现任务T008-T014只能在红灯亮起后开始并行是显式声明只有操作不同文件的独立任务才能标记[P]同文件任务一律串行路径是正确性依据每个任务描述携带精确文件路径既是定位手段也是并行/串行判定的依据验证是出口闸门契约↔测试、实体↔模型、端点↔实现三者必须闭环否则任务清单不允许交付。对希望复刻这套工作流的团队建议按以下顺序落地先建立 spec-template.md 规格化输入 → 再以 plan-template.md 固化计划与研究 → 最后让/tasks依据本文模板生成任务清单并在每个阶段用 AGENTS.md 式的项目约定约束智能体的执行纪律。这样人类专注设计决策与验收AI 智能体专注按确定性模板高效执行两者各司其职。【免费下载链接】AionUiOpen-source 24/7 Cowork app for OpenClaw, Hermes, Claude Code, Codex, OpenCode and 20 more CLI Agent | Customize your assistants | Team them upStar if you like it!项目地址: https://gitcode.com/GitHub_Trending/ai/AionUi创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考