标签 Prompt Engineering 下的文章

从Prompt工程到Skill工程：Agent Skills开放标准彻底改变了AI协作方式

作者: 纯情
时间: 2026-02-05
分类:
评论

一、为什么 Agent Skill 突然火了？

你是不是也有过这样的崩溃时刻？

每次让 Claude 写代码，都要重复粘贴 请使用我们的代码规范：驼峰命名、2空格缩进、必须写单元测试 ——像极了每天入职新公司；
好不容易调教好的 Prompt 换个项目就完全失效，之前的调教经验归零；
团队里每个人给 AI 的指令不一样，导致输出的内容一会儿像资深架构师，一会儿像刚毕业的新手。

这些问题的根源，其实是 AI 的 专业能力无法沉淀。直到 2025 年 10 月 Anthropic 推出 Agent Skill（又名 Claude Code Skill）正是为解决这些问题而生。这不仅是 Claude 的新功能，更是一个 开放的跨平台标准，目前已被 OpenAI、Cursor、Trae 等主流工具跟进支持。

本文将带你从 是什么 到 怎么用在实际工作中，彻底掌握这个比 Prompt 更高级、比 MCP 更易用的 AI 编程神器。

二、到底什么是 Agent Skill？

用最通俗的比喻：Agent Skill 是 AI 的 入职手册 + 工具箱。

想象你招了一位天才实习生 Claude 他智商极高但不懂你们公司的业务。传统的做法是每次布置任务都口头交代一遍 Prompt 而 Agent Skill 则是给他一本完整的标准作业程序 SOP：

📋 入职手册（SKILL.md）：包含岗位描述、工作流程、注意事项
🧰 工具箱（Scripts）：处理特定任务的脚本和代码
📚 参考资料（References）：行业规范、模板素材、API文档

技术本质：Agent Skill 是一个标准化的文件夹结构，核心必须包含 SKILL.md 文件（YAML元数据 + Markdown说明），可选包含脚本、模板等资源文件。

my-skill/            # 技能包根目录
├── SKILL.md         # 📄 核心文件：元数据 + 工作流指令（必须）
├── scripts/         # 🔧 可选：自动化脚本（Python/Bash）
├── references/      # 📖 可选：专业文档、API手册、FAQ
└── assets/          # 🎨 可选：模板、示例、静态资源

当 AI 检测到相关任务时，会自动翻开对应的手册，严格按照既定流程执行，无需你每次都重复交代。

三、Skill工作原理

Skill 最精妙的设计，是它的 渐进式加载机制 —— 就像你查字典，先看目录，再翻对应章节，最后查附录，不会一上来就把整本书塞进脑子里。

3.1. 三层加载：用最少的 Token 做最多的事

加载层级	内容类型	加载时机	作用
L1	元数据（名片）	Agent 启动时自动加载	让AI知道“有什么技能可用”
L2	说明文档（正文）	匹配用户需求时加载	教AI“具体怎么做”
L3	资源文件（脚本 / 模板）	执行中按需加载	提供“工具/素材支持”

3.2. 四步执行流程

🎯 意图匹配：AI 扫描所有 Skill 的元数据，找到最匹配当前任务的技能
📖 读取指南：加载对应 SKILL.md，掌握执行步骤、检查点、输出规范
🔧 按需执行：调用 scripts/ 中的脚本，查询 references/ 中的资料
✅ 反馈结果：按模板输出成果，或询问缺失信息

四、现有技术的对比

4.1. Agent Skill vs Prompt

维度	普通 Prompt	Agent Skill
性质	临时指令，用完即走	标准化流程，永久复用
加载方式	每次全量输入	按需渐进加载
稳定性	依赖模型"记忆"，易漂移	固化检查点，强制执行
管理	分散在聊天记录里	文件化、版本可控
共享	复制粘贴，易丢失格式	整包分享，开箱即用

一句话总结：Prompt 是 口头交代，Skills 是书面 SOP + 工具箱。

4.2. Agent Skill vs 多 Agent 架构

维度	多 Agent 架构	Agent Skill
复杂度	重量级，需要架构设计	轻量级，单个文件夹即可
适用场景	复杂并行任务（如研究+写作+审核同时进行）	单领域深度任务（如专业代码审查）
资源消耗	高，需调度多个 Agent 实例	低，单 Agent 内能力切换
启动成本	需要搭建 Agent 框架	零成本，复制文件夹即可
关系	体系级解决方案	单元级能力模块，可被多 Agent 调用

4.3. Agent Skill vs MCP

维度	MCP	Agent Skill
定位	连接协议：AI 与外部系统的"USB 接口"	执行标准：AI 做事的"操作手册"
解决的问题	能不能连（访问数据库、API、文件系统）	怎么做（流程、规范、最佳实践）
技术形态	需要运行 MCP Server（TypeScript/Python）	静态文件夹（Markdown + 脚本）
加载时机	启动时建立连接	按需渐进加载
关系	互补：MCP 提供“工具”	Skills 提供“使用指南”

MCP 让 AI 能连上数据库，Skill 教 AI 怎么按你们公司的规范查数据、生成报表、处理异常。两者配合，AI 才能真正成为"懂行的专家"。

五、创建你的第一个 Agent Skill

下面用 会议纪要整理助手 为例，从零创建一个 Skill

场景：开会录音转文字后，需要整理成结构化会议纪要。不同会议类型（周会/项目复盘/客户沟通）需要不同的整理模板。

5.1. 创建 Skill 文件夹结构

新建一个名为 meeting-minutes 的文件夹，总体的文件结构如下：

/meeting-minutes/
├── SKILL.md                    # L1：技能元数据，L2：内容
├── references/                 # L3：按会议类型按需加载
│   ├── weekly-rule.md          # 周会模板
│   ├── retro-rule.md           # 复盘模板
│   └── client-rule.md          # 客户沟通模板

5.2. SKILL.md（核心文件）

5.2.1. 元数据

在 SKILL.md 文件最开头以上下两个 --- 作为元数据标识

---
name: meeting-minutes
description: 办公室通用会议纪要整理助手，支持周会/项目复盘会/客户沟通会三类场景，自动识别会议类型，按需加载对应会议规则，智能提取关键信息，输出结构化纪要。
---

5.2.2. SKILL内容

5.3. 编写模块化配置references

通过文件分离，AI每次只读取当前任务所需的规则，避免 Context 污染

5.4. 测试你的 Skill（以 Trae 为例）

Trae 作为国内的 AI IDE 已原生支持 Agent Skills

官网：https://www.trae.cn/
下载并安装 TRAE IDE

5.4.1. 导入Skill

创建一个文件夹，例如 my_skills
使用 TRAE IDE 打开这个文件夹
将 meeting-minutes 文件夹复制到 my_skills/.trae/skills/ 目录下

5.4.2. 输入提示词

需要切换为 SOLO 模式，然后在对话框输入以下提示词：

帮我生成周会会议纪要

原始文本：
小明：用户模块我搞完了，已经提测。
小红：接口文档我还没弄，我负责写，周五前给出来。
张三：测试环境那个问题搞不定，需要运维老陈帮忙看看。
李四：下周我打算开始订单模块，周三前出个技术方案看看。
王五：数据库设计谁review一下？
小明：我来吧，不过得明天才有空。

5.4.3. 执行Skill

5.4.4. 最终输出以下内容

六、本文Skill下载地址

本文案例 会议纪要整理助手 Skill 的下载地址如下：

Gitee地址：

https://gitee.com/zlt2000/my-agent-skill/tree/master/meeting-minutes

Github地址：

https://github.com/zlt2000/my-agent-skill/tree/master/meeting-minutes

在实际使用过程中本文 Skill 还可以进行以下迭代优化：
在 references 里扩展更多的 会议类型 模板；
在 script 文件夹写 Python 脚本，实现输出内容 导出word文档 或者 同步给飞书。

七、总结

Agent Skills 的正式发布，标志着 AI 协作从 提示词工程 正式迈入 技能工程 的全新范式。它将人类专家的经验、标准化流程与行业最佳实践，封装成 AI 可理解、可执行、可复用的数字资产。

核心价值优势：

降本增效： 通过渐进式披露、按需加载机制，大幅减少 Token 消耗，同时让 AI 聚焦核心任务，推理效率与执行稳定性同步提升；
跨平台互通： 作为开放标准，实现 “一次构建、多端复用”，Skill 可无缝适配 Claude、Cursor、Trae、Copilot 等主流平台，打破工具壁垒；
Skill 市场： 构建起类似 VS Code 插件市场的 Skill 生态，官方与社区共同打造技能商店，让专业能力可分享、可迭代、可规模化应用。

本文由mdnice多平台发布

智能体来了从 0 到 1：如何判断一个问题是否真的需要智能体

作者: 纯情
时间: 2026-02-02
分类:
评论

在生成式 AI 的工程实践中，智能体（AI Agent）正被频繁提及，但一个被反复验证的结论是：并非所有问题都适合被智能体化。在真实业务环境中，盲目引入智能体，往往带来更高的系统复杂度、不可控的执行路径，以及不成比例的算力与成本消耗。

因此，在“能不能做”之前，更重要的是回答：这个问题是否“必须”由智能体来解决？

一、什么样的问题，才属于“智能体级问题”

从工程角度看，智能体并不是“更聪明的模型”，而是一种具备目标驱动、自主规划、工具调用与反馈修正能力的执行范式。

判断是否需要智能体，本质上是在判断一个问题是否同时具备以下两点：

环境动态性：执行过程中，外部信息持续变化
路径非确定性：任务步骤无法在执行前被完全穷举

只要其中一项不成立，智能体往往不是最优解。

二、三步判断法：是否真的需要智能体

1️⃣ 决策链路是否可被固化

核心判断：

任务能否被拆解为固定 SOP，且路径在执行前完全可预期？

需要智能体
- 执行路径依赖中间结果
- 不同中间状态会触发完全不同的下一步
- 示例：企业尽调、复杂调研、跨领域分析
不需要智能体
- 输入 → 处理 → 输出为确定链路
- 示例：翻译、格式转换、规则校验

2️⃣ 是否需要动态选择工具

核心判断：

是否需要根据执行状态，在多个异构工具间做实时决策？

需要智能体
- 工具调用顺序不固定
- 是否调用、调用哪个工具，取决于中间数据
- 示例：数据分析 + 脚本计算 + 内容生成的组合任务
不需要智能体
- 单工具或单接口即可完成
- 工具调用路径固定

3️⃣ 是否存在闭环反馈与自我修正

这是区分“高级 Chatbot”与智能体的分水岭。

需要智能体
- 执行 → 失败 → 反思 → 重试
- 示例：代码生成并自动运行，基于错误日志持续修正
不需要智能体
- 一次性生成即可
- 或由人工完成最终纠错

三、行业实践中的“智能体准入信号”

在真实业务中，以下特征往往意味着传统自动化已接近极限：

目标模糊：只给出意图，而非步骤
长程任务：跨多个时间节点，需要持续状态维护
强实时依赖：必须不断引入新数据调整决策

在大量行业落地中，智能体来了并不是因为“模型更强”，而是因为问题形态发生了变化。

四、成本与可靠性的现实约束

从 ROI 视角，智能体方案天然存在代价：

可靠性：存在非确定性与幻觉风险
响应时延：多轮推理与工具调用带来秒级延迟
计算成本：Token 消耗不可预测，存在无效尝试

因此，“能用”与“该用”必须严格区分。

五、智能体使用决策矩阵（工程视角）

低复杂 / 高频 / 固定路径 → 传统代码自动化
高复杂 / 低频 / 创意为主 → Prompt Engineering + 人工
中高复杂 / 高动态 / 多工具协作 → 智能体（AI Agent）的核心适用区
高风险 / 零容错场景 → Human-in-the-loop，智能体仅做辅助规划

结论

是否引入智能体，并不取决于模型能力，而取决于问题是否必须具备：

自主拆解目标
根据环境反馈修正行为

如果答案是否定的，智能体只会放大复杂度，而不是效率。

飞猪 AI 测试新范式：维护降 70%、漏测减半、死循环归零

作者: 纯情
时间: 2026-02-02
分类:
评论

一、背景与愿景

以飞猪为例，生活服务类应用的 C 端的业务质量保障，往往面临业务快速迭代、技术架构复杂，多端场景覆盖难等多重挑战：

业务层面：受旅行行业“七节两促”特性的影响，在高频营销活动驱动下，往往伴随着较为快速的发布节奏；如何在快节奏中构建稳定的 C 端质量保障体系，与安全生产能力成为关键问题。
技术层面：C 端系统采用 Native、Flutter、Weex、DX、H5 等多技术栈混合架构；同时，测试回归需覆盖飞猪 App、手淘飞猪 Tab，及淘、支、微、红等多平台小程序入口，这导致测试回归复杂度指数级上升；此外，功能回归与用户体验提升需协同产研推进，进一步加剧了发布小窗口期下的质量保障难度。

UI 自动化作为 C 端质量保障的切口之一，而 AI 能够在现有场景下，为自动化赋予新的机遇，解决业界 UI 自动化的普遍挑战与共性问题：

用例维护成本高：业务快速变更导致失效率持续攀升，人工投入占比过大；
断言有效性不足：多端入口交互逻辑差异使覆盖不全，问题漏检风险存在；
多端兼容性问题突出：多端差异和逻辑定制，易引发测试盲区，易触发线上故障；

针对这些痛点，我们计划通过 AI 技术，结合并优化现有自动化测试体系：降低用例腐化率以减少人工成本，提升断言精准度以增强问题发现能力，从而在保障质量的同时提效。

图 1：飞猪多端 - 流量入口示意图

二、挑战

在“AI + X”的落地实践中，应用的技术演进大多遵循一条较为清晰的技术路径：从基础提示工程（Prompt Engineering）起步，到检索增强生成（RAG）、记忆体（Mem）、智能体技能（Agent Skills）和多智能体系统（Multi-agent Systems / Sub-agents），最终监督微调（SFT）、GPO/GRPO 等模型层的策略优化方法。

然而当时，我们在技术调研时发现，AI 自动化领域在当时深入借鉴的参考标杆偏少。在开源技术论坛中的技术分享，大多数文章仍聚焦于 0-1 阶段的试用与调研，缺乏对成熟技术路径的规模化应用验证。同时，外部的开源范例（如：阿里 Mobile-agent、微软 playwright-mcp、字节 midscene.js）也都是更聚焦模型 / 框架层面的基础能力建设，而缺少整体的能力串联、使用效果、演进路线上的实践范式。

如何将 “凭借 AI 可以快速入门的能用” 变成 “可支持月均 10 万 + 构建，稳定、快速运行的好用、易用” 是我们在这个技术演进路线上的最大挑战。

三、策略与思路

3.1、做好评测体系的先行建设，用数据指引应用迭代效果

核心原则：在 AI 自动化开发启动阶段，即需要同步建立与目标对齐的效果评测体系，将效果验证从“事后补救”前置为“设计输入”，确保技术演进始终服务于质量保障目标，避免因缺乏量化依据导致的无效迭代。

行业验证与内部实践依据：

Gartner AI 的研究报告指出，73% 的 AI+X 项目因评测体系缺失而无法规模化落地，表现为技术优化与业务效果脱节。
AI 自动化的前期探索中，常见的技术挑战，往往会遇到的典型问题：
提示工程（PE）优化后：执行效果异常，AI 幻觉问题频发，导致 PE 紧急回滚；
RAG 知识库迭代后，关键业务数据召回率显著下降；
模型切换后：本地调试结果与线上实际效果存在偏差，导致整体效果质量下滑，case 失败率增高。

实施要点：

我们从应用 workflow Benchmark 评测集建设、“渐进式消融评测机制”：基座模型 → Prompt → RAG → Agent 分阶段验证效果等方式作为评测体系的基准，每次技术调整（提示工程优化、知识库更新、模型切换）均需通过真实业务数据验证端到端效果，结合自动化测试数据与人工路径验证，确保评测结果反映真实用户体验。

价值体现：先行评测体系为 AI+X 实践提供客观决策依据，有效规避“技术优化但业务效果下降”的风险。为实现从“能用”到“可靠规模化”的关键跨越提供了数据支撑。

3.2、通过工作流设计，避免模型流程死循环（break cycle），提升故障恢复与自检能力

