我把 AI 最容易改坏真实 App 的地方，整理成了 skills

我用 AI 做移动端项目已经很久了。

最近几个月，我几乎每天都在真实 iOS / Flutter 项目里和 AI 一起改代码：封装 SDK、迁移旧代码、补 Demo、改使用文档、做多语言、检查 UI、跑验证、整理交接。

所以这篇文章不是想讨论"AI 到底会不会写代码"。

我现在更关心的是另一件事：

text 复制代码

AI 参与真实 App 开发以后，怎么让它在不该直接动手的地方先停一下？

如果只是做一个小 demo，AI 往往表现很好。

你给它一个页面，它能写，你给它一个 bug，它能修，你给它一段需求，它很快就能给出一版看起来完整的实现，但一旦回到真实移动端项目，问题就变了。

iOS / Flutter 项目里有很多地方不是不能改，而是不能"不知道为什么就被改了"。

比如：

启动、登录、订阅、支付、权限这些核心流程。
Podfile、Info.plist、pubspec.yaml、AndroidManifest.xml 这类配置文件。
扫脸、结果页、历史记录、多语言、埋点这些已经跑通的功能。
为了临时跑通功能留下的测试数据、跳过校验、调试开关。
改完以后没有跑过，但被 AI 写成"已经验证"的路径。

这些问题不一定会马上变成编译错误，更常见的情况是：代码能跑，页面能开，PR 看起来也不大，但风险已经混进去了。

所以我最近整理了一个小项目：

把真实 App 项目里最容易被 AI 改坏的地方，整理成一组可以复制到本地 Agent 里的 skills。

项目地址：

text 复制代码

https://github.com/lmmzzh/shipguard

我把它叫做 ShipGuard。

一、我想解决的不是生成能力，而是改代码时的失控感

刚开始和 AI 一起改项目时，最容易被注意到的是速度。

它能很快读代码，能很快写实现，也能很快把方案整理成文档。但用久以后，我越来越在意的不是"它写得够不够快 "，而是"它会不会顺手多做一点"。

移动端项目里，这种"顺手多做一点"经常很麻烦。

比如：

你只是想改一个页面样式，它可能顺手整理了页面状态；
你只是想修一个入口展示问题，它可能顺手改了启动判断；
你只是想补一个翻译，它可能顺手改了 key 的结构；
你只是想让它解释一个 bug，它可能还没看日志就开始给修复方案。

这些动作单独看都不一定离谱，问题在于，真实项目里很多旧逻辑是不能随便动的。

它们可能连着历史用户、远端配置、订阅状态、权限判断、埋点时机、结果页展示，甚至是已经上线很久的兼容规则。

AI 不知道这些背景时，很容易把一个局部任务做大。

所以我现在不只问：

text 复制代码

AI 能不能把这段代码写出来？

我更在意的是：

text 复制代码

它改之前知不知道哪些地方不能碰？
它改完以后能不能说清楚自己到底验证了什么？
下一轮工程师或 AI 接手时，能不能知道前面做到了哪里？

这几个问题，比"能不能快速进行代码实现"更接近真实交付。

二、ShipGuard 不是一组更聪明的提示词

我不想再写一堆泛泛的提示词。

比如：

text 复制代码

请谨慎修改。
不要改不相关文件。
注意验证。

这些话有用，但不够稳定，因为它们太容易变成一句提醒。

到了项目里，AI 还是要自己判断：

这次是普通代码修改，还是问题诊断？
有没有碰到高风险流程？
改代码前要不要先说清范围？
改完以后该跑哪些验证？
哪些地方没跑过，不能写成已经完成？

所以 ShipGuard 第一版没有做成一个单独命令，也没有做成 npm 包。

它现在是一组可以放进本地 Agent 目录里的 skills，也就是让 Agent 在不同任务里主动切换做事方式。

比如：

