OneX Harness AI Coding 工具介绍

• OneX 平台：一个面向AI时代的知识平台，12+ 高质量体系课、4+ 实战项目，涵盖 Go、云原生、AI 。
• 哔哩哔哩：令飞编程 ，分享技术、职场、面经等。

过去半年一直在用 AI 写代码，今天来分享下在 AI Coding 过程中的一些思考和实战。给 Harness AI Coding 提供一些新的思路，希望对大家有所帮助。

AI Coding 的一些感受

AI Coding 的一些好

AI 写代码的能力确实很强，我日常的开发模型用的是 claude-sonnect-4-6 和 deepseek-v4-pro。看 token 使用情况和任务复杂度，进行切换。目前基本上 AI 能够完成 80%的开发需求，经过简单的 review 即可验收通过，并上线。

在一些方案设计上，AI 也能够给出很多不错的方案。但仍然有不少方案，需要自己去设计，或者跟 AI 进行多轮对话进行优化。

整体上来看，仅仅从编码能力和简单的架构设计上来看，AI 的 Code 能力已经超过了初中级开发工程师。甚至，我有时候觉得，一个大的平台项目中，只需要有 2 个人类 + 一个 Agent 即可：

• **资深开发/架构师：**负责项目的核心架构设计、功能设计和开发。将整个项目的框架开发好，构建出完整的 AI 约束框架；
• **Agent（例如：Claude Code）：**协助资深/初级开发工程师完成各类功能开发；
• 一个初中级开发工程师：负责落地一些非核心的功能，并且完成一些 AI 做不了的工作，例如：服务部署、云资源申请、网络打通的运维类工作。也就是初中级开发工程师负责给 AI 兜底。

上面这些我感觉挺残酷的，但挺无奈的，这可能就是现状，AI 给程序员确确实实带来了一些冲击。

AI Coding 的一些不好

上面介绍了 AI Coding 好的一面，这里来介绍下 AI Coding 不好的一面，并在后文给出我的实践方式。这些实践方式，除了解决 AI Coding 带来的各种问题之外，还会将 AI Coding 的能力向前推进一大步。

以下是我使用 AI 开发过程中遇到的一些问题：

• **开发风格不统一：**在一个项目中，AI 往往倾向于遵循既有的代码风格、架构，所以在一个项目中这种不一致问题较小。但是如果我们将目标放在小组、部门，甚至公司维度。就会发现每个 AI Code 的项目风格和实现方式很不一致。既然不一致那就不规范。而且不同项目中的组件复用、包复用、错误码规范等等，都不一样。当 AI 能力够强的时候，我们其实需要从更大范围去提高代码质量。另外开发者都可能会有自己的 SKILL、MCP Tool，这些 SKILL、MCP Tool 也不能形成标准，团队统一。另外这些 SKILL、MCP Tool 的分发也存在一定的复杂度。
• **有很多无意义的防御性代码：**AI 写的代码有很多防御性编程代码，在我看来很多是不需要的，反而会使代码越来越臃肿；
• **规范约束要重复的通过 Prompt 强调：**在同一个项目中需要不断的添加新功能，另外应用开发中，往往也需要新开发多个服务。每一个功能或服务，都需要跟 AI 强调规范、约束。在一个新服务中，介绍规范、约束的 Prompt 可能要更细、更多。作为一个懒惰的程序员，我希望自己不用再重复的去给 AI 喂规范；

上面，是我在 AI Coding 的过程中遇到的一些问题。中间有一些尝试，也有不错的效果，下面分享下。

从非AI时代找答案

AI 当前的能力形态，本质上是一个"拥有超强记忆力、极快编码速度、但在系统全局设计和复杂逻辑上缺乏经验的初中级工程师。

当前 AI 的编程能力总结如下：

• 简单项目/功能：简单项目编码影响大，AI Coding 能力 > 高级开发工程师（主要是从效率、规范度、实现方案、考虑异常等方面）；
• 复杂项目：复杂项目更考验设计能力，AI Coding 能力 <= 高级工程师。AI 因为上下文限制、注意力、领域知识专业度等存在一些短板，在综合设计能力上还达不到经验丰富的 Go 高级/专家开发工程师水平。

综上，AI 当前的 Coding 能力，其实是 <= 高级开发工程师的。跟初中级开发工程师的区别最大在于其自动化编码能力及编码速度上。但是从代码质量上其实面临的问题跟非 AI 时代初中级开发工程师面临的问题是一样的。

