AI Coding - 用 copilot + spec-kit 完成一个 IOS APP

2025 在 AI Coding 领域来说是飞速发展的一年，一路使用过来，感叹与AI成长之迅速。年初的时候还是蹬一步走一步的自行车呢，到年底已经变成可以设置一个导航就自动开往目的地的自动驾驶汽车了。
年初，claude 3.7 发布，借着 copilot 的 edit 模式，一周之内完整移植了一整套 1w 行左右的代码，当时看着编辑器里面每秒冒出好几行代码的速度，同事们纷纷过来录像分享。这一典型案例也被后续分享到了全公司。
cline、roo code 等 vscode 插件的发布，agent 时代正式到来，这一期间我已经逐渐把 ai agent 当作一个实习生使用了，为每个项目仓库建立了 memory-bank，简单的需求写好提示词直接运行。开好多个 vscode 窗口，并行跑好多开发任务。从这个时期开始，我已经基本不使用搜索引擎了，知识类的交互交给 chat，执行类的任务交给 agent。
今年最重磅的事情我还是颁发给 claude code 和 qwen coder，一个是 coding 领域的王者 agent，另一个则物美价廉。任务来了，首先描述一遍需求，让 agent 先试一试，如果效果还可以，就让它接着干，不然就我自己上。但是 token 总归是要收费的，申请了好几次提额之后，使用上也慢慢变得收敛。
最近，github 推出了 copilot-cli，也冒出了很多提示词工具，例如 spec-kit、open-spec、bmad 等等，这又改变了 agent 的使用方式，以前是提前写好尽可能详细的提示词，让 agent 去执行，如果有描述不到位的地方，大模型会自己脑补。现在是前期利用工具，把提示词变得完美，再让大模型在一个没有歧义的提示词环境中去发挥。

前几年玩动森，得知花卉杂交符合孟德尔定律时，觉得非常有趣，课本中冷冰冰的知识，在一天天的期待中逐个应验，相当有成就感。当时每天必定要上线浇花、摆了好多栅栏，防止发生基因不纯的杂交、用纯种基因来验证杂交基因……上学时做任何一个实验都没有这么认真。最终花了半个月，终于培育出了纯种的蓝色玫瑰！
后来好朋友香菜看到国外独立开发者做的 IOS 水族箱小组件，神奇的话题就此融合，我们何不做一个符合孟德尔杂交定律实验的，美观实用的桌面小组件呢！于是在今年在三月份，我已经借助当时的 copilot 力量，搭建了一个原型 demo，但由于没有时间系统学习 swift-ui，而当时的 agent 水平又不能让我完全不操作源码，所以 demo 出来之后新增 feature 的过程推进得就很慢。

是时候，拿出一个早就想要做的项目，尝试一下 1 产品 + 1 开发 + 1 agent 团队的模式，完整实现一个有趣的应用了！

环境搭建

copilot for xcode

copilot 最完整的用法，本来是在 vscode 中内置的应用，或者是 vscode + copilot-cli，这都逃不开用 vscode 来编辑代码。可是 IOS APP 开发偏偏使用 xcode 体验要比 vscode 要好，经过一番搜索，得知 copilot 也有对 xcode 的支持：CopilotForXcode

home brew 安装得太慢了，我使用下载 dmg 文件的方式安装的，安装好后只需当作一个普通应用打开、登录，之后如果 xcode 打开了某个工作区，copilot 窗口就可以正常使用了。

spec-kit

目前的大模型还处在尽可能具体理解用户提示词的阶段，容易被用户言语中的某些词汇引导出倾向性。这无可厚非，如果用户是有意为之，大模型便能够因此给出更准确的输出。但是现实情况是，每个人的语言习惯不一样，有些可能是无意间带入的词汇，也会被大模型当作重点来对待。在大模型还没有进化出理解人类的潜台词之前，利用工具或是查漏补缺，或是引入经验提示词的方式，先生成详细具体没有歧义的提示词，再让大模型去工作，也就能尽可能避免大模型朝错误方向努力。

最近了解的 spec-kit、open-spec、bmad 等工具都有类似的功能，其原理可以简单理解为：1. 让 agent 做角色扮演，只针对自己职责范围做输出；2. 通过预设+问答的方式，提前生成好针对当前项目的提示词。
而这些工具也有自己擅长的领域，例如 open-spec 擅长在已有的项目上增加 feature、bmad 擅长处理多 agent 协作，能很好完成一个大型项目。这里选择 spec-kit 的原因是它擅长从 0 开始搭建一个软件，且不会像 bmad 一样复杂。

安装过程参考的是 spec-kit 仓库文档。

安装 uv curl -LsSf https://astral.sh/uv/install.sh | sh
安装 spec-kit uv tool install specify-cli --from git+https://github.com/github/spec-kit.git