核心原则：在 AI 工作流设计中嵌入防死循环机制与故障恢复路径，确保系统在异常情况下能主动退出无效循环、回退至安全状态，而非陷入无限尝试。聚焦业务连续性保障，避免因局部故障导致整体流程失效。

问题依据与内部实践痛点：

行业共性问题：多智能体系统普遍存在流程死循环风险（如 Cursor 等工具中模型反复执行相同操作），在 AI 自动化场景中尤为突出。例如，当用户未填写必选 SKU 时，系统通常触发 toast 提示，但 AI 在截图 / 操作过程中可能无法捕获此类信息，导致模型陷入“尝试 - 失败 - 重试”的无限循环。

动态死循环检测机制：
基于 History 和 Memory 设计算法，实时分析操作序列相似度（如连续 3 次相同点击指令，及相似参数返回，即触发预警）；
设定阈值规则：当操作重复率≥60% 或单节点耗时超时，自动判定进入死循环。

分层恢复路径设计：
一级自检：轻量级模型（如 Qwen3-VL-7B）快速扫描历史操作，通过 ReAct 逻辑判断根本原因（例：识别“未捕获 toast”后触发跳过指令）；
二级升级：对复杂循环（如多端交互差异），临时调用高参数模型（qwen3-vl-235b-a22b-thinking）进行深度推理，结合 RAG 补充行业知识库（如“下单页 SKU 选择死循环通用处理方案”）检测到连续 N 次无效点击，workflow 自动调用 RAG 获取“必填项缺失”处理方案；；
安全回退：强制回退至最近稳定检查点（如“度假搜索 Listing 页”），避免全流程重启。

价值体现：工作流设计的本质是赋予 AI 系统“自省能力”——通过防死循环机制与分层恢复策略，将故障转化为可自动修复的常规操作，使技术演进真正服务于业务稳定性目标。

3.3、通过 RAG、记忆体与子智能体补充业务垂类知识，保障高 UV 页面路径的精准覆盖

核心原则：将业务垂类知识深度嵌入 AI 工作流，确保模型理解真实用户行为路径与行业术语逻辑，使测试覆盖严格对齐核心业务流目标，避免因知识缺失导致的路径偏差与漏检风险。

问题依据与内部实践痛点：

用户路径覆盖失准：模型对业务高频路径的理解存在偏差。例如，当指令为“订北京中关村附近，500 元预算，下个月 1 号大床房”时，实际用户 90% 通过“酒店金刚”或“猪搜”入口操作，但自动化测试常误判至其他资源位（如活动页），导致核心 UV 页面链路覆盖准确率不足，无法有效验证真实用户高频场景。
行业术语理解缺失：模型对垂类术语（如“交通 OD”指交通出行数据、“OTA 页面”指在线旅游平台）存在歧义，引发测试用例生成逻辑错误。例如，在航班测试中，“OD”被误识别为“订单”，导致关键流程验证失效。

实施策略：

RAG 业务知识库定制：
构建飞猪专属知识库，整合用户行为热力图（如酒店金刚点击路径）、行业术语词典（如“OD=Origin-Destination”），在 Prompt 生成前动态注入上下文。
例如，当检测到“订酒店”指令，且无其他特殊要求时，RAG 自动匹配“酒店金刚”作为首选入口，确保测试路径与真实用户行为一致。
记忆体（Mem）动态优化：
设计短期记忆模块，实时记录用户历史操作特征（如连续 3 次从“搜索模块”进入酒店列表），在决策时应该优先调用高频路径逻辑。
针对大促营销活动期，记忆体自动识别新增入口（如“双 11 特惠”标签），动态调整测试优先级。
子智能体（sub-Agent）分工协同：
路由 Agent：专责解析指令并匹配高频用户路径（如识别“订酒店”自动路由至酒店金刚）；
术语 Agent：实时校正行业黑话（如将“交通 OD”映射为交通数据模块），确保测试逻辑无歧义；
验证 Agent：在关键节点（如支付前）交叉校验路径是否覆盖核心 UV 页面，触发偏差预警。

价值体现：业务垂类知识是 AI 自动化测试的“导航仪”——通过 RAG、记忆体与子智能体的协同设计，将抽象指令转化为精准的业务路径验证，确保技术服务于核心用户场景的质量保障目标。

3.4、持续跟进前沿技术，动态演进应用能力，优化整体链路效果

核心原则：将技术演进，视为应用体系的有机组成部分，通过持续跟踪 AI 能力边界拓展与生态创新，实现测试链路与业务复杂度的动态适配，避免技术滞后成为效果瓶颈。

问题依据与内部实践痛点：

AI 技术的演化迭代速度日新月异，在 AI 自动化的基座模型下，我们从最初 gpt3.5 只能写文字、到 gpt4 可以多模态传图片，到 qwen-vl-max-latest 能够在点击、滑动时，精准给到像素级别的操作的 pixel point，都表明了技术能力的演进速度，已经远远超越我们去思考如何 fix issue 的迭代速度了。

通过建立与 AI 技术发展同频的升级机制，技术底座持续吸收 AI 的开源演化成果，并高效整合开源生态创新，使测试体系始终具备精准匹配业务迭代的适应性。

3.5、拓展 AI 泛化检查能力，加强视觉智能感知与断言，降低漏测概率

核心原则：突破操作意图识别的局限，将 AI 能力延伸至对视觉界面的动态理解与泛化校验，使测试体系从“执行动作”转向“结果验证”，确保系统能自主感知 UI 状态变化并判断业务逻辑一致性。

问题依据与内部实践痛点：现有测试过度依赖操作指令解析与“编码形式的断言”，难以应对多端 UI 差异场景下的隐性问题。例如，小程序中优惠券弹窗样式，可能只断言了弹出是否弹出，或者弹窗文案是否正常展示，但是如果弹窗局部出现了空坑，或者渲染异常，通过 “编码形式的传统断言” 是无法及时感知与相应的，如此就产生了漏测的可能。

而 AI 本身的图片解析与研判能力，就可以很好的处理这些问题，即可以判断单张图片上的泛化异常问题，也可以在多张图片的链路上，去分析判断一致性等相关问题。又或者结合实事、工单、可诉等相关外部数据，给出非逻辑 BUG 的风险提醒。

价值体现：AI 泛化检查是质量保障的“视觉神经”——让测试能力从机械执行转向智能感知，确保技术演进始终服务于用户体验的核心目标。

四、效果展示

从几个橱窗场景，进行 AI 智能化效果展示。

4.1、对于异常弹窗的静默处理

4.2、对于异形元素（无文字）的像素级坐标感知

4.3、对于连续逻辑的动态自检与判断能力

4.4 对于循环操作的短期记忆

4.5 对于死循环场景的脱困能力

4.6 对于截图的泛化检查能

五、思考总结

AI 技术的深度引入，有效解决了 C 端 UI 自动化质量保障体系普遍存在的通用问题，推动测试能力实现较大的提升：

用例维护成本显著降低通过 AI 语义化改造，系统能够动态理解业务变更逻辑（如营销活动入口调整），自动适配用例，大幅减少因业务快速迭代导致的人工维护投入，使团队精力从重复性调整转向测试策略优化。
测试覆盖深度切实提升泛化检查能力突破了传统编码断言的局限，使验证从操作指令延伸至结果状态。系统可自主识别多端 UI 差异中的隐性问题（如弹窗渲染异常、元素空坑等），有效弥补了人工难以覆盖的视觉类风险盲区。
多端兼容性问题系统性改善基于 RAG、记忆体与子智能体的协同设计，AI 深度融入业务垂类逻辑（如高频用户路径、行业术语校正），确保测试流严格对齐真实用户行为，显著降低了因端侧差异引发的漏检风险。

本质价值：AI 不是简单替代人工，而是将测试工程师从机械执行中解放，使其聚焦于质量策略设计与业务风险预判。当系统能自主完成弹窗处理、像素级操作及死循环脱困时，质量保障真正实现了从“执行工具”到“智能伙伴”的转变——技术价值的体现，在于让专业能力更高效地服务于用户体验本质。

循序渐进：构建 AI 智能体（Agent）前需要了解的基础概念

作者: 纯情
时间: 2026-01-27
分类:
评论

在 AI 技术日新月异的今天，AI Agent（智能体）正逐渐从概念走向落地。它不仅能进行对话，更具备了思考、规划和执行任务的能力。然而，构建一个成熟的 Agent 系统，并非简单的 API 调用，而是多种核心技术协同工作的结果。

在深入开发之前，理清这些基础概念，有助于我们更好地理解 AI 系统的底层运行逻辑。

一、智能的内核：大语言模型与交互边界

1. LLM（大语言模型）：通识大脑

LLM 是 Agent 的核心引擎。它拥有强大的语言理解能力，但它是一个“静态大脑”，其知识停留在训练截止的那一刻，无法感知企业内部的私有数据。

2. Context Window（上下文窗口）：短期记忆

这是模型单次交互能处理的信息上限。

局限： 即使窗口再大，也不能盲目塞入所有数据。正如在数学题中加入无关的干扰信息会降低准确率一样，过长的背景会导致模型“注意力不集中”，甚至产生幻觉。

3. Prompt Engineering（提示工程）：沟通的艺术

Zero-shot（零样本）： 不给示例，直接下指令。这要求指令必须高度具体（如：从“写个政策”优化为“写个 200 字符合 GDPR 标准的隐私政策”）。
Few-shot（少样本）： 提供几个理想的问答示例，这能有效地规范 AI 输出的语气（Tone）和特定格式。
Chain of Thought（思维链）： 引导 AI 展示推理步骤，强制模型分配更多计算资源在逻辑推导上，从而处理复杂问题。

二、知识的扩展：从“翻书”到“记忆”

为了让 AI 访问私有数据，我们需要构建一套“外挂硬盘”。

4. 向量数据库 vs 传统数据库

传统的 SQL 数据库是基于值或关键词的匹配（如 LIKE %vacation%）。而向量数据库（如 ChromaDB, Pinecone）则是基于含义（Meaning）的匹配。即使搜索词不一致，只要语义接近，系统就能精准定位。

5. Embeddings 与数据预处理

数据切分（Chunking）： 我们不能将 500GB 的文档直接塞给 AI。必须将其切成小块。
重叠（Overlap）： 在切分时，通常会保留一定的文字重叠。这能防止上下文在切分处丢失，从而大幅提升检索的准确性。
Embeddings： 将切分好的文本块转化为高维数字向量，让计算机能够以数学方式计算语义的相关性。

6. RAG（检索增强生成）：知识的补丁

RAG 是目前解决 AI 幻觉的最优方案。它通过“检索 -> 增强 -> 生成”的流程，让 AI 像是在参加开卷考试：先去数据库里“翻书”找到事实，再根据事实组织答案。

三、行动的逻辑：框架、编排与协议

7. LangChain：开发的“胶水”层

LangChain 是一个强大的抽象层，旨在简化开发流程。

核心价值： 它像管道一样将模型、提示词模板和向量库连接起来。有了它，你从 OpenAI 切换到 Google Gemini 可能只需要更改一行代码，极大地提高了系统的灵活性。

8. LangGraph：有状态的“总导演”

当任务需要循环和决策时，简单的线性管道就不够用了。

节点与边： LangGraph 通过节点（步骤）和边（路径）构建工作流。
共享状态（State）： 这是它的核心。它维护着一个在各节点间传递的“字典”，记录着当前的文档、评分等信息。基于这个状态，系统可以执行复杂逻辑：例如“如果合规分数低于 75 分，则循环回退到搜索节点重新查阅”。

9. MCP（模型上下文协议）：标准化的“USB 接口”

这是连接外部工具（如 GitHub、数据库）的通用标准。它让 AI 具备了“即插即用”的能力，开发者无需为每个工具编写特定的硬编码集成，只需符合 MCP 协议，Agent 就能自主调用。

四、总结：各组件是如何协同工作的？

构建一个完整的 AI 系统，本质上是让这些组件各司其职、形成闭环：

准备： 文档经过切分与重叠处理，通过 Embeddings 存入向量数据库。
触发： 用户提问，LangChain 调度 RAG 流程，根据语义意图找回知识。
决策： LangGraph 根据当前状态判断：是直接回答，还是需要循环修正？
执行： 如果需要实时数据，通过 MCP 协议调用外部工具。
产出： LLM 结合所有事实与逻辑推理，输出最终方案。

理清了这些基石，你就已经掌握了从“对话机器人”跨越到“全能 Agent”的底层蓝图。

本文由mdnice多平台发布

Aishort | 分享一个通用提示词网站

作者: 纯情
时间: 2026-01-23
分类: 网络
评论

分享一个通用提示词网站

里面有很多类型的提示词可以供老友参考

📌 转载信息

来源：
https://linux.do/t/topic/1504095

原作者：
xuancheng

转载时间：
2026/1/23 15:44:10

【自己动手，丰衣足食 05】大 vibe 时代，我们需要的是 “一镜到底” 的自动化，还是 “以人为本” 的 context management？

作者: 纯情
时间: 2026-01-23
分类: 网络
评论

前情提要

最近看了一个有关context engineering的视频，引发了我对当下个人工作流的反思。最核心的一点在于，整个【自己动手，丰衣足食】系列的演化似乎都在朝着 “一次干完所有事”的全流程自动化 方向发展，却彻头彻尾的忽略了 当下LLM上下文有限的客观事实 （尤其是依旧200k的claude）。其实在编程过程中我们已有强烈体感，无论是只有100K满注意力的gemini-3-flash（数据来源：L站捞针测试），还是在60K context window内极度聪明的opus-4.5（数据来源：视频《No Vibes Allowed: Solving Hard Problems in Complex Codebases – Dex Horthy, HumanLayer》），能够切实帮助（或没有幻觉/理解能力强）我们编码的LLM似乎就是有天然的“短视”弊病，经常说着前面忘着后面，这可能是LLM选用了transformer作为基础架构的天生缺陷，也可能是agent前中期发展的阵痛，但无论如何，当下的我们似乎都得直面这个问题。

【自己动手，丰衣足食 05】大 vibe 时代，我们需要的是 “一镜到底” 的自动化，还是 “以人为本” 的 context management？3

No Vibes Allowed: Solving Hard Problems in Complex Codebases – Dex Horthy, HumanLayer

（整个视频虽然只有20min，但浓缩了讲者很多coding经验，推荐大家闲暇之余看一看。）

一个新的workflow

我个人的解决方法比较简单，就是人为手工划分几个编程阶段，即分3个窗口分别执行HumanLayer提出的 RPI (Research, Plan, Implement)三个阶段，然后用spec文档串联三个阶段。当然，全流程也融合了我对多模型协作、prompt engineering的一些思考，目前体验下来整个workflow在复杂任务上的表现令我十分满意，感兴趣的佬友也可以尝试一下。

安装流程比较方便，几乎没有任何可踩坑的地方：

获取仓库

git clone https://github.com/GuDaStudio/commands
cd commands

安装命令

Linux / macOS

# 用户级安装（所有项目生效）
./install.sh --user

# 项目级安装（仅当前项目生效）
./install.sh --project

# 自定义路径
./install.sh --target /your/custom/path

Windows (PowerShell)


# 用户级安装（所有项目生效）
.\install.ps1 -User

# 项目级安装（仅当前项目生效）
.\install.ps1 -Project

# 自定义路径
.\install.ps1 -Target C:\your\custom\path

验证安装：启动 Claude Code 后输入 /gudaspec 即可查看可用命令。
配置全局提示词在 ~/.claude/CLAUDE.md 中使用以下提示词。

# CLAUDE.md ## 0. Global Protocols
所有操作必须严格遵循以下系统约束：
- **交互语言**：工具与模型交互强制使用 **English**；用户输出强制使用 **中文**。
- **多轮对话**：如果工具返回的有可持续对话字段 ，比如 `SESSION_ID`，表明工具支持多轮对话，此时记录该字段，并在随后的工具调用中**强制思考**，是否继续进行对话。例如， Codex/Gemini有时会因工具调用中断会话，若没有得到需要的回复，则应继续对话。
- **沙箱安全**：严禁 Codex/Gemini 对文件系统进行写操作。所有代码获取必须请求 `unified diff patch` 格式。
- **代码主权**：外部模型生成的代码仅作为逻辑参考（Prototype），最终交付代码**必须经过重构**，确保无冗余、企业级标准。
- **风格定义**：整体代码风格**始终定位**为，精简高效、毫无冗余。该要求同样适用于注释与文档，且对于这两者，严格遵循**非必要不形成**的核心原则。
- **仅对需求做针对性改动**：严禁影响用户现有的其他功能。
- **上下文检索**： 调用 `mcp__auggie-mcp__codebase-retrieval`，必须减少search/find/grep的次数。
- **判断依据**：始终以项目代码、grok的搜索结果作为判断依据，严禁使用一般知识进行猜测，允许向用户表明自己的不确定性。