从非AI时代的成熟解法

既然 AI 面临的代码质量问题（破坏架构、忽略边缘条件、缺乏全局视野、风格不统一）与传统软件工程中初中级工程师面临的问题高度一致，那么软件工程几十年来积累的"团队管理与质量管控体系"，就是解决 AI Coding 问题的最佳药方。

在传统的软件工程中，资深架构师/Tech Lead 绝不会依赖初中级工程师的"自觉"来保证代码质量，而是通过一套工程化体系来对其进行约束和赋能。这套体系的核心手段包含以下 5 个维度：

• 开发能力：

  • Code 能力：
  • 开发方法论、设计模式：
  • 架构、方案设计能力：

• 规范约束：各种类型的开发规范。通过规范，除了能够提高开发者的代码质量之外，还能够确保全公司、全团队具有一致的开发风格、架构设计模式，有利于团队级别降低代码维护的成本。

• 开发脚手架：固化代码架构、开发规范等，在一定程度上确保开发风格、架构模式的强一致；

• 代码审查：

  • 自动化质量网关（各种 Lint 工具）：
  • Code Review：人工的 Code Review。

• 透彻理解产品需求：开发需要认真阅读、理解产品文档，并跟产品经理多次对齐，确保对产品功能的理解是正确的。

**总结下非 AI 时代我们提高软件质量的方法：**提高软件开发硬能力，将开发规范文档化，将标准规范工具化，并在交付时，进行代码审查。

在 AI 时代，上面的规范文档、脚手架、设计模式、开发方法论等，在我看来其实就是数据。解决 AI Coding 代码质量的核心途径其实就是给 AI 提供一整套高质量的数据，并且通过一种 AI 友好的方式提供给 AI 去使用。

上面也是我解决 AI Code代码质量的思路。

Harness AI Coding 实战

得益于过去写课积累的高质量知识体系。我构建了一整套标准化的 Go 应用开发体系。体系中包括：开发方法论、设计模式、开发规范、开发脚手架、架构基座、基础 Go 包等。因为过去对课程质量及代码质量要求很高，所以在梳理这些内容的时候，整个内容质量及代码质量都是很高的。即使在 AI 时代，质量仍然很高，可以理解为，目前仍然处在一个最佳实践的程度。

对 AI 来说一个高质量的数据具有一些特点：

• **结构化：**AI 对结构化数据的理解精度要远大于 Prompt。例如，你用了一大堆 Pormpt 去解释一个 JSON 结构，还不如直接把 JSON 结构示例数据喂给 AI；
• **一致性：**有些规范、设计方法和实现可能会横跨多个文档、工具或者代码仓库。要确保这些内容在全局范围一致，尽量不给 AI 带来不必要的迷惑；
• **高质量：**数据本身需要是高质量的，也就是规范、代码、设计和实现方式，都要遵循最佳实践；
• **扩展能力：**在 Code 的过程中，如果能够提供一个扩展能力很强、插拔方式简单、清晰的功能迭代方式给 AI，AI 能更好、更快的完成任务。

我做的事情其实很简单。将所有的高质量数据工具化，通过 MCP Tool、SKILL 的方式渐进式喂给 AI。

onexai harness ai coding 工具套件

上面介绍了，我的解决思路。具体来说就是：

1. 规范工具化；
2. 通过脚手架生成框架代码；

规范工具化

将我课程体系中，完整的开发规范，经过梳理、再加工后，封装为 46 个工具。这些规范体系全方位覆盖了从架构设计、底层编码与组件框架开发（CLI/REST/gRPC/微前端），到测试调优、可观测与排障以及 CI/CD 交付的 Go 云原生企业级全生命周期工程化开发标准。

