[ { "title": "AI 路线速查", "label": "Guide", "url": "./ai-roadmap.html", "topic": "learn", "summary": "从会提问、会验证到能设计个人 AI 工作系统的 12 周路线。", "homeTitle": "AI 路线速查", "homeSummary": "从会提问到会验证，再到能设计自己的工作流，附 12 周路线。", "readMinutes": 7, "priority": 20, "featured": true, "tags": [ "AI 路线", "学习", "能力分层", "验证", "复盘" ], "updated": "2026-06-08", "content": "30 秒结论 不要只学“怎么问”，还要学“怎么判断答案是否能用”。 Prompt 是入口，上下文是燃料，工作流才是长期复利。 真正稀缺的是定义问题、拆解任务、验证结果和复盘经验的能力。 重要结论不要只看一次回答，要准备材料、设置边界，并做交叉验证。 最好的学习产物不是收藏夹，而是下次可以直接复用的步骤和模板。 能力分层 普通用户 会描述问题、整理材料，能得到清晰摘要。 进阶用户 会把任务拆成步骤，能让 AI 辅助研究、写作和代码。 工作流设计者 会设计输入、输出、检查清单和复盘方式。 Agent 协作者 会给 AI 明确目标、材料、工具边界和验收标准。 个人系统建设者 会把提示词、文档、工具和复盘组织成稳定的个人系统。 今天就能开始的 3 个动作 01 挑一个真实任务 不要从“我要学 AI”开始，改成“我要用 AI 整理一篇文章、修一个脚本、做一次复盘”。 02 写清输入和验收 把材料、限制、输出格式和合格标准写进任务说明。AI 的发挥空间要大，验收边界要清楚。 03 留下可复用产物 任务完成后，把好用的步骤保存成模板，把踩坑点写进复盘，下次直接从这次结果继续。 验证习惯 关键事实至少用两个独立来源验证。 要求 AI 区分“确知”“推测”和“不知道”。 AI 生成的代码必须运行测试或语法检查。 运维命令先做只读检查，再决定是否改动。 成本、边界和公开范围要写进任务说明，而不是靠临场记忆。 最小验证问题 这个结论从哪里来？哪个地方最可能错？我能用什么小测试在 10 分钟内确认它？ 12 周路线 这条路线不用追求每天都学新工具，而是每两到三周沉淀一个能复用的工作单元。 第 1-2 周 固定常用任务：研究、写作、代码、复盘。每类任务至少保存一个可复制模板。 第 3-4 周 给模板加验收标准：来源要求、检查命令、输出格式、失败时怎么收尾。 第 5-8 周 把重复步骤变成清单或脚本，让 AI 不只生成内容，也帮你检查结果。 第 9-12 周 整理个人知识库和任务记录，开始建立自己的小型 AI 工作系统。 每周复盘问题 这周哪个任务真正被 AI 加速了？为什么？ 哪个回答看起来流畅但其实不能直接用？我后来怎么验证？ 有没有一个步骤值得写成模板、清单或脚本？ 下周最小的可交付成果是什么？ Next Action 把路线变成今天的 30 分钟练习 读完这一页后，不再继续收藏资料，直接选一个真实任务跑一轮提问、验证和复盘。 打开 Docs Planner 的学习计划，按 30 分钟执行。 复制下面的 Prompt，把“当前水平”和“任务”替换成真实材料。 完成后只记录一件事：哪一步最需要被写成模板。 打开 30 分钟学习计划 下一篇：论文工作流 Copy Prompt 我刚读完 AI 路线速查。 请帮我把今天的学习变成一个 30 分钟练习。 当前水平：[写下你会什么、卡在哪里] 真实任务：[写一个今天就能做的小任务] 限制：不要给泛泛书单；必须包含可验证产物。 输出：练习步骤、验收标准、复盘问题。 复制行动 Prompt", "related": [ "./ai-trends.html", "./thesis-ai-workflow.html", "./prompts.html" ] }, { "title": "研究生论文 AI 指南", "label": "Thesis", "url": "./thesis-ai-workflow.html", "topic": "thesis", "summary": "论文选题、文献、正文、引用核验和终稿门禁的 AI 辅助流程。", "homeTitle": "研究生论文 AI 指南", "homeSummary": "工具选择、文献处理、写作节奏、引用核验、诚信边界和终稿门禁。", "readMinutes": 12, "priority": 10, "featured": true, "tags": [ "论文", "文献", "引用", "写作", "诚信边界" ], "updated": "2026-06-08", "content": "定位与原则 AI 的角色是研究助理、语言编辑、结构检查员和流程管理工具，不应被视为论文作者。 论文中的文献、数据、案例、访谈和结论必须能够回到可核验来源。 研究问题、材料取舍、方法选择和核心结论应由作者和导师共同把关。 AI 输出进入论文前，应完成来源核验、语义确认和必要的人工改写。 学校、学院、导师和期刊的 AI 使用规定优先于任何通用流程建议。 基本边界 AI 可以提升检索、阅读、写作和检查效率，但不能替代真实研究、原文阅读、数据采集、导师确认和学术责任。 阶段交付物 准备阶段 论文目录、时间节点、Zotero Collection、导师沟通记录。先建立材料管理系统，再进入密集写作。 选题阶段 题目版本表、研究问题草案、可获得材料清单、风险说明。题目应能清楚说明对象、问题和范围。 文献阶段 检索记录、核心文献表、文献笔记、关键引文页码。AI 摘要只能辅助理解，不能替代原文笔记。 写作阶段 章节粗稿、修改版本、导师反馈处理表。每轮修改应明确处理结构、证据、语言或格式中的具体问题。 终稿阶段 引用检查、格式检查、查重记录、AI 使用记录、最终 Word/PDF。提交前应确认每个核心结论都有材料支撑。 工具选择 项目管理 本地论文目录、Markdown 或 Word。集中保存题目、文献笔记、正文、反馈和版本记录，避免材料只存在于聊天窗口。 文献管理 Zotero 优先。用 Collections 管项目，用 Tags 标记状态，用 Word 插件插入引用和生成参考文献。 文献发现 学校数据库、CNKI、Web of Science、Google Scholar、Semantic Scholar 用于获取一手来源；AI 推荐仅作为检索线索。 AI 检索辅助 Elicit、Consensus、Connected Papers 可用于发现相近论文、研究问题和证据链，但摘要不能替代原文阅读。 写作编辑 GPT Plus 适合选题讨论、概念解释和语言润色；本地 Codex 工作区适合文件整理、批量检查和长期文档维护。 最终检查 AI 检查结构、术语、引用对应和摘要结论一致性；查重、AI 检测、格式模板以学校要求为准。 工具取舍 讨论和润色优先使用 GPT Plus，文件管理和批量检查使用 Codex，引用和参考文献交给 Zotero，最终提交以 Word 和学校模板为准。 操作步骤 01 搭工作台 建立论文目录、Zotero Collection 和导师沟通记录，集中保存学校要求、时间节点、题目记录和反馈。 02 收窄选题 根据专业方向、导师要求、材料可得性和方法难度评估题目，最终题目仍需导师确认。 03 检索文献 先用数据库获取真实文献，再用 AI 工具扩展关键词和研究脉络。无法核验的参考文献不得使用。 04 读出笔记 每篇核心文献记录研究问题、理论、方法、结论、可用位置和关键页码，并形成简短评价。 05 搭综述地图 文献综述按主题、理论、方法或争议组织，避免按作者逐篇罗列，并自然引出研究切入点。 06 写粗稿再润色 作者先完成中心句、证据点和粗稿，再使用 AI 检查结构和润色语言，同时限制 AI 新增事实、数据和文献。 07 维护引用 使用 Zotero 插件插入引用和生成参考文献。优先修正 Zotero 元数据，再刷新 Word 文档。 08 终稿验收 检查题目、摘要、研究问题、章节结论、文献引用、图表编号和学校格式，并保留必要的 AI 使用记录。 执行节奏 每日 20 分钟 处理一条文献、导师反馈或格式问题，并留下可追踪记录。 每日 40 分钟 写一小节或修改一段正文，目标是形成 300-800 字可继续加工的草稿。 每日 20 分钟 使用 AI 检查结构、证据或语言，但不允许 AI 新增事实、数据和参考文献。 每周一次 复盘真实进展、待核验证据、导师沟通问题和下周最小交付物。 关键提示词 01 选题收窄 把大方向压缩成可完成的研究问题。 专业方向：[专业] 拟研究方向：[方向] 可获得材料：[文献/数据/案例/访谈/问卷] 导师偏好的方向是：[要求] 请评估这个方向是否适合研究生毕业论文。 请输出： 1. 题目是否过大 2. 可以收窄的 5 个题目 3. 每个题目的研究问题 4. 可用材料和方法 5. 最大风险 6. 最推荐的一个题目及原因 要求：不要夸大创新性，不要虚构文献和数据来源。 02 文献筛选 只基于你提供的真实文献做分类，不让 AI 编参考文献。 论文题目暂定为：[题目] 已找到的文献标题和摘要：[粘贴列表] 请帮我做文献筛选，而不是替我编文献。 请输出： 1. 哪些文献适合作为核心文献 2. 哪些文献只适合做背景材料 3. 还缺哪几类文献 4. 应该补充哪些关键词继续检索 5. 这些文献可以支持论文哪些章节 要求：", "related": [ "./ai-roadmap.html", "./prompts.html", "./prompt-context-harness.html" ] }, { "title": "Prompt 模板库", "label": "PromptOps", "url": "./prompts.html", "topic": "prompt", "summary": "研究、代码、网页、维护、复盘和验收任务的可复制提示词结构。", "homeTitle": "Prompt 模板库", "homeSummary": "直接从研究、代码、网页、维护、复盘和验收模板开始，替换变量就能用。", "readMinutes": 10, "priority": 30, "featured": false, "tags": [ "Prompt", "模板", "研究", "代码", "复盘" ], "updated": "2026-06-08", "content": "使用原则 先写目标，再写材料，最后写验收标准。 任务越重要，越要明确限制条件和失败时怎么处理。 研究类任务要求来源、日期和不确定性说明。 论文类任务必须禁止虚构文献、数据、访谈和实验结果。 代码类任务要求先读相关文件，再给最小改动和验证命令。 涉及私有材料时，只放必要摘要，不把原始内容直接贴进 prompt。 可复制模板 下面的模板不追求一次覆盖所有情况。使用时先替换方括号里的内容，再删除不需要的限制条件。 01 研究与判断 适合用来判断一个工具、趋势、产品或技术路线是否值得投入时间。 模板正文 请帮我研究：[主题] 我的目标是：[你要做什么决策] 我的背景是：[你的使用场景、限制、已有了解] 请按下面结构输出： 1. 30 秒结论 2. 当前最可靠的事实 3. 仍然不确定的地方 4. 适合我的选择 5. 不建议我做的事 6. 下一步可以验证的小实验 要求： - 优先使用官方来源或一手材料 - 标注信息日期 - 区分事实、推测和个人建议 - 如果证据不足，请明确说“不确定” 怎么改 把“主题”写窄一点，比如不要写“AI 工具”，改成“适合个人知识库的本地 RAG 工具”。 注意 不要让模型直接替你做最终决定。重要结论至少再用一次独立搜索或另一个模型交叉验证。 02 代码修改 适合让 AI 在已有项目里做小而明确的修改，而不是大范围重构。 模板正文 请修改这个项目中的：[功能或问题] 目标： [说明希望用户看到什么变化] 已知背景： [相关文件、错误信息、当前行为] 限制： - 先阅读相关文件再改动 - 优先做最小正确修改 - 不做无关重构 - 不改动与本任务无关的文件 - 如果发现高风险改动，先说明影响再继续 验收： - 说明改了哪些文件 - 运行必要的语法检查或测试 - 如果测试不能运行，说明原因和剩余风险 怎么改 把“目标”写成可观察结果，例如“按钮点击后出现确认提示”，不要只写“优化交互”。 注意 不要同时要求改很多方向。一次只处理一个问题，效果通常更稳。 03 网页内容优化 适合改首页、产品页、公开文档页，让内容更像真人写的，而不是空泛介绍。 模板正文 请优化这个网页的内容：[页面类型] 目标读者： [谁会看这个页面] 我希望读者看完后： [知道什么 / 点击什么 / 采取什么行动] 当前问题： [例如太空泛、太像内部说明、没有重点、没有可信度] 请重点处理： 1. 首屏标题和副标题 2. 主要模块标题 3. 每个模块的说明文字 4. CTA 文案 5. 哪些内容不适合公开展示 要求： - 少用抽象词，多写具体收益 - 不夸大能力 - 不暴露内部细节 - 保持语气清楚、克制、可读 怎么改 先写清“目标读者”。给自己看的笔记站、给客户看的产品页、给朋友看的作品集，写法完全不同。 注意 如果页面内容本身没价值，单纯换标题和排版只能短暂变好看，不能让页面真正有用。 04 检查与维护 适合做系统、网站或自动化任务的健康检查，强调先观察、再改动。 模板正文 请帮我检查并维护：[对象] 目标： [例如确认服务正常、排查错误、上线小改动] 规则： - 先做只读检查 - 先说明发现的问题，再决定是否修改 - 涉及删除、覆盖、重启、网络入口、证书、权限的动作必须先确认 - 不暴露私有材料 请输出： 1. 当前状态 2. 发现的问题 3. 建议动作 4. 已执行动作 5. 验证证据 6. 下次建议 怎么改 把“对象”写具体，例如“个人静态网站”或“某个自动化脚本”，不要只写“服务器”。 注意 维护类任务最怕一上来就改。先读状态、看日志、确认影响范围，通常比立刻修更重要。 05 学习复盘 适合把一天看的内容变成真正的能力，而不是“我好像学过”。 模板正文 请帮我做一次学习复盘。 今天我看了： [材料、课程、文章、视频或实践内容] 我现在的理解： [用自己的话写 3 到 5 句] 请帮我输出： 1. 我真正理解了什么 2. 我还混淆了什么 3. 哪些内容只是“看过”，还不能算掌握 4. 明天最值得做的一个小练习 5. 一个可以检验掌握程度的问题 要求： - 不要夸我 - 不要泛泛总结 - 把复盘变成下一步行动 怎么改 一定要写“我现在的理解”。如果只贴原文，模型会帮你总结材料，但不一定能发现你的理解漏洞。 注意 复盘的产出最好只有一个明日任务。任务太多，第二天通常不会做。 06 结果验收 适合在 AI 已经给出答案后，用第二轮提示把可用性检查一遍。 模板正文 请检查你刚才的结果是否能直接使用。 重点检查： 1. 哪些结论缺少依据？ 2. 哪些步骤不够具体，无法执行？ 3. 哪些地方可能不适合公开展示？ 4. 如果要我现在开始做，第一步是什么？ 5. 最小验收标准是什么？ 请输出： - 可以直接保留的部分 - 需要改写或删除的部分 - 仍需人工", "related": [ "./thesis-ai-workflow.html", "./ai-roadmap.html", "./prompt-context-harness.html" ] }, { "title": "Prompt Engineering 到 Harness Engineering", "label": "HarnessOps", "url": "./prompt-context-harness.html", "topic": "system", "summary": "从 Prompt Engineering、Context Engineering 到 Harness Engineering，把提示词、上下文、工具、验证和边界组成可复用的 AI 工作系统。", "homeTitle": "Prompt 到 Harness 方法论", "homeSummary": "不只优化提示词，而是把上下文、工具、状态、评估和发布门禁一起工程化。", "readMinutes": 11, "priority": 35, "featured": true, "tags": [ "Prompt Engineering", "Context Engineering", "Harness Engineering", "Agent", "评估", "MCP" ], "updated": "2026-06-08", "content": "为什么只写 prompt 不够 Prompt Engineering 解决“这一次怎么说清楚”，Context Engineering 解决“这一次让模型看见什么”，Harness Engineering 解决“每一次任务如何被入口、工具、状态、验证和边界稳定承接”。 过去很多 AI 工作流把注意力放在 prompt 上：写角色、写任务、写格式、写限制。这仍然重要，但已经不是稳定协作的全部。真正影响结果的，往往是上下文是否正确、工具是否可用、状态是否连续、验证是否及时、失败是否能回到系统里。 关键变化 Prompt 是一次对话的起步动作；Harness 是让多次任务可以复现、验收和改进的外部结构。 三层能力栈 Prompt Engineering 关注怎么把这次任务说清楚，产物是任务说明、角色、输入材料、输出格式和限制。 Context Engineering 关注让模型看见哪些事实和状态，产物是文件索引、检索、记忆、工具结果和状态摘要。 Harness Engineering 关注如何把任务放进可运行系统，产物是入口说明、脚本、MCP/工具、测试、门禁、日志和复盘。 这三层不是互相替代，而是逐层包住。好的 Harness 里面仍然需要好 prompt；好的 prompt 也要依赖正确上下文；正确上下文需要工具、索引和验证来保持新鲜。 Prompt Engineering：把意图说清 高质量 prompt 不是华丽措辞，而是结构清楚。一个可复用 prompt 通常包含目标、材料、边界、输出和验收五件事。 目标：这次要产出什么。 材料：模型可以使用哪些输入。 边界：不能做什么，哪些动作需要确认。 输出：用什么格式交付。 验收：完成后需要哪些证据。 对个人工作流来说，prompt 模板最适合覆盖高频任务：研究摘要、论文段落、代码修改、网页发布、运维检查、失败复盘。 Context Engineering：把事实放对 Context Engineering 的核心不是把所有东西塞进窗口，而是选择、压缩、排序和更新上下文。 入口文件 告诉模型这个工作区是什么、先读什么、当前事实源是什么。 最近记录 让模型知道最近已经做过什么、哪些结论仍然有效。 任务文件 只读必要文件，不把整个仓库塞进对话。 工具结果 命令输出、测试报告、网页状态、MCP 查询结果。 长期记忆 项目索引、决策记录、失败索引、可复用模板。 一个好上下文系统要回答四个问题：什么事实是当前的，什么材料是历史的，什么信息可以公开，什么操作必须确认。 Harness Engineering：把协作变成系统 Harness 是让 AI 能稳定完成任务的一组外部结构。它不把可靠性寄托在模型“自己记得”，而是把关键动作放进系统。 入口 AGENTS、README、CURRENT_SERVER、任务索引。 工具 脚本、部署命令、检查命令、MCP、浏览器门禁。 状态 public status、token 用量、备份、版本、notes。 验证 语法检查、测试、截图、DOM 断言、npm audit、smoke test。 边界 只读优先、高风险确认、敏感扫描、公开脱敏。 反馈 维护记录、失败复盘、索引更新、模板改进。 Harness Engineering 的判断标准是：如果换一个新会话、新 Agent 或一个月后的自己来接手，能不能从入口文件和脚本把任务继续做下去。 常用工具和方法 Prompt 模板 Markdown、docs/prompts、片段库，用来固定目标、材料、限制、输出和验收格式。 上下文索引 README、AGENTS、结构化 notes、search-index，用来声明当前事实源和资料边界。 检索和记忆 RAG、向量库、LangGraph memory、项目索引，让长期资料按任务被取回。 工具协议 MCP、函数调用、shell 脚本、浏览器自动化，把检查动作变成可执行工具。 评估系统 OpenAI Evals、Anthropic evals、单元测试、smoke test，用样例和指标发现回退。 发布门禁 deploy preflight、browser gate、敏感扫描、public smoke，防止内容和运行状态回退。 最小落地流程 选一个高频任务，例如发布一篇公开文章。 写一份 prompt 模板：目标、材料、边界、输出、验收。 写入口说明：这类任务先读哪些文件、哪些内容不可公开。 把重复检查脚本化：索引、敏感扫描、语法检查、浏览器截图、发布 smoke。 每次任务后写一条记录：做了什么、验证了什么、下次还要改什么。 把失败点更新回模板或脚本，不只在聊天里解释。 这个流程的关键是先最小可用。不要一开始就追求完整平台；先让一个任务可以从开始到验收稳定跑完。 常", "related": [ "./harness.html", "./thesis-ai-workflow.html", "./ai-roadmap.html" ] }, { "title": "个人 Harness 指南", "label": "Harness", "url": "./harness.html", "topic": "system", "summary": "入口说明、上下文、工具、验证、边界和反馈循环的个人 AI 系统指南。", "homeTitle": "个人 Harness 指南", "homeSummary": "入口说明、上下文、工具、验证、边界和反馈循环六件套。", "readMinutes": 8, "priority": 40, "featured": true, "tags": [ "Harness", "个人系统", "上下文", "验证", "边界" ], "updated": "2026-06-08", "content": "Harness 是什么 个人 AI Harness 是一套让 AI 稳定协作的工作系统：入口说明、上下文资产、工具接口、验证方式、安全边界和反馈循环。它减少临场解释，也减少反复踩坑。 一句话判断 如果每次开新任务都要重新解释背景、边界和验收方法，说明你需要的不是更长的 prompt，而是更清楚的 Harness。 六个组件 入口说明 告诉 AI 任务背景是什么、先读哪些材料、什么目标最重要。 上下文资产 笔记、文档、模板、案例和复盘，构成可复用的长期记忆。 工具接口 脚本、任务、检查命令和自动化流程，把重复动作标准化。 验证系统 语法检查、测试、结果校验和验收清单。 安全边界 私有材料保护、只读优先、高风险动作确认和公开内容脱敏。 反馈循环 每次任务后写记录，把成功流程沉淀为模板、脚本或文档。 最小版本 不需要一开始就搭复杂系统。个人 Harness 的最小版本可以只有三件东西：一页入口说明、一组可复制模板、一张验收清单。 01 入口说明 写清这个工作区是什么、先读哪些文档、什么内容不适合公开、哪些动作需要确认。 02 任务模板 为研究、写作、代码、检查、复盘这些高频任务准备固定结构，减少每次临场发挥。 03 验收清单 规定每类任务完成后要看什么证据：来源、测试、截图、输出文件、复盘记录或下一步动作。 任务如何流动 人定义目标：这次到底要产出什么，而不是“随便优化一下”。 AI 读取入口：先理解上下文、边界和已有材料。 AI 执行小步：每一步都有可观察结果，不把风险动作混在大段回答里。 人和检查清单验收：看结果是否满足标准，必要时要求改写或补证据。 把经验沉淀回文档：好流程变模板，坏流程写复盘。 最小落地路线 先选一个高频任务，例如整理文章、检查网页内容或复盘学习。 为它写一份任务模板：目标、材料、限制、输出格式、验收标准。 跑三次真实任务，把每次失败点补进模板。 把重复检查写成清单，能脚本化的再脚本化。 每周清理一次：保留好用模板，删除不再使用的规则。 成功标准 开始快 新任务能在几分钟内说清目标、材料、边界和验收方法。 结果可查 常见任务都有证据，不只留下“已经处理”的一句话。 边界清楚 私有材料不会进入公开内容，高风险动作先解释影响再确认。 失败可复盘 出错后能从记录里找到原因，并把修正写回模板或清单。 Next Action 搭一个只服务本周的最小 Harness 读完这一页后，不需要先做平台。先把入口说明、一个任务模板和一条验收清单写出来。 打开 Docs Planner 的个人系统计划，按 30 分钟执行。 复制下面的 Prompt，列出 3 个高频任务。 本周只跑一个任务，复盘后再加第二个。 打开 30 分钟系统计划 回到：AI 路线速查 Copy Prompt 我想搭一个个人 AI Harness 的最小版本。 请帮我设计入口说明、任务模板、验收清单和复盘方式。 我的高频任务：[列出 3 个任务] 可用工具或文档：[列出已有材料位置] 限制：先做最小可用，不要设计复杂平台。 输出：一页结构草案、本周落地步骤、第一次运行后的复盘问题。 复制行动 Prompt", "related": [ "./prompt-context-harness.html", "./thesis-ai-workflow.html", "./ai-roadmap.html" ] }, { "title": "AI 工具选择地图", "label": "Tools", "url": "./ai-tools.html", "topic": "tools", "summary": "按任务选择模型、AI IDE、Prompt、RAG、自动化和验证工具。", "homeTitle": "AI 工具选择地图", "homeSummary": "按任务选择模型、AI IDE、Prompt、RAG、自动化和验证方式。", "readMinutes": 9, "priority": 50, "featured": false, "tags": [ "AI 工具", "模型", "AI IDE", "RAG", "自动化" ], "updated": "2026-06-08", "content": "先按任务选，而不是按热度选 AI 工具变化很快，模型名、价格和入口都会过期。更稳定的做法是把任务拆成几层：理解材料、生成草稿、调用工具、检查事实、沉淀流程。 一句话判断 如果任务结果会被公开、提交或影响生产环境，就把验证工具放在模型前面；如果只是探索想法，再追求速度和灵感。 工具分层 通用模型 适合解释、改写、推理和方案比较。重点看上下文、稳定性、价格和中文体验。 AI IDE / CLI 适合读仓库、改文件、跑测试和复盘。重点看权限、回滚、验证命令和上下文组织。 Prompt 模板 适合高频任务复用。重点不是文采，而是目标、材料、限制、输出和验收是否明确。 RAG / 知识库 适合让 AI 基于自己的资料回答。重点是资料结构、检索质量、引用和权限边界。 自动化脚本 适合重复检查、部署、备份和报告。重点是可重复、可观察、失败可定位。 选择前问 5 个问题 这次任务要输出什么可验收结果？ 材料是否需要联网、查本地文档或读取代码？ 错误成本高不高，是否需要人工确认？ 结果是否需要公开，是否有脱敏边界？ 这件事会重复发生吗，值得模板化或脚本化吗？ 把验收写进工具选择 工具再强，也不能替代验收。研究任务要看来源和日期，代码任务要跑测试，网页任务要看移动端和敏感词，运维任务要看服务状态和备份证据。 最小落地路线 先选一个主力通用模型，用它做理解和草稿。 把代码和网页任务交给能读文件、跑命令的 Agent 工具。 为高频任务写 Prompt 模板，连续使用三次后再改。 当资料开始分散，再做轻量知识索引，不要一开始就上复杂 RAG。 Next Action 给当前任务选一套最小工具链 先把任务拆清楚，再决定用聊天模型、Agent、模板还是脚本。 写下这次任务的输出物和失败成本。 从工具分层里只选 1 到 2 个工具。 补一条验收命令或人工检查标准。 打开 Prompt 模板库 继续看：个人 Harness 指南 Copy Prompt 我需要为一个 AI 任务选择工具链。 任务：[说明要完成什么] 材料：[已有资料、文件或网页] 风险：[是否公开、是否涉及生产、是否需要准确来源] 请帮我输出：最小工具组合、每个工具负责什么、验收方式、不要做的事。 复制行动 Prompt", "related": [ "./thesis-ai-workflow.html", "./ai-roadmap.html", "./prompts.html" ] }, { "title": "AI 发展观察", "label": "Trends", "url": "./ai-trends.html", "topic": "learn", "summary": "从多模态、Agent、AI IDE、RAG 和验证习惯看 AI 长期变化。", "homeTitle": "AI 发展观察", "homeSummary": "从多模态、Agent、AI IDE、RAG 和验证习惯看 AI 长期变化。", "readMinutes": 8, "priority": 60, "featured": false, "tags": [ "AI 趋势", "Agent", "多模态", "AI IDE", "知识库" ], "updated": "2026-06-08", "content": "六个长期信号 01 多模态 文本、图像、音频、视频和屏幕状态逐步变成同一个交互界面。 02 Agent AI 从回答问题走向读文件、调用工具、执行步骤和交付结果。 03 AI IDE 代码协作从补全变成读仓库、改文件、跑测试和解释失败。 04 RAG 个人和团队会把自己的资料接进上下文，而不是只依赖模型记忆。 05 验证与评估 输出越多，越需要交叉核对、来源标注和可重复的评估流程把关。 06 个人系统 把资料、工具、边界和复盘组织成可复用系统，而不是只靠聊天记忆。 三次重心迁移 从“会聊天”到“会处理多种材料”。 从“单次回答”到“多步任务执行”。 从“追模型”到“搭系统”：上下文、工具、权限、验证和复盘越来越重要。 个人启示 个人最该补的不是追完每条发布会，而是学会把任务定义清楚，把资料组织好，把 AI 输出接到真实验收里。 学习 读官方来源和长文档，整理成自己的判断清单。 工作流 把论文、网页、代码、复盘拆成可重复步骤。 自动化 把常见检查做成脚本或固定门禁。 知识库 先整理 Markdown 和索引，再考虑复杂 RAG。 来源习惯 模型名称、发布日期、价格、上下文长度和 API 状态都属于高变化事实。公开写作时优先看官方发布页、模型卡、论文、GitHub release 和权威报告；证据不足时写成观察项。 下一步 短期先把公开知识页做成可检索、可更新的静态站。中期再把本地 notes 和 docs 接成个人知识库，让 AI 能基于自己的材料回答维护历史问题。 Next Action 建立一张自己的 AI 趋势观察表 不要只收藏新闻。把每条变化归到能力、工具、成本、风险和可做实验里。 选 3 个官方来源持续看。 每周只记录能影响行动的变化。 每月删掉过期判断。 打开工具选择地图 回到：AI 路线速查 Copy Prompt 请帮我整理一条 AI 趋势信息。 材料：[贴入官方发布、论文摘要或新闻链接摘要] 请区分：已确认事实、仍不确定的地方、对个人学习/工作流的影响、一个可验证的小实验。 要求：不要夸大，不要把单一来源写成确定结论。 复制行动 Prompt", "related": [ "./ai-roadmap.html", "./thesis-ai-workflow.html", "./prompts.html" ] }, { "title": "轻量运维健康检查清单", "label": "Ops", "url": "./hermes-health.html", "topic": "ops", "summary": "公开脱敏版服务状态、备份、资源、网页探针和维护记录检查清单。", "homeTitle": "轻量运维健康检查清单", "homeSummary": "把服务状态、备份、资源、网页探针和维护记录整理成公开脱敏方法。", "readMinutes": 8, "priority": 70, "featured": false, "tags": [ "运维", "健康检查", "备份", "状态页", "维护记录" ], "updated": "2026-06-08", "content": "固定检查顺序 先看核心服务是否运行，避免在服务已挂时继续做细节优化。 再看 failed units、磁盘、内存、备份年龄和公开探针。 最后做最小 smoke test，只验证主链路能回答或页面能打开。 如果要修改配置，先备份，再改动，再复核。 正常信号 核心服务 运行中，并且最近没有反复重启。 系统失败项 没有 failed units，或失败项已有记录和下一步。 资源 根分区和内存有明显余量，不接近告警阈值。 备份 最近备份存在，有校验文件，年龄在预期窗口内。 公开入口 首页、文档、状态页、404、安全头和 gzip 检查通过。 需要处理的情况 核心服务不运行，或 public status 从 ok 变成 warn / fail。 备份超过预期时间，或者最新归档没有校验文件。 磁盘使用率快速增长，尤其是日志、补丁备份和快照目录。 自动更新失败，但没有明确失败原因。 网页发布后 404、安全头、gzip 或 sitemap 检查失败。 维护记录怎么写 只写结论不够。每次维护至少留下目标、动作、验证证据、观察项和下次建议。这样下一次打开工作区时，不需要从聊天记忆里猜发生了什么。 公开边界 公开文章只讲方法，不记录服务器地址、密钥、内部路径、原始日志或备份内容。 自动化优先级 先把检查标准写清楚，再脚本化。最值得自动化的是重复而低风险的检查：状态摘要、备份校验、公开页面探针、敏感词扫描和部署门禁。 Next Action 写一份自己的只读健康检查模板 把常见检查固定下来，之后每次维护都沿着同一张表走。 列出核心服务和公开入口。 写下正常阈值和需要处理的阈值。 每次维护后补一条记录。 继续看：个人 Harness 指南 复制维护 Prompt Copy Prompt 请帮我为一个个人服务器写只读健康检查模板。 范围：[核心服务、公开网页、备份、磁盘、内存] 要求：先检查状态，再判断风险，最后给出下一步。 限制：不要读取密钥，不修改配置，不重启服务。 输出：检查命令、正常标准、需要处理的标准、维护记录模板。 复制行动 Prompt", "related": [ "./stable-skin-visual-gate.html", "./thesis-ai-workflow.html", "./ai-roadmap.html" ] }, { "title": "Stable Skin 与视觉回归门禁", "label": "Gate", "url": "./stable-skin-visual-gate.html", "topic": "ops", "summary": "从 Stable Skin 原理、视觉回归门禁分层、工具选择到发布流程，保护满意视觉不被后续改动悄悄带偏。", "homeTitle": "Stable Skin 与视觉回归门禁", "homeSummary": "先冻结满意的视觉方向，再用 DOM、截图、基准、布局和公开边界检查保护后续改动。", "readMinutes": 14, "priority": 80, "featured": false, "tags": [ "前端", "视觉回归", "Stable Skin", "Playwright", "Chromatic", "Percy", "BackstopJS", "发布检查" ], "updated": "2026-06-08", "content": "为什么需要 Stable Skin 网页视觉最危险的时刻，往往不是“还很丑”的时候，而是“刚刚满意”的时候。因为这时继续改一点按钮、阴影、边距或卡片，很容易把已经成立的整体感打散。 传统功能测试会告诉你按钮还能点、链接还存在、接口还返回 200；但它不一定会告诉你按钮已经被横幅遮住、卡片标题被截断、移动端出现横向滚动，或者整体视觉从稳定变成混乱。 Stable Skin 要解决的不是审美本身，而是视觉判断的可维护性：把一次满意的视觉状态命名、收口、保存证据，并让之后的每次变化都必须被解释。 视觉回归原理 视觉回归测试的基本模型很简单：先在一个被认可的版本上生成基准截图或基准快照，之后每次改动重新渲染相同页面、组件或状态，再把新结果与基准比较。 差异不自动等于错误。它只说明用户看到的东西变了。成熟流程通常允许三种结果：意外差异要修复，预期变化要 approve 并更新基准，可接受噪声要记录并降噪。 截图也不是唯一证据。稳定的视觉门禁通常会组合 DOM 文本、截图可见性、像素或视觉 AI 差异、移动端溢出检查和公开边界扫描。 先收口皮肤 给当前满意版本命名，例如 stable skin、readability pass、status polish，而不是继续留下“最后再改一点”的散乱覆盖。 把重复出现的颜色、卡片背景、输入框、焦点环和控件表面抽成少量 token。 让按钮、筛选、链接、复制控件和命令入口都有清楚的 hover 与 focus-visible 状态。 给长标题、长命令、窄屏布局加 overflow-wrap、min-width、grid 和 max-width 护栏。 冻结主背景、卡片密度、文章宽度、状态面板形态和移动端首屏，后续若要改这些，就按一次明确视觉版本处理。 判断标准 稳定皮肤不是“永远不改”，而是“以后每次改，都知道自己正在改哪一层”。 四层门禁模型 源码一致性 检查资源版本、SEO 元数据、JSON-LD、sitemap、Docs 索引和首页更新是否指向同一轮内容。 DOM 断言 确认文章标题、卡片数量、命令按钮、行动面板和关键 data 标记真的渲染出来。 截图差异 在桌面和移动端生成截图，必要时与基准比较；动态内容用 mock、mask 或 ignore 降噪。 发布边界 确认公开目录不含部署脚本、临时探针、私有路径、密钥、日志或内部状态。 常用工具 工具选择不应从“哪个最强”开始，而应从项目风险和现有流程开始。个人静态站先用轻量脚本就够；组件库更适合 Storybook/Chromatic；团队 PR 流程可接 Percy 或 Applitools；自托管页面级回归可以用 BackstopJS 或 Playwright。 Playwright 适合本地和 CI 的截图基线，能把 visual comparisons 和 E2E 流程放在一起。 Storybook + Chromatic 适合组件库和设计系统，每个 story 都可以成为组件状态的视觉规格。 Percy 适合团队在 PR 中审查多宽度、多浏览器的视觉变化，并管理 baseline。 Applitools 适合跨浏览器、动态内容较多、希望用视觉 AI 降低像素噪声的场景。 BackstopJS 适合静态站、CMS、营销页等 URL/viewport 清单明确的自托管截图对比。 Cypress 插件 适合已有 Cypress 流程的项目，把截图比较嵌入现有 E2E 或组件测试。 落地流程 列出关键页面：首页、Docs 列表、代表性文章、状态页、404。 列出关键视口：390px 手机、768px 平板、1280px 桌面。 冻结动态内容：时间戳、随机头像、动画、第三方 iframe、外部状态接口。 先跑源码检查和 DOM 断言，再生成桌面与移动端截图。 如果引入像素 diff，先从少量高风险页面开始，不要一口气截图所有状态。 定义基准更新规则：为什么更新、影响哪些页面、是否人工确认、是否写维护记录。 先 staging，再 live；发布后确认公开页面、gzip、安全头、真 404 和状态摘要。 这样做的意义 Stable Skin 和视觉门禁的收益，不只是少出视觉 bug。它让审美判断可复用，让 Agent 协作更可靠，让发布前检查更轻，让长期维护不再靠记忆。 对个人项目来说，这尤其重要。AI Agent 很擅长快速改页面，但也容易为了局部需求追加覆盖层。视觉门禁能把“别改坏已有页面”变成可执行约束，而不是一句笼统提醒。 一个网页“好看”之后，如果没有版本号、索引、发布脚本和回归检查保护，很快又会变成靠感觉维护。Stable Skin 的真正价值，是把满意状态变成未来可以继承的工程事实。 常见误区 只看首页，忽略二级页面、长文档、状态", "related": [ "./hermes-health.html", "./thesis-ai-workflow.html", "./ai-roadmap.html" ] } ]