首次配环境，我还是选择自己手动。后续遇到这类问题，我肯定就是在 agent 的对话框里写上：“帮我安装 spec-kit”。

文档工作

现在网上充斥着各种顶着教程的名号介绍 spec-kit 的文章，实际照着使用下来，效果不一定好。文章都说初始化好项目之后，只要顺序执行 constitution、specify、plan、tasks、implement 就好，没有讲每一步具体在做什么，需要注意什么，甚至有的文章直接给出一个只有一行针对当前项目的提示词的 sub-agent，让大家去一键执行。AI 时代下，大家似乎变得有些浮躁，这是危险的信号，效率虽然上去了，但技能退步了，万一遇到 AI 无法正确处理的事项，脑子可能一时间转不过来。
仔细想想，为什么 spec-kit 要设计这么多步骤呢？只执行一个命令，通过问答来一步到位生成所有文档不好吗？我理解是强制用户在每一步完成之后停下来，检查 AI 的输出，审阅并修改，之后或是重新执行当前过程，或是继续下一步。每一步都一定要是针对当前项目来实施的，例如在 agent 里面运行 /speckit.constitution 时，不要照抄示例 /speckit.constitution Create principles focused on code quality, testing standards, user experience consistency, and performance requirements，而是要考虑当前项目真正的原则，给后续的文档实施定一个跟当前项目有关的大基调。

项目初始化

由于我已经有一个 demo 了，在 demo 目录下运行 specify init . --ai copilot，注意，这是在终端里面运行，而不是在 agent 对话里面运行的。在简单几个问答之后，有如下输出

如有必要，也可以运行 specify check 来检查工具有没有安装齐全。

constitution

进入到 agent 界面，安装好 spec-kit 之后，CopilotForXcode 中便会出现 spec-kit 工具的命令。这个项目我选择的是 GPT-5.1 Codex，是 open ai 最新推出的针对编码调优的模型。

选 speckit.constitution，给我们的项目定义一下原则

/speckit.constitution 项目原则集中在代码质量、用户体验一致性、界面美观、交互直观、测试标准以及性能开销上

agent 运行期间会有多次交互；会自动创建分支；会自动打开编辑好的文件，让用户审阅并修改

这一过程生成了一个质量框架规格，内容大致分三个部分：

用户故事 1 - 一致性体验审核（优先级：P1）
用户故事 2 - 视觉协调性与交互预览（优先级：P2）
用户故事 3 - 质量与性能门禁（优先级：P3）

第一条对应“代码质量、用户体验一致性”，第二条对应“界面美观、交互直观”，第三条对应“测试标准以及性能开销”。很好，符合我们当前项目的要求，无需修改，可以进行下一步。

specify

现在可以开始描述需求了，我们应当跟 AI 讲一个故事，主要是讲背景和需求，也就是 what and why，无需关注技术栈。

/speckit.specify 我需要制作一款水族箱小组件应用，把小组件当成一个水族箱，里面用emoji展示出各种元素，包括生物例如各种鱼类和水草，也包括地形例如石头和珊瑚。水族箱里面的同种鱼类可以杂交，用不同的颜色表示不同的性状，杂交符合孟德尔杂交定律，有的鱼类有三对染色体来支撑颜色性状的杂交，有的鱼种有四对。鱼之间杂交时机是随机的，但也要符合现实原理，例如温度高的时候更活跃，或者下雨天更活跃之类的。当鱼发生杂交时，会创造一个新的小鱼，小鱼一开始颜色比较暗淡，身形也比较小，每次喂养的隔天小鱼会长大一个阶段，直到喂养三次，小鱼会长大成可以进行杂交的成年鱼，体形和颜色都到达成年的样子。如果一直不喂养，小鱼也会随机长大，但最短需要3天成长一个阶段，如果遇到小鱼合适的气温或者湿度，也会提前到2天。成年鱼之间的杂交行为也会因为喂养而变得概率更高，喂养是发生在用户点击小组件的时候。小组件里面的鱼会每隔1小时刷新位置。打开app有主界面，主界面上半部分就是水族箱的展示，这一界面的鱼会以正常的速度游动，用户可以拖动鱼到收纳箱，也可以从收纳箱放置鱼或者其他景观元素到水族箱。用户对鱼有两种操作方式，一种是拖动，可以拖动到水族箱或收纳箱里；另一种是点击，点击时会弹出菜单，可以选择放到水族箱/收纳箱、卖出或是分享。菜单顶部也展示着鱼的各种参数，例如品种、价格等，鱼的价格是根据基因的稀有性来定义的，越稀有的鱼越贵。用户卖出鱼时，会有金币余额，可以到商城去购买鱼苗盲盒，鱼苗盲盒可能开出不同品种、不同基因的鱼，但是随着基因的稀有，开出来的概率也会降低，不同品种的鱼开出来的概率也不同，高等级的鱼开出来的概率很低，原则是用户开出来概率最高的几种基因型是可以通过培育产出任意基因型的。鱼苗随着阶段的不同有不同的价值，最小的阶段，也就是刚杂交出来，或者刚从盲盒开出来，直接卖，则获得盲盒一半价钱的报酬，例如盲盒是10金币一个，则鱼苗能卖5金币，如果长到了第二阶段，则能卖这个基因型原价的一半价钱，长到第三阶段以后，则能卖全部价钱。商店也能购买景观元素，例如石头、珊瑚、水草、泡泡等等，这些都和盲盒卖一样的价钱，如果卖出也同样是半价。