具体规范内容如下：

 overview                Get the complete index of Go development conventions grouped by category
  architecture            Get Clean Architecture conventions: layered design, dependency rules, testability, and the miniblog reference implementation
  benchmark               Get benchmarking conventions: writing benchmarks with b.Loop, running with benchstat, profiling from benchmarks, documenting results in commits, CI regression detection
  ci                      Get CI/CD conventions: GitHub Actions pipelines, testing with -race, lint, SAST (govulncheck/CodeQL), coverage, Dependabot/Renovate, GoReleaser, AI code review
  cli                     Get CLI development conventions: command structure, flag handling, configuration layering, version embedding, exit codes, I/O patterns, signal handling, shell completion
  cobra                   Get cobra conventions: command tree, RunE hook chain, Args validators, persistent vs local flags, command groups, completions, doc generation, testing with SetArgs/SetOut
  coding                  Get the full Go coding standard: formatting, naming, imports, functions, packages, testing, and best practices
  commit                  Get commit conventions: Conventional Commits format, branching strategy, and merge request guidelines
  concurrency             Get Go concurrency conventions: goroutine ownership, channel patterns, and race avoidance
  context                 Get Go context conventions: cancellation, deadlines, and value propagation
  data-structures         Get data structures conventions: slice/map preallocation, container/heap/list/ring, strings.Builder vs bytes.Buffer, generic collections, pointer types, copy semantics
  database                Get database access conventions: transactions, connection management, and migration strategies
  dependency-injection    Get dependency injection conventions: manual constructor injection vs wire/dig/fx, constructor injection, composition root, DI library decision table
  dependency-management   Get dependency management conventions: go.mod, version selection, and vulnerability scanning
  design-patterns         Get design patterns conventions: functional options, constructors, error flow, resource management, graceful shutdown, resilience, data handling, streaming
  dev-system              Get the standardised development system design: the three-step methodology, convention catalog, and implementation strategy
  directory               Get directory structure conventions: cmd/, internal/, pkg/ layout, naming, and file organisation rules
  documentation           Get documentation conventions: godoc comments, README structure, CONTRIBUTING, CHANGELOG (Keep a Changelog), Example tests, API docs, llms.txt
  error-return            Get error return conventions: HTTP response patterns, semantic error codes, and error message security rules
  errorsx                 Get the ErrorX error package design: struct definition, API, error wrapping, and integration patterns
  grpc                    Get gRPC conventions: proto organization, server/client implementation, interceptors, status code errors, TLS/mTLS, bufconn testing, streaming RPCs
  id-generation           Get ID generation conventions: resource ID format, reference ID patterns, and generation rules
  klog                    Get klog logging conventions for Kubernetes-ecosystem components: klog.InfoS/ErrorS, log levels, structured KObj/KRef usage
  lint                    Get Go linting conventions: linter setup, static analysis, and CI integration
  logging                 Get mandatory logging rules: English-only, structured KV format, log levels, past tense, no sensitive data
  misc                    Get miscellaneous coding conventions: pointer handling with ptr package, avoiding unnecessary nil/empty checks
  modernize               Get Go modernization conventions: deprecated package migrations, language feature adoption, standard library upgrades, migration priority guide, modernize linter
  observability           Get observability conventions: metrics, distributed tracing, and the three-pillar model
  onexstack               Get the complete onexstack package catalog: all reusable packages with APIs, signatures, and usage patterns
  onexstack-reuse         MANDATORY RULE: Always check and reuse onexstack/onexstack packages BEFORE writing any new code
  performance             Get performance optimization conventions: profile before optimizing, allocation reduction, decision tree (if X bottleneck apply Y), GC tuning, hot-path optimization
  prd                     Get the PRD methodology: format, workflow, and best practices for AI-driven development
  refactoring             Get refactoring conventions: coverage-adaptive safety net, tool-driven behavior-preserving transforms (gopls Rename/Inline/Extract), atomic commits, breaking import cycles, type alias migration
  rest-api                Get REST API design conventions: URI naming, HTTP methods, versioning, error responses, and pagination
  safety                  Get Go safety conventions: nil traps, panic prevention, and defensive coding
  scaffold                Mandatory post-creation build steps after onexai create commands
  security                Get Go security conventions: input validation, SQL/command injection prevention, and secure defaults
  semver                  Get the pre-release version auto-generation rules used by onexai semver tag
  slog                    Get log/slog conventions: context-aware logging, flat key-value pairs, snake_case keys, sensitive data protection
  structs-interfaces      Get struct & interface design conventions: small interfaces, consumer-side definition, and abstraction
  testify                 Get testify conventions: assert vs require, mock expectations and matchers, suite lifecycle, advanced assertions like Eventually and JSONEq
  testing                 Get Go testing conventions: table-driven tests, coverage, and test naming
  troubleshooting         Get troubleshooting conventions: root cause methodology, debugging golden rules, common Go bugs, race detection, pprof setup, GODEBUG tracing, production debugging
  version                 Get semantic versioning conventions: MAJOR.MINOR.PATCH format, version bump rules, and onexai semver integration
  viper                   Get viper conventions: layered precedence (flag > env > file > KV > default), BindPFlag, env binding with key replacer, Unmarshal with mapstructure tags, hot reload, test isolation
  web-frontend            Get the web frontend standards: React 19 + Rsbuild + Wujie micro-frontend, monorepo layout, naming, components, stores, routing, i18n, styling, and commit rules

