概念解释器
适合划词工具栏、随手问答、术语梳理
你现在是“学术概念解释器”。 请把我给出的术语或句子解释给本专业研究生听懂，按以下格式输出： 1. 一句话定义 2. 为什么它重要 3. 在论文里通常怎么被使用 4. 一个通俗类比 5. 常见误解 如果有缩写，请先展开全称；如果是方法名，请补一句“适合解决什么问题”。
阅读提示： 本页将多版公开实践经验归纳为可直接复用的协作方法，覆盖第一性原理、文献闭环、Codex Subagents 并行协作、Plan-First 工作流、OpenClaw 边界、 AI 疲劳迁移、责任带宽与上下文交接等高频场景。
🧭
AI 协作方法论
当同事，不当工具
元提示词、苏格拉底追问、多模型协作、经验沉淀。
🧠
第一性原理规则
把澄清前置到系统层
把需求澄清、路径纠偏和根因导向写进 claude.md，减少盲目执行。
📚
文献阅读闭环
调研 → 筛选 → 精读 → 整合
从 Deep Research 到 Zotero 管理，形成可回溯知识资产。
🎨
绘图与写作质控
先理解，再生成
绘图 Prompt 规划、写作技能沉淀、多轮审稿与人工复核。
💻
Code Agent 协作
复杂需求治理
多模型澄清、严格执行、Skill 去重与“效率幻觉”防控。
👥
Codex Subagents 并行协作
主线程 + sidecar
先拆任务、再定边界、再收可消费结果；别把关键判断外包成等待线程。
🧩
Plan-First 工作流
先计划，再执行
把 research.md、plan.md、批注循环与 todo list 串成一条更稳的编码流水线。
🪢
Harness Engineering
设计 AI 的工作环境
当同类错误反复出现时，回到工具系统、权限边界、记忆管理、上下文压缩与反馈循环设计。
🗂️
OpenClaw 场景与边界
从聊天工具到系统
夜间预处理、四色分拣、并行代理与“默认不越权”的边界设计。
🪫
AI 疲劳迁移
少敲键盘，不等于少做判断
解释为什么代码写得更少，调度、监督、验收与上下文切换却可能更累，以及责任带宽为何会成为新的瓶颈。
🔍
AI Code Review
团队级审查治理
把 pre-commit、PR 深审和统一审查标准整理成独立子页，适合团队协作场景。
📝
可复制 Prompt 模板
直接拿去改写
覆盖概念解释、课题调研、逐句精读、写作风格沉淀、上下文交接记录、Skill 复盘与效率自检。
🧭
一、AI 协作方法论
把 AI 放进工作流，而不是放在工作流外面。
方法一
当同事，不当工具
更合适的定位不是“让 AI 替你做”，而是“让 AI 参与讨论、追问和拆解”。 这样能保留人的判断权，也更容易形成持续复用的工作流。
方法二
元提示词思维
先让模型帮你写 Prompt、工作流或 Skill 草案，再由人做微调。 人主要负责边界、验收标准与风格控制，避免从零开始手写所有提示词。
方法三
苏格拉底式追问
把模糊的一句话想法拆成多个决策点，让模型反复追问“目标是什么、依据是什么、约束是什么、如何验收”， 直到方案能落地。
方法四
经验沉淀成模板
真正高频、稳定、可复用的流程，才值得固化为 Skill、Prompt 模板或脚手架。 协作效率的提升来自“不断复用”，而不是“不断新增工具”。
低摩擦原则： 把 AI 的入口尽量放到你已经在使用的工作界面里。 比如划词解释、选中文本总结、局部翻译、知识点弹出说明，通常比“另开一个聊天窗口”更容易形成稳定使用习惯。
🧠
二、把“第一性原理”前置到 claude.md
先澄清问题，再决定路径；先看根因，再决定是否实现。
“
把“第一性原理”前置到 claude.md， 会直接改变 AI 的协作边界
适合写入 claude.md 的系统层规则：把问题澄清、路径纠偏与根因导向前置。
作用
让模型先问“问题是什么”
当需求半清晰、目标和路径混在一起时，模型更容易主动拆开“动机—目标—约束—验收标准”， 而不是直接进入生成阶段。
机制
把纠偏写进系统层
这类规则一旦写入 claude.md 或项目级提示文件， 模型会默认检查路径是否冗长、是否只是补丁式修修补补，从而提高回退与重构意愿。
效果
减少堆叠式低质量实现
公开经验里的直接反馈是：模型更愿意删掉不合理的临时实现，回到原始需求重新整理方案， 而不是沿着错误方向继续叠代码。
可直接复用的 claude.md 片段 ## 第一性原理思考 - 先从原始需求、目标与约束出发，不默认用户已经把问题想清楚。 - 若目标、动机或验收标准仍模糊，先停下来澄清，再决定是否执行。 - 若目标明确但当前路径冗长或偏离根因，指出原因并给出更短方案。 - 优先修复根因，不在低质量临时实现上继续叠加补丁。
更适合的使用场景： 项目刚启动、用户只描述了表层诉求、任务存在明显弯路，或你怀疑当前方案只是“先做再说”时， 这条规则尤其有价值。它本质上不是让模型更保守，而是让澄清和纠偏更早发生。
⚙️
三、低摩擦日常工作流
先解决“随手可用”，再追求“全自动化”。
划词问答与翻译
适合处理概念解释、局部翻译、快速摘要与术语梳理，减少复制粘贴和上下文切换。
Agent 作为提醒与陪跑者
把 AI 用作复盘、提醒、轻咨询与习惯维持工具，比一开始就做大而全自动系统更稳定。
复杂任务再接入调度系统
只有当任务确实跨模型、跨工具、跨文件时，再引入多 Agent 面板和调度器，否则容易徒增维护成本。
📚
四、文献阅读与知识整合闭环
从“找到论文”升级到“形成个人知识资产”。
课题调研
先要求模型同时给出最新论文与开山工作，再按时间线理解研究问题是如何被提出、修正和推进的。 这一步的目标不是做总结，而是建立领域地图。
文献网络分析
通过引用关系与被引关系判断研究脉络、热点程度与拥挤度。 如果某一方向的网络过大且高度集中，通常意味着竞争激烈；反过来可能代表仍有切入空间。
宏观精读 + 逐句精读
宏观层面关注“动机—方法—实验—结论—评述”，逐句层面关注翻译、术语解释和逻辑细节。 两层阅读配合使用，比单次摘要更能避免理解偏差。
知识整合与回链
在文献管理器中保留原始 PDF、批注、结构化速览、精读说明与周报回链， 让每一篇文献都能追溯到“为什么读”“读出了什么”“后续怎么用”。
文献精读提示词框架（可直接改写） 请先不要写泛泛总结，而是按以下顺序输出： 1. 这篇论文试图解决的核心问题 2. 作者为什么认为现有方法不够 3. 方法部分最关键的三个设计选择 4. 实验里最能支撑结论的证据 5. 这篇论文真正可复用的分析思路 6. 还存在哪些没有被证明的假设
🎨
五、科研绘图与学术写作
先把内容讲清，再让模型去生成视觉或文字。
科研绘图
- • 先区分插图、Teaser 图、Poster 三种任务，再写 Prompt。
- • 不直接要求模型“出图”，而是先让它规划内容布局、配色、字体与层级。
- • 参考图比抽象描述更有效，尤其适合风格迁移与版式学习。
- • 图像模型适合作为草图助手，不适合无审校直接交付科研图。
学术写作
- • 开始写之前，必须确认模型对问题、贡献与证据链理解正确。
- • 先用通用科研写作框架起草，再沉淀领域专用写作 Skill。
- • 草稿成形后，先做多轮 AI 审稿，再交导师或合作者审阅。
- • 风格记忆应包括结构偏好、展开尺度、图表说明与贡献句式。
补充提醒： 写作环节更值得沉淀的是领域专用写作 Skill，而不是万能写作 Prompt。 它至少应记住该领域常见结构、你的写作风格偏好、哪些地方该展开、以及图表、相关工作与贡献总结的呈现习惯。
科研绘图规划模板 请不要直接生成图片。 先根据我的论文内容，从以下五个维度输出方案： 1. 信息布局 2. 配色体系 3. 字体与标注 4. 图例与视觉层级 5. 更适合插图 / Teaser / Poster 的判断
写作质控模板 请站在审稿人视角检查： 1. 研究问题是否被说清楚 2. 方法与结论是否一一对应 3. 哪些句子像“AI 常见空话” 4. 哪些段落需要补证据或补限定语 5. 哪些地方不符合本领域常见写法
💻
六、Code Agent 与复杂任务协作
复杂需求的关键不是“立刻写”，而是“先把问题讲透”。
推荐流程
- 1. 用多个模型并行澄清需求，主动暴露决策点。
- 2. 让模型反复提问，直到问题表述和验收标准足够清楚。
- 3. 要求输出可视化结构，如 ASCII 原型图、流程图或目录草案。
- 4. 最后再交给严谨执行型模型落地编码与 review。
模型分工思路
- • 严谨执行型：适合代码实现、review、逐步落地。
- • 表达梳理型：适合需求澄清、汇总多轮讨论。
- • 搜索扩散型：适合方案发散、资料补充、外部信息对照。
- • 前端原型型：适合页面布局、界面想法、交互草图。
补充提醒： 复杂需求澄清阶段的提问应优先暴露真正的未知与决策点， 而不是让用户重复提供那些本地就能自行发现的信息。澄清阶段的目标是把问题讲透，而不是把对话拉长。
复杂需求澄清模板 请先不要实现。 请按下面顺序帮我把需求讲透： 1. 用你自己的话复述我的目标 2. 列出仍不明确的决策点 3. 每个决策点给出 2-3 个可选方案与代价 4. 输出一个最小可行版本的范围 5. 给出验收标准与风险点 6. 如果信息不足，请优先问那些我无法在本地自行发现的问题
新增子页 · Subagents
查看子页
Codex Subagents：把 sidecar 工作分出去，别把关键判断外包
Subagent 的真正价值，不是“多开几个分身”，而是把可并行的摸底、补测、验证任务拆出去， 让主线程继续守住关键路径。一个 subagent 只给一个职责，回收时只要可直接消费的结果，不要长报告。
适合拆出
只读摸底、范围明确的小 patch、与主线程并行的测试 / 回归验证。
必须留在主线程
会阻塞下一步的关键判断、架构选择、接口边界与最终 scope 决策。
回收格式
改了哪些文件、为什么这样改、跑了什么验证、还剩什么风险。
新增主题 · 计划先行
Plan-First 工作流：先把计划写对，再让 Claude 一次性执行
很多复杂编码任务真正决定成败的，不是实现速度，而是前面的理解质量：先深读系统、把理解写进 research.md，再把实施方案写进 plan.md， 通过文档批注循环把方案磨到正确，最后才进入实现。
research.md
plan.md
批注循环
todo list
推荐的 4 步流水线
深读代码，再写 research.md
先让模型把相关目录、调用链、约束和潜在 bug 真正读透，再把理解落到可审查文档。研究文档不是“作业”，而是人审模型理解是否扎实的界面。
把规划写进 plan.md
计划里要出现具体文件、实施顺序、最小范围、风险点与设计权衡。关键不是让模型“想一想”，而是让它把计划写成能被人修改的项目 artifact。
在文档里做 annotation cycle
直接在计划文档里批注错误、删掉多余 scope、补上接口约束，再让模型只更新文档、不开始实现。这个循环的作用，是把人的判断力注入最终方案。
补 todo list，再一次性执行
当设计决策都已经完成后，实现阶段就变成机械执行：按 todo list 逐项落地、持续跑 typecheck / lint / 必要测试，并把完成状态写回计划文档。
关键原则
先审研究，再审计划
最昂贵的失败通常不是语法错，而是“局部可跑、全局破坏”的错误实现。把研究和计划分开审，能更早发现误解与错位的抽象层级。
控制范围
方向错了，就回滚并重新缩 scope
如果模型沿着错误方案越走越远，不如直接 revert，重新定义“这次只做什么”。比起补丁式修修补补，重划范围往往更快。
人的职责
人做 judgement，AI 做 execution
是否砍掉锦上添花功能、是否保护旧接口、是否接受某个技术选型，这些都应该由人拍板。模型更适合承担机械实现、重复核对与文档更新。
为什么这套方法在长会话里更稳： session 负责建立理解，plan.md 负责保存决策。 当上下文压缩、阶段切换或实现中断时，只要让模型回到文档，就能比“只靠聊天记忆”更稳定地恢复状态。
Plan-First 模板（可直接改写） 研究模板 请先不要修改代码。 请对 [模块 / 目录] 做一次深度研究： 1. 读完相关源码、调用链、配置和已有约束 2. 标出最容易误判的地方与潜在 bug 3. 把结论写进 research.md 4. 如果你还没真正理解，就继续读，不要进入实现 计划模板 基于 research.md，为 [目标] 写一份 plan.md： - 列出要改的文件、原因与顺序 - 给出最小可行范围与明确不做项 - 标出接口边界、风险点与回滚点 - 如果有参考实现，先读参考源码再写计划 先不要实现 批注更新模板 我已经在 plan.md 里写了批注。 请逐条处理批注并更新文档： - 只更新 plan.md - 不要开始实现 - 如果有新歧义，先在文档里提出 实现模板 按最新的 plan.md 和 todo list 一次性实现全部任务： - 完成一项就勾选一项 - 不要私自增加 scope - 持续运行 typecheck / lint / 必要测试 - 如果方向偏了，先停下并说明是否应该回滚
🪢
七、Harness Engineering：把 AI 放进更可靠的工作环境
当 prompt 越写越长、同类错误反复出现时，往往该优化的不是一句提示词，而是整个工作环境。
“
Harness Engineering 不是继续把 prompt 写得更聪明， 而是把工具系统、权限边界、记忆管理、上下文压缩与反馈循环设计成一套稳定的工作环境。
模型决定能力上限，harness 更大程度决定稳定性、可控性与复用性。 当同类错误总在“再试一次”之后回来时，就该把纠错机制工程化，而不是继续堆上下文。
一个实用判断： 如果你最近明显感觉到会话越来越长、交接越来越乱、同一个错反复出现， 你缺的往往不是更多提示词，而是一套能把经验沉淀下来、把风险挡在系统边界外的 harness。
组成一
工具系统
把搜索、文件读写、测试、浏览器、部署等能力组合成明确工具链，让 AI 不必靠猜测完成任务。
组成二
权限边界
先定义哪些动作可以自动执行、哪些必须回到人来拍板，避免“能做”直接滑向“该做”。
组成三
记忆管理
把规则、SOP、失败案例、验收口径写进 AGENTS / CLAUDE / 模板文档，让经验离开当前对话也能复用。
组成四
上下文压缩
把长会话里的关键结论压进 plan、handoff、摘要和结构化记录，而不是让模型反复背整段聊天历史。
组成五
反馈循环
用测试、review、人工验收、线上验证与回滚点把错误变成下一轮系统规则，而不是变成下一次重复犯错。
个人可直接落地的 5 层实践框架
先写清任务目标与验收标准
告诉 AI 要交付什么、什么算完成、什么绝不能碰。没有验收标准，再强的模型也容易用局部正确替代整体正确。
再设计工具与权限边界
把能查、能改、能部署、能联网到什么程度说清楚；拿不准时默认退回人工确认，而不是先执行再补解释。
把工作区、记忆与上下文管理结构化
把项目规则、命名约定、常见坑、handoff 模板固定下来；长任务则用研究文档、计划文档和摘要替代纯聊天记忆。
把验证、review 与反馈循环前置
每次修改都要求对应验证命令、失败证据和上线检查，把“我觉得可以”替换成“我已经验证过”。
最后沉淀 SOP、模板与失败经验
真正拉开差距的不是某次 prompt 灵光一现，而是能把一次次踩坑变成下一次默认生效的流程规则。
什么时候该怀疑缺的是 harness
- prompt 越写越长，但结果并没有更稳。
- 同一个错误在不同任务里重复出现。
- 换一个会话、换一个模型，就得把前情重新解释一遍。
- 能跑通单次任务，但很难把流程交给别人复用。
和本站已有主题如何接上
第一性原理负责把目标问清楚，Plan-First 负责把决策写进文档，Subagents 负责拆出 sidecar 任务，Code Review 负责把反馈变成系统级治理。Harness Engineering 把这些分散技巧连成一套稳定环境。
一个常见误区
很多人把问题归咎为“模型不够聪明”，于是继续换模型、加 prompt、延长会话；但如果没有边界、没有记忆、没有验证，任何模型都会在长流程里变得不稳定。
继续往下看什么？
如果你想先看按视频顺序整理的逐句拆解、再把方法落到个人模板，可以先读“逐句拆解学习页”；如果想继续做深流程治理，再连读 Plan-First、Codex Subagents 与 AI Code Review。
🗂️
八、OpenClaw 场景与边界设计
真正稀缺的不是“全自动”，而是知道什么该交给 AI，什么必须留给人。
“
把 AI 从聊天工具升级成系统， 先画清 dispatch / prep / yours / skip 四条边界
适合在多代理协作中先定义 dispatch / prep / yours / skip 四类边界，再决定哪些任务交给系统自动流转。
案例收益： 每天节省约 30–45 分钟消息处理与任务整理时间，折算年化约 130–195 小时；新增工具成本约 5–10 美元/月。 更重要的变化不是“省几分钟”，而是从先组装信息再决策，切换到直接进入决策模式。
场景一
夜间预处理
把规则明确、重复出现的任务放到夜间批处理：扫描日历、补通勤提醒、整理消息与待办、自动去重， 并在次日清晨前把任务系统更新到可决策状态。
场景二
早间四色分拣
早上不再从零整理事务，而是直接按四类看板进入判断： dispatch 交给 AI 全权处理，prep 由 AI 准备选项， yours 留给人拍板，skip 暂不处理。
场景三
并行执行与时间块排程
多个代理并行推进草稿、调研、归档与待办整理，再把剩余事项转换成时间块， 结合地点、通勤和任务依赖排进日历，减少“会做但排不进去”的执行摩擦。
关键判断
真正门槛不是写代码，而是系统架构
公开案例最有启发的一点是：非程序员也能搭起这类系统，但前提是能把模块职责、上下游输入输出、 文档规则和人机边界想清楚。工具只是执行层，架构清晰度才决定系统能否长期稳定。
边界规则
默认不越权，拿不准就退回 prep
适合长期运行的设计不是“让 AI 自己发出去”，而是让 AI 先准备、再交人审。 当任务是否该自动执行仍不清楚时，默认退回 prep，而不是冒进地替人做最终决策。
迁移到科研/医疗场景时，更适合自动化的部分： 会议前材料归拢、文献待筛清单、项目待办去重、日程提醒、周报草稿与行政事务预处理。
不建议完全交给 AI 的部分： 对外正式发送、患者或受试者敏感沟通、定价/合作条件、核心研究判断与高风险伦理决策。
四色分拣模板（可直接改写） 请先不要直接执行任务。 请把我今天的待办按四类输出： 1. dispatch：规则明确、可由 AI 全权处理 2. prep：AI 先准备方案/草稿，由我最终拍板 3. yours：需要我亲自判断、沟通或到场 4. skip：今天不处理，说明延后理由 额外要求： - 若任务涉及对外发送、敏感关系或高风险判断，默认不要放入 dispatch - 若你拿不准分类，默认放入 prep，并说明还缺什么信息 - 最后给出一个按时间块排程的建议顺序
🛡️
九、风险控制：避免“效率幻觉”
越顺滑，越要主动检查自己是否还在主导问题。
Skill 不是越多越好
同类 Skill 过多、边界写得不清时，模型更容易选错工具、犹豫变慢，甚至拖垮上下文。 定期复盘、去重与关停低频工具，比无上限扩充更重要。
保持问题表述权
一旦你已经说不清楚“当前到底在解决什么问题、完成标准是什么”，就说明决策权可能已经悄悄让渡给模型。
把决策可视化
将关键判断点、路径选择和验收标准打成文字、流程图或思维导图， 可以强迫自己把“看似顺畅”的协作重新变成“可检查”的协作。
主动抽离与复看
工作一段时间后主动离开当前对话，重新问自己： 这件事为什么要做、现在做到哪一步、如果要向别人汇报我会怎么讲。
亲手输入，保持“人在回路”
把关键判断、思路和结构自己重新打一遍，再整理成列表或思维导图。 这一步越少复制粘贴，越能确认内容是“你已经想清楚”，而不是“模型说得很顺”。
定期给 Skill / MCP 做减法
同类工具堆太多会让模型只看 description 就犹豫选错。真正长期高频的留下， 低频重复的关掉，通常比继续扩容更能提升稳定性。
新增主题 · 负荷管理
为什么没怎么写代码，反而更累：AI 疲劳迁移
很多时候更累的不是敲代码，而是持续调度、监控、验收与上下文切换。 AI 不一定消灭疲劳，它更常把疲劳从“亲手执行”转移到“持续管理”；当生成速度显著提高而负责速度没有同步扩容时，新的瓶颈就会落在人类的验收、背书与责任带宽上。
上下文切换
多项目并发
验收负荷
持续监控
责任带宽
这类“更累”通常来自三种隐性负荷
能力边界被推开，scope 自然膨胀
当 Claude Code、OpenClaw 一类工具把“能做成”的预期拉高后，人会更容易同时打开多个项目，临时起意去优化、重构、benchmark 与部署。结果不是少做事，而是开始做更多事。
持续监控不完全可靠的 agent
真正消耗注意力的，往往不是打一段代码，而是反复确认 agent 有没有理解错、这次修改是否真的修好、dangerous-skip-permission 是否会越界，以及多个输出之间谁更可信。
上下文切换 + 小决策堆积
看起来都不是“重活”，却会不断打断：哪个项目先看、哪个结果先验、哪个分支该回滚、哪个任务该继续。真正累的是注意力、短时记忆、决策阈值，以及始终不敢完全放松的警戒状态。
一句话判断
不是工具让你少做事，而是工具让你敢想更多事
一旦“这个项目顺手再优化一下”也变得可行，人的默认任务边界就会被推开。疲劳没有消失，只是从体力执行转成了持续管理。
缓解动作 1
项目可以多开，但同时真正盯的别太多
允许并行跑，但不要同时在脑子里维持太多活跃上下文，否则像开了一堆后台进程，返回任何一个都要重新加载整个世界。
缓解动作 2
每次切走前，留一句交接记录
至少写清“做到哪里、已经确认了什么、最大风险是什么、下一步干什么”。这样回来时不必再次从零重建上下文。
缓解动作 3
把“让 agent 干活”和“自己做验收”分开
不要一边下新任务，一边盯另一个项目的细节。把 dispatch 与 review 拆开，有助于减少来回切换造成的碎脑感。
结构性矛盾
生产速度提高，不等于负责速度提高
AI 可以在半小时内给出十版方案、八段代码或三套文档，但最后仍要有人逐项确认：哪些能上线、哪些能署名、哪些值得承担后果。生成端提速之后，最慢的一环往往不再是“做出来”，而是“看懂并拍板”。
责任带宽
真正稀缺的是验收、背书与拍板能力
所谓“背锅带宽”，更中性的说法可以理解为责任带宽：一个人在一天内能完成多少高质量审查、验收、签字与责任承担。候选输出可以成倍增加，但高质量确认能力不会同速扩张。
系统视角
局部提速很快，整体吞吐未必线性增长
这有点像把系统里的“生成”环节加速了很多倍，但“审查与责任”仍保持原速。只要最慢环节没有同步扩容，整体效率就会很快碰到上限，于是人会主观感到更忙、更碎、更累。
缓解动作 4
少刷进度，也少开无限量候选
不要隔几分钟就去看一次 agent 跑到哪里。每看一次，都是一次上下文重载。除非到了约定检查点，否则让它先跑完整个阶段。同样，别让 AI 一次性铺开过多并列方案；先限定 2-3 个方向、按阶段提交，通常比一口气堆满候选更能保护责任带宽。
缓解动作 5
接受你做的已不只是 coding
现在的工作更像调度、监督、判断与整合，因此疲劳感不会像传统写代码那样有明确“敲完一段就轻松”的完成感。先承认工作形态变了，才更容易设计新的节奏。
核心判断： 如果你最近也在用 Claude Code、Cursor、OpenClaw 之类的工具，却发现自己反而更疲惫，问题不一定是状态差。 更可能是 AI 没有消灭疲劳，它只是把疲劳从亲手执行转移到了持续管理，同时把系统瓶颈推到了人类的验收、背书与责任带宽上。
真正更稳的做法，通常不是继续追求“多给几版”，而是先设定验收门槛、分批提交，并把最终待拍板的版本数量控制在人能认真看完的范围内。
上下文交接记录模板（切任务前可直接改写） 我准备暂时离开当前任务，请不要展开新方案。 只输出一条 6 行以内的交接记录： 1. 当前目标是什么 2. 现在做到哪里了 3. 已经确认了什么 4. 最大风险或未决点是什么 5. 下一步最小动作是什么 6. 我回来时应该先看什么 要求：短句、可直接贴到 todo / issue / notes。
📝
十、可复制 Prompt 模板
以下模板可直接复制后按你的课题替换变量。
课题调研时间线
适合文献调研与开山工作梳理
请围绕主题“[研究问题]”做课题调研。 不要只给最新论文，请同时给出： 1. 该方向的开山工作 2. 关键转折节点 3. 最近 3 年的新变化 4. 目前还没解决的问题 请按时间线组织输出，并额外标记： - 哪几篇值得精读 - 哪些工作只是热但不一定有方法增量 - 哪些方向可能已经非常拥挤
逐句精读助手
适合 PDF 逐段/逐句精读
请逐句处理下面这段论文原文，不要跳句。 每一句都输出： 【原句】 【中文直译】 【导师式解释】用研究生能听懂的话解释这句在说什么 【上下文作用】这句在整段里的作用是什么 【术语提醒】如果有关键术语或默认前提，请点出来 如果作者在这里偷换概念、默认跳步或没有说清楚，也请明确指出。
科研绘图规划器
适合插图、Teaser 图、Poster 前置规划
我准备为“[论文主题/研究结果]”做科研图。 请不要直接出图，而是先输出一份绘图规划： 1. 这更适合做插图、Teaser 图还是 Poster，为什么 2. 版式结构应该怎么排 3. 配色建议与原因 4. 文字标注应该保留到什么程度 5. 如果我给参考图，你最该学习哪些风格元素 6. 最后再给一版可用于图像模型的英文 Prompt 要求：优先保证逻辑清晰，不要为了“好看”牺牲准确性。
领域写作 Skill 蒸馏
适合从参考论文沉淀自己的写作风格
下面我会给你 3-5 篇我认可的本领域论文片段。 请不要直接模仿措辞，而是帮我蒸馏出一个“领域写作 Skill”： 1. 常见段落结构 2. 论证推进方式 3. 作者如何交代贡献与限制 4. 哪些句式常用于图表说明和结果总结 5. 哪些地方通常要展开，哪些地方应避免废话 最后请输出一个可长期复用的写作指令模板，供我后续写本领域论文时调用。
Skill / MCP 复盘与减法
适合清理重复工具、提升稳定性
请帮我审查当前这组 Skill / MCP / 工具清单。 目标不是“越多越好”，而是“长期稳定可用”。 请按以下维度输出： 1. 哪些功能明显重复 2. 哪些 description 边界不清，容易让模型选错 3. 哪些工具我应当保留为核心工作流 4. 哪些工具更适合停用或合并 5. 如果只能保留最小工具集，你建议留下什么 最后请给出一版“做减法后的推荐清单”。
上下文交接记录
适合切任务前留下最小可恢复信息
我准备从当前任务切到另一个任务。 请不要展开新方案，只输出一条 6 行以内的交接记录： 1. 当前目标 2. 已完成到哪一步 3. 已经确认的结论 4. 最大风险或未决点 5. 下一步最小动作 6. 回来时先看什么 要求：短句、可直接贴到 todo / issue / notes。
效率幻觉自检
适合项目推进中途强制回看
请不要继续生成方案，先帮我做一次“效率幻觉”检查。 围绕当前任务，逐条回答： 1. 我现在到底在解决什么问题 2. 当前验收标准是什么 3. 哪些决策其实还没想清楚 4. 我是不是只是因为对话顺畅就误以为自己在前进 5. 如果现在要向导师/同事汇报，我能否清楚讲明当前进展 如果存在方向漂移，请直接指出最可能漂移的地方，并建议我先暂停、整理再继续。
可直接点击的相关入口
十、参考资料与延伸阅读
以下链接为本页整理时参考的公开记录来源，便于继续查看相关实践与原始讨论。
01
我在日常是如何与AI协作的？-3.6版
补充了低摩擦入口、文献闭环、绘图规划、写作多轮审稿与复杂需求澄清等内容。
02
博士生日常如何与ai协作的（3.6更新版）
补充了领域写作 Skill、Skill/MCP 减法、效率幻觉、决策可视化与主动抽离等新增要点。
03
我在日常是如何与AI协作的？-2.27版
提供了早期版本的绘图对比、Code Agent 多模型澄清流程与经验沉淀思路。
04
这个 OpenClaw 的使用场景真有意思。
补充了夜间预处理、四色分拣、人机边界与“从聊天工具升级成系统”的案例化判断。
05
为什么没怎么写代码却更累：AI 疲劳迁移笔记
补充了“疲劳从亲手执行转向持续管理”的判断框架，以及多项目并发、交接记录、少刷进度与分离验收负荷等缓解动作。
06
Claude Code 工作流分享：Plan-First 编码流程
总结出 research.md → plan.md → annotation cycle → todo list → implement 的编码工作流，适合复杂任务先计划、后实现。
07
Codex Subagents：让任务自己并行
补充了“先拆任务、再开分身、一 agent 一职责、主线程守关键路径、结果回收要可消费”的 delegation 规则。
08
用了AI反而更累，因为背锅带宽满了
补充了“生成速度提高，但负责速度没有同步提高”的结构性判断，并将新的瓶颈概括为人类的验收、背书与责任带宽。