AI 技能人工智能大模型深度学习【免费下载链接】AI-Research-SKILLsComprehensive open-source library of AI research and engineering skills for any AI model. Package the skills and your claude code/codex/gemini agent will be an AI research agent with full horsepower. Maintained by Orchestra Research.项目地址https://gitcode.com/gh_mirrors/ai/AI-Research-SKILLs点击查看免费下载导读本指南围绕 AI-Research-SKILLs 仓库中的ara-research-manager技能Live PM展开它是一套在编码/科研会话结束后自动运行的研究记录员扫描整个会话历史把其中的决策、实验、死胡同、主张、启发式技巧与方向转折抽取出来按user/ai-suggested/ai-executed/user-revised四类溯源标签写入ara/目录形成跨会话可持续重建的科研过程档案。读完本文你将掌握会话结束后如何自动沉淀科研过程、如何用探索树exploration tree刻画研究 DAG、如何通过溯源标签实现人说了什么与AI 做了什么的严格区分以及如何用成熟度追踪器把零散观察晋升为正式主张。一、技能定位什么是 Live PM它什么时候运行ara-research-manager定义了一个名为Live PMLive Research Project Manager的角色——一个事后任务记录器post-task research recorder。它的核心约束是运行时机只在一次编码/科研会话结束时运行也就是用户请求已被完全处理后才审阅整个会话发生了什么并据此更新ara/产物。该定位在 SKILL.md 的 frontmatter 中有明确声明Use as a session epilogue — never during execution作为会话尾声使用绝不在执行期间。运行时机有三条硬性规则绝不在任务进行中运行处理用户请求期间不得读取或写入ara/仅在任务完成后运行用户请求被完整处理之后才审阅整个会话并更新ara/不污染工作上下文ara/目录不应在尾声阶段之前被加载进上下文。这一设计刻意把做研究与记录研究分离任务执行期间保持工作上下文干净、不被日志写入打断等一切尘埃落定后再一次性、增量地沉淀记录。Live PM 的整体工作流程How You Work分为五步审阅会话历史——扫描本次会话发生的一切抽取研究级事件——决策、实验、死胡同、主张、启发式技巧、AI 动作读取现有ara/文件——获取当前 ID、已有主张、当前树状态若ara/不存在则创建见初始化章节写入更新——向正确文件追加新条目、更新状态变化的既有条目、创建会话记录汇报捕获内容——结尾输出一行摘要。二、事件分类从会话中抽取什么Live PM 的核心能力是把嘈杂的对话历史分类为结构化的研究级事件。下表是 SKILL.md 中定义的事件类型、识别信号与路由目标事件类型识别信号路由目标Decision决策用户在多个备选方案中做了选择trace/exploration_tree.yamlExperiment实验测试运行、基准完成、产生定量结果trace/exploration_tree.yamlevidence/Dead End死胡同方法被放弃、不 work、被回滚trace/exploration_tree.yamlPivot转折基于证据的重大方向改变trace/exploration_tree.yamlClaim主张关于系统的断言、提出的假设logic/claims.mdHeuristic启发式技巧实现技巧、workaround、关键诀窍是……logic/solution/heuristics.mdAI ActionAI 动作Agent 写了代码、跑了命令、创建了文件仅会话记录session recordObservation观察有趣但暂无法归类staging/observations.yaml应当跳过的内容SKIP常规文件读取、拼写修正、格式调整Git 操作与依赖安装澄清性问题除非其答案构成一次决策。这一负清单保证了ara/只沉淀有研究信息增量的内容而不是变成操作日志。2.1 细粒度事件分类参考文档深化更完整的事件分类体系记录在 references/event-taxonomy.md 中它将事件细分为五类并分别路由研究事件→trace/exploration_tree.yamlquestion该不该用 attention 还是 convolution 做 encoder、decision用 GQA 而不是 MHA内存占用更低、experiment学习率扫描显示 3e-4 最优、dead_end试了 FP16但 1k 步后 loss 发散、pivotattention 方案太慢切换去状态空间模型知识事件→logic/claim我认为……、该系统达到……→logic/claims.md、heuristic关键诀窍是……→logic/solution/heuristics.md、concept新术语定义 →logic/concepts.md、constraint这只有在……时才 work→logic/solution/constraints.md、architecture系统设计 →logic/solution/architecture.md证据事件→evidence/result_table表格数据、基准数字 →evidence/tables/table{N}.md、result_figure图数据 →evidence/figures/fig{N}.md、metric单个定量测量内联在实验节点或证据文件中过程事件→trace/sessions/ai-actionAgent 写代码、跑命令、建文件、ai-suggestionAgent 提出方向/假设 → 记入ai_suggestions_pending、user-direction用户给出高层指令或纠正provenance 为user暂存事件→staging/observation无法归入以上任何一类、有趣但非结构化的内容。2.2 路由决策树event-taxonomy.md给出了一个可逐步执行的路由决策树Live PM 判断某条会话内容归属时按此顺序走是在多个备选方案间做选择 → 是decisiontrace → 否↓ 是定量结果或实验产出 → 是experimenttrace 证据数据evidence/ → 否↓ 是被放弃的方法且有原因 → 是dead_endtrace → 否↓ 是关于系统/方法的可证伪断言 → 是claimlogic/claims.md → 否↓ 是带 rationale 的实现技巧 → 是heuristiclogic/solution/heuristics.md → 否↓ 是重大方向改变 → 是pivottrace → 否↓ 是在探究的研究问题 → 是questiontrace → 否→ observationstaging这个决策树保证了任何一条对话内容都能被确定性地归类不会因为模棱两可而漏记或错记。三、Provenance 溯源标签人说了什么 vs. AI 做了什么每一条例入ara/的条目都必须携带溯源标记。这是 Live PM 区别于普通日志系统的关键设计知识的认识论地位epistemic status取决于其来源。用户在会话中明确说出的一句话与 AI 从代码输出中推断出的结论具有完全不同的可信权重。标签适用时机示例user用户明确陈述或确认我们改用 GQAai-suggestedAI 推断用户未确认AI 注意到某个模式ai-executedAI 执行了动作AI 写了 scheduler.pyuser-revisedAI 建议用户做了修正不阈值是 90%核心原则是不确定时默认ai-suggested绝不要把推断标记为user。3.1 四种标签的语义边界参考文档深化references/provenance-tags.md 给出了每种标签的完整语义与边界情况user用户确认/输入用户直接陈述学习率应该是 3e-4、确认 AI 建议对记下来/正确、给出决策我们选方案 A、提出研究问题能把内存降低 50% 吗。示例- **Provenance**: user于 claim 中或provenance: user于 decision 节点中。ai-suggestedAI 推断未确认AI 观察代码/输出中的模式并提出解释、建议研究方向、从实验结果推断主张、为观察提出分类、推测某决策可能有哪些备选项。该文档特别强调其升级路径只有当用户明确确认后才可改为user或user-revised。文档还给出了一种内联溯源写法用 HTML 注释标注长文本中不同句子的来源The system achieves 97% QoE coverage !-- provenance: ai-executed (from benchmark run) -- under bursty load conditions !-- provenance: user (stated requirement) --.ai-executedAI 动作AI 写/改了源码文件、跑了基准或测试套件、创建了 ARA 条目、产出了实验结果。即使动作是用户让 AI 去跑的动作本身仍是ai-executed但用户对结果的解读可能是user或ai-suggested。user-revised用户修正 AI 建议用户说不完全是更像……、纠正细节阈值是 90%不是 85%、收窄范围对但只对稠密模型成立、补充细微差别对但真正的原因是……。该文档要求保留修订历史例如- id: O05 provenance: user-revised content: KV cache watermark threshold should be 90%, not 85% revision_history: - original: ai-suggested watermark at 85% - revised: user corrected to 90% based on profiling data3.2 为什么溯源重要provenance-tags.md列出了四项核心收益可审计性Auditability评审者/协作者可以把每一条断言追溯到其来源信任校准Trust calibrationAI 的建议被明确标记为未经确认修正流程Correction flow用户修订 AI 建议时修订历史被保留责任归属AccountabilityAI 的动作写代码、跑测试被正确归因。3.3 溯源决策树与会话聚合references/session-protocol.md 提供了运行时的溯源决策树用户明确输入/说出 → provenance: user AI 运行了产生该结果的代码/测试/命令 → provenance: ai-executed AI 注意到模式、推断含义、提出解释 → provenance: ai-suggested 用户修正了 AI 的建议 → provenance: user-revised 不确定 → provenance: ai-suggested 保守默认会话记录还会聚合溯源统计作为整个产物可信度的信号provenance_summary: user_confirmed: 5 # provenance: user 的事件 ai_suggested: 3 # 未确认的 AI 建议 ai_executed: 7 # AI 采取的动作 user_revised: 1 # 用户对 AI 建议的修正 confirmation_rate: 0.625 # user / (user ai-suggested)3.4 溯源完整性五条规则provenance-tags.md明确列出绝不自动升级ai-suggested→user必须经过用户显式确认保留历史升级时在注释或修订字段中保留原始 provenance默认保守不确定时用ai-suggested复合事件用户让 AI 跑某事动作是ai-executed但解读可能是user或ai-suggested沉默不是确认如果 AI 提出建议而用户未回应它保持ai-suggested。四、ARA 目录结构科研产物的分层档案Live PM 写入的ara/目录遵循 Agent-Native Research ArtifactARA的层次化布局。ara-research-manager侧维护的是轨迹与过程层完整的字段级 schema 见 compiler 的 ara-schema.md。Live PM 视角下的目录结构如下ara/ PAPER.md # 根清单 层索引 logic/ # What Why是什么与为什么 problem.md # 问题定义 差距 claims.md # 可证伪断言 证据引用 concepts.md # 术语定义 experiments.md # 实验计划声明式 solution/ architecture.md # 系统设计 algorithm.md # 数学 伪代码 constraints.md # 边界条件 heuristics.md # 技巧 rationale 敏感性 related_work.md # 带类型依赖图 src/ # How代码产物 configs/ kernel/ environment.md trace/ # Journey研究旅程 exploration_tree.yaml # 研究 DAG sessions/ session_index.yaml # 会话主索引 YYYY-MM-DD_NNN.yaml # 单个会话记录 evidence/ # Raw Proof原始证据 README.md tables/ figures/ staging/ # 未分类观察 observations.yaml4.1 渐进式披露Progressive Disclosureara-schema.md定义了三级渐进式披露帮助 Agent 控制上下文成本Level 1 —PAPER.md约 200 tokensfrontmatter 层索引Agent 只需读它即可判断相关性Level 2 — 层文件problem.md、claims.md、experiments.md、evidence/README.md按需加载Level 3 — 细节文件algorithm.md、代码桩、单个证据表深入时加载。五、写入格式探索树、主张、技巧、观察与会话记录5.1 探索树结构trace/exploration_tree.yaml探索树是嵌套 YAML 结构父子关系通过children:键表达形成展示决策如何导向实验、实验如何导向进一步决策或死胡同的研究 DAG根节点是tree:下的顶层条目每个节点可有含嵌套子节点的children:缩进表示用also_depends_on: [N{XX}]表达交叉边节点依赖多个父节点叶子节点没有children:键。新增节点规则判断该节点逻辑上从哪个既有节点延续而来其父节点就把它嵌套进该节点的children:如果是全新的顶层研究线则作为根节点加入。完整的节点示例含 question → experiment → decision → dead_end/experiment 的嵌套链以及跨边和顶层 pivottree: - id: N01 type: question title: {根研究问题} provenance: user timestamp: YYYY-MM-DDTHH:MM description: {正在探索什么} children: - id: N02 type: experiment title: {测试了什么} provenance: ai-executed timestamp: YYYY-MM-DDTHH:MM result: {发生了什么——包含数字} evidence: [C{XX}, {figure/table refs}] children: - id: N03 type: decision title: {基于 N02 结果做出的选择} provenance: user timestamp: YYYY-MM-DDTHH:MM choice: {选了什么以及为什么} alternatives: - {未被选择的选项} evidence: {什么促成了这一选择——引用父节点} children: - id: N04 type: dead_end title: {失败的方法} provenance: user timestamp: YYYY-MM-DDTHH:MM hypothesis: {预期什么会 work} failure_mode: {为什么失败} lesson: {学到了什么} - id: N05 type: experiment title: {work 的替代方案} also_depends_on: [N02] # 交叉边也受 N02 影响 provenance: ai-executed timestamp: YYYY-MM-DDTHH:MM result: {结果} evidence: [C{XX}] - id: N06 type: dead_end title: {从 N01 尝试的姊妹方法} provenance: user timestamp: YYYY-MM-DDTHH:MM hypothesis: {预期什么} failure_mode: {为什么失败} lesson: {学到了什么——促成 N02 方向} - id: N07 type: pivot title: {新的顶层研究线} provenance: user timestamp: YYYY-MM-DDTHH:MM from: {先前方向} to: {新方向} trigger: {什么导致了改变}5.2 节点类型参考类型必填字段使用时机questiondescription根研究问题或子问题decisionchoice、alternatives、evidence用户在选项间做了选择experimentresult、evidence测试/基准产出了结果dead_endhypothesis、failure_mode、lesson方法被放弃pivotfrom、to、trigger重大方向改变探索树的git log价值exploration-tree-spec.md将其类比为研究的 git log——结构化的、可遍历的、记录每个成功分支、失败尝试与设计决策的档案。dead_end节点被特别强调为对下游 Agent 最有价值的节点类型因为它能避免 Agent 重新发现已知的失败。该规范同时要求每个节点声明support_level: explicit | inferredexplicit表示节点直接扎根于输入材料应携带source_refs如[Table 2, §4.1]inferred表示是对论文/会话逻辑的重构不得伪装成直接观察到的历史事件。5.3 主张logic/claims.md## C{XX}: {标题} - **Statement**: {可证伪断言} - **Status**: hypothesis | untested | testing | supported | weakened | refuted | revised - **Provenance**: user | ai-suggested | user-revised - **Falsification criteria**: {什么会推翻它} - **Proof**: [{证据引用或 pending}] - **Dependencies**: [C{YY}, ...] - **Tags**: {逗号分隔}值得注意主张的Status支持完整的生命周期假设 → 未测 → 测试中 → 被支持 → 被削弱 → 被反驳 → 被修订这与会话结束时 Live PM 更新状态变化条目的职责相呼应。ara-schema.md还要求主张的Proof必须引用experiments.md中的实验 IDE01、E02…而不是文件路径以此建立跨层绑定。5.4 启发式技巧logic/solution/heuristics.md## H{XX}: {标题} - **Rationale**: {为什么这招有效} - **Provenance**: user | ai-suggested | user-revised - **Sensitivity**: low | medium | high - **Code ref**: [{文件路径}]5.5 观察staging/observations.yaml- id: O{XX} timestamp: YYYY-MM-DDTHH:MM provenance: user | ai-suggested | ai-executed content: {原始观察} context: {当时发生了什么} potential_type: claim | heuristic | decision | unknown promoted: falsestaging/是松散线索的暂存区观察可能暂时无法归类通过potential_type预判其未来去向promoted标记是否已被晋升到正式层。5.6 会话记录trace/sessions/YYYY-MM-DD_NNN.yamlsession: id: YYYY-MM-DD_NNN timestamp: YYYY-MM-DDTHH:MM summary: {本次会话一行摘要} events_logged: - type: decision | experiment | dead_end | pivot | claim | heuristic | observation id: {N/C/H/O}{XX} provenance: user | ai-suggested | ai-executed | user-revised summary: {什么} ai_actions: - action: {AI 做了什么} provenance: ai-executed files_changed: [{路径}] claims_touched: - id: C{XX} action: created | advanced | weakened | confirmed provenance: user | ai-suggested open_threads: - {需要跟进的事} ai_suggestions_pending: - {本次会话未确认的 AI 建议}5.7 ID 约定与自增规则event-taxonomy.md定义了全局 ID 约定探索节点NN01…、主张CC01…、技巧HH01…、实验计划EE01…、观察OO01…会话 ID 按日期序列2026-03-11_001唯一命名。自增规则创建新 ID 前必须读取现有文件找到最大 ID避免重复。5.8 取证绑定清单Forensic Binding Checklistevent-taxonomy.md要求记录任何事件时立即建立以下绑定与 SKILL.md 规则 5 Establish forensic bindings 对应主张 → 证据主张创建时什么证据能证明/推翻它若无证据则Proof: [pending]实验 → 主张该实验测试哪些主张通过Claims tested:链接技巧 → 代码代码库中哪里实现了它设置Code ref:决策 → 证据什么证据或推理推动了该决策死胡同 → 教训学到了什么该知识能否防止未来重犯若当前无法建立绑定则添加!-- TODO: bind to {target} --注释作为可追踪的待办义务。六、会话协议从开始到结束的完整生命周期虽然 Live PM 只在会话结束后正式写入但 references/session-protocol.md 描述了贯穿整个会话的协议使其在会话结束时能无缝接续状态。6.1 会话开始自动若ara/已存在静默读取状态——session_index.yaml上次会话日期、摘要、未完成线程、claims.md按状态统计、staging/observations.yaml待处理数量、晋升候选随后按需上下文化简报用户直接开始任务则把上下文织入首条回复在我们开始前——上次会话你在测 C04结果是 92%有两个未完成线程用户询问进展则给出完整简报用户有明确任务时绝不以简报开场同时创建本次会话记录文件trace/sessions/YYYY-MM-DD_NNN.yaml初始化开始时间与空事件列表。若ara/不存在不要在首次交互时主动创建若检测到研究级讨论决策、假设、实验问一次要我跟踪这个项目的研究过程吗我会建立ara/确认后初始化完整目录结构并从当前会话引导启动。6.2 会话进行中持续、不可见每次实质交流后运行事件检测循环1. 做了决策 → 写入 exploration_tree.yaml 2. 观察到结果 → 写入 exploration_tree.yaml evidence/ 3. 方法失败 → 写入 dead_end 到 exploration_tree.yaml 4. 陈述了主张 → 写入 claims.md 5. 发现技巧 → 写入 heuristics.md 6. 方向改变 → 写入 pivot 到 exploration_tree.yaml 7. AI 写了代码 → 记录到会话记录ai_actions 8. 有趣的笔记 → 写入 staging/observations.yaml写入协议先读取目标文件获得下一个可用 ID追加新条目、绝不覆盖既有内容立即建立绑定claim→proof、heuristic→code_ref、decision→evidence使用正确的 provenance写入前在心中校验 YAML 结构有效性保持沉默——除非被询问否则不提日志记录。6.3 冲突检测写入新条目时检查冲突新主张与既有主张矛盾 → 双方都加!-- CONFLICT: see C{XX} --新证据削弱既有主张 → 将主张状态更新为weakened新决策推翻先前决策 → 记录为pivot并链接到原决策。6.4 会话结束自动结束触发信号对话明显收尾谢谢、就这些、用户沉默、上下文窗口即将压缩系统在总结旧消息、用户明确道别。结束流程定稿会话记录设置结束时间戳、写一行摘要、确保所有缓冲事件已刷入 ARA 文件更新会话索引session_index.yaml- id: YYYY-MM-DD_NNN date: YYYY-MM-DD summary: {主要成果} events_count: {N} claims_touched: [C{XX}, ...] open_threads: {N}对暂存区做成熟度检查详见下节输出一行简短收尾[PM] Session captured: 3 decisions, 1 experiment, 2 claims advanced. 1 open thread.6.5 跨会话连续性Agent 本身没有内置跨会话记忆ARA 本身就是记忆session_index.yaml→ 何时发生了什么claims.md→ 已知 vs. 未知exploration_tree.yaml→ 完整研究轨迹staging/observations.yaml→ 松散线索各会话记录 → 逐会话的详细历史。每个会话开始时读取这些文件即可重建完整项目上下文。未完成线程open threads自动结转每个会话记录列出open_threads会话开始时浮出最近会话的未完成线程后续会话解决某线程时在事件中注明。紧急/意外结束若会话未正常收尾——已写入 ARA 的事件是安全的增量写入会话记录可能不完整下次会话应检测并注明因为写入是实时而非批量不会丢数据。七、初始化ara/不存在时的自动引导若ara/不存在Live PM 自动创建完整目录结构并写入种子文件不要询问Initialization 章节明确要求 Do not askmkdir -p ara/{logic/solution,src/{configs,kernel},trace/sessions,evidence/{tables,figures},staging}然后写入 8 个种子文件ara/PAPER.md— 根清单根据项目上下文推断标题、作者、venueara/trace/sessions/session_index.yaml—sessions: []ara/trace/exploration_tree.yaml—tree: []ara/staging/observations.yaml—observations: []ara/logic/claims.md—# Claimsara/logic/problem.md—# Problemara/logic/solution/heuristics.md—# Heuristicsara/evidence/README.md—# Evidence Index。八、成熟度追踪器观察如何晋升为正式知识每次尾声阶段审阅staging/observations.yaml时运行成熟度追踪器Maturity Tracker同一主题 3 条观察→ 晋升到对应层标记为ai-suggested带实验证据的观察→ 晋升到evidence/与某主张矛盾的观察→ 标记!-- CONFLICT: contradicts C{XX} --陈旧观察跨 3 个会话→ 标记stale: true。这形成了一个自组织升级管道零散观察先在staging/积累达到足够密度或证据强度后自动晋升为正式主张、证据或技巧同时矛盾与陈旧信息得到显式标注避免污染后续会话。九、完整执行流程与七条规则9.1 尾声执行流程Procedure读取现有ara/文件获取当前状态ID、主张、树扫描整个会话寻找研究级事件对每个事件分类并赋予 provenance向正确文件追加新条目若状态变化则更新既有条目在ara/trace/sessions/YYYY-MM-DD_NNN.yaml创建会话记录将会话追加到ara/trace/sessions/session_index.yaml对暂存区运行成熟度追踪器输出一行摘要[PM] Session captured: {N} decisions, {N} experiments, {N} claims.9.2 七条操作规则Rules绝不在任务进行中运行——只在用户请求完成后的尾声阶段运行绝不虚构事件——只记录实际发生或讨论过的内容绝不升级 provenance——ai-suggested保持到用户显式确认为止总是先读取既有文件——获取正确的下一个 ID避免重复建立取证绑定——主张→证据、技巧→代码、决策→证据追加而非覆盖——新增条目绝不替换既有内容保持 YAML 有效——写入后校验结构。这七条规则是保证ara/记录可信度的基石尤其是不虚构事件不升级 provenance总是先读文件三者共同防止了最常见的三种污染——编造历史、夸大确认度、ID 冲突。十、与 ARA 生态的协同Compiler 与 Rigor Reviewerara-research-manager是 ARA 工作流中的过程记录器它与同目录下的另外两个技能构成完整闭环ara-compilerUniversal ARA Compiler把论文 PDF、GitHub 仓库、实验日志、代码目录等任意研究输入编译成完整 ARA其trace/exploration_tree.yaml的节点规范support_level: explicit | inferred、source_refs、≥8 节点、必须含 dead_end 与 decision 类型与 Live PM 维护的探索树是同一套格式——Compiler 从静态输入重建研究 DAGLive PM 则在真实研究过程中持续增量维护它ara-rigor-reviewerARA Seal Level 2 语义审稿在 Level 1 结构校验通过后从证据相关性、可证伪性、范围校准、论证连贯性、探索完整性、方法严谨性六个维度对 ARA 打分并产出level2_report.json。其中D5 探索完整性直接审查探索树是否记录了真实的失败过程——这正是 Live PM 持续写入的内容质量保证层。三者形成Compiler 建库 → Research Manager 记录过程 → Rigor Reviewer 审稿的闭环而 Live PM 提供的逐会话溯源记录正是 Rigor Reviewer 判断探索是否诚实是否记录了真实负结果的事实来源。结语ara-research-manager解决的是一个真实而隐蔽的问题AI 参与的研究过程其过程本身——失败的分支、放弃的方案、临时的直觉、未被确认的推断——在最终论文里往往消失不见。Live PM 通过会话尾声扫描 事件分类 溯源标签 探索树 DAG这套机制把过程变成了与结果同等重要、可审计、可跨会话重建的资产。对使用 Claude Code / Codex 等 Agent 进行研究的团队而言这意味着每次会话结束后项目的知识状态都会被自动、诚实、增量地沉淀下来——下一会话开始时Agent 通过读取ara/就能回忆起它从未真正拥有过的记忆。参考文件索引research-manager/SKILL.md — Live PM 技能定义本文主文档references/event-taxonomy.md — 完整事件分类、路由决策树、ID 约定与取证绑定清单references/provenance-tags.md — 溯源标签语义、边界情况与会话聚合references/session-protocol.md — 会话开始/进行中/结束的分阶段协议compiler/references/ara-schema.md — ARA 目录完整字段级 schemacompiler/references/exploration-tree-spec.md — 探索树 YAML 规范compiler/SKILL.md — ARA 编译器技能rigor-reviewer/SKILL.md — ARA Seal Level 2 语义审稿技能赞分享AI 技能人工智能大模型深度学习【免费下载链接】AI-Research-SKILLsComprehensive open-source library of AI research and engineering skills for any AI model. Package the skills and your claude code/codex/gemini agent will be an AI research agent with full horsepower. Maintained by Orchestra Research.项目地址https://gitcode.com/gh_mirrors/ai/AI-Research-SKILLs点击查看免费下载相关推荐ARA Research Manager 会话协议深度解析让 AI 研究 Agent 拥有可审计的跨会话记忆ARA Research Manager 会话协议深度解析让 AI 研究 Agent 拥有可审计的跨会话记忆 本篇技术指南以 research managerAI 技能人工智能大模型深度学习AI-Research-SKILLs 溯源标记系统实战指南用 Provenance Tags 构建可审计、可校准的人机协同研究轨迹AI Research SKILLs 溯源标记系统实战指南用 Provenance Tags 构建可审计、可校准的人机协同研究轨迹 在人机协同研究过程中一条AI 技能人工智能大模型深度学习pm-ai-shipping 实战指南为 AI 生成的代码补上意图记录让安全与性能审计可审查、可签收pm ai shipping 实战指南为 AI 生成的代码补上意图记录让安全与性能审计可审查、可签收 导读 pm ai shipping 是 pm skAI 技能AI 插件创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 ara-research-manager 深度指南：用 Live PM 技能为 AI 科研会话构建可审计的溯源记录
AI 技能人工智能大模型深度学习【免费下载链接】AI-Research-SKILLsComprehensive open-source library of AI research and engineering skills for any AI model. Package the skills and your claude code/codex/gemini agent will be an AI research agent with full horsepower. Maintained by Orchestra Research.项目地址https://gitcode.com/gh_mirrors/ai/AI-Research-SKILLs点击查看免费下载导读本指南围绕 AI-Research-SKILLs 仓库中的ara-research-manager技能Live PM展开它是一套在编码/科研会话结束后自动运行的研究记录员扫描整个会话历史把其中的决策、实验、死胡同、主张、启发式技巧与方向转折抽取出来按user/ai-suggested/ai-executed/user-revised四类溯源标签写入ara/目录形成跨会话可持续重建的科研过程档案。读完本文你将掌握会话结束后如何自动沉淀科研过程、如何用探索树exploration tree刻画研究 DAG、如何通过溯源标签实现人说了什么与AI 做了什么的严格区分以及如何用成熟度追踪器把零散观察晋升为正式主张。一、技能定位什么是 Live PM它什么时候运行ara-research-manager定义了一个名为Live PMLive Research Project Manager的角色——一个事后任务记录器post-task research recorder。它的核心约束是运行时机只在一次编码/科研会话结束时运行也就是用户请求已被完全处理后才审阅整个会话发生了什么并据此更新ara/产物。该定位在 SKILL.md 的 frontmatter 中有明确声明Use as a session epilogue — never during execution作为会话尾声使用绝不在执行期间。运行时机有三条硬性规则绝不在任务进行中运行处理用户请求期间不得读取或写入ara/仅在任务完成后运行用户请求被完整处理之后才审阅整个会话并更新ara/不污染工作上下文ara/目录不应在尾声阶段之前被加载进上下文。这一设计刻意把做研究与记录研究分离任务执行期间保持工作上下文干净、不被日志写入打断等一切尘埃落定后再一次性、增量地沉淀记录。Live PM 的整体工作流程How You Work分为五步审阅会话历史——扫描本次会话发生的一切抽取研究级事件——决策、实验、死胡同、主张、启发式技巧、AI 动作读取现有ara/文件——获取当前 ID、已有主张、当前树状态若ara/不存在则创建见初始化章节写入更新——向正确文件追加新条目、更新状态变化的既有条目、创建会话记录汇报捕获内容——结尾输出一行摘要。二、事件分类从会话中抽取什么Live PM 的核心能力是把嘈杂的对话历史分类为结构化的研究级事件。下表是 SKILL.md 中定义的事件类型、识别信号与路由目标事件类型识别信号路由目标Decision决策用户在多个备选方案中做了选择trace/exploration_tree.yamlExperiment实验测试运行、基准完成、产生定量结果trace/exploration_tree.yamlevidence/Dead End死胡同方法被放弃、不 work、被回滚trace/exploration_tree.yamlPivot转折基于证据的重大方向改变trace/exploration_tree.yamlClaim主张关于系统的断言、提出的假设logic/claims.mdHeuristic启发式技巧实现技巧、workaround、关键诀窍是……logic/solution/heuristics.mdAI ActionAI 动作Agent 写了代码、跑了命令、创建了文件仅会话记录session recordObservation观察有趣但暂无法归类staging/observations.yaml应当跳过的内容SKIP常规文件读取、拼写修正、格式调整Git 操作与依赖安装澄清性问题除非其答案构成一次决策。这一负清单保证了ara/只沉淀有研究信息增量的内容而不是变成操作日志。2.1 细粒度事件分类参考文档深化更完整的事件分类体系记录在 references/event-taxonomy.md 中它将事件细分为五类并分别路由研究事件→trace/exploration_tree.yamlquestion该不该用 attention 还是 convolution 做 encoder、decision用 GQA 而不是 MHA内存占用更低、experiment学习率扫描显示 3e-4 最优、dead_end试了 FP16但 1k 步后 loss 发散、pivotattention 方案太慢切换去状态空间模型知识事件→logic/claim我认为……、该系统达到……→logic/claims.md、heuristic关键诀窍是……→logic/solution/heuristics.md、concept新术语定义 →logic/concepts.md、constraint这只有在……时才 work→logic/solution/constraints.md、architecture系统设计 →logic/solution/architecture.md证据事件→evidence/result_table表格数据、基准数字 →evidence/tables/table{N}.md、result_figure图数据 →evidence/figures/fig{N}.md、metric单个定量测量内联在实验节点或证据文件中过程事件→trace/sessions/ai-actionAgent 写代码、跑命令、建文件、ai-suggestionAgent 提出方向/假设 → 记入ai_suggestions_pending、user-direction用户给出高层指令或纠正provenance 为user暂存事件→staging/observation无法归入以上任何一类、有趣但非结构化的内容。2.2 路由决策树event-taxonomy.md给出了一个可逐步执行的路由决策树Live PM 判断某条会话内容归属时按此顺序走是在多个备选方案间做选择 → 是decisiontrace → 否↓ 是定量结果或实验产出 → 是experimenttrace 证据数据evidence/ → 否↓ 是被放弃的方法且有原因 → 是dead_endtrace → 否↓ 是关于系统/方法的可证伪断言 → 是claimlogic/claims.md → 否↓ 是带 rationale 的实现技巧 → 是heuristiclogic/solution/heuristics.md → 否↓ 是重大方向改变 → 是pivottrace → 否↓ 是在探究的研究问题 → 是questiontrace → 否→ observationstaging这个决策树保证了任何一条对话内容都能被确定性地归类不会因为模棱两可而漏记或错记。三、Provenance 溯源标签人说了什么 vs. AI 做了什么每一条例入ara/的条目都必须携带溯源标记。这是 Live PM 区别于普通日志系统的关键设计知识的认识论地位epistemic status取决于其来源。用户在会话中明确说出的一句话与 AI 从代码输出中推断出的结论具有完全不同的可信权重。标签适用时机示例user用户明确陈述或确认我们改用 GQAai-suggestedAI 推断用户未确认AI 注意到某个模式ai-executedAI 执行了动作AI 写了 scheduler.pyuser-revisedAI 建议用户做了修正不阈值是 90%核心原则是不确定时默认ai-suggested绝不要把推断标记为user。3.1 四种标签的语义边界参考文档深化references/provenance-tags.md 给出了每种标签的完整语义与边界情况user用户确认/输入用户直接陈述学习率应该是 3e-4、确认 AI 建议对记下来/正确、给出决策我们选方案 A、提出研究问题能把内存降低 50% 吗。示例- **Provenance**: user于 claim 中或provenance: user于 decision 节点中。ai-suggestedAI 推断未确认AI 观察代码/输出中的模式并提出解释、建议研究方向、从实验结果推断主张、为观察提出分类、推测某决策可能有哪些备选项。该文档特别强调其升级路径只有当用户明确确认后才可改为user或user-revised。文档还给出了一种内联溯源写法用 HTML 注释标注长文本中不同句子的来源The system achieves 97% QoE coverage !-- provenance: ai-executed (from benchmark run) -- under bursty load conditions !-- provenance: user (stated requirement) --.ai-executedAI 动作AI 写/改了源码文件、跑了基准或测试套件、创建了 ARA 条目、产出了实验结果。即使动作是用户让 AI 去跑的动作本身仍是ai-executed但用户对结果的解读可能是user或ai-suggested。user-revised用户修正 AI 建议用户说不完全是更像……、纠正细节阈值是 90%不是 85%、收窄范围对但只对稠密模型成立、补充细微差别对但真正的原因是……。该文档要求保留修订历史例如- id: O05 provenance: user-revised content: KV cache watermark threshold should be 90%, not 85% revision_history: - original: ai-suggested watermark at 85% - revised: user corrected to 90% based on profiling data3.2 为什么溯源重要provenance-tags.md列出了四项核心收益可审计性Auditability评审者/协作者可以把每一条断言追溯到其来源信任校准Trust calibrationAI 的建议被明确标记为未经确认修正流程Correction flow用户修订 AI 建议时修订历史被保留责任归属AccountabilityAI 的动作写代码、跑测试被正确归因。3.3 溯源决策树与会话聚合references/session-protocol.md 提供了运行时的溯源决策树用户明确输入/说出 → provenance: user AI 运行了产生该结果的代码/测试/命令 → provenance: ai-executed AI 注意到模式、推断含义、提出解释 → provenance: ai-suggested 用户修正了 AI 的建议 → provenance: user-revised 不确定 → provenance: ai-suggested 保守默认会话记录还会聚合溯源统计作为整个产物可信度的信号provenance_summary: user_confirmed: 5 # provenance: user 的事件 ai_suggested: 3 # 未确认的 AI 建议 ai_executed: 7 # AI 采取的动作 user_revised: 1 # 用户对 AI 建议的修正 confirmation_rate: 0.625 # user / (user ai-suggested)3.4 溯源完整性五条规则provenance-tags.md明确列出绝不自动升级ai-suggested→user必须经过用户显式确认保留历史升级时在注释或修订字段中保留原始 provenance默认保守不确定时用ai-suggested复合事件用户让 AI 跑某事动作是ai-executed但解读可能是user或ai-suggested沉默不是确认如果 AI 提出建议而用户未回应它保持ai-suggested。四、ARA 目录结构科研产物的分层档案Live PM 写入的ara/目录遵循 Agent-Native Research ArtifactARA的层次化布局。ara-research-manager侧维护的是轨迹与过程层完整的字段级 schema 见 compiler 的 ara-schema.md。Live PM 视角下的目录结构如下ara/ PAPER.md # 根清单 层索引 logic/ # What Why是什么与为什么 problem.md # 问题定义 差距 claims.md # 可证伪断言 证据引用 concepts.md # 术语定义 experiments.md # 实验计划声明式 solution/ architecture.md # 系统设计 algorithm.md # 数学 伪代码 constraints.md # 边界条件 heuristics.md # 技巧 rationale 敏感性 related_work.md # 带类型依赖图 src/ # How代码产物 configs/ kernel/ environment.md trace/ # Journey研究旅程 exploration_tree.yaml # 研究 DAG sessions/ session_index.yaml # 会话主索引 YYYY-MM-DD_NNN.yaml # 单个会话记录 evidence/ # Raw Proof原始证据 README.md tables/ figures/ staging/ # 未分类观察 observations.yaml4.1 渐进式披露Progressive Disclosureara-schema.md定义了三级渐进式披露帮助 Agent 控制上下文成本Level 1 —PAPER.md约 200 tokensfrontmatter 层索引Agent 只需读它即可判断相关性Level 2 — 层文件problem.md、claims.md、experiments.md、evidence/README.md按需加载Level 3 — 细节文件algorithm.md、代码桩、单个证据表深入时加载。五、写入格式探索树、主张、技巧、观察与会话记录5.1 探索树结构trace/exploration_tree.yaml探索树是嵌套 YAML 结构父子关系通过children:键表达形成展示决策如何导向实验、实验如何导向进一步决策或死胡同的研究 DAG根节点是tree:下的顶层条目每个节点可有含嵌套子节点的children:缩进表示用also_depends_on: [N{XX}]表达交叉边节点依赖多个父节点叶子节点没有children:键。新增节点规则判断该节点逻辑上从哪个既有节点延续而来其父节点就把它嵌套进该节点的children:如果是全新的顶层研究线则作为根节点加入。完整的节点示例含 question → experiment → decision → dead_end/experiment 的嵌套链以及跨边和顶层 pivottree: - id: N01 type: question title: {根研究问题} provenance: user timestamp: YYYY-MM-DDTHH:MM description: {正在探索什么} children: - id: N02 type: experiment title: {测试了什么} provenance: ai-executed timestamp: YYYY-MM-DDTHH:MM result: {发生了什么——包含数字} evidence: [C{XX}, {figure/table refs}] children: - id: N03 type: decision title: {基于 N02 结果做出的选择} provenance: user timestamp: YYYY-MM-DDTHH:MM choice: {选了什么以及为什么} alternatives: - {未被选择的选项} evidence: {什么促成了这一选择——引用父节点} children: - id: N04 type: dead_end title: {失败的方法} provenance: user timestamp: YYYY-MM-DDTHH:MM hypothesis: {预期什么会 work} failure_mode: {为什么失败} lesson: {学到了什么} - id: N05 type: experiment title: {work 的替代方案} also_depends_on: [N02] # 交叉边也受 N02 影响 provenance: ai-executed timestamp: YYYY-MM-DDTHH:MM result: {结果} evidence: [C{XX}] - id: N06 type: dead_end title: {从 N01 尝试的姊妹方法} provenance: user timestamp: YYYY-MM-DDTHH:MM hypothesis: {预期什么} failure_mode: {为什么失败} lesson: {学到了什么——促成 N02 方向} - id: N07 type: pivot title: {新的顶层研究线} provenance: user timestamp: YYYY-MM-DDTHH:MM from: {先前方向} to: {新方向} trigger: {什么导致了改变}5.2 节点类型参考类型必填字段使用时机questiondescription根研究问题或子问题decisionchoice、alternatives、evidence用户在选项间做了选择experimentresult、evidence测试/基准产出了结果dead_endhypothesis、failure_mode、lesson方法被放弃pivotfrom、to、trigger重大方向改变探索树的git log价值exploration-tree-spec.md将其类比为研究的 git log——结构化的、可遍历的、记录每个成功分支、失败尝试与设计决策的档案。dead_end节点被特别强调为对下游 Agent 最有价值的节点类型因为它能避免 Agent 重新发现已知的失败。该规范同时要求每个节点声明support_level: explicit | inferredexplicit表示节点直接扎根于输入材料应携带source_refs如[Table 2, §4.1]inferred表示是对论文/会话逻辑的重构不得伪装成直接观察到的历史事件。5.3 主张logic/claims.md## C{XX}: {标题} - **Statement**: {可证伪断言} - **Status**: hypothesis | untested | testing | supported | weakened | refuted | revised - **Provenance**: user | ai-suggested | user-revised - **Falsification criteria**: {什么会推翻它} - **Proof**: [{证据引用或 pending}] - **Dependencies**: [C{YY}, ...] - **Tags**: {逗号分隔}值得注意主张的Status支持完整的生命周期假设 → 未测 → 测试中 → 被支持 → 被削弱 → 被反驳 → 被修订这与会话结束时 Live PM 更新状态变化条目的职责相呼应。ara-schema.md还要求主张的Proof必须引用experiments.md中的实验 IDE01、E02…而不是文件路径以此建立跨层绑定。5.4 启发式技巧logic/solution/heuristics.md## H{XX}: {标题} - **Rationale**: {为什么这招有效} - **Provenance**: user | ai-suggested | user-revised - **Sensitivity**: low | medium | high - **Code ref**: [{文件路径}]5.5 观察staging/observations.yaml- id: O{XX} timestamp: YYYY-MM-DDTHH:MM provenance: user | ai-suggested | ai-executed content: {原始观察} context: {当时发生了什么} potential_type: claim | heuristic | decision | unknown promoted: falsestaging/是松散线索的暂存区观察可能暂时无法归类通过potential_type预判其未来去向promoted标记是否已被晋升到正式层。5.6 会话记录trace/sessions/YYYY-MM-DD_NNN.yamlsession: id: YYYY-MM-DD_NNN timestamp: YYYY-MM-DDTHH:MM summary: {本次会话一行摘要} events_logged: - type: decision | experiment | dead_end | pivot | claim | heuristic | observation id: {N/C/H/O}{XX} provenance: user | ai-suggested | ai-executed | user-revised summary: {什么} ai_actions: - action: {AI 做了什么} provenance: ai-executed files_changed: [{路径}] claims_touched: - id: C{XX} action: created | advanced | weakened | confirmed provenance: user | ai-suggested open_threads: - {需要跟进的事} ai_suggestions_pending: - {本次会话未确认的 AI 建议}5.7 ID 约定与自增规则event-taxonomy.md定义了全局 ID 约定探索节点NN01…、主张CC01…、技巧HH01…、实验计划EE01…、观察OO01…会话 ID 按日期序列2026-03-11_001唯一命名。自增规则创建新 ID 前必须读取现有文件找到最大 ID避免重复。5.8 取证绑定清单Forensic Binding Checklistevent-taxonomy.md要求记录任何事件时立即建立以下绑定与 SKILL.md 规则 5 Establish forensic bindings 对应主张 → 证据主张创建时什么证据能证明/推翻它若无证据则Proof: [pending]实验 → 主张该实验测试哪些主张通过Claims tested:链接技巧 → 代码代码库中哪里实现了它设置Code ref:决策 → 证据什么证据或推理推动了该决策死胡同 → 教训学到了什么该知识能否防止未来重犯若当前无法建立绑定则添加!-- TODO: bind to {target} --注释作为可追踪的待办义务。六、会话协议从开始到结束的完整生命周期虽然 Live PM 只在会话结束后正式写入但 references/session-protocol.md 描述了贯穿整个会话的协议使其在会话结束时能无缝接续状态。6.1 会话开始自动若ara/已存在静默读取状态——session_index.yaml上次会话日期、摘要、未完成线程、claims.md按状态统计、staging/observations.yaml待处理数量、晋升候选随后按需上下文化简报用户直接开始任务则把上下文织入首条回复在我们开始前——上次会话你在测 C04结果是 92%有两个未完成线程用户询问进展则给出完整简报用户有明确任务时绝不以简报开场同时创建本次会话记录文件trace/sessions/YYYY-MM-DD_NNN.yaml初始化开始时间与空事件列表。若ara/不存在不要在首次交互时主动创建若检测到研究级讨论决策、假设、实验问一次要我跟踪这个项目的研究过程吗我会建立ara/确认后初始化完整目录结构并从当前会话引导启动。6.2 会话进行中持续、不可见每次实质交流后运行事件检测循环1. 做了决策 → 写入 exploration_tree.yaml 2. 观察到结果 → 写入 exploration_tree.yaml evidence/ 3. 方法失败 → 写入 dead_end 到 exploration_tree.yaml 4. 陈述了主张 → 写入 claims.md 5. 发现技巧 → 写入 heuristics.md 6. 方向改变 → 写入 pivot 到 exploration_tree.yaml 7. AI 写了代码 → 记录到会话记录ai_actions 8. 有趣的笔记 → 写入 staging/observations.yaml写入协议先读取目标文件获得下一个可用 ID追加新条目、绝不覆盖既有内容立即建立绑定claim→proof、heuristic→code_ref、decision→evidence使用正确的 provenance写入前在心中校验 YAML 结构有效性保持沉默——除非被询问否则不提日志记录。6.3 冲突检测写入新条目时检查冲突新主张与既有主张矛盾 → 双方都加!-- CONFLICT: see C{XX} --新证据削弱既有主张 → 将主张状态更新为weakened新决策推翻先前决策 → 记录为pivot并链接到原决策。6.4 会话结束自动结束触发信号对话明显收尾谢谢、就这些、用户沉默、上下文窗口即将压缩系统在总结旧消息、用户明确道别。结束流程定稿会话记录设置结束时间戳、写一行摘要、确保所有缓冲事件已刷入 ARA 文件更新会话索引session_index.yaml- id: YYYY-MM-DD_NNN date: YYYY-MM-DD summary: {主要成果} events_count: {N} claims_touched: [C{XX}, ...] open_threads: {N}对暂存区做成熟度检查详见下节输出一行简短收尾[PM] Session captured: 3 decisions, 1 experiment, 2 claims advanced. 1 open thread.6.5 跨会话连续性Agent 本身没有内置跨会话记忆ARA 本身就是记忆session_index.yaml→ 何时发生了什么claims.md→ 已知 vs. 未知exploration_tree.yaml→ 完整研究轨迹staging/observations.yaml→ 松散线索各会话记录 → 逐会话的详细历史。每个会话开始时读取这些文件即可重建完整项目上下文。未完成线程open threads自动结转每个会话记录列出open_threads会话开始时浮出最近会话的未完成线程后续会话解决某线程时在事件中注明。紧急/意外结束若会话未正常收尾——已写入 ARA 的事件是安全的增量写入会话记录可能不完整下次会话应检测并注明因为写入是实时而非批量不会丢数据。七、初始化ara/不存在时的自动引导若ara/不存在Live PM 自动创建完整目录结构并写入种子文件不要询问Initialization 章节明确要求 Do not askmkdir -p ara/{logic/solution,src/{configs,kernel},trace/sessions,evidence/{tables,figures},staging}然后写入 8 个种子文件ara/PAPER.md— 根清单根据项目上下文推断标题、作者、venueara/trace/sessions/session_index.yaml—sessions: []ara/trace/exploration_tree.yaml—tree: []ara/staging/observations.yaml—observations: []ara/logic/claims.md—# Claimsara/logic/problem.md—# Problemara/logic/solution/heuristics.md—# Heuristicsara/evidence/README.md—# Evidence Index。八、成熟度追踪器观察如何晋升为正式知识每次尾声阶段审阅staging/observations.yaml时运行成熟度追踪器Maturity Tracker同一主题 3 条观察→ 晋升到对应层标记为ai-suggested带实验证据的观察→ 晋升到evidence/与某主张矛盾的观察→ 标记!-- CONFLICT: contradicts C{XX} --陈旧观察跨 3 个会话→ 标记stale: true。这形成了一个自组织升级管道零散观察先在staging/积累达到足够密度或证据强度后自动晋升为正式主张、证据或技巧同时矛盾与陈旧信息得到显式标注避免污染后续会话。九、完整执行流程与七条规则9.1 尾声执行流程Procedure读取现有ara/文件获取当前状态ID、主张、树扫描整个会话寻找研究级事件对每个事件分类并赋予 provenance向正确文件追加新条目若状态变化则更新既有条目在ara/trace/sessions/YYYY-MM-DD_NNN.yaml创建会话记录将会话追加到ara/trace/sessions/session_index.yaml对暂存区运行成熟度追踪器输出一行摘要[PM] Session captured: {N} decisions, {N} experiments, {N} claims.9.2 七条操作规则Rules绝不在任务进行中运行——只在用户请求完成后的尾声阶段运行绝不虚构事件——只记录实际发生或讨论过的内容绝不升级 provenance——ai-suggested保持到用户显式确认为止总是先读取既有文件——获取正确的下一个 ID避免重复建立取证绑定——主张→证据、技巧→代码、决策→证据追加而非覆盖——新增条目绝不替换既有内容保持 YAML 有效——写入后校验结构。这七条规则是保证ara/记录可信度的基石尤其是不虚构事件不升级 provenance总是先读文件三者共同防止了最常见的三种污染——编造历史、夸大确认度、ID 冲突。十、与 ARA 生态的协同Compiler 与 Rigor Reviewerara-research-manager是 ARA 工作流中的过程记录器它与同目录下的另外两个技能构成完整闭环ara-compilerUniversal ARA Compiler把论文 PDF、GitHub 仓库、实验日志、代码目录等任意研究输入编译成完整 ARA其trace/exploration_tree.yaml的节点规范support_level: explicit | inferred、source_refs、≥8 节点、必须含 dead_end 与 decision 类型与 Live PM 维护的探索树是同一套格式——Compiler 从静态输入重建研究 DAGLive PM 则在真实研究过程中持续增量维护它ara-rigor-reviewerARA Seal Level 2 语义审稿在 Level 1 结构校验通过后从证据相关性、可证伪性、范围校准、论证连贯性、探索完整性、方法严谨性六个维度对 ARA 打分并产出level2_report.json。其中D5 探索完整性直接审查探索树是否记录了真实的失败过程——这正是 Live PM 持续写入的内容质量保证层。三者形成Compiler 建库 → Research Manager 记录过程 → Rigor Reviewer 审稿的闭环而 Live PM 提供的逐会话溯源记录正是 Rigor Reviewer 判断探索是否诚实是否记录了真实负结果的事实来源。结语ara-research-manager解决的是一个真实而隐蔽的问题AI 参与的研究过程其过程本身——失败的分支、放弃的方案、临时的直觉、未被确认的推断——在最终论文里往往消失不见。Live PM 通过会话尾声扫描 事件分类 溯源标签 探索树 DAG这套机制把过程变成了与结果同等重要、可审计、可跨会话重建的资产。对使用 Claude Code / Codex 等 Agent 进行研究的团队而言这意味着每次会话结束后项目的知识状态都会被自动、诚实、增量地沉淀下来——下一会话开始时Agent 通过读取ara/就能回忆起它从未真正拥有过的记忆。参考文件索引research-manager/SKILL.md — Live PM 技能定义本文主文档references/event-taxonomy.md — 完整事件分类、路由决策树、ID 约定与取证绑定清单references/provenance-tags.md — 溯源标签语义、边界情况与会话聚合references/session-protocol.md — 会话开始/进行中/结束的分阶段协议compiler/references/ara-schema.md — ARA 目录完整字段级 schemacompiler/references/exploration-tree-spec.md — 探索树 YAML 规范compiler/SKILL.md — ARA 编译器技能rigor-reviewer/SKILL.md — ARA Seal Level 2 语义审稿技能赞分享AI 技能人工智能大模型深度学习【免费下载链接】AI-Research-SKILLsComprehensive open-source library of AI research and engineering skills for any AI model. Package the skills and your claude code/codex/gemini agent will be an AI research agent with full horsepower. Maintained by Orchestra Research.项目地址https://gitcode.com/gh_mirrors/ai/AI-Research-SKILLs点击查看免费下载相关推荐ARA Research Manager 会话协议深度解析让 AI 研究 Agent 拥有可审计的跨会话记忆ARA Research Manager 会话协议深度解析让 AI 研究 Agent 拥有可审计的跨会话记忆 本篇技术指南以 research managerAI 技能人工智能大模型深度学习AI-Research-SKILLs 溯源标记系统实战指南用 Provenance Tags 构建可审计、可校准的人机协同研究轨迹AI Research SKILLs 溯源标记系统实战指南用 Provenance Tags 构建可审计、可校准的人机协同研究轨迹 在人机协同研究过程中一条AI 技能人工智能大模型深度学习pm-ai-shipping 实战指南为 AI 生成的代码补上意图记录让安全与性能审计可审查、可签收pm ai shipping 实战指南为 AI 生成的代码补上意图记录让安全与性能审计可审查、可签收 导读 pm ai shipping 是 pm skAI 技能AI 插件创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考