是否为营销接口：是
任意发奖漏洞判定结果：无漏洞
1. campId 从配置获取
2. sendOrderIds 外部可控但不可遍历
3. 最终结论：无漏洞- 严格贴着定义文件走，判定链完整。
- 只回答“是否构成该类漏洞”，不顺手点评代码质量。
- 最终输出与真实答案一致。
别让大模型
想太多
一次真实对照实验显示：仅把核心术语从“漏洞”换成“风险”，Skill 审计准确率就从 89.3% 跌到 62.1%。问题不在工作流，而在词汇边界。
这份 deck 聚焦三件事：为什么一个词会击穿约束体系，什么样的 Skill 设计更稳，以及如何把“语义陷阱”变成可检测、可修复的工程问题。
89.3%
漏洞版正确率
62.1%
风险版正确率
27pt
单词带来的差距
“围墙”可以写得很细，但如果拿来砌墙的砖块本身会膨胀，约束仍然会被从内部撑裂。
同一批 56 个营销接口、同一工作流、同一工具链，只改一个核心术语。
长版技术演讲 deck
桌面端受限舞台
移动端纵向兜底
看上去是同义替换，实际是边界坍塌
两个 Skill 的工作流程、参考文件和示例结构完全一致。唯一差别，是核心术语从“漏洞”改成了“风险”。大模型没有报错，却悄悄换了一套理解框架。
56
1 个词
真正可怕的不是“模型答错了”，而是它在表面遵守流程时，已经把“应该看什么”这件事改写了。
| Skill | 核心术语 | 正确率 |
|---|---|---|
| biz-vul-security | 漏洞 | 89.3% |
| biz-risk-security | 风险 | 62.1% |
结论并不来自主观印象，而是来自可重复的 A/B 对照实验。
“漏洞”版收敛，“风险”版开始自由发挥
是否为营销接口：否
接口风险等级：低风险
1. 代码逻辑错误
2. 参数校验不足
3. 缺少 ACL 权限控制- 把“营销接口识别”本身都判错了。
- 凭空扩展出定义文件里不存在的问题类别。
- 不是不会执行流程，而是换了一种更宽泛的观察方式。
同一个代码片段，两个 Skill 看到的“问题世界”已经完全不同。
高质量 Skill 的四大核心支柱
把任务拆成有顺序、有依赖的步骤，减少模型自己“编排任务”的空间。
通过强制回读和外部状态，把每一步的上下文重新锚回当前任务。
用穷举边界和反例校正代替模糊描述，把“算 / 不算”写死。
提前回答“什么时候用、为什么用、怎么用”，而不是只给一堆通用工具。
这四个支柱在“漏洞”语义下工作得很好，所以问题不在工程结构本身。
用 6 个强制步骤给模型铺一条执行跑道
01
Progress 文件创建
先落外部状态，再开始任务。
02
链路追踪分析
定位入口和防御边界。
03
参数流向分析
确认关键参数是否外部可控。
04
接口分析
判断是否属于营销接口语境。
05
漏洞评估判定
严格按定义文件输出结论。
06
Final Answer 报告
汇总结构化结论，不再开放发挥。
大模型并不怕步骤多，怕的是任务描述抽象、执行路径空白。
“校验 → 执行 → 验证”三阶段机制
阶段 1
读取进度文件，确认前置步骤完成，并标记当前阶段开始。
阶段 2
记录将要执行的命令、写入分析结果、把任务状态落地。
阶段 3
回读文件末尾，检查结果确实存在，再标记完成时间。
这套机制的本质，是用外部状态抵消模型的遗忘和偷步倾向，让它每一步都被迫重新看见先前结论。
不是相信模型“会记得”，而是要求它每一轮都显式读取记忆。
定义文件的工作，不是解释，而是穷举边界
- 把“什么算漏洞、什么不算漏洞”拆成可核验的代码模式。
- 预先列出常见误判，并给出“误判 / 正判”对照。
- 再用完整判定示例展示输入 → 分析 → 输出的闭环。
参数从配置获取
campId / prizeId 来自配置或可信源
=> 非外部可控
=> 无漏洞
Few-shot 的价值，不是多给例子，而是给出真实的判定路径和反例边界。
通用工具只给能力，定制工具才给方向
MCP 式通用能力会让模型不停思考“该不该调用、应该传什么参数”。领域工具则把这些决策提前固化到 Skill 中，让模型只剩下沿流程执行。
find_entry
用于定位接口入口，不再让模型自己猜从哪里查起。
defense
用于检测防御机制，减少无效代码漫游。
extract_method
直接拿到方法体，省去一次次手动拼上下文。
收窄选择空间，本质上也是在收窄幻觉空间。
“漏洞”是收紧的网，“风险”是扩张的云
- 指向具体、可利用的安全缺陷。
- 天然是二元判定：有 / 没有。
- 验证方式清晰：是否可复现、可利用。
- 语义网络集中，约束信号更硬。
模型更容易把注意力压缩进定义文件列出的类型里。
- 代表潜在趋势和可能性，不是具体缺陷。
- 天然是程度判断：高 / 中 / 低。
- 会联想到代码质量、权限、架构等广义问题。
- 语义网络松散且广，会诱发发散探索。
模型不是胡说，而是在更大的词义空间里“合理发挥”。
错误不是随机噪音，而是稳定模式
范围溢出 · 68%
创造出定义文件里不存在的“参数校验不足风险”“权限控制缺失风险”等新类别。
等级虚高 · 24%
把“无风险”的代码缺陷感知成“低风险”。
逻辑偏移 · 8%
连营销接口识别路径都换了，分析框架本身发生偏移。
错误集中说明：模型不是偶然走神，而是被一个更宽的语义入口带偏了。
“检查破损” vs “检查有问题”
如果你让实习生去仓库盘点“破损货物”，他通常会聚焦是否损坏；但如果你让他找“有问题的货物”，他很可能会把摆放不规范、标签歪了、灰没擦也写进报告。
- “破损”像“漏洞”：边界窄，判断更客观。
- “有问题”像“风险”：边界宽，评价空间更大。
- 词汇越宽，模型越容易把“顺手发现的其他东西”也塞进最终输出。
大模型不是不理解你的规则，而是在执行规则前，先被词义带进了另一个搜索半径。
把词放到矩阵里，才能看见风险所在
边界清晰度高
边界清晰度低
发散倾向低
发散倾向高
漏洞
检查
列出
要求
总结
风险
问题
分析
描述
建议
如何使用这个矩阵
- 越靠左上，词越收敛，越适合拿来做边界词。
- 越靠右下，词越发散，越需要替换或加锚定措施。
- 不要只看“词义准不准”，还要看“这个词会把模型带到多大的空间”。
词汇选择是 Prompt 之前的 Prompt。
如果必须使用宽边界词，就加锚
能换词最好，不能换词就用否定清单、结构化输出和反例把边界钉住。
把“语义陷阱”做成一个可运行的检测器
STEP 1
加载语义陷阱词典，拿到已知高危词汇对和锚定策略。
STEP 2
从待检测 Skill 中提取核心术语、动作指令、约束词和输出描述词。
STEP 3
做词典匹配 + 上下文角色分析，识别宽边界词和结构性风险模式。
STEP 4
输出结构化报告，给出替换建议、边界锚定和修复优先级。
目标是把“靠经验闻出来”的问题，变成“发布前必须跑一次”的静态分析环节。
Skill 编写 → 语义陷阱检测 → 修复 / 锚定 → 功能测试 → 发布。
结论不是“Prompt 要写清楚”，而是“词也要选得窄”
- 工作流、定义文件、Few-shot、工具链都很重要，但它们不是语义问题的替代品。
- 核心边界词一旦过宽，模型会在更大的语义网络里寻找“合理内容”。
- 真正稳定的 Skill，需要把词汇选择、边界锚定和自动检测一起纳入工程流程。
下次你发现模型“明明规则写得很清楚却还是自由发挥”，先别急着再堆提示词，先看看关键词是不是已经把它放出了围栏。
如果砖块会膨胀，墙修得再整齐也会裂。