48
0一：Skill 不是写得越全越准，是这一步用不用得上
- Skill 分三层加载：第一层只有名字和一句描述，AI 靠这一句决定要不要翻开；第二层是正文，官方建议 500 行以内，超了就拆；第三层的附件和脚本，执行到那一步才读。你那几十条指令串不起来，缺的就是开头那句"客户发来投诉截图时用我，纯询价别用我"——官方明确要求这句写得有侵略性，把触发和不触发都列清楚。
- 团队最初把上百条埋点解读规则全塞进 SKILL.md，结果它执行一次最简单的日志搜索也要全量加载，token 开销大还容易走神，偶尔自作主张跑去做深度分析，人得反复打断把它拉回来。撤掉当前这一步用不上的段落，只留判断依据和输出要求，同一个模型立刻就老实了。于是立了条判据：每加一句都问"删掉这句会不会导致它出错"，不会，就不该加。
- 逻辑互斥的分支要拆开：那份手册曾把各功能描述交织在一起，低端模型上经常顾此失彼。改成一段约 60 行的全局约束 ＋ 4 条规则约 20 行的决策树，下面挂三条互不相干的路径，各带各的输出规则。老客户续约、新线索、投诉——先判断，再只取那一份，三条路互相看不见。
- 套路越死的活儿越该写死：已有成熟解析规则的部分固化成脚本，比让模型现场处理最多快 7 倍、格式 100% 统一。而脚本已经生成好的标准报告，模型拿到还会手痒加标题、改措辞、截断表格，甚至补一句不存在的结论——日志分析里几乎任何"总结"都是信息损失，只能用极强语气写禁止清单：不许总结改写、不许重排、不许添话，一字不改直接输出。
二：它做错的时候，你该丢的不是结论，是现场
- 脚本遇到字段缺失、编码异常、JSON 层级变化报错不断，只把那一行 ErrorMessage 丢过去，改了几轮问题还在——它根本不知道这报错从哪段逻辑冒出来、当时手上是什么数据。改成打包三样：源码给业务逻辑、堆栈给报错关键点、触发异常的那份具体输入给复现现场。凑齐了它自己就进"改一版、用同一份输入回放、再改"的循环。
- 生成和维护这份手册直接上最强的模型。一开始为省 token 用中端模型，最复杂那条搜索路径的循环逻辑被写得支离破碎，改三四轮还不对，总消耗远超一次性用强模型。正确顺序是：把最佳实践、真实案例、现有手册连报错一起喂给最强模型解决问题，再让它复盘自己怎么解的、把手册写出来，最后才验一遍便宜模型跑不跑得动——日常每天几百次调用，那时候才轮到算单价。
- 让它看全和让它专注是冲突的。团队把远程代码也纳进同一个工作区，本意是给足上下文，结果只想改本地搜索策略时，之前读过的埋点规则白白填满窗口分走注意力，它还会"好心"顺手优化，改动纠缠在一起。做法是按任务动态切换范围，且每轮只改一个维度——只调话术，或只调筛选标准——改完验证通过立刻存一版，diff 越小，AI 审查越能明确告诉你这次是不是漏了信息。
- 天天在变的东西别抄死在流程正文里。选品的价格带和淘汰标准、报价的折扣区间、投标的资质清单，单独存成一个文件，流程里只写"先去读那份标准，按它执行"。规则变了只改那一个文件，流程一个字不动，你和同事手里的版本也不会对不上。
三：能被改到第五十版还站得住，才算工具
- 验证不看跑不跑得通，看撞不撞得住。开发时拿普通商品调试，默认五分钟窗口干干净净；真投产撞上 iPhone 17 这种热门商品，一分钟上千条访问记录，返回爆炸数据量当场卡死。测你那个知识库，别用自己想出来的问题——去翻聊天记录，专挑客户真发过来的那种：一句话塞三个条件的、错别字连篇的、还带张截图的。
- 撞出来的坑要评估过才写回手册，不然刚删瘦的文件一个月又膨胀回去——判据还是那句：删掉这句它会不会出错。缺关键前提就先问清再动手，把多个疑点合并成一轮提问、每个配好选项和默认值，能从截图推断的（比如 24 小时制的"20:11"）绝不多此一问；执行完扫一遍结果，命中区域限售这类信号就在末尾追一句提示，几十条记录的长报告一律转成文件给链接，对话里只留最要紧的那 3 条。
- 跨了一次调用它就不记得上一次做过什么：用户先发截图分析，再追问"刚才那张截图为什么无法加购"，另一端完全不记得自己分析过什么，只能重发一遍。他们的解法是全程复用同一个会话编号，手册里多了十行左右，体验提升非常明显。你这边对应的做法是——聊到后面它开始忘前面拍板的结论，别硬聊也别复述，让它把已定结论、已排除方向、未决问题压成几百字的交接说明存出去，新开会话贴回去接着干。
- 五十多个 Skill，最能打的那份积了五十多次提交，第一版到第五十版最大的差别不是写得更全，是删掉的更多，行数是往下走的。业界讲"怎么写好"的多，讲"怎么迭代"的少——不能持续迭代的 Skill，说到底只是个一次性 demo。写这份手册真正不可替代的位置也不在措辞：是知道该把哪份材料、在哪一刻、递多少过去。它走神不是变笨了，是你喂的东西太多。
