探索AI辅助移动端开发的过程中，我属于较早深入实践并持续积累经验的那一批。过去几个月里，我几乎每天都会在真实的iOS与Flutter项目中与AI协作调整代码：涵盖SDK封装、旧代码迁移、Demo补全、使用文档优化、多语言适配、界面检查、验证执行以及工作交接整理。

因此，本文无意纠缠“AI究竟能否编写代码”这类老生常谈的话题。

如今更关注的核心问题，其实是另一层面：

当AI真正深度参与真实App开发时，如何引导它在需要谨慎的地方先停顿思考，而非直接开始执行修改？

如果仅局限于开发小型Demo，AI的表现确实令人瞩目。给它一个页面，它能快速生成；给它一个缺陷，它能尝试修复；给它一段需求，它能迅速拼凑出一版看起来相当完整的实现方案。

然而，一旦回到真实的移动端项目环境中，情况则截然不同。

iOS与Flutter项目中存在大量区域，并非不能改动，而是不能在不经意间被“顺手调整”。例如：

• 影响用户体验的启动、认证、订阅、支付及权限等核心流程；
• Podfile、Info.plist、pubspec.yaml、AndroidManifest.xml等关键配置文件；
• 面部识别、结果展示页、历史记录、多语言支持、埋点追踪等早已稳定运行的功能模块；
• 为临时验证功能而留下的测试数据、绕过校验的调试开关及测试入口；
• 修改后未经实际运行验证，却被AI标注为“已验证”的执行路径。

这些问题未必会立即引发编译失败，更常见的状况是：代码依然可以编译，页面可以正常显示，代码审查（PR）看起来改动也不大，但潜在的风险已经悄无声息地混入其中。

因此，近期我们整理了一个名为 ShipGuard 的小项目。

一、核心目标不是提升生成能力，而是控制代码修改时的失序感

刚开始与AI协作修改项目时，最直观的感受往往是速度的提升。

它能迅速通读代码，快速编写实现方案，甚至能快速将方案整理成文档。但经过长时间使用后会发现，真正令人担忧的并非“它写得不快”，而是“它是否在不经意间多做了某些事”。

在移动端项目里，这种“顺手多做一些”往往带来很多麻烦。

• 你只是希望调整一个页面的样式，它可能顺手重构了页面状态管理；
• 你只是修复一个入口展示问题，它可能顺手更改了启动判断逻辑；
• 你只是补充一条翻译文本，它可能顺手重构了键值对的结构；
• 你只是让它分析一个Bug的原因，它可能还没查看日志，就直接给出了修复方案。

单独来看，这些调整未必都不合理。但问题在于，真实项目中存在大量历史逻辑不能随意改动——它们关联着历史用户数据、远程配置、订阅状态、权限判断、埋点时机、结果页展示，甚至包括已在线很长时间的兼容规则。当AI不了解这些背景信息时，很容易将一个局部任务扩展为全局性修改。

所以现在问得最多的已经不是“AI能不能编写出这段代码”，而是：

在修改之前，它是否清楚哪些地方绝对不能触犯？
完成修改后，它能否清晰说明自己实际验证了哪些内容？
当后续的工程师或AI接手任务时，能否明确知道之前已执行到哪一步？

这些问题的价值远比“代码生成速度”更接近真实交付的本质。

二、ShipGuard 并非一组更聪明的提示词

我们不想再编写一堆泛泛的提示指令，例如“请谨慎修改。不要改动不相关文件。注意验证流程。”这类语句虽然有一定作用，但非常不稳定——它们本质上只是一种口头提醒。

真正进入项目时，AI依然需要自己判断：这次是常规代码修改，还是问题诊断？是否涉及高风险流程？修改代码前是否需要先明确范围？完成修改后需要执行哪些验证？哪些区域尚未验证，能否标记为“已完成”？

因此，ShipGuard的第一版没有做成一个独立的命令行工具，也没有发布为npm包。

它现在以一组可直接放入本地Agent目录的skills形式存在——核心思路是让AI能在不同任务中主动切换工作方式。例如：

• 任务刚开始时，先判断它属于哪一分类型；
• 当遇到高风险流程时，先执行风险评估；
• 在开始修改代码前，先明确哪些文件和流程必须保持不动；
• 修改完成后，将已验证、未验证以及残留风险分门别类地写清楚；
• 需要交接时，将下一轮可以继续使用的信息完整保留下来。