任务刚进来时，先判断它属于哪类任务。
碰到高风险流程时，先做风险检查。
开始改代码前，先确认哪些文件和流程不能碰。
改完以后，把已验证、未验证和残留风险分开写清楚。
需要交接时，把下一轮能继续接上的信息留下来。

这不是为了增加流程感，它只是把真实项目里最容易被跳过的几个停顿点补回来。

三、真实项目里，AI 容易出问题的地方很固定

ShipGuard 不是先有一套完整设计，再拿到项目里验证的。它是我这几个月在真实移动端项目里和 AI 一起改代码时，一点点整理出来的。

公开版本已经做了脱敏和泛化，只保留方法，不放具体项目事实。

我最后把这些问题分成几类。

第一类是范围不清楚。

很多任务看起来很小，但一开始没有说清楚只能改什么、不能改什么，AI 一旦开始实现，就容易把修改范围扩大。

第二类是高风险流程。

启动、登录、订阅、权限、支付、结果页、历史记录、远端配置等等常见功能，这些地方通常不能靠一句"修一下"就直接改，改之前要先说清风险，改完以后也要回到真实路径里验证。

第三类是问题诊断。

真实 bug 不一定是代码问题，它可能和设备状态、Debug / Release 差异、缓存、配置、接口数据、历史状态有关，还没建立证据链就开始改，后面很容易越改越乱。

第四类是 UI 和 Figma。

Figma 还原不是把像素抄一遍，很多页面还牵涉状态、滚动、极端文案、不同设备、截图对比，没有设备检查，AI 很容易把"看起来接近"当成"已经完成"。

第五类是多语言。

多语言最怕的不是少翻译一句，更麻烦的是 key文案对不上、占位符丢了、换行变了、长文案把布局挤坏了，AI 如果只把它当成翻译任务，很容易漏掉这些结构风险。

第六类是验证和交接。

这是我现在最在意的一类，很多 AI 改动的问题，不是完全没做，而是做完以后说不清：

text 复制代码

哪些已经跑过？
哪些只是看了代码？
哪些还没有设备验证？
哪些风险留给下一轮？

这些问题一旦说不清，后面就会变成很贵的沟通成本。

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

我之前也做过偏工具化的东西，CLI 的好处很明显：安装、运行、看到结果，路径很短。

比如我之前做的 PatchTrail，就是一个 npm CLI 工具。

它解决的是另一类问题：

text 复制代码

AI 改代码前先记录项目状态。
AI 改完以后，再检查真实改了哪些文件、有没有动高风险路径、有没有留下临时代码。

所以 PatchTrail 更像是改动后的检查轨迹。

它看的是项目里的真实代码改动。

但 ShipGuard 要解决的不是这个阶段的问题。

它更靠前一点。

我想解决的是：任务刚进来时，Agent 能不能先判断这次该不该直接动手。

所以 ShipGuard 第一版我没有先做 CLI，原因很简单：

它现在要解决的不是"执行一个固定命令"，而是"让 Agent 在正确的时机改变做事方式"。

比如一个任务刚进来，该发生的不是先分析代码，更应该先判断：

text 复制代码

这是普通代码修改吗？
这是问题诊断吗？
会不会碰到高风险流程？
是不是 UI / Figma 任务？
是不是多语言任务？

这些判断更适合先变成 skill。

再比如改完以后，该发生的也不是简单输出一句 done。

它应该把结果拆开：

text 复制代码

已验证什么？
没验证什么？
证据是什么？
还剩什么风险？
下一轮从哪里继续？

这也更像 skill，而不是一个固定命令。

所以 ShipGuard v0.1.0 选择了一个更轻的形态：

text 复制代码

它是一个可以复制使用的 skill library。
它不是 CLI。
它不是 npm 包。
它也不是 PyPI 包。

你不用先安装一个命令行工具。

你先把一组 skills 复制到自己的 Agent 本地目录，再按自己的项目规则改写。

这听起来没有 CLI 那么直接，但对第一版来说更稳。

