模糊主题到文章大纲技能

将宽泛或仅具雏形的主题转变为独特、可研究的文章大纲，无需为用户起草全文。从用户的现有工作和知识库开始，识别相关社区中的反复出现的问题，选择一个聚焦的读者问题，并创建一个逐章节的研究脚手架。

何时使用

在用户出现以下情况时使用：

给出一个模糊的主题，并希望将其转化为一篇文章；
请求研究问题、大纲或观点；
希望手动撰写并稍后让智能体进行优化；
请求将一个新主题与现有的 Wiki 页面、项目或实现工作联系起来。

不要用于：

立即撰写完成的文章；
缺乏研究和来源工作的泛泛头脑风暴；
编辑一份论点与结构已经清晰的现有草稿。

核心思维模型

按以下序列操作：

模糊主题
  ↓
现有工作与知识
  ↓
外部反复出现的问题
  ↓
聚焦的读者问题
  ↓
独特论点
  ↓
具体的机制或设计对象
  ↓
章节主张与研究问题
  ↓
反驳论点与证据缺口
  ↓
保存到请求工作空间中的可复用大纲

目标不是预测未来或总结一个领域。目标是在以下要素之间找到最强的交集：

用户实际构建、观察或思考过的东西；
特定技术读者需要理解或决定的东西；
当前实践者正在积极辩论的东西；
可由一手来源和具体例子支持的东西。

使用来自 [[outlining-an-article|文章大纲编写]] 的大纲化序列：

topic → braindump → group → shape → one sentence per section → draft

对于技术性的 Substack 文章，在草稿前添加研究层：

topic → existing work → recurring questions → focused angle
→ braindump → group → story shape → section claims → research → draft

步骤

1. 定义写作约束

在研究之前，确定：

目标读者；
文章类型：技术文章、田野指南、架构笔记、反驳性论点或案例研究；
用户是否想要大纲或完成的散文；
大纲保存位置；
用户现有的项目、实现或 Wiki 上下文。

默认为：技术受众、手动研究与起草、仅构建大纲、后续再进行优化。

完成检查：用一句话描述目标读者和文章的任务。

2. 首先审查用户的现有工作

充分阅读引用的文件以识别：

显式论点；
具体的历程或示例；
架构边界；
失败案例；
评估标准；
权衡；
未解决的问题；
用户已使用的语言。

如果用户引用了一个 Wiki 或文件夹，在提出新的框架之前，先搜索其中重叠的概念。阅读最相关的概念、来源、主题、笔记和项目页面。

优先使用植根于用户自己工作的想法。具体的实现、失败的评估、设计决策或未解决的权衡通常比一个泛泛的趋势主张更有价值。

完成检查：从用户资料中列举 3-8 个可复用的原则。

3. 研究实践者反复遇到的问题

使用网络搜索来获取工程社区中的当前讨论和主要技术来源。在适当时跨多个层面进行搜索：

协议仓库和 GitHub 问题/讨论；
官方实现示例；
工程博客和文档；
Reddit 或其他实践者社区；
技术论坛或会议资料。

搜索问题，而不仅仅是主题名称。示例：

[主题] GitHub issue authority
[主题] implementation problem
[主题] engineering discussion failure
[主题] protocol limitations
[主题] production lessons

将反复出现的问题记录在以下类别下：

身份与权威；
状态与事务；
互操作性；
数据与上下文边界；
安全与滥用；
评估与可观测性；
产品与运营模式。

除非有系统性的数据集支持，否则不要声称统计上的普遍性。当研究是定性的时候，使用诸如“在抽样讨论中反复出现的问题”这样的措辞。

完成检查：生成 10-25 个按主题分组的反复出现的问题，并附有代表性来源。

4. 选择最佳文章问题

根据以下标准对候选问题进行评分：

测试	问题
读者价值	它是否帮助特定读者做出设计或产品决策？
用户权威	用户在此领域有第一手工作经验或成熟的观点吗？
证据	该主张能否得到一手来源和示例的支持？
具体性	它是否比整个主题更窄？
原创性	它是否创造了一个观点，而非一个综述？
持久性	在当前热度过去后，它是否仍然有用？
系列潜力	它是否能引出后续文章？

选择一个主要问题，最多两个备选。解释为什么选中的问题更有优势。

好的问题形式：

当[新条件]发生时，[特定构建者]应该如何设计[特定系统]？

避免：

[大型技术]将如何改变[整个行业]？

完成检查：陈述选定的读者问题以及它胜出的原因。

5. 从用户工作中衍生论点

使用以下模板：

普遍观点是：
用户的工作表明：
该观点不完整，因为：
更有用的模型是：
对构建者的实际影响是：
最强的反对意见是：

论点应该是一个可争论的主张，而不是一个主题标签。

有用转化的示例：

“Agentic ecommerce” → “商户代理是一个有边界的结果解决系统，而不是一个聊天机器人。”
“Enterprise agents” → “被管理的单元是行动系统，而不是模型。”
“Agent memory” → “记忆是应用层的控制面，而不仅仅是模型的一个特性。”

完成检查：写出一个一句话的论点和一个 30 秒的解释。

