一个提示词搞定复杂功能：Simon Willison 的 Agentic 工程实践

起因：一个常见但棘手的需求

Simon Willison 遇到了一个许多内容创作者都会面临的问题：他需要将博客上新增的“beats”（一种聚合外部动态的内容类型）整合到每周的邮件通讯中。这并非一个简单的“添加字段”任务，它涉及到理解新内容类型的逻辑、筛选规则（只包含有描述的 beats），并与现有工具（blog-to-newsletter）的生成流程对接。对于开发者来说，这通常意味着需要阅读新功能的代码、理解数据流，然后修改工具——一系列繁琐的步骤。

拆解：提示词的“魔法”在哪里？

然而，Simon 只用了一个由三句话组成的提示词，就通过 Claude Code 在一次交互中完成了所有工作。这个提示词的精妙之处在于它完美诠释了 Agentic 工程 的核心思想：不是用自然语言描述你想要什么，而是用代码和操作指令来引导AI理解上下文并执行。

1. Clone simonw/simonwillisonblog from github to /tmp for reference：这是最关键的第一步。他没有试图用语言解释“beats”是什么、数据结构如何，而是直接让AI去克隆包含该功能源代码的仓库。这相当于把“需求说明书”直接递给了AI，并且特意指定克隆到 /tmp 目录，避免了后续代码提交的混乱。这揭示了与编码代理协作的一个高效范式：让AI自己去读代码来理解需求，比你费尽口舌描述更准确、更全面。

2. Update blog-to-newsletter.html to include beats that have descriptions - similar to how the Atom everything feed on the blog works：这一句完成了任务指派和逻辑定义。首先，明确指定了要修改的文件（blog-to-newsletter.html），在拥有200多个文件的仓库中精准定位。其次，对于“哪些beats需要包含”这个核心业务逻辑，他没有自己定义，而是引用了博客上已有的 Atom feed 的实现逻辑（“similar to how... works”）。这又是一个高明之处：复用系统中已有的、经过验证的逻辑，避免了重新发明轮子和可能产生的误解。 AI 只需要去阅读 Atom feed 的生成代码，就能完美复现筛选规则。

3. Run it with python -m http.server and use uvx rodney --help to test it...：最后一部分是验证指令。他不仅要求AI修改代码，还给出了具体的本地运行和测试方法，并指定了对比基准（与网站首页内容一致）。这形成了一个完整的“开发-测试”闭环，确保了交付物的质量。

趋势洞察：Agentic 工程正在重新定义开发者工作流

这个案例远不止是一个聪明的提示词技巧。它象征着一种正在兴起的 Agentic 工程模式。在这种模式下，开发者与AI的关系从“程序员与代码生成器”转变为 “架构师与具备代码阅读和执行能力的实习生”。

• 沟通语言的转变：最高效的沟通不再是自然语言，而是代码本身。通过让AI克隆仓库、引用特定文件和现有逻辑，开发者利用代码库作为最精确的“需求文档”。
• 工作重心的转移：开发者的核心工作从“编写实现代码”前移到 “设计任务、提供上下文、验证结果”。Simon 花时间思考的是“如何向AI描述这个问题”，而不是“如何用JavaScript实现这个功能”。
• “一次性”交付成为可能：当上下文提供得足够精准（完整的代码库+明确的参照逻辑），复杂的、跨文件的功能修改确实可以在单次提示中完成。这极大地提升了开发效率，将过去可能需要数小时甚至数天的“理解-编码-调试”循环压缩到了分钟级别。

实用价值与反常识

对于读者而言，这个案例的实用价值在于提供了一套可复用的方法论：

• 当你需要AI帮你修改或扩展一个现有项目时，第一步永远是让它获得完整的代码上下文（如克隆仓库）。
• 尽量引用项目内已有的模式或逻辑作为你新需求的范例，这比你自己重新描述一遍要可靠得多。
• 为AI提供明确的验证步骤，让它能自己检查工作成果。

一个可能反常识的点是：最强大的提示词往往不是最长的、最详细的那个，而是上下文给得最准的那个。 Simon 的提示词很短，但它通过两个关键动作（克隆代码、引用现有逻辑）为AI注入了极其精准的上下文，从而释放了AI强大的代码理解和生成能力。这提示我们，在Agentic时代，“如何为AI搭建舞台”比“如何对AI耳提面命”更重要。

---

原文地址: Adding a new content type to my blog-to-newsletter tool