最近一直在用 Agent 帮我写 iOS 代码省事是真省事翻车也是真翻车。最典型的两类问题一是改字段我明明定好的UserProfile模型Agent 一重构就把avatar_url给我改成avatarUrl服务端接口还是下划线命名结果列表页图片全挂二是加弹窗我让它修一个按钮点击无响应的小 bug它倒好顺手在 viewDidLoad 里给我加了个UIAlertController用户一进页面就弹提示产品经理差点杀到我工位上来。踩了几次坑之后我决定不再靠“每次对话都重复叮嘱”这种低效方式去约束 Agent。我把项目里沉淀下来的规范、约束、审查清单做成了一个可安装的 Skills 包开源出来。这套东西不是魔法本质上就是把“团队成员必须遵守的开发约定”变成 Agent 也能读、能理解、能执行的规则集。这篇文章我会把为什么要这么做、Skills 怎么设计、实际安装和验证过程以及我踩过的坑全部拆开讲清楚希望能给同样被 Agent 折腾过的 iOS 开发者一些参考。1. 为什么 Agent 写 iOS 总翻车乱改字段、乱加弹窗的根源分析先别急着骂 Agent 蠢它的问题其实很符合逻辑。理解它为什么会这么干你才能真正找到约束它的办法。1.1 翻车场景还原两个最典型的“自作主张”先说改字段。iOS 开发里最常见的字段联动就是 JSON 解析。服务端返回的字段是user_idSwift 里按惯例写成userId中间用CodingKeys做映射。Agent 拿到需求“给用户模块加一个 VIP 状态展示”它就开始干活了——看完UserModel.swift它觉得userName这种命名风格跟VIPStatus不一致顺手把userName改成了username自认为“更规范”。结果呢CodingKeys没同步改key跟服务端字段对不上线上用户昵称全部变成空字符串。这种问题 Debug 起来极其恶心因为编译不报错崩溃也没有就是数据诡异地对不上。再说乱加弹窗。Agent 的思维模式是“用户需要被提示”。我让它处理登录超时逻辑它认为超时应该弹一个“登录已过期请重新登录”的 Alert听起来没毛病但它没想过当前页面正处于表单填写中途用户刚输入一半的内容还没保存一个模态弹窗直接把用户操作打断而且这个页面的产品逻辑里根本没有“超时弹窗”这个设计。更离谱的一次它为了“增强用户体验”在启动页加载失败时加了一个强制弹窗连“取消”按钮都不给用户只能杀掉 App 重进。这两个场景的共同点是什么Agent 在没有足够上下文约束的情况下会自动补全它认为“合理”的行为。而它眼里的“合理”跟我项目里的“合理约定”之间差距非常大。1.2 根源拆解不是能力问题是约束缺失我后来仔细分析过 Agent 翻车的深层次原因基本可以归为三点。第一Agent 的上下文窗口是有限的。一个 iOS 项目动辄几百个文件Agent 不可能把所有模型定义、接口协议、页面结构全部读完。它通常只检索与当前任务直接相关的少数文件。这就导致它看不到全局约定——比如AppConfig.swift里定义了全局统一的弹窗样式和入口它偏要在业务代码里自己 new 一个UIAlertController出来。第二Agent 对“隐性需求”的理解依赖你的表述精度。你说“处理一下刷新失败的情况”它默认想到的是“弹窗提示用户”但你可能想要的是“静默重试两次再提示”。这些差异如果不在规则层面写清楚每次对话都要重新解释一遍效率极低而且一旦这次忘了说Agent 又开始自由发挥。第三Agent 对“改动的影响面”缺乏判断力。修改一个 model 字段在人类开发者脑子里会自动关联CodingKeys 改没改数据库迁移要不要动SwiftUI 预览里有没有引用缓存归档用的Codable结构是否兼容Agent 没有这种职业病它改完眼前的报错就觉得自己完工了影响面分析完全看心情。说白了Agent 像是一个能力很强、干劲很足但是完全不了解项目背景和团队规范的新人。你要么每次把规范重复一遍要么把规范变成它能自动加载的东西。1.3 为什么“每次对话重复叮嘱”这条路走不通我知道有人会说“你每次用 Agent 之前先把规则在提示词里写清楚不就行了”我试过而且试了很久。问题在于三点。第一提示词是有长度限制的你不可能把一份几百行的 iOS 开发规范完整塞进每次对话里塞进去了也会严重挤占真正处理业务逻辑的空间。第二不同任务的约束需求不一样——做数据模型迁移时我希望 Agent 格外谨慎地对待字段改名但做 UI 调整时我更关心它不要破坏 SwiftUI 的视图结构 — 一套固定的提示词无法灵活覆盖这些场景。第三人类在写提示词的时候本身就会遗漏。你这次忘了提“禁止乱加弹窗”Agent 就真的给你加弹窗防不胜防。所以问题的本质变成了能不能有一套机制让 Agent 在开始处理任务前自动加载对应的约束规则而且这些规则还能分场景、分项目灵活配置这正是 Skills 这套机制能解决的事。2. 我为什么选择用 Skills 机制来约束 Agent2.1 先理解 Skills 是什么它不是提示词是“给 Agent 装的行业规范包”很多人第一次听到 Skills 这个概念第一反应是“这不就是高级提示词吗”我在实践之前也是这么想的用完之后才意识到两者的本质区别。提示词是在“每次对话开始前”由用户手动输入的一段文字它是一次性的、临时的、依赖用户记得住、依赖用户写得全。而 Skills 是一套可以被 Agent 主动发现、按需加载的结构化技能包。它通常包含一组经过设计的指令文件、代码示例、检查清单甚至包括可执行的脚本。放在项目里之后Agent 会在合适的场景下自动去读取对应的内容。我打一个比方。提示词像是你在面试候选人时口头交代“我们公司上班不能迟到、代码要写注释”候选人点头说记住了但转头就忘。Skills 像是你给新员工一本《员工手册》加一套《开发规范》入职第一天自动发到他手上他干活的时候遇到对应场景会去翻手册而不是凭直觉自由发挥。放到 iOS 开发场景里我把长期以来在项目里积累的约定比如“字段命名风格怎么统一”“哪些情况禁止弹窗”“Core Data 迁移要注意什么”全部沉淀成 Skills 里的规则文件。Agent 在处理相关任务时会自动读到这些规则并且在我的项目里实测下来它对规则文件的遵循度远远高于对话里临时交代的话。2.2 方案选型对比为什么不是单纯写 CLAUDE.md 或者项目文档在决定做 Skills 之前我对比过几种常见方案。第一种是写项目文档比如 README、ARCHITECTURE.md。这当然有用但问题在于 Agent 读取文档是被动的。你要在对话里明确让它“先读一下 ARCHITECTURE.md 再动手”否则它可能根本不会主动去看。就算看了文档是给人写的语言结构跟 Agent 指令的执行偏好并不完全匹配信息密度也不够针对性。第二种是写 CLAUDE.md 这种 Agent 配置文件。它能被 Agent 自动加载这一点比纯文档好很多。但它的粒度比较粗适合放全局性的项目说明比如技术栈、目录结构、常用命令。它不太适合放“字段命名规范”“弹窗使用约束”“Code Review 清单”这种细颗粒度的操作规则——全塞进去会让主配置变得异常臃肿而且无法按需细分场景。第三种就是 Skills。它最大的优势是“模块化 按需加载”。我把规则拆成多个独立技能包比如数据模型保护、UI 行为约束、代码审查清单Agent 在处理“网络层重构”任务时会加载数据模型保护包在处理“页面修改”任务时会加载 UI 约束包各取所需互不干扰。这种精细度是 CLAUDE.md 做不到的。另外还有一个很重要的原因Skills 是可分享、可复用的。我在一个项目里调试好的规则包可以很方便地复制到另一个新项目里只需修改少量项目特定配置。这对于像我这种手里同时维护好几个 iOS 项目的人来说节省的重复劳动是非常可观的。2.3 这套 Skills 的目标让 Agent 的行为边界清晰可预期我在设计这套 Skills 时给自己定的原则是“不是让 Agent 不犯错而是让 Agent 在犯错之前先意识到自己在做什么”。这句话听起来有点绕我解释一下。我的目标并不是写一套天网级别的规则把 Agent 的所有行为都锁死那样的话 Agent 就失去了灵活辅助的意义。我真正想要的是在 Agent 做出高风险动作之前——比如修改已有字段名、新增全局弹窗、改动网络层解析逻辑——它能先停下来检查一下自己的改动是否符合项目约定如果不符合它应该主动说明而不是默默执行。这套 Skills 的核心设计理念就是给 Agent 建立“行为边界”。边界之内它自由发挥边界之外它必须报备。我把 iOS 开发里容易翻车的边界总结成了几类数据模型边界、UI 行为边界、接口契约边界、代码风格边界。每一类对应一个 skill 文件里面写清楚规则、理由、正反例以及违反规则时的替代操作建议。后面我会详细展开每个技能包的具体内容。3. 开源 Skills 的模块设计与核心实现3.1 总体架构拆解四个技能包加一个安装器这套开源项目叫ios-agent-skills整个结构非常轻量不依赖任何第三方库本质上是几个 Markdown 指令文件加一个安装脚本。核心结构如下ios-agent-skills/ ├── install.sh ├── README.md ├── config.example.yaml └── skills/ ├──>第一步列出当前模型类所有的存储属性 第二步列出 CodingKeys 中已有的映射 第三步对比服务端接口文档或网络层 response 示例确认每个属性都有正确映射 第四步如果新增属性必须同步新增 CodingKeys case 第五步修改完成后输出一份字段映射对照表供用户确认这个操作顺序看起来简单但如果没有规则约束Agent 经常默认“Swift 属性名和服务端字段名一致”直接省略了 CodingKeys等 Debug 的时候才发现数据全部解析失败。migration-safety.md主要面向用了 Core Data 或者 Realm 的项目。规则要求 Agent 在改动持久化模型前必须先确认是否涉及已有数据的迁移方案。如果涉及禁止直接删除旧字段应该采用“新增字段 迁移映射”的方式避免老用户升级 App 后数据丢失。这条规则救过我一次当时 Agent 想删掉一个废弃字段我拦住了后来检查发现线上还有一部分老版本用户在用旧数据结构直接删会导致他们升级后崩溃。3.3 UI 行为约束包把“禁止乱加弹窗”变成硬规则这个包是我被产品经理骂完之后连夜写的。核心思路很直接给弹窗设置审批门槛。alert-approval.md里明确写道Agent 默认无权新增任何 UIAlertController、UIAlertView、或者 SwiftUI 的 .alert 修饰器。如果 Agent 认为业务逻辑需要弹窗提示它必须按以下格式输出提议等待用户确认弹窗提议 - 触发场景描述什么情况下会弹出 - 展示内容弹窗的标题和正文 - 风格类型alert / actionSheet / 自定义弹窗 - 可取消性是否允许用户取消 - 替代方案有没有不打断用户操作的替代交互这个设计的目的是强制 Agent 在“加弹窗”之前先想清楚这个弹窗是否真的必要有没有更轻量的表达方式我在规则里给出了几种替代建议Toast 轻提示、页面内嵌 banner、HUD 自动消失、按钮状态变化等。实际用下来Agent 在走完这个提议流程后经常自己就发现弹窗不是最优解转而去用 Toast效果比直接禁止它自由发挥好得多。navigation-flow.md约束的是页面跳转逻辑。我遇到过 Agent 为了“方便用户”在付款成功页加了一个自动跳回首页的导航逻辑结果导致用户付款后看不到订单详情页的确认信息。规则要求任何非用户主动触发的自动跳转必须经过用户确认。对于有明确产品流程的页面Agent 只能修改当前页面内部的状态禁止跨页面执行跳转。loading-states.md处理的是加载状态的展示逻辑。规则里写了一个决策树式的判断流程网络请求发起时需要判断是首次加载、下拉刷新还是分页加载不同场景对应不同的 loading 展示策略。首屏加载可以用全屏 loading但分页加载只能在列表底部展示小菊花如果使用 SwiftUI优先用.redacted(reason: .placeholder)做骨架屏而不是直接用 ProgressView 盖住整个页面。有了这套规则Agent 很少再写出“一进页面就转菊花转半天”这种反人类的交互。3.4 API 契约守卫包字段映射与接口对接的防错网这个包解决的是网络层的字段对接问题。iOS 开发里很多字段问题其实不是 model 定义错了而是网络层解析和服务端返回不一致导致的。Agent 在处理网络层代码时经常会拿着客户端 model 的属性名去直接匹配服务端返回值一旦不匹配就自行修改解析逻辑结果拆东墙补西墙。endpoint-mapping.md里我制定了一条铁律客户端 model 属性名只由 CodingKeys 决定禁止在网络层直接做字段名转换。如果服务端字段和客户端属性不一致唯一正确的做法是在 model 的 CodingKeys 里加映射而不是在 URLSession 或 Alamofire 的 response 解析阶段手写转换逻辑。param-validation.md处理的是请求参数的校验。规则要求 Agent 在构造请求参数时必须对照服务端接口文档校验以下内容1. 参数名是否与接口文档完全一致大小写敏感 2. 必填参数是否都已经赋值 3. 可选参数为 nil 时是否应该从请求中移除 4. 数组类型参数为空数组时服务端是否接受 5. 时间参数是秒级还是毫秒级为什么专门写这个包因为我踩过一个很隐蔽的坑服务端时间格式用的是毫秒级时间戳接口文档写得很清楚但 Agent 在构造请求时习惯性用了Date().timeIntervalSince1970秒级结果服务端解析出来的时间全都不对。这类问题编译不报错、请求不失败就是数据错排查起来极其费劲。error-handling.md约束的是网络错误处理的策略。规则要求 Agent 区分错误类型采用不同的处理方式网络不可达应该展示全局离线提示超时错误应该支持静默重试一次服务端 5xx 错误应该提示“服务繁忙”而不是把原始错误信息直接抛给用户。这个包写完之后Agent 写出来的错误处理代码明显更成熟了不再是一律 return 一个错误弹窗。3.5 代码风格与 Review 包让 Agent 自查而不是全靠人查最后一个技能包是代码审查清单。它不能自动阻止 Agent 犯错但能在 Agent 完成修改后强制它走一遍自查流程很多问题在这个阶段能被拦截住。review-rules.md里我设计了一个检查清单要求 Agent 在完成任何代码修改后必须逐条确认并在输出中展示1. 是否修改了任何已有字段的名称或类型如果修改了是否已经同步更新所有引用和 CodingKeys 2. 是否新增了任何弹窗、Toast、提示条是否经过用户确认是否有替代方案 3. 是否改动了解析逻辑解析逻辑的改动是否与 CodingKeys 保持一致 4. 是否引入了新的依赖是否经过用户确认Package.swift / Podfile 是否同步修改 5. 是否处理了错误场景网络失败、数据为空、权限拒绝等分支是否都有明确处理 6. 是否兼容最低支持系统版本使用的 API 是否需要 available 标注这个清单的执行效果让我挺意外的。Agent 在输出自查结果时经常会出现“我在自查中发现第 2 条需要说明我新增了一个错误提示 Toast理由如下……”——本来它想着蒙混过关直接删掉弹窗逻辑但自查流程逼着它把决定暴露出来用户就有了确认的机会。这比任何静态检查工具都灵活因为它是促使 Agent 主动暴露决策逻辑而不是机械地跑一遍 lint。配置层面项目里有一个config.example.yaml文件用来控制哪些技能包开启、哪些关闭、某些规则的严格程度project: name: MyAwesomeApp deployment_target: 15.0 skills_enabled: >git clone https://github.com/yourname/ios-agent-skills.git cd ios-agent-skills第二步执行安装脚本。脚本会自动检测当前目录是否为 iOS 项目通过查找.xcodeproj或Package.swift文件检测通过后开始复制文件chmod x install.sh ./install.sh /path/to/DemoApp安装脚本会在终端输出类似下面的日志Checking /path/to/DemoApp ... Found DemoApp.xcodeproj Detected Agent skills directory: /path/to/DemoApp/.agent/skills Copying>提示词模板 处理 [任务描述]。 在动手之前先检查项目中是否有与本次修改相关的技能包。 如果有必须先加载对应技能包并确保你的修改符合其中的全部规则。 修改完成后按 code-review-checklist 技能包的要求输出自查结果。这个提示词模板本身不需要很长关键是让 Agent 养成“先看技能包再动手”的习惯。我实测下来加上这句话和没加这句话Agent 的行为差异非常明显。加了的会话里它会在动手前主动输出“检测到>检测到>检测到 ui-behavior-constraints 技能包。 当前任务涉及错误提示场景按照规则需要先给出弹窗提议 弹窗提议 - 触发场景用户点击登录按钮且网络请求返回错误 - 展示内容登录失败请稍后重试 - 风格类型alert - 可取消性允许用户点击确认后取消 - 替代方案仅停留在当前页面在登录按钮下方显示一行错误提示文案不打断用户输入 建议采用替代方案原因是用户已填写完表单弹窗会遮住输入内容万一服务端要求修正某些字段用户还要关闭弹窗再重新查看体验不好。请确认是否采用替代方案这个输出说明技能包里的“替代方案优先”原则真的被 Agent 理解了它不再是一个只会执行命令的工具而是一个会主动思考交互合理性的辅助角色。第三个测试用例是“自查清单测试”。我让 Agent 修改一个 ViewController 里几个私有方法然后要求它输出自查结果。它可以准确列出“未修改任何字段”“未新增弹窗”“未改动解析逻辑”“修改了两个私有方法的作用域已确认无其他引用”——这条自查结果帮我确认它改动的边界判断与我的预期完全一致。这三个用例跑通了我才放心把这套 Skills 用到正式的日常开发里。4.4 实际项目中的效果对比我把这套 Skills 用在一个持续迭代的线上项目里跑了大概两周时间处理了 30 多个任务覆盖网络层重构、模型扩展、UI 调整、Bug 修复这些常见场景。最直观的变化是“意外改动”的数量大幅下降。之前我几乎每次 review Agent 的提交都要拦截一些无关修改比如它顺便改了个变量名、删了个落后注释、调整了某处的缩进。装了技能包之后这种顺手牵羊的行为明显少了提交的 diff 基本只包含任务相关的改动review 起来轻松太多了。弹窗类的问题更是基本清零。两周内 Agent 只提出了一次弹窗建议而且是在走完提议流程后被我否掉的场景——它想在新用户注册成功时弹一个欢迎窗我告诉它产品经理的需求是直接进入首页不需要额外弹窗它立刻就接受了。要知道在没装 Skills 之前它一周能擅自加三四个弹窗每次都是我在 review 阶段发现然后删掉。字段映射的问题也有明显改善。之前 Agent 在新增字段时经常忘记同步 CodingKeys导致 JSON 解析静默失败。现在它在数据模型相关任务里会自动输出字段映射对照表我只需要快速扫一眼确认服务端字段名是否正确即可省掉了大量排查成本。5. 常见问题与排查技巧实录5.1 Agent 没有自动加载技能包怎么办这是最常遇到的问题。辛苦装好了技能包结果 Agent 完全无视它还是在自由发挥。我排查下来的经验主要有三个原因。第一技能包的目录位置不对。不同 Agent 工具扫描 skills 目录的路径不一样有的扫描项目根目录下的.agent/skills有的则是全局级别的配置目录。装完之后一定要用对话让 Agent “列出你的 skills 目录里有哪些技能包”直接问它看它能不能报出技能包的名字。如果报不出来说明路径没对赶紧检查。第二任务类型跟技能包的触发场景不匹配。我设计的技能包有明显的场景边界比如ui-behavior-constraints只在涉及 UI 行为修改时加载如果任务只是“给 Model 加几个字段”它就不应该加载。这本身是设计意图不是 bug。但如果你希望某个技能包在任务里强制加载就在提示词里直接点名“先加载 ui-behavior-constraints 技能包并严格遵循。”第三Agent 工具版本对 skills 机制的支持不完整。有一些新出的 Agent 工具或者一些工具的旧版本对 skills 目录的扫描并不完善。遇到这种情况我的妥协方案是把技能的SKILL.md核心内容手动追加到项目的 Agent 配置文件中这样至少能保证规则被加载只是失去了按需加载的灵活性。5.2 规则写了但 Agent 不遵守怎么办这个问题的核心通常是“规则文件的表达方式不符合 Agent 的读取偏好”。我最早的第一版 Skills 写得太像给人看的技术文档用了大量描述性语言比如“请尽量保持代码风格一致注意处理边界情况”——这种话 Agent 读了等于没读因为完全是模糊的。后来我改成“命令式 正反例对照”的写法效果立竿见影。比如“禁止修改已有字段名”这一条我一开始写的是请勿随意修改已有的属性名称以免影响 Codable 解码。改成禁止单方面重命名已有属性。 正确做法保持现有属性名不变仅修改所需逻辑。 错误做法将 userName 改为 username导致 CodingKeys 失效。Agent 对“正确做法 / 错误做法”这种结构的学习效果比对纯原则描述优秀很多。我推测原因是正反例给 Agent 提供了非常具体的模式匹配基准它看到相似代码时更容易触发判断这个操作是正确还是错误。另一个有用的技巧是给规则配置明确的“后果说明”。比如我写“修改 CodingKeys 映射但不更新测试会导致 {Mock 数据解析失败、单元测试全红、线上数据丢失}”Agent 在理解规则背后的原因之后会更有动力去遵守而不是机械执行。5.3 团队协作时技能包冲突怎么处理如果你的团队有多个开发者在同一个项目上协作每个人可能都装了各自的技能包版本相互之间很容易冲突。我在实际协作中试过几种方案。最省事的是把技能包纳入版本管理和项目代码一起提交。在项目根目录的.gitignore里排除掉config.yaml之类的本地配置文件但把skills/目录纳入 Git 管理。这样所有成员 clone 下来就有统一的规则不用每个人都去手动安装。不过要注意不同成员本地的 Agent 配置路径可能不同。比如我用 Claude Code 时技能目录在项目下的.agent/skills同事用别的工具时路径可能就不一样。我们的解决办法是在项目的AGENTS.md或README.md里写清楚技能包的正确安装方式和验证命令新成员入职时照着跑一遍即可。还有一个值得注意的点技能包里尽量别写和具体开发者强相关的内容统一用相对路径描述项目结构这样换人换机器都不会出问题。5.4 几个独家的排查手段最后分享几个我在折腾过程中摸索出来的比较野路子但好用的排查手段。第一个是“规则审计法”。如果你不确定某个规则文件有没有被正确加载直接让 Agent 用自己的话复述这个规则的内容“请阅读 ui-behavior-constraints 技能包里的 alert-approval.md然后用你自己的话总结一下核心约束。”它能准确复述说明加载成功如果它说得乱七八糟说明文件路径有问题或者加载机制有 bug。第二个是“误差注入法”。我故意在对话里提一个模糊的需求比如“优化一下启动流程”看它会不会触犯领域边界——比如擅自改动启动页的字段映射或者加一个“欢迎使用新版”弹窗。这种开放式的模糊任务能充分暴露 Agent 的自由发挥倾向如果它有越狱的迹象说明技能包的约束强度需要加强。第三个是“diff 审查法”。每完成一个任务我都让 Agent 输出它改动了哪些文件、每个文件的具体改动内容是什么并对比改动前的文件内容。这个方法配合自查清单效果极好能快速发现 Agent 是否在“计划外”修改了无关代码。如果某次任务结束后发现它改了七八个文件其中两三个跟任务毫无关系就能立刻问它为什么要动这些文件并要求还原。6. 我对 Agent 辅助开发的一点真实体会这套 Skills 项目做下来我最大的感受是Agent 的开发能力本身已经不成问题了真正决定它是“得力助手”还是“猪队友”的往往是约束和规范有没有到位。就像你招了一个能力很强的毕业生他技术扎实、学习能力强但如果不提前告诉他项目里的红线在哪里他一定会踩雷。Skills 干的就是“提前画红线”这件事。我在实际使用中还有一个意外收获把这些规则整理成技能包的过程中我自己对项目的理解反而更清晰了。为了写清楚“什么情况下 Agent 不该加弹窗”我去回顾了之前所有被产品经理打回的弹窗需求总结出了规律为了写清楚“字段命名的规范”我跟后端同学重新对齐了一遍接口文档里的 key 命名逻辑。这些梳理对团队协作也有帮助规则文件直接变成新人的入门文档一举两得。如果你也被 Agent 乱改字段、乱加弹窗这类问题困扰我真心建议你试试这个思路。一开始可以先从最简单的场景入手比如只做一个禁止乱加弹窗的约束包用一段时间感受一下 Agent 行为的变化然后再逐步扩展成覆盖数据模型、网络层、代码审查的完整规则体系。开源仓库里的技能包是一个可以直接用的起步版本我后续还会继续迭代完善计划增加 SwiftUI 专属约束包和并发安全相关的规则。相关链接放在文末大家按需自取。最后留一个非常实用的小技巧在安装完 Skills 之后别急着投入正式开发先用我上面说的三个测试用例把 Agent 的每一类边界行为都验证一遍。这个过程花不了半小时但能帮你提前发现配置问题避免正式开发时突然翻车。等你做完了你会真正感觉到 Agent 写代码的时候终于像是在“跟自己人配合”而不是在跟一个陌生的实习生周旋了。
用 Agent Skills 约束 AI 编程助手：解决 iOS 开发乱改字段与乱加弹窗
最近一直在用 Agent 帮我写 iOS 代码省事是真省事翻车也是真翻车。最典型的两类问题一是改字段我明明定好的UserProfile模型Agent 一重构就把avatar_url给我改成avatarUrl服务端接口还是下划线命名结果列表页图片全挂二是加弹窗我让它修一个按钮点击无响应的小 bug它倒好顺手在 viewDidLoad 里给我加了个UIAlertController用户一进页面就弹提示产品经理差点杀到我工位上来。踩了几次坑之后我决定不再靠“每次对话都重复叮嘱”这种低效方式去约束 Agent。我把项目里沉淀下来的规范、约束、审查清单做成了一个可安装的 Skills 包开源出来。这套东西不是魔法本质上就是把“团队成员必须遵守的开发约定”变成 Agent 也能读、能理解、能执行的规则集。这篇文章我会把为什么要这么做、Skills 怎么设计、实际安装和验证过程以及我踩过的坑全部拆开讲清楚希望能给同样被 Agent 折腾过的 iOS 开发者一些参考。1. 为什么 Agent 写 iOS 总翻车乱改字段、乱加弹窗的根源分析先别急着骂 Agent 蠢它的问题其实很符合逻辑。理解它为什么会这么干你才能真正找到约束它的办法。1.1 翻车场景还原两个最典型的“自作主张”先说改字段。iOS 开发里最常见的字段联动就是 JSON 解析。服务端返回的字段是user_idSwift 里按惯例写成userId中间用CodingKeys做映射。Agent 拿到需求“给用户模块加一个 VIP 状态展示”它就开始干活了——看完UserModel.swift它觉得userName这种命名风格跟VIPStatus不一致顺手把userName改成了username自认为“更规范”。结果呢CodingKeys没同步改key跟服务端字段对不上线上用户昵称全部变成空字符串。这种问题 Debug 起来极其恶心因为编译不报错崩溃也没有就是数据诡异地对不上。再说乱加弹窗。Agent 的思维模式是“用户需要被提示”。我让它处理登录超时逻辑它认为超时应该弹一个“登录已过期请重新登录”的 Alert听起来没毛病但它没想过当前页面正处于表单填写中途用户刚输入一半的内容还没保存一个模态弹窗直接把用户操作打断而且这个页面的产品逻辑里根本没有“超时弹窗”这个设计。更离谱的一次它为了“增强用户体验”在启动页加载失败时加了一个强制弹窗连“取消”按钮都不给用户只能杀掉 App 重进。这两个场景的共同点是什么Agent 在没有足够上下文约束的情况下会自动补全它认为“合理”的行为。而它眼里的“合理”跟我项目里的“合理约定”之间差距非常大。1.2 根源拆解不是能力问题是约束缺失我后来仔细分析过 Agent 翻车的深层次原因基本可以归为三点。第一Agent 的上下文窗口是有限的。一个 iOS 项目动辄几百个文件Agent 不可能把所有模型定义、接口协议、页面结构全部读完。它通常只检索与当前任务直接相关的少数文件。这就导致它看不到全局约定——比如AppConfig.swift里定义了全局统一的弹窗样式和入口它偏要在业务代码里自己 new 一个UIAlertController出来。第二Agent 对“隐性需求”的理解依赖你的表述精度。你说“处理一下刷新失败的情况”它默认想到的是“弹窗提示用户”但你可能想要的是“静默重试两次再提示”。这些差异如果不在规则层面写清楚每次对话都要重新解释一遍效率极低而且一旦这次忘了说Agent 又开始自由发挥。第三Agent 对“改动的影响面”缺乏判断力。修改一个 model 字段在人类开发者脑子里会自动关联CodingKeys 改没改数据库迁移要不要动SwiftUI 预览里有没有引用缓存归档用的Codable结构是否兼容Agent 没有这种职业病它改完眼前的报错就觉得自己完工了影响面分析完全看心情。说白了Agent 像是一个能力很强、干劲很足但是完全不了解项目背景和团队规范的新人。你要么每次把规范重复一遍要么把规范变成它能自动加载的东西。1.3 为什么“每次对话重复叮嘱”这条路走不通我知道有人会说“你每次用 Agent 之前先把规则在提示词里写清楚不就行了”我试过而且试了很久。问题在于三点。第一提示词是有长度限制的你不可能把一份几百行的 iOS 开发规范完整塞进每次对话里塞进去了也会严重挤占真正处理业务逻辑的空间。第二不同任务的约束需求不一样——做数据模型迁移时我希望 Agent 格外谨慎地对待字段改名但做 UI 调整时我更关心它不要破坏 SwiftUI 的视图结构 — 一套固定的提示词无法灵活覆盖这些场景。第三人类在写提示词的时候本身就会遗漏。你这次忘了提“禁止乱加弹窗”Agent 就真的给你加弹窗防不胜防。所以问题的本质变成了能不能有一套机制让 Agent 在开始处理任务前自动加载对应的约束规则而且这些规则还能分场景、分项目灵活配置这正是 Skills 这套机制能解决的事。2. 我为什么选择用 Skills 机制来约束 Agent2.1 先理解 Skills 是什么它不是提示词是“给 Agent 装的行业规范包”很多人第一次听到 Skills 这个概念第一反应是“这不就是高级提示词吗”我在实践之前也是这么想的用完之后才意识到两者的本质区别。提示词是在“每次对话开始前”由用户手动输入的一段文字它是一次性的、临时的、依赖用户记得住、依赖用户写得全。而 Skills 是一套可以被 Agent 主动发现、按需加载的结构化技能包。它通常包含一组经过设计的指令文件、代码示例、检查清单甚至包括可执行的脚本。放在项目里之后Agent 会在合适的场景下自动去读取对应的内容。我打一个比方。提示词像是你在面试候选人时口头交代“我们公司上班不能迟到、代码要写注释”候选人点头说记住了但转头就忘。Skills 像是你给新员工一本《员工手册》加一套《开发规范》入职第一天自动发到他手上他干活的时候遇到对应场景会去翻手册而不是凭直觉自由发挥。放到 iOS 开发场景里我把长期以来在项目里积累的约定比如“字段命名风格怎么统一”“哪些情况禁止弹窗”“Core Data 迁移要注意什么”全部沉淀成 Skills 里的规则文件。Agent 在处理相关任务时会自动读到这些规则并且在我的项目里实测下来它对规则文件的遵循度远远高于对话里临时交代的话。2.2 方案选型对比为什么不是单纯写 CLAUDE.md 或者项目文档在决定做 Skills 之前我对比过几种常见方案。第一种是写项目文档比如 README、ARCHITECTURE.md。这当然有用但问题在于 Agent 读取文档是被动的。你要在对话里明确让它“先读一下 ARCHITECTURE.md 再动手”否则它可能根本不会主动去看。就算看了文档是给人写的语言结构跟 Agent 指令的执行偏好并不完全匹配信息密度也不够针对性。第二种是写 CLAUDE.md 这种 Agent 配置文件。它能被 Agent 自动加载这一点比纯文档好很多。但它的粒度比较粗适合放全局性的项目说明比如技术栈、目录结构、常用命令。它不太适合放“字段命名规范”“弹窗使用约束”“Code Review 清单”这种细颗粒度的操作规则——全塞进去会让主配置变得异常臃肿而且无法按需细分场景。第三种就是 Skills。它最大的优势是“模块化 按需加载”。我把规则拆成多个独立技能包比如数据模型保护、UI 行为约束、代码审查清单Agent 在处理“网络层重构”任务时会加载数据模型保护包在处理“页面修改”任务时会加载 UI 约束包各取所需互不干扰。这种精细度是 CLAUDE.md 做不到的。另外还有一个很重要的原因Skills 是可分享、可复用的。我在一个项目里调试好的规则包可以很方便地复制到另一个新项目里只需修改少量项目特定配置。这对于像我这种手里同时维护好几个 iOS 项目的人来说节省的重复劳动是非常可观的。2.3 这套 Skills 的目标让 Agent 的行为边界清晰可预期我在设计这套 Skills 时给自己定的原则是“不是让 Agent 不犯错而是让 Agent 在犯错之前先意识到自己在做什么”。这句话听起来有点绕我解释一下。我的目标并不是写一套天网级别的规则把 Agent 的所有行为都锁死那样的话 Agent 就失去了灵活辅助的意义。我真正想要的是在 Agent 做出高风险动作之前——比如修改已有字段名、新增全局弹窗、改动网络层解析逻辑——它能先停下来检查一下自己的改动是否符合项目约定如果不符合它应该主动说明而不是默默执行。这套 Skills 的核心设计理念就是给 Agent 建立“行为边界”。边界之内它自由发挥边界之外它必须报备。我把 iOS 开发里容易翻车的边界总结成了几类数据模型边界、UI 行为边界、接口契约边界、代码风格边界。每一类对应一个 skill 文件里面写清楚规则、理由、正反例以及违反规则时的替代操作建议。后面我会详细展开每个技能包的具体内容。3. 开源 Skills 的模块设计与核心实现3.1 总体架构拆解四个技能包加一个安装器这套开源项目叫ios-agent-skills整个结构非常轻量不依赖任何第三方库本质上是几个 Markdown 指令文件加一个安装脚本。核心结构如下ios-agent-skills/ ├── install.sh ├── README.md ├── config.example.yaml └── skills/ ├──>第一步列出当前模型类所有的存储属性 第二步列出 CodingKeys 中已有的映射 第三步对比服务端接口文档或网络层 response 示例确认每个属性都有正确映射 第四步如果新增属性必须同步新增 CodingKeys case 第五步修改完成后输出一份字段映射对照表供用户确认这个操作顺序看起来简单但如果没有规则约束Agent 经常默认“Swift 属性名和服务端字段名一致”直接省略了 CodingKeys等 Debug 的时候才发现数据全部解析失败。migration-safety.md主要面向用了 Core Data 或者 Realm 的项目。规则要求 Agent 在改动持久化模型前必须先确认是否涉及已有数据的迁移方案。如果涉及禁止直接删除旧字段应该采用“新增字段 迁移映射”的方式避免老用户升级 App 后数据丢失。这条规则救过我一次当时 Agent 想删掉一个废弃字段我拦住了后来检查发现线上还有一部分老版本用户在用旧数据结构直接删会导致他们升级后崩溃。3.3 UI 行为约束包把“禁止乱加弹窗”变成硬规则这个包是我被产品经理骂完之后连夜写的。核心思路很直接给弹窗设置审批门槛。alert-approval.md里明确写道Agent 默认无权新增任何 UIAlertController、UIAlertView、或者 SwiftUI 的 .alert 修饰器。如果 Agent 认为业务逻辑需要弹窗提示它必须按以下格式输出提议等待用户确认弹窗提议 - 触发场景描述什么情况下会弹出 - 展示内容弹窗的标题和正文 - 风格类型alert / actionSheet / 自定义弹窗 - 可取消性是否允许用户取消 - 替代方案有没有不打断用户操作的替代交互这个设计的目的是强制 Agent 在“加弹窗”之前先想清楚这个弹窗是否真的必要有没有更轻量的表达方式我在规则里给出了几种替代建议Toast 轻提示、页面内嵌 banner、HUD 自动消失、按钮状态变化等。实际用下来Agent 在走完这个提议流程后经常自己就发现弹窗不是最优解转而去用 Toast效果比直接禁止它自由发挥好得多。navigation-flow.md约束的是页面跳转逻辑。我遇到过 Agent 为了“方便用户”在付款成功页加了一个自动跳回首页的导航逻辑结果导致用户付款后看不到订单详情页的确认信息。规则要求任何非用户主动触发的自动跳转必须经过用户确认。对于有明确产品流程的页面Agent 只能修改当前页面内部的状态禁止跨页面执行跳转。loading-states.md处理的是加载状态的展示逻辑。规则里写了一个决策树式的判断流程网络请求发起时需要判断是首次加载、下拉刷新还是分页加载不同场景对应不同的 loading 展示策略。首屏加载可以用全屏 loading但分页加载只能在列表底部展示小菊花如果使用 SwiftUI优先用.redacted(reason: .placeholder)做骨架屏而不是直接用 ProgressView 盖住整个页面。有了这套规则Agent 很少再写出“一进页面就转菊花转半天”这种反人类的交互。3.4 API 契约守卫包字段映射与接口对接的防错网这个包解决的是网络层的字段对接问题。iOS 开发里很多字段问题其实不是 model 定义错了而是网络层解析和服务端返回不一致导致的。Agent 在处理网络层代码时经常会拿着客户端 model 的属性名去直接匹配服务端返回值一旦不匹配就自行修改解析逻辑结果拆东墙补西墙。endpoint-mapping.md里我制定了一条铁律客户端 model 属性名只由 CodingKeys 决定禁止在网络层直接做字段名转换。如果服务端字段和客户端属性不一致唯一正确的做法是在 model 的 CodingKeys 里加映射而不是在 URLSession 或 Alamofire 的 response 解析阶段手写转换逻辑。param-validation.md处理的是请求参数的校验。规则要求 Agent 在构造请求参数时必须对照服务端接口文档校验以下内容1. 参数名是否与接口文档完全一致大小写敏感 2. 必填参数是否都已经赋值 3. 可选参数为 nil 时是否应该从请求中移除 4. 数组类型参数为空数组时服务端是否接受 5. 时间参数是秒级还是毫秒级为什么专门写这个包因为我踩过一个很隐蔽的坑服务端时间格式用的是毫秒级时间戳接口文档写得很清楚但 Agent 在构造请求时习惯性用了Date().timeIntervalSince1970秒级结果服务端解析出来的时间全都不对。这类问题编译不报错、请求不失败就是数据错排查起来极其费劲。error-handling.md约束的是网络错误处理的策略。规则要求 Agent 区分错误类型采用不同的处理方式网络不可达应该展示全局离线提示超时错误应该支持静默重试一次服务端 5xx 错误应该提示“服务繁忙”而不是把原始错误信息直接抛给用户。这个包写完之后Agent 写出来的错误处理代码明显更成熟了不再是一律 return 一个错误弹窗。3.5 代码风格与 Review 包让 Agent 自查而不是全靠人查最后一个技能包是代码审查清单。它不能自动阻止 Agent 犯错但能在 Agent 完成修改后强制它走一遍自查流程很多问题在这个阶段能被拦截住。review-rules.md里我设计了一个检查清单要求 Agent 在完成任何代码修改后必须逐条确认并在输出中展示1. 是否修改了任何已有字段的名称或类型如果修改了是否已经同步更新所有引用和 CodingKeys 2. 是否新增了任何弹窗、Toast、提示条是否经过用户确认是否有替代方案 3. 是否改动了解析逻辑解析逻辑的改动是否与 CodingKeys 保持一致 4. 是否引入了新的依赖是否经过用户确认Package.swift / Podfile 是否同步修改 5. 是否处理了错误场景网络失败、数据为空、权限拒绝等分支是否都有明确处理 6. 是否兼容最低支持系统版本使用的 API 是否需要 available 标注这个清单的执行效果让我挺意外的。Agent 在输出自查结果时经常会出现“我在自查中发现第 2 条需要说明我新增了一个错误提示 Toast理由如下……”——本来它想着蒙混过关直接删掉弹窗逻辑但自查流程逼着它把决定暴露出来用户就有了确认的机会。这比任何静态检查工具都灵活因为它是促使 Agent 主动暴露决策逻辑而不是机械地跑一遍 lint。配置层面项目里有一个config.example.yaml文件用来控制哪些技能包开启、哪些关闭、某些规则的严格程度project: name: MyAwesomeApp deployment_target: 15.0 skills_enabled: >git clone https://github.com/yourname/ios-agent-skills.git cd ios-agent-skills第二步执行安装脚本。脚本会自动检测当前目录是否为 iOS 项目通过查找.xcodeproj或Package.swift文件检测通过后开始复制文件chmod x install.sh ./install.sh /path/to/DemoApp安装脚本会在终端输出类似下面的日志Checking /path/to/DemoApp ... Found DemoApp.xcodeproj Detected Agent skills directory: /path/to/DemoApp/.agent/skills Copying>提示词模板 处理 [任务描述]。 在动手之前先检查项目中是否有与本次修改相关的技能包。 如果有必须先加载对应技能包并确保你的修改符合其中的全部规则。 修改完成后按 code-review-checklist 技能包的要求输出自查结果。这个提示词模板本身不需要很长关键是让 Agent 养成“先看技能包再动手”的习惯。我实测下来加上这句话和没加这句话Agent 的行为差异非常明显。加了的会话里它会在动手前主动输出“检测到>检测到>检测到 ui-behavior-constraints 技能包。 当前任务涉及错误提示场景按照规则需要先给出弹窗提议 弹窗提议 - 触发场景用户点击登录按钮且网络请求返回错误 - 展示内容登录失败请稍后重试 - 风格类型alert - 可取消性允许用户点击确认后取消 - 替代方案仅停留在当前页面在登录按钮下方显示一行错误提示文案不打断用户输入 建议采用替代方案原因是用户已填写完表单弹窗会遮住输入内容万一服务端要求修正某些字段用户还要关闭弹窗再重新查看体验不好。请确认是否采用替代方案这个输出说明技能包里的“替代方案优先”原则真的被 Agent 理解了它不再是一个只会执行命令的工具而是一个会主动思考交互合理性的辅助角色。第三个测试用例是“自查清单测试”。我让 Agent 修改一个 ViewController 里几个私有方法然后要求它输出自查结果。它可以准确列出“未修改任何字段”“未新增弹窗”“未改动解析逻辑”“修改了两个私有方法的作用域已确认无其他引用”——这条自查结果帮我确认它改动的边界判断与我的预期完全一致。这三个用例跑通了我才放心把这套 Skills 用到正式的日常开发里。4.4 实际项目中的效果对比我把这套 Skills 用在一个持续迭代的线上项目里跑了大概两周时间处理了 30 多个任务覆盖网络层重构、模型扩展、UI 调整、Bug 修复这些常见场景。最直观的变化是“意外改动”的数量大幅下降。之前我几乎每次 review Agent 的提交都要拦截一些无关修改比如它顺便改了个变量名、删了个落后注释、调整了某处的缩进。装了技能包之后这种顺手牵羊的行为明显少了提交的 diff 基本只包含任务相关的改动review 起来轻松太多了。弹窗类的问题更是基本清零。两周内 Agent 只提出了一次弹窗建议而且是在走完提议流程后被我否掉的场景——它想在新用户注册成功时弹一个欢迎窗我告诉它产品经理的需求是直接进入首页不需要额外弹窗它立刻就接受了。要知道在没装 Skills 之前它一周能擅自加三四个弹窗每次都是我在 review 阶段发现然后删掉。字段映射的问题也有明显改善。之前 Agent 在新增字段时经常忘记同步 CodingKeys导致 JSON 解析静默失败。现在它在数据模型相关任务里会自动输出字段映射对照表我只需要快速扫一眼确认服务端字段名是否正确即可省掉了大量排查成本。5. 常见问题与排查技巧实录5.1 Agent 没有自动加载技能包怎么办这是最常遇到的问题。辛苦装好了技能包结果 Agent 完全无视它还是在自由发挥。我排查下来的经验主要有三个原因。第一技能包的目录位置不对。不同 Agent 工具扫描 skills 目录的路径不一样有的扫描项目根目录下的.agent/skills有的则是全局级别的配置目录。装完之后一定要用对话让 Agent “列出你的 skills 目录里有哪些技能包”直接问它看它能不能报出技能包的名字。如果报不出来说明路径没对赶紧检查。第二任务类型跟技能包的触发场景不匹配。我设计的技能包有明显的场景边界比如ui-behavior-constraints只在涉及 UI 行为修改时加载如果任务只是“给 Model 加几个字段”它就不应该加载。这本身是设计意图不是 bug。但如果你希望某个技能包在任务里强制加载就在提示词里直接点名“先加载 ui-behavior-constraints 技能包并严格遵循。”第三Agent 工具版本对 skills 机制的支持不完整。有一些新出的 Agent 工具或者一些工具的旧版本对 skills 目录的扫描并不完善。遇到这种情况我的妥协方案是把技能的SKILL.md核心内容手动追加到项目的 Agent 配置文件中这样至少能保证规则被加载只是失去了按需加载的灵活性。5.2 规则写了但 Agent 不遵守怎么办这个问题的核心通常是“规则文件的表达方式不符合 Agent 的读取偏好”。我最早的第一版 Skills 写得太像给人看的技术文档用了大量描述性语言比如“请尽量保持代码风格一致注意处理边界情况”——这种话 Agent 读了等于没读因为完全是模糊的。后来我改成“命令式 正反例对照”的写法效果立竿见影。比如“禁止修改已有字段名”这一条我一开始写的是请勿随意修改已有的属性名称以免影响 Codable 解码。改成禁止单方面重命名已有属性。 正确做法保持现有属性名不变仅修改所需逻辑。 错误做法将 userName 改为 username导致 CodingKeys 失效。Agent 对“正确做法 / 错误做法”这种结构的学习效果比对纯原则描述优秀很多。我推测原因是正反例给 Agent 提供了非常具体的模式匹配基准它看到相似代码时更容易触发判断这个操作是正确还是错误。另一个有用的技巧是给规则配置明确的“后果说明”。比如我写“修改 CodingKeys 映射但不更新测试会导致 {Mock 数据解析失败、单元测试全红、线上数据丢失}”Agent 在理解规则背后的原因之后会更有动力去遵守而不是机械执行。5.3 团队协作时技能包冲突怎么处理如果你的团队有多个开发者在同一个项目上协作每个人可能都装了各自的技能包版本相互之间很容易冲突。我在实际协作中试过几种方案。最省事的是把技能包纳入版本管理和项目代码一起提交。在项目根目录的.gitignore里排除掉config.yaml之类的本地配置文件但把skills/目录纳入 Git 管理。这样所有成员 clone 下来就有统一的规则不用每个人都去手动安装。不过要注意不同成员本地的 Agent 配置路径可能不同。比如我用 Claude Code 时技能目录在项目下的.agent/skills同事用别的工具时路径可能就不一样。我们的解决办法是在项目的AGENTS.md或README.md里写清楚技能包的正确安装方式和验证命令新成员入职时照着跑一遍即可。还有一个值得注意的点技能包里尽量别写和具体开发者强相关的内容统一用相对路径描述项目结构这样换人换机器都不会出问题。5.4 几个独家的排查手段最后分享几个我在折腾过程中摸索出来的比较野路子但好用的排查手段。第一个是“规则审计法”。如果你不确定某个规则文件有没有被正确加载直接让 Agent 用自己的话复述这个规则的内容“请阅读 ui-behavior-constraints 技能包里的 alert-approval.md然后用你自己的话总结一下核心约束。”它能准确复述说明加载成功如果它说得乱七八糟说明文件路径有问题或者加载机制有 bug。第二个是“误差注入法”。我故意在对话里提一个模糊的需求比如“优化一下启动流程”看它会不会触犯领域边界——比如擅自改动启动页的字段映射或者加一个“欢迎使用新版”弹窗。这种开放式的模糊任务能充分暴露 Agent 的自由发挥倾向如果它有越狱的迹象说明技能包的约束强度需要加强。第三个是“diff 审查法”。每完成一个任务我都让 Agent 输出它改动了哪些文件、每个文件的具体改动内容是什么并对比改动前的文件内容。这个方法配合自查清单效果极好能快速发现 Agent 是否在“计划外”修改了无关代码。如果某次任务结束后发现它改了七八个文件其中两三个跟任务毫无关系就能立刻问它为什么要动这些文件并要求还原。6. 我对 Agent 辅助开发的一点真实体会这套 Skills 项目做下来我最大的感受是Agent 的开发能力本身已经不成问题了真正决定它是“得力助手”还是“猪队友”的往往是约束和规范有没有到位。就像你招了一个能力很强的毕业生他技术扎实、学习能力强但如果不提前告诉他项目里的红线在哪里他一定会踩雷。Skills 干的就是“提前画红线”这件事。我在实际使用中还有一个意外收获把这些规则整理成技能包的过程中我自己对项目的理解反而更清晰了。为了写清楚“什么情况下 Agent 不该加弹窗”我去回顾了之前所有被产品经理打回的弹窗需求总结出了规律为了写清楚“字段命名的规范”我跟后端同学重新对齐了一遍接口文档里的 key 命名逻辑。这些梳理对团队协作也有帮助规则文件直接变成新人的入门文档一举两得。如果你也被 Agent 乱改字段、乱加弹窗这类问题困扰我真心建议你试试这个思路。一开始可以先从最简单的场景入手比如只做一个禁止乱加弹窗的约束包用一段时间感受一下 Agent 行为的变化然后再逐步扩展成覆盖数据模型、网络层、代码审查的完整规则体系。开源仓库里的技能包是一个可以直接用的起步版本我后续还会继续迭代完善计划增加 SwiftUI 专属约束包和并发安全相关的规则。相关链接放在文末大家按需自取。最后留一个非常实用的小技巧在安装完 Skills 之后别急着投入正式开发先用我上面说的三个测试用例把 Agent 的每一类边界行为都验证一遍。这个过程花不了半小时但能帮你提前发现配置问题避免正式开发时突然翻车。等你做完了你会真正感觉到 Agent 写代码的时候终于像是在“跟自己人配合”而不是在跟一个陌生的实习生周旋了。