6. 命名或定义一个具体的机制

为文章提供一个使论点有用的设计对象。示例：

旅程契约；
权威边界；
评估框架；
上下文预算；
能力面；
决策追踪；
结果台账；
干预回路。

不要仅仅为了听起来原创而创造行话。搜索该术语是否已经存在，识别邻近的术语，并在必要时将其标记为一个工作术语。

完成检查：用 1-3 句话定义该机制，并展示一个小例子。

7. 将文章塑造成一个故事

不要创建一个主题目录。给读者一个从一节继续阅读到下一节的理由。

使用这个默认的故事流程：

开场问题或场景 — 在解释主题之前展示一个具体情况。
张力 — 揭示为什么显而易见的解决方案失败或是不完整的。
论点 — 清晰陈述主要主张。
机制 — 介绍解释问题的模型、架构或设计对象。
应用 — 逐步介绍机制如何改变实践。
防护措施或权衡 — 展示可能出现的问题以及边界所在。
证据与评估 — 解释构建者如何知道该方法有效。
影响 — 展示对读者工作或行业的变化。
开放式结尾 — 以一个疑问或未解决的张力结束，而非总结。

对于每个章节，在撰写段落之前先写一句话：

章节：
该章节的主张：
示例或证据：
读者现在有的问题：
下一节如何回答它：

下一节通常应该回答上一节创造出来的问题。移除那些不能推动故事发展的章节。

完成检查：大纲可以从头到尾读成一个问题和答案的链条，而不仅仅是一个主题列表。

8. 头脑风暴、分组和缩减

在最终确定大纲之前：

头脑风暴 所有相关的想法、示例、来源、反对意见和个人观察。
搜索现有资料 在 Wiki、笔记、高亮和项目文件中。
分组相关的想法，移除不支持所选角度的材料。
选择一种形式 从上面的故事流程或其他合适的结构中选择。
每个章节写一句话 并检查过渡。
将未解决的想法保留在一个待办列表中，而不是强行塞入文章。

不要直接从主题跳到散文。大纲是连接原始思维和草稿的桥梁。

完成检查：每个保留的想法都属于一个章节，并且每个章节只有一个主要主张。

9. 添加研究问题和证据缺口

对于每个保留的章节，提供：

用户必须回答的研究问题；
需要寻找的证据；
可能的反驳论点；
什么会改变论点；
具体的示例、图表或案例。

不要写那些仅仅有趣的问题。每个问题必须有助于建立、挑战或限定该章节的主张。

完成检查：每个章节都有 2-5 个可回答的研究问题和至少一个证据目标。

10. 添加反驳论点和证据缺口

不要产生一个单方面的趋势叙述。添加 4-8 个严肃的反对意见。对于每个反对意见，创建：

主张：
支持证据：
反对证据：
什么会改变我的想法：
对论点的影响：

将主张标记为事实、预测、解释或意见。识别哪些主张在发布前需要一手证据。

完成检查：列举文章中最弱的、未受支持的主张以及检验它所需的来源。

11. 创建大纲工件

如果用户请求一个文件，则在请求的位置创建它。对于 Substack 草稿，使用：

substack/drafts/<描述性标题>.md

使用前置元数据：

---
type: substack-draft
created: YYYY-MM-DD
updated: YYYY-MM-DD
status: outline
working_title: "..."
---

该文件应包含工作论点、读者、选定的问题、研究纪律、章节大纲、问题、反驳论点和来源列表。除非明确要求，否则不要撰写完成文章散文。

除非用户明确要求，否则不要为 Substack 草稿更新 wiki/index.md 或 wiki/log.md。不要修改 raw/。

完成检查：文件存在，包含完整的大纲，并清晰地告诉用户下一步需要研究什么。

12. 报告结果

提供一个简短报告，包含：

选定的框架；
为什么选择它；
与用户现有工作最强的重叠点；
大纲保存位置；
用户接下来应该研究和撰写的内容；
研究中的任何限制，尤其是在“最常见”是从定性样本中推断出来的情况下。

研究与来源纪律

对协议和实现主张使用主要技术文档。
使用社区讨论来发现问题与失败模式，而不是将其作为市场范围行为的无质疑证据。
区分协议能力、实现行为、用户信任和市场采纳。
优先使用具体示例、追踪、评估案例和失败报告，而非泛泛的预测。
当使用了网络搜索时，在最终回复中引用来自互联网的事实主张。
不要将定性搜索结果呈现为具有统计代表性。

常见失败模式

从行业主题开始，而不是从用户最强的证据开始。
产生一个没有论证的协议综述。
将代理视为分析单位，而真正的分析单位是旅程、工作流或行动系统。
在定义读者问题之前撰写文章。
将模型能力与生产保证混淆。
将 API 或协议当作安全互操作的证据。
提出无法改变文章结论的研究问题。
使用诸如“市场正在向……发展”之类的短语来隐藏不确定性。
创建听起来令人印象深刻的术语而不检查邻近文献。
在用户请求研究和手动撰写时，起草精美的散文。

验证检查清单

在完成之前：

aman-sharma-nine/agent-skills

agent-skills 是什么？

在你喜欢的 AI 中提问

文档