这个过程生成了需求文档，内容大概如下：

用户故事 1 - 带喂食与游动功能的鱼缸小组件（优先级：P1）
用户故事 2 - 繁殖、遗传与生长阶段（优先级：P2）
用户故事 3 - 应用内鱼缸管理、库存、商店与经济系统（优先级：P3）

AI 所整理出来的需求：

功能需求
FR-001：系统必须提供一款桌面小组件，以表情符号呈现鱼缸场景中的鱼和布景元素。
FR-002：系统必须至少每小时更新一次小组件内鱼儿的位置，模拟游动效果。
FR-003：系统必须在用户点击小组件时，记录一次喂食事件。
FR-004：系统必须保证投喂后成鱼的繁殖概率，高于未投喂时的繁殖概率。
FR-005：系统仅允许同品种成鱼之间进行繁殖。
FR-006：系统必须依据孟德尔遗传定律生成后代性状。
FR-007：系统需支持具备体色相关染色体的鱼类品种，染色体配对数量可为 3 对或 4 对。
FR-008：系统呈现的幼鱼，体型需小于成鱼，且体色饱和度更低。
FR-009：系统必须在每次喂食事件的次日，将幼鱼生长阶段提升一级；幼鱼累计投喂 3 次后，发育为成鱼。
FR-010：系统需支持无投喂生长模式，幼鱼生长速度受环境适宜度影响 —— 最快每 2 天提升一个阶段，最慢每 3 天提升一个阶段。
FR-011：系统需依据类现实环境因素（如温度、降雨、湿度），按照既定、公开的规则调整繁殖行为的触发概率。
FR-012：应用必须设置主界面，界面上方区域展示鱼缸，鱼儿以正常速度游动。
FR-013：用户必须能将鱼和布景在鱼缸与储物箱之间拖拽转移。
FR-014：用户点击任意一条鱼时，必须弹出菜单，展示该鱼核心参数（至少包含品种和售价），并提供操作选项：转移（鱼缸 / 储物箱）、出售、分享。
FR-015：系统必须依据基因型稀有度为鱼类定价，稀有度越高，售价越高。
FR-016：出售鱼类获得的金币奖励，需由生长阶段和基因型全价共同决定：新生 / 刚获取的鱼苗为盲盒价格的 50%；2 阶段鱼苗为对应基因型全价的 50%；3 阶段> 上为对应基因型全价。
FR-017：商店必须支持用户使用金币购买盲盒鱼苗，购买后必得一条鱼苗。
FR-018：盲盒鱼苗的品种和基因型结果需遵循加权概率规则，稀有度越高的结果获取概率越低；同时需满足设计约束：通过常见品种的繁殖，可培育出所有基因型的。
FR-019：商店必须支持用户购买布景物品（如石头、珊瑚、水草、气泡），且转售时价格为购买价的 50%。
FR-020：所有随机结果（繁殖触发时间、生长加速效果、盲盒结果）必须具备可复现性。
数据定义
品种：定义可用鱼类品种、表情符号样式、染色体配对数量（体色性状对应 3 对或 4 对）及基础稀有度等级。
鱼类：用户拥有的个体，属性包含品种、基因型（体色性状）、表现型（展示颜色）、生长阶段（幼体至成体）、来源（繁殖所得或盲盒获取）及当前位置（鱼缸或储物箱）。
繁殖事件：记录两条成鱼的配对尝试、环境条件及繁殖结果（若有后代）。
喂食事件：带时间戳的记录，标记用户投喂鱼缸的行为（点击小组件）。
布景物品：用户拥有的非鱼类元素，属性包含类型（石头 / 珊瑚 / 水草 / 气泡）、表情符号样式、价格及位置。
金币余额：记录用户当前持有的货币数量。
盲盒商品：定义盲盒价格、按品种和基因型稀有度划分的概率表，且需满足约束条件：通过常见盲盒产出品种的繁殖，可培育出所有基因型的鱼类。