<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>prompt-engineering on </title>
    <link>/tags/prompt-engineering/</link>
    <description>Recent content in prompt-engineering on </description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en</language>
    <lastBuildDate>Thu, 21 May 2026 22:00:00 +0800</lastBuildDate><atom:link href="/tags/prompt-engineering/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>读《Structured Prompt-Driven Development》：把 prompt 当一级交付物的几点笔记</title>
      <link>/reading/martinfowler/structured-prompt-driven-spdd/</link>
      <pubDate>Thu, 21 May 2026 22:00:00 +0800</pubDate>
      
      <guid>/reading/martinfowler/structured-prompt-driven-spdd/</guid>
      <description>背景：我为什么会去读这篇 整理 Agentic Workflow 那篇笔记时，我反复卡在同一个问题上：**当 AI 真的开始替我写代码，&amp;ldquo;需求&amp;quot;和&amp;quot;设计&amp;quot;这两件事到底应该长成什么样？**Spec Kit、AGENTS.md、ADR 都能算是答案，但它们各自只覆盖了一部分。
正好在 Martin Fowler 的网站上看到 Wei Zhang 和 Jessie Jie Xia（两位都来自 Thoughtworks）2026-04-28 发的这篇 Structured Prompt-Driven Development。文章的核心主张比较干脆：把 prompt 当成与代码同级的工程工件管理——版本化、评审、复用、迭代。
这条主张其实不新，但作者把它具体化成了一组流程、一份七维度模板和一套配套 CLI（gszhangwei/open-spdd），加上一个完整示例项目（gszhangwei/token-billing），值得花时间读完整理。
关于 SPDD 与 PDD、Spec Kit、PromptOps 这些相邻概念的差别，我另起了一篇速写：prompt-driven vs spec-driven：把 PDD、SPDD、Spec Kit 几支理清楚。本文只聚焦 SPDD 这一篇文章本身。
这篇文章不是教程，是我读完后留下的几条笔记 + 对照我自己经验的取舍判断。
文章主张：prompt 是一级交付物 文章开头给的一句话很直接：
Instead of relying on ad hoc chats, SPDD turns prompts into assets that can be: version controlled, reviewed, reused, and improved over time.</description>
    </item>
    
    <item>
      <title>我怎么理解 AI Agent Skills：规范、实证，以及落地时的取舍</title>
      <link>/posts/agent-skills-spec-and-evals/</link>
      <pubDate>Wed, 06 May 2026 10:00:00 +0800</pubDate>
      
      <guid>/posts/agent-skills-spec-and-evals/</guid>
      <description>至少从 2025 年下半年到我写这篇（2026-05-06）这段产品叙事看，&amp;ldquo;Agent Skills&amp;quot;是一个在 AI 工具圈快速升温的概念：Anthropic 在 Claude / Claude Code 里推它，Cursor、GitHub Copilot、Gemini CLI、OpenCode、Goose、Roo Code 等一批工具也陆续宣布支持，agentskills.io 则把它整理成了一个开放标准。至少在叙事层面，它确实有点像 AI 工具圈想长出来的一个&amp;quot;USB-C 接口&amp;rdquo;。
但热闹归热闹，更冷静的那一面是：skill 真的有用吗？什么时候有用？怎么知道它有用？ 这一篇我把三份资料串起来聊一下：
agentskills.io 给出 skill 的开放定义和加载机制； SWE-Skills-Bench 用基准实测提醒我们：公开 skill 在真实仓库里未必会带来增益； Angular 社区开发者 Daniel Sogl 那篇 Skills Without Evals Are Just Markdown and Hope，把 skill 的两种隐性失败模式说得很透。 我现在更愿意把 skill 拆成两个层面来看：规范层面，它解决的是上下文如何按需分发；工程效果层面，它解决的是这份指令包能不能在你当前仓库里产生净增益。 前者解释它为什么会流行，后者决定它值不值得进你的工作流。
Agent Skills 是什么 按照 agentskills.io 的定义，一个 skill 本质上就是一个文件夹 + 一个 SKILL.md：
my-skill/ ├── SKILL.md # 必需：metadata + 指令 ├── scripts/ # 可选：可执行脚本 ├── references/ # 可选：参考文档 ├── assets/ # 可选：模板、资源 └── .</description>
    </item>
    
  </channel>
</rss>