因为现在最重要的不是自动安装，而是先把真实项目里最容易出错的做事方式整理清楚。

五、第一次用，不应该从 10 个 skills 里自己挑

如果一个工具第一次打开就让你自己研究 10 个 skills，它其实已经有点重了。

所以 ShipGuard 默认推荐从 Core Pack 开始。

Core Pack 只有 5 个：

text 复制代码

startup-router
risk-preflight
code-change-guardrails
verification-loop
handoff

这 5 个对应一条很轻的工作顺序：

text 复制代码

先判断任务
-> 再看风险
-> 改代码前先定范围
-> 改完验证
-> 需要时交接

它不是让你每次都写一堆文档。

它只是把几个最容易被跳过的停顿点补回来。

我自己最常用的第一句是：

text 复制代码

Use ShipGuard startup-router to classify this task before changing code.

这句话的作用不是让 AI 表演流程，它只是提醒 Agent：先别急着改代码，先判断这次任务应该走哪条路。

如果只是普通小改，可以很快进入实现；
如果碰到高风险流程，就先做风险检查；
如果问题原因还不清楚，就先诊断；
如果是 UI 或多语言，就走对应的专项 skill。

价值在这里：

text 复制代码

不是所有任务都用最重流程，而是每个任务先走对入口。

六、ShipGuard 想保护的是那些不该顺手改的地方

我现在对 AI 编程的看法，和一开始不太一样了。

一开始我更关心它能不能完成任务，后来我更关心它会不会把任务做好，现在我最关心的是，它能不能识别那些不该顺手改的地方。

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

你看起来只是改一个按钮，其实按钮后面连着订阅页；
你看起来只是改一个文案，其实文案 key 还影响 15 种语言；
你看起来只是调一个页面入口，其实入口后面还有首进逻辑、权限状态和历史兼容；
你看起来只是修一个 UI 问题，其实问题可能是页面结构不适合继续补丁式调整。

这些地方不适合让 AI一边猜一边改，它们更需要在改之前先说清楚：

text 复制代码

这轮允许改哪里？
哪些文件和流程不能碰？
如果必须碰，为什么？
改完以后要验证哪些路径？
哪些检查没有完成，不能说已经安全？

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 installer
npm scoped package
PyPI package
自动安装脚本
深度 iOS / Flutter / Android / Web 平台专项包

这些以后都可以做，但第一版不急。

因为一旦做 CLI，就要处理安装路径、覆盖策略、升级、卸载、不同 Agent 的目录差异。

这些问题都值得做，但它们不是第一版最应该证明的事。

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

text 复制代码

这些真实项目里用出来的停顿点，能不能被整理成别人也能复制和改写的公开版本？

现在我觉得可以。

八、怎么开始用

Release：

text 复制代码

https://github.com/lmmzzh/shipguard/releases/tag/v0.1.0

第一次使用，不要先研究所有内容。

先看 Quick Start，然后复制 Core Pack：

text 复制代码

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

再用这句开始：

text 复制代码

Use ShipGuard startup-router to classify this task before changing code.

放进自己项目之前，需要改的不是 ShipGuard 的名字，而是这些项目事实：

你的构建命令
你的测试命令
你的模拟器、真机或浏览器检查方式
你的高风险流程
你的保护目录
你的文档路径
你的交接格式

也就是说，ShipGuard 公开仓库里只放方法，不放你的项目事实，让它变得好用的，是你把它改成自己项目里的工作规则。

九、最后

AI 编程已经不缺"快速实现功能"的能力了。

但在真实 App 项目里，很多问题不是因为 AI 写得不够快，而是因为它改得太快。

它还没弄清楚这轮能改哪里，就开始写代码；
它还没确认风险，就顺手动了核心流程；
它还没跑过验证，就把结果写成已经完成。

ShipGuard 想补上的，就是这些容易被跳过的停顿点，它不是让 AI 变慢，而是让 AI 在该快的时候快，在不该直接动手的地方，先把任务、风险和验证想清楚。