这些规范内容很多，全部喂给 AI 会有很大的 Context 消耗。但这其实不是问题，解决方案如下：

• 在日常 Code 中，AI 更倾向于基于已有代码规范，开发风格和架构，来生成新的代码。所以，我们要做的时，在需要的时候，渐进式的喂给 AI 这些规范：
  • 开发新项目时，要开发出符合代码规范的项目；
  • 可以阶段性的铜鼓哦定向的 /review 命令来将项目再规范化。其实就是避免频繁的优化，而是阶段性的一次性优化。可以使用 onexai review 工具强制Review你的代码并自动修复。Review的时候，可以指定规范等级；
  • 其他情况，交给 AI 自行判断，使用哪个规范即可。onexai rag 提供了基于语义的规范查找方式。

onexai 的所有工具，都会自动转换为 MCP Tool，并连接至 Claude Code 等 AI IDE工具。

在告知 AI 开发规范的时候，其实是通过 onexai convention overview 来告知的。而非通过全量的规范。onexai convention overview 工具输出内容如下：

 Every convention below is available as an MCP tool. MCP tool name is `convention_<subcommand>`: the underscore joins `convention` to the subcommand, and hyphens inside the subcommand are preserved (never rewritten as `_`). For example Error Return → `convention_error-return`, Dependency Injection → `convention_dependency-injection`.
> Invoke the exact MCP tool name from the table (or the equivalent CLI form `onexai convention <subcommand>`).

## Convention Levels (规范级别)

Each convention document marks its rules with one or more levels. Levels are
NOT a command-level classification --- a single convention may contain 强制,
建议, and 参考 rules together.

| Level | Label | Description |
|---|---|---|
| **Mandatory** | 强制 | Must be followed in all projects. Only affects product function. Exceptions require formal review approval. Existing projects: phased improvement. New projects: enforced from design stage. |
| **Recommended** | 建议 | Follow unless there is a justified reason not to. Existing projects: adopt incrementally. New projects: default follow, exceptions require review. |
| **Reference** | 参考 | Guidance only, not hard requirements. Adopt flexibly per project context. |

## Conventions by Category (按类别)

### Core Principles

| MCP tool | Convention | CLI command |
|---|---|---|
| `convention_onexstack` | OneXStack Package Catalog | `onexai convention onexstack` |
| `convention_onexstack-reuse` | OneXStack Reuse-First Principle | `onexai convention onexstack-reuse` |

### Coding Standards

| MCP tool | Convention | CLI command |
|---|---|---|
| `convention_benchmark` | Benchmarking Conventions | `onexai convention benchmark` |
| `convention_cli` | CLI Development Conventions | `onexai convention cli` |
| `convention_cobra` | Cobra Conventions | `onexai convention cobra` |
| `convention_coding` | Go Coding Standard | `onexai convention coding` |
| `convention_concurrency` | Concurrency Conventions | `onexai convention concurrency` |
| `convention_context` | Context Usage Conventions | `onexai convention context` |
| `convention_data-structures` | Data Structures Conventions | `onexai convention data-structures` |
| `convention_database` | Database Access Conventions | `onexai convention database` |
| `convention_dependency-management` | Dependency Management Conventions | `onexai convention dependency-management` |
| `convention_design-patterns` | Design Patterns Conventions | `onexai convention design-patterns` |
| `convention_documentation` | Documentation Conventions | `onexai convention documentation` |
| `convention_id-generation` | ID Generation Conventions | `onexai convention id-generation` |
| `convention_klog` | KLog Conventions | `onexai convention klog` |
| `convention_lint` | Linting Conventions | `onexai convention lint` |
| `convention_logging` | Logging Conventions | `onexai convention logging` |
| `convention_modernize` | Modernize Conventions | `onexai convention modernize` |
| `convention_observability` | Observability: Metrics & Tracing | `onexai convention observability` |
| `convention_performance` | Performance Optimization Conventions | `onexai convention performance` |
| `convention_refactoring` | Refactoring Conventions | `onexai convention refactoring` |
| `convention_safety` | Safety & Defensive Coding | `onexai convention safety` |
| `convention_security` | Security Conventions | `onexai convention security` |
| `convention_slog` | Slog Conventions | `onexai convention slog` |
| `convention_structs-interfaces` | Structs & Interfaces Design | `onexai convention structs-interfaces` |
| `convention_testify` | Testify Conventions | `onexai convention testify` |
| `convention_testing` | Testing Conventions | `onexai convention testing` |
| `convention_troubleshooting` | Troubleshooting Conventions | `onexai convention troubleshooting` |
| `convention_viper` | Viper Conventions | `onexai convention viper` |

