如何用 last30days 来完成基于社交网络的 AI 调研需求

如何用 last30days 完成基于社交网络的 AI 调研需求社交网络上每天都有人在表态发帖、投票、争吵、退订、迁移。这些散落在 Reddit、X、YouTube 评论、TikTok、Hacker News、Polymarket 上的声音单独看只是噪音攒到一起却是一份相当真实的民意切片。问题只在于——没人愿意为了一个调研结论手动去八个平台翻三十天的帖子。last30days 这个 skill 就是为此而生的。它会替你把上面这些渠道的近三十天内容拉到一起、按主题合成。而 preset task 这一层则把调用 last30days这件事从一句需要记参数的指令变成一个填好就能跑的表单。这篇文章想聊的不是 last30days 本身有多好用而是 HagiCode 怎么用 preset task 这套编排机制把一个 skill 编排出四种调研姿态这件事做扎实的。毕竟skill 是能力preset 是把能力变成产品的胶水。背景preset 想省下的其实是那句被反复说的话preset task 体系最早是 preset 级绑定一个 skill。也就是说一个 preset 对应一个 skill调用方式相对单一。可现实里同一个能力往往要以不同姿态被使用——同样是 last30days有时候你想做泛调研有时候你想做竞品对比有时候你只想针对某个产品做提示词风格的分析。把这些不同的使用方式硬塞进一个交互流程里界面会越来越乱拆成四个独立 skill又重复造轮子。于是设计上往中间走了一步允许在 command 级绑定 skill。一个 preset 下挂多个 command每个 command 自描述自己要调用哪个 skill、用什么参数而 preset 层的 requirements 则作为权威清单声明这个 preset 一共依赖哪些 skill。这样一来界面归界面执行归执行。谁愿意把界面样式和执行逻辑揉成一团呢。一个 skill四种 modelast30days 这个 preset 就是这个范式的样板一个 skill四个 command。四个 command 对应四种调研姿态general泛调研给一个 query让 last30days 自己去各平台捞近三十天的相关讨论再合成结论。comparison对比明确给出要对比的对象让 skill 围绕谁更好/谁更差/各自痛点组织素材。competitors竞品聚焦于某个产品的竞品生态调用 last30days 自带的--competitorsflag。prompting提示词风格关注人们实际上在怎么用、怎么提问偏向用法与心智模型。四个 command 在commands.json里全部声明skill: last30days但各自的 prelude参数与提示不同。前端抽屉里用户选的是 mode、写的是 query、勾的是目标仓库至于背后拼出哪条指令由 preset 自己决定。用户不必记参数也不必知道--competitors这种 flag 的存在。两层数据commands.json 与 task-preset.jsonpreset 包里有两个文件分担职责分得相当干净commands.json描述有哪些 command、每个 command 长什么样。每个 command 自带skill字段说明它要调用哪个 skill还带着自己的 prelude 模板说明怎么把这个 command 拼成一行指令。这是 command 级的自描述。task-preset.json描述这个 preset 整体需要什么。它持有 requirements声明依赖的 skill 清单、inputs 定义、inputBindings以及 selectionMode 之类的元信息。这是 preset 级的权威清单。两层各自的边界很清楚command 负责说我需要这个 skillpreset 负责说我这个 preset 允许用到哪些 skill。如果某个 command 声明了一个 skill但 preset 的 requirements 里没有校验就会报错——diagnostic 是command-skill-not-in-requirements。这种显式的失败比静默退化要好得多。单行注入/{skill} {prelude}把 skill 真正接进执行流程的是一个不起眼的小机制单行注入。PresetTaskCatalogProvider里有个方法叫CombineCommandSkillPrelude。逻辑很简单如果一个 command 声明了skill并且它渲染出来的 prelude 行不是以/{skill}开头那就把/{skill}前置上去。最后交给执行器的是形如/last30days {commandPrelude}这样的一行独立指令。紧接着才是user.hbs渲染出来的正文模式塑形、query、目标仓库边界、以及非交互、记录假设的约束。为什么要这么做因为 last30days 这类 skill 本身就是按收到/{skill}指令来加载和运行的。preset 不能假设 skill 会自动被触发必须显式地把这条指令喂进去。一行而已却是整个链路能跑通的关键。五段式技术链路把上面这些串起来从用户点提交到结论回连仓库一共是五段前端选单用户在CreatePresetTaskDrawer里选 mode、写 query、勾目标仓库。resolveCommandPreview镜像后端的拼装逻辑实时把预览指令显示给用户看buildTargetScopeMarkdown按 read/write 分组把仓库边界算成一段 markdown。后端校验请求落到SessionsController.PresetTasks.TryResolvePresetTaskRequestAsync。它先校验 inputs/targets/derived 的键是不是在白名单里、command id 是不是在 catalog 内、selectionMode 是不是 single再跑PresetTaskRequirementCheckService.CheckAsync对每个 requirements 里的 skill通过LocalSkillCommandAdapter查本地 skill inventory按 CacheKey 去重。提示词渲染根据 locale 渲染对应的user.hbs把last30daysMode、last30daysQuery、targetScopeMarkdown、targetRepositories注入进去。user.hbs明确禁止AskUserQuestion要求执行器在遇到歧义时记录假设而不是反问——这是非交互执行的硬边界。skill 加载与执行执行器收到拼好的 prompt。/last30days作为独立指令在最前触发 skill 加载。skill 内部按自己的 LAWs 跑Step 0.45 做 keyword-trap 预检防止 query 被误当成 handle/subredditStep 0.5/0.55 解析定向渠道Step 0.75 让推理模型自己生成--plan然后跑 Python 引擎去 Reddit/X/YouTube/TikTok/Instagram/HN/Polymarket/Web 拉数据Step 2 用 WebSearch 补充Step 2.5 追加到 raw 文件最后按 LAWs 合成结论。结论回连合成出的结论带回到 preset 的上下文里。目标仓库的 read/write 边界是靠 prompt 里的targetScopeMarkdown软约束的——preset 告诉 skill你只能读这几个、能写那几个skill 在自己的执行里遵守这条边界。几条实践要点非交互边界要写进模板。user.hbs里禁用AskUserQuestion不是建议是硬约束。preset 跑起来后没有人坐在屏幕前回答反问所以歧义必须靠记录假设来消化。能预置的 flag 就预置。竞品 mode 直接把--competitors写进 prelude用户不需要知道这个 flag 的存在。preset 的意义就是把专业参数藏到合适的人手里。skill 去重靠 CacheKey。requirements 里同一个 skill 出现多次也没关系PresetTaskRequirementCheckService按 CacheKey 去重不会重复检查、重复加载。仓库边界是软约束。read/write 边界靠 prompt 注入不是靠沙箱。这意味着 skill 是否听话部分取决于它对 prompt 的遵循程度。这是一个现实的折中。失败要明确不要静默。skill 缺失就报 requirement check 失败返回 400并在前端给出一键安装入口openSkillGalleryForSkill。让用户知道哪里坏了、怎么修比悄悄退化成没有 skill 也能跑要负责得多。迁移要无破坏。从 preset 级 skill 到 per-command skill 的演进是向后兼容的。老的 preset 级声明仍然有效新的 command 级声明是叠加能力不是替换。步子迈太大容易扯着何必呢。preset task 把一个 skill 变成四种产品形态靠的不是什么精巧的算法而是几处边界划得干净的契约command 自描述、preset 权威清单、单行注入、非交互硬约束、显式失败。把这些拼起来用 last30days 做社交网络调研这件事才从一句需要记参数的指令变成了一个填表就能跑的功能。至于这些声音攒到一起到底能说明什么那是 last30days 自己的活儿了……原文与版权说明感谢您的阅读,如果您觉得本文有用,欢迎点赞、收藏和分享支持。本内容采用人工智能辅助协作,最终内容由作者审核并确认。本文作者: newbe36524原文链接: https://docs.hagicode.com/go?platformcsdntarget%2Fblog%2F2026-02-11-last30days-social-ai-research%2F版权声明: 本博客所有文章除特别声明外,均采用 BY-NC-SA 许可协议。转载请注明出处!