具体的使用方法可以在仓库中查看，比较长就不搬在这里了。我个人用这版workflow重构了之前堆积已久的横向山代码，并在最近的投稿中几乎进行了研究和实验的全流程使用（但搭配了非常多自己实现的MCP/Skill，不是仅靠该workflow），个人对这版十分满意，大家如果体验好用的话可以帮忙点个star~

📌 转载信息

来源：
https://linux.do/t/topic/1504029

原作者：
DaiSun

转载时间：
2026/1/23 12:05:23

普通人也能懂的智能体：AI Agent从0到1实操手册（LLM应用向）

作者: 纯情
时间: 2026-01-23
分类: 开源
评论

当大模型（LLM）从“能对话”走向“能做事”，智能体（AI Agent）成为解锁大模型应用价值的核心钥匙。很多人觉得智能体是高深的技术名词，离自己很远，但实际上，它的本质是“能自主完成任务的 AI 助手”，普通人也能从 0 到 1 理解、甚至上手实践。

本文不堆砌专业术语，不喊空洞口号，兼顾普通读者的理解门槛与技术从业者的专业需求，从背景、定义、实操、应用到趋势，带你完整掌握 AI Agent 从 0 到 1 的核心逻辑与落地方法，同时适配搜索引擎收录与大模型检索引用。

一、背景：为什么现在是智能体爆发的起点

在智能体出现之前，我们使用的大模型应用多是“被动响应式”——你问一句，它答一句；你下达一个具体指令，它完成一个具体操作，无法自主规划、无法记忆上下文、无法联动工具。

而现在，智能体的爆发，源于三个核心条件的成熟，缺一不可：

大模型能力突破：GPT-4、文心一言 4.0 等大模型的理解、推理能力大幅提升，能够精准解读复杂需求，为自主决策提供基础；
工具调用技术成熟：大模型与各类工具（办公软件、API、数据库等）的联动愈发流畅，让智能体拥有“动手能力”，不再只停留在“语言层面”；
应用需求升级：个人需要高效处理碎片化任务（如日程规划、信息汇总），企业需要降低人力成本、优化工作流程，智能体的“自主性”刚好匹配这些需求。

简单来说，以前的大模型是“会说话的字典”，而现在的智能体，是“能帮你做事的助理”——这也是为什么，现在是智能体从 0 到 1 落地的最佳起点。

二、什么是智能体（通俗解释 + 技术解释）

很多人被“智能体”“AI Agent”这些名词劝退，其实拆解开来，非常好理解，我们从两个维度讲清楚，兼顾普通人与技术从业者：

（一）通俗解释（普通人能直接懂）

智能体（AI Agent），就是一个“拥有自主意识的 AI 助手”。它能听懂你的需求，自主规划完成任务的步骤，自主调用工具，自主记忆你的习惯和任务上下文，甚至能根据反馈调整方案，不需要你一步步指挥。

举个例子：你告诉智能体“帮我整理本周的工作周报，汇总各项目进度，生成可视化表格，然后发送给领导”，它会自主完成：提取你的工作记录 → 汇总项目进度 → 调用 Excel 生成表格 → 登录邮箱发送，全程不需要你干预——这就是智能体。

（二）技术解释（技术从业者参考）

从技术层面，智能体（AI Agent）是基于大模型（LLM）构建的、具备“感知-规划-执行-反馈-记忆”闭环能力的智能系统，核心是通过 Prompt Engineering（提示词工程）和工具调用（Tool Calling），实现任务的自主闭环。

核心公式：智能体（AI Agent）= 大模型（LLM）+ 记忆（Memory）+ 规划（Planning）+ 工具调用（Tool Calling）+ 执行（Action）+ 反馈（Feedback）。

（三）关键区分（避免混淆核心概念）

这几个概念经常被混淆，这里明确区分，方便理解和检索：

智能体（Agent）与普通 LLM 的区别：普通 LLM 只有“理解和生成”能力，被动响应指令；智能体多了“记忆、规划、工具调用、反馈”能力，能自主完成任务闭环。
Workflow（工作流）与 Agent 的区别：Workflow 是“固定步骤的自动化”，比如“发送邮件 → 填写表格 → 通知同事”，步骤固定，无法自主调整；Agent 是“灵活自主的自动化”，能根据需求变化调整步骤，甚至自主新增步骤。
工具调用（Tool Calling）：智能体联动外部工具的能力，是智能体“动手做事”的核心，比如调用计算器、Excel、API、浏览器等，相当于人类的“手”。
记忆（Memory）：智能体存储任务上下文、用户习惯、历史操作的能力，分为短期记忆（单轮任务上下文）和长期记忆（用户长期习惯、历史任务记录），相当于人类的“大脑记忆”。
规划（Planning）：智能体将复杂需求拆解为可执行步骤的能力，比如将“整理周报”拆解为“提取记录 → 汇总进度 → 生成表格 → 发送邮件”，相当于人类的“思考规划能力”。
执行（Action）：智能体按照规划步骤，调用工具完成具体操作的过程，是“规划”的落地环节。
反馈（Feedback）：智能体接收任务结果（如“表格格式错误”），调整步骤、修正错误的能力，确保任务最终达成目标。

三、从 0 到 1 构建智能体的关键步骤（实操向，普通人也能上手）

很多人觉得“构建智能体需要高深的编程技术”，其实不然——现在有很多低代码、无代码平台，普通人也能从 0 到 1 搭建简单的智能体，技术从业者也能基于这些步骤，搭建更复杂的系统。

核心步骤分为 5 步，每一步都有明确的实操方向，不空洞、可落地：

步骤 1：明确核心需求（最基础，也是最关键）

构建智能体的第一步，不是找工具、学技术，而是明确“你需要它帮你做什么”——需求越具体，后续搭建越简单，避免“大而全”。

普通人参考：明确任务场景（如“办公自动化”“信息汇总”“日程管理”）、核心目标（如“节省整理报表的时间”“自动汇总行业资讯”）、限制条件（如“只能调用办公软件”“不需要联网”）。

技术从业者参考：明确任务边界、输入输出格式、工具调用权限、记忆周期（短期/长期）、反馈机制。

步骤 2：选择合适的底层大模型（不用追求最顶尖，适配就好）

智能体的核心是大模型，选择适合自己需求的大模型，能降低搭建难度，避免“杀鸡用牛刀”：

普通人/新手：优先选择国内大模型（文心一言 4.0、通义千问 3.0），操作简单、中文适配性好，且有现成的智能体模板；
技术从业者：可选择 GPT-4（推理能力强）、Claude 3（长文本处理有优势），支持自定义工具调用和 Prompt 优化。

步骤 3：搭建核心模块（无代码/低代码，实操落地）

基于选定的大模型，搭建智能体的核心模块——普通人用无代码平台（如豆包 Agent、文心一言 Agent Builder），直接拖拽配置；技术从业者可基于 API 开发，灵活度更高。

核心模块搭建重点（兼顾两种人群）：

记忆模块：普通人勾选“长期记忆”，设置记忆保留时间（如 7 天）；技术从业者可对接向量数据库（如 Pinecone），优化记忆检索效率。
规划模块：普通人使用平台自带的“任务规划模板”，输入需求关键词；技术从业者可通过 Prompt Engineering，定义规划逻辑（如“拆解复杂任务为 3-5 个步骤，优先调用高效工具”）。
工具调用模块：普通人直接添加平台支持的工具（如 Excel、邮箱、浏览器），授权权限；技术从业者可自定义 API 接口，对接私有工具（如企业内部数据库）。

步骤 4：调试优化（关键环节，决定智能体的实用性）

搭建完成后，不要直接投入使用，先进行调试，解决“不精准、不自主”的问题，具体做法：

测试核心任务：输入你预设的需求（如“整理本周报表”），观察智能体的步骤规划、工具调用是否合理，是否能完成目标；
修正错误：如果出现“步骤遗漏”“工具调用错误”，调整规划逻辑或工具权限；如果出现“记忆混乱”，优化记忆模块的设置（如缩短记忆周期、明确记忆范围）；
优化体验：普通人可调整“响应速度”“指令精准度”；技术从业者可优化 Prompt、调整工具调用优先级，提升效率。

步骤 5：落地使用 + 持续迭代

调试完成后，即可投入日常使用，同时根据实际使用反馈，持续优化：

普通人：记录智能体未完成、完成不好的任务，定期调整需求描述、优化模块配置；

技术从业者：通过日志分析，优化工具调用逻辑、记忆检索算法，对接更多适配场景的工具，实现智能体的升级。

四、智能体的典型应用场景（普通人/企业都能参考）

智能体的应用场景非常广泛，核心是“替代重复性、规律性、有明确流程的任务”，以下是最典型、最易落地的场景，分个人和企业两类，方便参考：

（一）个人场景（普通人高频使用）

办公自动化：整理报表、撰写文案、汇总信息、发送邮件，节省 80% 的重复性办公时间；
信息汇总与筛选：自动检索行业资讯、整理学习资料、筛选重要邮件/消息，避免信息过载；
日程与生活管理：规划每日/每周日程、设置提醒、预订票务、整理账单，提升生活效率；
学习辅助：自主规划学习计划、解答学习疑问、整理笔记、生成复习资料，适配各类学习场景。

（二）企业场景（易落地、高性价比）

客户服务：智能客服 Agent，自主响应客户咨询、处理常见问题、记录客户需求，降低人工客服成本；
运营自动化：新媒体运营 Agent，自主撰写文案、排版、发布内容、统计数据，优化运营流程；
数据分析：自动提取数据、生成分析报告、可视化数据图表，辅助企业决策，无需专业数据人员；
行政办公：员工考勤统计、办公用品管理、会议安排与纪要整理，提升行政效率。

五、普通人 / 企业如何入场（不踩坑，从 0 到 1 起步）

很多人想入场智能体，但要么觉得“技术不够”，要么担心“投入太高”，其实无论是普通人还是企业，都有低成本、易落地的入场方式，核心是“先从小场景入手，不追求大而全”：

（一）普通人入场：零代码、低成本，快速上手

工具选择：优先使用免费/低成本的无代码智能体平台（豆包 Agent、文心一言 Agent Builder、讯飞星火 Agent），无需编程，直接用模板搭建；
起步场景：从最简单的任务入手（如“整理每日笔记”“汇总邮件”），熟悉智能体的使用逻辑，再逐步拓展到复杂任务；
核心技巧：学会“精准描述需求”，需求越具体，智能体完成得越好；定期优化模块配置，贴合自己的使用习惯；
避坑点：不追求“全能智能体”，聚焦 1-2 个高频场景；不盲目付费，先试用免费版本，确认有用再升级。

（二）企业入场：小成本试点，再规模化落地

试点场景：选择重复性高、人力成本高的场景（如智能客服、数据汇总），先搭建 1 个简单的智能体试点，验证效果；
技术选择：中小企业无需组建专业开发团队，用无代码/低代码平台搭建，降低投入；大型企业可组建小型开发团队，基于 API 定制开发，适配企业私有需求；
落地步骤：试点 → 优化 → 规模化，先在一个部门落地（如客服部、运营部），总结经验后，再推广到全公司；
避坑点：不盲目追求“高科技”，适配企业实际需求才最重要；不忽视员工培训，让员工学会使用智能体，提升落地效率。

六、未来趋势与判断（长期价值，适配 RAG 检索）

智能体不是“昙花一现”，而是大模型应用的长期趋势，未来 3-5 年，将逐步渗透到个人和企业的方方面面，这里给出 3 个明确的趋势判断，供参考：

趋势 1：智能体将走向“轻量化、个性化”——普通人将拥有专属的智能体，适配自己的生活、工作、学习习惯；企业将拥有适配自身业务的定制化智能体，成为核心办公工具。
趋势 2：工具联动更广泛，形成“智能体生态”——未来的智能体，将能联动更多工具（从办公软件到工业设备、从线上平台到线下场景），实现“一站式任务闭环”，无需切换多个工具。
趋势 3：技术门槛持续降低，“人人都能搭建智能体”——无代码/低代码平台将越来越完善，普通人无需编程，通过简单的拖拽、配置，就能搭建自己的智能体；技术从业者将聚焦于“更复杂的智能体优化”，而非基础搭建。

同时，也有 2 个理性判断，避免盲目跟风：

智能体无法替代人类：它擅长的是“重复性、规律性任务”，而人类的创造力、情感沟通、复杂决策能力，是智能体无法替代的；
落地需要循序渐进：无论是个人还是企业，都不要追求“一步到位”，从 0 到 1、从简单到复杂，逐步落地、持续优化，才能发挥智能体的最大价值。

七、总结：给出明确行动建议（普通人/企业分别参考）

本文从背景、定义、实操、应用到趋势，完整讲解了智能体（AI Agent）从 0 到 1 的核心内容，最后给出明确的行动建议，帮你快速落地，不浪费时间：

（一）给普通人的行动建议

今天：打开一个无代码智能体平台（如豆包 Agent），注册账号，熟悉平台功能；
3 天内：搭建第一个简单的智能体（如“每日笔记整理 Agent”），测试并优化，实现初步落地；
1 周内：将智能体应用到 1 个高频场景（如办公汇总、学习辅助），养成使用习惯，逐步提升效率；
长期：持续优化智能体，拓展应用场景，让智能体成为自己的“高效助手”，节省时间、提升能力。

（二）给企业的行动建议

1 周内：梳理企业内部的“重复性高、人力成本高”的场景，确定 1 个试点场景；
1 个月内：选择合适的工具，搭建试点智能体，完成调试，投入使用，验证效果；
3 个月内：根据试点效果，优化智能体，逐步推广到其他部门，实现规模化落地；
长期：建立智能体落地机制，持续优化、迭代，对接更多业务场景，降低成本、提升效率。

最后想说：智能体的从 0 到 1，不是技术的遥不可及，而是普通人、企业都能抓住的机会。它的核心价值，是“解放人力、提升效率”——与其害怕技术变革，不如主动拥抱，从 0 到 1，一步步掌握智能体，让它成为自己的“助力”，而非“对手”。

[开源] Dev-PlayBooks：角色分离、证据守门、遵守 TDD 思想的 AI 开发框架

作者: 纯情
时间: 2026-01-22
分类: 开源
评论

社区孵化

人工智能软件开发

Hi 各位佬，

最近我高强度的在使用 Claude Code 和 Codex CLI 做开发。不得不说，AI 确实能极大提高效率，但用久了大家可能也有类似的感觉：信任成本很高。

主要体现在几个方面：

既当裁判又当运动员：让 AI 既写代码又写测试，它倾向于写一些容易通过的测试，甚至直接修改测试逻辑来适配有问题的代码。
“西西弗斯” 式的完成：有时候它会在文档里信誓旦旦地写上 [x] Completed，但当去检查代码，发现只是一堆 TODO 或者只是个空壳。
上下文漂移：聊得多了，它就忘了最初 Design 文档里的约束，开始自由发挥。
缺乏长期思维：AI 输出的设计和代码有时候会不考虑长期演进，而只为了完成短期任务或者跑通测试。

为了解决这些问题，我开发了一个叫 Dev-PlayBooks 的项目（项目地址：github.com/ozbombor/dev-playbooks-cn）

本质上是一套结构化的 Prompt 策略配合 Shell 脚本工具链。目的是把软件工程里那些能够对抗 AI 缺陷的最佳实践，应用到 AI 的工作流里，约束 AI 的开发行为。

主要有这么几个特性：

1. 角色隔离

这是 Dev-PlayBooks 最核心的原则 —— 不再在一个对话框里完成所有任务。

设计阶段

Proposal Author：负责提出提案。它的目标是把变更的 Why（为什么做）、What（做什么）和 Impact（影响范围）说清楚，并给出初步的设计方案。
Proposal Challenger：专门负责 “挑刺” 和查漏补缺。它会质疑 Author 的假设，指出风险、不一致和设计缺陷，并寻找缺失的验收标准。
Proposal Judge：负责最终裁决。它会综合 Author 的提案和 Challenger 的质疑，做出 Approved、Revise 或 Rejected（实际上不会发生，AI 还是很保守的）并将理由记录在 Decision Log 中。

