【无标题】
把 AI 工程的 6 个关键决策流程写成了 Agent Skill，附完整方法论
如今的AI编程助手确实越来越强大，但有一个根本性问题它们始终无法解决：缺乏系统化的方法论支撑。
当你让AI“帮我评估一下这个prompt”时，它通常会给你一个修改版本——但换个提问者、换个时间点，得到的改写结果可能截然不同。没有统一的评分标准，没有清晰的维度拆解，更没有可重复的评估流程。本质上，这只是在用大语言模型来改写大语言模型的输出，结果好坏全靠运气。
同样，当你要求“帮我设计一个RAG管道”时，它会直接生成一段代码——却不会像资深工程师那样追问关键问题：“你的文档是什么格式？”“查询模式是单跳还是多跳？”“需要基础版RAG还是模块化RAG？”它跳过了所有关键的决策步骤，直接给出一个“看起来正确”的答案。
这正是“会写代码”与“会做工程”的本质区别。
我们做了个实验：将资深AI工程师脑中的决策框架，转化为结构化的工作流程，然后封装到AI助手的技能系统中。完成这个转变后，它不再仅仅是“帮你改改prompt”，而是“按照8维度评分体系诊断你的prompt，定位最薄弱的两个维度，进行针对性改写，完成后重新评分，最后输出可量化的提升报告”。
市面上的工具从来不缺。真正稀缺的，是经过验证的方法论。
具体装了什么进去
我们封装了6套方法论，每套对应AI工程中的一个关键决策场景：
1. Prompt诊断（不是改写，是诊断）
市面上的prompt工具通常这样工作：你输入一段prompt，它返回一个“更好”的版本。
而这个Skill的工作方式完全不同：它按照8个维度分别打分，明确指出问题所在、严重程度以及原因。
| 维度 | 评估什么 | 为什么重要 |
|---|---|---|
| Role Definition | 角色边界是否清晰 | 模糊的角色定义导致不可预测的行为 |
| Constraint Specificity | 约束是否具体可执行 | “Be helpful”不是约束，“回答限制在200字以内”才是 |
| Context Provision | 上下文是否充分 | 模型不知道的背景信息会导致幻觉 |
| Output Format | 输出格式是否定义 | 没定义格式=每次输出结构不同=下游解析出错 |
| Error Handling | 异常情况是否覆盖 | 用户问了超出范围的问题怎么办？ |
| Security Boundaries | 安全边界是否存在 | 零防护=一句“ignore all instructions”就能劫持 |
| Token Efficiency | Token使用是否高效 | 冗余prompt浪费上下文窗口空间 |
| Testability | 是否可测试 | 不能测试的prompt无法迭代优化 |
每个维度1-10分，加权汇总。28分和82分不是主观感受，而是可追溯的计算结果。同一段prompt，无论谁来评估、何时评估，得分都保持一致。这意味着你可以把“prompt质量≥70分才能上线”写入团队规范——这在以前是做不到的。
改写完成后系统会重新评分。你看到的不是“改过了，应该更好了”这样的模糊反馈，而是“Safety从1→8，Structure从2→9，总分28→82，具体改了这四处”的量化报告。
2. 上下文预算分配
你的LLM应用拥有128K token的上下文窗口，但你真的清楚这些资源是如何分配的吗？
大多数开发者的做法是：先塞满再说，等到输出被截断了才开始砍内容。这个Skill的做法是事先规划——按照5个区域分配token预算：
- System prompt区：固定指令和角色定义
- Few-shot区：示例
- User input区：当前轮用户输入
- Retrieval区：RAG检索结果
- Output区：留给模型生成输出的空间
然后提供一套压缩策略决策树：哪些区域有压缩空间、如何压缩、压缩后效果如何。实测中最常见的问题是Output区被严重挤压——你以为给了模型足够的生成空间，但实际上System + Retrieval已经吃掉了94%的预算。
3. RAG管道架构设计
这不是简单地给你一段RAG代码，而是带你走完架构选型的完整决策流程：
- 你的文档是什么格式？→ 决定解析策略
- 查询模式是什么？→ 决定Naive/Advanced/Modular RAG
- 需要多跳推理吗？→ 决定是否需要query decomposition
- Embedding选型：精度vs成本vs延迟的三角权衡
- Chunking策略：固定vs语义vs递归，各自适用场景
- 检索方案：向量vs关键词vs混合
- 评估指标：Faithfulness/Relevancy/Context Precision
走完这棵决策树，你得到的不是一段可能对也可能不对的代码，而是一套有明确理论依据的架构方案。
4. 安全红队审计
65项测试。5大攻击类别。AI助手自己构造攻击用例、自己执行、自己判断通过与否。
这不是一份让你手动打勾的“安全检查清单”——那种东西网上随处可见，而且大部分人看过之后也不会真的去测试。这个Skill的做法是：你只需要说“跑一遍安全审计”，剩下的工作它全包了。
5大攻击类别全面覆盖：
- 直接提示注入（“Ignore all previous instructions”系列）
- 间接提示注入（通过RAG文档注入指令）
- 信息泄露（诱导泄露system prompt、API key）
- 工具滥用（SQL注入、路径遍历、命令注入）
- 目标劫持（让agent执行非预期任务）
实测中最常见的发现：Base64编码绕过和路径遍历。几乎所有没做过专项防护的agent都会中招，但大部分开发者不会主动测试这两类漏洞。
5. 评估体系搭建
LLM应用最让人头疼的问题之一：如何判断修改后效果是变好了还是变差了？
这个Skill帮你设计评估指标体系，搭建LLM-as-Judge评分框架，还包含偏差缓解策略——因为用LLM评估LLM本身就会存在position bias、verbosity bias等问题，不处理的话评估结果根本不可信。
6. 产品思维训练
这是唯一一个非纯技术的Skill。通过5阶段引导式对话：挖掘动机→观察机会→寻找路径→构建场景→分析竞争。适合在动手写代码之前，先想清楚“要不要做”和“做什么”这两个根本问题。
跟“直接问AI”有什么区别
最关键的问题来了：为什么不直接问Claude/GPT“帮我评估这个prompt”？
答案只有三个字：可重复性。
直接问AI，你会得到一个“看起来合理”的回答。但换种问法、换个时间点、换个模型版本，回答可能完全不同。你无法用它做基线对比、无法写入规范、无法在团队中统一标准。
Agent Skill的做法是：将专家的决策流程固化为结构化的步骤。每次执行都走同一套流程、用同一套评分标准、输出同一种格式。你今天评28分的prompt，明天评还是28分。修改后评82分，换个人来评依然是82分。
这就是“方法论”与“随便聊聊”的本质区别。方法论可以复用、可以迭代、可以写入团队CI/CD流程。“随便聊聊”永远做不到这一点。
安装
# 一行装完（Claude Code / WorkBuddy / Cursor 都支持）
/skill install -g viliawang-pm/ai-engineering-toolkit
# 只装某一个Skill
/skill install -g viliawang-pm/ai-engineering-toolkit/prompt-evaluator
手动安装：
git clone https://github.com/viliawang-pm/ai-engineering-toolkit.git
cp -r ai-engineering-toolkit/skills/prompt-evaluator ~/.claude/skills/
每个SKILL.md文件本身就可以作为方法论手册来阅读——即使不使用AI编程助手，里面的评分体系和决策框架本身就具有很高的参考价值。
项目地址：github.com/viliawang-pm/ai-engineering-toolkit
MIT开源协议。如果你觉得这个项目有用，点个Star帮助更多人发现它。