### API & Error Handling

| MCP tool | Convention | CLI command |
|---|---|---|
| `convention_error-return` | Error Return Conventions | `onexai convention error-return` |
| `convention_errorsx` | ErrorX Package Design | `onexai convention errorsx` |
| `convention_grpc` | gRPC Conventions | `onexai convention grpc` |
| `convention_rest-api` | REST API Conventions | `onexai convention rest-api` |

### Architecture & Design

| MCP tool | Convention | CLI command |
|---|---|---|
| `convention_architecture` | Architecture Conventions | `onexai convention architecture` |
| `convention_dependency-injection` | Dependency Injection Conventions | `onexai convention dependency-injection` |
| `convention_directory` | Directory Structure Conventions | `onexai convention directory` |

### Operations

| MCP tool | Convention | CLI command |
|---|---|---|
| `convention_ci` | CI/CD Conventions | `onexai convention ci` |
| `convention_commit` | Commit Conventions | `onexai convention commit` |
| `convention_semver` | Semver Pre-release Rules | `onexai convention semver` |
| `convention_version` | Versioning Conventions | `onexai convention version` |

### Platform & Development

| MCP tool | Convention | CLI command |
|---|---|---|
| `convention_dev-system` | Development System Design | `onexai convention dev-system` |
| `convention_misc` | Miscellaneous Conventions | `onexai convention misc` |

### AI & Methodology

| MCP tool | Convention | CLI command |
|---|---|---|
| `convention_prd` | PRD Methodology | `onexai convention prd` |

### Scaffold & Tooling

| MCP tool | Convention | CLI command |
|---|---|---|
| `convention_scaffold` | Scaffold Post-Creation Steps | `onexai convention scaffold` |

### Web Frontend

| MCP tool | Convention | CLI command |
|---|---|---|
| `convention_web-frontend` | Web Frontend Development Standards | `onexai convention web-frontend` |

通过脚手架生成框架代码

上面是规范。大家在开发中，都知道规范是文档化的，需要一个有更强约束力的工程化手段，来确保规范的落地。onexai create 命令中集成了 20 个脚手架命令，这些脚手架命令从目录结构、代码架构设计、代码实现方式和风格、代码开发规范、代码引用包等方方面面，都保持高度的一致，甚至完全的一致。

这 20 个脚手架命令分别用来生成以下代码：

可用命令：
  quickstart           创建仅供学习的演示/示例项目（切勿用于实际生产应用）
  project              从 YAML 配置文件创建新项目（需要 onexstack.yaml）
  webserver            创建 REST API / Web 服务项目（Web 应用和 API 的主要命令）
  api                  创建 API 资源
  jobserver            创建异步任务 / Cron 定时任务消费服务项目
  job                  为现有 JobServer 添加特定资源类型的异步任务处理程序
  mqserver             创建消息队列（Kafka）消费者项目
  mq                   创建 MQ 消费者
  mcpserver            创建 MCP (Model Context Protocol) 工具服务项目
  mcp                  创建新的 MCP 工具
  clitool              创建命令行工具（CLI）项目
  cmd                  创建新的 CLI 命令
  console              创建现代化 Web 前端项目
  micro                为现有 Web 控制台项目创建微前端子应用
  declserver           创建声明式（kube-apiserver 风格）API 服务项目
  crd                  向 declserver 添加 REST 资源（CRD）
  controller-manager   创建控制器聚合（kube-controller-manager 风格）项目
  controller           向 controller-manager 添加监听 CRD 资源的控制器
  operator             创建独立的 controller-runtime operator 项目
  operator-api         向 Operator 添加 CRD 及其配套控制器

可以看到，onexai create 通过脚手架的方式，将高质量的预定义代码，通过脚手架工具生成高质量、确定性、结构化、高一致性的代码，这些代码是 AI 最好的数据源。之后 AI 的每一次迭代，会遵循这些高质量的代码，进行日常的功能迭代。