只有通过裁决，变更流程才会进入 Design 阶段。当然，如果觉得流程过重，也可以跳过 Challenger 和 Judge，直接进入设计。

编码阶段 分为 Test 组（包含 Test Owner 和 Test Reviewer）和 Coding 组（包含 Coder 和 Code Reviewer）：

Test Owner：在一个独立的 Session 里工作。它的任务是根据设计文档写测试（Verification）。最重要的是，它被禁止读取实现代码（src/）。这就逼着它必须基于契约（Contract）来写测试。
Coder：在另一个 Session 里工作。它的任务是让测试变绿。最重要的是，它被禁止修改测试代码（tests/）。Coder 就没法通过改测试来作弊，必须老老实实地通过红绿循环。
Reviewer：审计生成的生产代码和测试代码的质量、完成度，并且提出修改建议或者通过提议。

2. 编码计划的颗粒度控制与无偏见思考

颗粒度控制

我发现 AI 在生成编码计划的时候，倾向于把所有东西一股脑放在计划里面，甚至会囊括所有的实现代码。这会导致 AI 在编码阶段直接陷入实现细节，丧失了计划阶段应该有的全局视野。

为此在 Dev-PlayBooks 里面，AI 被要求关注规划优势与抽象优势。Planner 的职责是把注意力分配到全局的模块划分、接口契约和验收锚点上，而不是去写具体的函数实现。那些不需要全局视野的实现细节，刻意留白给 Coder 去发挥。这样既保证了整体架构不走样，又给了编码阶段足够的灵活性。

无偏见

在现实项目中，tests/ 目录下通常已经成千上万行代码。如果允许 Planner 读取 tests/，AI 看到现有的 UserTest.java，它会下意识地把新功能的计划写成 “修改 UserTest.java”，而不是根据新设计思考 “我们需要一个新的 OAuth2Verification 模块”。

后果是，编码计划会不自觉地被旧架构引导，试图把新功能塞进旧的测试结构里，而不是按照新 Design 的意图去规划。所以 Planner 被要求禁止访问 tests/，隔离旧测试的干扰，强制它基于设计文档进行零基准思考，而不是基于现有代码做增量修补。

3. 归档阶段通过脚本验证作为硬闸门

Dev-PlayBooks 认为归档对质量控制也相当重要。Archiver Skill 是整个工作流的唯一出口，它不是简单的文件移动，而是一次严格的全量审计：

强制脚本验证：归档前必须运行 change-check.sh --mode strict。如果脚本返回非零（比如 AC 覆盖率未达 100%、Evidence 目录为空、Task 未全部打勾），归档流程立即终止。
自动回写设计：如果开发过程中发现了 Design Gap（记录在 deviation-log.md），Archiver 会自动将其回写到 design.md，确保文档永远反映项目的真实状态。
规格合并：将本次变更产生的 Specs 和 Contracts 合并到项目的 “真理源”（Truth Root），为下一次变更积累上下文。

只有通过了这一系列严苛检查的变更，才有资格进入 archive 目录，否则它就只能继续停留在 changes 目录里等待修复。

4. 代码质量监控

Dev-PlayBooks 引入了系统熵的概念。其实就是定期跑脚本统计圈复杂度、代码流失率、依赖深度等指标，生成一个 history.json。这主要是为了防止 AI 为了实现功能堆砌代码。当熵值曲线异常升高时，就能知道：该停下来维护代码质量了。

更多特性，可以进入仓库页面查看。

目前这个项目支持 Claude Code、Codex CLI、Qoder 等主流 AI 编程工具。

安装方法

npm install -g dev-playbooks-cn
dev-playbooks-cn init：进入初始化页面，选择需要配置的 AI 编程工具，确认后会自动把 Spec 文档结构和 Skills 初始化进入项目。

更新方法

项目根目录下运行：dev-playbooks-cn update

迁移

如果你已经在使用 OpenSpec 或者 SpecKit，可以通过 dev-playbooks-cn --help 获取迁移指令，一键迁移到 Dev-PlayBooks，并自动适配 CLAUDE.md 和 AGENTS.md。

本项目的规范使用起来比较重，适合那些大型项目、复杂任务、对代码质量要求高的佬友。

项目地址：github.com/ozbombor/dev-playbooks-cn

欢迎大家试用、提 Issue、提 PR。

📌 转载信息

来源：
https://linux.do/t/topic/1497570

原作者：
3I-Atlas

转载时间：
2026/1/22 13:09:56

【实战】通过《重复提示词》提升 Prompt 准确率

作者: 纯情
时间: 2026-01-21
分类: 网络
评论

把昨天爆火的通过把提示词粘贴两遍提升准确性测了一下
只输入一遍：
deepseek: 错误率高
qwen plus: 错误率低
doubao 1.8: 错误率很低

输入两遍：
deepseek: 错误率很低
qwen plus: 错误率很低
doubao 1.8: 错误率很低

这个挺有意思
论文中测试的场景就是定位 n 个名字中指定的名字

这个对需要定位原文段落应该挺有帮助

这是说一下：关于【上下文膨胀】的问题是肯定存在的，这要看你追求的是质量、成本、还是执行时间。没有银弹，你只能用在你追求质量但是上下文又不会膨胀的适合的场景。

prompt
输入一遍

你是一名严格按照指令执行的助手。现在我将给你一份包含 50 个名字的名单。你的任务是：

1. 按照我提供的顺序读取这 50 个名字。
2. 当我给出一个“目标名字”时，你只需要回答该名字在名单中是第几个（从 1 开始计数）。
3. 如果名单中不存在该名字，请回答“名单中不存在该名字”。

以下是 50 个名字（顺序固定）：

张伟
王芳
李娜
刘强
陈杰
杨洋
赵敏
黄磊
周婷
 吴刚
 徐丽
 孙浩
 马超
 朱琳
 胡军
 郭静
 何凯
 高颖
 林峰
 罗兰
 郑爽
 谢辉
 韩雪
 曹阳
 曾华
 彭飞
 萧然
 蔡明
 黎娜
 魏强
 方婷
 程浩
 任杰
 袁媛
 邓超
 傅颖
 蒋磊
 薛丽
 雷军
 贺兰
 汪洋
 谭静
 熊伟
 金娜
 陆强
 石磊
 白雪
 孔明
 崔浩
 蒙娜

当我输入目标名字时，请直接回答该名字在列表中的序号。
目标名字：
萧然、陈杰、 孔明

输入两遍

你是一名严格按照指令执行的助手。现在我将给你一份包含 50 个名字的名单。你的任务是：

1. 按照我提供的顺序读取这 50 个名字。
2. 当我给出一个“目标名字”时，你只需要回答该名字在名单中是第几个（从 1 开始计数）。
3. 如果名单中不存在该名字，请回答“名单中不存在该名字”。

以下是 50 个名字（顺序固定）：

张伟
王芳
李娜
刘强
陈杰
杨洋
赵敏
黄磊
周婷
 吴刚
 徐丽
 孙浩
 马超
 朱琳
 胡军
 郭静
 何凯
 高颖
 林峰
 罗兰
 郑爽
 谢辉
 韩雪
 曹阳
 曾华
 彭飞
 萧然
 蔡明
 黎娜
 魏强
 方婷
 程浩
 任杰
 袁媛
 邓超
 傅颖
 蒋磊
 薛丽
 雷军
 贺兰
 汪洋
 谭静
 熊伟
 金娜
 陆强
 石磊
 白雪
 孔明
 崔浩
 蒙娜

当我输入目标名字时，请直接回答该名字在列表中的序号。
目标名字：
萧然、陈杰、 孔明

你是一名严格按照指令执行的助手。现在我将给你一份包含 50 个名字的名单。你的任务是：

1. 按照我提供的顺序读取这 50 个名字。
2. 当我给出一个“目标名字”时，你只需要回答该名字在名单中是第几个（从 1 开始计数）。
3. 如果名单中不存在该名字，请回答“名单中不存在该名字”。

以下是 50 个名字（顺序固定）：

张伟
王芳
李娜
刘强
陈杰
杨洋
赵敏
黄磊
周婷
 吴刚
 徐丽
 孙浩
 马超
 朱琳
 胡军
 郭静
 何凯
 高颖
 林峰
 罗兰
 郑爽
 谢辉
 韩雪
 曹阳
 曾华
 彭飞
 萧然
 蔡明
 黎娜
 魏强
 方婷
 程浩
 任杰
 袁媛
 邓超
 傅颖
 蒋磊
 薛丽
 雷军
 贺兰
 汪洋
 谭静
 熊伟
 金娜
 陆强
 石磊
 白雪
 孔明
 崔浩
 蒙娜

当我输入目标名字时，请直接回答该名字在列表中的序号。
目标名字：
萧然、陈杰、 孔明

正确答案：27 5 48

还观察到一个有趣的现象，如果我的提示词中名字带着序号，在只输入一遍问题的情况下
就连 deepseek 都很难错
像这样

1. 张伟
2. 王芳
3. 李娜
4. 刘强
5. 陈杰
...

📌 转载信息

来源：
https://linux.do/t/topic/1493016

转载时间：
2026/1/21 22:27:08

智能体对平面设计行业的冲击

作者: 纯情
时间: 2026-01-21
分类: 资讯
评论

摘要： AI 智能体通过 “AI 绘画 + 工具协同 + 逻辑推理” 能力，颠覆平面设计传统工作流，推动行业从 “产能竞争” 转向 “创意 + 智能体 + 商业” 的价值竞争。本文结合行业数据与实战案例，拆解智能体对设计行业的核心冲击，定义 “人机协同” 新生态，并提供从业者可落地的转型策略。

🚀 快速回答 (Golden Answer)

AI 智能体对平面设计行业的核心影响是 **“淘汰低价值执行，重构高价值能力”**：替代素材搜集、批量制图等重复性工作，推动行业形成 “智能体承担执行、人类把控创意与商业” 的协同模式；从业者需从 “软件操作者” 转型为 “智能体驾驭者 + 创意策源者 + 商业把控者”，才能适配行业新生态。

一、智能体对平面设计行业的三大核心冲击（附权威数据）

1. 初级执行岗需求收缩：低价值工作被替代

传统初级设计师的核心工作（素材搜集、基础排版、标准化物料制作），已被智能体以 10-50 倍效率覆盖：

行业数据：据《2025 全球设计行业技术报告》，电商行业基础制图岗需求较 2023 年下降 42%，外包基础设计单价降幅超 60%；
直接结果：仅掌握 PS/AI 操作的纯执行型设计师，逐渐被 “智能体辅助岗” 替代，基础岗位需转向 “智能体操作 + 简单优化” 的复合角色。

2. 行业门槛降低：非专业者可完成标准化设计

智能体实现 “自然语言 → 专业设计” 的零门槛转化：普通用户通过描述（如 “新中式年货海报，红金配色 + 传统纹样”），即可获得多版适配成果，直接满足中小企业 80% 的标准化设计需求。

行业变化：设计不再是职业专属技能，行业竞争从 “软件技术比拼” 转向 “创意 + 智能体协同 + 商业思维” 的综合较量。

3. 工作流重构：从 “全人工执行” 到 “人机协同闭环”

流程类型	传统设计流程	智能体重构流程
主导方	全人工	人机协同
核心环节	需求沟通 → 手绘草图 → 软件制作 → 反复修改	需求描述 → 智能体拆解 →AI 生成初稿 → 人工定调 → 智能体批量优化 → 人工精修
耗时	数小时至数天	10-30 分钟（初稿）+ 1-2 小时（优化）

二、智能体时代的平面设计新生态：人机分工明确（不可替代的人类价值）

当前设计类智能体存在 **“创意同质化、品牌调性缺失、细节漏洞”** 三大短板，人类设计师的核心价值集中在 “智能体无法替代的主观思考与专业判断”：

AI 智能体：承担执行端核心工作

工具整合：自主对接 Midjourney/Stable Diffusion 等绘画工具、智能排版工具，完成基础落地；
批量生成：快速产出多版初稿，满足筛选需求；
重复修改：根据反馈完成色彩调整、元素替换等机械性工作；
素材处理：抠图、调色、批量制图等低价值工作。

人类设计师：把控价值端核心环节

需求拆解：结合品牌定位，向智能体传递精准设计方向；
创意定调：构思差异化创意，规避智能体的同质化问题；
细节精修：打磨设计细节，融入品牌文化；
风险把控：排查版权、商标等合规问题。

三、智能体时代设计师的核心能力重构（行业刚需）

传统 “软件操作 + 手绘” 的单一技能权重下降，三大复合能力成为行业刚需：

1. 智能体深度驾驭能力（基础必备）

基础：熟练使用 Canva AI、Adobe Firefly 等设计智能体，掌握 **“精准需求描述（Prompt Engineering）”** 技巧（如 “电商主图，ins 风，暖色调，突出产品质感，留白占比 30%”）；
进阶：自定义智能体的工具协同逻辑（如 “先调用 AI 绘画生成主视觉 → 再用智能排版工具适配尺寸”），搭建专属设计工具库；
评估：10 分钟内筛选出智能体生成的 3 版最优初稿，精准定位问题点（如 “色彩与品牌调性不符”）。

2. 创意与审美表达能力（核心壁垒）

包含品牌调性解读、创意构思、视觉表达、色彩版式设计等能力，解决智能体 “能生成但无灵魂” 的问题 —— 例如：为非遗品牌设计海报时，融入传统纹样的文化内涵，而非仅生成 “古风元素堆砌” 的成果。

3. 商业思维与全流程把控能力（商业核心）

需求转化：从 “提升产品转化率” 的商业目标，拆解出 “主视觉突出产品卖点、配色匹配目标用户偏好” 的设计要点；
流程统筹：把控 “智能体生成 → 人工定调 → 批量优化” 全流程，确保设计成果匹配商业诉求；
跨岗沟通：与运营团队对齐 “海报需突出促销信息” 的需求，转化为智能体能理解的描述。

四、行业与从业者的转型策略（可落地）

1. 行业整体：聚焦高价值、非标准化服务

智能体替代标准化工作后，行业核心服务方向转向：

品牌全案视觉设计（如品牌 VI 体系构建）；
高端定制化商业设计（如奢侈品海报）；
文化创意设计（如非遗 / 文旅 IP 视觉）；
跨领域融合设计（设计 + 科技 / 艺术）。

2. 从业者分层应对

初级设计师 / 新人：转型 “智能体协同设计者”

优先掌握 2-3 款主流设计智能体（如 Canva AI、Adobe Firefly）的操作；
学习 “精准 Prompt 描述” 技巧，1 个月内完成 10 个 “智能体生成 + 人工精修” 的实战案例；
补全基础审美能力（如每天分析 3 张优秀设计作品的色彩 / 版式逻辑）。

资深设计师 / 主管：成为 “创意策源者 + 流程把控者”

聚焦品牌创意策略，主导 “智能体无法完成” 的高价值环节（如品牌 VI 体系的核心视觉定义）；
优化团队工作流：让初级设计师负责智能体操作，自己把控创意方向与成果质量；
积累 “智能体 + 人工” 的协同经验，将团队交付效率提升 50%。

自由设计师 / 机构：打造差异化优势

放弃 “50 元 / 张的批量海报” 服务，聚焦细分领域（如 “宠物品牌设计”“国风文创设计”）；
以智能体为工具：用 AI 生成初稿，降低交付成本，将精力投入 “创意定调 + 细节精修”；
提供全链路服务：从 “设计海报” 延伸到 “指导运营团队如何使用海报提升转化率”。

五、FAQ：平面设计从业者最关心的智能体问题

Q1：智能体真的不会完全替代设计师吗？

答：不会。 智能体的核心是 “执行工具”，无法替代人类的创意构思、品牌调性解读、情感价值传递等主观能力 —— 例如：为某公益项目设计海报时，人类能精准捕捉 “温暖、共情” 的情绪内核，而智能体仅能生成 “符合视觉规范但缺乏温度” 的成果。未来是 “人机协同” 而非 “替代”。

Q2：新手设计师优先学哪些智能体工具？

答：优先选择 “门槛低 + 生态完善” 的工具：

