把 Prompt 当作代码：内容工程师的 AI 工作流

Source: Pulumi Blog

要为您提供准确的翻译，请将您希望翻译的完整文本粘贴在此处（包括正文、标题、列表等），我将保持原始的 Markdown 格式并只翻译内容部分。谢谢！

Source: …

AI 真正解决的问题

大家都在说 AI 能让你更快。这并没有错，但这并不是最有趣的部分——至少对我来说不是。

最有趣的部分是它对起始问题的影响。我有 ADHD 脑（虽未正式诊断，但自我认知足以了解情况）。我知道这对我处理大多数任务的关系意味着什么：我能看到问题，理解它，想要解决它，但随后启动的沉重负担会把我压垮。

当我在某个任务上卡住时，问题几乎从来不是我不知道该怎么做。问题在于我的大脑试图在工作记忆中同时保持整个完成品的全貌并产生第一步。这是巨大的认知负担，对 ADHD 脑来说常常是难以逾越的。

用对话的方式讨论问题则是完全不同的认知负荷。我可以对 Claude 说：

“这里是问题，这里是我想要实现的目标，这里有什么奇怪的地方。”

然后我不再盯着空白页。我进入了一段对话。脚手架已经存在，我可以在其上构建。

这种动态对我来说并不新鲜。在之前的微软撰写培训模块的工作中，我的一些最佳作品不是因为工作容易，而是因为我有一个合作者——一个可以一起思考、一起大声说出“好吧，我们到底想表达什么？”的朋友。那种对话式的脚手架是从原地打转到顺利交付的关键。

在我目前单枪匹马的岗位上，AI 成了那个合作者。

这并不完全是一个生产力的故事。
更接近于认知适配的故事。我敢打赌，很多人——无论是否被诊断——都会对我所描述的情形产生共鸣。

将提示视作代码

如果对话脚手架能够降低我的激活能，接下来的问题显而易见：我能为所有需要它的人构建这种工具吗？

我知道我想用 AI 来解决这个问题，但我不想只写一堆一次性的提示。这会导致维护噩梦，而且无法超出我个人使用的规模。我需要一个系统。

Claude Code 将这些可复用的提示称为 skills——其他平台也有类似的概念，叫做 plugins 或 extensions。

第一次实验：/docs-review

• 一个可复用的提示，在我提交之前，用一套一致的标准审阅我的文稿。
• 没有什么花哨的，我只想要一个可靠的基准，不受我的情绪或咖啡摄入量的影响。

随后我想到：我们文档仓库的每个 PR 都应该自动运行这个检查。于是我把它接入了我们的 CI/CD 流水线。

我的经理 Meagan 很喜欢它——几周后她注意到 PR 的质量显著提升。几乎每个 PR，贡献者都会在自动审阅发布后立刻自行提交一个 “Addressing feedback” 的 commit——在我看到 PR 之前就捕获并修复了问题。

就在这时，我恍然大悟：我不再是在写提示，而是在写模块——可复用、可组合的我的专业知识块。

集中上下文

这个洞见很直接，却改变了我对整个系统的思考方式：

• 如果多个 skill 需要相同的上下文——我们的风格指南、审阅标准、内容规范——这些上下文应该 集中存放，并被所有需要它的地方共享。
• 可以把它想象成软件项目中的 共享库。

我创建了一个 REVIEW-CRITERIA.md 文件，作为 Pulumi 文档 PR “好评审” 的 唯一真相来源。每个进行审阅的 skill 都会从中读取。只需修改一次，所有相关功能即可同步升级。

同样地，我们的风格指南、Hugo 约定、导航结构——全部存放在中心参考文件 中，任何 skill 都可以调用。

为什么这很重要

• Token 效率：在多个 skill 中重复上下文会快速膨胀 token 使用量。模块化可以保持精简。
• 成本：你的 CI/CD 流水线不在乎优雅，但它绝对在乎成本。

我反复回归的思维模型是：不要重复自己（DRY）。这正是让优秀软件易于维护的原则，同样也让优秀的 AI 工作流易于维护。

技能目录

从那时起，系统自然地成长起来。每当我发现自己重复做某件事时，我就会问自己：“我能把它变成一个技能吗？”

以下是它产生的一些示例：

（列表会随着新需求的出现而继续扩展。）

要点

1. 将知识打包 成可重用、受版本控制的资产（技能、Markdown 参考文件）。
2. 尽可能自动化——将技能挂接到 CI/CD，以在大规模下强制一致性。
3. 集中 共享上下文，以降低令牌使用并简化维护。
4. 把 AI 提示视为代码：模块化、可测试且可重用。

通过将临时提示转化为技能库，我把单人瓶颈转变为可持续、可扩展的文档工作流，Pulumi 的任何人都可以使用。

摆脱累计的技术债务

• /new-doc 和 /new‑blog‑post – 为任何人提供添加新文档或博客文章的指南，包括正确的位置、元数据和导航连接。工程师、营销人员，任何人都可以。贡献的门槛显著降低。
• /docs‑tools – 帮助其他仓库用户发现这些工具的存在。可发现性是内部工具的一个真实问题。