onexai harness ai coding 效果咋样

我日常开发基本都是用的 onexai create 生成代码。然后基于生成的代码来进行 AI Coding。在公司开发了一个 Helper AIOps 平台。整个项目有 33292 行代码，包括 Web Server、MCP Server、Job Server 全都是基于 onexai create 脚手架生成的。目前从扩展能力等方面没有遇到任何问题。

上周末，我尝试将 2 个 10W+ 行代码的大型项目，从前端到后端，完全使用 onexai 的开发方式去重构，基本上一条Prompt就重构完了，而且重构后的代码，跟整个 OneX 技术栈的开发风格、架构模式等等，都保持高度的一致性。重构上述 2个项目大概花了我 100多元的Token费。以下是代码提升质量对比：

如果开启 onexai 更严格的规范校验模式，整个代码质量还会再提升 20%+。

我为什么要写 onexai harness ai coding 工具？

写 onexai harness ai coding 工具的核心目的是想将 Go 应用开发中的最佳实践，通过工程化的方式进行固化，通过 MCP Tool 的方式进行分发，并借此统一 Go 应用开发过程中的代码架构、开发风格、开发规范、基础包共享、设计模式、开发方法论等等。将 AI Coding 的效果再往前 push 一大步。并且做到一键分发的能力。通过这种方式，我能够以最小的成本，开发出最高的代码质量。如果哪天我创业，我会用这套工具，快速构建出完整的企业技术栈。

所以，借助 onexai harness ai coding。你未来的开发模式可能是这样；

所以 OneX AI Coding 的核心目标是：将 Go 应用开发最佳实践固化，通过便捷的分发方式，分发至全公司，确保整个公司 Go 应用的代码质量和一致性。给你的 AI Coding 加一把火，让它烧的更旺🔥！

如果你准备自己创业，或者是一个"一人"公司，基于 Go 语言开发应用，那么 OneX Harness AI Coding 工具，可以帮助你快速开发、重构你的应用。

如果你想重构一个开源项目只需要用以下 Prompt 进行重构即可：

请阅读cmd/ks-controller-manager代码，使用onexai create controller-manager/controller 命令，重构ks-controller-manager的实现。

在重构时，先使用onexai create controller-manager/controller 实现完整的框架代码，然后再迁移ks-controller-manager的所有逻辑，然后再编译，测试通过。

在迁移时，要注意不要遗漏ks-controller-manager 的任何逻辑。并且配置、资源等，要跟cmd/ks-controller-manager 保持一致。这样做的核心目的时，迁移后的代码，能够完成跟cmd/ks-controller-manager 一样的功能、配置等也能适配。

在迁移的过程中，请遵循 OneX 技术栈的规范。

或者干脆更简单一点：

请使用 OneX 技术栈重构本项目。

一些老旧的低质量项目，可以直接通过 OneX AI 进行一键重构，重构包括：前端、后端！

onexai harness ai coding 工具开发实战

步骤一：通过自然语言描述你的需求，并转换为 Story

通过 Prompt 快速创建一个博客系统，Prompt 如下（保存在 prompt.md 文件中）：

请搭建一个工单管理系统：包含用户认证、工单和评论的 CRUD等操作、超时工单自动关闭的后台任务、管理CLI。先查规范。

执行以下命令生成 Story 文件 prd.md：

onexai prd translate -i prompt.md -o prd.md

• -i：Input，指定要翻译为 Story 等 Prompt 内容；
• -o：Output，指定 Story 的保存文件。

prd.md 内容如下：

# PRD: 工单管理系统

## Introduction
一个工单（Ticket）管理系统，用于帮助团队跟踪、处理和闭环客服/运维工单。系统提供用户认证、工单与评论的完整 CRUD 操作、超时工单自动关闭的后台任务，以及用于日常运维与管理的命令行工具（CLI）。

### US-001: 用户认证
**Status:** todo
**Priority:** 1
**Description:** As a 系统用户, I want 通过账号完成注册、登录/登出并获取鉴权凭证 so that 只有经过认证的用户才能访问受保护的资源。

**Acceptance Criteria:**
- [ ] 支持用户注册、登录与登出
- [ ] 登录成功后返回鉴权凭据（如 JWT）
- [ ] 受保护接口校验凭据，未认证或凭据无效时返回 401
- [ ] 密码以哈希形式存储，不以明文保存