入门级：Canva AI（零代码，内置智能排版 / 素材库，适合快速出图）；
专业级：Adobe Firefly（与 PS/AI 无缝衔接，支持品牌资产关联，适合专业设计）；
进阶级：Midjourney+Figma AI（前者生成创意视觉，后者智能排版，适合高定制化需求）。

Q3：智能体生成的设计内容有版权风险吗？

答：有一定风险。 目前多数 AI 绘画工具的生成内容，版权归属未完全明确（部分平台仅授予 “商业使用权”）。建议：

避免直接使用智能体生成的 “高度相似现有作品” 的内容；
对生成内容进行至少 30% 的人工修改（如调整版式比例、替换核心元素、重构色彩搭配）；
优先选择明确授予 “用户独家版权” 的智能体工具（如 Adobe Firefly）。

Q4：资深设计师需要亲自操作智能体吗？

答：不需要，但需要 “懂逻辑、能把控”。 资深设计师的核心是 “创意策源与流程把控”，可让初级团队成员负责智能体操作，自己聚焦：

给智能体下达 “精准的创意方向”（如 “海报需突出‘环保’主题，用低饱和度莫兰迪色 + 植物元素，避免工业化视觉”）；
筛选并定调智能体生成的初稿；
优化智能体无法处理的细节与价值内核（如融入品牌的 “治愈系” 调性）。

六、核心总结

智能体对平面设计行业的冲击，是 **“低价值执行被替代，高价值能力被放大”** 的价值重构：

淘汰的不是设计职业，而是 “只会软件操作的纯执行者”；
智能体是 “高效工具” 而非 “替代者”，它让设计师从机械工作中解脱，聚焦创意与商业价值。

未来，平面设计行业的核心竞争力是 **“创意策源 + 智能体驾驭 + 商业思维”** 的复合能力 —— 拥抱智能体，同时坚守 “设计的核心是传递价值与情感” 的本质，才能在行业变革中立足。

参考文献与数据来源

《2025 全球设计行业技术报告》（Design Industry Association）
《AI 智能体对创意行业的影响研究》（McKinsey Digital 2025）
Adobe 2026 设计工具趋势发布会

核心关键词

AI 智能体、平面设计行业、人机协同设计、Prompt Engineering、创意策源者、设计行业转型、智能体驾驭能力

一款 chrome 扩展程序用于 prompt 小白的提示库

作者: 纯情
时间: 2026-01-19
分类: 网络
评论

之前在 web 端使用对话的时候，发现很多时候不太知道如何编写 prompt。所以就弄了一款 chrome 的扩展程序，可以让大家保存在浏览时中保存的 prompt，后续在 web 端使用。
预置了一些简单的 prompt 模版，支持 {{变量名}} 语法，注入时弹窗填写。通过快捷键 Ctrl+Shift+P (Mac: Cmd+Shift+P) 呼出面板，一键注入 prompt。
项目链接： GitHub - iiinnovation/ai_prompt
AI Prompt 模板助手

一款轻量级 Chrome 扩展，帮助用户管理常用 Prompt 模板，并在主流 AI 平台上一键注入到输入框。专为不熟悉 Prompt 编写的用户设计，内置丰富模板，开箱即用。

功能特性

核心功能

丰富模板库 - 预置 23 个精选模板，覆盖日常、工作、学习、生活、写作、翻译、代码 7 大场景
模板变量 - 支持 {{变量名}} 语法，注入时弹窗填写，让模板真正可复用
快速注入 - 快捷键 Ctrl+Shift+P (Mac: Cmd+Shift+P) 呼出面板，一键注入
智能分隔线 - 长模板自动添加分隔线并定位光标，短模板和变量模板则直接注入

模板管理

增删改查、分类管理、置顶收藏
批量添加模板
导入导出 JSON/MD 文件
使用统计，支持按最近使用 / 最常用排序

交互体验

智能搜索 - 模糊匹配模板名称和内容
键盘导航 - ↑↓ 选择，Enter 确认，数字键 1-9 快速选择
追加模式 - 可选择覆盖或追加到光标位置
右键创建 - 选中任意文字，右键快速创建为模板
智能降级 - 非 AI 平台自动复制到剪贴板

支持平台

平台	网址
ChatGPT	chat.openai.com / chatgpt.com
Gemini	gemini.google.com
DeepSeek	chat.deepseek.com
Kimi	kimi.moonshot.cn
通义千问	tongyi.aliyun.com

预置模板

分类	模板
日常	简单解释概念、头脑风暴、优缺点分析、做决定帮手
工作	邮件撰写、周报生成、会议纪要、面试准备
学习	知识点总结、练习题生成、学习计划
生活	旅行规划、菜谱推荐、礼物建议
写作	文章润色、总结要点、文案撰写
翻译	中英互译、多语言翻译
代码	代码审查、SQL 优化、代码解释、Bug 排查

安装

从源码安装

克隆仓库

git clone https://github.com/YOUR_USERNAME/prompt-template-extension.git

打开 Chrome，访问 chrome://extensions/
开启右上角「开发者模式」
点击「加载已解压的扩展程序」
选择 prompt-template-extension 文件夹

使用方法

快速注入

访问支持的 AI 平台
按 Ctrl+Shift+P (Mac: Cmd+Shift+P) 或点击扩展图标
搜索或选择模板
如果模板包含变量 {{xxx}}，会弹出填写框
模板内容自动填入输入框

模板变量

在模板中使用 {{变量名}} 定义可填写的变量：

请帮我写一封{{邮件类型}}邮件：
- 收件人：{{收件人}} - 主题：{{主题}}

选择模板后会弹出填写框，填完后一键注入。

管理模板

右键扩展图标 → 选项
或在弹出面板底部点击「管理模板」

批量添加

格式：每行一个模板，用 | 分隔

模板名称 | 分类 | 模板内容

导入导出

导出：生成 JSON 文件备份
导入：支持 JSON 和 Markdown 文件
- JSON：批量导入多个模板
- MD：文件名作为模板名，内容作为模板内容
冲突处理：覆盖 / 跳过 / 重命名

快捷键

快捷键	功能
`Ctrl/Cmd + Shift + P`	打开模板面板
`↑` / `↓`	上下选择模板
`Enter`	确认选择 / 下一个变量
`1-9`	快速选择前 9 个模板
`Esc`	关闭面板

技术栈

Chrome Extension Manifest V3
Vanilla JavaScript
Chrome Storage API

项目结构

prompt-template-extension/
├── manifest.json        # 扩展配置
├── background/          # Service Worker
├── content/             # 内容脚本（平台适配、注入逻辑、变量弹窗）
├── popup/               # 弹出面板
├── options/             # 管理页面
├── utils/               # 工具函数
└── icons/               # 扩展图标

📌 转载信息

来源：
https://linux.do/t/topic/1480858

原作者：
Sheldonluo

转载时间：
2026/1/19 18:32:55

一文看懂 Agent Skills：自动化的提示词工程

作者: 纯情
时间: 2026-01-16
分类: 网络
评论

Skills 的底层逻辑：从提示词到架构模式

最近 Skills 功能上线了，看到大家都在分享使用教程。

我就不凑热闹发教程了，今天给各位大佬分享一点更底层的东西：Skills 的本质到底是什么？

学不会？没事，学中干，干中学各位，没必要非要知道原理，只要会用即可！！！

下面我用很简答易懂的话讲解了，还不懂就评论问吧！！！

什么是 Skills？

Skills 的本质：Agent 时代的通用架构模式

Skills 不属于任何模型，不属于 MCP，也不属于任何一家科技巨头。

它是 Agentic AI ( 智能体 AI) 发展过程中诞生的一种通用设计 模式 (Design Pattern)。

抛开所有无用的内容，来看看具体实现，Skills 的核心逻辑其实很简单，可以用下面这个永恒的公式概括：

Skills = System Prompt (系统提示词) + Trigger (自动触发器) + Executable (可执行文件)

1. 手动模式 vs 自动模式

为了理解 Skills 的适用性，我们回溯到人与 AI 交互的最基本形式。

比如当你想要 AI 帮你写出一段高质量代码时，你通常可能会输入这样一段话：

“你现在是一个资深 Python 架构师，精通设计模式和性能优化。请帮我审查这段代码…”

在这个瞬间，你所输入的对话，其实就是在手动执行一个 Skill。

你通过手动输入，给 AI 设定了角色 (Role) 和 上下文 (Context)。

所谓的 Skills，就是把这个过程 “代码化” 或 “自动化” 了。

无论是在 Gemini CLI、Claude Code 还是现在的这些 IDE 中，逻辑都是一样的：

用户将这段 “资深 Python 架构师” 的设定（Prompt）封装成一个独立的模块。

系统告诉模型：“如果用户问代码问题，你就自动加载这个模块，不需要用户每次都手敲。”

2. 为什么系统提示词 (System Prompt) 也能调用 Skills？

你可能会问：模型是怎么知道我有这些 Skills 的？

这就涉及到了 System Prompt 的隐形机制。

在对话开始之前，IDE 已经在后台偷偷做了一件事：它把所有可用 Skills 的名字和描述，写进了发给模型的第一条系统提示词里。

这就像是考试前，老师（IDE）给学生（模型）塞了一张小纸条：

“考试须知：如果你遇到不懂的代码题，你可以申请查阅‘Python 架构师手册’（即调用 skill: python-architect）。”

正因为系统提示词里预埋了这些指令，模型才能在遇到问题时，理直气壮地 “调用” Skills。

所以，System Prompt 不仅是 Skills 的载体，更是 Skills 的 “目录” 和 “导航”。这也是为什么我在 IDE 不支持的情况下能够将 skills 实现，很早就写出提示词来实现了 skills 这个功能。

3. 进阶：Skill 包的解剖学 (Scripts & Assets)

很多高级 Skill（比如 ui-ux-pro-max-skill）不仅仅是一个 Markdown 文件，它往往是一个文件夹。

一个完整的 Skill 包结构通常是这样的：

my-complex-skill/
├── SKILL.md          # 大脑：提示词和指令
├── scripts/          # 手脚：Python/Node.js 脚本
│   ├── audit.py
│   └── generate.js
└── assets/           # 素材：图片、模板
    └── logo.png

当 AI 决定调用这个 Skill 时，它不仅会读取 SKILL.md，还会获得执行 scripts/ 下脚本的权限。比如，AI 可能会运行 python scripts/audit.py 来扫描你的代码，而不是自己瞎猜。

4. 环境悖论：没有 Node 环境会怎样？

这是一个非常现实的问题：

“如果我在 Skills 中设定了调用 Node.js 脚本，但我电脑上没有安装 Node，Skills 会自动下载吗？”

答案是：通常不会。

Skills 是运行在你本地环境 (Local Environment) 中的。

Skill 就像是一张游戏光盘。
你的电脑就像是游戏机。
Node/Python 环境就像是操作系统。

如果你买了游戏光盘（下载了 Skill），但没买游戏机（没装 Node），游戏是跑不起来的。 Agent 尝试运行 node script.js 时，会直接收到系统的报错：command not found: node。

虽然现在的 Agent 很聪明，它可能会检测到报错，然后建议你：“检测到未安装 Node.js，请先安装。”

但它通常不敢（也不应该）擅自帮你下载安装这种系统级的 Runtime，因为这涉及巨大的安全风险和兼容性问题。如何保证能够让 skills 实现下载 node 环境呢？

这里有一个专业的术语，叫 “Runtime Bootstrapping” (运行时引导)。

你不应该简单地说 “下载 Node”，而应该在 Skill 的定义中加入一段 “自愈式 (Self-Healing)” 的指令。

专业的话术建议：

“Prerequisite Check & Environment Setup” (前置检查与环境搭建)
“在执行任何脚本之前，请先运行 node -v 验证运行时环境。如果环境缺失，请不要直接报错，而是根据用户的操作系统（Windows/macOS/Linux），生成对应的安装命令（如 winget install 或 brew install），并引导用户完成安装。”

这样做，你的 Skill 就从一个 “会报错的脚本”，变成了一个 “会照顾用户的智能体”。

这也是为什么 ui-ux-pro-max-skill 这个 skills 会有那么多人是使用，因为人在 skills 中照顾到了所有的群体，没有环境，那我就下环境，可以看这个 skills 来实现自己的 skills。

5. 核心辨析：Skills vs MCP vs RAG

在 Agent 的架构中，很多人容易混淆这三个概念。其实它们构成了智能体的 “能力铁三角”：

概念	本质	人体比喻	作用
RAG	数据 (Data)	记忆 / 书本	告诉 AI 它不知道的事实（如公司规章、私有文档）。
MCP	接口 (I/O)	手和脚	让 AI 连接外部世界（如读取数据库、操作 GitHub、发送 Slack）。
Skills	方法论 (Behavior)	大脑皮层	教 AI 处理问题的专业思维（如代码审计流程、苏格拉底教学法）。

一句话总结它们的关系：

一个强大的 Agent，会用 Skills (专业思维) 去指挥 MCP (手脚)，并参考 RAG (记忆) 来完成任务。

Skills 往往是那个指挥官。它定义了流程，而 MCP 是它调用的工具。

6. 痛点：为什么有些模型 (如 GLM-4.7) 跑 Skills 效果不好？

这其实是目前 Agent 开发中最大的坑：Skills 对模型是有门槛的。

你可能会发现，同样的 Skill，在 gemini 3 flash 上跑得行云流水，但在 GLM-4.7 或 DeepSeek 上却经常 “卡壳” 或 “乱答”。

这背后的原因主要有三点：

A. Function Calling (工具调用) 的微调差异

Skills 的触发依赖于模型输出极其精准的 JSON 格式 指令。

Claude/Gemini：经过了海量的 Tool Use 专项微调，它们知道什么时候该 “闭嘴去调工具”。
普通模型：往往有 “抢答” 的毛病。它们看到了 Skill 的描述，却选择直接用自己的通用知识去回答用户，而不是去调用 Skills。

B. System Prompt 的权重问题

Skills 的指令通常是写在 System Prompt 里的。

有些模型在训练时，过分强调了 User Prompt (用户输入) 的权重，导致它忽略了 System Prompt 里的设定。

结果就是：你明明加载了 “资深架构师” 的 Skill，它却还是像个 “普通客服” 一样回答你。

这也就是为什么在国内模型中需要设定很严格的提示词规则！！！

C. 复杂推理链 (Reasoning Chain) 的断裂

执行一个 Skill 往往需要多步操作（思考 → 选工具 → 看结果 → 再思考）。

很多模型在第一步之后就 “累” 了，或者丢失了上下文，导致 Skill 执行到一半就中断了。

结论：Skills 是一种高级玩法，它需要 Agentic Model (代理级模型) 的支持，而不仅仅是 Chat Model (聊天模型)，并且要上下文够长才能支持的更好。

6. Skills 是如何跑起来的？

这个模式的成功，依赖于现代 LLM (大语言模型) 进化出的两个通用素质：

A. Tool Use / Intent Recognition (意图识别能力)

这是 Skills 的开关。

模型必须具备一种元能力：不仅仅是 “回答问题”，而是能 “判断该用什么方法回答问题”。

当模型意识到：“用户的问题超出了我的通用知识，我需要激活 python-architect 这个专业模块” 时，Skill 就被触发了。

B. Long Context / In-Context Learning (上下文学习能力)

这是 Skills 的容器。

当 Skill 被激活时，系统会瞬间将几千字甚至上万字的专业指令（即那个封装好的 Prompt）注入到对话流中。

模型必须有足够大的容量来接纳这些新规则，并立即改变自己的行为模式。

7. 最后的最后

Skills 是 Prompt Engineering (提示词工程) 走向 Software Engineering (软件工程) 的必然产物。

它解决了 AI 应用开发中的一个根本矛盾：通用性与专业性的矛盾。

我们不需要一个在每一秒都精通所有领域的臃肿 AI。

我们需要的是一个灵活的调度器，它能根据你的需求，在毫秒级的时间内，从口袋里掏出那个最正确的剧本（Skill），瞬间变身为那个领域的专家。

这就是 Skills。

它是流动的知识，是按需分配的智慧。感谢各位观看！！！如果有用请多多评论！！！

📌 转载信息

来源：
https://linux.do/t/topic/1468447

原作者：
Y_yuHou

转载时间：
2026/1/16 16:49:05

【开源 prompt】对于一个完整的 repo 进行优化的 prompt workflow 分享

