现在工作中在使用不同的AI开发工具，比如：codebuddy、claude code CLI、gemini CLI等，并行地在开发多个不同技术栈的项目。不同的AI开发工具的切换，导致为该工具配置的各种资源来回迁移麻烦。以skill为例，在某一个工具或某一个项目里发现一个好用的skill时，想在另外一个工具或项目里也使用，需要自己手动将对应的资源来回拷贝。当skill更新后又需要在不同的工具或项目里再依次更新下。过程非常繁琐，维护成本也高。因此就萌生做一个AI资源同步的工具应用，来实现这些AI资源的高效同步。实现资源一处维护，各处都同步使用。维护一份唯一的源目录作为单一事实源，在用户级和项目级里不同AI开发工具使用同一套资源。mvp版本只做skills的本地资源同步，后期再实现远程skills资源下载及同步。commands、agents、rules这些都先不做。二、启动：快速开发实现阶段有了上面的想法后，借助codebuddy很快就启动了开发工作。将上面的背景和目标给AI描述之后，初期完成技术选型和方案之后，很快就进入到了开发阶段。第一版面向的对象是我自己，一个技术开发人员，最小化原则只做CLI命令操作。AI根据要求很快就做出来第一版CLI，经过几轮调试和优化，命令很快就跑起来了。以下是核心的命令示例，并不是完整的命令：aitools init // 初始化工具，引导式创建源目录和关联的AI开发工具aitools list // 列出当前skills的列表及同步情况aitools sync // 同步源目录里有变更的skill到用户级目录或项目级目录
CLI基本能满足我的需求，但是存在一个熟练度的问题。 aitools CLI命令并不像 git 之类的命令在自己每天的开发场景里都会用到，过一段时间就会把命令给遗忘了，还需要频繁的去查看帮助。而且不知道现在有哪些项目关联使用了这个命令。还是有一个GUI用户界面展示的更加直观好用，因此又启动了GUI的开发。相对于CLI纯命令行的开发来说GUI更加复杂些，用之前CLI的开发方式做出来几版都不满意。主要存在以下几个问题：- UI连续性差：在持续功能迭代的过程中，后出的UI样式和交互与之前的版本不具有连续性，需要不断重复调教AI才能修复。
- 应用缺乏统一的设计规范，比如弹窗、菜单等，每次生成都是不同的样式，缺乏统一的品牌调性和一致性。
因此我又花了一上午的时间使用AI设计了整个应用的设计系统体系。由于自己本身没有任何UX/UI设计相关的知识，所以我让AI引导我逐步创建设计规范，自己只需要在关键策略上回答AI的相关问题即可。提示词如下：你是一位资深的专业UX/UI设计师，熟悉现代的UX/UI设计理念。我完全不懂UX/UI设计，需要为当前的项目（AI工具助手）设计一个的桌面应用，请一步步指导我完成UX/UI的起步，并完成初版GUI，沉淀针对该应用的设计理念及后续遵守的规范（保持UX/UI的统一性）。
AI收集完相关信息后，给出了设计系统的7层架构和实施方式，如下：┌─────────────────────────────────────────────────────────────┐│ L1 品牌战略 (Brand Strategy) │ ← 现在在这│ 产品是什么？给谁？解决什么？要让人感觉怎样？ │├─────────────────────────────────────────────────────────────┤│ L2 设计原则 (Design Principles) ││ 5~7 条可判断对错的铁律，指导后续所有决策 │├─────────────────────────────────────────────────────────────┤│ L3 信息架构 + 用户旅程 (IA + User Journey) ││ 有哪些页面？怎么连？用户从哪来、到哪去？ │├─────────────────────────────────────────────────────────────┤│ L4 视觉语言 (Visual Language) ││ 颜色 / 字体 / 间距 / 圆角 / 阴影 / 图标 │├─────────────────────────────────────────────────────────────┤│ L5 组件规范 (Component Spec) ││ 按钮、卡片、列表、输入框...的具体规则 │├─────────────────────────────────────────────────────────────┤│ L6 初版 GUI 原型 (Hi-Fi Prototype) ││ 可点击的 HTML/CSS Demo │├─────────────────────────────────────────────────────────────┤│ L7 走查规范 (Review Checklist) ││ 每次新增页面必须过的清单，保证一致性 │└─────────────────────────────────────────────────────────────┘
就这样一步步执行，最终得到了一套设计系统规范，包含：品牌战略、设计原则、信息架构、视觉语言、组件规范和走查清单。并且指定了AI工作指令，用来指导AI如何使用和遵守这一套设计系统。如下图所示：有了这一整套设计系统规范后，再进行GUI的开发，就能保持应用气质、交互和样式的一致性与连贯性了。整个GUI的效果好了很多。以下是GUI阶段应用的效果：在开发GLI和GUI应用的过程中还发现另外一个问题：功能范围和细节把控不足。经常出现一次开发了太多功能，没有聚焦，且功能开发完之后不符合要求，细节缺失或异常，需重新澄清后推倒重来的情况。虽然也用了 openspec 这类开源的 SDD 规范驱动开发的工具，但满足不了自己的需求，对中间细节的调整效率和精细度不足，也不适合我自己的开发流程。因此接下来开始了对整个开发流程的升级。个人工作流的核心思想：文件即协议，状态可追踪，上下文可恢复。目前为止，个人工作流设计了需求分析、需求设计、方案设计、编码实现、测试验证和归档六个阶段，每个阶段完成后向下一个阶段流转。设计了状态机机制，用来管理每个阶段状态的流转，状态机如下所示：// 任务阶段ANALYSIS → DESIGN → TECHNICAL → CODING → TESTING → ARCHIVED// 阶段状态pending → in_progress → completed ↑ ↓ └── revision ←┘
为每个任务阶段设计了门禁规则，门禁检查有三种状态：通过、跳过（必须说明原因）和不允许。只有当所有的门禁都满足条件后（通过或说明）才能从当前阶段流转到下一个阶段。通过 yaml 文件来记录当前的阶段和状态，避免状态丢失并能随时恢复到上次进行到的阶段（比如第二天继续前一天的工作）。以下是我的个人工作流状态机模版：# manifest.yaml 模板# 说明：创建新任务时，AI 根据此模板生成 manifest.yaml# 注意：此文件仅作参考，不应直接使用# === 基础信息 ===id: "{{TYPE}}-{{SEQ}}"title: "{{TITLE}}"type: "{{TYPE}}" # FEAT | FIX | REFACTORcreated: "{{DATE}}"updated: "{{DATE}}"# === 当前所处的状态 ===status: "ANALYSIS" # ANALYSIS | DESIGN | TECHNICAL | CODING | TESTING | ARCHIVEDsub_status: null # null | blocked | revision# === 阶段详情 ===phases: analysis: status: "in_progress" # pending | in_progress | completed | revision started: "{{DATE}}" completed: null output: "01-requirements.md" design: status: "pending" started: null completed: null output: "02-design.md" technical: status: "pending" started: null completed: null output: "03-technical.md" coding: status: "pending" started: null completed: null output: "04-coding-log.md" testing: status: "pending" started: null completed: null output: "05-testing.md"# === 门禁 ===gates: analysis_to_design: checklist: - "需求范围明确" - "验收标准（AC）已定义" - "用户故事完整" passed: [] skipped: [] # skipped 格式： # - item: "用户故事完整" # reason: "本次为纯技术重构，无用户故事" # date: "2026-04-29" design_to_technical: checklist: - "页面流程完整" - "组件规范引用" - "交互状态覆盖（空态/加载/错误/成功）" passed: [] skipped: [] technical_to_coding: checklist: - "架构设计完整" - "接口定义明确" - "影响范围已评估" passed: [] skipped: [] coding_to_testing: checklist: - "自测通过" - "代码已提交" - "编码日志已更新" passed: [] skipped: [] testing_to_archived: checklist: - "功能验收通过" - "UI 走查通过" - "文档归档完成" passed: [] skipped: []# === AI 上下文恢复 ===context: last_action: "" next_action: "" blockers: [] decisions: [] # decisions 格式： # - date: "2026-04-29" # decision: "决策内容" # reason: "决策原因"
每个阶段都设计了模版文件，每个阶段通过时最终输出该阶段的.md文档，作为启动下一个阶段的输入。在工作流的基础上，构建了驱动工作流的Skill。AI开发工具通过Skill来驱动工作流执行，每个阶段都有对应的文件输出，我来审查对应的产出文档，提出修改意见，每一步都经过精细化地打磨，保障产出始终是自己想要的东西。最终设计出来如下结构的工作流结构：.workflow/├── workflow.config.yaml ← 全局配置（编号计数器、阶段和门禁定义）├── README.md ← 本文件（规范说明）├── templates/ ← 各阶段文档模板│ ├── manifest.tpl.yaml ← 任务状态追踪模板│ ├── 01-requirements.tpl.md ← 需求分析模板│ ├── 02-design.tpl.md ← UI/UX 设计模板│ ├── 03-technical.tpl.md ← 技术方案模板│ ├── 04-coding-log.tpl.md ← 编码日志模板│ └── 05-testing.tpl.md ← 测试验收模板├── tasks/ ← 进行中的任务（AI 扫描此目录恢复上下文）│ └── FEAT-002-xxx/└── archived/ ← 已归档的任务（验收通过后移入） └── FEAT-001-xxx/
- 需求分析阶段：明确需求范围，本次做哪些和不做哪些都有明确说明，避免模型跑偏；逐步完善需求细节，输出用户故事、功能清单和验收标准。在分析过程中也是不断将自己的想法和思路具象化，落地为可执行的文档。
- 需求设计阶段：明确信息架构（页面结构和用户操作流程），并根据设计系统规范完成页面设计，列出本次需求的组件清单和状态。在将需求分析阶段的功能文档可视化的过程中，又进一步地帮助自己捋清了思路，明确想要的结果。
- 方案设计阶段：完成技术架构设计、数据模型定义、接口定义、实施步骤清单输出，并进行影响范围、风险评估和回滚方案设计。这个阶段通过后本次需求基本就没问题了，要做什么、输出的结果是什么样的、如何做就都比较清晰了。
- 编码实现阶段：根据技术方案和实施步骤完成编码实现。每个步骤完成后对比技术方案，如果编码实现和技术方案设计有偏移，偏移原因是否正确？如果不正确则重新按照技术方案重新执行；如果正确则生成一条偏移记录，说明偏移的原因，供开发者了解原因并进行判别。
- 测试验证阶段：根据需求文档和设计文档输出测试方案。测试验收分为静态验收和动态验收，能有AI执行的则交给AI执行（静态验收+部分动态验收），AI无法执行的则人工按照测试用例逐条验证并反馈结果。
- 归档阶段：测试验证通过后，整个需求就完成了，将相关资源归档。
有了工作流之后开发功能更加可控。每个环境都有人工审核，虽然增加了人工审核的成本，但这些都是必要的。更明确的目标和规则能明显减少AI的自由发挥，防止AI执行跑偏，降低了返工率。目前还没有设计使用 /command 来执行工作流的不同阶段，后续使用过程中再考虑是否加入命令形式。目前开源的 openspec 、 speckit 项目都是基于命令驱动的，我们团队大型项目也是基于命令驱动工作流的，但目前的工作流方式满足我自己的诉求，而且更适合自己的工作方式，暂时不会调整。- 需要拓展和加强产品思维能力。我发现自己还是习惯性地从技术角度看待需求，从功能想法很快就过渡到技术方案和代码实现上，而很少思考产品功能的底层逻辑。比如在这个项目里关于 skills源目录 、 AI Agent工具 和 项目 三者这件的关系没有考虑清楚，一开始只考虑了skills和用户级目录与项目级目录的关系，将其关系简单地理解为skill文件的移动和对比关系，没有考虑到skills、项目两者和AI agent工具应该是什么关系。导致在 codebuddy 管理的项目里创建了 .claude 目录，并将skill移动到该目录下；历史使用 codebuddy 创建的项目，已经关联了skill，在面板里展示里未使用过的 claude-code Agent工具等。导致了各种问题，修复完一个问题又出现另外一个问题。最后是跟AI沟通的过程中skill文件移动抽象为skill订阅关联关系：项目分别去关联AI Agent工具和订阅skill，一个项目可以关联多个AI Agent工具（如 codebuddy 、 claude-code 等），然后去订阅skill，将对应的skill拷贝对关联AI Agent工具都skills目录下。
- 涉及到界面的需要优先确认一套设计系统规范。在将项目从CLI拓展到GUI的过程中，没有系统地设计UI/UX，让AI简单地输出一个可见的HTML原型，然后就开始实现GUI了。首次这么做倒是没有问题，实现速度还快。但是很快就发现其不可持续，后续页面再按照这种方式很容易跑偏，无法保持设计风格、样式的一致性。本次个人项目的事件中和AI创建设计系统的过程还是很有收益的，也了解到了一个好的应用是有其一贯坚持的设计哲学、原则和视觉语言的，像微信的绿色主题和功能哲学。这一次是和AI共同创建了一套设计系统，大多是AI在主导方向和步骤，后面有必要了解一下设计领域的一些基础知识。
- 架构设计不能交给AI发挥，必须有开发者把控。越早纠正架构问题，后续维护成本越低，这条原则依然成立。虽然使用AI编写代码速度很快，但是遇到架构调整其工作量依然巨大。在不合理的架构上开发的N个需求，在架构重构时这N个需求可能都需要调整。本项目里在CLI基础上扩展GUI过程中，采纳了AI的建议“分本次需求重点，架构调整收益不大，可以考虑后续再进行”，结果是我又花了一整天的时间才加架构重新调整过来，而且GUI实现功能都涉及到调整。架构层面AI不一定有工程师可靠。
夜雨聆风
