俗话说：付出不一定有回报，但要回报一定得付出。

在AI时代，似乎付出和回报的比例不是那么稳定了，然而其实这个规则仍在继续。

有人拿AI当女朋友发泄情感，有人拿AI当百科，有人拿AI写小X文赚钱……同样是Token的消费，如果你指望从AI的工作中得到更好的回报，依然是要花大量的时间和金钱与AI进行磨合，锻炼自己的表达和指示能力，让AI为你做出更好的产出。

本文将主要讲我在使用AI期间体会到的一些经验，比如如何更有效地指导AI编码，如何避免AI产生的各种问题，以及怎样把你获取的信息教给AI让它也学会。

本文将同时包含关于：**AI辅助小白打包技能的更新**

最基础的小白打包技术我已经在 [《Vibe打金计划（1）： 小白学打包应用》](https://lazycat.cloud/playground/guideline/753) 写过了，而随着逐渐的学习和深入，我和AI都学到了新的知识，所以将在这里顺便补充一下。

如果你只是移植，可能完全用不到这些打包技巧，如果你也是像我打算原创应用，或许能在这里找到多少有点用的启发。

---

让AI做你没想到的事

这条是关于使用**upstreams**写启动脚本。

首先你会在官方文档看到在exec中路由放置启动脚本的方法如：

```yaml

routes:

- ...

- /api/=exec://3000,./lzcapp/pkg/content/backend/run.sh

```

这样懒猫就会在运行run.sh(文件名自定)后访问指定端口。

比如node.js的后台，在run.sh中的npm run start之类的服务和监听任务启动完成之前，向指定端口3000的访问会反复被拒绝再重试，而前端会一直显示赛伯猫头图标和“{应用名}启动中”的界面。

直到成功启动了监听服务，正式的界面才会显示出来。

除了这种简写的路由，其实还有一个语义上更明确的方式，就是写在upstreams中。

至于为什么一定要用upstreams而不用简单版exec路由，除了语义看上去更直观，还有我在之前一篇文章中已经提到过的，因为用Windows打包的话无法执行类似run.sh的启动脚本，所以目前只能把启动命令写到lzc-manifest.yml里application.upstreams下的backend_launch_command中。

我个人感觉还有一个好处是不用搞一个专门的run.sh在里面，虽然维护时在后台代码中多一个文件虽然也没啥不好，但毕竟是复杂一点点，感觉多少会破坏项目的独立性。

我把这个方式告知AI后，AI为我写了这样的启动脚本，

```yaml

backend_launch_command: |

echo "=== 懒猫文件选择器后端启动 ==="

cd /lzcapp/pkg/content/backend

echo "当前工作目录: $(pwd)"

echo "=== 环境变量检查 ==="

echo "LAZYCAT_BOX_NAME: $LAZYCAT_BOX_NAME"

echo "LAZYCAT_BOX_DOMAIN: $LAZYCAT_BOX_DOMAIN"

echo "LAZYCAT_APP_DOMAIN: $LAZYCAT_APP_DOMAIN"

echo "LAZYCAT_APP_ID: $LAZYCAT_APP_ID"

echo "=== 安装系统依赖 ==="

apk update

apk add nodejs npm curl

echo "=== 启动应用 ==="

node server.js

```

还有一个更复杂的版本：

```yaml

backend_launch_command: |

echo "= 懒猫文件选择器后端启动 =" cd /lzcapp/pkg/content/backend echo "当前工作目录: $(pwd)"

echo "= 环境变量验证 ="

echo "LAZYCAT_BOX_NAME: ${LAZYCAT_BOX_NAME}"

echo "LAZYCAT_BOX_DOMAIN: ${LAZYCAT_BOX_DOMAIN}"

echo "LAZYCAT_APP_DOMAIN: ${LAZYCAT_APP_DOMAIN}"

echo "LAZYCAT_APP_ID: ${LAZYCAT_APP_ID}"

echo "= 网络连接测试 ="

netstat -tlnp | grep :3000 || echo "端口3000未被占用"

echo "= 安装依赖 ="

apk update && apk add nodejs npm curl

# npm install --production

echo "= 启动应用 ="

node server.js &

SERVER_PID=$!

echo "= 等待服务启动 ="

sleep 5

echo "= 本地连接测试 ="

curl -f http://127.0.0.1:3000/health || echo "本地健康检查失败"

echo "= 保持服务运行 ="

wait $SERVER_PID

```

说实话，我之前写的也就是安装和运行那两三句，从来没想过在这里可以直接写后台调试的脚本，直接判断启动的进程有没有问题。

而告知了AI这里可以运行脚本之后，它立即就应用这个入口写了调试逻辑，这是我真没想到的。

---

不要因为问题小就不同步给AI

因为/lzcapp/pkg/content是只读的，所以我曾经有很久卡在安装依赖上，尤其是依赖包挺大的时候，总是想着初始化的时候再装方便点，折腾半天以后才发现行不通。

虽然这只是小白的我犯的一个很傻的错误，不是什么大事，但是要注意的是：

AI一样理解不了！

所以我在之前让AI打包时，它给我的方案总是在启动脚本里加npm install，每次都要手动删除。这本来我也不觉得有什么问题，可是次数多了毕竟是麻烦。

所以我在系统提示语中加了一句：

由于懒猫的安全设置，/lzcapp/pkg/content是只读的，所以只能在build过程中安装依赖，请将安装的脚本写在lzc-build.yml中！

这之后大约有70%的机率它能帮我写好了（记忆力总是有限）。

```

buildscript: cd ./app/backend && npm install

```

(注意buildscript只支持单行文本，而且如果在windows下打包不能用.sh文件，而是要写成.bat)

---

你不会的AI也不一定会

另一个“小白坑”绊了我相当久，就是注意工作目录和路由地址。简写的时候可能注意不到，后台的工作目录和路由如果写错，当然经常会出现问题。

我曾经半个晚上纠结在AI给我的文件执行时总是找不到路由，除了首页搞什么都是404。导致我一度迁怒于AI认为是它太不靠谱了，直到把让它输出各种调试信息，再把调试信息喂回给AI，它才帮我发现问题！

所以一些特别的知识点，尤其懒猫这样自研的系统里的一些机制，如果不提示给AI，它可不会主动提醒你。

虽然大神们不会在这些小问题上裁坑，可是永远不要以为小白+AI=大神。AI只是在基于你能够提供的信息之上把代码写出来，很多隐藏的知识点如果你没有提供，它只会凭猜测给你乱写，所以“AI不靠谱”的印象也就随之建立起来了，其实呢？不靠谱的很可能是你自己。

```

upstreams:

- location: /api/

working_dir: /lzcapp/pkg/content/backend/

backend: http://127.0.0.1:3000/api/

```

这是后来写成功的API路由，我搞清楚了以后再没出过纠结在路由上的问题。

---

你会了不代表AI会了

我犯过的其他一些小错误，包括AI犯下的一些错误，可能没法或不适合举例来说。

但总之是比如AI在哪里搞错了一点（这是常事），但在我来看我是知道问题出在哪的，然后问题不大，就手动改了……这雷也就埋下了。

记性不好的AI会反复出现同样的错误，有时改下一个模块时会重新出错，有时改好这里那里又出错，有时在最后整理的时候会再次出错，你除了反复强调和抽卡之外几乎做不了什么别的。

于是我得到的一条经验是，每过几轮对话，就要确认一下之前的功能是否没有问题，有问题的地方要挂起，然后让强调让AI整理代码，争取只改出错的地方，其他的地方“不允许乱动”。

甚至有的时候要从git回滚到某个状态，然后从相应的对话节点重新提问，同时废掉搞错的分支。

这种情况下，我们的老朋友Refly就很适合干这种工作。

Refly的分支式交流很适合回到之前的某个对话点，再从那个点延伸之前的对话历史，在新的支线里解决问题。

---

疑AI不用，用AI不可不疑

如果你只是浅用AI，可能根本不太在意它的可靠性，试一试，好用就用，不好用就骂，这是人之常情。

但是如果要Vibe打金，做不到可靠是不行的。这种时候最重要的办法是，不要舍不得你的Tokens，玩命刷吧。

我后来养成一个习惯，每到一个关键点，比如哪些功能实现了，哪些Bug解决了，就用git提交一下，做个标记，比如“XXX功能已实现，整理代码前的备份”。

这一习惯在一定程度上避免了AI偶尔犯病胡说八道的灾难性后果。

还有一点就是：

一定要输出文档！

比如上一篇Minidb的文档

比如更早打包的文档

每次让AI汇总文档，不光是为我自己的学习，也为了以后让AI可以更好的参考既有基础去做新的工作。

因为每次AI对问题的理解不同，输出的稳定性不同，会犯的错也不同，有一个整理好的文档是非常有帮助的。

---

LLM大模型的本质是基于语言的“预测”行为，而预测这件事情，无论是找神婆算命还是算股票升级彩票代码，最关键的就是信息的输入。

有人说设计这个行业将不存在了，有人说艺术已经死了，有人说码农的职业也快完蛋了，也有人说产品经理终究会被AI替代。或许没错吧，但所有这些职业在我看来都将进化成“给AI喂食”这同一结果。

既然未来可能无法避免，为何不早些训练自己的喂食技能呢？