x-bookmark-quote-posts

X 书签引用帖

概览

将用户最新的 X 书签整理成带日期的引用帖队列。输出应让人感觉像某个具体的人或品牌基于亲身经历公开分享想法，而不是泛泛的 AI 评论。

开始

除非用户指定其他仓库，否则使用当前内容仓库。如果当前没有活动仓库，请先询问目标工作区，再写入文件。

开始收集前：

• 阅读 AGENTS.md（如果文件存在或已在提示中提供）。
• 尽早检查 git status --short。内容工作区通常有未提交的改动；请将变更限制在必要范围内。
• 如果存在最新的书签引用帖文件，请阅读以保持连贯性。常见位置包括 data/x-growth/bookmark-quote-posts/*.md、data/x/bookmark-quote-posts/*.md，或用户指定的内容队列。不要将生成的草稿作为主要的语气参考。
• 仅使用 Codex 应用内浏览器访问 X。不要使用 Chrome。
• 不要在 X 上发帖、回复、引用、点赞、转推、发送私信、关注或进行任何更改。

如果 X 已退出登录、被 CAPTCHA 拦截，或应用内浏览器无法连接，请停止并报告具体阻碍。只有当浏览器会话要求用户登录时，才请用户登录。

根据 100 条帖子校准语气

收集书签前先校准语气。根据请求或当前 X 个人资料确定目标账号，然后打开该账号和 X 的 Latest 搜索：

https://x.com/<handle>
https://x.com/search?q=from%3A<handle>&src=typed_query&f=live

如果 X 提供了足够的历史记录，收集最新的 100 条原创帖子。包括原创帖、回复和引用帖；排除由他人撰写的纯转帖。对每条帖子，保留：

• 原创帖子的网址和时间戳
• 完整的原创文本
• 是否为回复，以及是否包含引用来源
• 引用帖的引用来源网址
• 时间线中的文本是否被截断

直接展开每条被截断的原创帖子。如果 X 阻止完整展开，请报告不完整的数量，不要默默将片段当作完整帖子。如果少于 100 条原创帖子可用，则使用所有可用帖子，并报告实际样本数量和日期范围。

根据完整语料建立内部语气记录：

• 通过回复了解自然用词、大小写习惯、缩写、句子节奏、表达异议的方式和不拘一格的风格。
• 通过独立帖子了解开场、段落长度、节奏、列表、论据和结尾。
• 将引用帖作为格式特定的权威参考，了解用户如何回应来源并补充背景。
• 区分可复用的模式和一次性内容，例如粘贴的提示词、文字记录、链接堆砌或异常冗长的公告。保留其中的事实信息，但不要让它们决定常规节奏。
• 进行实际统计，而不是凭空假设：样本数量和日期范围、格式构成、中位长度、常见段落数、第一人称使用频率、列表使用情况，以及反复出现的开头和结尾方式。
• 匹配表达方式，而不是照搬具体措辞。绝不要拼接多条帖子中的片段来撰写草稿。

将最新的 100 条原创帖子作为主要语气来源。仅将之前生成的草稿用于保持队列连贯性。如果实时语气证据与下方通用起草默认规则冲突，以实时语料为准。

收集书签

打开：

https://x.com/i/bookmarks

从最新可见的书签信息流中收集一批数量有限的内容：

• 提取作者、用户名、来源 URL、来源时间戳、可见帖子文本、文章卡片标题/摘要，以及媒体/上下文线索。
• 默认收集过去 30 天内书签信息流中的来源帖子，除非用户指定其他时间范围。按字面处理当前日期/时间和时区。
• 适当滚动，在 30 天的时间范围内收集约 12-20 条可用候选内容，同时控制收集范围。
• 收录实用的资源列表类书签，不要只收录关于 AI Agent 的观点。例如，Solt Wagner 风格的创意资源、网站和应用列表，其中包括图像生成器、抖动工具、样机工具、Framer 模板、Dock 小组件、动态效果工具和渐变工具。
• 注意，X 通常显示来源帖子的时间戳，而非书签保存时间。除非能看到保存/添加书签的时间戳，否则应明确标注时间范围指的是书签信息流中来源帖子的日期。
• 如有需要，打开状态 URL，查看被截断的帖子或文章卡片，以获取足够的上下文。确保收集内容均有来源依据。

除非浏览器访问受阻且用户批准采用替代方案，否则，若任务明确针对书签，不要依赖公开搜索。

起草

创建或更新：

data/x-growth/bookmark-quote-posts/YYYY-MM-DD.md

如果已有项目路径，请沿用。如果仓库中还没有书签队列，请创建最精简合理的日期路径，例如 data/x/bookmark-quote-posts/YYYY-MM-DD.md。

使用以下格式：

# Bookmark Quote Posts - YYYY-MM-DD

Checked in Codex Browser: https://x.com/i/bookmarks

Window: ...

Voice sample: latest <count> authored posts from <date> to <date>; <standalone> standalone posts, <replies> replies, <quotes> posts with quoted sources. Reply and quote counts may overlap.

Tone pass: first-person voice matched to repeated patterns in the live 100-post corpus.

## Best Picks

### 1. Source Name - Topic

Source: https://x.com/...

<draft>

除非来源材料不足，否则撰写 7-10 条草稿。将质量最好的帖子放在 Best Picks 下；将备选内容或来源可信度较低的内容放在 Secondary Picks 下。尽量涵盖用户关注主题中的不同类别，例如工具、产品创意、设计资源、技术经验、行业观点、工作流创意和实用资源。

将每条完成的草稿视为建议发布的引用转推，用户可以继续打磨。保存的文件是完整队列，但助手的回复应直接展示质量最好的草稿文本，让用户无需先打开文件，就能提出意见、改写，或要求调整角度。

语气

采用用户或品牌一贯的语气，让句子更有真实经历的质感，而非一味追求精致。

采用：

• 自然合适时使用第一人称
• 参考用户独立帖子和引用转推中的段落数量与长度分布
• 语言直接，保留不刻意修饰的表达，并体现具体的个人特点
• 融入用户所在领域的实际经验，例如构建、设计、教学、交付、销售、调试、研究、运营或从错误中学习
• 来源信息有限时，坦诚表达不确定性

避免：

• “短句、空行、短句、空行”的节奏
• “真正的技能是……”之类的通用框架
• “说得好”之类空洞的赞同
• “game changer”“unlock”“hot take”“supercharge”等炒作式短语
• 过于工整对称的表达、抽象结论，或与实际内容语料中风格不符的重复模板式开头
• 除非用户要求，否则不要加入行动号召
• 不要声称用户的生活、工作、产品、团队、客户或成果情况，除非这些信息有当前提示、现有草稿或可信项目上下文作为依据

好的草稿应听起来像目标作者结合个人经历补充来源内容，而不是对来源内容作摘要。

验证

提交前：

• 确保每份草稿都有来源 URL。
• 确保每份最终草稿都遵循从用户近期的独立推文和引用推文中学到的结构。不要强行让每份草稿都采用相同的段落数。
• 在带日期的文件中记录语气样本数量、日期范围，以及原创／回复／引用的构成比例。
• 在脑海中默读文件，并删除听起来像 AI 总结的句子。
• 运行 git diff --check -- data/x-growth/bookmark-quote-posts/YYYY-MM-DD.md。
• 仅暂存预期的书签引用推文文件。

如果本次运行更改了文件，请从目标仓库提交。提交信息可采用如下格式：

git commit -m "Refresh X bookmark quote posts for YYYY-MM-DD"

如果浏览器访问受阻，或没有可用书签，导致文件未发生更改，请勿凭空创建提交；请如实说明受阻原因或无更改状态。

报告

最后列出：

• 输出路径
• 候选项／来源数量
• 使用的时间范围
• 浏览器／访问状态
• 语气语料数量、日期范围和格式构成
• 验证结果
• 提交时的提交哈希
• 一张包含最值得推荐的引用推文的 Markdown 表格，通常为 3–5 行，列名如下：
  • Pick
  • Source
  • Suggested tweet
  • Why this angle
  • Hone next
• 将当前最佳建议放在第一行。Suggested tweet 单元格应包含实际的推文草稿，而不是摘要。如需保留两段或三段结构，请在单元格内使用 <br><br>。
• 让表格便于修改：Why this angle 应用一句话说明编辑上的取舍，Hone next 应指出最可能需要改进之处、可能遇到的反对意见或具体性不足。
• 如果浏览器访问受阻或没有找到可用书签，请勿编造引用推文建议表格。请说明受阻情况，并指出本次运行没有基于来源的建议。