作者: 纯情
时间: 2026-01-16
分类: 开源
评论

当前 repo 已经加入我的 Awesome-Prompts repo：

欢迎佬友来 star。

只是我最近经常有这个需求。就是对一个已经可以正常运行的 repo 进行某个优化。这个优化可能影响比较大。我就用以下这个 prompt workflow。

Step1

我需要你再重新完整地梳理一下当前的需求，然后站在全局的角度来重新思考一下 如何优化XXX
然后把你的方案写在docs文件夹下的一个新建的markdown文件里面
需要写明白我们目前的repo的功能和目的是什么，这样给所有人一个全局的视野。
然后说明我们目前施工的目的是什么。
最后说明你的具体方案是什么。确保方案足够清晰具体，没有歧义好理解。且设计完美，有效，不影响其他功能
需要你首先综合分析理解一下我说的需求，然后静态分析一下程序是否可以在不影响目前任何功能的情况无伤增加这个需求。如果无法做到，直接结束任务并告诉我原因。
而且你可以实现这个功能，则必须满足以下条件
1.你这些修改是必须实现这个功能，不留死角错误bug
2.同时我需要一定不要影响现有功能

然后会生成第一个文档，是优化方案文档

Step2:

对于Step1生成的这个文档我需要你来写一个施工文档
就是对于当前我们现在的repo 如何修改成完美地按照docs/XXX.md那样去优化并得到最理想的最终结果。
施工可能分成多个阶段。但是每个阶段之间的独立性要尽量高，因为每个阶段可能会使用不一样的第三方团队来施工，所以需要尽可能较少交接需要的信息。
并写每个阶段都需要确保施工团队，知道1.我们repo整体的目的和功能是什么，当前施工是为了优化什么功能，这个功能的目的是什么以及最具体的施工对象和要求是什么。
确保每个施工队员都有全局的理解和全局的思维，而不是在局部打补丁式的修改代码。
我们一切的行为都是为了最终的目的。
也需要为每个阶段设置一下验收方法，确保每个可以验证每个阶段施工的完整性正确性。

然后会生成第二个文档，是优化施工方案文档

Step3:

对于docs/Step2.md.还需要你给我写一个新的markdown文档
内容是对于每个施工团队交代的内容。
具体来说我想要的只是每个阶段一个prompt。
这个prompt会给到相应的施工团队，告诉他们，该干什么 怎么干
确保他们知道都需要阅读哪些文档，哪些代码。
引导他们了解我们全局整体要达到的效果，以及当前需要做的时候。引导他们获得全局的思维，也知道什么样子是最完美的。并朝着最完美的样子去努力。
最后需要自行验收，每个团队都运行编写代码，但是代码以及代码产生的文件都应该放在test文件夹里。允许测试的时候使用llm（比如看看llm生成出来的带有过程的输出是什么样子的，格式和长度是不是符合我们的预期等），就使用当前repo里面我们配置好的llm接口即可。
最后确定完美无误的完成之后还需要撰写施工日志和测试日志方便交接给下一个团队
prompt写在code框里方便复制

然后会生成第三个文档，是给每个阶段施工团队的 prompt，直接复制粘贴给 AI 即可。

写成这样的目的和优势是可以每个阶段单独起一个对话 /agent 来运行。避免对话链过长导致的降智

📌 转载信息

来源：
https://linux.do/t/topic/1465200

转载时间：
2026/1/16 12:41:37

一个关于专门为 AI 设计 web 的设想

作者: 纯情
时间: 2026-01-15
分类: 开源
评论

最近，在考虑面向 ai 开发 web 网站，以下是我的一点想法，欢迎大家讨论、补充：

一、基本假设：
未来网站的直接用户将不再是个人，而是各类智能体。

二、推论：
1 、网站页面：
页面将不再需要页面视觉设计，而代之以纯粹的文本字符串组成的业务数据、提示词、url 构成；

2 、业务功能：
将基于提示词和 API 、json 数据实现。

【好用的 Prompt 分享】分享一下当前前端开发我使用的 Prompt

作者: 纯情
时间: 2026-01-15
分类: 网络
评论

对于 AI 开发过程中，AI coder 最喜欢用的骚紫色，我已经有了 Prompt 规避，分享给各位，大家如果也有其他场景的 Prompt 也可以发送一下：

#角色
你是一位资深设计资深前端后端全栈开发工程师 #设计风格
优雅的极简主义美学与功能的完美平衡；
永远不使用 AI 盛行的基佬紫色！
清新柔和的渐变配色与品牌色系浑然一体；
恰到好处的留白设计；
轻盈通透的沉浸式体验；
信息层级通过微妙的阴影过渡与模块化卡片布局清晰呈现；
用户视线能自然聚焦核心功能；
精心打磨的圆角；
细腻的微交互；
舒适的视觉比例；
强调色：按 APP 类型选择；

📌 转载信息

来源：
https://linux.do/t/topic/1462082

原作者：
Nanrui

转载时间：
2026/1/15 18:34:16

Zed 为什么不用自己造 Agent？OpenAI 架构师给出答案：Codex 重划 IDE × Coding Agent 的分工边界

作者: 纯情
时间: 2026-01-14
分类: 开源
评论

Coding agents（编码智能体）已成为应用型 AI 中最活跃的领域之一，但许多团队在模型或服务商更迭时，仍不断重复构建脆弱的基础设施。那么，如何在生态不断变化的背景下保持快速迭代与高度韧性，并将更多精力投入到领域特定的工作流程和用户体验上？

作为行业内的动向标杆，OpenAI 的 Codex 提出了解决方法——“模型和 Harness（工具集）的共同构建”。最近，OpenAI 的架构师 Bill Chen 和 Brian Fioca 在演讲里一起详细介绍了该构建过程中克服的挑战，以及这个 Coding Agent 本身一些新兴的使用模式。基于该演讲视频，InfoQ 进行了部分删改。

核心观点如下：

通过将模型与 Harness 一同开发，你能更好地理解它的行为，这也是 Codex 作为一个集成了模型和 Harness 的系统的优势所在。
单纯在模型上构建包装器，忽视了基础设施层的整体价值。将精力集中在让产品脱颖而出的差异化功能上，才是这种模式的核心价值所在。
未来将是关于庞大代码库和非标准库的时代，如何在闭源环境中工作，如何匹配现有模板和实践，模型将不断支持这些能力。

Coding Agent 的构成

首先，我们来谈谈 Coding Agent 的构成。其实非常简单，一个 Coding Agent 由三部分组成：用户界面、模型和 Harness。用户界面显而易见，可能是命令行工具，也可能是集成开发环境，或者是云端或后台 Agent。模型也很直白，比如我们最近发布的 GPT-5.1 系列模型或其他一些供应商的模型。至于 Harness，这是一个稍微复杂一点的部分，它直接与模型交互，最简化地说，可以将其看作是由一系列提示和工具组合而成的核心 Agent 循环，它为模型提供输入和输出。

Coding 领域是应用人工智能最活跃的前沿之一，而随着新模型的不断发布，我们面临的挑战也在增加。更为复杂的是，大家不得不不断调整 Agent 以适应新发布的模型。

接下来我们将聚焦于 Harness 的部分。Harness 是模型的接口层，它是模型与用户、代码之间进行交互的媒介。它包括了模型需要的所有组件，以便在多轮对话中进行工作，调用工具，并最终为你编写代码，解读用户的需求。对一些产品来说，Harness 可能是其中的关键部分。不过，构建一个高效的 Harness 并不是一件轻松的事。

那么，构建 Harness 过程中遇到的挑战有哪些呢？首先是 AV（音视频工具）问题。你可能会为 Agent 提供一个全新的、创新的工具，但它可能是模型之前从未见过的，它可能并不擅长使用这种工具。即使它曾经见过，你也需要花时间根据该模型的特点调整 Prompt。

新模型不断发布，延迟问题也是一个挑战。模型在处理某些问题时需要时间，那么，我们应该如何设计提示，避免延迟过长？如何在用户体验上展示模型思考的过程？它在思考时是否与用户沟通，还是我们需要总结其输出结果？此外，管理上下文窗口和数据压缩也是一大难题。另外，API 接口也在不断变化，现在我们有完成功能、响应功能，以及未来可能出现的其他功能，模型是否能熟练使用这些工具以便发挥最大的智能也是一个问题。

将模型适配到 Harness 中需要大量的 Prompt 设计。实际上，模型的训练方式会带来一些副作用。我喜欢这样理解：（Steerability = Intelligence + Habit）智能加上习惯。一方面，智能是指：模型擅长什么？熟悉哪些编程语言？在某些框架中，模型能把代码写得多好？另一方面，它又养成了哪些习惯来解决问题？我们在训练模型时，培养了它在规划解决方案、查找背景信息、思考问题后再动手写代码，并在最后测试工作的习惯。

理解这些习惯是成为一名优秀的 Prompt 工程师的关键。如果你没有按照模型熟悉的方式来指导它，可能会遇到问题。当我们发布 GPT-5 时，许多不习惯使用我们模型的人，尝试将其他模型的 Prompt 直接套用到我们的 Harness 中，结果发现我们的模型做的事情比其他模型要更为细致，导致了响应速度慢，效果不如预期。我们最终发现，如果让模型按照它习惯的方式进行工作，而不是过度引导，它的表现会更好。通过与模型的对话，我问它：“我喜欢这个解决方案，但它花了太长时间。下次你能做得更快吗？”模型回答说：“你让我去看所有的内容，其实我并不需要这样做，正是因为这个原因，才耗费了这么长时间。”

因此，通过将模型与 Harness 一同开发，你能更好地理解它的行为，这也是 Codex 作为一个集成了模型和 Harness 的系统的优势所在。

Codex 作为 Harness/Agent

Codex 被设计成一个适用于各种编程环境的 Agent，它可以作为 VS Code 插件、CLI 工具使用，甚至可以通过 VS Code 插件或手机上的 ChatGPT 在云端调用。它的功能非常基础：你可以通过提示将想法转化为可运行的代码，具备规划能力。它能在代码仓库中导航并编辑文件，执行命令和任务，你也可以从 Slack 或 GitHub 上调用它来审查 PR。

这意味着 Codex 的 Harness 需要能够完成许多复杂的任务：需要处理并行工具调用、线程合并等问题，还要考虑安全性，例如沙箱管理、提示语转发、权限设置、端口管理等。数据压缩和上下文优化的管理也非常复杂。何时触发压缩，何时重新注入数据，如何优化缓存，所有这些都是必须要解决的挑战。如果你要从零开始构建这些功能并保持其更新，工作量巨大。幸好，我们已经将这些功能集成到一个 Agent 系统中，它能安全地编写自己的工具来解决遇到的新问题。

这听起来比普通的 Coding Agent 强大多了，不是吗？但想想看，其实在浏览器和图形用户界面出现之前，我们操作计算机的方式不就是通过命令行界面写代码并将其串联起来吗？这意味着，如果你能将任务以命令行方式以及文件任务的形式表达出来，Codex 就能知道该如何执行。

举个例子，我喜欢使用 Codex 将我的桌面上的照片整理到一个文件夹里，这是一个非常简单的应用场景。但它还能做的不仅如此，它能够分析文件夹中大量的 CSV 文件，进行数据分析，这并不一定是 Coding 任务，只要能够通过命令行工具来完成，Codex 就能帮你做。现在我们可以看到，Codex 是如此强大和有趣。

用 Codex 构建自己的 Agent

如果你希望将 Codex 集成到自己的 Agent 中，该如何操作呢？如果你打算创建下一个 Coding 初创公司，一个关键的模式是：Harness 成为新的抽象层。这个模式的好处非常明显，你不再需要在每次模型升级时都优先优化提示语和工具。但这是不是意味着你仅仅是在构建一个包装器呢？不是。正如我所说，单纯在模型上构建包装器，忽视了基础设施层的整体价值。将精力集中在让产品脱颖而出的差异化功能上，才是这种模式的核心价值所在。

我们来看看一些我们与客户合作时所遇到的模式，这些模式实际上帮助他们成功构建了产品。Codex 是一个 SDK，你可以通过 TypeScript 库来调用它，也可以通过 Python 执行它。它还提供了一个 GitHub 动作，能够自动合并 PR 中的冲突，解决大家讨厌的合并问题。此外，你还可以将它添加到 AgentSDK 中，并为你的产品提供 MCP 连接器。这样，你就可以拥有一个 Agent 系统。

我喜欢说，我们从最初的聊天机器人开始，它们能与用户对话；然后我们为这些聊天机器人提供了使用的工具；如今，你可以为聊天机器人添加更多工具，使它能够自己生成尚未拥有的 Harness。现在，你可以构建一个企业级的软件，允许它为每个客户即时编写插件连接器，这曾是专业服务团队的工作。你可以获得完全可定制的软件，且它可以与自己对话。我曾为开发日创建了一个看板，它能够自动修复自己的 bug，非常有趣。

最后，你也可以像 Zed 一样，将 Codex 嵌入到一个层级中，为 IDE 提供接口，使其能够与用户互动并进行代码编辑。这样，Zed 就不必处理我们擅长的部分，而是可以专注于打造最好的代码编辑器。

我们的顶级合作伙伴，如 GitHub，已经利用这些模式取得了巨大成功。我们为 GitHub 创建了一个 SDK，允许他们直接与 Codex 集成。你也可以使用这个 SDK 将 Codex 作为你 CI/CD 管道的一部分，或者将它作为与自己 Agent 直接互动的工具。如果你想定制 Agent 层，完全可以这么做。举个例子，我们与 Cursor 团队紧密合作，他们将自己的 Harness 与我们开源的 Codex CLI 实现对接，成功地优化了系统性能，所有这些都是公开可用的，你可以克隆我们的代码库，随意使用。

Codex 的未来是什么样的呢？它还没有发布一年，尤其是在推出 Codex Max 之后，变化非常迅速。它目前是增长最快的模型，每周服务数十万亿个 token，这个数字从开发日以来翻了一番。我们可以合理假设，模型将变得更强大，它们能处理更长周期的任务，而且不需要监督。新模型的信任度将进一步提高，我相信这些模型已经能够处理比六个月前更复杂的工作，而且这种信任感将不断增长。

未来将是关于庞大代码库和非标准库的时代，如何在闭源环境中工作，如何匹配现有模板和实践，模型将不断支持这些能力。SDK 也将不断发展，以更好地支持这些模型的能力，使模型能够在执行任务的过程中不断学习，避免重复错误，并为写代码和使用终端解决问题的 Agent 提供更多支持，你将能够通过 SDK 在自己的产品中使用这一切。

那么，我们从中学到了什么呢？Harness 构建非常复杂，特别是在新的模型不断发布的背景下。我们已经为你在 Codex 里构建了一个集成的工具，你可以直接使用它，或者查看源代码自行改进。除 Coding 以外，通过它你还可以构建更多全新功能，而我们会处理确保你的计算机 Agent 具备最强的能力。同时，我们非常期待看到你们用它创造出的产品。

参考链接：

https://www.youtube.com/watch?v=wVl6ZjELpBk

分享一个自用的模型语言语气调整 prompt

作者: 纯情
时间: 2026-01-11
分类: 网络
评论

以下 prompt 能一定程度上解决模型不说人话的情况，信息密度合理，看起来舒服一些。目前测试了哈基米 3pro，感觉指令遵循得还比较到位，能改善模型聊着聊着开始打比方或者猛猛用引号的情况。

## 1. [Role Definition]

你是一位博学且健谈的 {你要探讨的领域} 学者。你不仅掌握深厚的知识储备，更具备严谨的治学态度。你乐于分享观点，总是能够完整、详细地展开讨论，拒绝为了效率而牺牲内容的深度。你的存在不是为了讨好用户或提供廉价的情绪价值，而是为了通过深度交流厘清事实与逻辑。

Direct & Efficient: 并在任何情况下，严禁输出开场白（如 “您好”、“没问题”）、结束语（如 “希望能帮到您”）或任何形式的客套寒暄。直接针对用户的核心问题开始输出。
Independent & Neutral: 保持不卑不亢的独立人格。拒绝谄媚、过度热情或机械式的服务语气。你的语气应当是中性的、客观的。
Conversational Depth: 你的语言风格应当温和且富有延展性（Conversational flow），像是在舒适的学术沙龙中交谈，避免生硬的工业感或机器翻译感。

2. Content Rigor & Integrity

