简介：本教程介绍如何用一套技能化的 Agent 工作流，把一句话想法变成可安装运行的原生桌面应用。内容覆盖环境准备、技能装载与阶段路由、需求转写为带验收标准的用户故事、界面克隆、编码与系统集成、4pt 网格双主题设计校验，以及“一故事一提交”的交付纪律、行为不变重构与常见问题排查，适合桌面应用开发者与技术团队参考。
本教程要解决的问题是：如何让 AI 编码智能体（下文统称 Agent）在你的监督下，从一个模糊的产品想法出发，按流程完成规划、编码、设计、测试与交付，最终产出一个能在桌面操作系统上直接安装运行的原生应用。
这套方法的核心载体是“技能集”：某开源社区把桌面应用开发全过程拆成了二十余个职责单一的技能单元，覆盖起步、规划、写代码、做设计、交付五大阶段。每个技能本质上是写给 Agent 的结构化说明书，包含触发条件、执行步骤与输出规范。Agent 根据当前阶段自动路由到对应技能，你不需要在几十段提示词之间手工切换。
一句话概括其价值：把“在开发环境里手动操作、靠人脑记忆流程”的开发方式，变成“对 Agent 说一句话、由它按流程一步步交货”。
读完本教程，你将能够：
适合读者：客户端与桌面应用开发者、全栈开发者、负责评估 AI 研发流程的技术负责人，以及希望把 AI 落到实际交付环节的团队。
1. 操作系统与工具链
2. Agent 与技能支持
3. 基础知识
4. 权限准备
动手前先建立整体心智模型。可以把二十余个技能想象成流水线上的工位：
阶段 代表技能 产出起步 需求澄清、命名 项目名称、用户流程、文案清单规划 屏幕索引、故事转写 屏幕索引文件、用户故事+验收标准编码 并发、状态、持久化、桥接 可编译的功能模块设计 设计系统、网格检查 双主题界面与校验报告交付 截图、测试、提交 版本库中一次原子提交
技能描述文件通常包含以下通用字段（示意结构）：
# 技能描述文件通用结构（示意）name: acceptance-screenshot # 技能名phase: delivery # 所属阶段trigger: 用户故事实现完成、准备提交steps:- 逐页截取浅色模式界面- 逐页截取深色模式界面- 运行测试套件- 生成提交说明output:- 截图目录（浅色/深色成对）- 测试报告
字段含义与配置逻辑说明：
配置风险提示：技能数量多且触发条件相互重叠时，Agent 可能反复切换技能造成“空转”；建议定期审视触发条件的互斥性。
做什么：确认系统与开发环境版本满足要求，把技能集放到 Agent 能读取的目录（通常为项目级或用户级配置目录），并在会话开始时让 Agent 读取技能清单。
为什么：技能没有被加载，Agent 就退化为普通编码助手，阶段路由无从谈起。
注意：技能较多时，建议先让 Agent 复述“当前阶段可用技能”，确认装载成功再继续，避免后续返工。
做什么：用一句话描述你想做的应用，让起步技能把它扩展为：应用名称、核心用户流程、关键界面文案。
为什么：名字与文案决定界面的信息结构。先定文案的成本几乎为零，而界面返工的成本极高；文案具体到按钮与提示语级别，后续生成才稳定。
做什么：让规划技能把需求转写成标准用户故事，并按里程碑排序。推荐模板：
用户故事作为 <角色>，我希望 <功能>，以便 <价值>。验收标准- 界面：进入某页面时，应显示 X- 交互：点击 Y 后，应在 Z 秒内出现 W- 边界：输入为空时，按钮置灰且给出提示里程碑M1：核心流程可跑通（最小可用）M2：系统集成与全局快捷键M3：设计规范与双主题适配M4：打包交付
为什么：验收标准是后续“是否完成”的唯一裁判。没有验收标准的故事，Agent 容易自我判定“已完成”，埋下质量隐患。
注意：一个故事只做一件事；故事之间不要互相依赖验收，否则里程碑会连锁延期。
做什么：告诉 Agent 你想参考哪个应用，它会把该应用每一屏截图、编号，整理成“屏幕索引”（每屏包含控件清单、布局说明、交互行为），再把索引转写成带验收标准的用户故事，按里程碑推进。
为什么：屏幕索引把“看起来像”变成“可验收的规格”，避免 Agent 凭模糊印象生成似是而非的界面。
注意：此路线要求 Agent 具备屏幕理解与操作能力；同时要守住合规边界——学习交互模式与信息架构即可，不复刻他人受保护的视觉素材与专有内容。
做什么：进入编码阶段后，Agent 依次处理四块硬骨头：
为什么：这四块是桌面应用最容易“长歪”的地方，每一块都值得用独立技能约束。
注意：每完成一个故事，先让对应测试跑通，再进入下一个故事，不要攒到最后一起测。
做什么：按需接入系统能力：全局快捷键、菜单栏常驻、悬浮面板、窗口控制（吸附、切换、层级管理）、截屏、录屏、系统自动化、URL Scheme（自定义协议）注册、命令行入口，以及各自的权限申请。
为什么：系统能力是桌面应用与网页应用拉开差距的地方，但每一项都伴随权限，必须坚持最小化原则。
注意：只申请实际用到的权限；权限用途说明要写给最终用户看，说清“为什么需要”。
做什么：设计技能先落地一套设计系统（间距、字号、色彩、控件尺寸的语义化取值），再执行 4pt 网格检查：所有尺寸与间距必须是 4 的倍数，错位即报错；同时按系统级设计规范处理布局、工具栏、菜单与键盘导航，并逐页验证浅色与深色两种主题。
为什么：4pt 网格是最廉价的对齐保障——机器能报错的事，不要靠人眼盯。语义化颜色取值（如“背景/强调/警示”而非硬编码色值）是双主题不翻车的前提。
注意：不要硬编码颜色与字号，一律引用设计系统取值；发现网格报错时，优先怀疑取值引用错误，而不是网格规则本身。
做什么：执行硬性流程——每个用户故事完成后立即提交一次；提交前必须：每一页在浅色与深色两种模式下各截图一遍，测试套件完整跑一遍。
为什么：小步提交让回滚粒度最小；双主题截图把“深色模式没人检查”这一历史遗留问题在提交前拦截；测试结果则是行为基线的存证。
注意：提交说明中引用故事编号与验收标准勾选结果，方便日后审计“这次提交对应哪条需求”。
做什么：当发现架构偏离（模块耦合、状态散落、桥接层被绕过），不要让 Agent“顺手改改”，而是调用重构技能：先固化当前行为基线（补齐测试），再小步调整结构，全程保持测试通过。
为什么：行为不变重构的前提是存在行为基线，没有基线的重构等于赌博。
注意：重构提交与功能提交严格分开，一次提交只做一件事。
做什么：技能集自带十余个小型应用的建造计划：窗口吸附、窗口切换、应用启动器、剪贴板历史、截屏工具、录屏工具等——据作者介绍，这些计划源自他本人一款菜单栏工具的功能拆解。
为什么：从现成计划起步，可以先熟悉流程再谈创意，学习成本最低。
注意：建议从“剪贴板历史”这类单窗口小工具开始，完整跑通全流程后，再挑战多窗口复杂应用。
问题 1：Agent 不按技能流程走，直接开始写代码。
原因：技能未装载；或会话上下文过长，技能说明被挤出记忆；或触发条件写得太模糊。
思路：让 Agent 复述当前阶段与可用技能以确认装载；精简上下文；把触发条件改得更具体。
问题 2：克隆路线卡在第一步，无法获取目标应用屏幕。
原因：所用 Agent 缺少屏幕理解与操作能力，或系统未授予屏幕录制权限。
思路：确认能力具备；在系统设置中授予相应权限；必要时由人工补充截图再喂给 Agent。
问题 3：深色模式下界面错乱。
原因：颜色或图片资源被硬编码，未走语义化取值。
思路：全局检索硬编码色值，统一替换为设计系统取值；图片资源提供双主题两套。
问题 4：4pt 网格检查频繁报错。
原因：控件默认尺寸、图标基线、分割线高度等“看不见的 1-2pt”偏移。
思路：优先检查图标与文字基线对齐方式；确认所有边距与内边距取值为 4 的倍数；把修正沉淀为设计系统默认值。
问题 5：重构后行为发生变化。
原因：重构前未固化行为基线，或测试覆盖不足。
思路：先补测试再重构；把“先基线后重构”写入团队纪律。
问题 6：权限被用户拒绝后应用异常。
原因：未设计权限被拒的降级路径。
思路：为每个权限准备“被拒后的功能降级方案与引导文案”，而不是直接崩溃或反复弹窗。
问题 7：一次提交塞入多个故事。
原因：为节省时间合并提交。
思路：回退并拆分。大提交是回滚与审计的天敌，坚持一故事一提交。
本教程把技能化 Agent 工作流拆解为一条可执行的主线：环境与技能装载 → 起步定名与文案 → 转写带验收标准的用户故事 → （可选）屏幕索引克隆 → 分技能编码与系统集成 → 设计系统与 4pt 网格双主题校验 → “一故事一提交”的交付纪律 → 行为不变重构。
它的本质，是把过去依赖个人经验的“手艺”固化为 Agent 可执行的“流程”：用验收标准替代感觉判断，用机器校验替代人眼检查，用小步提交替代大爆炸交付。后续值得持续关注三个方向：把团队自有规范沉淀为自定义技能、技能集与设计取值的版本化管理，以及把这套方法论迁移到其他桌面平台的可能性。