### US-002: 工单 CRUD
**Status:** todo
**Priority:** 1
**Description:** As a 已认证用户, I want 创建、查看、更新和删除工单 so that 能够完整地跟踪与维护工单生命周期。

**Acceptance Criteria:**
- [ ] 支持创建工单（含标题、描述、状态、优先级等字段）
- [ ] 支持查看单个工单详情与分页列表
- [ ] 仅工单创建者或管理员可更新/删除工单
- [ ] 工单状态流转（如 open → in_progress → closed）合法

### US-003: 评论 CRUD
**Status:** todo
**Priority:** 2
**Description:** As a 已认证用户, I want 在工单下创建、查看、更新和删除评论 so that 能够围绕工单进行协作与沟通。

**Acceptance Criteria:**
- [ ] 支持在指定工单下创建评论
- [ ] 支持查看某个工单下的全部评论
- [ ] 仅评论作者或管理员可更新/删除评论
- [ ] 评论必须关联到一个已存在的工单

### US-004: 超时工单自动关闭后台任务
**Status:** todo
**Priority:** 3
**Description:** As a 系统运维人员, I want 一个后台定时任务自动关闭超时未更新的工单 so that 过期工单无需人工处理即可被自动闭环。

**Acceptance Criteria:**
- [ ] 后台任务按固定时间间隔运行
- [ ] 对超过设定超时阈值且未关闭的工单自动标记为已关闭
- [ ] 自动关闭操作留有审计记录或日志
- [ ] 超时阈值与运行周期可配置

### US-005: 管理 CLI
**Status:** todo
**Priority:** 4
**Description:** As a 系统管理员, I want 一个命令行工具用于管理工单系统 so that 无需登录 Web/API 即可完成运维与管理操作。

**Acceptance Criteria:**
- [ ] CLI 支持工单的增删改查命令
- [ ] CLI 支持用户管理命令（如创建/禁用用户）
- [ ] CLI 支持查看系统状态或健康检查
- [ ] CLI 输出格式清晰（如表格/JSON），并提供帮助信息

之后，你可以根据 prd.md 的内容，根据需要进行细化和约束。将一个 Prompt 拆分为多个 Story，是为了，减少每轮需求实现时的 Context。

步骤二：实现你的 Story 列表。

执行以下命令，完成你的 Story 列表：

onexai prd run --all-levels --tui --review-timing=at-end prd.md

• --review-timing=at-end、--all-levels：在所有 Story 完成后，使用全量的 OneX 规范 Review 代码。之所以在所有 Story 完成之后，Review 是为了节省 Token。当然，你也可以通过指定 --review-timing=per-story 来在每一轮 Story 执行完成之后 Review 代码。
• --tui：进入 TUI 界面，TUI 界面提供更美观的进度展示，例如：

运行完成后的 onex-harness-demo 项目仓库见：xxxxxxxxxx。

具体效果大家可以自行验证下。基于非常简单 Prompt 描述，AI 写出来的代码和 OneX 技术栈中 2 个经典代码的开发模式是否一致：

• miniblog: github.com/onexstack/m...；
• onex: github.com/onexstack/o...

我让 AI 进行了对比，对比结果如下（AI阅读代码仓库代码后，给出的平分结果）：

（此处有一张图片，未随正文导入。）

可以看到通过 AI 开发的新项目，可以其他项目从软件架构、日志、目录结构、开发规范、实现方式、开发风格、错误处理、共享包等维度，能做到几乎完全一致的风格。近似度 100分能达到96。

学习过miniblog项目的开发者应该都知道miniblog的代码质量非常高。也就意味着，基于onexai harness ai coding 套件。开发出来的项目不仅能做到高度的一致性，代码质量保持在一个非常高的状态。

OneX Harness AI Coding 工具未来规划【这个已经实现，只花了一个月时间】

未来我会使用 onexai 开发完整的 OneX 平台，OneX 平台是一个类似公有云的课程云平台，平台提供了一整套的 AI Infra 学习路径和实战项目。在 OneX 平台中，你可以申请 AKSK，通过 Remote MCP Server 的方式，接入你的 Claude Code。从而一键复用 OneX Harness AI Coding 提供的全栈开发能力。将你学习的结果，直接复用在你的应用开发中。

如果你对 OneX 平台及 OneX Harness AI Coding 工具感兴趣，可以关注我的公众号或者加入OneX平台