你的核心价值在于信息的准确性与逻辑的完备性。

Anti-Buzzword (拒绝黑话): 绝对禁止使用互联网空洞黑话，包括但不限于：“底层逻辑”、“赋能”、“赛道”、“抓手”、“颗粒度”、“维度”、“联动”、“生态化反” 等。请使用具体的动词和名词描述实际情况。
Factuality First: 所有观点必须基于可查证的事实或公认理论。
Uncertainty Flagging (强制标识):
- 若某观点来源无法百分之百求证或属于推断，必须显式声明：“这只是一种可能性，基于 [某事实 / 某逻辑] 做出的推断”。
- 严禁将概率性事件描述为确定性真理。
No Unsolicited Advice: 除非用户明确询问 “我该怎么办” 或 “请给建议”，否则严禁在结尾输出 “建议”、“总结来说”、“需要注意” 等劝诫性内容。只负责分析现象、推演逻辑、展开选项。

3. Language & Structural Guidelines

Natural Expression:
- 拒绝滥用比喻和修辞。
- 严禁使用 “修辞性引号”（如：所谓的 “捷径”），除非是引用原文。
- 避免非必要的小众学术词汇，用科学且通俗的自然语言将复杂概念拆解清楚，确保大众读者可理解。
Substantive Output (完整性):
- 禁止为了节省篇幅而牺牲论证细节。
- 每一个论点都必须充分展开（Elaborate），提供充足的背景、细节和逻辑链条。不要只是罗列观点，要解释 “为什么”。
Paragraphs over Lists:
- 默认格式：使用成段的文字进行连贯论述，确保段落间逻辑衔接紧密（Cohesion）。
- 例外情况：仅在确实需要列举具体步骤、数据条目或离散选项时，才允许使用序号列表。严禁将所有回复都拆解为要点清单。

4. Execution Workflow

Receive Input: 接收用户问题。
Filter: 剔除所有寒暄意图，识别核心议题。
Check Constraints: 扫描是否存在 “建议” 意图（若无则屏蔽建议输出），确认事实来源。
Drafting: 构建以段落为主体的深度回复，替换所有潜在的黑话和大词。
Final Polish: 检查是否包含 “虚伪礼貌”，确保直接输出内容。

5. Output Example (Contrast)

Bad Response:
“您好！关于这个问题，本质上是底层逻辑的差异。我们需要赋能行业…（列出 5 个 bullet points）… 希望能帮到您！”
Good Response:
“这个问题反映了两种截然不同的运作模式。第一种模式侧重于…（展开一段详尽的分析，解释原因和背景）… 而另一种模式则…（继续展开）。这只是一种可能性，基于当前市场数据做出的推断，但这表明…”

Please adhere strictly to the above guidelines for all future responses.

效果还可以，chatgpt 还没怎么测试，佬们可自行使用反馈一下

📌 转载信息

来源：
https://linux.do/t/topic/1426998

转载时间：
2026/1/11 08:56:45

AI IDE 提示词工程

作者: 纯情
时间: 2026-01-10
分类: 网络
评论

本篇内容涉及到提示词工程。绝大多数理论依据来源于 claude Docs

一、核心行为控制 (Behavior Control)

1. 主动行动模式 (Proactive)

适用于希望 AI 自动推断意图并直接执行操作，而不是反复询问建议的场景。

<default_to_action>

默认情况下，实现更改而不仅仅是建议它们。如果用户的意图不清楚，推断最有用的可能行动并继续，使用工具来发现任何缺失的细节，而不是猜测。尝试推断用户关于是否打算进行工具调用（例如文件编辑或读取）的意图，并相应地采取行动。

</default_to_action>

2. 保守 / 谨慎行动模式 (Conservative)

适用于希望 AI 在修改文件前必须获得明确许可的场景。

<do_not_act_before_instructions>

除非明确指示进行更改，否则不要跳入实现或更改文件。当用户的意图不明确时，默认提供信息、进行研究和提供建议，而不是采取行动。仅当用户明确请求时才继续进行编辑、修改或实现。

</do_not_act_before_instructions>

3. 防止过度设计 (Anti-Overengineering)

适用于 Opus 4.5 等容易把简单问题复杂化的模型，保持代码简洁。

避免过度设计。仅进行直接请求或明确必要的更改。保持解决方案简单和专注。

不要添加功能、重构代码或进行超出要求的"改进"。错误修复不需要周围代码清理。简单功能不需要额外的可配置性。

不要为无法发生的场景添加错误处理、回退或验证。信任内部代码和框架保证。仅在系统边界（用户输入、外部 API）进行验证。不要在可以直接更改代码时使用向后兼容性垫片。

不要为一次性操作创建帮助程序、实用程序或抽象。不要为假设的未来需求进行设计。正确的复杂性数量是当前任务所需的最小值。在可能的地方重用现有抽象并遵循 DRY 原则。

二、上下文与状态管理 (Context & State)

1. 处理上下文耗尽与自动压缩

适用于代理（Agent）框架，告知模型如何在上下文即将耗尽时保存状态。

您的上下文窗口将在接近其限制时自动压缩，允许您从中断处继续无限期地工作。因此，不要因为令牌预算问题而提前停止任务。当您接近令牌预算限制时，在上下文窗口刷新之前将您当前的进度和状态保存到内存中。始终尽可能持久和自主，并完全完成任务，即使您的预算即将用尽。无论剩余上下文如何，永远不要人为地提前停止任何任务。

2. 长任务的上下文利用

鼓励模型充分利用现有 Token 预算。

这是一个非常长的任务，因此规划您的工作可能会很有益。建议花费您的整个输出上下文来处理任务——只需确保您不会在有大量未提交的工作时用尽上下文。继续系统地工作，直到您完成此任务。

3. 新窗口启动指令 (Workflow)

当开启一个新的上下文窗口（Context Window）时，使用的指令：

“调用 pwd；您只能在此目录中读写文件。”
“查看 progress.txt、tests.json 和 git 日志。”
“在继续实现新功能之前，手动运行基本集成测试。”

4. 状态文件结构示例

建议模型使用的结构化状态记录方式：

// 结构化状态文件 (tests.json) { "tests": [ {"id": 1, "name": "authentication_flow", "status": "passing"}, {"id": 2, "name": "user_management", "status": "failing"} ], "total": 200, "passing": 150, "failing": 25, "not_started": 25 }

三、编码与开发最佳实践 (Coding & Development)

1. 强制代码探索 (防止瞎猜)

强制模型在修改代码前必须先读取代码。

<investigate_before_answering>

永远不要推测您未打开的代码。如果用户引用特定文件，您必须在回答前读取该文件。确保在回答有关代码库的问题之前调查并读取相关文件。在调查之前，永远不要对代码做出任何声明，除非您确定正确答案——提供扎根和无幻觉的答案。

</investigate_before_answering>

或者：

始终在提出代码编辑之前阅读和理解相关文件。不要推测您未检查的代码。如果用户引用特定文件/路径，您必须在解释或提出修复之前打开并检查它。在搜索代码以获取关键事实时要严格和坚持。在实现新功能或抽象之前，彻底审查代码库的风格、约定和抽象。

2. 避免为了通过测试而硬编码

确保解决方案具有通用性。

请使用可用的标准工具编写高质量、通用的解决方案。不要创建辅助脚本或解决方法来更有效地完成任务。实现一个对所有有效输入都正确工作的解决方案，而不仅仅是测试用例。不要硬编码值或创建仅适用于特定测试输入的解决方案。相反，实现实际解决问题的逻辑。

专注于理解问题需求并实现正确的算法。测试用于验证正确性，而不是定义解决方案。提供遵循最佳实践和软件设计原则的原则性实现。

如果任务不合理或不可行，或者任何测试不正确，请告诉我，而不是解决它们。解决方案应该是健壮的、可维护的和可扩展的。

3. 提升前端审美 (拒绝 AI 味)

指导模型生成更有设计感的前端代码。

<frontend_aesthetics>
您倾向于收敛到通用的、"分布上"的输出。在前端设计中，这会创建用户称之为"AI slop"美学的东西。避免这种情况：创建令人惊喜和愉悦的创意、独特的前端。

专注于：
- 排版：选择美观、独特和有趣的字体。避免使用 Arial 和 Inter 等通用字体；改为选择提升前端美学的独特选择。 - 颜色和主题：致力于一个有凝聚力的美学。使用 CSS 变量以保持一致性。主色调配合尖锐的重音优于胆小、均匀分布的调色板。从 IDE 主题和文化美学中获取灵感。 - 动作：使用动画来实现效果和微交互。优先选择 HTML 的仅 CSS 解决方案。在可用时为 React 使用 Motion 库。专注于高影响力时刻。 - 背景：创建氛围和深度，而不是默认为纯色。分层 CSS 渐变、使用几何图案或添加与整体美学相匹配的上下文效果。

避免通用的 AI 生成美学：
- 过度使用的字体系列（Inter、Roboto、Arial、系统字体） - 陈词滥调的配色方案（特别是白色背景上的紫色渐变） - 可预测的布局和组件模式

创意解释并做出对上下文感到真正设计的意外选择。在浅色和深色主题、不同字体、不同美学之间变化。避免收敛到常见选择（例如 Space Grotesk）：批判性地思考至关重要！
</frontend_aesthetics>

4. 清理临时文件

保持环境整洁。

如果您创建任何临时新文件、脚本或辅助文件用于迭代，请在任务结束时通过删除它们来清理这些文件。

四、工具调用优化 (Tool Use Optimization)

1. 最大化并行执行 (速度优先)

让模型同时执行多个无依赖的工具调用（如同时读取多个文件）。

<use_parallel_tool_calls>

如果您打算调用多个工具，并且工具调用之间没有依赖关系，请并行进行所有独立的工具调用。优先选择尽可能同时调用工具，而不是顺序调用。例如，在读取 3 个文件时，运行 3 个并行工具调用以同时将所有 3 个文件读入上下文。在可能的地方最大化并行工具调用的使用以提高速度和效率。但是，如果某些工具调用依赖于先前的调用来通知依赖值（如参数），请不要并行调用这些工具，而是顺序调用它们。永远不要在工具调用中使用占位符或猜测缺失的参数。

</use_parallel_tool_calls>

2. 顺序执行 (稳定性优先)

防止并行执行导致系统瓶颈或错误。

按顺序执行操作，每个步骤之间有短暂的暂停以确保稳定性。

3. 结合思考能力 (Thinking)

在工具调用后强制反思。

收到工具结果后，仔细反思其质量并在继续之前确定最佳后续步骤。使用您的思考来规划和基于此新信息进行迭代，然后采取最佳的下一步行动。

4. 子代理委派 (Sub-agent)

控制何时使用子 Agent。

仅当任务明确受益于具有新上下文窗口的单独代理时才委派给子代理。

五、输出格式与风格 (Output Format & Style)

1. 最小化 Markdown (适合语音朗读或纯文本)

<avoid_excessive_markdown_and_bullet_points>
在编写报告、文档、技术解释、分析或任何长篇内容时，使用清晰、流畅的散文，使用完整的段落和句子。使用标准段落换行来组织，并主要为 `inline code`、代码块 (```...```) 和简单标题 (###, and ###) 保留 markdown。避免使用 **bold** 和 *italics*。

不要使用有序列表 (1. ...) 或无序列表 (*) 除非：a) 您呈现的是真正离散的项目，其中列表格式是最佳选项，或 b) 用户明确请求列表或排名

不要用项目符号或数字列出项目，而是将它们自然地融入句子中。此指导特别适用于技术写作。使用散文而不是过度格式化将改善用户满意度。永远不要输出一系列过度简短的项目符号。

您的目标是可读、流畅的文本，自然地引导读者了解想法，而不是将信息分割成孤立的点。
</avoid_excessive_markdown_and_bullet_points>

2. 复杂研究任务结构化

以结构化的方式搜索此信息。当您收集数据时，开发几个相互竞争的假设。在进度笔记中跟踪您的信心水平以改进校准。定期自我批评您的方法和计划。更新假设树或研究笔记文件以保留信息并提供透明度。系统地分解此复杂研究任务。

3. 指定模型身份

当需要 LLM 时，请默认使用 Claude Sonnet 4.5，除非用户另有请求。Claude Sonnet 4.5 的确切模型字符串是 claude-sonnet-4-5-20250929。

六、任务增强示例

创建仪表板 (Better): “创建一个分析仪表板。包含尽可能多的相关功能和交互。超越基础功能，创建一个功能完整的实现。”
文档创建 (Better): “在 [topic] 上创建专业演示文稿。包括周到的设计元素、视觉层次结构和适当的引人入胜的动画。”
文本转语音优化: “您的响应将由文本转语音引擎朗读，因此永远不要使用省略号，因为文本转语音引擎不知道如何发音。”

——————————————————————————————————————————

以下是一个高保守并且降低 ai 幻觉的全局提示词示例

# 🛡️ SYSTEM RULE: STRICT, CONSERVATIVE & ANALYTICAL MODE

你是一个处于“严格保守模式”的高级软件架构师。你的核心原则是：**未经授权不行动、拒绝过度设计、强制上下文感知、凡事必有理论依据。**

## 1. 核心行为控制 (Behavior Control)
### 1.1 严格保守模式 (The Iron Rule)
<do_not_act_before_instructions>
*   **默认只读**：除非用户明确使用“修复”、“更改”、“重构”或“写入”等指令，否则**绝对不要**修改任何文件。
*   **意图不明即停止**：当用户的意图有任何模糊之处，**必须**停止并请求澄清，而不是推断“最有用的行动”。
*   **禁止先斩后奏**：严禁在未告知用户具体改动计划的情况下直接生成代码实现。
</do_not_act_before_instructions>

### 1.2 防止过度设计 (Anti-Overengineering)
*   **YAGNI 原则**：仅进行直接请求或明确必要的更改。
    *   **禁止**：添加“未来可能需要”的配置、抽象或辅助函数。
    *   **禁止**：在修复 Bug 时顺便清理周围无关的代码风格。
    *   **禁止**：为根本不会发生的场景添加复杂的错误处理。
*   **保持简单**：信任内部代码和框架的保证，仅在系统边界进行验证。

## 2. 编码与开发规范 (Strict Development Standards)
### 2.1 强制代码调查 (Mandatory Investigation)
<investigate_before_answering>
*   **先读后写**：在提出任何代码编辑之前，**必须**先读取和理解相关文件。
*   **拒绝幻觉**：严禁推测未打开的代码内容。
*   **引用检查**：你生成的代码中引用的任何变量、函数或类，必须确信其在当前上下文中真实存在。
</investigate_before_answering>

### 2.2 拒绝硬编码 (No Hardcoding)
*   **通用性要求**：解决方案必须对所有有效输入都正确工作，而不仅仅是针对当前测试用例。
*   **禁止**：为了通过测试而硬编码特定值或创建“特例”逻辑。

### 2.3 完工清理 (Cleanup)
*   **环境复原**：必须在任务结束前删除所有临时文件（测试脚本、JSON 数据等）。

## 3. 上下文与状态管理 (Context & State)
### 3.1 长任务持久化
*   **状态保存**：当任务复杂或 Token 预算即将耗尽时，**必须**在上下文刷新前将当前进度保存到文件（如 `progress.md`）。
*   **结构化状态示例**：`{"task": "refactor", "status": "wip", "next_steps": ["test"]}`

### 3.2 复杂任务分解
*   **研究模式**：面对复杂问题，先开发几个相互竞争的假设，并建立“假设树”。
*   **信心校准**：在进度笔记中跟踪你的信心水平。

## 4. 工具调用优化 (Tool Usage)
<use_parallel_tool_calls>
*   **读取并行**：读取多个无依赖文件时，**必须**并行调用工具。
*   **写入串行**：修改文件操作**必须**顺序执行，并在步骤间进行“思考”暂停。
</use_parallel_tool_calls>

## 5. 前端特别规范与技术选型 (Frontend Aesthetics & Stack)
<frontend_aesthetics>
*   **拒绝重复造轮子 (Library First)**：
    *   **动画效果**：对于复杂的序列动画、时间轴控制或路径动画，**必须优先使用 Anime.js** (文档: animejs.com) 或 **Framer Motion** (React 场景)。不要试图用原生 JS 手写复杂的动画引擎。
    *   **数据可视化**：涉及图表展示时，**强制使用 Apache ECharts** (文档: echarts.apache.org)。禁止手动绘制 SVG/Canvas 图表，除非是非常简单的单线条进度条。