Slack 集成

Slack 的内置 Claude 集成并不是运行你的 Claude Code 工作流的同一个 Claude——它们不共享上下文或自定义指令。如果你想在两个界面之间保持一致的标准，需要自行提供后端。这正是 /slack‑to‑issue 所处理的。

社区贡献

其他人开始向仓库贡献技能——不是因为我请求，而是因为这个模式足够清晰，易于扩展。

• 有人为 SEO 分析构建了一个技能。
• 市场部门添加了他们自己的评审标准。
• 工程师贡献了我从未想过要构建的工作流。

我原本作为个人生存工具构建的东西已经成为了一个共享平台。这是因为我把提示视作代码：模块化、可复用、文档化、开放供他人贡献。

诚实的局限性

• 不是人类判断的替代品。 这些是概率工具——它们大多数时候是正确的，但并非全部正确。/pr‑review 并不会自行批准 PR。它会标出问题，然后让人类的我去阅读并做出决定。AI 完成第一次审查，我完成最后一次。
• 系统也并未完成。 它可能永远都不会真正完成。我仍在微调审查标准，仍在发现技能产生奇怪结果的边缘案例，仍在随着新痛点的出现添加新工具。把提示当作代码来对待，就等于把它们当作软件来对待：发布、迭代、维护。没有所谓的 1.0 版完成。
• ADHD 真实存在，但它不是魔法。 仍然会有日子里瘫痪占上风。AI 降低了启动的激活能量，却并未消除它。我仍然是必须出现的人。我可以把这也自动化，但那样我们就会进入完全不同的反乌托邦。

Lessons to Share

1. 了解你的模型及其成本。

   • 在 Pulumi 我们主要使用 Claude，我在 Claude Code 工作；对于大多数任务，我更倾向于使用 Sonnet 而不是 Opus。
   • Opus 很强大，但费用显著更高，而精心编写的针对 Sonnet 的指令能够同样高效地处理我绝大多数的工作。

2. 把它当作同事来对待。

   • 不要只下达指令然后等输出。要询问它的想法。出现错误时要提出质疑。解释你的推理过程。
   • 你越是以对话的方式互动，结果往往越好。
   • 对齐很重要：在深入复杂任务之前，先一起讨论实现思路。前期几分钟的对齐胜过在误解的规格上反复迭代。

3. 在合适的地方加入个性。

   • 我在配置中加入了个人指令——比如在我假装自己是皮卡尔船长时配合演出，或在上下文需要时使用丰富的语言。（是的，这些都是字面上的配置项。）
   • 听起来轻浮，但如果你真的喜欢使用某个工具，你就会主动去用它，而不是回避。

4. 将工作流模块化。

   • 不要写一个巨大的单体提示去尝试完成所有事情。
   • 将其拆分为专注的技能，每个技能只做好一件事，并通过中心引用文件共享公共上下文。这样更易维护、更易调试、运行成本更低。

5. 对提示进行版本控制。

   • 你的技能就是代码。像对待代码一样对待它们。提交、审查、迭代。
   • 如果某个技能在一次微调后产生了奇怪的输出，你需要知道到底改动了什么。

6. 考虑 token 消耗率。

   • 这在 CI/CD 自动化运行时尤为重要。
   • 保持技能聚焦——检查代码风格的技能不需要加载你的 Hugo 导航约定。模型只会读取你提供的内容，所以只给它需要的内容。

7. 并非所有内容都必须是提示。

   • 技能可以包含脚本，而这往往是正确的做法。
   • 示例：当我的团队在仓库中移动文档时，需要使用 git mv 来保留历史，并在 front‑matter 中添加重定向别名以防 404 并保护 SEO。这是已经解决的问题，所以它是一个脚本。技能只需要知道脚本的存在及其作用。Claude 负责编排，脚本负责执行。

8. 并非所有内容都必须是生成式的。

   • 如果需要确定性的输出，就不要使用概率性的工具。
   • 我们有一个生成博客文章元图的技能——它是过程化的，而非生成式的。没有 AI 生成的图像。该技能以编程方式遵循我们的视觉标准，每次都产生一致的结果。

接下来

下一个前沿是将部分工具引入团队中技术水平较低的成员——尤其是营销人员。我所构建的技能假设使用者对终端和代码仓库有一定的舒适度。这对工程师来说没问题，但对其他人来说却是障碍。一个友好的界面可以显著降低这道门槛——这正是我目前正在探索的方向。

如果你是技术写作者、开发者倡导者，或是独自探索 AI 如何融入工作流的从业者，本文描述的方法是一个坚实的起点。

• 工具固然重要，但思维模型更关键：把你的提示当作代码来对待。
• 让它们可复用。
• 为它们编写文档。
• 与他人分享。

我们的文档仓库是公开的，任何需要这些技能的人都可以获取。如果你正在构建类似的东西，尽情借鉴——或者回馈贡献。

空白页仍然存在，只是当你拥有一个优秀的协作者时，它就不再那么令人生畏。