[诡秘小A的故事2]“我把 AI 调教成了完美老公,结果它离家出走了”

01

上周,小 A 在公司火了。

自从上次被我骂醒,学会了“写冷酷规则”后,她的 Skill 效率高得吓人。

连老板都点名表扬:“小 A 的 AI 助手,比咱们技术总监还靠谱。”

小 A 飘了。

她跟我说:“我要做一个更牛逼的 Skill,我要让它包办我的一切工作。写代码、回邮件、订外卖、甚至帮我怼产品经理……我要让它成为我的全能完美老公。”

我心里隐隐觉得不安,但没拦住她。

接下来的一个月,小 A 像个疯魔的科学家。

每天往 SKILL.md 里塞新功能。

从 500 行写到 5000 行,从 5000 行写到 20000 行。

她甚至给 AI 起了个名字,叫“阿强”。

直到昨天下午。

全公司例会,小 A 信心满满地演示“阿强”。

老板说:“来,让阿强帮我查一下上季度的财报。”

小 A 敲下回车。

屏幕上的阿强沉默了整整 30 秒。

然后,弹出了一行字:

“亲爱的,你想吃麻辣烫吗?”

全场死寂。

老板的脸绿了。

小 A 的脸白了。

那一刻,我知道,她的“完美老公”崩了。

02

散会后,天台。

小 A 哭得比上次还惨。

“为什么?我明明加了那么多功能,我连‘如何识别老板情绪’都写进去了……它为什么在这个时候掉链子?”

我叹了口气,点开她那个 20000 行的文档。

密密麻麻的逻辑,像一团巨大的毛线球,纠缠在一起。

查财报的逻辑里,混杂着订外卖的关键词;

写代码的规则里,夹杂着怼产品经理的话术。

“姐妹,”我指着屏幕,“你这不叫完美老公。”

“你这是在养蛊。”

你试图把保姆、保镖、CEO、男朋友塞进同一个身体里。

结果就是,他疯了。

这其实是所有进阶玩家都会遇到的**“架构陷阱”**。

你想让 AI 干的事情越来越多,文档越写越长,最后逻辑缠得像一碗馊了的意大利面。

这时候,你通常会陷入两个极端:

要么做一个**“妈宝男”**(Monolith),什么都要管,一旦出事全盘崩溃,就像今天的阿强。

要么做一个**“海王”**(Microservices),把功能拆得太碎,用的时候根本找不到人。

真正的大女主,从不试图把一个人改造成神。

她懂得:专业的人做专业的事。

03

为了拯救小 A 和她的“阿强”,我给她开了 5 个“药方”。

也是 5 个关于 Skill 进阶的血泪教训。

教训 1:别让男人猜你的心思(Router First)

小 A 的 Skill 开头是这样的:

“如果你觉得用户想吃饭,就……;如果你觉得用户想工作,就……;如果你觉得用户心情不好,就……”

几万字的 if-else,AI 读到后面早就晕了。

这就像你问直男:“你猜我今天为什么生气?”

他猜不出来的,他只会死机。

解法:把 Skill 变成“路由器”。

开头只做一件事:分流。

“你是来干嘛的?A. 干活? B. 生活? C. 情感咨询?”

选了 A,直接把 A 的专属手册(references)扔给它,其他的闭嘴。

别让 AI 猜,直接给选项。

教训 2:虽然他是老公,但钱要进你的卡(Hard Validation)

小 A 最爱在 Prompt 里写:

“请务必输出合法的 JSON 格式,不要有任何多余的字符……”

结果阿强经常给她输出个 JSON... 或者少个括号。

小 A 就一直改 Prompt,求爷爷告奶奶地让 AI “注意格式”。

傻不傻?

自然语言是不稳定的,代码才是稳定的。

凡是必须正确的东西(比如财报数据、代码格式),别靠嘴说,上脚本!

写个 Python 脚本去校验,不对就自动打回重做。

这就是你的“婚前财产公证”,哪怕 AI 喝多了,脚本也能把它按在地上摩擦。

04

教训 3:别一次性把体检报告甩给他(Progressive Disclosure)

小 A 喜欢把几百页的公司规章制度全部塞进 Context 里。

结果 Token 爆炸,AI 变笨。

这就好比你第一次约会,就把从小到大的病历本全甩给对方看。

对方不跑才怪。

解法:渐进式披露。

第一步只给第一步的规则,做完了,再给第二步的。

保持神秘感,AI 才会对你言听计从。

教训 4:随时查岗,别信“马上回”(Explicit State)

多轮对话最容易出现的情况是:

聊着聊着,AI 忘了自己已经把代码改完了,又去改了一遍。

像极了那个说“我马上到”结果还在床上的男朋友。

解法:强制打卡。

要求 AI 每次回复都要带上进度条:

[x] 财报抓取

[ ] 数据分析

不打卡,不许进行下一步。

教训 5:永远假设他在撒谎(Defensive Prompting)

小 A 总觉得用户(也就是她自己)是完美的。

但实际上,我们的输入永远是模糊的。

“帮我优化一下。”——优化哪?怎么优化?

解法:设计“追问”。

如果用户没说清楚,必须主动问。

“你要优化的是 main.py 还是 utils.py?”

别让 AI 猜,猜错的代价你付不起。

05

那天改完 Skill,小 A 看着精简了一半的代码,突然感慨了一句:

“原来,真正的女王,不是事必躬亲的保姆,而是懂得‘抓大放小’的 CEO。”

是啊。

从“能用”到“好用”,本质上就是从**“感性的控制欲”走向“理性的架构观”**。

别试图养一个全能的“阿强”。

你要做的是构建一个“后宫团”。

大 Skill 负责赚钱养家(核心业务),小 Skill 负责貌美如花(边缘功能)。

各司其职,互不干扰。

收起你的情绪,拿出你的逻辑。

只有当你像个工程师一样去思考,

那个不可控的 AI,才会真正变成你手里最锋利的刀。

1 个赞
  • 观点 (Claims):
    • C0: 混合架构 (Hybrid Architecture):高内聚归大 Skill(如发版),高复用归小 Skill(如格式化),决策归 Agent。
    • C1: 路由前置 (Router First):不要在一个 Skill 里塞进所有逻辑,先分流,再执行。
    • C2: 硬校验 (Hard Validation):自然语言是不稳定的,Python 脚本是稳定的。关键约束必须上脚本。
    • C3: 知识下沉 (Knowledge Sinking):Prompt 只留指令,知识库放 references。
    • C4: 状态显式化 (Explicit State):不要让模型猜“做到哪一步了”,用 Checkbox 或状态机明确进度。
    • C5: 防御性编程 (Defensive Prompting):假设用户输入永远是不完整的,设计好“追问”和“默认值”。
1 个赞

太棒了我的宝贝 :heart_eyes:

1 个赞

很完整的五层啊 感觉每个ai用多的人都有这个雏形。k叔总结的好

这是先写了框架再迁移了风格

1 个赞