这么做不是为了增加流程复杂度，而是将真实项目中最容易被跳过的那些关键停顿点，一一重新拾起。

三、真实项目中，AI最常出错的地方其实很固定

ShipGuard并非先有一套完整设计再用项目去验证。它是这几个月在真实移动端项目中与AI协作修改代码时，一点一点积累总结出来的。公开版本已经做了脱敏和泛化，只保留了方法论，不涉及具体项目事实。

最后将问题归纳为几个类别：

第一类：范围不明确。许多任务看起来很小，但一开始没有清晰界定“只能改什么、不能改什么”，AI一旦开始执行，就很容易将修改范围无限扩大。

第二类：高风险流程。启动、登录、订阅、权限、支付、结果页、历史记录、远程配置……这些区域不是简单一句“修一下”就能直接动手的。修改前必须说清风险，修改后也必须回到真实路径进行验证。

第三类：问题诊断。真实的Bug未必是代码本身的问题，它可能和设备状态、Debug/Release版本差异、缓存、配置、接口数据、历史状态都有关。没有建立完整的证据链就开始修改，后面越改越乱几乎是必然的。

第四类：UI与Figma还原。Figma还原不只是照抄像素，许多页面还涉及状态切换、滚动、极端文案、不同设备适配以及截图对比。如果没有设备检查，AI很容易将“看起来相似”当作“已完成”。

第五类：多语言处理。多语言最怕的不是少翻译一句，更麻烦的是键值对与文案对不上、占位符丢失、换行格式改变、长文案导致布局样式崩坏。AI如果只将其当作翻译任务，很容易忽视这些结构风险。

第六类：验证与交接。这是目前最关注的一类。许多AI改动产生的问题，并非完全没做，而是做完后无法说清楚——哪些已经实际运行验证过？哪些只是看了代码？哪些还没有设备验证？哪些风险留给了下一轮？一旦说不清，后面就会产生高昂的沟通成本。

四、为什么第一版做成skills，而不是CLI工具

之前也尝试过偏工具化的方案。CLI的好处很明显，安装、运行、看到结果，路径非常清晰。比如之前做的 PatchTrail 就是一个npm CLI工具。

它解决的问题在另一个层面：AI修改代码前先记录项目状态，修改完成后检查真正改动了哪些文件、有没有触碰高风险路径、有没有留下临时代码。因此 PatchTrail 更像一份改动后的检查轨迹，它关注的是项目里真实的代码变更。

但 ShipGuard 要解决的并非这个阶段的问题——它更靠前一些。

真正想解决的问题是：当任务刚进入时，AI能否先判断一下，这个任务是否适合直接动手？

因此ShipGuard第一版没有先做CLI，原因很简单：因为它现在要解决的，不是“执行一个固定的命令”，而是“让AI在正确的时机切换工作方式”。

比如任务刚进入时，不应该直接分析代码，而是先判断：这是常规代码修改？还是问题诊断？会不会碰到高风险流程？是不是UI/Figma任务？是不是多语言任务？这些判断更适合先变成一个skill。

再比如修改完成后，不应该简单输出一句“done”，而是要把结果拆开：已验证了什么？未验证了什么？证据是什么？还剩哪些风险？下一轮从哪里继续？这同样更像一个skill，而不是一个固定命令。

所以ShipGuard v0.1.0选择了一个更轻量的形态：它是一个可以复制使用的 skill library。它既不是CLI，也不是npm包，更不是PyPI包。

你不需要先安装一个命令行工具，只需要把这组skills复制到自己的Agent本地目录，再根据项目规则进行改写。这听起来没有CLI那么直接，但对第一版来说更稳妥——因为现阶段最重要的不是自动安装，而是先把真实项目中最容易出错的做事方式整理清楚。

五、初次使用，不应从10个skills里自行挑选

一个工具如果在首次使用时就需要你自己研究10个skills，那它的复杂度已经有点高了。

因此ShipGuard默认推荐从Core Pack开始，只包含5个核心skill：startup-router、risk-preflight、code-change-guardrails、verification-loop、handoff。

这5个skill对应一条很轻量的工作流程：先判断任务类型 → 再评估风险 → 修改代码前先界定范围 → 修改完成后验证 → 需要时进行交接。