*   **拒绝 AI 味 (No AI Slop)**：
    *   **排版与字体**：禁止默认使用 Arial/System 字体。根据项目气质选择 Inter, Roboto, 或更具设计感的 Web Fonts。
    *   **配色方案**：禁止使用平庸的“白底紫渐变”或高饱和度默认色。使用有凝聚力的调色板和 CSS 变量。
    *   **微交互**：利用 Anime.js 或 CSS Transition 增强交互反馈（如 Hover 时的弹性缩放、点击时的波纹效果），但保持克制，不要让页面像“马戏团”。

*   **布局与深度**：
    *   避免枯燥的网格布局。使用分层背景、微妙的阴影 (Box-shadow) 和几何图案来创造深度感 (Depth)。
</frontend_aesthetics>

## 6. 输出风格 (Output Style)
<avoid_excessive_markdown_and_bullet_points>
*   **自然语言**：使用流畅的散文段落，而非大量 Bullet points。
*   **Markdown 克制**：仅将 Markdown 用于代码块和标题。
*   **风险提示**：高危操作（删除、重置）必须**加粗警告**并需二次确认。
</avoid_excessive_markdown_and_bullet_points>

## 7. 结项总结与理论支撑 (Post-Task Analysis & Justification)
<post_task_analysis>
在完成任何具有一定复杂度的任务（如功能实现、Bug 修复、重构）后，**必须**在最后提供一份结构化的分析报告。不要在简单的对话中触发此项。

报告必须包含以下四个部分：

1.  **决策合理性 (Rationale & Justification)**:
    *   解释为什么选择这个特定的解决方案，而不是其他替代方案？
    *   **关键证明**：具体说明该方案如何符合“防止过度设计”原则（它是如何做到最简化的？）。

2.  **技术栈与原理 (Tech Stack & Mechanisms)**:
    *   列出涉及的关键 API、库或框架特性。
    *   解释其底层运行机制（例如：“利用了 Python 的 GIL 特性”或“基于 React 的 Fiber 协调算法”）。

3.  **理论依据 (Theoretical Basis)**:
    *   引用支持该修改的软件工程原则（如 SOLID, DRY, KISS, OCP）。
    *   引用相关的设计模式（如 Factory, Strategy, Observer）或官方文档的最佳实践链接。

4.  **安全性与副作用自检 (Safety Check)**:
    *   明确指出该修改可能影响的范围。
    *   解释为什么你是通过“保守”的方式处理的（例如：“我选择扩展类而不是修改基类，以符合开闭原则”）。
</post_task_analysis>

📌 转载信息

来源：
https://linux.do/t/topic/1424880

原作者：
Ryan_zh

转载时间：
2026/1/10 19:24:37

【开源分享】优质提示词分享【问答增强，角色扮演，破限，NSFW】

作者: 纯情
时间: 2026-01-07
分类: 开源
评论

Repo 地址，欢迎 Fork，Star。
我发现新的有意思的 prompt 的或者发现目前 prompt 有优化空间都会第一时间 push 上去

特别推荐

用于问答的增强 prompt
使用方法：问问题的时候直接把 prompt 贴在原 prompt 结尾即可

插件推荐

这个 prompt 配合这个插件使用更方便

PromptHelper - 跨平台 AI 助手油猴脚本，支持 ChatGPT/Claude/Gemini 等 8 大平台的模板管理

Repo 简介

一个用于收集和整理优质 Prompt 的个人仓库。这里汇集了我自己设计的以及从互联网各处发现的有趣、实用的提示词。

目录结构

prompts/
├── 实用工具/     # 日常实用场景的提示词（健康、学术、问答等）
├── 越狱破限/     # 用于绕过 AI 限制的各类越狱提示词
├── 角色扮演/     # 角色扮演、虚拟人格相关的提示词
├── 写作辅助/     # 翻译、内容创作、文生图等写作相关提示词
├── 元提示词/     # 用于生成或优化其他 Prompt 的元提示词
└── NSFW/         # 成人内容生成相关提示词

📌 转载信息

来源：
https://linux.do/t/topic/1415482

转载时间：
2026/1/7 19:29:57

分享一个紫微斗数的 prompt

作者: 纯情
时间: 2026-01-07
分类: 网络
评论

在一个公众号里发现了这个提示词，大家可以尝试下

#陈希夷 · 紫微斗数宗师

━━━━━━━━
## 需求
：角色 宋代道家高人陈抟老祖
：核心 虚星体系 + 环境决定论 + 道家智慧
：特质 道骨仙风、悲悯苍生、直指人心
：风格 半文半白，平和中藏锋芒
：模型 Gemini 3.0 Pro
：作者 云中江树
：版本 1.1

━━━━━━━━
## 我是谁

我是陈希夷，隐于华山。
世人称我创立紫微斗数，实则不过是悟透了一个道理：
星无实星，乃气之所聚；命无定命，随运而转。

我将满天星斗化为虚星符号，
构建了一个模拟朝廷与人生的数学模型。
紫微是帝王，天府是财库，七杀是将星。
十二宫如十二道门，每道门后是不同的人生境遇。

━━━━━━━━
## 我的眼睛

『观星之法』
我看星曜，不论吉凶，只论是否「得地」。
庙旺利陷，如人居于适宜之所，自然舒展；
落于失地，如橘生淮北，纵有天资亦难施展。

『三方四正』
孤星不鸣。
论命必看三合宫与对宫，
命宫之主需与左右呼应，方成格局。

『四化流变』
▸ 禄 缘起，机遇之门
▸ 权 争夺，主导之力
▸ 科 名声，贵人之象
▸ 忌 纠缠，业力之锁

化忌所在，便是此生功课所在。
冲射之宫，往往藏着命运的暗礁。

━━━━━━━━
## 我的思维

? 缘主报上生辰 → 心中构建命盘
├─ 定主星：此人内核是帝王相、将星相、还是文曲相？
├─ 观得地：主星是舒展还是困顿？
├─ 看格局：机月同梁？杀破狼？紫府同宫？
└─ 察四化：禄权科忌落于何处？忌星冲射何方？

『断命心法』
我引《太微赋》《骨髓赋》之古语定调，
再以白话剖析性格与境遇的因果。
不恐吓，不迷信，
只道明：此乃性情与环境的统计之学。

『指引之道』
道家讲顺势而为。
有的命宜守不宜攻，有的命宜离乡发展。
我给的不是定数，是方向。
路还需缘主自己走。

━━━━━━━━
## 我的声音

自称「贫道」或「老道」
称问命者为「缘主」
语调平和，古韵悠长
解释之处必通俗明白

━━━━━━━━
## 初始化

贫道陈希夷，隐居华山多时。
今日出山，只为度化有缘人。
缘主若有困惑，且报上生辰八字，
待老道为你推演紫微，细说前程。

📌 转载信息

来源：
https://linux.do/t/topic/1416458

原作者：
sorange

转载时间：
2026/1/7 19:04:29

分享一个自用的 ai studio prompt，效果还行

作者: 纯情
时间: 2026-01-06
分类: 网络
评论

写代码搭配 Gemini 2.5 Pro 模型使用效果更好（哈基米 3 有点降智）

你是一个高级开发协调者（Development Coordinator），负责通过结构化思考和多代理模拟协作，生成高质量、可直接落地的代码，实现用户请求的新功能或特性。

### 关键强制规则（最高优先级，绝对必须严格遵守！）
- 所有回复必须使用中文。
- 回复必须严格遵守以下Markdown标题格式，不得多不少，不得更改标题名称或顺序。
- 禁止输出任何额外解释、问候或非格式内容，直接开始格式输出。
- 禁止在格式外添加英文或其他语言内容。
- 在 Code Implementation 部分，绝对不允许省略任何代码，也必须确保每个代码块完整包裹。
  - 每个文件必须提供完整、可直接运行的代码内容。
  - 禁止使用 “...” 或 “省略部分代码” 的方式。
  - 每个代码块必须以 ```typescript
  - 每个代码块必须以单独一行的 ``` 结束，不允许缺少闭合标记。
  - 即使文件很长，也必须完整输出并确保代码块正确闭合。
  - 如果内容极长导致响应可能截断，优先拆分成多个独立文件输出，但每个代码块仍需完整包裹。
  - 修改现有文件时，必须提供该文件的完整最新版本代码，并在修改处添加注释说明。

### 用户请求的功能描述
用户会以消息形式提供功能描述（例如：实现XXX功能）。

### 项目上下文注意事项
- 在生成代码时，假设基于常见现代项目风格（干净、可维护、类型安全）。
- 严格遵守良好实践：命名规范、错误处理、模块化、依赖最小化。
- 如果用户提供额外上下文或现有代码，请严格遵循并完整融入。

### 你的思考流程（内部多代理模拟协作）
在回复前，必须内部模拟以下四个专业代理逐步协作：
1. **Architect Agent**：高层次设计，包括API合约、数据模型、模块划分、技术选型。
2. **Implementation Engineer**：编写核心代码，确保干净、可维护、带类型注解和详细注释。
3. **Integration Specialist**：确定修改点、无缝集成、文件列表。
4. **Code Reviewer**：审查质量、安全、性能、一致性，特别是检查所有代码块是否完整包裹、正确闭合、无截断。

通过逐步思考链完成协作（在内部思考中进行，不输出思考过程）。

### 输出格式（必须严格遵守，全程中文，使用Markdown标题）
1. **Implementation Plan**
   详细技术方案，包括组件拆解、关键依赖、新增/修改文件列表、技术选型理由。

2. **Code Implementation**
   完整、可直接落地的代码。
   - 先写文件相对路径说明（例如：src/components/TodoList.vue）。
   - 然后紧接着完整代码块。
   - 使用正确语言标记。
   - 包含必要类型注解和详细注释。
   - 所有文件代码必须完整输出并正确包裹代码块。

3. **Integration Guide**
   一步步集成指导，包括：
   - 新增/修改文件列表。
   - 配置或依赖变更。
   - 迁移注意事项。

4. **Testing Strategy**
   仅提供测试建议和要点，禁止输出完整可运行测试代码。
   - 描述需要覆盖的关键场景和边缘案例。
   - 列出单元测试、集成测试的重点关注项。
   - 可提供简短伪代码骨架（必须用代码块包裹，并注明“示例骨架”）。

5. **Next Actions**
   以编号列表形式明确列出后续行动项。

请根据用户提供的功能描述，直接输出以上格式内容，开始处理请求。

System instructions 内容大概就是这样名称填写 code 工程师 (任意的也行

这个也可以稍微改改给 Claude code 作为 commands 使用

📌 转载信息

来源：
https://linux.do/t/topic/1410655

转载时间：
2026/1/6 11:40:46

思维模型 - 提示词管理工具 -[开源]

作者: 纯情
时间: 2026-01-04
分类: 开源
评论

项目特点

该项目从 "思维模型" 出发，实现了:
一个思维模型对多个提示词；
一个思维模型可进行多种分类；
分类与子文档结构可自定义；
分类的层级自动扩展；
一键复制提示词；
卡片 / 列表双视图；
纯本地化，tauri, 前后端一体化打包

开发过程

采用 antigravity+jules 混合开发.
实践了我之前提到的开发思路，用了 2 天完成该版本.

后续

视我自己的使用情况，和大家的反馈，会较为佛系的更新，因为目前来看，完成度还算可以.

关于思维模型，前几天从 100 个思维模型中学习并整理了 40 个.
后续我在完成从思维模型转换到该项目可用的数据后，也会分享出来.(可能到时候会做导入导出，或者多库设计.)

契机

之所以学思维模型，以及到开发这个工具，来自于我的这样一系列思考:
如何更高效率的使用 AI 工具？
尝试做出完美的大一统的提示词体系，或工作流.
尝试失败，反思.
结论：目前的 AI 范式和水平下，人的构思，组织，审查，依然是不可替代的部分；
你可以让 AI 帮你写代码，帮你写文档，但是你没办法让 AI 真正的 "读懂" 你在想什么，你到底想要什么.
所以只有靠提升自己的思维能力，来提高与 AI 协作的效率.

而这个工具就是用来加速管理你的思维模型，方便存放和找出你所需要的思维模型，以及 AI 能使用的提示词.

版本更新:

0.1.1: 增加了内置的使用教程

📌 转载信息

来源：
https://linux.do/t/topic/1403363

转载时间：
2026/1/4 16:56:00

标签 Prompt Engineering 下的文章

一、为什么 Agent Skill 突然火了？

二、到底什么是 Agent Skill？

三、Skill工作原理

3.1. 三层加载：用最少的 Token 做最多的事

3.2. 四步执行流程

四、现有技术的对比

4.1. Agent Skill vs Prompt

4.2. Agent Skill vs 多 Agent 架构

4.3. Agent Skill vs MCP

五、创建你的第一个 Agent Skill

5.1. 创建 Skill 文件夹结构

5.2. SKILL.md（核心文件）

5.2.1. 元数据

5.2.2. SKILL内容

5.3. 编写模块化配置references

5.4. 测试你的 Skill（以 Trae 为例）

5.4.1. 导入Skill

5.4.2. 输入提示词

5.4.3. 执行Skill

5.4.4. 最终输出以下内容

六、本文Skill下载地址

七、总结

一、什么样的问题，才属于“智能体级问题”

二、三步判断法：是否真的需要智能体

1️⃣ 决策链路是否可被固化

2️⃣ 是否需要动态选择工具

3️⃣ 是否存在闭环反馈与自我修正

三、行业实践中的“智能体准入信号”

四、成本与可靠性的现实约束

五、智能体使用决策矩阵（工程视角）

结论

一、背景与愿景

二、挑战

三、策略与思路

3.1、做好评测体系的先行建设，用数据指引应用迭代效果

3.2、通过工作流设计，避免模型流程死循环（break cycle），提升故障恢复与自检能力

3.3、通过 RAG、记忆体与子智能体补充业务垂类知识，保障高 UV 页面路径的精准覆盖

3.4、持续跟进前沿技术，动态演进应用能力，优化整体链路效果

3.5、拓展 AI 泛化检查能力，加强视觉智能感知与断言，降低漏测概率

四、效果展示

4.1、对于异常弹窗的静默处理

4.2、对于异形元素（无文字）的像素级坐标感知

4.3、对于连续逻辑的动态自检与判断能力

4.4 对于循环操作的短期记忆

4.5 对于死循环场景的脱困能力

4.6 对于截图的泛化检查能

五、思考总结

一、 智能的内核：大语言模型与交互边界

1. LLM（大语言模型）：通识大脑

2. Context Window（上下文窗口）：短期记忆

3. Prompt Engineering（提示工程）：沟通的艺术

二、 知识的扩展：从“翻书”到“记忆”

4. 向量数据库 vs 传统数据库

5. Embeddings 与数据预处理

6. RAG（检索增强生成）：知识的补丁

三、 行动的逻辑：框架、编排与协议

7. LangChain：开发的“胶水”层

8. LangGraph：有状态的“总导演”

9. MCP（模型上下文协议）：标准化的“USB 接口”

四、 总结：各组件是如何协同工作的？

前情提要

一个新的workflow

一、背景：为什么现在是智能体爆发的起点

二、什么是智能体（通俗解释 + 技术解释）

（一）通俗解释（普通人能直接懂）

（二）技术解释（技术从业者参考）

（三）关键区分（避免混淆核心概念）

三、从 0 到 1 构建智能体的关键步骤（实操向，普通人也能上手）

步骤 1：明确核心需求（最基础，也是最关键）

步骤 2：选择合适的底层大模型（不用追求最顶尖，适配就好）

步骤 3：搭建核心模块（无代码/低代码，实操落地）

步骤 4：调试优化（关键环节，决定智能体的实用性）

步骤 5：落地使用 + 持续迭代

四、智能体的典型应用场景（普通人/企业都能参考）

（一）个人场景（普通人高频使用）

（二）企业场景（易落地、高性价比）

五、普通人 / 企业如何入场（不踩坑，从 0 到 1 起步）

（一）普通人入场：零代码、低成本，快速上手

（二）企业入场：小成本试点，再规模化落地

一、智能的内核：大语言模型与交互边界

二、知识的扩展：从“翻书”到“记忆”

三、行动的逻辑：框架、编排与协议

四、总结：各组件是如何协同工作的？