它并不是要求你每次都写一堆文档，它只是把几个最容易被跳过的关键停顿点给补回来。

最常用的第一条指令是：Use ShipGuard startup-router to classify this task before changing code. 这句话的作用并不是让AI去表演流程，它只是提醒AI：先别急着修改代码，先判断一下这次任务应该走哪条路线。

• 如果只是常规小改动，可以快速进入实现阶段；
• 如果遇到高风险流程，就先进行风险检查；
• 如果问题原因还不明确，就先进行诊断分析；
• 如果是UI或多语言任务，就走对应的专项skill。

价值就在这里：并不是所有任务都使用最重的流程，而是每个任务先走对正确的入口。

六、ShipGuard想守护的，是那些不该被顺手改动的地方

现在对AI辅助编程的认识，和一开始完全不同了。

一开始更关注它能否完成任务；后来更关注它能否把任务做好；现在最关注的，是它能否识别出哪些地方不该被顺手改动。

真实App项目里，很多风险都隐藏在这些地方：

• 表面上只是改一个按钮，但这个按钮后面可能连接着订阅页面；
• 表面上只是改一个文案，但这个文案键可能影响到15种语言的适配；
• 表面上只是调整一个页面入口，但这个入口后面还涉及首次启动逻辑、权限状态和历史兼容；
• 表面上只是修复一个UI问题，但问题可能是页面结构已经不适合继续打补丁。

这些地方不适合让AI一边猜测一边修改。它们更需要先把话说明白：这一轮允许改动哪些地方？哪些文件和流程绝对不能动？如果必须触碰，理由是什么？修改完成后需要验证哪些路径？哪些检查项没有完成，不能声称已安全？

ShipGuard并非替代程序员做决策，而是让AI在动手之前，先将范围、风险和验证项说清楚。

七、v0.1.0先保持克制

此次发布的ShipGuard v0.1.0版本非常克制。它包含了Core Pack、Diagnosis Pack、UI Pack、i18n Pack、Full Pack manifest、10个公开skills、8个输出模板、Quick Start、Codex手动使用说明、隐私与脱敏规则，以及已脱敏的示例。

同时它明确不包含：CLI安装程序、npm 作用域包、PyPI 包、自动安装脚本、深度的iOS/Flutter/Android/Web平台专项包。

这些内容以后都可以逐步添加，但第一版不急于做。因为一旦涉及CLI，就要处理安装路径、覆盖策略、升级、卸载、不同Agent的目录差异等问题……这些都值得做，但它们不是第一版最需要验证的事。

第一版更应该先回答一个更基础的问题：

这些从真实项目中打磨出来的关键停顿点，能否被整理成别人也能复制和改写的公开版本？

现在这个问题的答案，是肯定的。

八、如何开始使用

Release 地址：https://github.com/lmmzzh/shipguard/releases/tag/v0.1.0

首次使用，不要先研究所有内容。先阅读Quick Start，然后复制Core Pack中的这5个文件：

• skills/core/startup-router
• skills/delivery/risk-preflight
• skills/delivery/code-change-guardrails
• skills/delivery/verification-loop
• skills/core/handoff

然后用这句话开始：Use ShipGuard startup-router to classify this task before changing code.

在将其放入自己项目中时，真正需要改动的并非ShipGuard这个名称，而是这些项目具体事实：你的构建命令、测试命令、模拟器/真机或浏览器检查方式、高风险流程、需要保护的文件目录、文档路径以及交接格式。

ShipGuard公开仓库中只提供方法论，不包含你的项目具体事实。让它真正变得好用的，是你根据自己的项目规则对它进行个性化的改造。

九、最后

AI辅助编程领域已经不缺“快速实现功能”的能力，这是不争的事实。

但在真实App项目中，绝大多数问题并非AI写得不够快，而是它改得太快——它还没弄清楚这一轮能改动哪些地方，就开始编写代码；它还没确认风险，就顺手更改了核心流程；它还没实际运行验证，就把结果写成了“已完成”。

ShipGuard希望补上的，正是这些容易被跳过的关键停顿点。

它不是要让AI变慢，而是让AI在该快速执行时保持高效，在不该直接动手的地方，先把任务性质、风险状态和验证事项想清楚。

这才是如今真实交付中最稀缺的能力。